Quel regard portez-vous aujourd'hui sur le marché du streaming qui a vu tomber bon nombre d'acteurs ?
Je crois que le paradoxe de la popularité a été très cruel pour le marché du streaming: les fournisseurs de contenu dont le marketing a été trop efficace, ont dû, pour tenir la charge, supporter les coûts très élevés des infrastructures de streaming.

Vous faites allusion aux Content Delivery Network (CDN), ces réseaux spécialisés élaborés par exemple par Akamai ?
Oui en effet. Ce cruel paradoxe que j'évoque a poussé les fournisseurs de contenus streamés vers les CDN. A mon sens, la qualité était bien au rendez-vous avec ce type de solutions, le retour sur investissement beaucoup moins...

Quelles alternatives proposez-vous ?
Indépendamment de la technologie que nous avons développée, il faut savoir qu'une solution existe depuis bien longtemps: il s'agit du multicast. Une technique que nous pouvons comparer à la diffusion broadband que nous connaissons sur les ondes. Techniquement, avec le multicast, un serveur envoie un stream et un seul sur une adresse IP dite multicast, sur laquelle les visiteurs viennent en quelque sorte se brancher. Ces IP multicast sont gérées au niveau des routeurs. L'avantage saute aux yeux: le serveur n'émet qu'un seul stream et un seul stream est donc véhiculé sur les backbones (artères principales, ndlr) des réseaux.

Si la solution miracle existe, pourquoi n'est-elle pas déployée ?
Pour plusieurs raisons. Déployer une architecture multicast à l'échelle du Net représente un investissement hors de portée. Ensuite, la perspective du multicast entre aujourd'hui en conflit d'intérêt avec les capacités réseau déployées par les opérateurs. Le déploiement du multicast se solderait par de grandes économies de bande passante, donc par une chute des prix de cette bande passante, ce qui n'aiderait pas vraiment les opérateurs à rentabiliser leurs infrastructures. Enfin, dernier obstacle, il n'est pas facile d'identifier les utilisateurs qui sont derrière une adresse IP multicast. Ce qui complique la personnalisation des services, voire les modèles économiques des fournisseurs de contenu. Bref, tout cela explique qu'une grosse incertitude pèse sur le déploiement à terme du multicast. C'est un vrai problème car d'un côté les contenus deviennent plus riches, de l'autre les débits locaux s'améliorent, et au milieu le goulet d'étranglement se précise...

Sur quelles solutions réellement opérationnelles peuvent s'appuyer les utilisateurs ?
J'en vois au moins deux. Les CDN que nous évoquions tout à l'heure ou les systèmes de cache qui permettent de rapprocher le contenu de son destinataire représentent une première solution. Mais leur coût ne les met pas à la portée de toutes les bourses ou de tous les projets. Aux côtés de ses CDN et des solutions de cache, nous entendons proposer une autre piste. C'est une solution alternative, dans le sens où elle a encore peu de poids sur le marché. Nous pensons toutefois qu'elle a le mérite d'être pragmatique.

Quels procédés met-elle en oeuvre ?
Notre système demande d'installer chez l'hébergeur une plate-forme serveur aux côtés du serveur de streaming. Cette plate-forme, vTcaster, va se charger d'analyser les demandes de streams des visiteurs. Prenons le cas d'une entreprise qui possède cinq sites et souhaite diffuser le discours de son président. Notre solution va analyser d'un point de vue réseau les demandes de connexion. Et au lieu de produire 200 streams pour répondre à 200 demandes individuelles réparties sur les 5 sites, elle va envoyer le stream à un utilisateur par site. Le poste de cet utilisateur va alors à son tour reproduire le stream sur une adresse IP multicast vers laquelle seront routés de façon transparente les utilisateurs du site qui souhaitent visualiser la séquence.

Votre dispositif suppose que les réseaux locaux des entreprises puissent exploiter du multicast. Comment procéder si ce n'est pas le cas ?
Aujourd'hui, la majeure partie des routeurs installés dans l'entreprise peuvent gérer du multicast. Cela dit, c'est un fait, tout le monde ne le permet pas forcément. Dans ce cas, nous fonctionnons selon le principe du "peer-to-peer": l'utilisateur qui, sur un site, sera le premier à recevoir un stream le transmettra à son voisin et ainsi de suite. La puissance dont nous disposons aujourd'hui avec nos PC permet tout à fait de gérer le streaming de la sorte, sur un mode "peer-to-peer". C'est également le mode de fonctionnement que nous préconisons pour des applications de streaming qui sortent du périmètre maîtrisé de l'entreprise.

Outre l'installation d'une plate-forme serveur chez l'hébergeur, quels sont les autres pré-requis de votre dispositif ?
Tout d'abord une précision: notre plate-forme prend l'apparence d'une boîte noire qui embarque notre application fonctionnant sous Solaris ou Linux. Côté utilisateur, le dispositif est plutôt léger puisqu'il demande juste de télécharger un composant ActiveX qui prendra en charge le dialogue avec la plate-forme serveur.

Nous avons commencé cet entretien en parlant des coûts du streaming. Quel est votre modèle tarifaire ?
Pour 5 000 utilisateurs, notre solution avoisine les 25 000 dollars et pour 15 000 environ 45 000 dollars. Pour les radios en ligne, nous proposons une offre particulière qui, pour 10 000 dollars, permet de gérer 1000 utilisateurs.

Je suppose que vous n'êtes pas les seuls à avoir imaginé ce procédé ?
Trois sociétés américaines nous semblent être des concurrents assez proches. Cela dit, deux d'entre elles ne couvrent que l'audio, pour les radios en ligne, et une autre est intimement liée aux formats vidéos. Dans notre cas, nous sommes indépendants du format et cohabitons aussi bien avec les technologies de Real Media que celles de Microsoft. Nous comptons beaucoup sur ce point pour faire la différence dans les mois à venir.