Codes ISRC expliqués : pourquoi ils sont importants pour les droits musicaux et le suivi des royalties

Le code ISRC music est l’identifiant standard de l’industrie qui relie un enregistrement sonore spécifique aux systèmes de reporting, de suivi et de royalties. Ce guide technique décompose le format ISRC à 12 caractères, qui délivre les codes d’enregistrement, comment les ISRC circulent dans les livraisons DDEX et DSP, et les règles pratiques pour la validation, les remasters et la résolution des royalties orphelines.

Format et composants de l’ISRC

Information essentielle : un ISRC est un identifiant rigide à 12 caractères divisé en quatre parties qui, ensemble, créent une balise unique au niveau mondial pour une instance d’enregistrement spécifique. Les parties sont le code pays, le code d’enregistrement, l’année de référence à deux chiffres et le code de désignation à cinq chiffres. Les systèmes doivent stocker la forme canonique (majuscules, sans tirets) et traiter la présence de tirets uniquement comme une présentation.

Structure et signification de chaque segment

• Code pays (2 caractères) : lettres alpha-2 ISO 3166-1 indiquant la région de l’agence ISRC nationale qui a délivré le code d’enregistrement.
• Code d’enregistrement (3 caractères) : code alphanumérique attribué par l’agence nationale à un label, un distributeur ou un autre déclarant ; combiné au pays pour identifier l’émetteur.
• Année de référence (2 chiffres) : l’année où l’ISRC a été attribué (format à deux chiffres) ; utilisé pour suivre le moment où l’identifiant est entré dans le système, et non la propriété.
• Code de désignation (5 chiffres) : un numéro séquentiel que le déclarant émet pour identifier les enregistrements individuels sous son préfixe de déclarant.

Exemple concret : US-A1B-20-00001 se décompose comme suit : US = agence des États-Unis, A1B = code de déclarant, 20 = année d’attribution 2020, 00001 = première désignation. En pratique, vous le verrez stocké sous la forme USA1B2000001 ou avec des tirets pour faciliter la lecture ; considérez les deux comme le même ID canonique.

Règle de validation pour l’ingestion : normalisez les valeurs entrantes en supprimant les espaces, en mettant en majuscules et en supprimant les caractères non alphanumériques ; puis validez par rapport à un modèle strict tel que ^[A-Z]{2}[A-Z0-9]{3}[0-9]{2}[0-9]{5}$. Remarque : exigez que les deux premiers caractères soient des lettres correspondant à la norme ISO 3166-1 dans la mesure du possible et croisez le code de déclarant avec le portail ISRC de l’IFPI lorsque vous le pouvez.

Compromis pratique : l’application de lettres de pays ISO strictes réduit les ISRC mal formés et faux, mais rejettera quelques variantes héritées ou attribuées par le fournisseur que les systèmes acceptent toujours. D’après mon expérience, le bon équilibre est une validation stricte plus un flux de travail d’exception : signalez et mettez en quarantaine les ISRC suspects pour une vérification manuelle au lieu de les accepter automatiquement.

Comment l’ISRC s’articule avec d’autres identifiants : l’ISRC identifie l’instance d’enregistrement ; un ISWC identifie l’œuvre musicale sous-jacente ; un UPC ou un EAN identifie la sortie du produit commercial. Une seule sortie peut comporter un UPC, répertorier plusieurs ISRC pour chaque piste et référencer les ISWC pour les compositions. Assurez-vous que votre modèle d’ingestion stocke les trois et les relie au même enregistrement principal pour éviter les discordances de division et de royalties.

Stockez les ISRC sous forme canonique (majuscules, 12 caractères, sans tirets) et validez par rapport aux listes de déclarants ; le formatage de présentation est secondaire.

Application concrète : lorsqu’un distributeur livre un nouveau master, votre pipeline d’ingestion doit rejeter ou signaler les enregistrements auxquels il manque un ISRC valide et exiger un champ isrc canonique avant de créer un ID master. Cela empêche les pistes orphelines d’entrer dans les systèmes de reporting et permet d’économiser des semaines de rapprochement par rapport aux rapports de lecture DSP.

Jugement : la validation et la normalisation sont des contrôles à faible effort et à fort impact. Les équipes qui sautent la canonisation chasseront les doublons et les revenus orphelins plus tard ; la mise en œuvre de la liste de contrôle ci-dessus empêche les échecs de rapprochement courants et rend les livraisons DDEX en aval et la correspondance DSP fiables. Considération suivante : vérifiez qui a émis le préfixe de déclarant avant d’accepter un ISRC dans votre registre master canonique.

Qui délivre les ISRC et les flux de travail d’attribution

Réponse directe : les agences ISRC nationales délivrent des préfixes de déclarant ; les labels, les distributeurs ou les déclarants détenant ce préfixe attribuent les ISRC à 12 caractères aux masters individuels. ISRC code music dépend de cette chaîne en deux étapes : l’agence délivre le code de déclarant, le déclarant délivre les codes de désignation.

Émetteurs et arrangements courants

Agences nationales : les organismes énumérés par l’IFPI administrent les préfixes de déclarant pour les pays (par exemple, RIAA est le contact aux États-Unis et PPL gère les flux opérationnels au UK). De nombreuses agences publient des formulaires de demande et des règles sur le portail ISRC de l’IFPI.

Déclarants tiers : les distributeurs et certains agrégateurs détiennent des codes de déclarant et attribuent des ISRC au nom de leurs clients. Ceci est pratique pour les indépendants, mais transfère le contrôle opérationnel des numéros de désignation au distributeur et complique la portabilité si vous changez de service par la suite.

Flux de travail d’attribution pratique (pour les équipes et les systèmes)

1. Obtenez l’accès au déclarant : adressez-vous à votre agence nationale ou passez un contrat avec un distributeur qui détient un préfixe de déclarant. Conservez la documentation du préfixe émis et le contact de l’agence.
2. Créez un enregistrement master : avant d’attribuer un ISRC, capturez les métadonnées requises telles que le titre de l’enregistrement, l’interprète principal, la date d’enregistrement, les notes de version (remaster/remix) et le label propriétaire. Stockez une entrée d’audit horodatée enregistrant qui a attribué le code.
3. Émettez le code de désignation : combinez votre préfixe de déclarant et un numéro de désignation séquentiel pour former l’ISRC complet ; utilisez un générateur déterministe afin que les affectations soient uniques (pas de numérotation manuelle ad hoc).
4. Enregistrez la provenance : écrivez l’ISRC canonique (majuscules, 12 caractères, sans tirets) dans votre registre master, incluez le préfixe de déclarant, la date d’attribution et le nom de l’agent ; exportez ceci dans les champs DDEX ERN au moment de la livraison.
5. Livrez et rapprochez : incluez l’ISRC dans toutes les livraisons et enregistrements DSP (par exemple, à SoundExchange le cas échéant), et rapprochez les rapports de lecture entrants avec votre registre master chaque semaine ou chaque mois.

Compromis à prendre en compte : la possession d’un préfixe de déclarant vous donne un contrôle à long terme et des pistes d’audit plus propres, mais elle nécessite une gouvernance : gestion des séquences, sauvegardes et responsabilité de la correction des erreurs. L’utilisation d’un ISRC attribué par un distributeur est plus rapide, mais conduit souvent à une provenance embrouillée lorsque vous déplacez des catalogues.

Exemple concret : un petit label s’est adressé à l’agence américaine, a reçu un préfixe de déclarant et a mis en œuvre un script interne pour générer des numéros de désignation. Lorsqu’un distributeur a ensuite livré une compilation et a accidentellement réutilisé un numéro de désignation, le journal d’audit du label a permis de prouver trivialement l’attribution correcte et d’amener le DSP à corriger l’ingestion, sans ouvrir de litige de royalties.

Si vous acceptez l’attribution d’ISRC d’un distributeur, insistez sur une exportation lisible par machine de chaque ISRC attribué et de ses métadonnées ; sans cela, vous perdez la possibilité d’auditer ou de récupérer des pistes lorsque vous changez de service.

Jugement : pour la plupart des indépendants, le chemin pragmatique commence par les ISRC attribués par le distributeur, mais chaque artiste ou label qui s’attend à évoluer devrait prévoir d’obtenir son propre préfixe de déclarant dans les 12 mois. Le coût administratif supplémentaire est rentable en termes de portabilité et de résolution des litiges plus rapide.

Considération suivante : après avoir décidé qui attribue les ISRC pour votre catalogue, créez un point de terminaison d’audit simple qui renvoie l’historique des attributions pour tout ISRC ; cette API unique élimine la plupart des escalades de rapprochement et accélère les corrections DDEX ERN lorsque les services signalent des discordances. Pour les modèles de mise en œuvre, consultez les conseils DDEX ERN et nos notes opérationnelles sur l’ingestion de métadonnées chez UniteSync.

Comment l’ISRC circule dans les systèmes de l’industrie et affecte les royalties

Point direct : l’ISRC fonctionne comme la clé primaire opérationnelle qui relie un master enregistré à travers les pipelines d’ingestion, les catalogues DSP, les manifestes de sociétés de perception et les enregistrements de paiement. Lorsqu’un master porte un ISRC canonique lors de la livraison, les systèmes en aval peuvent faire correspondre les lectures et générer des événements de paiement sans intervention humaine.

Les ISRC voyagent en trois étapes pratiques : attribués et stockés dans votre registre master ; intégrés dans les packages de livraison (par exemple via DDEX ERN) aux DSP et aux plateformes ; et présents sur les rapports d’utilisation et les manifestes renvoyés par ces services. Les systèmes utilisent l’ISRC pour agréger les nombres de flux à un seul enregistrement master, puis les couches comptables appliquent les règles de propriété et de division tirées d’autres métadonnées et enregistrements.

Limitation importante : l’ISRC lie l’activité à une instance d’enregistrement, mais ne porte pas la propriété, les divisions d’éditeur ou les instructions de paiement. Cette séparation est la cause première de nombreux problèmes de royalties : des ISRC précis accélèrent la correspondance automatisée, mais sans métadonnées de propriété correctement enregistrées, vous avez toujours besoin d’un rapprochement manuel pour acheminer l’argent.

Comment la correspondance échoue dans la nature

Les plateformes se rabattent sur des heuristiques imparfaites lorsque les ISRC sont manquants ou mal formés. La correspondance titre/artiste, les références croisées UPC ou les correspondances d’empreintes digitales peuvent fonctionner, mais elles augmentent à la fois les faux positifs et les faux négatifs. En pratique, cela signifie un paiement retardé, des revenus orphelins et un travail supplémentaire pour reconstruire ce qui a été diffusé.

• Comportements courants en aval : les DSP agrègent par ISRC pour le reporting ; YouTube Content ID donne la priorité à l’empreinte digitale + aux métadonnées et monétisera l’actif que le système juge le mieux adapté ; les sociétés de perception utilisent les ISRC dans les manifestes, mais exigent des enregistrements distincts pour les bénéficiaires.
• Stratégie de jointure pratique : faites correspondre les enregistrements d’utilisation par ISRC en premier, puis rapprochez les lignes non appariées à l’aide de l’empreinte audio et des correspondances croisées UPC/ISWC pour réduire les orphelins.

Exemple concret : un label publie un remix avec un nouvel ISRC. Les plateformes de streaming enregistrent ces lectures par rapport à l’ISRC du remix et les renvoient dans les relevés. Si l’éditeur oublie d’enregistrer la division du remix auprès de SoundExchange ou de soumettre les métadonnées appropriées au DSP, les lectures seront mises en correspondance avec le master, mais les paiements resteront non attribués jusqu’à ce que les enregistrements soient corrigés, ce qui nécessite souvent des réclamations rétroactives.

La prise d’empreintes digitales aide, mais n’est pas une panacée : elle détecte les correspondances audio lorsque les métadonnées sont absentes, mais les systèmes d’empreintes digitales peuvent confondre des enregistrements similaires et sont coûteux à exploiter à grande échelle. La solution pragmatique est la correspondance en couches (ISRC en premier, puis les empreintes digitales, puis l’examen humain des exceptions) plutôt que de dépendre d’une seule méthode.

Étapes opérationnelles que vous pouvez mettre en œuvre dès aujourd’hui : créez votre ingestion pour rejeter les livraisons dépourvues d’un champ ISRC canonique, exportez l’ISRC dans chaque champ DDEX ERN ResourceReference ou équivalent lorsque vous livrez, automatisez le rapprochement hebdomadaire des manifestes DSP avec votre registre master par ISRC et conservez un journal de provenance horodaté indiquant qui a attribué chaque code et quand.

Jugement : les équipes qui donnent la priorité à la livraison cohérente des ISRC et à une boucle de rapprochement simple récupèrent la plus grande part des revenus perdus avec un minimum d’efforts. Si vous ne pouvez corriger qu’un seul pipeline, faites-en le transfert ISRC de votre registre master dans la livraison DDEX et le rapprochement DSP hebdomadaire qui suit.

Normes de métadonnées et intégration du développeur

Point d’intégration direct : l’ISRC est la clé d’ancrage dans les pipelines de livraison et de rapprochement ; les développeurs doivent le traiter comme un identifiant stable qui voyage dans plusieurs couches de métadonnées, et non comme un simple champ cosmétique. Capturez l’ISRC canonique tôt, propagez-le inchangé dans chaque package de livraison et utilisez-le comme clé de jointure principale pour les rapports d’utilisation.

Mappage DDEX en pratique

Où le mettre : dans les livraisons DDEX ERN, incluez l’ISRC dans la ressource d’enregistrement sonore et dans toutes les références au niveau de la sortie qui pointent vers cet enregistrement. En pratique, cela signifie placer le code dans le conteneur ResourceReference ou SoundRecordingId (selon votre version ERN) et s’assurer que les références ReleaseResource font référence à la même entrée d’enregistrement sonore afin que les systèmes en aval puissent faire correspondre les flux au master.

Extrait d’exemple (de haut niveau) : mappez votre champ isrc interne à la référence de ressource ERN, par exemple : US-A1B-20-00001. Ne vous fiez pas aux tirets de présentation ; envoyez la valeur canonique à 12 caractères comme votre élément faisant autorité.

Liste de contrôle du développeur pour l’ingestion et la livraison

• Capturez l’ISRC canonique lors de l’ingestion : stockez la charge utile d’origine plus une valeur isrc_canonical normalisée (majuscules, 12 caractères).
• Validez le schéma des charges utiles ERN : exécutez la validation du schéma DDEX et les règles personnalisées qui affirment que l’ISRC apparaît à la fois dans l’enregistrement sonore et dans toutes les références de piste de sortie.
• Appliquez les livraisons idempotentes : utilisez l’ISRC + l’identifiant de sortie comme clé d’idempotence afin que les redéploiements ne créent pas de masters en double.
• Supprimez les doublons et rapprochez en amont : lors de l’ingestion en masse, supprimez les doublons par ISRC canonique avant de créer de nouveaux enregistrements master ; enregistrez les collisions pour un examen manuel.
• Conservez la provenance : écrivez un audit d’attribution immuable (qui a attribué, horodatage, préfixe de déclarant) et exposez une API qui le renvoie pour tout ISRC.

Compromis à accepter : la validation stricte ERN et les rejets durs réduisent l’orphelinage en aval, mais augmentent la friction d’intégration initiale avec les partenaires qui envoient des métadonnées désordonnées. D’après mon expérience, une approche hybride fonctionne : échouer rapidement pour les problèmes structurels, mais fournir une file d’attente de quarantaine et des charges utiles d’erreur claires afin que les partenaires puissent corriger et soumettre à nouveau sans perdre le débit d’ingestion.

Erreur courante du développeur : les équipes supposent qu’il suffit de placer l’ISRC une fois dans un flux de sortie. Ce n’est pas le cas. Vous devez vous assurer que le même ISRC apparaît partout où l’enregistrement sonore est référencé dans DDEX et dans toutes les charges utiles supplémentaires (registres d’éditeurs, API spécifiques à DSP, téléchargements de sociétés de perception). Les placements non concordants créent des discordances silencieuses qui apparaissent des semaines plus tard lors du rapprochement des paiements.

Exemple concret : une API de distributeur reçoit un CSV d’un label indépendant et mappe la colonne isrc dans son catalogue. L’équipe d’intégration a normalisé l’ISRC et l’a inséré dans la ressource DDEX ERN SoundRecording et la liste des pistes ReleaseResource. Lorsque les manifestes DSP hebdomadaires ont renvoyé des lectures, le système a immédiatement fait correspondre par ISRC et a automatisé les régularisations de royalties, évitant ainsi la correspondance manuelle qui prenait auparavant deux analystes trois jours par lot.

Intégrez l’ISRC dans votre API master canonique et votre exportation DDEX. Si un système en aval rejette votre ERN, la piste d’audit doit afficher la valeur ISRC exacte que vous avez envoyée et où elle a été placée.

Règles d’attribution pour les remasters, les modifications et les remixes

Règle directe : attribuez un nouvel ISRC lorsque le contenu audio lui-même est matériellement différent ; réutilisez l’ISRC d’origine pour les changements cosmétiques de mastering ou de format qui ne modifient pas la performance ou le mixage. C’est la meilleure politique pour éviter les discordances en aval dans le reporting et l’attribution des royalties pour ISRC code music.

Ce qui compte comme changement matériel : les modifications structurelles (nouvelles sections, nouvelles prises vocales, instrumentation ajoutée), les remixes qui créent un enregistrement distinct et les réenregistrements ont tous besoin de nouveaux ISRC. Le remastering mineur (ajustements d’égalisation/de tonalité, normalisation du volume sonore ou conversion en audio haute résolution) conserve normalement l’ISRC d’origine, à condition que la performance sous-jacente soit identique.

Liste de contrôle de décision pratique

Étape 1 : Comparez l’audio, pas les labels. Si une comparaison de forme d’onde ou une écoute montre une performance différente ou un contenu ajouté, créez un nouvel ISRC et enregistrez l’ISRC parent dans vos métadonnées. Étape 2 : Enregistrez les notes de version. Capturez toujours type de version, description de version et parent_isrc (le cas échéant) dans le registre master et exportez-les dans les livraisons telles que DDEX ERN. Étape 3 : Enregistrez la propriété séparément. Un nouvel ISRC ne modifie pas les divisions : enregistrez immédiatement toute nouvelle division auprès des sociétés de perception et des services comme SoundExchange.

Compromis à accepter : l’émission d’un nouvel ISRC fragmente les nombres de lectures historiques, mais donne une séparation juridique propre entre les masters ; la réutilisation d’un ISRC préserve la continuité du flux, mais obscurcit la lignée et peut provoquer des litiges de division. En pratique, choisissez la voie juridique la plus sûre pour tout changement susceptible d’affecter qui doit être payé.

Exemple concret : une performance acoustique de 1998 est remasterisée pour le streaming avec une plage dynamique améliorée uniquement : conservez l’ISRC d’origine (par exemple, GBZ9X1901234) et notez les détails du remaster dans les métadonnées. Un remix de danse de 2024 qui ajoute une nouvelle production et un chant invité doit obtenir un nouvel ISRC et être enregistré séparément auprès des DSP et des sociétés de perception afin que les flux soient signalés au master correct et que les divisions puissent être appliquées.

Malentendu courant : de nombreuses équipes pensent que les modifications de temps (modifications radio courtes ou fondus) peuvent réutiliser le même ISRC ; cela se retourne souvent contre eux. Une modification raccourcie modifie l’audio livré et la façon dont les DSP signalent l’identité de la piste : si la modification a été utilisée comme une sortie distincte, émettez un nouvel ISRC et reliez-le à l’original via des relations de métadonnées.

• Incontournable opérationnel : stockez un champ parent_isrc dans votre enregistrement master afin que la lignée survive aux déplacements de catalogue et aux changements de distributeur.
• Détail de la livraison : incluez versiondescription et parentisrc dans les livraisons DDEX ; consultez les conseils relatifs aux éléments DDEX ERN pour les conteneurs corrects.
• Conseil de rapprochement : lorsque vous voyez de l’audio dupliqué sur différents ISRC, utilisez la prise d’empreintes digitales pour confirmer, puis fusionnez le reporting à l’aide de vos enregistrements de provenance.

Problèmes courants, rapprochement et dépannage

Vérification de la réalité : la plupart des rapprochements ISRC sont triables : un petit nombre de pistes produisent la majorité des revenus orphelins, et les corrections sont soit des corrections de métadonnées, soit des preuves de provenance pour les plateformes et les sociétés. Considérez le rapprochement comme un flux de travail médico-légal, et non comme un nettoyage ponctuel.

Flux de travail de triage que vous pouvez exécuter dans les premières 48 heures

1. Collectez les entrées : rassemblez les derniers manifestes DSP, les exportations d’utilisation de la plateforme et les manifestes de la société de perception dans un seul schéma de mise en scène.
2. Classez par impact : exécutez un cumul par isrc pour trouver le premier 1 % des ISRC par flux ou revenus et attaquez-vous à ceux-ci en premier.
3. Classez les échecs : étiquetez les lignes comme ISRC manquant, ISRC en double, Lignée non concordante ou Écart de propriété et attribuez une gravité.
4. Résolvez et documentez : appliquez les corrections dans votre registre master, créez une entrée de journal des modifications horodatée, puis envoyez les livraisons ou réclamations DDEX ERN corrigées à la plateforme.
5. Vérifiez la clôture : réingérez le prochain manifeste de la plateforme et confirmez que les lectures précédemment orphelines rejoignent maintenant le master correct.

Aperçu pratique : la priorisation par revenus réduit considérablement les heures. D’après mon expérience, la correction des 20 premiers ISRC récupère généralement plus de 70 % des revenus orphelins récupérables dans un catalogue. Commencez par des jointures quantifiables, et non par la chasse aux anomalies de faible valeur.

Modes de défaillance qui refont surface

• Collisions de déclarants lors de la migration des distributeurs : un nouveau distributeur réutilise les numéros de désignation sous son préfixe, produisant des ISRC jumeaux pour le même audio ; le catalogue perd la provenance faisant autorité.
• Lignée parentale manquante ou obsolète : les remasters ou les modifications manquent d’un champ parent_isrc dans le registre, de sorte que les jointures automatisées les traitent comme des masters non liés.
• Jointures sensibles à la casse et au formatage : certains pipelines d’ingestion ne parviennent pas à normaliser les tirets ou la casse ; les plateformes ingèrent la valeur littérale et votre canonisation ultérieure ne correspond plus aux lignes signalées.
• Corrections ERN retardées : les métadonnées corrigées sont envoyées, mais ne sont pas consommées par le DSP, car la livraison n’avait pas les clés d’idempotence ou les indicateurs de mise à jour corrects.

Exemple concret : un indépendant de taille moyenne a trouvé un orphelin récurrent pour un remix à flux élevé. L’enquête a montré que le remix avait deux ISRC parce que le distributeur d’origine avait émis le remix sous son préfixe de déclarant et qu’un agrégateur ultérieur avait émis un ISRC différent. L’équipe a utilisé la prise d’empreintes digitales audio pour prouver l’audio identique, a soumis une mise à jour DDEX ERN consolidée référençant le parent_isrc correct et a récupéré trois mois de paiements retenus grâce à un processus de réclamation SoundExchange.

• Requêtes rapides à exécuter : SELECT isrc, SUM(streams) AS s FROM dspreports GROUP BY isrc ORDER BY s DESC LIMIT 100; puis SELECT * FROM dspreports WHERE isrc IS NULL OR isrc = '' LIMIT 500;
• Vérification des empreintes digitales : traitez par lots les doublons suspects via un fournisseur de prise d’empreintes digitales (BMAT, Audible Magic) et stockez les scores de confiance. Utilisez les correspondances à haute confiance pour amorcer les réclamations, mais exigez un examen humain pour les cas limites.
• Preuve de provenance : préparez un paquet d’une page par réclamation avec votre ISRC canonique, l’entrée du journal d’attribution, les horodatages de livraison et l’élément DDEX ERN que vous avez envoyé afin que les plateformes aient une piste vérifiable.

Conseil de dépannage : enregistrez toujours la charge utile exacte que vous avez livrée (ERN, requête API, CSV) avec l’ISRC canonique. Lorsqu’une plateforme conteste une correspondance, la charge utile brute est le moyen le plus rapide de résoudre qui a envoyé quoi et quand.

Considération suivante : créez une petite API qui renvoie l’historique des attributions pour tout ISRC et exposez-la aux partenaires lorsque vous soumettez des réclamations. Ce point de terminaison unique réduit de 50 % les escalades manuelles et rend les litiges traçables. Pour le formatage de la livraison et le placement des éléments ERN, consultez les conseils DDEX ERN et, lorsque vous devez escalader vers des payeurs non interactifs, utilisez les procédures SoundExchange.

Tendances émergentes et considérations d’interopérabilité

Bref aperçu : l’industrie évolue vers une réalité multi-identifiants où un ISRC reste la balise d’enregistrement principale, mais doit coexister avec de nouveaux ID de registre, des signatures d’empreintes digitales et des identifiants spécifiques à la plateforme pour obtenir une correspondance fiable entre les systèmes.

Implication pratique : concevez des systèmes pour accepter et renvoyer plusieurs ID persistants pour un master au lieu de traiter l’ISRC comme la seule clé externe. Stockez chaque identifiant avec sa source, un score de confiance ou de fiabilité et un horodatage afin que les jointures en aval puissent choisir la correspondance la plus fiable pour un contexte donné.

Comment gérer plusieurs ID dans votre catalogue

Suggestion de schéma : incluez un tableau identifiers sur votre objet master où chaque élément enregistre type (ISRC, RIN, empreinte digitale, plateformeid), value, source, confidence et assignedat. Par exemple : {identifiers:[{type:ISRC,value:USA1B2000001,source:registrant,assigned_at:2020-05-01}]}.

• Recommandation d’ordre de correspondance : préférez d’abord les correspondances ISRC exactes, puis les ID de registre faisant autorité tels que DDEX RIN, puis les correspondances d’empreintes digitales à haute confiance.
Règle de gestion des versions : ne remplacez jamais un ISRC existant ; ajoutez des ID supplémentaires et enregistrez pourquoi le nouvel ID a été ajouté (ing