Architecture vidéo temps réel : les composants d'une infrastructure WebRTC

Réponse courte

Une architecture vidéo temps réel professionnelle combine signalisation (WebSocket), ICE/STUN/TURN (connectivité réseau), SFU (distribution multi-participants), API vidéo (orchestration), authentification (SSO/LDAP) et stockage (enregistrements). Chaque composant a un rôle distinct ; la souveraineté se joue sur la localisation de chaque brique.

Les 6 couches d'une plateforme vidéo

Client navigateur
    ↕ Signalisation (HTTPS/WSS)
Serveur de signalisation
    ↕ ICE (STUN + TURN)
SFU (Selective Forwarding Unit)
    ↕ API REST / Webhooks
Couche applicative (CRM, SSO, ticketing)
    ↕ Stockage chiffré
Enregistrements / logs / métriques

1. Client navigateur

WebRTC natif : capture, encodage adaptatif, décodage, rendu. Pas d'installation pour le participant.

2. Signalisation

Canal WebSocket sécurisé (WSS) pour l'échange SDP (Session Description Protocol). Ne transporte pas la vidéo : orchestre la session.

3. ICE / STUN / TURN

Traversée NAT et pare-feu. Voir STUN et TURN pour le détail réseau.

4. SFU

Relais sélectif pour les réunions multi-participants. Voir SFU WebRTC.

5. API vidéo

Création de salles, tokens, webhooks, métriques. Voir API vidéo.

6. Couche applicative

SSO, annuaire, intégration SI : voir intégration vidéo.

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 et reach massif.

Où se situe la souveraineté ?

Composant	Données sensibles	Localisation critique
Signalisation	Métadonnées session	Oui
SFU	Flux vidéo en transit	Oui
TURN	Flux vidéo relayés	Oui
Enregistrements	Données personnelles	Oui
API / logs	Identifiants, audit	Oui

→ Hébergement France, cloud souverain, RGPD.

Scalabilité et haute disponibilité

SFU horizontal : cluster derrière load balancer ;
TURN redondé : plusieurs zones géographiques ;
Signalisation stateless : scaling Kubernetes ;
Monitoring : métriques ICE, bitrate, packet loss, latence.

→ Scalabilité WebRTC.

Stack open source vs propriétaire

	Open source (mediasoup, Jitsi, Janus)	SaaS propriétaire
Audit code	Possible	Non
Hébergement	Libre (France, on-prem)	Imposé par l'éditeur
Personnalisation	Totale	Limitée
Responsabilité ops	Client ou infogéreur	Éditeur

Voir open source pour l'approche Leagora.

Cas d'usage : qui consomme l'infrastructure ?

Leagora.io documente l'architecture. Les produits métier consomment cette infrastructure :

Produit	Architecture consommée
assistance-video.fr	WebRTC 1:1 + TURN + API
meeting.leagora.io	SFU + TURN + salles persistantes
mes-rdv.fr	API vidéo + liens auto
live.gniarkgniark.fr	WebRTC + CDN hybride

Comment Leagora conçoit ses architectures ?

Atelier technique avec la DSI : schéma composants, localisation, guide pare-feu, dimensionnement SFU/TURN. Contact.

FAQ

Quelle est la différence entre signalisation et SFU ?

La signalisation échange les métadonnées (qui rejoint, quels flux). Le SFU transporte les flux vidéo eux-mêmes en réunion multi-participants.

Faut-il un composant par usage (assistance, réunion, live) ?

Non : une plateforme vidéo unifiée peut servir plusieurs usages via l'API, avec des configurations différentes par tenant.

Comment tester l'architecture avant production ?

Pilote réseau : postes pare-feu strict, 4G, Wi-Fi client, réunion 15+ participants, mesure latence.

L'architecture est-elle compatible on-premise ?

Oui : tous les composants (signalisation, SFU, TURN, API) peuvent tourner en datacenter client.

Peut-on intégrer l'architecture dans un portail existant ?

Oui : via API vidéo, iframe ou SDK. Voir intégration vidéo.

À retenir

Architecture pro = 6 couches : client, signalisation, ICE, SFU, API, applicatif.
Souveraineté = localisation de chaque composant, pas seulement la page web.
Leagora.io = hub architecture ; produits métier sur les sites satellites.