Au premier mouvement (Mediakwest #63, septembre), nous avons investigué le sujet de l’orchestration broadcast dans le cloud sous l’angle de la production vidéo ST 2110. Ce deuxième mouvement explore les fondamentaux du cloud et de son orchestration, en gardant à l’esprit la production vidéo.

Historiquement, les infrastructures de télévision ont été conçues pour des environnements stables, dimensionnés et fortement dépendants d’équipements spécialisés « hardware ». D’ailleurs, la mise en œuvre d’un dispositif TV nécessite encore plusieurs semaines de logistique et d’intégration manuelle. Accélérer la transformation de l’industrie broadcast ne consiste pas simplement à déplacer des charges de travail vers le cloud. Il s’agit plutôt de revoir en profondeur notre façon de concevoir, de déployer et d’orchestrer des services TV.

Aujourd’hui, de nouveaux concepts d’architectures transforment l’ensemble des verticales industrielles (télécoms, services, streaming…). Les télécoms ont ouvert la voie avec la virtualisation de fonctions réseau. Cette tendance s’est renforcée avec l’émergence de la philosophie « cloud native » – micro services, conteneurs, orchestration – qui promet agilité, élasticité et accélération du « time-to-market ».

L’orchestration, clé de la transformation broadcast

L’industrie broadcast n’échappe pas à cette dynamique. De grands groupes média, tels que Sinclair, NBCUniversal, Warner Bros. Discovery, Sky UK et Netflix, ont adopté les technologies basées sur le cloud, que ce soit pour la diffusion, la production, la distribution ou le streaming. De plus, les salons professionnels IBC et NAB font la vitrine d’une profusion d’applications cloud dédiées au broadcast.

Bien que tout le monde semble s’accorder sur les bénéfices, l’enthousiasme s’accompagne d’une prudence assumée. Le broadcast a la tête dans les nuages, mais garde les pieds sur terre.

Au-delà de la rupture technologique, cette transformation doit s’opérer sur le plan organisationnel et culturel. Il s’agit désormais de gérer de nouveaux types de ressources cloud, là où l’on manipulait jusqu’alors des équipements SDI et ST 2110. Dans ce contexte, l’orchestration devient un levier stratégique pour exploiter les environnements cloud. Mais de quels « clouds » parle-t-on ? Et comment l’orchestration peut-elle faciliter l’adoption d’une culture « software-based » et « cloud-ready » ?

Cloud et broadcast : un paradoxe industriel

Imaginez que vous disposez d’un large catalogue de droits de diffusion TV (sports, événements, séries) mais que la rigidité de vos infrastructures ne vous permette pas d’exploiter pleinement votre investissement. L’équation « faire plus avec moins » consiste donc à rendre votre activité plus agile. D’une part, elle vise à optimiser l’usage de vos ressources hardware (mélangeur vidéo, gateway software-defined…). D’autre part, elle permet d’accéder aux nouvelles ressources du cloud.

De réels avantages

L’orchestration d’une infrastructure cloud permettrait de répondre à plusieurs de ces scénarios :

1. absorber les pics d’activité ponctuels par l’allocation dynamique de ressources ;
2. substituer les contributions satellites onéreuses par des contributions cloud (SRT, RIST…) ;
3. déployer des services récurrents qui peuvent être arrêtés hors période d’exploitation ;
4. expérimenter facilement les innovations du cloud public : IA, science des données, etc.

Le modèle technologique du cloud public (Amazon Web Services, Microsoft Azure, Google Cloud…) répond aux impératifs d’élasticité et d’agilité des centres de production modernes. Le fournisseur de cloud public AWS, par exemple, s’impose en leader des applications média. Son stand à l’IBC 2025 présentait une quarantaine de démonstrations. L’industrie salue ses partenariats et ses innovations qui lui ont valu deux distinctions : Industry Partnership Award et IBC Best of Show Award.

Mais aussi des obstacles

Toutefois, malgré les bénéfices réels du cloud public, son adoption systématique reste en demi-teinte. On entend souvent sur le terrain la formule suivante : « Le cloud, tout le monde en parle, mais personne n’y va ! ». Cette rhétorique illustre bien un paradoxe propre à la production TV.

Selon le rapport du cabinet d’analyse Devoncroft (Big Broadcast Survey), l’adoption du cloud public connaît un ralentissement notable. Les grands groupes média qui ont investi le cloud public il y a quelques années ne sont plus légion. De plus, les discussions informelles de l’IBC 2025 ont révélé de nombreux questionnements. L’enjeu économique est bien réel, et les réflexions autour de la localisation des ressources se multiplient. Faut-il centraliser ou décentraliser ? Faut-il opter pour une approche cloud public ou hybride ? À la même période, TVU Networks soulignait le fait qu’« à peine 1 % des productions sont réalisées dans le cloud ».

Contrairement aux workflows basés sur les médias dématérialisés « file-based », la production vidéo temps réel présente des défis technologiques spécifiques qu’il faut considérer pour garantir une exploitation optimale. On pourrait croire que les freins à l’adoption se limiteraient aux exigences usuelles : latence, fiabilité et résilience. Or, les décisionnaires révèlent une réalité organisationnelle et économique tout aussi déterminante.

Le coût caché de la flexibilité

La compréhension des coûts opérationnels reste un défi majeur. Il n’est pas aisé de prévoir avec certitude le coût d’une production du fait de nombreux facteurs : trafic sortant, échanges multi-cloud, modèle de licence, variabilité des usages, etc.

• Un déficit de compétences

La complexité technologique de l’IT/DevOps contraste avec les compétences historiques des équipes d’ingénierie broadcast.

• Des fonctions critiques encore incomplètes

Certaines fonctionnalités essentielles pour assurer un standard de production sont vraisemblablement manquantes ou limitées (audio, intercom, mélangeur vidéo…).

• Une interconnexion encore trop complexe

L’interconnexion d’équipements sur site avec un cloud repose encore largement sur des procédures manuelles. Le risque opérationnel est élevé du fait des nombreux paramètres de configuration : adresses IP, protocoles, règles de sécurité…

Ces questionnements sont d’autant plus pertinents au regard des enjeux de souveraineté numérique et des récentes défaillances du cloud public. Dans ce contexte, de nouvelles stratégies émergent, notamment avec l’orchestration d’environnements multi-cloud et cloud hybride (voir figure 1). L’orchestrateur joue effectivement un rôle central. Il agit comme le garant de la cohérence technique et économique. Il ne suffit pas de consommer des ressources temporaires, il faut aussi les gérer, assurer leur cohérence globale et protéger leur exploitation.

Plusieurs Proof of Concept récents ont permis de tester ces approches dans des environnements concrets. Nous découvrirons progressivement les principales fonctionnalités d’orchestration qui permettent d’aborder cette transformation sereinement.

Retours de Proof of Concept : perspectives encourageantes

L’exploitation du cloud en production TV est encore un sujet exploratoire. Les organisations cherchent des alternatives qui répondent à trois besoins essentiels : l’adéquation technique, l’élasticité des ressources et l’optimisation des investissements financiers. Pour valider ces approches, plusieurs preuves de concept (PoC) ont émergé en Europe. Analysons ci-après deux retours d’expérience : l’un basé sur un fournisseur et l’autre sur un écosystème multi-fournisseur.

• Cloud Media Production

Le secteur audiovisuel belge a récemment franchi une étape importante avec l’achèvement de son PoC cloud. Un projet soutenu par l’initiative « Digital Transformation » du gouvernement flamand. Au cours de deux années de tests, ils ont pu créer un environnement de production évolutif, efficace et accessible aux équipes (créatifs, éditeurs et ingénieurs…).

L’expérimentation s’est appuyée sur la solution LiveOS de l’éditeur belge NetOn.Live, en charge de la production vidéo et de l’orchestration des ressources. L’initiative a démontré la faisabilité technique du modèle, comme l’ont souligné les porteurs du projet : « La production dans le cloud n’est plus une vision, c’est une réalité. »

LiveOS a ainsi pu valider sa suite applicative constituée de plus de quarante fonctions média, dont celles en lien avec l’orchestration :

• automatisation de production (macro, salvo, etc.) ;
• instanciation de templates de production ;
• routage des flux audio/vidéo ;
• gestion des ressources (spin up/down).

• Master Control Cloud

Plus récemment, la RTÉ (chaîne irlandaise) et la BBC ont mené une évaluation approfondie du concept de Master Control Cloud, dont les différentes composantes sont illustrées dans la figure 2.

Ce projet collaboratif, présenté à l’IBC (Zone Accelerator), se distingue par son approche pragmatique. Les équipes ont privilégié l’évaluation de la faisabilité opérationnelle et l’interchangeabilité des fonctions média. Tout cela dans un environnement multi-fournisseurs et multi-clouds (AWS, Google).

Les résultats ouvrent des perspectives intéressantes. À terme, nous devrions pouvoir interchanger dynamiquement une ressource logicielle d’un fournisseur A avec un fournisseur B, en fonction de critères de coût, de performance et de qualité. Cet exemple illustre le niveau de flexibilité que l’on attend d’une orchestration moderne pour créer un contexte opérationnel agile.

À défaut d’un orchestrateur, les équipes ont dû connecter les signaux manuellement, en utilisant les données d’un tableur Google Sheets. Cette expérience laborieuse aura permis de formaliser les fonctions clés d’un orchestrateur MCR cloud :

• couche d’orchestration unifiée ;
• interface opérationnelle unique ;
• API universelle pour rappeler des « templates » ;
• fonctions média hébergées chez plusieurs fournisseurs cloud.

Le MCR basé sur le cloud est-il l’avenir ? Selon le fournisseur InSync, la réponse est « oui, mais pas dans l’immédiat ». Outre les avantages constatés – flexibilité, évolutivité et efficacité des coûts – le concept est non seulement possible, mais également viable d’un point de vue opérationnel. Toutefois, les opérations de diffusion 24/7 exigent la fiabilité et la simplicité du matériel broadcast. « L’évolution la plus probable à court terme sera un modèle hybride. »

Ces retours d’expérience démontrent la nécessité d’une orchestration moderne pour faciliter la tâche des équipes d’exploitation. Sur le plan stratégique, il est crucial d’adopter une approche cloud native. Cela permet de déployer des fonctions média, peu importe leur environnement : cloud privé, public ou hybride.

En route vers le cloud native

• Les fondamentaux

Le cloud native représente une nouvelle pratique de développement et un écosystème technologique (voir figure 3). Il permet de concevoir et de déployer des applications modernes selon les principes d’élasticité, de résilience et de portabilité.

Contrairement à la virtualisation, les applications cloud native sont conçues pour exploiter la puissance du cloud computing.

Elles sont décomposées en petits modules indépendants « micro services » que l’on exécute dans des conteneurs « Docker ». Ce découpage modulaire permet d’assurer un dimensionnement à la hausse ou la baisse (scale up/down).

C’est le principe de la scalabilité. Prenons l’exemple d’une application mélangeur vidéo qui pourrait se décomposer en plusieurs micro services : T-bar (gestion des transitions), Mix/Effects (effets de mixage), Frame Store (mémoire d’images), etc.

Cette implémentation permettrait d’ajuster dynamiquement la puissance allouée à chaque module en fonction des besoins réels de production.

Le cloud native ne se limite pas au cloud public. Son principe fondamental est de rendre les applications indépendantes de leur environnement d’exécution. Cela garantit leur portabilité, qu’elles soient sur cloud public, privé ou hybride.

C’est un réel avantage stratégique pour garantir l’indépendance et la flexibilité dans les choix d’infrastructure.

Une stratégie multi-cloud ou hybride permettrait notamment de redistribuer des services sur des infrastructures distantes en fonction de critères établis – souveraineté numérique, optimisation des prix, contraintes de latence, disponibilité géographique – ou simplement selon les besoins opérationnels.

C’est précisément la scalabilité et la portabilité du cloud native, qui offre une réponse directe à la maîtrise des coûts et à la dépendance fournisseur.

• L’orchestration de conteneurs

La fondation Cloud Native Computing Foundation (CNCF) héberge l’écosystème des projets cloud native. Elle regroupe plus d’une centaine d’applicatifs organisés en six catégories (observabilité, orchestration, provisionnement…). Selon la CNCF, les ressources du cloud sont éphémères par nature, car elles sont créées en fonction des besoins.

Par conséquent, la complexité des systèmes augmente de manière exponentielle en fonction du nombre de micro services déployés. Une orchestration est donc essentielle pour coordonner cette complexité. On compte environ cinquante projets en lien avec l’orchestration de conteneurs, dont le plus populaire Kubernetes [ndlr : notation abrégée K8s].

K8s gère le cycle de vie des micro services : création/destruction, démarrage/arrêt, entre autres. Il est devenu l’orchestrateur de référence de la communauté cloud native pour les déploiements à grande échelle. L’émergence des besoins en matière d’intelligence artificielle a fortement enrichi ses fonctionnalités.

• Le cloud native appliqué au broadcast

La figure 4 illustre une interprétation des principes d’architecture cloud native qu’on pourrait appliquer au broadcast. Ce modèle se décompose en trois couches d’abstraction et trois couches transverses.

• Les couches d’abstraction

– la couche applicative héberge les fonctions métier, telles que les fonctions réseau dans les télécoms ou encore les fonctions média dans le broadcast (encodeurs, graphiques…) ;

– la couche plate-forme est un environnement chargé d’exécuter les charges de travail (workloads). Cette couche comprend notamment l’orchestrateur K8s et les services associés ;

– la couche infrastructure héberge les ressources physiques : interface réseau, CPU , GPU, stockage… ;

• Les couches transverses

– l’observabilité : supervision et collecte de métriques à travers toutes les couches ;

– le provisionnement : automatisation de la configuration (ndlr : Infrastructure as Code) ;

– l’orchestration et management est la coordination des infrastructures et services pour gérer efficacement la complexité de ces topologies.

L’architecture cloud native apporte une agilité incontestable, mais au prix d’une nouvelle complexité. De nombreuses communautés open source ont rejoint la CNCF.

Cela les aide à accompagner l’adoption du cloud native dans leurs secteurs respectifs. C’est notamment le cas de l’industrie des télécoms qui a vu émerger des initiatives autour de l’orchestration et du cloud. La transformation du secteur télécom est à ce titre un exemple particulièrement éclairant pour le broadcast.

• S’inspirer de l’orchestration du Cloud Télécom

L’article introductif sur l’orchestration (Mediakwest #63) a révélé une deuxième vague de transition : le tout logiciel, ou software-based. Cette approche vise à se défaire des équipements hardware, pour accroître la flexibilité et s’adapter plus rapidement aux besoins du marché. L’industrie des télécoms a entamé cette transformation il y a plus de dix ans. Son parcours offre aujourd’hui un retour d’expérience précieux.

• Les standards ETSI-NVF et ETSI-MANO

Dès 2012, l’Institut Européen de la Standardisation des Télécommunications (ETSI) a standardisé le concept de Networked Virtualized Function (NVF).

Il repose sur la virtualisation de fonctions et d’applications réseau sur du matériel informatique COTS (Commercial Off-The-Shelf). Ce modèle a ouvert la voie à de nouvelles architectures virtualisées.

Par exemple, les réseaux de distribution vidéo (vCDN) ou encore les têtes de réseau vidéo (vHE). Le standard ETSI-NVF a continuellement évolué, en intégrant le Software-Defined Networking (SDN), le cloud native, et maintenant le support de l’intelligence artificielle.

Sur le plan de l’orchestration, le standard ETSI-MANO (Management and Orchestration) encadre la configuration dynamique des réseaux, dont l’automatisation du cycle de vie des VNF.

Plusieurs projets open source comme Sylva, Arkunet, OSM ont émergé ces dernières années. Ils soutiennent l’adoption du cloud native en s’appuyant sur les efforts de standardisation et de spécification de l’ETSI, du 3GPP et du TM Forum. Il s’agit désormais d’orchestrer le « Telco Cloud », (figure 5).

• Les bénéfices de l’orchestration

Les bénéfices du Telco Cloud sont mesurables. Orange France et Ericsson ont récemment passé le premier appel 5G via une plate-forme cloud. Cette expérimentation vise à préparer les futures évolutions de la 5G.

Cela ouvre des perspectives prometteuses sur l’orchestration des nouveaux services cloud native. On peut également souligner le rapport de l’ETSI qui synthétise les bénéfices liés à l’adoption de son standard d’orchestration (figure 6).

Les résultats dépassent les attentes dans plusieurs domaines clés. Cela inclut notamment l’interopérabilité, le CAPEX, la scalabilité et la rapidité de déploiement des nouveaux services.

En somme, le secteur des télécoms nous fournit une feuille de route pour l’orchestration cloud.

La standardisation a été le catalyseur de sa transformation, en favorisant notamment le développement d’expertise et de la collaboration. Bien que le marché des télécoms soit plus vaste, l’industrie broadcast peut adopter ces bonnes pratiques pour faciliter sa transition.

• Les fonctions clés de l’orchestration

Une définition récente de l’orchestration la décrit comme un « cadre et architecture permettant d’automatiser le cycle de vie de bout en bout d’un événement ou d’un service à travers plusieurs domaines technologiques…

Les ressources sont gérées en tenant compte de leurs contraintes : disponibilité, capacités et fonctionnalités » (SMPTE MTS, Californie).

L’orchestration des services media s’opère au plus haut niveau afin de piloter la logique métier et d’assurer la cohérence globale des opérations (voir figure 4). Les solutions issues de plusieurs industries révèlent un ensemble de fonctionnalités clés.

Au cœur de ces fonctions se trouve le gestionnaire de ressources. Celui-ci assure l’allocation des ressources et l’automatisation du déclenchement d’événements. Les ressources cloud native étant éphémères, elles n’existent que durant une période de temps gouvernée par l’orchestrateur.

La figure 7 illustre un cycle de vie en quatre phases opérationnelles. Ce nouveau modèle d’exploitation s’accompagne d’un vocabulaire spécifique (réservation, placement, instanciation, initialisation…) qui reflète la dynamique des environnements cloud.

Ainsi, cette gestion avancée des ressources ouvre la voie à une utilisation optimisée, selon de multiples critères : contraintes budgétaires et autres performances ciblées.

Le support du cloud hybride et l’interopérabilité sont des atouts clés de la production distribuée.

L’orchestrateur établit un lien entre les environnements sur site et le cloud pour assurer une continuité opérationnelle. Un contrôle unifié des ressources est assuré, qu’elles soient locales ou distantes.

De plus, l’idée d’alliance ou d’écosystème de partenaires se développe progressivement (GV Media Universe, TVU Board, Sony Networked Live, etc.).

Cette stratégie enrichit l’offre de services d’une approche modulaire « best of breed ». Le broadcaster peut ainsi bénéficier d’une variété d’applications tierces dans un écosystème « commercialement ouvert ».

Enfin, l’interface utilisateur est tout aussi essentielle. Elle simplifie la complexité technique grâce à une interface unifiée centralisant l’accès aux diverses fonctions. On parle désormais d’orchestration visuelle ou d’interfaces no-code/low-code pour faciliter l’exploitation des plates-formes.

• Réponses aux défis du cloud

L’orchestrateur joue un rôle déterminant pour faciliter l’exploitation du cloud et particulièrement le cloud public. La figure 8 propose quelques leviers opérationnels pour surmonter les principaux freins à l’adoption que nous avons identifiés en préambule.

1- La maîtrise des coûts

• Orchestration intelligente des ressources

L’activation « just in time » des ressources assure une utilisation optimale des fonctions média. Les ressources ne sont mobilisées que lorsqu’elles sont réellement requises. (figure 7)

• Options de redondance

Différentes stratégies de protection des flux peuvent être implémentées en fonction du niveau de risque. Typiquement, une production enregistrée pourrait s’accommoder d’une sécurité moindre. L’orchestrateur peut optimiser les coûts en combinant les mécanismes appropriés : ST2022-7, N+1, ARQ, FEC, hitless merge…

• La portabilité

Plusieurs stratégies de déploiement sont possibles, qu’elles soient basées sur un cloud privé (Red Hat OpenShift, OpenStack, Oracle OCI, etc.), public ou hybride. Avec le principe Bring Your Own Cloud (BYOC), les clients peuvent sélectionner le fournisseur cloud qui correspond le mieux à leurs besoins. L’orchestrateur doit être indépendant de son environnement d’exécution.

• Dynamic Software Licensing (DSL)

Depuis fort longtemps, le modèle d’affaire du broadcast s’est fortifié autour du CAPEX. Les besoins de productions occasionnelles sont traités au cas par cas. Il s’agit souvent d’une négociation commerciale sur la base de licences perpétuelles ou de quotas.

Aujourd’hui, on observe l’émergence de nouveaux modèles plus flexibles. On parle de « subscription, credit-based, usage-based, token-based, Pay as you go, ou encore de semi-capex ».

Tant de termes marketing annonciateurs d’un nouveau changement de paradigme. Lawo propose son offre commerciale Lawo Flex, Eyewinn Technology adopte une facturation à l’usage et Ross Video gère le Dynamic Licensing grâce à sa plate-forme RPM (Ross Platform Manager).

Il va de soi qu’une orchestration devra coordonner agilement les licences et les ressources en fonction des besoins de production. Notons qu’il n’existe pas, à ce jour, de consensus pour fédérer les approches isolées des vendeurs. Soulignons cependant l’initiative de AWS et de ses partenaires qui ont annoncé au VSF New-York une réflexion sur le Dynamic Software Licensing.

Un des fondements clés consisterait à définir une API universelle pour gérer les licences (ndlr : article publié dans le magazine de l’IABM : Journal n°135).

• Le FinOps à la rescousse

A ce stade, l’enjeu fondamental du cloud public est clair : il est impératif de définir une stratégie d’orchestration adéquate pour optimiser l’usage des ressources. La démarche de FinOps (Financial Operations) consiste justement à tirer parti des bonnes ressources et à rechercher les améliorations pertinentes. Un orchestrateur devrait permettre de prévoir les coûts opérationnels et les comparer avec la consommation réelle. L’intégration avec une solution d’analyse de type Business Intelligence (BI) permettrait de détecter tout changement ou amélioration non sollicités. Cette pratique est nécessaire pour faciliter le suivi quotidien des opérations.

2- Complexité opérationnelle

L’adoption du cloud impacte directement les équipes opérationnelles. Une orchestration peut faciliter la prise en main et masquer la complexité sous-jacente. Plusieurs fonctionnalités se démarquent. Les interfaces dites low-code et no-code permettent aux utilisateurs de concevoir des workflows sophistiqués sans nécessiter de compétences techniques approfondies. L’orchestration devient aussi de plus en plus visuelle en permettant la construction de workflows graphiques. L’éditeur de topologie est notamment fondamental pour construire le schéma global de la production. Il permet de déployer des modèles préconfigurés (templates) pour les besoins récurrents. Enfin, grâce à l’intelligence artificielle, l’utilisateur pourra générer des infrastructures TV complexes en utilisant un langage naturel. C’est un concept émergent que nous explorerons dans un prochain article.

3- Limitations fonctionnelles

Les principales limitations répertoriées sont liées aux capacités audio et à la puissance de calcul nécessaire pour certaines applications vidéo.

Sur le plan audio, il faut assurer des fonctions d’intercommunication et de mixage. Le transport de signaux de production ST 2110-30 entre les studios et le cloud a été jusqu’alors limité.

Le cloud ne répondant pas aux prérequis techniques : multicast, NMOS, PTP et faible latence. Une solution a récemment émergé pour étendre les réseaux locaux au cloud. CloudSwXtch de swXitch.io règle le problème en créant une couche d’abstraction réseau pour facilement connecter ces deux mondes.

D’ailleurs, les fournisseurs Telos Alliance et On-hertz Aristo ont d’ores et déjà adopté cette technologie pour enrichir leur solution. Ainsi, un orchestrateur pourrait opérer un workflow audio de bout en bout en contrôlant le switch virtuel de swXitch.io.

Sur le plan vidéo, la problématique du cloud public réside dans la puissance de calcul nécessaire pour produire de façon iso-fonctionnelle.

Aujourd’hui, la capacité d’une fonction média est contrainte par la capacité maximale de l’instance de calcul du cloud (AWS EC2 par exemple). Cette approche peut être particulièrement coûteuse si on doit déployer un mélangeur vidéo dans le cloud…

Dans un futur proche, le découpage d’une fonction média en micro services pourrait permettre une répartition de la charge de calcul sur plusieurs serveurs.

Les échanges de médias en temps réel seraient alors assurés par la prise en charge du protocole MXL (Media eXchange Layer), ainsi que d’autres protocoles réseau tels que RoCE v2 (RDMA over Converged Ethernet).

L’orchestrateur serait de facto en charge du partage de ressources média entre les différents serveurs.

En résumé, l’orchestration dispose de nombreux leviers pour faciliter l’exploitation et l’adoption de cloud.

La portabilité des applications est le dénominateur commun d’une transition vers la production software-based. Bien qu’il n’existe pas de standards ou de guides pratiques sur le sujet, on peut espérer que la notion d’orchestration sera définie dans le cadre des travaux du Dynamic Media Facility (DMF).

Dynamic Media Facility : industrialiser le software-based

À l’instar du modèle Telco Cloud exposé en début d’article, le DMF bouleverse les méthodes traditionnelles du broadcast. Il définit une infrastructure de production entièrement logicielle qui a été conceptualisée en 2024 par l’EBU et certains membres actifs.

L’objectif est d’adopter une approche flexible et un écosystème interconnecté dont les fondamentaux reposent sur quelques principes clés :

• approche 100 % logicielle ;
• un modèle d’infrastructure inspiré du cloud ;
• une couche d’échange média unifiée (Media eXchange Layer) ;
• interopérabilité entre les solutions ;
• déploiement flexible de fonctions média.

En pratique, il s’agit de pouvoir exécuter des fonctions média (figure 9, en vert) de manière dynamique et interchangeable sur une plate-forme informatique générique (figure 9, en bleu).

Les différentes fonctions média (mélangeur, mosaïque, console audio, etc.) peuvent échanger des flux (vidéo, audio, données, etc.) directement via la mémoire informatique « shared memory » grâce au nouveau protocole MXL.

L’ambition est de garantir l’interopérabilité des fonctions, que ce soit à l’échelle d’un serveur ou entre plusieurs serveurs, sans avoir à recourir au réseau ST 2110.

À titre d’exemple, la figure 10 illustre un cas d’application suggéré par la chaîne CBC/Radio-Canada.

La logique de production y est matérialisée par des templates qui sont constitués de fonctions virtuelles, en lieu et place des équipements (SDI, ST 2110). La chaîne envisage de reconfigurer dynamiquement ses plates-formes de production en fonction de ses besoins. Elle compte par ailleurs conduire des expérimentations durant les JO d’hiver Milan-Cortina.

Afin d’assurer la gouvernance du DMF, l’EBU et l’AMWA se sont associés en créant une force d’action commune, la « Joint Taskforce » JT-DMF. La toute première séance inaugurale s’est tenue à Genève, réunissant les membres et les fournisseurs. L’objectif était de créer quatre groupes de travail, dont un consacré au « Compute Resources Management ».

Contrairement au secteur télécom, le sujet de l’orchestration dans l’industrie broadcast n’a jamais été standardisé. La prochaine version du DMF à venir devrait mettre en exergue la nécessité de clarifier la notion d’orchestration.

En complément des fonctions transversales existantes (sécurité, contrôle, provisionnement), l’orchestration devrait couvrir les différents niveaux du modèle cloud. L’approche pragmatique et agile du DMF permettra sans doute d’avancer plus rapidement qu’un long processus de standardisation.

Des solutions software-based existent, avec déjà plusieurs déploiements en data center privés (CBC/Radio-Canada, DMC Production, BMG…). Ces solutions et frameworks propriétaires adoptent un modèle en couches IT. On peut citer Lawo HOME, GV AMPP, NetOn.Live, Matrox Origin, Nvidia Holoscan, Intel Tiber.

Le DMF permettra de faciliter l’interopérabilité des solutions du marché, quelle que soit la stratégie d’hébergement des ressources.

C’est en quelque sorte le trait d’union entre le cloud privé (sur site, hébergé..) et le cloud public dont l’orchestration aura la charge de mettre en musique via des protocoles de contrôle. La machine software-based est désormais lancée et il faudra attendre les mois à venir pour découvrir la feuille de route.

Ne perdons pas le contrôle

Il n’existe pas à ce jour de protocoles de contrôle clairement établis pour le cloud. Essayons de comprendre les récents dénouements en la matière.

NMOS Control et Monitoring (IS-12)

L’AMWA continue ses campagnes de vulgarisation pour supporter l’adoption du protocole IS-12. Il permet de faciliter l’exploitation d’infrastructures ST 2110.

On peut supposer que la suite NMOS deviendra un choix naturel pour les productions cloud. Les particularités du cloud nécessiteront sans doute des évolutions.

C’est une tâche qui devrait mobiliser les groupes de travail JT-DMF pour assurer la cohérence globale des workflows hybrides ST 2110 – software.

À noter que l’événement NMOS Tested fera prochainement son retour. La communauté NMOS se rassemblera le temps de conduire quelques sessions d’interopérabilité.

SMPTE ST 2138 (Ross Catena)

Le processus de standardisation du protocole ST 2138 a été amorcé. Lors du récent séminaire technologique de la SMPTE à Pasadena, Californie, il est apparu clairement que ce protocole pourrait répondre aux besoins du cloud, bien que cela reste à démontrer dans la pratique.

Pour rappel, le standard ST 2138 définit le contrôle et la gestion de tous types de ressources en environnements hybrides et multi-constructeurs. Le document central, ST 2138-10, définit entre autres l’architecture générale ainsi que la découverte des ressources.

Il est donc établi que cette initiative entraînera la fragmentation du marché, alors même que les bases du DMF commencent à être posées par le JT-DMF.

Pour paraphraser l’intervenant de Ross Video, Chris Lennon (directeur, standards strategy), nous disposons certes de deux approches (NMOS IS-12 vs ST 2138) pour le contrôle, mais in fine, c’est toujours mieux que de gérer les +200 protocoles historiques du broadcast. Lennon a également souligné le fait que l’orchestration des ressources pourrait être facilitée en adoptant une approche standardisée, sécurisée, prête à l’emploi et basée sur un protocole unique.

Un futur plugfest est attendu courant mi-2026 pour permettre aux fabricants de tester leur implémentation du ST 2138.

Client Device Discovery (CDD)

Le CDD est un protocole qui a pour ambition de simplifier la connexion d’équipements vidéo avec le cloud. La mise en œuvre de contribution vidéo Ground to Cloud Cloud to Ground (GCCG) est parfois complexe et sujette aux erreurs humaines. Elle nécessite la saisie manuelle de nombreux paramètres techniques : VPN, pare-feu, IP statiques, clés…

Pour résoudre ce problème, AWS développe un protocole basé sur des technologies IoT (Internet des Objets). Cette solution ouverte permettra de connecter facilement les équipements en utilisant un mécanisme d’appairage (Code, QR code, etc.). Le SDK sera accessible à tous les fournisseurs de cloud et les fabricants qui souhaitent l’utiliser.

Le CDD est en cours d’analyse par le groupe de travail GCCG du Video Service Forum (VSF). Il pourrait être considéré pour devenir une recommandation technique VSF TR-12.

On pourrait imaginer à terme que le CDD puisse s’intégrer directement aux protocoles RIST et SRT pour un usage plug-and-play.

La figure 11 illustre une possibilité d’intégration d’un orchestrateur pour coordonner l’ensemble.

API-First

Enfin, n’oublions pas que le cloud native est aussi fondé sur le principe « API first » (figure 3). L’expérience d’une plate-forme de production TV sera enrichie par l’usage des API.

Il faudra compter sur les interfaces Northbound et Southbound des orchestrateurs pour s’interfacer avec l’écosystème cloud. Le docteur Adrian Roe, de Norsk Video, soulignait récemment le fait que l’IA pourrait faciliter l’intégration des protocoles.

Grâce aux agents IA, on pourrait imaginer une passerelle automatique entre diverses API. Cela permettrait de réduire les coûts d’intégration et faciliter la collaboration entre fournisseurs (ndlr : ce n’est pas de la science-fiction, mais presque).

Il faudra espérer qu’un consensus sur les protocoles émerge à mesure que l’écosystème cloud se développe.

Conclusion

Le cloud n’est pas une destination en soi. C’est avant tout un cheminement qui se construit par l’expérimentation, l’appropriation et la reconnaissance d’une valeur ajoutée tangible.

Le paradoxe du broadcast révèle une réalité de terrain. Si le cloud public offre indéniablement flexibilité et scalabilité, il ne répond pas, à lui seul, aux exigences de la production TV. Les retours d’expérience sont encourageants.

Toutefois, la maturité fait défaut, surtout dans un contexte multi-vendeurs et multi-clouds. Le constat est sans appel : aujourd’hui, à peine 1 % des productions sont réalisées dans le cloud public.

L’orchestrateur est indispensable pour faciliter l’adoption du cloud. Nous l’avons montré tout au long de cet article. Sur le plan économique, une gestion avancée des ressources permet de mieux maîtriser les coûts opérationnels, notamment grâce aux pratiques FinOps et à l’allocation dynamique des ressources.

Sur le plan humain, l’orchestration joue un rôle tout aussi essentiel en masquant la complexité technique : interfaces low-code/no-code, outils de monitoring et workflows visuels qui facilitent la tâche des opérateurs.

Un frein subsiste toutefois : la performance des productions TV est fortement dépendante de l’écosystème technologique, ce qui explique les écarts fonctionnels actuels.

Le véritable virage repose sur l’adoption d’une posture software-based. Les enjeux de souveraineté et de fiabilité ont changé la donne. Le modèle cloud privé s’impose comme la voie la plus évidente pour envisager des productions logicielles à grande échelle.

Les principes fondamentaux du cloud computing, notamment la scalabilité, ne sont plus l’apanage du cloud public. La portabilité des applications cloud native permet désormais leur déploiement dans des environnements privés ou hybrides.

L’exemple du secteur télécom est particulièrement éclairant : ayant entamé cette transformation il y a plus de dix ans, il a déjà franchi le cap du software-based. La standardisation de l’orchestration avec ETSI-MANO génère des bénéfices mesurables en matière d’interopérabilité et d’agilité. Le broadcast peut aujourd’hui s’inspirer de ce retour d’expérience précieux.

C’est précisément l’ambition du Dynamic Media Facility : poser les bases d’une infrastructure de production entièrement logicielle, agnostique de son environnement d’exécution.

Dans ce modèle, l’orchestration joue un rôle central pour coordonner et optimiser l’usage des ressources, qu’elles soient locales ou distantes.

Le véritable défi n’est désormais plus technologique, mais collaboratif. L’écosystème cloud broadcast reste fragmenté : divers protocoles de contrôle et de transport, modèles de licences hétérogènes, intégrations encore limitées. La prochaine étape consistera à faire converger toutes les initiatives vers une feuille de route commune. Le JT-DMF incarne cette ambition. La transformation sectorielle est en marche et le broadcast écrit une nouvelle partition, à son rythme. Mais une certitude demeure : sans chef d’orchestre, les instruments du cloud resteront désaccordés.

Pour aller plus loin

Cette réflexion en quatre mouvements vous guidera, crescendo, vers l’orchestration de demain :

• Le troisième mouvement – Intermezzo, dressera un panorama des solutions d’orchestration du marché
• Le quatrième et dernier mouvement – Finale, explorera les fonctionnalités et pratiques disruptives du futur (Agents IA, MCP, GPU serverless, etc.).

Article paru pour la première fois dans Mediakwest #65, p. 34-44