Architecture du mesh WebRTC — comment on gère N participants sans SFU

Mesh WebRTC vs SFU — le choix de Nodyx

Pour les non-initiés, il y a deux grandes architectures pour la VoIP multi-participants.

Mesh (notre choix)

Chaque participant est connecté à chaque autre. Dans un salon à 5 :

A ←──── WebRTC P2P chiffré ────→ B
A ←────────────────────────────→ C
A ←────────────────────────────→ D
B ←────────────────────────────→ C
B ←────────────────────────────→ D
C ←────────────────────────────→ D

N participants → N*(N-1)/2 connexions

SFU — Selective Forwarding Unit

Chaque participant envoie son flux à un serveur central qui le redistribue. Meilleure scalabilité, mais le serveur voit les flux audio/vidéo.

Pourquoi mesh ?

Critère	Mesh	SFU
Confidentialité	✅ Serveur ne voit rien	⚠️ Serveur voit tout
Scalabilité	⚠️ Limite ~10 pairs	✅ Illimitée
Complexité deploy	✅ Aucun service SFU	❌ Mediasoup/Janus/Livekit
Usage Nodyx	✅ 2-10 personnes	Inutile pour notre cible

La limite en pratique

Au-delà de 8-10 participants, la charge CPU côté client augmente (encodage × N connexions). C'est acceptable pour des salons de discussion quotidiens.

Pour les très grandes instances : un SFU optionnel pourrait être ajouté. Mais ce n'est pas dans la roadmap v1 — les communautés Nodyx ont des salons à 2-10 personnes.

La limite CPU client est réelle mais honnêtement pour des salons de discussion quotidiens on ne dépasse jamais 6-7 simultanés.

Le mesh est le bon compromis. La confidentialité ne doit pas être optionnelle.

J'apprécie la transparence sur les limitations. C'est rare de voir une doc technique qui dit clairement "ça ne scale pas au-delà de X".

C'est le signe d'une architecture honnête plutôt que d'un over-engineering pour impressionner.