La génération de feed DDEX est le processus par lequel une sortie musicale et ses métadonnées sont converties en un message XML standardisé que les plateformes de streaming peuvent lire automatiquement. Le format est l’ERN (Electronic Release Notification) de DDEX, et il contient tout ce dont un DSP a besoin pour publier une sortie : titres et artistes, ISRC, références vers la pochette et les fichiers audio, ainsi que les territoires et les conditions commerciales applicables. Générer ce feed correctement est ce qui permet à votre musique d’être livrée sans ressaisie manuelle.
Ce guide explique ce que contient un message ERN, comment fonctionne la génération de feed étape par étape, la différence entre ERN 3.8.2 et 4.3, et comment évaluer un prestataire qui s’en charge à votre place – y compris où s’inscrit LabelGrid.
Qu’est-ce que DDEX et pourquoi est-ce important pour la distribution ?
DDEX (Digital Data Exchange) est un organisme de normalisation à but non lucratif, fondé en 2006, qui définit les formats de messages XML de la chaîne d’approvisionnement de la musique numérique. Labels, distributeurs, DSP, éditeurs et sociétés de gestion collective s’en servent pour échanger automatiquement des données de sorties, de droits et de ventes, sans développer une intégration sur mesure pour chaque partenaire (À propos de DDEX). Pour la distribution, le standard qui compte est l’ERN (Electronic Release Notification) : le message qui transmet à un DSP une nouvelle sortie, les références à ses fichiers audio et à sa pochette, ainsi que ses conditions commerciales.
LabelGrid livre les sorties aux DSP sous forme de messages DDEX-ERN et prend en charge les versions ERN 3.8.2, 4.3.0, 4.3.1 et 4.3.2. LabelGrid n’est pas membre de DDEX, et l’adhésion n’est pas nécessaire pour implémenter les standards : n’importe qui peut le faire avec la licence d’implémentation gratuite de DDEX (standards DDEX). Le vrai travail – et la partie que la plupart des labels préfèrent ne pas assumer eux-mêmes – consiste à générer des feeds ERN valides et à les tenir à jour à mesure que les exigences de chaque DSP évoluent.
Qu’est-ce qu’un feed DDEX-ERN ?
Un feed ERN est un document XML qui décrit une sortie et sa disponibilité. Le message central est le NewReleaseMessage, et il regroupe trois éléments dont un DSP a besoin ensemble : les ressources, la sortie et les conditions.
- ResourceList contient les enregistrements sonores ainsi que les éventuelles vidéos ou images, chacun assorti d’identifiants (ISRC pour les titres) et de détails techniques.
- ReleaseList est la sortie elle-même : titre, artiste affiché, nom du label, UPC, genre, date de publication.
- DealList fixe les conditions commerciales, notamment quels territoires et plateformes la reçoivent, le calendrier de publication ainsi que l’éventuelle fenêtre de précommande.
Les maisons de disques et les distributeurs envoient ces messages aux DSP ; le DSP parse le feed et publie la sortie selon les conditions du deal (documentation DDEX-ERN). Un retrait, une correction de métadonnées ou un nouveau territoire devient à chaque fois un message distinct dans le même format. Une violation du schéma ou un champ obligatoire manquant suffit à faire rejeter la livraison – c’est pourquoi la validation est tout aussi importante que la génération.
Comment fonctionne la génération de feed DDEX ?
La génération de feed prend vos données de sortie et produit un paquet ERN prêt pour les DSP. Une pipeline typique se déroule ainsi :
- Collecter les métadonnées. Champs de la sortie et des titres, contributeurs, identifiants (ISRC, UPC), territoires et indications explicit.
- Référencer les ressources. Les fichiers audio, transcodés selon la spécification de chaque DSP, et les pochettes qui respectent les exigences de taille (typiquement un master carré de 3000x3000px) sont rattachés en tant que ressources.
- Valider. Le feed est vérifié par rapport au schéma DDEX et au profil propre du DSP cible avant que quoi que ce soit ne soit envoyé. Les lignes de copyright manquantes, les ISRC erronés ou les pochettes trop petites sont détectés ici.
- Générer l’XML ERN. Le
NewReleaseMessageest créé avec la bonne version (3.8.2 ou 4.3) pour la cible. - Livrer. Le paquet est transmis à chaque DSP et une confirmation est renvoyée.
- Gérer les mises à jour. Les corrections, retraits et nouveaux territoires sont envoyés sous forme de messages de suivi rattachés à la même sortie.
La raison pour laquelle ce n’est pas une entreprise triviale : en 2024, environ 99 000 nouveaux titres étaient livrés chaque jour aux services de streaming (Luminate 2024 Year-End Report). Personne ne code du XML à la main à ce volume. LabelGrid prend en charge la génération de feed DDEX de bout en bout, génère et valide l’ERN par rapport au profil actuel de chaque DSP et livre à toutes les grandes plateformes – afin que les labels et les distributeurs expédient des sorties au lieu de construire et maintenir un moteur de feed.
ERN 3.8.2 vs. ERN 4.3 : quelle version les DSP utilisent-ils ?
Deux générations d’ERN restent en usage. ERN 3.8.2 subsiste dans des intégrations DSP existantes, même si DDEX a mis fin au support de toutes les versions d’ERN 3 le 1er mars 2025. ERN 4.3.x est la génération actuelle, et DDEX conseille d’en implémenter la version la plus récente. Elles ne sont pas interchangeables. Un moteur de feed doit parler la version précise que chaque DSP attend.
| Aspect | ERN 3.8.2 | ERN 4.3.x |
|---|---|---|
| Statut | Ancienne version ; support DDEX arrêté le 1er mars 2025 | Actuelle ; DDEX conseille d’implémenter la version la plus récente |
| Données territoriales | Les blocs DetailsByTerritory répètent les titres par territoire | Surcharges territoriales uniquement là où les données diffèrent réellement |
| Contributeurs | Artistes et auteurs répétés dans l’ensemble du message | Définis une seule fois dans la PartyList, référencés par ID |
| Sorties par titre | Structure de sortie complète avec champs redondants | Composite TrackRelease allégé |
| Taille du message | Plus volumineux, en raison de la duplication | Plus léger, dédupliqué |
| Spatial Audio | Prise en charge limitée de l’audio immersif | Prise en charge complète de l’audio immersif, ajoutée en 4.3 |
Ce qu’il faut retenir en pratique : les intégrations ERN 3 existantes perdurent, car passer d’ERN 3 à 4 implique de restructurer tout le modèle de données territoriales, ERN 4 ayant supprimé les blocs DetailsByTerritory. Les fonctionnalités plus récentes, dont la prise en charge complète de l’audio immersif et la déduplication PartyList, nécessitent ERN 4. Un prestataire qui en vaut la peine prend en charge les deux et choisit la bonne version selon la cible. LabelGrid livre en DDEX ERN 3.8.2, 4.3.0, 4.3.1 et 4.3.2. L’import DDEX, qui permet d’intégrer vos propres livraisons ERN dans LabelGrid, est disponible avec les offres API et Custom Distribution.
L’importance de réussir la livraison ne cesse de croître. Le streaming a atteint en 2025 une part de 69,6 % des revenus mondiaux de la musique enregistrée, avec 837 millions d’abonnés payants (IFPI Global Music Report 2026). Un feed rejeté ou erroné signifie une visibilité perdue sur le canal où se trouve aujourd’hui le plus d’argent.
Passez l’ingénierie ERN
LabelGrid génère des feeds ERN 3.8.2 et 4.3 valides et les tient à jour à mesure que les exigences des DSP évoluent.
Voir les plansQue faut-il rechercher dans un service de génération de feed DDEX ?
Si vous choisissez un prestataire qui génère les feeds, plutôt que de construire votre propre solution, voici la checklist qui compte.
| Critère | À quoi ressemble un bon résultat |
|---|---|
| Plusieurs versions d’ERN | À la fois 3.8.2 et 4.3.x, sélectionnées par DSP, et non selon le principe du « one size fits all ». |
| Validation avant la livraison | Vérifications de schéma et de profil propres à chaque DSP, qui détectent les erreurs avant la livraison, et non après le rejet. |
| Maintenance des spécifications | Le prestataire suit les modifications des profils DSP, afin que vos feeds ne se cassent pas silencieusement. |
| Transcodage audio | Les fichiers sont encodés selon la spécification de chaque plateforme dans le cadre de la pipeline. |
| Retraits et mises à jour | Les corrections, changements de territoire et retraits sont gérés comme de véritables messages de suivi. |
| Accès API | Livraison et statut programmatiques, afin que la génération de feed puisse s’exécuter au sein de vos propres systèmes. |
| Prise en charge SOBO | La possibilité de livrer sous vos propres contrats DSP, lorsque vous détenez des contrats directs. |
Comment livrer de la musique via DDEX : le guide étape par étape
- Décider entre construire ou acheter. Maintenir un moteur ERN et suivre chaque modification d’un profil DSP représente un effort d’ingénierie réel et continu. Pour la plupart des labels et distributeurs, recourir à un prestataire est la décision rationnelle.
- Confirmer la couverture des versions. Assurez-vous que le prestataire génère à la fois ERN 3.8.2 et 4.3.x et achemine la bonne version vers chaque DSP.
- Préparer des métadonnées propres. ISRC et UPC corrects, lignes de copyright exactes et pochette conforme à la spécification. Des entrées propres sont ce qui fait passer la validation.
- Valider avant la livraison. Faites passer le feed par les vérifications de schéma et propres à chaque DSP. Corrigez ce qui est signalé avant tout envoi.
- Livrer et confirmer. Transmettez à chaque DSP et surveillez les confirmations. Suivez quelles plateformes ont accepté la sortie.
- Maintenir le catalogue. Envoyez les corrections, nouveaux territoires et retraits sous forme de messages de suivi, et gardez un œil sur les feeds lorsque les spécifications DSP changent.
LabelGrid intervient à chacune de ces étapes avec une génération de feed DDEX complète sur ERN 3.8.2, 4.3.0, 4.3.1 et 4.3.2, une validation avant la livraison, le transcodage audio et la livraison à tous les grands DSP. Pour les équipes qui souhaitent l’exécuter de manière programmatique, la même pipeline est disponible via l’API REST de LabelGrid avec sandbox et documentation publique. LabelGrid est Spotify Preferred Provider et membre de Merlin Network. Il tient les feeds à jour à mesure que les exigences des plateformes évoluent.
Génération de feed DDEX : l’essentiel
La génération de feed DDEX convertit une sortie en un message ERN standardisé – le NewReleaseMessage, qui porte les ressources, les données de la sortie et les conditions du deal – que les DSP lisent automatiquement. Les deux versions encore utilisées sont ERN 3.8.2 (ancienne, support DDEX arrêté en mars 2025) et 4.3.x (actuelle, plus légère, avec une prise en charge complète de l’audio immersif), et un bon prestataire parle les deux, valide avant la livraison et suit les modifications des spécifications DSP. Construire son propre moteur représente une charge de maintenance continue ; pour la quasi-totalité des acteurs, un prestataire qui prend en charge le feed de la génération à la livraison, validation comprise, est le meilleur choix. LabelGrid prend en charge la livraison DDEX pour les labels et les distributeurs sur les quatre versions ERN prises en charge, avec accès API et SOBO pour les catalogues sous contrat direct.
Questions fréquentes
Qu’est-ce qu’un feed DDEX ?
Un feed DDEX est un message XML standardisé, le plus souvent un ERN NewReleaseMessage, qui décrit une sortie musicale et sa disponibilité pour les DSP. Il porte les ressources audio et image, les métadonnées de la sortie et les conditions du deal (territoires, calendrier, plateformes) dans un paquet que le DSP peut lire automatiquement.
Quelle est la différence entre ERN 3.8.2 et ERN 4.3 ?
ERN 3.8.2 est une ancienne version : DDEX a cessé de la prendre en charge le 1er mars 2025, mais certaines intégrations DSP l’utilisent encore. Elle répète des données comme les titres à travers les blocs de territoires. ERN 4.3.x est la version actuelle que DDEX conseille d’implémenter : elle déduplique les contributeurs dans une PartyList, n’envoie les données territoriales que là où elles diffèrent, ajoute un composite TrackRelease allégé et prend entièrement en charge le Spatial Audio comme Dolby Atmos. LabelGrid prend en charge les deux.
Dois-je générer les feeds DDEX moi-même ?
Non. La plupart des labels et distributeurs n’en ont pas besoin : un prestataire peut générer, valider et livrer les feeds ERN aux DSP. Construire son propre moteur implique d’écrire de l’XML ERN valide, de valider par rapport au profil de chaque DSP et de suivre chaque modification de spécification au fil du temps. C’est de l’ingénierie continue qui ne se justifie qu’à grande échelle.
LabelGrid est-il membre de DDEX ?
Non. LabelGrid n’est pas membre du consortium DDEX, et l’adhésion à DDEX n’est pas nécessaire pour implémenter le standard. LabelGrid implémente DDEX ERN et prend en charge les versions 3.8.2, 4.3.0, 4.3.1 et 4.3.2 pour la livraison. L’import DDEX est disponible avec les offres API et Custom Distribution.
Qu’est-ce que le SOBO dans la livraison DDEX ?
SOBO signifie « sent on behalf of » (envoyé pour le compte de). C’est une directive DDEX qui établit que le concédant de licence d’une sortie est le client, et non le distributeur. Elle permet à un label ou à un distributeur qui détient ses propres contrats DSP directs de livrer via une plateforme comme LabelGrid tout en laissant intactes la relation directe et les conditions de redevances.
Quelle version d’ERN un nouveau catalogue devrait-il utiliser ?
DDEX conseille d’implémenter la version la plus récente, ERN 4.3.x. Plus légère et dédupliquée, elle prend entièrement en charge le Spatial Audio ainsi que des crédits plus riches. Certaines intégrations DSP fonctionnent encore avec ERN 3.8.2, c’est pourquoi un bon prestataire livre la bonne version selon la cible. LabelGrid s’en charge automatiquement sur les quatre versions prises en charge.
