Media over QUIC — MoQ — est le protocole de streaming émergent le plus discuté de 2025-2026. Les articles de blog se multiplient, les conférences s'accumulent, et les fournisseurs de CDN rivalisent pour annoncer leur prise en charge. Si vous travaillez dans le streaming en direct, on vous a probablement déjà demandé : devrait-on passer à MoQ ?
La réponse courte, pour la plupart des produits en production aujourd'hui, est non — pas encore. Mais MoQ mérite d'être compris, car les problèmes qu'il résout sont réels, et le calendrier pour qu'il soit prêt pour la production se mesure désormais en trimestres, pas en années.
Cet article explique ce qu'est réellement MoQ, où il en est en mars 2026, ce qu'il change par rapport à HLS, WebRTC et SRT — et s'il serait pertinent pour deux produits réels que nous avons déployés : WeSpeakSports (commentaire audio de fans en direct via WebRTC) et DJing Stream (audio DJ de qualité broadcast via SRT et HLS Lossless).
Ce qu'est réellement MoQ
MoQ signifie Media over QUIC. C'est un effort du groupe de travail IETF lancé en 2022, visant à définir un nouveau protocole de diffusion média construit au-dessus de QUIC (la couche de transport derrière HTTP/3).
La spécification principale du transport, draft-ietf-moq-transport, a atteint la version 17 en mars 2026. Une spécification de format de streaming (draft-ietf-moq-msf) est également en cours, accompagnée de documents complémentaires pour le packaging CMAF et la compression d'en-têtes. Aucun de ces documents n'est encore un RFC finalisé.
En son cœur, MoQ est un protocole publish/subscribe. Un éditeur envoie des objets média nommés (trames audio, trames vidéo, métadonnées) vers des relais, et les abonnés les reçoivent en s'abonnant à des pistes nommées. C'est fondamentalement différent de HLS (requête/réponse HTTP pour des segments) et de WebRTC (négociation de session pair-à-pair avec SDP/ICE).
MoQ fonctionne sur des flux et datagrammes QUIC, soit nativement, soit via WebTransport (l'API navigateur pour QUIC). Cela lui donne accès au multiplexage, à la priorisation et aux fonctionnalités de fiabilité partielle de QUIC — ce qui signifie que le protocole peut, par conception, abandonner une trame vidéo en retard plutôt que de bloquer l'ensemble du flux en attendant la retransmission.
Ce que MoQ cherche à remplacer
Comme le formule Cullen Jennings de Cisco (participant au groupe de travail MoQ), le monde du streaming est actuellement divisé en deux silos. D'un côté, des services comme Netflix et YouTube diffusent du contenu à grande échelle via des CDN basés sur HTTP, mais avec des secondes de latence. De l'autre côté, des outils de visioconférence comme Zoom et les plateformes basées sur WebRTC diffusent du contenu en quasi-temps réel, mais ne peuvent pas monter en charge de manière économique pour de larges audiences.
MoQ vise à faire le pont entre ces deux mondes avec un protocole unique capable de servir à la fois les cas d'usage temps réel et quasi-temps réel, de la contribution (ingestion) à la distribution (diffusion vers les spectateurs), avec une infrastructure de relais compatible CDN entre les deux.
Où en est MoQ aujourd'hui (mars 2026)
Soyons précis sur l'état actuel :
La spécification est proche mais pas terminée. Le document de transport en est à la version 17, avec des itérations rapides. Le document sur le format de streaming a été publié en janvier 2026. Des travaux complémentaires actifs portent sur le packaging CMAF et la compression d'en-têtes. Mais il n'y a pas encore de RFC ratifié.
Le retard Safari/WebTransport se comble. MoQ dans le navigateur dépend de WebTransport, qui nécessite HTTP/3 et QUIC. Chrome et Firefox prennent déjà en charge WebTransport. Safari était le retardataire — mais Apple a ajouté la prise en charge de WebTransport dans Safari 26.4 bêta (février 2026), et c'est un engagement officiel d'Interop 2026 de la part de WebKit. En mars 2026, cela n'a pas encore été livré dans une version stable de Safari, mais ce n'est plus une question de si — seulement de quand dans le prochain cycle de mises à jour. Pour les produits ciblant les utilisateurs iPhone et iPad via un navigateur, l'écart est presque comblé.
Des déploiements en production précoces existent mais restent limités. Nanocosmos a démontré une diffusion MoQ de bout en bout (ingestion OBS vers une audience mondiale) lors du MonteVIDEO Summer Project. Cloudflare a lancé une bêta MoQ. Red5 a annoncé la prise en charge de MoQ d'ici fin 2026. Mais il s'agit de déploiements d'early adopters, pas d'infrastructure grand public.
La communauté est honnête sur la maturité. Même Luke Curley, qui a construit l'une des premières implémentations MoQ chez Twitch (maintenant Discord) et a rédigé le document de simplification moq-lite, déclare explicitement que la spécification complète du transport MoQ « est devenue trop compliquée » avec « trop de messages, de modes optionnels et de fonctionnalités à moitié abouties ». Son document moq-lite est une réponse à cette complexité.
Les vétérans de l'industrie sont mesurés. Tsahi Levent-Levi de BlogGeek.me a prédit qu'en 2026, les développeurs se plaindraient davantage de WebRTC que de MoQ — non pas parce que MoQ est meilleur, mais parce que les utilisateurs de MoQ sont encore des early adopters qui s'attendent à des aspérités. C'est WebRTC qui est en production partout, portant le poids des attentes du monde réel.
Ce que MoQ change par rapport à HLS
HLS (HTTP Live Streaming) fonctionne en découpant le contenu média en segments, en les écrivant sur un serveur HTTP, et en faisant interroger par les lecteurs les nouvelles playlists pour obtenir de nouveaux segments. C'est un protocole mature, compatible CDN, largement déployé et bien documenté dans le RFC 8216 et la spécification HLS Authoring d'Apple. Low-Latency HLS (LL-HLS) réduit la latence à environ 2-4 secondes.
MoQ modifie le modèle de diffusion de plusieurs façons :
Du polling au push. Les lecteurs HLS demandent les segments. Les abonnés MoQ reçoivent les objets dès qu'ils sont publiés. Cela élimine la latence liée au polling.
Des segments aux objets. HLS opère sur des segments de plusieurs secondes (ou des segments partiels en LL-HLS). MoQ peut opérer au niveau de la trame. Une seule trame vidéo ou audio peut être un objet individuellement adressable et individuellement livrable.
De TCP à QUIC. HLS fonctionne sur HTTP/TCP. Quand un paquet TCP est perdu, tout ce qui suit est bloqué (blocage en tête de file). MoQ fonctionne sur QUIC, où les flux sont indépendants — un paquet perdu sur un flux ne bloque pas les autres.
Priorisation explicite. Le document de transport de MoQ définit la priorité et l'ordre de livraison au niveau du protocole. En cas de congestion, un relais peut abandonner les objets de priorité inférieure (par exemple les B-frames) plutôt que de retarder tout de manière égale.
Ingestion et distribution unifiées. Aujourd'hui, la plupart des workflows de diffusion en direct utilisent un protocole pour la contribution (RTMP, SRT, WHIP) et un autre pour la distribution (HLS, DASH). MoQ peut potentiellement servir les deux chemins avec un seul protocole, éliminant l'étape de reconditionnement au serveur d'origine.
Quand HLS reste le meilleur choix
Rien de tout cela ne signifie que HLS est obsolète. HLS reste le choix le plus solide quand :
- Quelques secondes de latence sont parfaitement acceptables
- Une large compatibilité avec les appareils est essentielle (chaque téléphone, téléviseur et décodeur lit le HLS)
- L'investissement existant en CDN et en outillage fonctionne bien
- La simplicité opérationnelle et la fiabilité éprouvée comptent plus que de réduire encore la latence
Pour la diffusion OTT standard en direct et à la demande — qui représente l'écrasante majorité du trafic de streaming — HLS n'est pas cassé, et MoQ ne résout pas un problème qui existe.
Ce que MoQ change par rapport à WebRTC
WebRTC a été conçu pour la communication pair-à-pair en temps réel : appels vidéo, partage d'écran, conversations en tête-à-tête ou en petit groupe. L'industrie l'a poussé bien au-delà de ce périmètre initial, en utilisant des architectures SFU (Selective Forwarding Unit) pour faire monter WebRTC en charge vers de plus larges audiences.
MoQ diffère de WebRTC de plusieurs manières importantes :
Architecture. WebRTC est fondamentalement un protocole pair-à-pair orienté session, même lorsqu'il est relayé par des SFU. MoQ est un protocole client-serveur publish/subscribe conçu dès le départ autour de relais et d'une distribution de type CDN.
Modèle de scalabilité. Faire monter WebRTC en charge nécessite une infrastructure SFU spécialisée et coûteuse. Les relais MoQ sont conçus pour s'intégrer à l'infrastructure CDN existante — les serveurs HTTP/3 peuvent être étendus pour gérer le trafic MoQ, c'est pourquoi des fournisseurs de CDN comme Akamai et YouTube sont activement impliqués.
Complexité. WebRTC embarque une complexité significative : négociation offre/réponse SDP, collecte de candidats ICE, serveurs STUN/TURN pour la traversée de NAT, SRTP pour le chiffrement, SCTP pour les canaux de données. L'établissement de connexion MoQ est plus simple — un handshake QUIC suivi de messages subscribe/publish.
Flexibilité des codecs. La négociation de codecs de WebRTC est étroitement couplée au protocole. MoQ est agnostique en matière de codecs au niveau du transport — le format média est géré par la couche applicative (MSF, LOC ou conteneurs personnalisés).
Dépendance au navigateur. Les deux protocoles dépendent d'API navigateur pour la diffusion web. WebRTC bénéficie d'une prise en charge universelle par les navigateurs. MoQ dépend de WebTransport, que Safari vient seulement d'ajouter en bêta (26.4, février 2026) et qui n'est pas encore disponible en version stable. Cet écart se réduit mais reste une considération pratique pour MoQ aujourd'hui.
Quand WebRTC reste le meilleur choix
WebRTC reste le meilleur choix quand :
- Une véritable communication bidirectionnelle en temps réel est nécessaire (appels vidéo, visioconférence)
- La compatibilité navigateur sur toutes les plateformes, y compris Safari/iOS, est requise
- Le cas d'usage est pair-à-pair ou en petit groupe sans besoin de distribution à l'échelle d'un CDN
- La maturité éprouvée des outils et des SDK en production compte
Ce que MoQ change par rapport à SRT
SRT (Secure Reliable Transport) excelle dans le transport de contenu média de haute qualité d'un point A à un point B sur des réseaux imprévisibles. Il fournit un chiffrement AES, une récupération de paquets perdus via ARQ (Automatic Repeat Request) et une prise en charge du débit adaptatif. SRT est largement adopté pour les workflows d'ingestion (caméras vers studios, production distante vers encodeurs cloud) mais sert également de protocole de distribution point-à-point — comme le démontre DJing Stream.
MoQ et SRT répondent à des besoins qui se chevauchent mais qui sont différents :
SRT est point-à-point ; MoQ est publish/subscribe. SRT connecte un émetteur à un récepteur. MoQ prend nativement en charge la distribution un-vers-plusieurs via des relais.
SRT garantit la livraison ; MoQ peut choisir de ne pas le faire. Le mécanisme ARQ de SRT retransmet chaque paquet perdu, ce qui garantit une livraison sans perte mais ajoute de la latence en cas de perte de paquets. MoQ peut être configuré pour une fiabilité partielle — abandonnant les objets en retard au lieu de les retransmettre — ce qui est préférable pour une diffusion en direct sensible à la latence, mais inacceptable quand chaque échantillon compte.
SRT est mature et déployé ; MoQ est émergent. SRT bénéficie d'une large prise en charge matérielle et logicielle (OBS, vMix, FFmpeg, Haivision, tous les encodeurs majeurs). MoQ n'a que des implémentations au stade précoce.
Quand SRT reste le meilleur choix
SRT est le choix le plus solide quand :
- Le cas d'usage est point-à-point (source vers encodeur, encodeur vers origine, ou distribution directe vers un lieu)
- La livraison sans perte compte plus que la latence minimale absolue
- Le workflow implique du matériel de diffusion professionnel qui parle déjà SRT
- La fidélité audio au niveau du bit est non négociable
Étude de cas : WeSpeakSports — commentaire de fans en direct via WebRTC
WeSpeakSports est une plateforme de commentaire audio de fans en direct. Les fans créent ou écoutent des commentaires audio en temps réel pendant les matchs sportifs — football, basketball, rugby, F1 et plus encore. L'application est disponible sur iPhone, iPad, Mac (Apple Silicon) et Vision Pro.
L'architecture actuelle utilise WebRTC pour le streaming audio. Un fan commentateur diffuse l'audio depuis son appareil, et les auditeurs le reçoivent en quasi-temps réel. L'audio est de qualité voix, pas de qualité musicale — l'intelligibilité et la faible latence importent bien plus que la fidélité audiophile.
MoQ serait-il pertinent pour WeSpeakSports ?
En théorie, oui — c'est un cas d'usage idéal. WeSpeakSports est une diffusion audio en direct de type 1-vers-plusieurs avec des attentes de temps réel. C'est précisément le créneau que MoQ est conçu pour combler : trop d'auditeurs pour une montée en charge efficace avec WebRTC, mais trop sensible à la latence pour HLS.
Le modèle publish/subscribe de MoQ correspond naturellement à l'architecture de WeSpeakSports : un commentateur publie une piste audio, les auditeurs s'y abonnent, et les relais CDN gèrent la distribution. Ce serait plus simple et moins coûteux à faire monter en charge que l'infrastructure SFU de WebRTC.
En pratique, pas encore — pour deux raisons concrètes :
- Safari/iOS y est presque, mais pas encore. WeSpeakSports nécessite iOS 18.0. Le public principal de l'application est sur iPhone. MoQ dans le navigateur dépend de WebTransport, qu'Apple a ajouté dans Safari 26.4 bêta mais qui n'a pas encore été livré dans une version stable. Même pour les applications iOS natives, il n'existe pas aujourd'hui de SDK MoQ prêt pour la production sur les plateformes Apple. La pile WebRTC sur iOS (via la prise en charge intégrée de WebKit par Apple et des SDK tiers matures) est éprouvée et fonctionne.
- Maturité. WeSpeakSports est un produit livré avec de vrais utilisateurs. Remplacer la couche de transport d'un protocole éprouvé par une spécification pré-1.0 serait prématuré. WebRTC gère la charge actuelle. Le coût en complexité d'une migration n'est pas justifié par la base d'utilisateurs actuelle.
Quand reconsidérer
MoQ mérite d'être évalué pour WeSpeakSports quand :
- WebTransport sera disponible dans une version stable de Safari — ce qui est désormais imminent vu la bêta de Safari 26.4 — et qu'un SDK MoQ natif mature pour iOS/macOS émergera
- La base d'utilisateurs aura atteint une échelle où les coûts de SFU WebRTC deviendront une contrainte significative
- L'infrastructure de relais MoQ sera disponible auprès d'au moins deux fournisseurs de CDN avec des engagements de SLA
- La spécification de transport MoQ aura atteint le statut de RFC
À ce moment-là, MoQ pourrait simplifier significativement l'architecture de distribution et réduire le coût par auditeur. Le modèle commentateur-vers-relais-vers-auditeurs est un cas d'usage typique de MoQ. C'est une question de timing, pas d'adéquation.
Étude de cas : DJing Stream — audio DJ de qualité broadcast via SRT
DJing Stream est une application macOS conçue pour un cas d'usage très spécifique : diffuser de l'audio de qualité broadcast depuis l'installation d'un DJ vers le système son d'un lieu, via internet, en temps réel. L'architecture privilégie la qualité audio au-dessus de tout le reste.
La pile actuelle utilise SRT pour la distribution en temps réel — transmettant de l'audio PCM stéréo 24 bits à 48 kHz (environ 2,3 Mbps) depuis le Mac du DJ vers le système son du lieu. Pour une distribution plus large vers des auditeurs distants, l'audio peut également être servi via HLS avec audio lossless. La philosophie de conception est que l'audio d'un DJ mérite la même fidélité qu'une connexion par câble physique.
MoQ serait-il pertinent pour DJing Stream ?
Non — et ce n'est pas une question de timing. MoQ est fondamentalement en désaccord avec les exigences de DJing Stream.
Voici pourquoi :
- La livraison sans perte est non négociable. DJing Stream envoie de l'audio PCM non compressé. Chaque échantillon compte. La retransmission ARQ de SRT garantit que chaque paquet arrive — elle ajoutera de la latence en cas de perte plutôt que d'abandonner de l'audio. Le modèle de fiabilité partielle de MoQ, qui est l'un de ses avantages clés pour la vidéo en direct, est exactement le mauvais compromis pour l'audio de qualité broadcast. Une trame audio abandonnée est un glitch audible sur un système son de club. Ce n'est pas acceptable.
- Le point-à-point est le cas d'usage principal. Le scénario central de DJing Stream est un DJ diffusant vers un lieu. C'est une liaison point-à-point, pas un problème de distribution. Le modèle publish/subscribe avec relais de MoQ ajoute de la complexité sans bénéfice pour cette topologie.
- Pas de nécessité de navigateur. DJing Stream est une application macOS native se connectant à du matériel de lieu. Il n'y a pas de navigateur web dans la boucle. Le retard WebTransport/Safari n'est pas pertinent, mais l'avantage principal de MoQ — la diffusion native dans le navigateur — ne l'est pas non plus.
- SRT est déjà le bon outil. SRT a été conçu exactement pour cela : un transport fiable, chiffré, à faible latence, de contenu média de haute qualité sur des réseaux imprévisibles. Il est éprouvé en production broadcast. Chaque encodeur et serveur média le prend en charge. Remplacer SRT par MoQ pour la liaison de distribution DJ-vers-lieu signifierait renoncer à la garantie de livraison sans gain significatif.
- HLS Lossless gère le volet distribution. Pour le cas d'usage secondaire de distribution vers une audience plus large (auditeurs web), HLS avec des codecs audio lossless est éprouvé et compatible avec tous les appareils. La tolérance à la latence pour les auditeurs distants est plus élevée que pour le lieu lui-même, donc le modèle à base de segments de HLS est parfaitement adéquat.
Quand reconsidérer
Honnêtement ? Probablement jamais pour la liaison centrale DJ-vers-lieu. SRT fait exactement ce dont DJing Stream a besoin, et les objectifs de conception de MoQ (distribution à grande échelle avec une perte de qualité acceptable en cas de congestion) sont opposés aux objectifs de conception de DJing Stream (livraison sans perte de chaque échantillon audio).
Le seul scénario où MoQ pourrait devenir pertinent pour DJing Stream est si le produit s'étend vers la distribution à grande échelle pour les fans avec des attentes de fidélité moindres — par exemple, diffuser une version compressée d'un set DJ à des milliers d'auditeurs simultanément. Même dans ce cas, HLS ou LL-HLS resterait probablement plus simple et plus largement compatible.
Le cadre de décision
Après avoir étudié MoQ en profondeur — les documents IETF, les commentaires de l'industrie de Broadpeak, Red5, BlogGeek.me, webrtcHacks, Meetecho et Nanocosmos — voici la règle de décision la plus simple que je puisse proposer :
Conservez votre pile actuelle quand
- Votre produit est en production aujourd'hui et votre protocole actuel fonctionne
- Vous avez besoin de la prise en charge navigateur Safari/iOS dès aujourd'hui (WebTransport est en bêta dans Safari mais pas encore en version stable)
- Quelques secondes de latence sont acceptables (→ HLS/LL-HLS)
- Vous avez besoin d'une livraison sans perte garantie (→ SRT)
- Vous avez besoin d'une véritable communication bidirectionnelle en temps réel (→ WebRTC)
Commencez à évaluer MoQ quand
- L'ultra-faible latence vers de larges audiences est au cœur de la valeur de votre produit (paris en direct, enchères, expériences synchronisées de second écran)
- Vous contrôlez l'ensemble de la chaîne, de l'ingestion à la lecture, et pouvez absorber un nouveau protocole
- Les coûts de montée en charge de WebRTC deviennent un vrai problème business
- Vous construisez un nouveau produit qui ne sera pas lancé avant fin 2026 ou 2027
- Vous pouvez accepter que la spécification puisse encore changer avant d'atteindre le statut de RFC
Surveillez MoQ de près si
- Vous exploitez une infrastructure CDN ou de relais (MoQ est conçu pour fonctionner avec les CDN HTTP/3)
- Vous développez des produits de sport en direct avec des exigences de synchronisation
- Vous souhaitez faire converger l'ingestion et la distribution sur un seul protocole
- Vous êtes frustré par la surcharge de reconditionnement entre l'ingestion RTMP/SRT et la distribution HLS
Le mot de la fin
MoQ est réel, bien conçu, et répond à de véritables limitations dans le paysage actuel des protocoles de streaming. L'ambition — un seul protocole pour le temps réel et le quasi-temps réel, de l'ingestion à la distribution, avec une prise en charge de relais à l'échelle des CDN — est convaincante.
Mais l'ambition n'est pas synonyme de maturité. La spécification n'est pas finalisée. Safari intègre WebTransport en bêta mais pas encore dans une version stable. Les déploiements en production se limitent aux early adopters. L'écosystème de SDK, d'outils et de savoir-faire opérationnel qui rend HLS, WebRTC et SRT fiables en production n'existe tout simplement pas encore pour MoQ.
Pour la plupart des produits de streaming livrés en 2026, MoQ est quelque chose à suivre — pas quelque chose à adopter. Quand il arrivera à maturité, et c'est inévitable, il a le potentiel de simplifier des architectures qui assemblent actuellement plusieurs protocoles avec des couches de reconditionnement entre eux.
D'ici là : si HLS fonctionne pour votre diffusion, gardez-le. Si WebRTC fonctionne pour vos besoins temps réel, gardez-le. Si SRT fonctionne pour vos liaisons point-à-point, gardez-le. Le meilleur protocole est celui qui est en production et qui fonctionne, pas celui qui est le plus enthousiasmant sur une diapositive de conférence.
Sources
- IETF MoQ Transport draft (v17, mars 2026) : datatracker.ietf.org/doc/draft-ietf-moq-transport
- IETF MoQ Charter : datatracker.ietf.org/group/moq/about
- moq-lite draft : ietf.org/archive/id/draft-lcurley-moq-lite-02.html
- IETF Blog — What's the deal with MoQ : ietf.org/blog/moq-overview
- BlogGeek.me — MOQ: How it will redefine realtime media : bloggeek.me/moq-redefine-realtime
- webrtcHacks — WebRTC vs. MoQ by Use Case : webrtchacks.com/webrtc-vs-moq-by-use-case
- RFC 8216 (HLS) : rfc-editor.org/rfc/rfc8216.html
- Apple HLS overview : developer.apple.com/streaming
- WebKit — Announcing Interop 2026 (engagement WebTransport) : webkit.org/blog/17818/announcing-interop-2026
- MoQ CDN — Open-source MoQ CDN relay infrastructure: moqcdn.net
- Erik Herz on LinkedIn: linkedin.com/in/erikherz