SFU WebRTC en Rust : pourquoi c'est l'avenir du temps réel

La plupart des serveurs de visioconférence sont écrits en Java, en Go ou en C/C++. Chacun de ces langages fait un compromis : Java et Go ont un garbage collector qui peut suspendre l’exécution au mauvais moment ; C et C++ offrent la performance mais au prix de failles mémoire récurrentes. Rust est le premier langage à éliminer les deux problèmes en même temps. Et pour un SFU WebRTC, c’est un changement de paradigme.

Qu’est-ce qu’un SFU et pourquoi le langage compte ?

Un SFU (Selective Forwarding Unit) est le cœur d’un système de visioconférence moderne. Il reçoit les flux audio et vidéo de chaque participant et les redistribue aux autres, sans les décoder ni les réencoder. C’est un routeur de paquets spécialisé pour le temps réel.

Le travail d’un SFU est simple en apparence (recevoir, décider, envoyer) mais extrêmement exigeant en pratique. Chaque paquet audio doit être relayé en quelques millisecondes. Un retard de 20 ms est perceptible. Un gel de 100 ms est inacceptable. Et le serveur doit maintenir cette performance de façon stable, que la réunion dure 5 minutes ou 5 heures, avec 10 ou 500 participants.

C’est dans ces contraintes que le choix du langage devient déterminant.

Le paysage des SFU en 2026

SFU	Langage	Bibliothèque WebRTC	Modèle	Éditeur
Jitsi Videobridge (JVB)	Java	Implémentation propre	SFU	8x8 (États-Unis)
Kurento	C/C++	GStreamer / libnice	SFU + MCU	Communauté (fin de vie active)
mediasoup	C++ (worker) + Node.js (signalisation)	libwebrtc	SFU	Communauté open source
Janus	C	libnice, libsrtp	SFU + plugins	Meetecho (Italie)
LiveKit	Go	Pion	SFU	LiveKit Inc. (États-Unis)
Vuisio	Rust	str0m	SFU	Geezot (France)

Chaque génération de SFU a été dictée par le langage dominant de son époque. Kurento et Janus sont nés à l’ère du C/C++. JVB a été écrit en Java car Jitsi est issu du monde des clients SIP Java. LiveKit est apparu avec la montée de Go et de Pion. Vuisio marque l’entrée de Rust dans le temps réel WebRTC.

Pourquoi Rust change la donne pour le temps réel

Le garbage collector est l’ennemi du temps réel

Java, Go et JavaScript utilisent tous un garbage collector. Le GC libère automatiquement la mémoire inutilisée, ce qui simplifie la vie du développeur. Mais il le fait en suspendant périodiquement l’exécution du programme.

En Go, les pauses GC sont courtes en moyenne (sub-milliseconde dans les cas simples) mais peuvent atteindre 10 à 50 ms sous charge, surtout avec de grands heaps ou de longues listes chaînées (golang/go #37116). Un développeur Go expérimenté témoigne : « GOGC=100 par défaut causait des pics de latence de 200 ms en charge » (DEV Community). Go force par ailleurs un cycle GC toutes les 2 minutes même en l’absence d’allocations (golang/go #37116).

OpenAI, qui utilise Go pour son infrastructure WebRTC temps réel (ChatGPT voice mode), a dû recourir à des « pre-allocated buffers and minimal copying to avoid garbage collection » pour maintenir des latences acceptables (OpenAI). C’est un contournement, pas une solution : le GC reste présent, il faut simplement éviter de le déclencher.

En Java (JVB), la situation est pire : les pauses GC du JVM peuvent atteindre des centaines de millisecondes avec de grands heaps, ce qui est incompatible avec le relai audio en temps réel.

Rust n’a pas de garbage collector. La mémoire est gérée par le système de propriété (ownership) vérifié à la compilation. Il n’y a aucune pause, aucun pic de latence imprévisible, aucune dégradation progressive. Le temps de traitement d’un paquet est le même au bout de 5 minutes et au bout de 5 heures.

La sécurité mémoire sans le coût du GC

C et C++ n’ont pas de GC non plus, mais ils ouvrent la porte aux failles mémoire : buffer overflows, use-after-free, data races. Pour un SFU qui traite des flux média en continu, ces failles sont un cauchemar de sécurité. V100.ai (infrastructure vidéo IA en Rust) résume : « Buffer overflows in media pipelines are a security nightmare » (V100.ai).

Rust élimine ces catégories de bugs à la compilation grâce à son système de types et son borrow checker. Un SFU Rust ne peut pas avoir de buffer overflow, de use-after-free ni de data race, parce que le compilateur refuse de produire un binaire qui en contient. C’est une garantie structurelle, pas un objectif de qualité.

mediasoup (C++ worker + Node.js signalisation) illustre le compromis inverse : les performances du worker C++ sont excellentes, mais la couche de signalisation Node.js introduit les caractéristiques du runtime V8 (V100.ai).

La prévisibilité sous charge

Un SFU doit tenir une charge soutenue sans dégradation. C’est là que Rust brille le plus.

La documentation de Vuisio détaille les techniques employées (docs.vuis.io) : architecture multi-thread avec un socket UDP par thread, répartition des participants par hachage de (salle, client), files inter-threads bornées avec un budget de temps pour éviter qu’une salle chargée ne bloque les autres, appels système groupés pour l’envoi et la réception réseau. Un travail de profilage mémoire (perf, bytehound) a permis d’éliminer toute croissance mémoire sous charge soutenue.

Résultat : le relai média ne consomme que « quelques pour cent du processeur » (docs.vuis.io), et l’empreinte mémoire reste stable. Sur un serveur à 6 vCPU, Vuisio a tenu 450 à 500 participants simultanés en test de charge.

str0m : la bibliothèque WebRTC pensée pour Rust

Vuisio est construit sur str0m, une bibliothèque WebRTC open source en Rust développée par Martin Algesten (Lookback) (GitHub str0m). str0m adopte une architecture Sans I/O (Sans Input/Output) : la bibliothèque ne fait aucun appel réseau elle-même. C’est l’application (le SFU de Vuisio) qui contrôle les sockets, les threads et le scheduling.

Cette conception a plusieurs avantages pour un SFU :

Contrôle total sur la concurrence. L’application décide combien de threads utiliser, comment répartir les connexions, et quand envoyer les paquets. str0m ne crée aucun thread, aucune tâche async, aucun lock interne (GitHub str0m). C’est ce qui permet à Vuisio d’implémenter son modèle un-socket-par-thread avec répartition par hachage.

Intégration avec n’importe quel runtime. str0m est entièrement synchrone et s’intègre avec Tokio, async-std, ou un event loop maison. Pas de conflit entre le runtime de la bibliothèque et celui de l’application.

Résilience. Si une session WebRTC rencontre un bug dans str0m, l’instance Rtc peut être jetée via catch_unwind sans risque de poisonner des locks ou de corrompre d’autres sessions (GitHub str0m). Puisqu’il n’y a pas de threads internes, le cleanup est propre.

Le même code pour les tests. Le harnais de test de charge de Vuisio utilise str0m pour ses bots de rejeu : ils sont indiscernables de vrais clients au niveau réseau (DTLS-SRTP, ICE, SCTP, RTP) (docs.vuis.io). C’est un avantage méthodologique majeur par rapport aux SFU qui testent avec des outils tiers.

Le mouvement Rust dans les infrastructures critiques

Vuisio n’est pas un cas isolé. En 2026, Rust s’impose dans les infrastructures où la performance et la sécurité ne sont pas négociables :

Le noyau Linux intègre du code Rust depuis la version 6.1 pour les nouveaux drivers. Android utilise Rust pour les composants système critiques. Cloudflare a réécrit son proxy HTTP en Rust (Pingora). AWS utilise Rust pour Firecracker (virtualisation serverless). Et dans le WebRTC spécifiquement, V100.ai construit 20 microservices en Rust avec un traitement serveur à 0,01 ms et 220 000 requêtes par seconde (V100.ai / DEV Community).

La tendance est claire : pour les systèmes temps réel, réseau et sécurité, Rust devient le choix par défaut des nouveaux projets.

Ce que cela signifie concrètement

Pour un administrateur système, un SFU Rust signifie moins de RAM, moins de CPU, et une stabilité prévisible sous charge. Le serveur ne se dégrade pas progressivement parce qu’un GC accumule de la pression mémoire.

Pour un responsable sécurité, un SFU Rust signifie une catégorie entière de vulnérabilités éliminées à la compilation (buffer overflow, use-after-free, data races). La surface d’attaque est structurellement réduite.

Pour un décideur, un SFU Rust signifie des coûts d’infrastructure divisés (un Raspberry Pi peut suffire pour 10 utilisateurs), une maintenance réduite (moins de composants, mises à jour atomiques) et une souveraineté renforcée (Vuisio est français, le code est auditable).

En résumé

Le choix du langage d’un SFU n’est pas un détail d’implémentation. C’est une décision architecturale qui détermine la latence, la sécurité, la consommation de ressources et la stabilité en production. Java et Go font un compromis avec le garbage collector. C et C++ font un compromis avec la sécurité mémoire. Rust est le premier langage à ne faire ni l’un ni l’autre.

Vuisio est le premier produit de visioconférence complet construit sur un SFU Rust. Si vous voulez voir ce que ça change en pratique, testez-le gratuitement.