Identités externes
Un exploitant ne travaille jamais seul. Autour de lui, un constructeur livre un catalogue, un service de codification attribue des numéros, un bureau d’études raccroche ses analyses. Chacun désigne vos objets avec ses propres identifiants.
Les identités externes sont la table de correspondance entre les vôtres et les leurs.
Ce que ça change concrètement
Sans elles, chaque import est un coup unique. Le premier lot d’un constructeur crée mille références ; le second lot, six mois plus tard, ne reconnaît aucune de celles qu’il a lui-même créées, et en fabrique mille doublons.
Le défaut ne se voit pas au premier lot. C’est précisément ce qui le rend coûteux : on le découvre quand il y a déjà deux catalogues.
Deux écrans
Administration › Référentiels d’identifiants (/admin/identifier-schemes) — les familles d’identifiants que vous acceptez : codification OTAN, séquences de catalogue, codes de module, références constructeur. Sept sont posées au départ ; vous en ajoutez autant que vos partenaires en imposent.
L’onglet « Identités externes » d’un objet — les valeurs que ses partenaires lui donnent. Il est aujourd’hui sur la fiche d’une référence article ; le même panneau se branchera ailleurs sans changement.
Le paramétrage d’un référentiel
| Champ | Ce qu’il décide |
|---|---|
| Code | La clé stable, en majuscules. Figée après création : les imports s’appuient dessus, et ils ne doivent pas casser parce qu’un libellé a été retouché. |
| Portée | Qui attribue les valeurs — une autorité de codification, un partenaire, ou un programme. Un NSN a le même sens partout ; une référence constructeur, non. |
| Normalisation | Comment la valeur est nettoyée à l’enregistrement. |
| Gabarit | Le format exigé, vérifié après normalisation. |
| Référentiel parent | Pour un identifiant hiérarchique seulement. |
| Stockage | Colonne dédiée ou table générique — voir plus bas. |
La normalisation se fait à l’écriture, jamais à l’affichage
C’est la règle qui évite le défaut le plus coûteux de tout le dispositif.
Un NSN s’écrit 5330-14-123-4567 ou 5330141234567 selon la source ; un préfixe CSN- est de l’habillage. Si l’on nettoie seulement au moment d’afficher, deux saisies différentes s’affichent identiquement et divergent en base. Personne ne le voit — jusqu’au premier rapprochement de catalogue, qui produit alors des écarts en série sur des lignes pourtant identiques.
Quatre règles sont disponibles : aucune, majuscules et espaces retirés, retrait d’un préfixe, chiffres uniquement.
Normaliser n’est pas valider
Deux gestes distincts, et il ne faut pas les confondre :
- normaliser réussit toujours — on enlève l’habillage ;
- valider peut refuser — le gabarit dit si la valeur est recevable.
Un NSN à douze chiffres est refusé, pas complété. On ne « répare » jamais en silence une donnée reçue d’un partenaire : la corriger sans le dire reviendrait à inventer.
Référentiels à colonne dédiée
Quatre référentiels ont déjà leur place dans le modèle : le NSN a son onglet, le NCAGE sa colonne sur le partenaire, le CSN et l’ISN les leurs sur la décomposition. Ce sont des clés que l’application affiche comme les siennes.
Ils sont marqués « colonne dédiée », et l’application refuse d’en enregistrer une copie dans les identités externes. Deux endroits pour la même valeur, ce sont deux valeurs qui finissent par différer — le rapprochement lisant l’une, l’écran affichant l’autre.
Le registre décrit quand même leur règle de normalisation : c’est elle qui s’applique avant d’interroger la colonne d’origine.
Attacher une identité
Les champs apparaissent quand ils ont un sens :
- le contexte ne s’affiche que pour un identifiant hiérarchique. Un rang d’article n’est unique que dans sa planche : deux planches différentes portent légitimement le même rang, et sans contexte la seconde saisie serait refusée à tort ;
- le partenaire ne s’affiche que pour un référentiel qui lui appartient. Demander qui attribue un NSN n’aurait pas de sens — c’est une autorité de codification.
L’identité principale est celle qu’on affiche quand un objet en porte plusieurs du même référentiel. Une seule à la fois.
Supplanter plutôt que supprimer
Quand un partenaire renumérote, supplantez. L’ancienne identité sort du rapprochement mais reste lisible : un lot ancien qui s’y référait doit rester relisible, et sa valeur redevient disponible pour un autre objet.
La suppression est réservée aux saisies erronées. Elle efface une trace de rapprochement : tout lot ancien qui s’y référait devient illisible. L’application demande une confirmation explicite, et l’écran propose la supplantation en premier.
Ce que ça prépare
Cette table est la première brique du socle d’interopérabilité. Elle ne lit ni ne produit aucun format — mais aucun format n’est tenable sans elle.
Le jour où un lot constructeur arrive, la question n’est plus « comment lire ce fichier » mais « à quoi correspond cette ligne » : et c’est exactement ce que les identités externes savent répondre.