Cela fait dix ans que nous avons lancé notre première solution UCC basée sur le WebRTC. Mais pourquoi avons-nous choisi cette solution innovante ? Jetons un coup d’œil sur le WebRTC et sur sa genèse.
Une brève histoire du WebRTC : La phase préparatoire
Wildix utilisait des applets pour créer des connexions directes sans serveur dans le navigateur depuis la sortie de son premier client logiciel en 2009. Il s’agissait d’une manière maladroite de procéder, et s’en suivait toute une série de problèmes – un manque de support entre les navigateurs, des mises à jour mineures des navigateurs qui pouvaient casser les choses apparemment au hasard et la dépendance réduite à Java dans les navigateurs en raison de problèmes de sécurité (et d’efficacité).
Le principal problème était l’absence de normalisation entre les navigateurs et l’absence de prise en charge intégrée des technologies permettant les vidéoconférences d’égal à égal.
Pourtant, nous avons réussi à faire en sorte que cela fonctionne. Tout simplement.
Les technologies clés existaient déjà, cependant. Le streaming P2P sans serveur était disponible gratuitement depuis la fin des années 90 et le début des années 2000, notamment avec l’essor des torrents de partage de fichiers. Les adolescents et les jeunes d’une vingtaine d’années de l’époque connaissaient probablement « un ami » qui avait régulièrement accès à des émissions de télévision et à des films populaires bien avant leur sortie en salle.
De plus, les fournisseurs de télécommunications avaient déjà commencé à percevoir la menace que représentait l’accès facile aux flux de données. Flash 2.0 prenait en charge le son stéréo dès 1997, et diverses messageries instantanées, telles que AOL, MSN Messenger et même Yahoo Messenger, offraient des possibilités d’appel ainsi que des fonctions de type SMS.
Parallèlement, Mark Spencer a développé Asterisk, le premier IP-PBX, en 1999, parce qu’il n’avait pas les moyens d’acheter un PBX conventionnel pour son entreprise. Asterisk a servi de base à de très nombreux IP-PBX et a fini par inspirer l’Ecosystème Bleu Wildix.
Skype, l’une des premières solutions d’appel vidéo sur IP, a été lancé en version bêta en 2003. Tous ces éléments donnaient un aperçu de ce que l’avenir nous réservait, et c’est un avenir que Dimitri et Steve Osler pouvaient prédire. D’autant plus que la thèse de Dimitri portait sur le développement d’Asterisk.
Le décor était donc planté pour le WebRTC
Le développement du WebRTC
Global IP Solutions a été fondée en 1999 et s’est concentrée sur les logiciels intégrés permettant des communications en temps réel (voix et vidéo) pour les réseaux IP. En règle générale, ses produits étaient livrés sous forme de « moteurs » regroupant tout ce dont le client avait besoin.
La société a compris que la plupart des technologies VoIP avaient été développées pour des réseaux à commutation de circuits, c’est-à-dire des réseaux dotés d’un canal dédié par lequel les nœuds du réseau pouvaient communiquer. Ces réseaux étaient très stables et on pouvait compter sur eux pour produire des conditions optimales pour la VoIP.
Cependant, la plupart des appels VoIP passent par des réseaux IP publics, qui sont sujets à la perte de paquets, au retard et à la gigue. Un appel vers un bureau situé sur le même réseau ne posait pas de problème, mais un appel vers un client externe était souvent inutilisable.
Global IP Solutions a été racheté par Google pour 68,2 millions de dollars en 2010, qui a commencé à intégrer ses brevets et ses idées dans sa propre norme open-source : le WebRTC. La société a également collaboré avec d’autres entreprises pour développer cette idée.
La première version du WebRTC a été publiée en janvier 2011 par Ericsson Labs (alors une subdivision d’Ericsson). Il s’agissait d’un simple article de blog : il y a eu très peu de bruit autour. Pour beaucoup, c’est passé totalement inaperçu.
En juin de la même année, Google a publié le code source du WebRTC et, l’année suivante, il a soumis la spécification WebRTC au World Wide Web Consortium et à l’Internet Engineering Task Force afin de contribuer à la normalisation du protocole. C’est ainsi que Chrome et Firefox ont mis en œuvre le WebRTC en 2013.
Wildix a rapidement constaté que le protocole était très polyvalent et suffisamment sûr pour être utilisé. Nous avons abandonné les applets NPAPI que nous avions développés et nous avons cherché comment incorporer les éléments critiques dans un programme compatible avec le WebRTC.
Ou plutôt, nous avons presque abandonné ces applets NPAPI. En réalité, si Chrome et Firefox prenaient en charge le WebRTC, le navigateur web de Microsoft ne le faisait pas à l’époque. Si nous nous étions concentrés sur le marché grand public, cela n’aurait pas posé de problème, mais Internet Explorer – puis Edge – était encore largement utilisé par les entreprises.
À l’été 2013, nous disposions d’une solution de communication WebRTC fonctionnelle pour les pages web : WebRTC Kite. Cela nous a permis de connecter nos PBX à la page web pour améliorer la communication en temps réel. Bien que nous ayons réalisé une solution similaire auparavant avec Collaboration fonctionnant dans le navigateur, cette technologie unique a rendu le processus beaucoup plus simple. Mais en raison des problèmes susmentionnés – la solution « normalisée » ne l’était pas encore – nous avons constaté que nous devions maintenir beaucoup de code et un grand nombre de mises à jour pour d’autres navigateurs.
Mais les clients difficiles devenaient redondants.
Au fur et à mesure que les navigateurs intégraient le WebRTC, nos premières difficultés de croissance disparaissaient. Microsoft a fini par intégrer une forme du WebRTC (presque) dans son navigateur en 2017, car il était déterminé à faire quelque chose de différent, comme d’habitude.
Même si le WebRTC devenait rapidement une norme, l’état d’esprit de nombreuses solutions UC&C posait encore des problèmes importants. La plupart d’entre elles nécessitaient encore le téléchargement d’une sorte de client matériel, et c’est encore le cas en 2023 ! Cela peut entraîner des problèmes de sécurité, l’un des plus récents étant (à l’heure où nous écrivons ces lignes) l’incident de sécurité de 3CX.
De même, la plupart des solutions dites WebRTC sont encore maintenues par les applets et les plugins du début des années 2010, ce qui se traduit par un temps de développement beaucoup plus long, une stabilité moindre et une sécurité plus faible. Après tout, pourquoi télécharger quelque chose quand tout est disponible dans votre propre navigateur ? Pour nous, cela n’a aucun sens.
Quelques utilisations du WebRTC
Les utilisations du WebRTC ne se limitent pas aux communications en temps réel. Comme le montre notre développement de x-bees, il est possible d’intégrer une vaste gamme de produits à une solution WebRTC, et le fait que tout se passe dans le navigateur la rend très efficace.
Prenons par exemple l’intégration avec Salesforce. Elle permet l’ouverture automatique des appels entrants et sortants, la détection automatique des contacts existants dans la base de données Salesforce et l’affichage d’une fenêtre contextuelle pour les appels entrants.
Il n’y a que très peu de marge de manœuvre supplémentaire et il n’est pas nécessaire de procéder à une intégration complexe avec un client lourd. Du point de vue du personnel, cette intégration simple se traduit par un gain de temps considérable : plus besoin de copier et de coller les numéros (ou de les saisir manuellement). Elle permet également d’extraire rapidement des enregistrements de la base de données à partir d’un simple numéro, s’ils existent déjà.
Ajoutez à cela l’enregistrement automatique des appels, des chats, etc., et vous obtenez une solution fortement axée sur la vente qui permet de conserver vos contacts.
Mais le WebRTC peut faire encore plus. Comme nous l’avons déjà mentionné, la vidéoconférence consiste simplement à faire transiter des données sur un réseau. Qu’en est-il de l’accès à distance via le WebRTC ? Au lieu de télécharger un logiciel encombrant, un canal de données WebRTC peut être utilisé (avec l’autorisation du client) pour contrôler un système à distance. Cela pourrait faciliter la vérification d’un ordinateur pour les MSP et autres fournisseurs de services informatiques, en particulier lorsqu’une assistance technique ponctuelle est nécessaire.
Wildix peut déjà le faire par le biais du WebRTC.
D’autres possibilités sont en cours d’élaboration.
L’effet du WebRTC
Le WebRTC a permis de normaliser les éléments de base du navigateur pour permettre les communications en temps réel. Le navigateur qui l’utilise n’a pas vraiment d’importance – tous les navigateurs importants ont désormais une forme de WebRTC activée.
Wildix peut être utilisé par presque tous les systèmes, sans plugins ou téléchargements supplémentaires. Il est donc léger, facile à utiliser et rapide à déployer.
La question est donc la suivante : Pourquoi ne pas opter pour une solution WebRTC ?
Pour plus de conseils marketing, inscrivez-vous pour recevoir gratuitement notre magazine !