LL-HLS ou WebRTC : quelle architecture de streaming live ?

Choisir entre LL-HLS et WebRTC ne revient pas à opposer un protocole lent à un protocole rapide. Ils ne résolvent pas le même problème. LL-HLS organise la diffusion d'un flux à une audience. WebRTC crée des connexions média interactives entre participants. La bonne décision dépend donc moins d'un objectif de latence abstrait que des rôles présents dans le live : qui publie, qui regarde, qui parle et quelles actions doivent rester synchronisées.

Cette distinction évite une erreur coûteuse : imposer la même architecture au présentateur, aux invités et à tous les spectateurs. Sur un produit mêlant scène, audience et événements métier, la réponse est souvent une combinaison de plusieurs chemins spécialisés.

LL-HLS et WebRTC ne servent pas le même échange

LL-HLS : distribuer un programme à une audience

LL-HLS reste fondé sur HTTP. L'encodeur produit plusieurs qualités, le packager les découpe en fragments courts, puis un origin et un CDN les distribuent aux lecteurs. Les extensions low-latency permettent au player de commencer à recevoir un fragment avant que le segment complet soit terminé.

Cette chaîne conserve les propriétés utiles de HLS : mise en cache, adaptation de qualité, reprise après une coupure et intégration avec des infrastructures web largement maîtrisées. Elle convient bien lorsque beaucoup de personnes regardent principalement un flux descendant, sur des appareils et des réseaux variés.

La contrepartie est un décalage lié à la création, au transport et à la mise en tampon des fragments. LL-HLS ne fournit pas non plus, à lui seul, le canal retour nécessaire à une enchère, un chat ou une réaction.

WebRTC : faire participer en temps réel

WebRTC privilégie une session média continue et bidirectionnelle. Dans une architecture serveur, un SFU reçoit les pistes des participants et les relaie aux autres. La signalisation, la négociation des codecs, le contrôle de congestion ainsi que la traversée réseau via STUN ou TURN font partie du système à concevoir et à exploiter.

Ce modèle est adapté aux conversations, aux co-animateurs et aux interactions pour lesquelles entendre ou voir la réponse presque immédiatement fait partie de l'expérience. En échange, chaque participant maintient une connexion active. Le fan-out, les relais TURN et l'état des sessions rendent le dimensionnement et le diagnostic plus exigeants à mesure que l'audience grandit.

Partir des rôles et non du protocole

Avant de choisir une technologie, dessinez les échanges du produit. Un présentateur qui publie une vidéo, un invité qui monte sur scène et un spectateur qui envoie une réaction n'ont ni le même besoin média ni la même tolérance au décalage.

• Privilégiez LL-HLSlorsque l'audience consomme surtout un programme, que la distribution doit absorber des variations de trafic et que la qualité de lecture prime sur la conversation vidéo.
• Privilégiez WebRTClorsque chaque participant peut publier, que les prises de parole s'enchaînent ou que le retour audiovisuel immédiat conditionne l'usage.
• Combinez-leslorsque quelques personnes produisent le direct tandis qu'une audience plus large regarde et agit via une interface applicative.

Le budget de latence doit lui aussi être défini par action. Le retour audio d'un invité, l'affichage d'une enchère validée et la vidéo reçue par un spectateur peuvent suivre des chemins différents sans dégrader la cohérence du produit.

Une architecture hybride sépare trois plans

Le plan de contribution

Les hôtes et co-animateurs publient en WebRTC vers la couche média. Elle gère les pistes, les permissions et, si nécessaire, la composition. Ce chemin reste réservé aux personnes qui ont besoin d'interagir sur la scène.

Le plan de distribution

Le programme résultant est encodé en plusieurs qualités, packagé en LL-HLS puis servi par un origin derrière un CDN. Les spectateurs utilisent ainsi un chemin de lecture conçu pour la diffusion, sans ouvrir une session WebRTC pour chaque viewer.

Le plan métier

Les enchères, réactions, messages et changements d'état transitent par une API et un canal temps réel dédiés. Le serveur métier reste la source d'autorité : il ordonne les événements, valide les droits et renvoie un état récupérable après reconnexion. La vidéo illustre l'action, mais ne décide jamais de son résultat.

C'est le principe retenu pour la marketplace d'enchères live Blisterr : WebRTC pour les personnes sur scène, LL-HLS pour la diffusion, et un backend distinct pour les interactions du produit. La séparation permet de faire évoluer chaque chemin selon ses propres contraintes.

Arbitrer latence, coût et interaction

La latence est une chaîne

Mesurer uniquement le protocole masque souvent le vrai goulot. Capture, encodage, transport, packaging, cache, buffer du player et rendu contribuent tous au délai perçu. Pour les événements métier s'ajoutent la validation serveur et la mise à jour de l'interface. Il faut donc tracer un budget de bout en bout pour chaque parcours critique.

Le coût suit la topologie

Côté LL-HLS, les postes structurants sont l'encodage, le stockage éventuel, les requêtes à l'origin et la distribution CDN. Côté WebRTC, ce sont surtout les sessions simultanées, le fan-out des pistes, le trafic relayé par TURN et la capacité de la couche média. Une estimation utile part d'un profil de live — éditeurs, spectateurs, qualités et durée — puis rend chaque hypothèse explicite.

L'interaction doit survivre au média

Un changement de qualité, une reconnexion ou un décalage de lecture ne doit pas dupliquer une action ni faire revenir l'interface à un état ancien. Identifiants idempotents, horodatage serveur et reprise depuis un curseur d'événements rendent le plan métier indépendant des aléas du player.

Exploiter le live : observer chaque frontière

Un écran noir côté utilisateur peut venir de la capture, de l'authentification, de l'encodeur, du packager, du CDN ou du player. Une plateforme exploitable doit relier ces signaux avec un identifiant de session commun.

• Contribution : état de publication, pertes réseau, changements de qualité, reconnexions et usage des relais.
• Traitement : santé des encodeurs, disponibilité des renditions, progression des manifests et erreurs de packaging.
• Distribution : erreurs origin et CDN, comportement du cache, débit de sortie et disponibilité des fragments.
• Lecture : temps de démarrage, mises en tampon, changements de qualité, erreurs fatales et abandon.
• Métier : connexions au canal temps réel, retards de traitement, événements refusés, reprises et désynchronisations.

Des tests synthétiques complètent les métriques réelles : publier un flux, ouvrir un lecteur depuis plusieurs réseaux, déclencher une interaction et vérifier que le système récupère après une coupure. Les alertes doivent porter sur l'expérience complète, pas seulement sur des serveurs encore actifs.

Les erreurs d'architecture les plus fréquentes

• Mettre toute l'audience en WebRTC uniquement parce que la latence annoncée est plus basse, sans chiffrer les connexions et le trafic relayé.
• Faire dépendre l'état métier du player, puis découvrir qu'une mise en tampon suffit à désynchroniser l'interface.
• Choisir une latence unique pour tout le produit au lieu de définir les besoins du présentateur, des invités et des spectateurs.
• Oublier les modes dégradés : reprise de publication, retour à une qualité sûre, lecture différée ou état métier restauré.
• Tester uniquement sur un poste de développement sans couvrir les appareils, navigateurs et réseaux réellement visés.
• Laisser vivre les ressources après le directsans politique explicite d'arrêt, d'archivage et de suppression.

Checklist avant de figer l'architecture

• Cartographier les rôles et les flux montants ou descendants.
• Définir la latence acceptable pour chaque interaction critique.
• Décrire la forme de l'audience et ses variations attendues.
• Lister les appareils, navigateurs et conditions réseau à couvrir.
• Choisir la source d'autorité et la stratégie de reconnexion.
• Prévoir permissions, jetons d'accès, modération et révocation.
• Décider si le direct doit être enregistré, rejoué ou découpé.
• Modéliser les coûts par composant à partir des hypothèses produit.
• Définir métriques, traces, alertes et tests synthétiques.
• Tester la charge et les pannes avant le premier événement public.

La meilleure architecture est celle que le produit peut exploiter

LL-HLS et WebRTC sont des briques, pas une stratégie complète. Le bon système réserve la connexion interactive aux rôles qui en ont besoin, distribue efficacement le programme aux spectateurs et garde les règles métier dans un plan indépendant et observable.

Le protocole média ne décide pas non plus de l'architecture du client : notre guide Flutter ou natif iOS/Android traite ce choix séparément.

Black Tide conçoit ce type de systèmes dans ses missions d'architecture cloud et produit. Si vous devez choisir une stack, reprendre un live existant ou préparer une montée en charge, parlons de votre architecture.