Entretien avec Régis Moulin (EUTELSAT), Co-Chairman du groupe TM‑NIP ensemble avec Tom Christophory (SES)
Le DVB Project a récemment finalisé la première version commerciale du standard DVB‑NIP (Digital Video Broadcasting – Native IP), publié par l’ETSI sous la référence TS 103 876. Présenté comme un pont entre les mondes du broadcast et de l’OTT, DVB‑NIP suscite un intérêt croissant au sein de l’industrie. Pour comprendre les principes techniques de cette nouvelle architecture et ses cas d’usage, nous avons rencontré Régis Moulin, Co‑Chairman du Technical Module NIP (TM‑NIP, le groupe d’experts de l’industrie qui définit le Standard DVB-NIP).
Régis, qu’est-ce que le DVB‑NIP, en quelques mots ?
Régis Moulin : Le DVB‑NIP est un standard technologique qui permet de distribuer des contenus audiovisuels et des données via les réseaux de diffusion broadcast — satellite ou terrestre — directement sous forme IP native. L’idée est de réutiliser les formats utilisés dans l’univers OTT pour les transporter efficacement sur une infrastructure broadcast.
C’est un changement de paradigme. Historiquement, les réseaux DVB transportaient principalement des flux MPEG Transport Stream. Avec le DVB‑NIP, nous transportons des objets IP. Une chaîne de télévision linéaire devient simplement une succession de petits fichiers appelés segments DASH ou chunks HLS distribués via un réseau broadcast.
Quels sont les problèmes que le DVB‑NIP cherche à résoudre ?
RM : Aujourd’hui, la plupart des diffuseurs exploitent deux infrastructures distinctes. D’un côté, une plateforme broadcast traditionnelle pour la télévision linéaire. De l’autre, une plateforme OTT reposant sur des CDN pour distribuer les mêmes contenus vers les smartphones, tablettes ou Smart TV.
Cette duplication génère de la complexité, des coûts et parfois des limites techniques. Chaque utilisateur OTT consomme sa propre copie des contenus. Lors d’événements à forte audience, les infrastructures CDN et les réseaux IP doivent absorber des volumes considérables de trafic. Les coûts augmentent avec le nombre d’utilisateurs et la qualité de service peut varier selon l’état du réseau Internet.
Le broadcast fonctionne différemment : la même transmission est reçue simultanément par un nombre illimité d’utilisateurs sans coût marginal supplémentaire. Le DVB‑NIP vise précisément à combiner cette efficacité du broadcast avec la souplesse de l’écosystème OTT.
Comment fonctionne concrètement une plateforme DVB‑NIP ?
RM : Une plateforme DVB‑NIP repose sur trois composants principaux : la plateforme d’émission, la passerelle de réception (Gateway) et les applications clientes. On peut voir leur interaction dans le schéma général présenté ci‑après.
Au cœur de la Plateforme d’Emission se trouve un serveur DVB‑MABR (Multicast Adaptive Bit Rate). Son rôle consiste à récupérer les contenus OTT sous forme de segments DASH ou HLS – normalement déjà disponibles chez les opérateurs, car ils alimentent leur réseau OTT – puis à les distribuer sous forme multicast sur le réseau broadcast.
Cette approche sous-entend un point important : le DVB‑NIP n’est pas limité à la vidéo. Tout contenu pouvant être représenté sous forme de fichiers IP peut être distribué. Cela inclut des vidéos à la demande, des applications, des mises à jour logicielles, des contenus éducatifs, des sites web statiques ou encore des éléments publicitaires.
Quels sont les flux traités par la plateforme ?
RM : Nous distinguons trois catégories principales.
La première concerne les contenus audiovisuels linéaires. Les chaînes sont préparées sous forme ABR, conformément aux méthodes du streaming vidéo (le format HLS issu d’Apple et le format DASH qui est le standard ouvert), exactement comme dans un environnement OTT classique.
La deuxième concerne la signalisation. Elle comprend toutes les informations permettant au terminal de découvrir les services disponibles : listes de chaînes, logos, guide des programmes, métadonnées éditoriales, etc.
La troisième catégorie regroupe les fichiers génériques. C’est elle qui ouvre de nouvelles possibilités, notamment pour les services « push » et les applications de distribution de données.
Quel est le rôle du DVB‑I dans cet ensemble ?
RM : Le DVB‑I apporte une solution standardisée pour la découverte des services et des métadonnées. Il définit la manière dont les listes de services, les guides électroniques des programmes et les informations associées sont structurés et interprétés par les terminaux.
Si le DVB NIP permet également l’utilisation de solutions propriétaires, le DVB-I est recommandé afin de garantir l’interopérabilité entre les plateformes et les applications.
En pratique, le DVB‑I joue pour l’univers IP un rôle comparable à celui occupé historiquement par les tables de signalisation du DVB classique.
Parlons maintenant du récepteur DVB‑NIP. Quel est son rôle ?
RM : La Gateway constitue la pièce maîtresse du côté utilisateur. Il reçoit le flux DVB‑NIP via satellite ou réseau terrestre, analyse la signalisation, récupère les contenus multicast puis les redistribue localement sous forme de flux OTT unicast classiques.
Le terminal client — smartphone, tablette ou Smart TV — voit simplement un serveur OTT local. Il n’a pas besoin d’intégrer directement un tuner satellite.
Selon les usages, les fabricants peuvent ajouter à la Gateway, les composants et fonctions d’une Box, comme un décodeur A/V (“player IP”) avec sortie HDMI, du stockage ou un point d’accès Wifi.
Que doit faire l’application côté utilisateur ?
RM : Grâce aux protocoles DNS‑SD et mDNS — souvent connus sous le nom de Bonjour dans l’écosystème Apple — l’application découvre automatiquement la présence de la Gateway sur le réseau local.
Une fois cette découverte effectuée, l’application récupère les listes de services et les URL des contenus puis lit les flux DASH ou HLS comme n’importe quelle application OTT.
C’est pourquoi nous disons souvent qu’un client DVB‑I auquel on ajoute la découverte automatique du Gateway devient pratiquement un client DVB‑NIP.
Faut-il remplacer entièrement l’infrastructure existante ?
RM : Non. C’est justement l’un des objectifs du standard.
Le DVB‑NIP a été conçu pour faciliter la migration progressive depuis les architectures DVB traditionnelles. Les opérateurs peuvent continuer à distribuer leurs services historiques tout en introduisant progressivement des services IP natifs.
Le standard supporte notamment deux modes de transport : le DVB‑MPE, compatible avec les infrastructures MPEG‑TS existantes, et le DVB‑GSE, plus efficace pour les déploiements futurs orientés IP.
Il faut aussi préciser que le DVB‑NIP nécessite effectivement une nouvelle génération de récepteurs, mais il s’agit davantage d’une évolution que d’une rupture technologique. Les équipements reposent sur une architecture très proche de celle des décodeurs satellites modernes, la plupart des fonctions spécifiques au DVB‑NIP étant implémentées par logiciel. Selon les usages, des fonctions comme le Wi‑Fi intégré ou le stockage local peuvent être ajoutées pour supporter les services multiscreens et Push‑VoD. Plusieurs fabricants proposent déjà des prototypes opérationnels et, comme lors des précédentes transitions technologiques du secteur, le léger surcoût actuel devrait progressivement disparaître avec l’augmentation des volumes. À terme, le coût d’un récepteur de DVB‑NIP devrait être comparable à celui des décodeurs satellites grand public actuels.
Non seulement, le DVB-NIP décrit une stratégie de migration depuis les modes de diffusion actuels, mais anticipe de nouveaux déploiements, comme la 5G Broadcast actuellement en test par TDF. Ces deux technologies s’appuient sur les mêmes solutions de streaming et protocoles de transmission.
Le standard est-il prêt pour une exploitation commerciale ?
RM : Oui. C’est probablement l’évolution la plus importante de ces dernières années.
Des solutions de tête de réseau, des passerelles, des applications clientes et des outils de validation existent déjà auprès de plusieurs industriels du secteur. L’écosystème s’est considérablement développé au cours des travaux de normalisation et nous disposons aujourd’hui de l’ensemble des briques nécessaires à un déploiement opérationnel.
Existe‑t‑il déjà des déploiements réels ?
RM : Le projet le plus emblématique est aujourd’hui celui de l’Instituto Nacional de Radio y Televisión del Perú (IRTP).
L’objectif était de fournir un accès aux contenus audiovisuels et éducatifs dans les régions les plus isolées du pays, là où les infrastructures terrestres sont absentes ou économiquement difficiles à déployer. Grâce au DVB‑NIP, les contenus sont diffusés via satellite puis redistribués localement vers des téléviseurs, smartphones ou ordinateurs sans dépendre d’une connexion Internet.
Ce projet est généralement considéré comme le premier déploiement commercial à grande échelle d’une architecture Native IP sur réseau satellitaire. Il démontre concrètement la capacité du standard à associer la couverture universelle du broadcast et la flexibilité des services IP.
Au‑delà des premiers déploiements, quelles sont les prochaines évolutions du standard DVB‑NIP ?
RM : Le standard continue d’évoluer activement et plusieurs sujets sont aujourd’hui au cœur des travaux du TM‑NIP. L’un des plus importants concerne la gestion des contenus protégés dans des environnements non connectés. Les mécanismes DRM utilisés par l’univers OTT fonctionnent très bien lorsque le terminal dispose d’une connexion Internet, mais nous travaillons désormais sur des solutions permettant de distribuer également les licences et les éléments de sécurité via le réseau broadcast afin de rendre possibles des services premium même en l’absence de connectivité haut débit.
Un autre axe majeur est le Filecasting, qui étend la logique de DVB‑NIP bien au‑delà de la vidéo. Les travaux sur les API visent notamment à rendre les Gateway NIP entièrement agnostiques à la nature et à la taille des fichiers distribués. L’idée est d’exploiter l’efficacité du broadcast pour distribuer n’importe quel type de contenu — catalogues VoD, contenus éducatifs, mises à jour logicielles, jeux vidéo, sites web ou objets destinés à alimenter des CDN locaux — en permettant aux utilisateurs de tirer parti des capacités de stockage déjà présentes sur leurs smartphones, tablettes, SmartTV ou dans leur environnement local, PC, NAS,… réduisant de fait les coûts d’adoption de cette technologie. Le réseau broadcast devient ainsi une infrastructure générique de distribution IP à coût fixe, capable de s’adapter à des volumes et des typologies de données variées, indépendamment du nombre de récepteurs.
Nous travaillons également sur des fonctionnalités destinées à enrichir l’expérience utilisateur. Le Download‑to‑Go permettra, par exemple, de transférer sur un smartphone ou une tablette des contenus préalablement reçus et stockés sur le Gateway DVB‑NIP, afin de les consulter ultérieurement hors connexion.
Enfin, la publicité constitue un autre domaine d’innovation. Des mécanismes de diffusion d’assets publicitaires via broadcast, associés à des playlists locales et à la remontée différée des statistiques d’audience lorsqu’une connexion devient disponible, ouvrent la voie à de nouvelles formes de monétisation, y compris dans des environnements partiellement ou totalement déconnectés. À plus long terme, ces travaux pourraient également préparer le terrain à des solutions de publicité ciblée nativement intégrées à l’écosystème DVB‑NIP.
En une phrase, comment résumeriez-vous le DVB‑NIP ?
RM : Je dirais que le DVB‑NIP applique l’efficacité du broadcast à l’univers OTT. Nous distribuons les mêmes contenus, dans les mêmes formats IP, mais avec l’échelle, la stabilité et la couverture propres aux réseaux de diffusion. C’est probablement la voie la plus naturelle pour faire converger les mondes du broadcast et de l’Internet au cours des prochaines années.
Glossaire des acronymes
ABR — Adaptive Bit Rate
Technique de streaming permettant d’adapter dynamiquement la qualité vidéo en fonction des capacités du réseau et du terminal de l’utilisateur.
API — Application Programming Interface
Interface logicielle normalisée permettant à deux applications ou systèmes d’échanger des données et des commandes.
CDN — Content Delivery Network
Réseau de serveurs distribués géographiquement permettant de rapprocher les contenus des utilisateurs afin d’améliorer les performances de diffusion OTT.
DASH — Dynamic Adaptive Streaming over HTTP
Standard ouvert de streaming vidéo adaptatif utilisé pour la diffusion de contenus OTT sur les réseaux IP.
DNS-SD — DNS Service Discovery
Protocole permettant à une application de découvrir automatiquement les services disponibles sur un réseau local.
DRM — Digital Rights Management
Ensemble de technologies permettant de protéger les contenus premium contre la copie ou l’accès non autorisé.
DVB — Digital Video Broadcasting
Organisation internationale qui définit les standards de télévision numérique utilisés dans le monde entier.
DVB‑GSE — Digital Video Broadcasting – Generic Stream Encapsulation
Méthode d’encapsulation IP très efficace permettant de transporter des paquets IP directement sur les réseaux DVB de nouvelle génération.
DVB‑I — Digital Video Broadcasting – Internet Centric Services
Standard DVB de découverte des services et de présentation des contenus sur les appareils IP. Il fournit notamment les listes de chaînes et les guides de programmes.
DVB‑MABR — Digital Video Broadcasting – Multicast Adaptive Bit Rate
Technologie permettant de convertir des flux OTT unicast en diffusion multicast afin d’optimiser leur transport sur les réseaux broadcast.
DVB‑MPE — Digital Video Broadcasting – Multi-Protocol Encapsulation
Technique historique permettant de transporter des données IP au sein d’un multiplex DVB classique basé sur MPEG Transport Stream.
DVB‑NIP — Digital Video Broadcasting – Native IP
Standard DVB permettant de distribuer des contenus et services directement sous forme IP native via des réseaux broadcast satellite ou terrestre.
EPG — Electronic Programme Guide
Guide électronique des programmes présentant les chaînes disponibles et leurs horaires de diffusion.
ETSI — European Telecommunications Standards Institute
Organisme européen chargé de la publication officielle de nombreux standards télécoms et audiovisuels.
Filecasting
Fonctionnalité DVB‑NIP permettant de distribuer tout type de fichiers (vidéo, logiciels, contenus éducatifs, jeux vidéo, sites web, etc.) via les réseaux broadcast.
Gateway (GW)
Équipement de réception DVB‑NIP qui reçoit les contenus broadcast, les traite puis les redistribue sous forme de services IP vers les terminaux locaux.
HLS — HTTP Live Streaming
Protocole de streaming développé par Apple et largement utilisé dans les services OTT.
mDNS — Multicast DNS
Extension du protocole DNS utilisée pour la découverte automatique d’équipements et de services sur un réseau local. [2026 07 En…FAVN v1.2 | Word]
MPEG‑TS — MPEG Transport Stream
Format historique de multiplexage utilisé pour la télévision numérique DVB.
OTT — Over-The-Top
Mode de distribution des contenus vidéo via Internet, indépendamment des réseaux broadcast traditionnels.
STB — Set-Top Box
Décodeur ou récepteur permettant d’accéder aux services audiovisuels distribués par satellite, terrestre ou IP.
TM‑NIP — Technical Module Native IP
Groupe de travail du DVB Project chargé de la définition et de l’évolution du standard DVB‑NIP.
