WebRTC : la visioconférence directement dans le navigateur

Un lien cliqué, une caméra qui s’allume, un interlocuteur qui apparaît : aucune installation, aucun compte à créer, aucun plugin. Cette expérience repose sur WebRTC, l’ensemble de technologies qui rend la visioconférence dans le navigateur possible depuis n’importe quel poste récent. Derrière cette apparente simplicité se cache une mécanique réseau qui explique la plupart des surprises rencontrées en cours de projet, à commencer par les coûts d’infrastructure.

WebRTC, la visioconférence dans le navigateur sans installation

WebRTC désigne un ensemble d’interfaces de programmation intégrées aux navigateurs, accompagné d’un jeu de protocoles réseau standardisés. Son objet est la communication en temps réel : audio, vidéo, et transfert de données quelconques entre deux points, sans passer par un logiciel installé sur le poste de travail. Les navigateurs courants le prennent en charge depuis plusieurs années, sur ordinateur comme sur mobile.

La différence avec une application de réunion classique tient au chemin des flux. Dans un outil traditionnel, chaque participant envoie son image à un serveur central, qui la redistribue. WebRTC permet, dans son cas le plus simple, un échange direct entre deux navigateurs : les paquets audio et vidéo empruntent le chemin le plus court disponible, ce qui réduit la latence et le coût de bande passante. Cette architecture pair à pair constitue l’argument principal de la technologie.

Une précision compte pour cadrer les attentes : WebRTC ne fournit ni salle d’attente, ni liste de participants, ni enregistrement, ni compte utilisateur. La norme couvre le transport des flux et la négociation entre les deux extrémités. Tout le reste, c’est-à-dire l’expérience produit, relève du développement applicatif. Un projet de visioconférence sur mesure consiste donc à construire une application autour d’une brique de transport, pas à activer une fonctionnalité.

Ce qui se passe vraiment quand deux navigateurs se parlent

Trois étapes s’enchaînent avant qu’une image apparaisse. La première est l’accès au matériel : le navigateur demande l’autorisation d’utiliser la caméra et le microphone, et cette demande n’aboutit que sur une page servie en HTTPS. Un site non sécurisé ne peut tout simplement pas ouvrir de caméra, ce qui élimine d’emblée les environnements de test bricolés.

La deuxième étape s’appelle la signalisation. Les deux navigateurs doivent échanger leurs paramètres : formats acceptés, résolutions, adresses réseau candidates. WebRTC ne définit délibérément aucun mécanisme pour ce dialogue préalable, laissant l’application choisir le sien. En pratique, la plupart des projets utilisent une connexion WebSocket vers un serveur applicatif, parfois complétée par des appels vers une interface de programmation classique dont le fonctionnement est décrit dans notre article sur l’API REST expliquée simplement. Ce serveur de signalisation reste léger : il transporte quelques messages, pas des flux vidéo.

La troisième étape est la découverte du chemin réseau, gérée par le mécanisme ICE. Chaque poste propose ses adresses possibles, et les deux extrémités testent les combinaisons jusqu’à en trouver une qui fonctionne. Un serveur STUN aide chaque participant à connaître l’adresse publique sous laquelle il est vu depuis internet. Quand aucun chemin direct n’aboutit, typiquement derrière un pare-feu d’entreprise restrictif, un serveur TURN prend le relais et fait transiter les flux par son intermédiaire. Cette bascule est invisible pour l’utilisateur, mais elle change la facture.

Au-delà de deux participants : le rôle du serveur média

L’échange direct fonctionne parfaitement à deux. À quatre, chaque poste envoie son flux à trois destinataires et en reçoit trois : la charge grimpe rapidement, et le débit montant d’une connexion domestique ou d’un poste en mobilité devient le facteur limitant. Passé un petit groupe, une architecture pair à pair intégrale devient inconfortable.

La réponse habituelle porte le nom de SFU, pour unité de retransmission sélective. Chaque participant envoie son flux une seule fois à ce serveur, qui se contente de le réexpédier aux autres sans le décoder ni le recomposer. La consommation processeur du serveur reste modérée, et le débit montant de chaque poste redevient constant quel que soit le nombre de participants. Une variante plus lourde, le MCU, mélange les flux en une image unique : elle soulage les postes faibles mais coûte beaucoup plus cher en calcul.

Le choix se fait au cadrage, pas en cours de route : basculer d’une architecture à l’autre suppose de revoir le serveur, la logique de salle et souvent l’interface. Une erreur de dimensionnement à ce stade coûte plus cher que l’ensemble du développement de l’interface utilisateur.

Un dernier paramètre pèse sur la qualité perçue : le codec, c’est-à-dire la méthode de compression des images et du son. Les navigateurs s’entendent sur un socle commun de formats vidéo, et l’audio repose largement sur un codec conçu pour la voix, capable de s’adapter en continu à la bande passante disponible. Cette adaptation automatique explique pourquoi une réunion reste intelligible quand le réseau faiblit : la qualité vidéo chute d’abord, la voix est protégée en dernier. Un prestataire qui promet une résolution constante quel que soit le réseau décrit une situation qui n’existe pas.

Sécurité, confidentialité et hébergement des flux

Le chiffrement des médias n’est pas une option activable : il est obligatoire dans la norme. Les clés se négocient au moment de l’établissement de la session, et les flux audio et vidéo circulent chiffrés de bout en bout entre les deux extrémités de la connexion. Un appel direct entre deux navigateurs échappe donc à toute lecture intermédiaire.

La nuance apparaît dès qu’un serveur média entre en jeu. Un SFU réexpédie les flux, ce qui suppose techniquement de traiter les paquets : le chiffrement de bout en bout au sens strict, où le serveur lui-même ne peut rien lire, exige des dispositifs supplémentaires que tous les projets ne mettent pas en place. Pour un usage impliquant des données sensibles, la question à poser au prestataire est simple : le serveur qui relaie peut-il, techniquement, restituer le contenu de la réunion.

L’hébergement mérite le même examen. Un serveur relais installé en Europe et administré par l’entreprise offre une maîtrise que ne procure aucun service tiers, au prix d’une exploitation à assumer. Les enregistrements, quand ils existent, constituent des données personnelles à part entière : durée de conservation, information des participants et base légale se traitent avant la mise en production, pas après le premier incident.

Ce que coûte une brique de visioconférence

Deux postes structurent le budget. Le développement applicatif d’abord : interface, gestion des salles, droits d’accès, partage d’écran, comportement en cas de coupure réseau. L’infrastructure ensuite, dominée par la bande passante relayée. Un flux vidéo de qualité correcte consomme de l’ordre du mégabit par seconde et par participant, chiffre à multiplier par la durée et le nombre de sessions relayées.

La part des sessions nécessitant un relais varie fortement selon le parc visé : un public grand public passe majoritairement en direct, tandis qu’un public salarié derrière des réseaux d’entreprise verrouillés sollicite bien davantage le relais. Cette proportion se mesure lors d’une phase pilote, et elle conditionne la facture mensuelle bien plus que le nombre d’utilisateurs déclarés.

Quand cette technologie est un bon choix, et quand elle ne l’est pas

WebRTC s’impose quand la vidéo doit s’intégrer à un parcours existant : une téléconsultation dans un espace patient, une visite d’un bien depuis une annonce, une assistance technique lancée depuis un espace client, un entretien de recrutement dans un outil de suivi de candidatures. L’absence d’installation supprime la friction, et l’intégration dans un outil interne réellement adopté évite de disperser les usages entre plusieurs applications.

À l’inverse, remplacer un outil de réunion générique par un développement sur mesure se justifie rarement. Un service du marché apporte des années de traitement des cas limites : réseaux instables, matériels exotiques, accessibilité, sous-titrage. Reproduire cette maturité représente un investissement sans retour si le besoin se résume à des réunions internes.

Le cas du mobile mérite un examen séparé. Une session vidéo lancée depuis un navigateur mobile fonctionne, mais l’expérience se dégrade dès que l’utilisateur verrouille son écran, reçoit un appel ou change de réseau. Une application installée gère ces transitions bien plus proprement, au prix d’un projet distinct dont les ordres de grandeur budgétaires n’ont rien à voir avec ceux d’une page web. Arbitrer entre les deux suppose de savoir si les appels seront majoritairement passés depuis un poste fixe ou en déplacement.

Trois questions départagent les deux situations. La vidéo apporte-t-elle une valeur propre au parcours métier, ou remplace-t-elle un outil déjà satisfaisant. Les données échangées imposent-elles une maîtrise de l’hébergement. Le volume prévisible justifie-t-il une infrastructure dédiée. Trois réponses positives orientent vers le développement ; une seule suffit rarement.

Le repère à garder en tête

La visioconférence dans le navigateur est devenue accessible, pas gratuite. La technologie de transport est mûre, standardisée et gratuite à utiliser ; ce qui se paie, c’est l’application autour, la capacité à absorber les réseaux hostiles et l’exploitation des serveurs relais. Un projet cadré sur ces trois postes, avec une phase pilote mesurée avant l’engagement, part sur des bases solides.