Pendant des décennies, transporter des canaux audio d’un point à un autre voulait dire tirer du cuivre : une paire par signal, un multipaire pour une scène, des mètres de câble et des connecteurs par dizaines. Le numérique a d’abord densifié ce transport avec des liaisons comme le MADI, puis le monde entier a fini par converger vers la même idée que l’informatique : faire passer tout cela sur un simple réseau Ethernet. C’est l’audio sur IP. Derrière ce terme se cachent plusieurs technologies aux noms qui reviennent sans cesse — Dante, AES67, Ravenna, SMPTE ST 2110 — et qu’on confond facilement. Ce guide remet chaque brique à sa place.
Qu’est-ce que l’audio sur IP, au juste ?
L’audio sur IP consiste à transporter des canaux audio numériques, généralement non compressés et de qualité studio, dans des paquets qui circulent sur un réseau Ethernet standard, exactement comme le fait votre trafic informatique. Un seul câble réseau peut alors véhiculer des dizaines, voire des centaines de canaux dans les deux sens. Les avantages sont considérables : un câblage radicalement simplifié, des distances qui se comptent en centaines de mètres sur fibre, un routage entièrement logiciel (n’importe quelle entrée vers n’importe quelle sortie, sans re-câbler), et la possibilité de bâtir une redondance complète en doublant le réseau.
Cette logique prolonge naturellement ce que les consoles numériques font déjà en interne. Si la notion de routage et de bus vous est familière, l’audio sur IP n’en est que l’extension à l’échelle d’un bâtiment entier : le patch cesse d’être un panneau physique pour devenir une matrice virtuelle que l’on reconfigure d’un clic.
Dante, AES67, ST 2110 : qui fait quoi
La première source de confusion tient à ce que ces noms ne désignent pas la même catégorie de choses. Dante, développé par la société Audinate, est une solution propriétaire complète : protocole de transport, découverte automatique des appareils et logiciel de routage (Dante Controller). C’est aujourd’hui la technologie la plus répandue, précisément parce qu’elle fonctionne en « plug-and-play » : on branche, les appareils se voient, on route. Sa domination sur le marché du live et de l’installation est écrasante.
AES67, à l’inverse, n’est pas un produit mais une norme d’interopérabilité publiée par l’Audio Engineering Society. Son rôle n’est pas de remplacer Dante ou Ravenna, mais de leur fournir un terrain d’entente : un ensemble de règles communes (synchronisation, format des paquets, adressage) permettant à des équipements de marques et d’écosystèmes différents d’échanger des flux audio. Dante, Ravenna, Livewire+ savent tous parler AES67 : c’est la langue véhiculaire du secteur.
SMPTE ST 2110 vient du monde de la vidéo professionnelle et du broadcast télé. C’est une suite de normes qui transporte séparément, sur le même réseau IP, les « essences » d’un programme : la vidéo, l’audio et les données auxiliaires, chacune dans son propre flux. La partie audio de ST 2110 (le document ST 2110-30) s’appuie directement sur AES67 — autrement dit, le broadcast TV a bâti son standard audio sur les fondations posées par l’audio pro. Ravenna, enfin, est une technologie ouverte très présente en radio et en broadcast (on la retrouve chez des fabricants comme Lawo ou DHD), elle aussi compatible AES67.
| Standard | Nature | Terrain de prédilection | Compatible AES67 |
|---|---|---|---|
| Dante | Solution propriétaire complète | Live, installation, studio | Oui (mode AES67 activable) |
| AES67 | Norme d’interopérabilité | Passerelle entre écosystèmes | Par définition |
| Ravenna | Technologie ouverte | Radio, broadcast | Oui |
| SMPTE ST 2110 | Suite de normes broadcast | Télévision, production vidéo | Oui (audio via ST 2110-30) |
Les fondations techniques qui comptent vraiment
Sous ces noms commerciaux, deux notions techniques conditionnent tout. La première est la synchronisation d’horloge. Pour que des flux audio venus de partout restent parfaitement alignés, tous les appareils doivent partager une même référence temporelle, distribuée sur le réseau par le protocole PTP (Precision Time Protocol, norme IEEE 1588). Un appareil fait office d’« horloge maître » (grandmaster) et tous les autres s’y asservissent. Une horloge mal configurée, et le réseau se met à cracher des clics et des décrochages : c’est la première chose à vérifier quand un système IP se comporte mal.
La seconde notion est le multicast. Plutôt que d’envoyer une copie du flux à chaque destinataire, un émetteur diffuse une seule fois et le réseau distribue à ceux qui s’abonnent. C’est terriblement efficace, mais cela impose des switches réseau gérés, capables d’encadrer ce trafic (via l’IGMP snooping) et de prioriser l’audio par une politique de qualité de service. On touche là au point le plus important pour un ingénieur du son qui se lance : un réseau audio sur IP n’est pas un réseau bureautique. On ne branche pas des flux critiques sur le premier switch venu.
Ce qu’il faut réunir pour déployer
- Des switches managés correctement configurés (IGMP snooping, QoS), et surtout l’option d’économie d’énergie (EEE) désactivée, ennemie jurée du PTP.
- Un plan de synchronisation clair : une horloge maître désignée, une horloge de secours.
- Un plan d’adressage et, souvent, un VLAN dédié pour isoler l’audio du reste du trafic.
- Pour les usages critiques, une redondance à deux réseaux physiquement séparés (le principe du ST 2022-7, qui envoie deux copies et bascule sans coupure).
Pourquoi le broadcast bascule le premier
La radio et la télévision sont en première ligne de cette transition, et pour de bonnes raisons. Un bâtiment de diffusion, ce sont des dizaines de studios, de régies et de points de captation à interconnecter, avec une exigence de fiabilité absolue et un besoin de redondance permanent. L’IP y répond mieux que n’importe quel câblage figé. L’exemple du Concert de Paris et de la régie tout-IP redondante de Radio France l’illustre parfaitement : un réseau doublé, un routage logiciel, et la capacité de reconfigurer un système entier sans toucher un seul câble. Ajoutez à cela les contraintes de normalisation du loudness propres à la diffusion, et l’on comprend pourquoi ce secteur a été un moteur de l’adoption.
La convergence audio-vidéo accélère encore le mouvement : dès lors qu’une console pense l’audio et la vidéo ensemble, transporter les deux sur la même infrastructure IP devient la suite logique.
Faut-il y passer ?
Pour la scène et le studio, la réponse dépend de l’échelle. Sur un petit set-up, un réseau IP peut être une complexité inutile, et un bon vieux lien numérique point à point suffit largement. Mais dès que vous routez beaucoup de canaux entre plusieurs machines, plusieurs salles ou plusieurs régies, l’audio sur IP devient rapidement imbattable — c’est d’ailleurs une des raisons qui font pencher la balance dans le débat analogique contre numérique.
Mon conseil, après avoir vu passer des régies de toutes tailles : ne sous-estimez jamais la partie réseau. La qualité sonore de l’audio sur IP est irréprochable — on transporte des échantillons intacts, il n’y a pas de « couleur du câble » à débattre ici. Le vrai sujet, c’est la rigueur : une horloge PTP propre, des switches à la hauteur, un plan d’adressage carré. Un système IP bien conçu est d’une fiabilité déconcertante ; un système bâclé vous lâchera au pire moment. Investissez le temps qu’il faut dans le réseau, pas seulement dans les têtes de série qui s’y branchent.
Retenez l’essentiel : Dante pour la simplicité clé en main, AES67 comme langue commune qui garantit l’interopérabilité, ST 2110 quand la vidéo entre dans l’équation, Ravenna dans l’univers radio. Ces mondes ne s’excluent pas — ils s’emboîtent, et c’est précisément AES67 qui joue le rôle de ciment. Comprendre cette architecture, c’est se donner les moyens de choisir la bonne brique pour le bon usage, plutôt que de subir un vocabulaire marketing qui brouille des concepts au fond assez logiques.
