Données de référence dans les catalogues produits : codes, listes et gouvernance

Les données de référence sont l'ensemble des valeurs autorisées vers lesquelles pointent les autres données : codes pays, devises, unités de mesure, noms de couleur, systèmes de tailles et codes de classification. Elles ne décrivent pas un produit ou une commande. Elles décrivent les listes dans lesquelles produits et commandes choisissent, comme NL, EUR, KGM ou « navy ».

Dans un catalogue produits, ce sont les données de référence qui font que 4 000 produits disent « navy » au lieu de navy, Navy, bleu foncé et marine. Elles changent rarement, elles sont partagées par chaque produit et chaque canal, et quand elles sont fausses, l'erreur se répète d'un coup sur tout le catalogue. C'est pour cela qu'elles ont besoin d'un responsable, d'une version et d'un mapping vers la liste de codes propre à chaque canal.

Données de référence, données de base, données transactionnelles et métadonnées

Les équipes data répartissent les données métier en quatre types. Dans la pratique, les frontières sont floues (certains considèrent les données de référence comme un sous-ensemble des données de base, ou master data), mais ce découpage aide à décider qui est responsable de quoi et à quelle fréquence cela change.

Un test simple : si la valeur n'a de sens que comme un choix parmi une liste fixe, c'est une donnée de référence. Le poids du produit (1,25) est une donnée de base ; l'unité à côté (kg) vient d'une liste de référence. Le pays du client sur une commande est une donnée transactionnelle, mais la liste des pays dans laquelle la commande peut choisir est une donnée de référence. Pour en savoir plus côté données de base, consulte la gestion des données de base (MDM).

Les listes de codes externes dont dépend chaque catalogue produits

Une grande partie des données de référence ne s'invente pas. Des organismes internationaux les publient, et les canaux attendent que tu utilises exactement leurs codes. Voici les listes qu'un e-commerçant ou un grossiste rencontre en premier.

Quelques faits derrière ce tableau. Les flux et les fichiers marketplace associent un prix à un code devise ISO 4217 ; Google Merchant Center, par exemple, attend 15.00 USD plutôt que $15. La liste de la Recommandation n° 20 de la CEE-ONU, que la facturation électronique Peppol utilise dans sa révision 11e, définit KGM comme le kilogramme et H87 comme la pièce (liste de codes Peppol) ; notre guide des unités de mesure explique comment les modéliser. Le Système harmonisé, utilisé par plus de 200 pays et économies, compte plus de 5 000 groupes de marchandises, chacun identifié par un code à six chiffres (OMD) ; l'UE ajoute deux chiffres pour sa nomenclature combinée, que tu peux parcourir à partir de la position 8539.

Les normes de classification ont aussi des versions. Selon ETIM International, la version officielle actuelle est ETIM 10.0, publiée en décembre 2024, avec des versions dynamiques entre-temps pour les classes prêtes à être publiées. Si ton catalogue est classé selon une version plus ancienne, certaines classes et caractéristiques auront changé. GS1 GPC utilise des codes à huit chiffres à chaque niveau, par exemple le segment 47000000 (Cleaning/hygiene products) et la famille 47100000 (Cleaning products), et seule la brick est échangée via les pools de données GS1 ; segment, famille et classe servent à trouver la bonne brick (GS1 Pays-Bas). Les guides ETIM et GS1 GPC expliquent les deux structures.

Listes de valeurs internes : couleurs, tailles et matières

Le second type de données de référence t'appartient : les noms de couleur, grilles de tailles, matières et coupes que ton catalogue autorise. Personne ne les publie pour toi, et c'est là que la plupart des catalogues dérivent. Un fichier fournisseur dit Midnight, un autre Dk Navy, un troisième 410, et sans liste fixe, les trois finissent dans le filtre couleur.

Une bonne liste interne enregistre chaque valeur sous forme de code stable avec des libellés par langue, plus un mapping vers chaque canal qui a sa propre liste. Exemple fictif pour une couleur :

• Code : navy (ne change jamais, utilisé dans les exports et les règles)
• Libellés : Navy (en), Marineblauw (nl), Marineblau (de), Bleu marine (fr)
• Groupe de filtre de la boutique : Bleu
• Couleur Google Shopping : Navy, le même nom que celui affiché sur la fiche produit
• Synonymes fournisseurs : Midnight, Dk Navy, 410 (mappés à l'import, jamais publiés)

Les règles des canaux rendent le mapping indispensable. L'attribut color de Google accepte jusqu'à trois couleurs séparées par des barres obliques (Red/Green/Black), refuse des valeurs comme « voir image » ou « N/A », et demande d'utiliser le même nom de couleur que la page de destination (Google Merchant Center). Pour les tailles de vêtements, size_system n'accepte que AU, BR, CN, DE, EU, FR, IT, JP, MEX, UK et US, et Google se rabat sur le système du pays cible si tu l'omets. Du texte libre ne peut pas respecter ces règles de façon constante ; une liste codée avec un mapping le peut.

Une grille de tailles mappée vers trois formats de canal

Les tailles montrent pourquoi un mapping vaut mieux qu'une copie. Prenons un pull en maille femme fictif, vendu en tailles EU 36 à 44. Ta liste de référence enregistre cinq codes : eu_36, eu_38, eu_40, eu_42 et eu_44. Chaque canal reçoit ensuite ce qu'il attend :

• Filtre de la boutique : les libellés 36, 38, 40, 42, 44, avec un guide des tailles qui montre les équivalences internationales utilisées par ta marque (par exemple S pour 36 et 38).
• Google Shopping : taille 38 avec size_system EU, pour que Google ne lise pas 38 comme une taille US.
• Une marketplace qui n'accepte que les tailles en lettres : un mapping qui envoie M pour eu_38, décidé une fois par le responsable de la liste au lieu de produit par produit par la personne qui charge le fichier.

Quand la marque change sa coupe et que 38 correspond désormais à une autre taille en lettres, tu modifies une seule ligne de mapping. Les 300 produits avec le code de taille eu_38 restent intacts, et chaque canal reçoit la nouvelle valeur au prochain export. Si la taille en lettres avait été saisie dans chaque produit, le même changement serait une modification en masse avec de fortes chances d'en oublier quelques-uns.

Le même principe s'applique aux matières (ton cotton_organic vers le « Coton biologique » d'une marketplace), aux unités (ton kg vers KGM dans un fichier B2B) et aux catégories (ta catégorie vers une catégorie de produits Google). Enregistre ta valeur une fois, mappe-la par canal, et garde le mapping au même endroit que la liste.

Gouverner les données de référence : responsable, versions et mappings par canal

La gouvernance des données de référence est modeste comparée à celle des données de base, mais elle doit être stricte. Quatre règles couvrent la plupart des catalogues :

1. Un responsable par liste. Une seule personne décide si « teal » devient une nouvelle couleur ou se mappe sur une couleur existante. Sans responsable, chaque import ajoute des valeurs.
2. Les codes sont permanents, les libellés non. Change un libellé (Navy en Navy blue) librement ; ne réutilise ni ne renomme jamais un code dont dépendent des exports et des règles. Retire une valeur en la marquant inactive.
3. Suis la version de chaque norme externe. Note la version d'ETIM et de GPC et l'année de NC qu'utilise ta classification, et planifie la mise à jour quand une nouvelle version sort.
4. Mappe les listes des canaux, ne les copie pas. Garde ta propre liste comme source et maintiens un mapping vers les codes de chaque canal, pour qu'un changement côté canal touche le mapping, pas chaque produit.

Une gouvernance des données plus large ajoute des rôles, des politiques et des audits pour les données de base ; pour les données de référence, le flux ci-dessus suffit généralement.

Que faire quand ETIM, la NC ou une liste ISO publie une nouvelle version

Les listes externes changent à leur propre rythme, et chacune demande une réponse différente. ETIM International publie une version officielle environ tous les trois ans, avec des versions dynamiques entre-temps (ETIM International). L'UE republie chaque année l'annexe I de sa nomenclature combinée sous forme de règlement autonome au Journal officiel, avec les changements convenus pour le Système harmonisé à l'OMD et ses propres mises à jour (Commission européenne). Les codes pays et devises ISO ne changent que lorsqu'un pays, une subdivision ou une devise change.

• Nouvelle version d'ETIM : compare les classes que tu as adoptées avec la nouvelle version, liste les classes scindées, fusionnées ou remplacées, et remappe ces produits avant que tes partenaires ne valident selon la nouvelle version. Une version dynamique contient encore des classes marquées pour suppression dans la prochaine version officielle : ces marquages te servent d'alerte précoce.
• Nouvelle année de NC : vérifie chaque code NC à huit chiffres du catalogue par rapport à la nouvelle liste dès sa publication. Un code qui n'existe plus sera rejeté dans une déclaration en douane, et la correction coûte moins cher dans le catalogue qu'à la frontière.
• Code ISO modifié : ajoute le nouveau code à ta liste, marque l'ancien comme inactif et déplace les produits concernés en une seule modification en masse, puis mets à jour chaque mapping de canal qui pointait vers l'ancien code.
• Tes propres listes : révise-les quand l'assortiment change, par exemple avant une saison avec de nouvelles matières ou une nouvelle grille de tailles, plutôt que de laisser le premier fichier fournisseur décider.

Auditer les données de référence d'un catalogue existant

La plupart des catalogues contiennent déjà des données de référence, simplement pas sous forme de listes. Un premier audit prend un après-midi, avec un export de tous les produits :

1. Liste chaque champ qui devrait être un choix. Couleur, taille, matière, pays d'origine, unité, marque, catégorie, certification. Tout champ qui a moins de valeurs distinctes que de produits est candidat.
2. Compte les valeurs distinctes par champ. Si un catalogue mode qui vend 14 couleurs a, disons, 212 valeurs distinctes dans son champ couleur, tu sais combien de nettoyage t'attend.
3. Regroupe les graphies d'une même valeur. La casse, les espaces et la ponctuation expliquent beaucoup de doublons ; les synonymes (Dk Navy, Midnight) demandent une décision humaine.
4. Vérifie les codes externes par rapport à la norme. Le pays d'origine doit être un code à deux lettres, les devises des codes à trois lettres, les codes SH valides pour l'année en cours.
5. Choisis un responsable et un code pour chaque liste, puis convertis le champ de texte libre en attribut à liste de choix qui n'accepte que les valeurs listées.
6. Décide ce qui arrive aux nouvelles valeurs à l'import : rejeter le produit, accepter et signaler pour vérification, ou accepter automatiquement pour les listes à faible risque.

Sept façons dont de mauvaises données de référence cassent un catalogue

1. Plusieurs graphies d'une même valeur. Navy, navy et NAVY scindent une option de filtre en trois, et chacune contient un tiers des produits.
2. Des noms de pays au lieu de codes. Holland, Netherlands et Nederland dans le pays d'origine sont tous rejetés par un champ qui attend NL.
3. Des unités dans les valeurs. 500g sous forme de texte ne peut pas être comparé à 0,5 kg ; l'unité a sa place dans son propre champ codé.
4. Des codes réutilisés. Renommer le code red en coral change en silence chaque produit qui portait le code red.
5. Une classification obsolète. Des produits restent sur une classe ETIM ou un code SH qu'une version plus récente a scindé ou remplacé, et les exports vers les partenaires échouent à la validation.
6. Des valeurs de canal stockées comme données de base. Saisir la couleur Google dans le produit au lieu de la mapper fait de chaque changement côté canal une modification en masse.
7. Des identifiants mélangés. Traiter un SKU, un GTIN et une référence article fournisseur comme un seul champ casse chaque recherche ; voir UPC vs SKU.

Option sets, UOM code sets et classification dans WISEPIM

WISEPIM conserve les données de référence internes dans des option sets (jeux d'options) : des listes partagées de valeurs autorisées pour les attributs à choix unique ou multiple. Chaque valeur a un code et un libellé par langue, un même jeu peut servir à plusieurs attributs, et les valeurs peuvent être rendues inactives au lieu d'être supprimées. Chaque jeu a une règle pour les valeurs inconnues venant d'un import : ignorer le produit, ajouter la valeur avec un signalement pour vérification, ou l'ajouter automatiquement. Les imports CSV peuvent mapper des valeurs fournisseurs vers des options existantes, et la page Attribute values (valeurs d'attribut) regroupe les graphies qui ne diffèrent que par les majuscules, les espaces ou la ponctuation pour que tu puisses les fusionner (voir la normalisation des valeurs d'attribut).

Avec la fonctionnalité d'espace de travail Classification activée, les UOM code sets (jeux de codes UOM) contiennent des unités avec un code, un symbole, des noms localisés et un facteur de conversion vers une unité de base. L'espace de classification permet aussi de parcourir les classes ETIM et GS1 GPC : une classe ETIM peut être adoptée comme famille de produits avec ses caractéristiques, une revue de mapping propose des liens entre tes familles et attributs et ETIM, et des nœuds GPC peuvent être importés comme catégories avec leur chemin complet. Plus de détails sur la page classification produit.

WISEPIM ne maintient pas les normes externes à ta place : c'est toi qui choisis les versions d'ETIM et de GPC, et les mappings de valeurs propres à chaque canal pour les couleurs ou les tailles font toujours partie de la configuration de chaque export.