WebRTC en 2026 : SFU, MCU ou P2P, comment choisir ?
Quand on construit ou choisit un système de visioconférence, la première décision technique est l’architecture de transport des flux média. Trois modèles existent : le pair-à-pair (P2P), le serveur qui fusionne (MCU) et le serveur qui relaie (SFU). En 2026, le SFU domine largement, mais comprendre les trois est nécessaire pour faire un choix éclairé et éviter les pièges.
Qu’est-ce que le P2P (pair-à-pair) ?
En P2P, les participants s’envoient directement leurs flux audio et vidéo, sans passer par un serveur. Chaque navigateur établit une connexion WebRTC avec chaque autre participant.
L’avantage est la latence minimale : aucun serveur intermédiaire ne traite ni ne relaie les paquets. Pour un appel à deux, c’est le modèle le plus efficace.
La limite est mathématique. Avec N participants, chacun doit envoyer N-1 flux. Pour 5 personnes en vidéo 720p (environ 1,5 Mbit/s par flux), chaque participant doit envoyer 4 × 1,5 = 6 Mbit/s en montant. À 10 participants, c’est 13,5 Mbit/s en montant par personne. La bande passante requise croît en O(N²), ce qui rend le P2P impraticable au-delà de 3 à 4 participants avec des connexions résidentielles.
Le P2P n’a pas non plus de point central pour l’enregistrement, la modération ou le contrôle des flux. C’est le modèle le plus simple mais le moins flexible.
Qui utilise le P2P en 2026 ? Jitsi Meet bascule automatiquement en P2P pour les appels à deux (jitsi.org). WebRTC natif dans les navigateurs fonctionne en P2P par défaut. Mais aucun système de visioconférence sérieux ne repose sur le P2P pour les réunions de groupe.
Qu’est-ce que le MCU (Multipoint Control Unit) ?
Le MCU est l’architecture historique de la visioconférence. Un serveur central reçoit les flux de tous les participants, les décode, les fusionne en un seul flux composite (une mosaïque vidéo et un mixage audio), puis envoie ce flux unique à chaque participant.
L’avantage est la faible bande passante côté participant : chacun ne reçoit qu’un seul flux, quelle que soit la taille du groupe. C’est aussi le seul modèle qui permet d’envoyer un flux composite vers des systèmes SIP ou des terminaux de téléphonie classique.
La limite est la consommation CPU du serveur. Décoder, fusionner et réencoder N flux vidéo en temps réel est l’opération la plus gourmande en ressources dans la visioconférence. Le MCU est un goulot d’étranglement qui limite drastiquement la scalabilité.
BigBlueButton utilise encore un MCU pour l’audio : FreeSWITCH décompresse les flux audio de tous les participants, les mixe, et réencode le résultat. C’est ce qui explique en partie les exigences matérielles de BBB (16 Go RAM, 8 cœurs, bare metal recommandé) (doc d’architecture BBB) et la consommation CPU élevée de FreeSWITCH (4,5 à 7 threads pour 167 utilisateurs selon Octopuce).
Qui utilise le MCU en 2026 ? Presque plus personne pour la vidéo. Le MCU reste présent dans les passerelles SIP (Janus, jigasi pour Jitsi) et dans le mixage audio de BigBlueButton. Mais les nouveaux projets ne choisissent plus le MCU comme architecture principale.
Qu’est-ce que le SFU (Selective Forwarding Unit) ?
Le SFU est le modèle dominant en 2026. Un serveur central reçoit le flux de chaque participant (une seule fois) et le redistribue sélectivement aux autres, sans le décoder, sans le réencoder, sans le fusionner.
L’avantage côté participant : chacun n’envoie son flux qu’une seule fois (vers le serveur), ce qui économise la bande passante montante par rapport au P2P. La bande passante descendante reste proportionnelle au nombre de flux souscrits, mais le SFU peut gérer cela intelligemment (simulcast, sélection du locuteur actif, réduction adaptative du nombre de flux).
L’avantage côté serveur : le SFU ne touche pas au contenu des paquets. Il les reçoit et les renvoie. Le travail CPU est une fraction de celui d’un MCU. Un SFU bien implémenté peut tenir des centaines de participants sur un serveur modeste.
L’avantage sécurité : puisque le SFU ne décode pas les flux, il est possible d’ajouter une couche de chiffrement de bout en bout par-dessus DTLS-SRTP. Le serveur relaie les paquets chiffrés sans pouvoir en lire le contenu. C’est ce que fait Jitsi avec Insertable Streams (jitsi.org) et c’est le modèle natif de Vuisio.
La limite : la bande passante descendante du participant augmente avec le nombre de flux reçus. Mais en pratique, les SFU modernes contournent ce problème avec le simulcast (chaque participant publie plusieurs qualités, le SFU choisit la bonne pour chaque récepteur) et la sélection du locuteur actif (seules les vidéos des personnes qui parlent sont envoyées en haute qualité).
Comparatif synthétique
| Critère | P2P | MCU | SFU |
|---|---|---|---|
| Serveur nécessaire | Non | Oui (très puissant) | Oui (modeste) |
| Bande passante montante | O(N) par participant | O(1) | O(1) |
| Bande passante descendante | O(N) par participant | O(1) | O(N) optimisable |
| CPU serveur | Aucun | Très élevé (décodage + encodage) | Très faible (relai de paquets) |
| Scalabilité | 2 à 3 participants | Dizaines (selon CPU) | Centaines à milliers |
| Latence | Minimale | Élevée (traitement serveur) | Faible (relai direct) |
| Chiffrement de bout en bout | Natif (DTLS-SRTP) | Impossible (le serveur décode) | Possible (Insertable Streams, E2EE) |
| Enregistrement côté serveur | Impossible | Possible (flux composite) | Possible (capture des flux relayés) |
| Qualité adaptative | Non | Non (flux unique) | Oui (simulcast, sélection de couche) |
| Cas d’usage 2026 | Appels 1:1 | Passerelles SIP, héritage | Visioconférence, classes virtuelles, agents IA |
Pourquoi le SFU domine en 2026
Trois facteurs expliquent la convergence de l’industrie vers le SFU.
La bande passante a augmenté, le CPU reste cher
En 2026, les connexions fibre et 5G rendent la bande passante descendante abondante. Recevoir 5 ou 10 flux vidéo n’est plus un problème pour la plupart des participants. En revanche, le CPU serveur reste la ressource la plus coûteuse et la plus difficile à scaler. Le SFU fait le bon compromis : il consomme de la bande passante (abondante) au lieu du CPU (cher).
Le simulcast et la qualité adaptative
Le SFU moderne ne se contente pas de relayer bêtement. Avec le simulcast, chaque participant publie son flux en 2 à 3 qualités (basse, moyenne, haute). Le SFU choisit la qualité appropriée pour chaque récepteur en fonction de sa bande passante et de la taille d’affichage. C’est le meilleur des deux mondes : la flexibilité du flux individuel (SFU) avec l’économie de bande passante du flux adaptatif.
Vuisio implémente cette logique dans son SFU Rust : il identifie automatiquement le locuteur actif et n’envoie en priorité que les vidéos des intervenants actifs dans les grandes réunions, ce qui limite naturellement la consommation de bande passante (docs.vuis.io).
L’architecture hybride devient la norme
Un article de référence sur les architectures WebRTC en production note que « la topologie hybride domine en 2026 : P2P pour les appels 1:1, SFU pour les groupes, sélectionné dynamiquement par session » (Forasoft). C’est exactement l’approche de Jitsi Meet. Vuisio simplifie en utilisant le SFU pour tous les cas, ce qui élimine la complexité de la bascule P2P/SFU.
Tous les SFU ne se valent pas
Le modèle SFU est un choix d’architecture, pas une garantie de qualité. L’implémentation fait la différence.
| Critère | JVB (Jitsi) | LiveKit | mediasoup | Vuisio |
|---|---|---|---|---|
| Langage | Java | Go (Pion) | C++ (worker) + Node.js | Rust (str0m) |
| Garbage collector | Oui (JVM) | Oui (Go GC) | Non (C++) / Oui (V8) | Non |
| Transcodage | Non (SFU pur) | Non (SFU pur) | Non (SFU pur) | Non (SFU pur, relai RTP brut) |
| Architecture I/O | Threads JVM | Goroutines Go | libuv (Node.js) + threads C++ | Multi-thread natif, socket UDP par thread (docs.vuis.io) |
| Sécurité mémoire | JVM (managed) | Go (managed) | C++ (non garanti) | Rust (garanti à la compilation) |
| Produit complet inclus | Oui (Jitsi Meet) | Non (toolkit) | Non (bibliothèque) | Oui (Vuisio, client web, modules) |
| Éditeur | 8x8 (États-Unis) | LiveKit Inc. (États-Unis) | Communauté open source | Geezot (France) |
La différence fondamentale entre un SFU Go/Java et un SFU Rust est la prévisibilité. Go et Java ont un garbage collector qui peut introduire des pauses de latence imprévisibles (10 à 50 ms sous charge en Go selon golang/go #37116). OpenAI, qui utilise Go pour son infrastructure WebRTC temps réel, a dû contourner ce problème avec des buffers pré-alloués (OpenAI). Rust élimine le GC entièrement : la latence est constante, pas juste faible en moyenne.
Comment choisir pour votre projet ?
Choisissez le P2P si votre cas d’usage est strictement limité aux appels 1:1 (téléconsultation, support client) et que vous n’avez besoin ni d’enregistrement ni de modération côté serveur.
Choisissez un SFU si vous faites de la visioconférence de groupe, des classes virtuelles, des webinaires ou des agents IA vocaux. C’est le choix par défaut en 2026.
Évitez le MCU sauf si vous avez une contrainte de compatibilité SIP/téléphonie classique. Le coût CPU et la complexité ne se justifient plus.
Parmi les SFU, le choix dépend de votre besoin :
Si vous construisez une application custom (agent IA, plateforme sur mesure) et que vous avez des développeurs WebRTC, LiveKit ou mediasoup sont de bons choix d’infrastructure. Si vous cherchez un produit de visioconférence complet, souverain, compatible Moodle, sans développement nécessaire, Vuisio est le seul SFU Rust à proposer tout cela dans un produit fini, hébergé en France.
En résumé
Le P2P fonctionne pour les appels à deux. Le MCU appartient au passé de la téléphonie. Le SFU est l’architecture du présent et du futur de la visioconférence.
Mais le SFU n’est qu’un modèle. Ce qui compte, c’est l’implémentation : le langage (Rust élimine le GC et les failles mémoire), la conception (relai RTP brut, multi-thread, files bornées) et le produit qui l’entoure (interface, modération, chiffrement, intégration LMS). Vuisio combine tout cela dans un produit complet, souverain et gratuit pour commencer.
Questions fréquentes
Quelle est la différence entre SFU, MCU et P2P ?
En P2P, chaque participant envoie ses flux directement aux autres (pas de serveur). En MCU, un serveur décode tous les flux et les fusionne en un seul. En SFU, un serveur reçoit chaque flux une fois et le redistribue sans le décoder. Le SFU est le meilleur compromis entre qualité, performance et scalabilité.
Pourquoi le P2P ne fonctionne-t-il pas au-delà de 3 participants ?
En P2P, chaque participant doit envoyer son flux à tous les autres. Avec 5 participants, chacun doit envoyer 4 flux vidéo simultanés. La bande passante montante requise explose et dépasse rapidement les capacités d'une connexion résidentielle.
Le MCU est-il encore utilisé en 2026 ?
Très peu. Le MCU (Multipoint Control Unit) est la technologie historique des systèmes de téléphonie. BigBlueButton utilise encore un MCU pour l'audio (FreeSWITCH). Mais le MCU est gourmand en CPU (il décode et réencode tous les flux) et ne passe pas à l'échelle. Les projets modernes choisissent le SFU.
Un SFU consomme-t-il beaucoup de ressources serveur ?
Beaucoup moins qu'un MCU. Le SFU ne décode pas les flux, il les relaie. Le travail se résume à recevoir un paquet et le renvoyer. En Rust (Vuisio), le relai média ne consomme que quelques pour cent du processeur, et le serveur tient 450 à 500 participants sur 6 vCPU.
Vuisio est-il un SFU ou un MCU ?
Vuisio est un SFU pur. Il relaie les paquets audio et vidéo sans jamais les décoder ni les réencoder (relai RTP brut). C'est ce qui lui permet de consommer très peu de ressources et de tourner sur du matériel modeste, y compris un Raspberry Pi.
Peut-on combiner P2P et SFU dans un même produit ?
Oui, c'est l'approche hybride utilisée par Jitsi Meet : P2P pour les appels à deux (latence minimale), SFU pour les groupes. Vuisio utilise le SFU pour tous les cas, ce qui simplifie l'architecture et le déploiement.
