AV-over-IP : comment distribuer audio et vidéo sur un réseau professionnel ?

Les écrans d’un showroom, les salles de conférence et les zones sonores d’un hôtel peuvent échanger des flux audio-vidéo sur Ethernet. L’AV-over-IP permet cette distribution, mais ce n’est pas un simple branchement d’extendeurs sur n’importe quel switch. La qualité dépend de l’architecture du réseau, des codecs, de la gestion des flux multicast, de la synchronisation et des contraintes d’exploitation. Voici comment préparer ce type de projet sans confondre l’audiovisuel IP professionnel avec le streaming Internet classique.

Photo by Thomas Delacrétaz on Unsplash

Synthèse pour décideurs (à valider avec l’IT)

• Commencer par les usages (qui envoie quoi vers qui, simultanéité, salles divisibles), puis dimensionner le réseau sur le scénario le plus chargé.
• Ne pas déduire la faisabilité d’un “4K” : exiger du fournisseur les débits par flux, la latence et le mode de distribution (unicast/multicast) pour les réglages réels.
• Multicast = décision d’architecture : l’optimisation (réplication non ciblée / flooding multicast) dépend des switches et de la configuration (IGMP snooping, querier, etc.). Les comportements sont décrits au niveau “considérations” par la RFC sur l’IGMP/MLD snooping (source : RFC 4541), mais l’implémentation exacte reste à valider sur la plateforme réseau et avec la solution AV retenue.
• Inter-VLAN / multi-zones : faire traverser des flux multicast au-delà d’un VLAN/sous-réseau n’est pas un “détail de switch” ; c’est un choix à cadrer avec l’IT (portée, sécurité, exploitation).
• La recette est un livrable : tests de charge, de commutation, et de reprise après incident doivent être définis au cahier des charges et remis avec un dossier d’exploitation.

Définir les sources et les destinations

Avant d’arrêter une marque, l’intégrateur doit lister les sources : ordinateurs, lecteurs média, caméras, micros et postes de conférence. Il identifie ensuite les destinations : écrans, projecteurs, zones audio, enregistreurs et salles divisibles. Les flux peuvent être point à point, un vers plusieurs ou plusieurs vers plusieurs selon les besoins.

Le projet doit aussi préciser les événements : changement de configuration de salle, réunion hybride, diffusion sur plusieurs écrans et gestion des droits de commande. Pour les usages hôteliers et les contraintes de présentation, notre dossier sur la sonorisation professionnelle rappelle l’importance de la couverture audio et de l’acoustique.

Repère de vocabulaire (pour cadrer les échanges IT/AV)

• VLAN (Virtual LAN) : segmentation logique d’un réseau Ethernet pour isoler des usages (médias, contrôle, administration, invités…).
• IGMP (Internet Group Management Protocol) : protocole IPv4 utilisé par les hôtes pour signaler à un routeur multicast voisin leur volonté de recevoir (ou non) un groupe multicast, et par le routeur pour interroger les hôtes (source : RFC 9776).
• IGMP snooping : fonction de commutation (couche 2) qui observe (“snoope”) les messages IGMP afin de limiter l’envoi des trames multicast aux ports où des récepteurs ont exprimé un intérêt, plutôt que de laisser le multicast être répliqué de manière non ciblée selon le comportement du switch (source : RFC 4541). Attention : la RFC est de type “Informational” et décrit des considérations ; les détails varient selon les switches.
• Querier IGMP : équipement jouant le rôle de routeur multicast sur le segment et émettant des queries IGMP pour maintenir à jour les abonnements (source : RFC 9776). Certaines solutions (ex. Dante) documentent explicitement la nécessité de disposer d’un querier par VLAN lorsque du multicast est utilisé (source : Audinate — Recommended IGMP snooping configuration for Dante).
• QoS (Quality of Service) : mécanismes réseau qui priorisent certains paquets lors des congestions.
• DSCP : marquage dans l’en-tête IP utilisé par la QoS pour classer/prioriser les flux ; les valeurs à appliquer sont propres à chaque système et doivent suivre la documentation du protocole AV (ex. recommandations Dante : Audinate — Networks and Switches).
• PTP (Precision Time Protocol) : synchronisation d’horloge sur IP ; l’usage concret (profil, transport, modes) dépend du protocole AV et/ou du constructeur, et doit être confirmé dans la documentation de la solution (ex. recommandations Dante : Audinate — Networks and Switches).

Choisir la qualité d’image et calculer les débits avant les switches

Les systèmes AV-over-IP ne constituent pas une seule famille de produits. Certains transportent des images non compressées ou faiblement compressées pour préserver la qualité et limiter la latence ; d’autres utilisent des codecs avec des débits bien plus bas, au prix de traitements supplémentaires. Le choix dépend des usages : caméra destinée à suivre un intervenant en direct, transmission entre salles, écran d’accueil ou affichage promotionnel.

Il est donc nécessaire de demander au constructeur le débit par flux à la résolution et à la cadence réellement retenues, la latence bout en bout, le type de compression, les fonctions disponibles en multicast et les capacités des encodeurs et décodeurs. Une fiche annonçant « 4K » ne suffit pas à établir le débit du système.

Un ordre de grandeur pour comprendre la vidéo non compressée

Un calcul simplifié du seul contenu image donne : largeur × hauteur × images/seconde × bits par pixel. Pour une image 1 920 × 1 080 pixels, 60 images/seconde, couleur 4:4:4 sur 8 bits par composante (24 bits/pixel), cela représente environ 2,99 Gbit/s de données vidéo actives. Pour de la UHD 3 840 × 2 160 avec les mêmes caractéristiques, le résultat atteint environ 11,94 Gbit/s. Ces valeurs ne sont pas des débits Ethernet complets : elles excluent les enveloppes de transport et ne présument ni compression, ni chroma subsampling, ni éventuelles données annexes.

Cette comparaison montre pourquoi une vidéo compressée peut circuler sur des liens 1 Gb/s là où une distribution non compressée exige une autre classe d’infrastructure. Les débits exacts et la disponibilité des flux varient cependant selon les solutions et leurs paramètres. Il faut conserver une marge de capacité et tenir compte des autres services utilisant les mêmes uplinks.

Les flux audio demandent souvent beaucoup moins de bande passante que la vidéo, mais leur tolérance aux variations de délai (gigue), pertes et instabilités d’horloge dépend fortement du protocole, des buffers et du mode de synchronisation. Le compromis débit–qualité–latence doit donc être validé pour l’ensemble de la chaîne audiovisuelle, et non appareil par appareil.

Unicast, multicast et IGMP : choisir selon la distribution réelle

En unicast, un émetteur utilise des flux distincts à destination de plusieurs récepteurs. Cela peut convenir parfaitement à une petite installation ou à des flux audio dont la technologie privilégie ce mode. En multicast, un flux commun est envoyé à un groupe de destinataires : le réseau peut alors éviter de répliquer inutilement la même source sur chaque liaison partagée. L’intérêt devient sensible lorsqu’une source doit être distribuée vers de nombreux écrans ou zones.

L’IGMP snooping est classiquement utilisé pour limiter le flooding du multicast au niveau commutation, en s’appuyant sur les informations d’abonnement (source : RFC 4541). Mais son intérêt et ses effets concrets restent dépendants des switches, des tables disponibles, du mode de distribution de la solution AV, et de la présence (ou non) d’un querier selon l’architecture.

La documentation Audinate (Dante) précise, par exemple, des points d’attention sur le snooping/querier dans un VLAN transportant des flux multicast, ainsi que le fait qu’une configuration inadaptée peut provoquer des dysfonctionnements. Portée : ces recommandations s’appliquent à Dante et ne doivent pas être extrapolées automatiquement à d’autres écosystèmes AV.

Pour la gestion des membres multicast en IPv4, la RFC 9776 (IGMPv3) décrit le protocole IGMP. Les réseaux IPv6 emploient MLD pour un rôle analogue : IGMP ne doit pas être présenté comme le mécanisme de toutes les diffusions multicast, toutes versions IP confondues (source : RFC 4541).

Multicast « entre VLAN » : cadrage décideur (à concevoir avec l’IT)

Un VLAN et l’IGMP snooping servent surtout à organiser et limiter la diffusion dans un même domaine de commutation. Faire circuler des flux multicast au-delà (entre VLAN/sous-réseaux, ou entre zones réseau) devient une décision d’architecture : équipements de couche 3 impliqués, périmètre autorisé, sécurité, et exploitation.

Plutôt que de supposer un mécanisme unique, il est préférable de trancher dès le cadrage :

• Objectif “local” : médias cantonnés à un bâtiment/une baie/un VLAN, et seules les fonctions nécessaires (supervision, contrôle) traversent des frontières réseau.
• Objectif “multi-zones” : distribution de médias vers plusieurs étages/ailes (voire plusieurs bâtiments). Dans ce cas, l’IT doit valider la faisabilité, la surface d’exposition, les règles de filtrage et le mode d’exploitation (qui supervise et qui dépanne).

Dans tous les cas, la traversée de frontières réseau peut impacter la découverte des équipements, le contrôle et le média de manière différente : ces flux doivent être identifiés et testés, puis approuvés par l’équipe réseau.

Réseau AV dédié ou réseau convergé : choisir selon les contraintes

Un réseau dédié aux médias peut faciliter la maîtrise des capacités, des paramètres de commutation et des responsabilités d’exploitation. Un réseau partagé avec le SI peut également convenir lorsqu’il offre les fonctionnalités nécessaires, une segmentation correctement administrée et les marges suffisantes dans chaque trajet. Le choix dépend de la solution AV et des usages réels, pas d’une règle « toujours tout séparer » ou « tout mélanger ».

La préparation consiste à définir qui administre les switches, qui peut modifier les VLAN et les réglages de qualité de service, quels flux doivent traverser des baies différentes, et quel contrat d’interface s’applique entre l’intégrateur audiovisuel et l’équipe IT. L’article Domocasa sur l’architecture réseau d’un hôtel traite les usages IP du bâtiment ; ici, la particularité est le transport des médias, les abonnements de sources et la synchronisation.

Contexte d’exploitation fréquent au Maroc (hypothèses de diagnostic, à confirmer sur site)

Sans généraliser, beaucoup de projets AV-over-IP au Maroc se déroulent dans des environnements où l’exploitation est partagée : équipe IT interne, intégrateur audiovisuel, et parfois prestataires événementiels (hôtels, centres de conférence, showrooms). Dans ce contexte, les risques ne sont pas uniquement techniques : ils concernent aussi la capacité à opérer (qui a accès à quoi) et la capacité à dépanner (qui intervient, sur quel périmètre).

Autre cas courant : des bâtiments avec plusieurs baies techniques et des liaisons inter-baies hétérogènes (cuivre, fibre, débits variables). Un design AV-over-IP robuste doit expliciter où transitent les flux (uplinks, cœur, inter-baies), et si certaines zones (ex. salles de réunion) doivent continuer à fonctionner en mode dégradé en cas de coupure partielle.

Enfin, si des usages multi-sites sont envisagés (siège + succursales, diffusion vers plusieurs sites), il faut clarifier dès le cadrage si l’objectif est de transporter des flux AV en temps réel ou de s’appuyer sur d’autres mécanismes (distribution locale + contenus synchronisés), car les exigences réseau et la sécurité ne sont pas les mêmes. Ce point doit être qualifié contractuellement et validé par l’IT.

Audio sur IP, vidéo sur IP et “standards” : sécuriser le choix par des questions vérifiables

Le site IPMX décrit le cadre et les familles techniques associées, mais ne garantit pas l’interopérabilité automatique de deux produits. De manière générale, ne pas déduire une compatibilité “multi-marques” du seul terme « AV-over-IP » : exiger des matrices de compatibilité et une recette.

L’audiovisuel IP doit également être séparé logiquement des accès invités et des comptes d’administration, avec des règles adaptées aux fonctions de découverte, de média et de contrôle. Certains flux de découverte ne traversent pas spontanément les frontières entre sous-réseaux : ils nécessitent une architecture approuvée par les responsables IT et AV.

Horloges et synchronisation : adapter PTP au protocole choisi

Une installation de microphones et de haut-parleurs répartis sur plusieurs appareils nécessite souvent un alignement temporel précis pour éviter pertes d’échantillons, ruptures ou artefacts. Le protocole Precision Time Protocol (PTP) peut assurer cette synchronisation lorsque la technologie audio le prévoit. Il faut cependant distinguer la qualité d’horloge des équipements, le transport des messages de synchronisation et la latence effective du média.

Point de méthode : PTP n’est pas “une configuration unique”. Les exigences (marquage QoS, transport, compatibilités) peuvent être spécifiques à la solution AV. Par exemple, l’écosystème Dante publie des recommandations sur les switches, la QoS/DSCP et des points d’attention réseau ; ces recommandations doivent être appliquées dans leur périmètre (source : Audinate — Networks and Switches).

Dans une salle divisible, il faut tester les changements de scène, le retour de la synchronisation après incident et la cohérence entre son et image. Les réglages d’horloge ne doivent être modifiés que par une personne maîtrisant les modes de synchronisation prévus par le fournisseur et la topologie du site.

Dimensionner les switches et les uplinks à partir du scénario le plus chargé

Le dimensionnement commence par la liste des sources, des récepteurs et des chemins de distribution. Pour chaque encodeur, il faut demander le débit soutenu et de pointe du codec au format choisi. On calcule ensuite le trafic sur chaque liaison réellement traversée : un cœur réseau ne voit pas nécessairement la même charge qu’un switch d’une salle, et une diffusion multicast correcte peut limiter les répétitions sur un uplink partagé.

Exemple chiffré : quatre sources vers trois écrans

Imaginons quatre encodeurs vidéo transmettant chacun 120 Mbit/s, débit supposé et non fiche constructeur. Trois écrans situés derrière un même uplink doivent pouvoir recevoir chacun les quatre sources. Avec des flux unicast distincts franchissant cet uplink, le trafic vidéo pourrait atteindre 4 × 3 × 120 = 1 440 Mbit/s, avant les frais de protocole et les autres usages. Une liaison à 1 Gb/s ne suffirait alors pas.

Si la solution permet un multicast correctement distribué, le même uplink peut ne transporter qu’une copie de chaque flux, soit 4 × 120 = 480 Mbit/s de débit vidéo sur cette liaison, indépendamment du nombre de récepteurs situés derrière. En prenant une réserve illustrative de 25 % par rapport au débit vidéo nominal, cela représenterait environ 600 Mbit/s de capacité à considérer, avant les autres flux, pics possibles et contraintes de l’équipement. Cette réserve ne constitue ni une norme ni une garantie : le fabricant doit confirmer les débits de pointe, les comportements multicast et les limites de sa solution.

Ce cas sert à comprendre la topologie, pas à affirmer que 1 Gb/s conviendrait toujours. Le calcul doit être refait pour les vrais codecs, le nombre de médias simultanés, les trajets, le trafic informatique et les exigences de continuité. La capacité de décodage et d’affichage est elle aussi à vérifier sur chaque récepteur.

Ce que l’IT doit valider (avant achat)

• Capacité : liens réellement disponibles (1/10/25 GbE…), marges en heure de pointe, et chemins inter-baies.
• Comportement multicast : snooping/querier, limites de tables et impact attendu sur les liaisons partagées (repères : RFC 4541 ; exigences spécifiques Dante si concerné : Audinate).
• Segmentation : VLAN(s) médias, VLAN contrôle/administration, et règles de filtrage associées (repères de bonnes pratiques de sécurité réseau : DGSSI — Guide technique relatif à la sécurité des réseaux (PDF)).
• QoS / priorisation : classes et marquages à appliquer selon la technologie retenue (ex. recommandations Dante : Audinate), sans dégrader les autres services.
• Exploitation : qui administre, qui intervient en incident, et quelles sauvegardes/exports de configuration seront remis.

Points de contrôle avant l’achat

• Débits réseau : vérifier ports, uplinks, capacité réelle de transfert et compatibilité des modules optiques si plusieurs baies sont reliées.
• Multicast : vérifier IGMP snooping, le querier adapté si nécessaire, la table de groupes, les comportements de souscription et la traversée éventuelle des VLAN.
• QoS : utiliser les files de priorité et valeurs DSCP exigées par les systèmes audio et vidéo retenus, sans perturber les autres services (ex. Dante : Audinate — Networks and Switches).
• Synchronisation : contrôler les capacités et restrictions prévues par le fournisseur ; ne pas activer un mode de switch inadéquat par automatisme.
• PoE et énergie : additionner les classes de puissance des terminaux réellement alimentés, tenir compte des alimentations de secours et vérifier les pertes éventuelles.
• Exploitation : valider la supervision, les sauvegardes, les droits administrateurs et la procédure de rétablissement.

Cybersécurité et droits de commande

Les encodeurs, décodeurs et interfaces de contrôle sont des équipements IP à protéger. L’architecture doit limiter l’accès à leur administration, contrôler les mises à jour et documenter les droits des prestataires événementiels. Les invités connectés au Wi-Fi ne doivent pas disposer d’un accès non autorisé aux contrôleurs de salle.

Le guide Domocasa de cybersécurité des systèmes connectés rappelle l’importance d’identifier les flux et les comptes techniques. En complément, le guide de la DGSSI peut servir de repère méthodologique de sécurisation des réseaux (source : DGSSI — Guide technique relatif à la sécurité des réseaux (PDF)).

Lorsque des prestataires externes doivent accéder à des fonctions (événementiel, captation, diffusion), l’objectif est de définir un cadre : réseau dédié temporaire ou VLAN dédié, profils de commande limités, et procédure de retrait d’accès après l’événement. Les mesures exactes dépendent de la politique IT et doivent être validées par les responsables sécurité du site.

Recetter les médias, le réseau et les procédures d’exploitation

Une recette AV-over-IP doit simuler les usages contractuels, pas seulement constater qu’une image s’affiche. Il faut tester les modes de salle (réunion, projection, multi-écrans, espace divisible), la charge maximale prévue, les changements de source et les comportements en cas d’incident. Les temps, débits et défauts acceptables doivent être fixés dans le cahier des charges : il n’existe pas un chiffre universel de latence ou de perte convenant à tous les systèmes.

Pour un hôtel ou un showroom, la grille doit inclure au moins une personne de l’exploitation : le fonctionnement nominal ne suffit pas si seul l’installateur sait rétablir les sources après une panne. Remettre le schéma logique, la correspondance source/destination, les sauvegardes de configuration, les versions des équipements et les procédures de dépannage adaptées au système choisi.

Questions à poser (cadrage projet) à l’IT local et à l’intégrateur AV

• Périmètre : la distribution reste-t-elle dans un bâtiment/une baie, ou doit-elle traverser plusieurs étages/ailes (voire des sites) ?
• Gouvernance : qui administre les switches et qui valide VLAN/QoS ? Qui intervient en astreinte ?
• Sécurité : quels comptes/profils pour l’exploitation (réception, technique, événementiel) et quels accès pour les prestataires externes ?
• Capacité : quels uplinks sont réellement disponibles entre baies (1/10/25 GbE, cuivre/fibre), et quelles marges de trafic existent aux heures de pointe ?
• Recette : quels tests de charge et de reprise incident sont exigés, et quels livrables sont attendus en fin de projet ?

Décisions d’architecture AV-over-IP

Checklist opérationnelle

• Recenser sources, destinations et scénarios événementiels.
• Calculer débit de pointe et exigences de latence.
• Choisir unicast/multicast et, si multicast, cadrer IGMP snooping/querier selon la plateforme et la solution.
• Dimensionner switches, uplinks, PoE et liaisons inter-baies.
• Définir VLAN, droits de commande et politiques de maintenance.
• Tester les configurations divisibles et la bascule des sources.
• Remettre schémas, paramètres et procédure de secours.

Questions fréquentes

Peut-on utiliser le switch réseau de l’hôtel ?

Parfois, si ses fonctionnalités et réserves de capacité répondent aux protocoles AV retenus et si les règles d’exploitation sont claires.

AV-over-IP est-il identique à IPTV ?

Non. Les usages peuvent partager des principes IP, mais les contraintes de latence, de contrôle, de compression et d’interopérabilité varient.

Le Wi-Fi peut-il transporter tous les flux ?

Cela dépend du débit et des délais exigés. Les systèmes professionnels s’appuient souvent sur des liaisons filaires pour leurs fonctions structurantes.

Références techniques et standards à consulter

• IETF — RFC 4541, IGMP/MLD Snooping Switches : considérations, bénéfices et précautions autour du snooping multicast.
• IETF — RFC 9776, IGMPv3 : protocole de gestion d’appartenance multicast en IPv4.
• Audinate — Recommended IGMP snooping configuration for Dante : cas d’usage et précautions de configuration (périmètre Dante).
• Audinate — Networks and Switches : recommandations QoS/DSCP et considérations réseau (périmètre Dante).
• IPMX — site officiel : cadre et objectifs des spécifications IPMX.
• DGSSI (Maroc) — Guide technique relatif à la sécurité des réseaux (PDF) : repères de bonnes pratiques de sécurité réseau.

Ces références décrivent des technologies différentes : elles aident à établir un cahier des charges, mais ne garantissent pas la compatibilité de deux produits particuliers. Les contraintes exactes doivent être confirmées dans les documents des fabricants retenus et pendant la recette.

Conclusion : concevoir l’audiovisuel comme un service réseau

Une architecture AV-over-IP réussie ne commence pas par la marque d’un encodeur. Elle part des besoins de diffusion, des destinations, des débits et de la latence acceptables. Elle intègre ensuite la distribution des flux, les contraintes de synchronisation, la supervision et les responsabilités entre les équipes IT et audiovisuelles.

Dans un showroom, une salle de conférence ou un hôtel, la qualité de service repose autant sur une architecture mesurable que sur la capacité de l’équipe d’exploitation à changer de source et à rétablir le fonctionnement après un incident. Pour approfondir la dimension d’usage, voir également notre guide sur l’affichage digital multi-écrans.

Prochaine étape : cadrer l’audit et les livrables attendus

Pour rester cohérent avec l’approche « service réseau », un accompagnement peut se cadrer autour de livrables tels que : schéma de flux, matrice source/destination, hypothèses de débits et dimensionnement, principes VLAN/QoS (selon politiques IT), protocole de recette et dossier d’exploitation (sauvegardes, procédures de reprise, droits de commande). Le périmètre exact doit être défini au cas par cas.

Étudier votre architecture audiovisuelle avec Domocasa