Le streaming en direct a longtemps été confronté à un problème structurel : les protocoles optimisés pour une faible latence, comme WebRTC, ne passent pas efficacement à l’échelle pour de larges audiences, tandis que les protocoles conçus pour une diffusion à l’échelle des CDN, comme HLS et DASH, imposent un seuil minimal en latence qui les rend inadaptés aux cas d’usage sensibles au facteur temps. Media over QUIC (MoQ) est une initiative prometteuse visant à répondre à ces deux contraintes au sein d’un protocole unique et, en 2026, il passe du stade de la standardisation à celui du déploiement commercial.
L’émergence rapide de MoQ
L’industrie du streaming en direct se heurte à la même limitation fondamentale depuis plus d’une décennie.
Les protocoles basés sur http – HLS, DASH – et leurs variantes à faible latence, ont fait leurs preuves en matière de scalabilité et de maturité opérationnelle. Ils transportent aujourd’hui la grande majorité du trafic de streaming sur Internet. Ils fonctionnent de manière fiable à toute échelle, s’intègrent naturellement aux infrastructures CDN et bénéficient de décennies d’outillage et d’expérience opérationnelle.
Leur modèle basé sur les segments impose néanmoins un seuil minimal de latence que LL-HLS et LL-DASH ont progressivement réduit, atteignant typiquement entre 2 et 6 secondes dans les déploiements réels.
Pour la catégorie croissante de cas d’usage où une latence inférieure à la seconde est essentielle, sports en direct, événements interactifs, paris en direct, cet écart demeure une contrainte réelle.
WebRTC a résolu le problème de la latence mais en a créé un autre. Chaque spectateur nécessite une session dédiée sur une Selective Forwarding Unit (SFU). Lorsque le nombres spectateurs simultanés se compte en milliers, cette architecture devient coûteuse et complexe à opérer. WebRTC a été conçu pour la visioconférence, pas pour le streaming à grande échelle.
Media over QUIC adopte une approche totalement différente. Au lieu de segments, MoQ traite les médias comme un flux continu d’objets individuellement adressables, un par frame vidéo, un par chunk audio. Plutôt que de requêtes HTTP de type pull, il utilise un modèle publish/subscribe dans lequel les relais intermédiaires souscrivent au contenu une seule fois puis le poussent à des millions d’abonnés.
Cette approche est structurellement différente de WebRTC, où chaque spectateur requiert une session dédiée, et de HLS/DASH, où chaque requête de segment remonte indépendamment la chaîne CDN. Le résultat est une architecture capable de fournir une latence de bout en bout inférieure à la seconde à l’échelle d’un CDN.
Ce protocole repose sur le protocole de transport QUIC, déjà utilisé par HTTP/3, ce qui lui confère : un support natif dans les navigateurs via WebTransport[1], le multiplexage des flux sans head-of-line blocking et une gestion intelligente des pertes de paquets sans recourir aux retransmissions TCP.
Du draft IETF au standard de l’industrie
MoQ est développé à l’IETF par le groupe de travail Media over QUIC. La spécification centrale de Media over QUIC Transport (MOQT), draft-ietf-moq-transportest en est à la révision 18 en mai 2026, et le groupe de travail vise un Working Group Last Call dans les mois à venir, dernière étape formelle avant la publication en tant que RFC.
La spécification MOQT est maintenant stabilisée. Le modèle de données (tracks, groups, objects), les messages de contrôle publication/subscription (SUBSCRIBE, PUBLISH, FETCH), ainsi que les liaisons avec QUIC et WebTransport ont convergé. Ce qui reste en développement actif concerne des fonctionnalités avancées : mécanismes de changement dynamique de track, sélection de contenu par filtres et fill-fetch pour la reprise en cours de lecture. Ces fonctionnalités sont actuellement affinées grâce à un programme rigoureux de tests d’interopérabilité.
En parallèle du transport MOQT, le groupe de travail a également adopté plusieurs spécifications complémentaires :
- Le MOQT Streaming Format (MSF), qui définit la manière dont la vidéo et l’audio sont empaquetés sous forme d’objets MoQ en utilisant le format Low Overhead Container (LOC) pour une encapsulation efficace des frames. MSF décrit également comment les pistes média et événementielles sont annoncées dans un « catalog » JSON, jouant un rôle similaire à celui d’un manifeste DASH ou d’une playlist HLS.
- Sa variante compatible CMAF (CMSF) destinée aux opérateurs exploitant déjà des workflows CMAF.
Pour les opérateurs exploitant aujourd’hui des workflows CMAF, le format CMSF fournit un chemin de migration bien défini : les mêmes fragments fMP4 peuvent être empaquetés comme objets MoQ, réutilisant l’infrastructure d’encodage existante tout en bénéficiant des avantages de la distribution avec MoQ, comme l’a montré Ateme lors du NAB 2026.
Un écosystème qui a progressé plus vite que la RFC
L’industrie n’a pas attendu la publication de la RFC. Lors du Mile High Video 2026 à Denver, MoQ a dominé le programme technique. Les sujets abordés allaient des stratégies d’adaptation ABR pour MoQ aux watch parties de sport en direct, en passant par la lecture VOD synchronisée et les timelines d’événements générées par IA. Le volume de présentations consacrées à MoQ en une seule édition est en lui-même révélateur : MoQ est désormais au cœur des préoccupations techniques du secteur.
Au NAB Show 2026 à Las Vegas, furent exposées, pour la première fois, des démonstrations concrètes et interopérables de MoQ par une douzaine de fournisseurs. Ateme y a démontré :
- un streaming MoQ en direct à faible latence protégé par DRM, en partenariat avec EZDRM ;
- la capacité d’atteindre une latence inférieure à la seconde tout en maintenant une haute qualité vidéo, combinaison qui imposait historiquement un compromis.
Les ingénieurs d’Ateme ont également contribué directement à l’écosystème open source en apportant des contributions essentielles au support de MoQ dans Shaka Player, le lecteur JavaScript open source de référence. Celui-ci a été testé avec les flux en direct issus de l’encodeur TITAN d’Ateme via Cloudflare et via des relais MoQ auto-hébergés.
Démonstration de latence inférieure à la seconde par Ateme au NAB 2026
Des signaux de déploiement commercial étaient déjà perceptibles. Cloudflare a déployé une infrastructure de relais MoQ sur l’ensemble de son réseau edge, dans plus de 330 villes, reposant sur son implémentation open source moq-rs. Nanocosmos a lancé MoQ en production lors de l’IBC 2025 et a fait état de déploiements précurseurs atteignant plusieurs centaines de milliers de spectateurs simultanés. Oracle Video @ Edge est arrivé sur le marché en tant que fabric de relais MOQ pour les workflows média d’entreprise. Red5 a lancé un service managé de relais MoQ en partenariat avec CacheFly. Ensemble, ces déploiements marquent la transition d’une phase d’expérimentation protocolaire vers un phase de mise en place d’une infrastructure commerciale.
En mai 2026, Ateme s’est associé à Big Blue Marble dans le cadre d’un Proof of Concept (PoC) visant à évaluer MoQ. Ce PoC a pour objectif de tester MoQ dans un environnement de sport en direct afin d’évaluer ses performances, sa montée en charge et sa maturité opérationnelle pour les futurs événements en direct.
Le consortium OpenMOQ : coordonner l’écosystème
Avec de nombreuses organisations avançant simultanément, le risque de fragmentation est réel. C’est précisément le problème qu’OpenMOQ veut résoudre.
Fondé en septembre 2025, OpenMOQ est un consortium industriel, dont Ateme est membre, centré sur l’interopérabilité, le développement d’outils partagés et la coordination de l’adoption de MoQ au sein de l’écosystème.
Il ne s’agit pas d’un organisme de normalisation, l’IETF demeure responsable des spécifications, mais d’une couche de coordination garantissant que les implémentations des drafts IETF soient interopérables en production.
La portée pratique d’OpenMOQ est de changer la dynamique pour les opérateurs évaluant MoQ. Lorsque plusieurs CDN, fournisseurs d’encodeurs et éditeurs de SDK player coordonnent leurs efforts sur l’interopérabilité, le risque de dépendre de l’interprétation d’un seul fournisseur diminue considérablement.
Ce que MoQ change pour les opérateurs… et ce qu’il ne change pas
MoQ ne remplace pas intégralement les infrastructures existantes. HLS et DASH continueront à transporter l’essentiel du trafic de streaming pendant de nombreuses années et demeurent le choix approprié pour les contenus qui ne requièrent pas une très basse latence.
Les cas d’usage pour lesquels MoQ change la donne sont ceux où une latence inférieure à la seconde est déterminante : le sport en direct, les paris sportifs, les événements interactifs et tout scénario où les spectateurs doivent vivre le même moment simultanément.
Dans ces contextes, MoQ apporte quelque chose de réellement nouveau : la possibilité d’obtenir une latence comparable à celle de WebRTC avec une montée en charge comparable à celle d’un CDN, sans surcharge opérationnelle.
Bien que cet article se concentre principalement sur les aspects B2C et la distribution secondaire, il convient également de souligner que MoQ constitue un candidat particulièrement intéressant pour la distribution primaire. MoQ permettrait à un diffuseur de publier une seule fois dans le réseau de relais et de permettre aux affiliés, distributeurs régionaux et partenaires de plateforme de s’abonner directement via MOQT.
Ateme a participé à la démonstration Oracle Video @ Edge au NAB 2026, illustrant précisément ce scénario. Pour la distribution primaire, MoQ facilite considérablement la montée en charge lorsque le nombre d’affiliés augmente. Le modèle publication/abonnement de MoQ signifie que le diffuseur publie une seule fois ; le réseau de relais prend en charge la distribution.
Ce que le standard doit encore adresser
Plusieurs lacunes méritent d’être signalées pour toute personne prenant aujourd’hui des décisions d’architecture.
La monétisation et l’insertion publicitaire ne sont que partiellement spécifiées dans MSF.
La prise en charge de l’insertion publicitaire dans MoQ reste partielle. La chronologie d’événements MSF (MSF Event Timeline) peut déjà transporter des points de signalisation SCTE-35 pour l’insertion publicitaire côté client. Une extension est à l’étude afin de permettre une insertion publicitaire pilotée côté serveur.
Au-delà de cela, le tableau reste incomplet : l’assemblage publicitaire côté serveur (server-side ad stitching) n’est pas normalisé, et MoQ ne dispose pas encore d’un équivalent aux mécanismes de publicités interstitiels définis dans HLS ou dans la sixième édition de DASH.
La prise en charge de la VOD demeure limitée dans la spécification principale actuelle.
Le groupe de travail a reconnu que les fonctionnalités complètes de la vidéo à la demande, lecture basée sur des plages (range-based playback), lecture accélérée (trick play), recherche (seek), nécessitent des mécanismes qui ne sont pas encore formellement spécifiés.
Le mécanisme Fill Fetch, actuellement en cours de finalisation, améliore la situation pour le rattrapage de contenu en direct (live catch-up), mais la VOD sur MoQ reste encore en cours de développement.
Le changement de débit adaptatif (ABR switching) au niveau du relais constitue une innovation architecturale et reste encore en cours de définition. Le mécanisme Dynamic Track Selection (changement de qualité piloté par le relais en fonction des signaux de congestion) ainsi que le filtrage des tracks sont en voie de standardisation mais ne figurent encore dans le draft IETF. La logique ABR côté player pour MoQ ne bénéficie pas non plus des décennies d’optimisation accumulées par les algorithmes ABR de HLS et DASH.
L’écosystème des navigateurs présente encore certaines lacunes.
WebTransport, l’API navigateur dont dépend MoQ, est désormais pris en charge par Chromium, Firefox et, depuis avril 2026, Safari iOS 26.4.
Cependant, le déploiement de navigateurs compatibles WebTransport n’est pas encore universel, et les opérateurs ciblant une grande diversité d’appareils devront prévoir des solutions de repli.
Enfin, si MoQ est envisagé pour la distribution primaire comme alternative à SRT (basé sur MP2TS), il pourrait devoir transporter des informations de service enrichies (tables DVB SI/PSI ou informations système ATSC) décrivant notamment les données EPG, les informations d’accès conditionnel ou les métadonnées réglementaires. Un système de distribution primaire basé sur MoQ devra définir la manière dont ces métadonnées sont transportées. Par ailleurs, les contenus de distribution primaire sont généralement protégés par des systèmes d’accès conditionnel (CAS), tandis que le modèle de sécurité de MoQ est centré sur les DRM.
Aucune de ces limitations ne constitue une raison de rejeter MoQ. Elles sont plutôt des raisons de planifier soigneusement son adoption et de distinguer précisément les cas d’usage prêts pour la production aujourd’hui de ceux qui gagneront en maturité au cours des deux à trois prochaines années.
Comment Ateme accompagne cette évolution
En tant que leader mondial des solutions de distribution vidéo, Ateme aborde MoQ sous plusieurs angles. Tout d’abord au niveau de l’encodage, en repoussant les limites de la compression à très faible latence avec TITAN afin de garantir que le compromis entre qualité et latence qui a longtemps contraint le streaming en direct n’ait tout simplement plus lieu d’exister.
Ensuite au niveau de la normalisation, en contribuant activement à l’interopérabilité et à la viabilité de l’écosystème MoQ via sa participation à OpenMOQ, ses contributions à Shaka Player et ses tests de validation de la pile protocolaire dans des conditions réelles, comme lors du NAB 2026 sur les infrastructures Cloudflare, Oracle Cloud ou sur la plateforme Big Blue Marble.
Grâce à un portefeuille de solutions couvrant la contribution, le transcodage, le packaging et la distribution sur tous les types de réseaux, Ateme est idéalement positionné pour accompagner ses clients dans leur transition vers MoQ, quel que soit leur point de départ en matière d’infrastructure.
En résumé
MoQ se situe aujourd’hui à un point de bascule entre promesse et réalité. La finalisation de la RFC est imminente. L’écosystème est bien réel et le marché est en train de se structurer. Les infrastructures de relais commencent à être déployées. Le manque de support des navigateurs, longtemps considéré comme un obstacle à une diffusion MoQ de bout en bout, se réduit avec la généralisation du support de WebTransport en 2026.
Pour les décideurs techniques qui évaluent leurs architectures de streaming, la question, pour ceux qui visent une latence de bout en bout inférieure à la seconde, n’est plus de savoir si MoQ est pertinent, mais de savoir à quelle vitesse l’ensemble de leur chaîne de distribution, depuis la contribution jusqu’au player, peut être modernisée.
[1] WebTransport est l’API développée conjointement par le W3C et l’IETF qui fournit à JavaScript un accès contrôlé aux flux et datagrammes QUIC, dans le cadre d’un modèle de sécurité appliqué par le navigateur, sans exposer directement les sockets UDP.