TURN, SFU, WebRTC : explication simple pour les entreprises
Réponse courte
WebRTC est la technologie qui met la vidéo dans le navigateur en temps réel. SFU est un serveur qui relaye les flux entre plusieurs participants sans tout mélanger dans un seul flux. TURN est un relais de secours quand le réseau (pare-feu, NAT) empêche une connexion directe. Ensemble, ils permettent une visio pro fluide, y compris en entreprise — à condition que l'éditeur les dimensionne et les documente pour votre DSI.
Définition simple
WebRTC en une phrase
WebRTC (Web Real-Time Communication) = standards pour envoyer audio, vidéo et données entre navigateurs avec une faible latence, sans plugin. C'est le socle de l'assistance vidéo, de la visioconférence et de nombreux parcours métier.
→ Pourquoi le choisir côté métier : WebRTC et vidéo professionnelle.
SFU et TURN : les deux « aides » de WebRTC
| Terme | Rôle métaphorique | Rôle technique |
|---|---|---|
| WebRTC | La langue parlée par les navigateurs | Capture, encodage, chiffrement, transport temps réel |
| SFU | La salle de conférence intelligente | Chaque participant envoie son flux au serveur ; le serveur redistribue aux autres (Selective Forwarding Unit) |
| TURN | Le passeur si la porte directe est fermée | Relais des flux quand la connexion peer-to-peer est bloquée |
Sans SFU, les grosses réunions satureraient chaque poste. Sans TURN, beaucoup de clients derrière pare-feu d'entreprise ne pourraient pas se connecter.
Pourquoi la DSI et les métiers doivent-ils connaître ces termes ?
Achats et appels d'offres
Les cahiers des charges mentionnent parfois « WebRTC », « hébergement TURN en France », « architecture SFU ». Comprendre le lexique évite de comparer des offres incomparables ou de rejeter une bonne solution par jargon.
Diagnostic des incidents
« Ça marche chez moi, pas chez le client » pointe souvent vers TURN mal configuré ou pare-feu. « La réunion rame à 15 personnes » vers un SFU sous-dimensionné.
Souveraineté et sécurité
Où tournent le SFU et le TURN ? En France, en on-premise ? Les flux passent-ils par un pays tiers ? Questions pour le DPO et la sécurité, complémentaires au RGPD visio.
Comment fonctionne une session WebRTC en entreprise ?
Étape 1 — Signalisation (hors WebRTC strict)
Avant la vidéo, un serveur de signalisation (souvent WebSocket HTTPS) échange les paramètres de session : qui rejoint, quels flux audio/vidéo. Pas le média lui-même — l'annuaire de la réunion.
Étape 2 — ICE : trouver le meilleur chemin
ICE teste plusieurs chemins réseau :
- Connexion directe (peer-to-peer) si possible — latence minimale ;
- Sinon relai TURN — traverse NAT et pare-feu.
C'est transparent pour l'utilisateur s'il clique sur un lien.
Étape 3 — SFU pour les réunions à plusieurs
En 1 contre 1, le direct peut suffire. Dès 3 participants ou plus, l'architecture SFU est standard :
- chaque client envoie un flux vers le SFU ;
- le SFU renvoie les flux des autres ;
- le poste ne décode pas 20 flux entrants lourds — le serveur sélectionne ce qui est renvoyé.
Étape 4 — Qualité adaptative
WebRTC réduit le débit si le réseau faiblit (4G client, Wi-Fi saturé). L'expérience se dégrade parfois en résolution, mais la session continue — utile en support terrain.
WebRTC, SFU, TURN : questions que pose la DSI
Où sont hébergés SFU et TURN ?
Exiger une réponse pays + opérateur dans le DPA. Pour une politique stricte : France ou on-premise sur les deux composants, pas seulement la page web d'accueil.
Le TURN est-il obligatoire ?
En B2B, quasi oui pour les invités externes et les réseaux verrouillés. Un pilote doit inclure des postes derrière pare-feu corporate et des 4G clients.
SFU vs MCU : quelle différence ?
| SFU | MCU (mixeur classique) | |
|---|---|---|
| Principe | Relaie les flux individuels | Mélange tout en un flux |
| Charge serveur | Modérée, scalable | Élevée |
| Latence | Faible | Souvent plus haute |
| Usage pro moderne | Standard visio WebRTC | Plutôt legacy ou salles hardware |
Pour un appel d'offres, « architecture SFU » est aujourd'hui l'attente normale d'une visio WebRTC professionnelle.
Peer-to-peer pur suffit-il ?
Pour de rares 1:1 internes sur réseau ouvert, parfois. Pour le support client et les comités, non — prévoir SFU + TURN dès le cadrage.
Quels symptômes indiquent un problème TURN ou SFU ?
| Symptôme | Cause probable |
|---|---|
| Connexion OK en 4G, échec Wi-Fi bureau client | TURN / pare-feu |
| Un seul sens audio ou vidéo | ICE / TURN partiel |
| Réunion OK à 3, instable à 12 | SFU ou bande passante |
| Latence qui grimpe avec le nombre de participants | SFU sous-dimensionné |
| Ça marche en pilote mais pas en production | TURN non déployé en prod |
Demandez à l'éditeur un guide pare-feu (ports UDP/TCP, domaines TURN) — la DSI l'intègre au runbook.
Quels liens avec l'expérience client et les coûts ?
- TURN bien configuré → plus de clients rejoignent la session → meilleur taux de résolution à distance ;
- SFU stable → réunions sans abandon → expérience client préservée ;
- WebRTC navigateur → pas d'installation → visio sans installation.
La techno n'est pas qu'IT : elle conditionne le ROI métier.
Limites ou points d'attention
- Jargon : certains éditeurs disent « WebRTC » sans préciser SFU/TURN — demander le schéma d'architecture.
- TURN consomme bande passante côté serveur quand tout passe en relais — le dimensionner fait partie du contrat.
- UDP bloqué : certains réseaux imposent du TCP sur TURN — l'éditeur doit le supporter.
- On-premise : vous opérez SFU/TURN ou un infogérant — voir visio on-premise.
- Pas besoin que le métier maîtrise les acronymes — il leur faut un lien qui marche ; la DSI porte la couche réseau.
Exemple concret : déploiement groupe et filiale client
Un groupe déploie la visioconférence pour les comités internes (SFU + TURN en France) et l'assistance client (assistance-video.fr).
Phase pilote DSI :
- Tests depuis réseau strict (UDP filtré) → validation TURN TCP ;
- Réunion 15 personnes → charge SFU OK ;
- Client invité en 4G → ICE choisit direct ou TURN sans action manuelle.
Livrable éditeur : schéma + liste des FQDN à autoriser — intégré au ticket firewall. Produit réunion : meeting.leagora.io. Stack détaillée : technologies WebRTC, open source.
Comment Leagora utilise WebRTC, SFU et TURN ?
Leagora s'appuie sur WebRTC pour les parcours navigateur, avec architectures SFU pour la montée en charge et TURN documentés pour les environnements entreprise :
- assistance, RDV, réunion, live selon le besoin ;
- hébergement France ou on-premise ;
- vidéo sur mesure pour intégrations SI ;
- documentation réseau pour la DSI.
Pour un cadrage technique ou un atelier pare-feu : devis.
FAQ
Faut-il installer quelque chose pour WebRTC ?
Non pour l'invité standard — navigateur récent. La DSI peut devoir autoriser des flux vers SFU/TURN.
SFU et TURN sont-ils deux serveurs distincts ?
Souvent oui en production (rôles différents). Certains déploiements regroupent des fonctions — demander le schéma à l'éditeur.
WebRTC est-il chiffré ?
Oui, flux média DTLS-SRTP en transit. Le chiffrement ne remplace pas la gouvernance (enregistrements, accès admin).
Pourquoi ne pas rester sur Zoom ou Teams ?
Ce sont des stacks fermées avec leurs propres relais. WebRTC ouvert + hébergement maîtrisé répond aux besoins marque blanche et souveraineté — alternative Zoom.
L'éditeur doit-il fournir un test TURN ?
Oui — page de test connectivité ou procédure de pilote incluant postes pare-feu et 4G.
Le métier doit-il comprendre SFU ?
Non. Il doit avoir un parcours simple ; la DSI valide SFU/TURN en amont pour que le parcours tienne en production.
À retenir
- WebRTC = vidéo temps réel dans le navigateur ; socle de la vidéo métier moderne.
- SFU = serveur qui relaye proprement les réunions à plusieurs — standard pro.
- TURN = relais indispensable derrière pare-feu et NAT — à héberger et documenter.
- La DSI doit exiger schéma, localisation et guide pare-feu — pas seulement le mot « WebRTC ».
- Leagora combine ces briques avec hébergement France ou on-prem — WebRTC et devis.