Architecture vidéo : comment concevoir une infrastructure WebRTC professionnelle

Le schéma minimal d'une architecture vidéo

Navigateurs / mobile / postes agents
    ↕ HTTPS / WSS
Signalisation + authentification
    ↕ ICE / STUN / TURN
SFU (routage média temps réel)
    ↕ API / webhooks / règles métier
Applications métier (CRM, portail, SSO, ticketing)
    ↕ stockage / logs / monitoring
Enregistrements, audit, métriques

Une architecture simple en apparence devient vite une infrastructure dès qu'il faut gérer des réseaux d'entreprise, plusieurs participants, des contraintes RGPD, du SSO et des parcours métier.

Les 6 briques à maîtriser

1. Les clients vidéo

Le client navigateur ou mobile capture la caméra, le micro, le partage d'écran, encode les flux et les restitue. Avec WebRTC, l'utilisateur rejoint une session sans logiciel lourd, mais cela ne dispense pas de concevoir le reste de la chaîne.

2. La signalisation

La signalisation orchestre la session : création de salle, échange SDP, présence, modération, permissions. Elle passe en général par HTTPS/WSS. Elle ne transporte pas la vidéo elle-même, mais sans elle, aucun appel ne démarre proprement.

3. La connectivité ICE / STUN / TURN

La négociation ICE choisit le meilleur chemin réseau. STUN découvre l'adresse publique ; TURN relaie les flux quand le réseau bloque le direct. En production, c'est souvent le TURN qui fait la différence entre une démo qui marche et un service qui tient derrière des pare-feu d'entreprise.

Voir le détail réseau sur STUN et TURN.

4. Le SFU

Le SFU (Selective Forwarding Unit) route les flux dans les sessions multi-participants. Il évite à chaque poste d'envoyer un flux vers tous les autres, ce qui améliore la tenue en charge et la maîtrise CPU côté client. Pour des usages métier sérieux, c'est généralement la brique centrale de l'architecture.

Approfondir : SFU WebRTC.

5. L'API vidéo et la logique applicative

L'API vidéo permet de créer des sessions, émettre des tokens, recevoir des webhooks, piloter des droits, brancher le parcours métier et automatiser les actions en amont ou en aval de la session.

Voir aussi API vidéo.

6. Le stockage, les logs et l'observabilité

Les enregistrements, traces d'audit, journaux techniques et métriques doivent être pensés dès la conception. C'est là que se jouent le support, le diagnostic, les SLA et une partie des enjeux de conformité.

À quoi ressemble le flux en pratique ?

1. L'utilisateur rejoint une salle depuis un navigateur ou un portail métier.
2. La signalisation authentifie, crée la session et échange les métadonnées.
3. ICE tente le meilleur chemin réseau possible.
4. Si nécessaire, le TURN relaie le trafic.
5. Le SFU distribue les flux audio/vidéo aux autres participants.
6. L'API alimente le SI : CRM, ticket, prise de rendez-vous, supervision, analytics.

Cette chaîne explique pourquoi une architecture vidéo ne se résume pas à "activer WebRTC".

Architecture 1:1, multi-participants ou live : ce qui change

Une même plateforme vidéo peut couvrir ces usages, à condition de ne pas répliquer une stack différente pour chaque besoin.

Quand faut-il une architecture hybride WebRTC + CDN ?

Pour les très grands publics unidirectionnels :

• WebRTC pour le plateau interactif (animateur, modérateurs, Q&R) ;
• HLS/DASH pour la diffusion passive vers des milliers de spectateurs.

Cette approche combine faible latence côté interaction et capacité de diffusion côté audience.

Où se joue vraiment la souveraineté ?

La souveraineté ne dépend pas seulement du datacenter qui héberge la page web. Elle dépend de la résidence réelle des briques sensibles : relais média, logs, stockage, administration, sous-traitants, sauvegardes.

→ Hébergement France, cloud souverain, RGPD.

Les 5 erreurs fréquentes en architecture vidéo

1. Sous-estimer TURN : sans relais correctement exposé, les réseaux corporate cassent les appels.
2. Confondre signalisation et média : le WebSocket ne remplace ni SFU ni TURN.
3. Penser uniquement UX : sans métriques ICE, packet loss et bitrate, l'exploitation devient aveugle.
4. Oublier la localisation des logs et enregistrements : risque conformité immédiat.
5. Concevoir par produit et non par plateforme : multiplication des stacks, des coûts et de la dette ops.

Scalabilité et haute disponibilité : les points à prévoir

• SFU horizontal : cluster derrière load balancer ;
• TURN redondé : plusieurs zones géographiques ;
• Signalisation stateless : scaling Kubernetes ;
• Observabilité : métriques ICE, bitrate, packet loss, latence ;
• Runbooks : procédures incident, tests réseau, capacité de diagnostic.

→ Scalabilité WebRTC.

Open source, propriétaire ou sur-mesure ?

Le bon choix dépend moins d'un dogme que du niveau de contrôle attendu sur l'hébergement, l'intégration SI, la marque et l'exploitation. Voir open source pour l'approche Leagora.

Comment une DSI peut cadrer son architecture

Avant de choisir un éditeur, un intégrateur ou une stack, cinq questions structurent bien le cadrage :

1. Quel niveau de latence et d'interactivité est attendu ?
2. Quels environnements réseau doivent être supportés : VPN, proxy, pare-feu, 4G, Wi-Fi invité ?
3. Où doivent résider SFU, TURN, logs, enregistrements ?
4. Quelle profondeur d'intégration faut-il : SSO, CRM, ticketing, webhooks, multi-tenant ?
5. Quelle équipe exploitera la plateforme : DSI interne, infogérance, éditeur, mixte ?

Qui consomme cette architecture chez Leagora ?

Les produits métier s'appuient sur ce socle :

Le détail fonctionnel de chaque usage reste sur les sites dédiés ; la présente page reste centrée sur la conception technique.

Comment Leagora conçoit une architecture vidéo

Leagora travaille en général à partir d'un atelier d'architecture avec la DSI ou l'équipe produit : cartographie des composants, choix de localisation, stratégie SSO, guide pare-feu, dimensionnement SFU/TURN, métriques de supervision et trajectoire de déploiement. Pour cadrer un besoin : contact.