SFU WebRTC : l'architecture Selective Forwarding pour l'entreprise
Réponse courte
Un SFU (Selective Forwarding Unit) est un serveur WebRTC qui reçoit le flux de chaque participant et le redistribue sélectivement aux autres, sans transcodage ni mixage. Cette architecture limite la charge CPU côté client, préserve une faible latence et permet de monter en charge sur les réunions multi-participants. C'est le modèle standard de l'infrastructure vidéo professionnelle moderne.
Qu'est-ce qu'un SFU WebRTC ?
En 1 contre 1, WebRTC peut fonctionner en peer-to-peer direct : chaque poste envoie et reçoit un seul flux. Dès 3 participants ou plus, le modèle P2P impose à chaque client d'encoder N-1 flux et d'en décoder autant : charge réseau et CPU qui devient rapidement insoutenable.
Le SFU corrige cette limite structurelle :
- Chaque client envoie un seul flux vers le serveur ;
- Le SFU choisit quels flux renvoyer à chaque participant (simulcast, SVC, speaker detection) ;
- Le client ne décode que les flux qu'il reçoit : la charge reste maîtrisée.
Le SFU ne remplace pas WebRTC : il en est la brique de distribution média dans une architecture vidéo complète (signalisation, ICE, API, authentification).
Comment fonctionne une session via SFU ?
Une session multi-participants suit généralement ce déroulé :
- Signalisation (HTTPS/WSS) : création de salle, échange SDP, présence ;
- ICE / STUN / TURN : établissement du chemin réseau vers le SFU ;
- Publication : chaque participant envoie audio, vidéo (et parfois partage d'écran) au SFU ;
- Forwarding sélectif : le SFU route les flux pertinents vers chaque récepteur ;
- Adaptation : simulcast ou SVC ajuste la qualité selon la bande passante disponible.
L'utilisateur ne voit qu'une réunion fluide. Pour la DSI, la différence se joue dans la qualité du dimensionnement SFU et la documentation réseau associée.
SFU vs MCU vs P2P : quelle différence ?
| P2P | SFU | MCU | |
|---|---|---|---|
| Principe | Connexion directe entre clients | Relais sélectif des flux individuels | Mixage en un flux composite |
| Transcodage | Non | Non (forwarding) | Oui |
| Latence | Minimale (1:1) | Faible | Souvent plus élevée |
| Charge CPU serveur | Nulle | Modérée, scalable horizontalement | Élevée |
| Participants | 2–3 max en pratique | Dizaines à centaines+ | Variable, coût élevé |
| Usage moderne | Appels courts 1:1 | Standard WebRTC pro | Legacy, salles hardware |
Pour une infrastructure vidéo professionnelle, le SFU est l'approche attendue dans les appels d'offres. Le MCU reste pertinent dans des contextes legacy (salles équipées, mixage hardware), rarement comme socle d'une plateforme WebRTC moderne.
Pourquoi le SFU est central pour la scalabilité ?
- Scaling horizontal : cluster de nœuds SFU derrière un load balancer, avec session pinning (un SFU par session) ;
- Simulcast : le client encode plusieurs qualités ; le SFU transmet celle adaptée à chaque récepteur ;
- SVC (Scalable Video Coding) : couches vidéo dépendantes (VP9, AV1) pour une adaptation fine sans retranscodage ;
- Forwarding sélectif : speaker detection, layout dynamique, réduction des flux inutiles ;
- Faible latence : pas de pipeline de transcodage intermédiaire.
Les ordres de grandeur, le dimensionnement TURN associé et les stratégies de cluster sont détaillés sur scalabilité WebRTC.
Où héberger le SFU ?
Le SFU traite les flux média en temps réel : c'est un composant critique pour la souveraineté et la conformité.
| Modèle | Cas d'usage | Point d'attention |
|---|---|---|
| Cloud France / UE | Déploiement standard, résidence des données en Union européenne | Vérifier la localisation réelle des nœuds SFU, pas seulement du portail web |
| On-premise | Secteurs réglementés, politiques IT strictes | Prévoir le dimensionnement hardware et la redondance |
| Hybride | Collaborateurs internes + invités externes | SFU interne + TURN relais pour les connexions bloquées |
Voir hébergement France et cloud souverain vidéo.
Symptômes d'un SFU sous-dimensionné
| Symptôme | Cause probable |
|---|---|
| Réunion stable à 5, instable à 20 | SFU ou bande passante insuffisante |
| Latence qui grimpe avec les participants | Saturation CPU ou réseau du nœud SFU |
| Qualité dégradée pour tous | Absence de simulcast / SVC |
| Déconnexions aléatoires | Timeouts ICE, pas de TURN de secours |
| OK en pilote, dégradé en production | Charge réelle non simulée, cluster non dimensionné |
Un pilote réseau réel (poste corporate + 4G + partage d'écran) reste le meilleur test avant un déploiement généralisé.
SFU et TURN : rôles complémentaires
Ne pas confondre les deux composants :
- STUN/TURN = connectivité réseau (couche ICE) : traverser NAT et pare-feu ;
- SFU = distribution des flux en réunion multi-participants.
Un participant peut atteindre le SFU via une connexion directe ou un relais TURN. Les deux composants doivent être dimensionnés et documentés séparément. Ensemble avec la signalisation, ils forment l'infrastructure collaborative WebRTC complète.
Ce que la DSI doit exiger de l'éditeur
Avant de valider une architecture SFU, demandez :
- Benchmark documenté pour votre profil (résolution, fps, partage d'écran, nombre de participants) ;
- Schéma d'architecture : signalisation, SFU, TURN, stockage, monitoring ;
- Localisation des nœuds SFU et des relais TURN (France, on-premise, zones) ;
- Stratégie simulcast / SVC activée par défaut ou en option ;
- Métriques ops : packet loss, jitter, bitrate, latence bout-en-bout ;
- Transparence stack : composants open source auditable (mediasoup, Janus, Jitsi…) si exigé par la sécurité.
Sans benchmark, comparer des offres « 50 participants » reste une comparaison de slogans, pas d'infrastructure.
SFU, enregistrement et conformité
L'enregistrement est compatible avec une architecture SFU :
- Côté serveur : capture des flux individuels ou compositing sur le SFU ;
- Côté client : enregistrement local (moins courant en B2B).
La gouvernance RGPD s'applique au stockage, à la durée de rétention et aux droits des personnes. Le SFU lui-même ne stocke pas les flux en temps normal : il les route. L'enregistrement est une couche applicative distincte.
Comment Leagora dimensionne ses SFU ?
Leagora déploie des architectures SFU basées sur des composants open source, dimensionnées pour les usages professionnels (réunion, assistance, live modéré). La plateforme vidéo combine SFU, TURN et API vidéo, avec déploiement France ou on-premise.
Les cas d'usage métier (assistance, rendez-vous, réunion client) sont portés par les produits dédiés : meeting.leagora.io, assistance-video.fr, mes-rdv.fr.
FAQ
Qu'est-ce qu'un SFU WebRTC ?
Un SFU (Selective Forwarding Unit) est un serveur qui relaie les flux vidéo sans les transcoder. Chaque participant envoie un flux ; le SFU le redistribue sélectivement aux autres, réduisant la latence et la consommation CPU côté client.
Un SFU remplace-t-il le peer-to-peer ?
Non : il complète le P2P. Le 1:1 peut rester en direct pour minimiser la latence ; le SFU intervient dès que la session dépasse quelques participants ou que la charge client devient critique.
Combien de participants par SFU ?
Variable selon le hardware, les codecs, le simulcast et le profil d'usage (720p, partage d'écran, etc.). Demandez un benchmark documenté à l'éditeur plutôt qu'un chiffre marketing.
Le SFU transcode-t-il les flux ?
Non : il fait du forwarding pur. C'est ce qui préserve la latence faible et permet le scaling horizontal. Le transcodage relève du MCU ou de pipelines dédiés.
SFU et enregistrement : compatible ?
Oui. L'enregistrement se fait côté serveur (flux individuels ou compositing) ou client. La gouvernance RGPD s'applique au stockage, pas au routage temps réel du SFU.
Peut-on auditer le code du SFU ?
Avec des stacks open source (mediasoup, Janus, Jitsi, Pion…), la transparence est possible : critère souvent exigé par les grands comptes et les équipes sécurité.
À retenir
- SFU = relais sélectif sans transcodage : standard de l'infrastructure WebRTC professionnelle.
- SFU ≠ MCU : latence plus faible, scalabilité horizontale, charge serveur maîtrisée.
- SFU ≠ TURN : distribution média vs connectivité réseau ; les deux sont nécessaires en production B2B.
- Dimensionner SFU + TURN + latence sur un pilote réseau réel, avec benchmark documenté.
Demander un devis
Pour un cadrage SFU, dimensionnement et architecture réseau : demander un devis.