Comment garantir des identifiants produit stables entre ses flux ?

Un catalogue tient debout par ses identifiants. Tant qu'ils sont stables, tout le reste peut changer : le nom du produit, son prix, ses images, sa catégorie. Dès qu'ils bougent, la boutique perd le fil de ses propres données, et tous les systèmes qui en dépendent le perdent avec elle. Les identifiants produit stables ne sont pourtant presque jamais traités comme un sujet à part entière : on les hérite d'un fichier de reprise, on les laisse générer par la plateforme, et on découvre le problème le jour où une place de marché refuse la moitié du catalogue, où les statistiques ne se rapprochent plus des ventes, ou où un client reçoit la mauvaise taille. Le sujet est simple à traiter au départ et pénible à rattraper ensuite.

Ce que chaque identifiant désigne réellement

La confusion la plus fréquente consiste à mélanger deux familles d'identifiants qui n'ont ni la même autorité ni le même usage. La première est interne : c'est la référence que l'entreprise attribue elle même, souvent appelée SKU, dont elle est seule maîtresse et qu'elle peut définir comme elle l'entend. La seconde est externe et normalisée : le code à barres, désigné génériquement par le terme GTIN, attribué selon des règles internationales et rattaché à l'entreprise qui met le produit sur le marché. Le SKU sert à l'entreprise à retrouver son propre article dans son stock, ses commandes et ses flux ; le GTIN sert à tout le monde à savoir qu'il s'agit du même produit d'un système à l'autre, ce qui est exactement ce dont un moteur de recherche ou une place de marché a besoin pour rapprocher deux offres. Il en découle une règle qui règle beaucoup de discussions : le SKU ne doit jamais être communiqué comme s'il était universel, et le GTIN ne doit jamais être inventé. Un revendeur qui ne fabrique pas le produit n'a pas à créer un code à barres, il doit reprendre celui du fabricant ; un fabricant qui met un produit sur le marché doit en obtenir un auprès de l'organisme compétent, ce qui a un coût et un délai qu'il vaut mieux anticiper. Reste le cas des produits qui n'ont légitimement aucun GTIN, les créations uniques, les articles personnalisés, les prestations, pour lesquels les flux marchands acceptent une combinaison de marque et de référence fabricant à la place. Cette troisième voie est prévue et documentée, et elle vaut infiniment mieux qu'un code inventé, qui sera tôt ou tard identifié comme appartenant à un autre produit et fera rejeter l'offre entière. Ce sujet touche directement la structure du catalogue, dont nous avons traité la modélisation dans la rubrique e-commerce.

Écrire une règle de nommage qui tienne dix ans

Le SKU étant libre, tout le monde l'invente, et c'est là que les ennuis commencent. Une règle de nommage doit satisfaire trois exigences simultanées, dont la troisième est presque toujours oubliée. La première est l'unicité, y compris entre familles de produits, y compris pour les articles supprimés : un identifiant libéré ne doit jamais être réattribué, sous peine de faire ressusciter d'anciennes commandes sous un nouveau produit. La deuxième est la lisibilité, parce que ces références sont lues à voix haute au téléphone, saisies à la main dans un entrepôt et recherchées dans un tableur : on évite donc les caractères ambigus, la lettre O face au chiffre zéro, le I face au chiffre un, ainsi que les espaces, les accents et toute ponctuation autre que le tiret. La troisième exigence, celle qu'on néglige, est l'absence d'information encodée dans l'identifiant. Il est tentant de composer une référence qui contient la famille, le fournisseur, l'année et le coloris, parce que cela permet de tout lire d'un coup d'œil ; c'est une erreur, parce que chacune de ces informations peut changer alors que l'identifiant doit rester fixe. Un produit change de famille lors d'une réorganisation du catalogue, change de fournisseur, se voit reclassé : à chaque fois, soit on modifie l'identifiant et on casse tout, soit on le garde et il devient mensonger, ce qui est pire puisque des humains continueront de s'y fier. La règle qui vieillit bien consiste donc à retenir un identifiant court, opaque, alphanumérique, sans signification, et à laisser les attributs vivre dans les champs qui leur sont dédiés. On peut concéder un préfixe stable de deux ou trois caractères pour distinguer une entité ou un canal, à condition qu'il désigne quelque chose qui ne changera pas. Une longueur fixe simplifie par ailleurs tous les traitements ultérieurs, du tri au contrôle de saisie, et rend immédiatement visible une référence tronquée par un logiciel.

Le piège des variantes

C'est de loin le sujet qui produit le plus d'incohérences, et il ne se règle que par une décision explicite. Ce qui se vend, s'expédie et se compte en stock n'est pas le produit mais la variante : la chemise bleue en taille quarante, pas la chemise. Chaque variante doit donc porter son propre SKU, distinct, et son propre GTIN quand il existe, car les codes à barres normalisés sont attribués à un article précis et non à une gamme. Un catalogue qui attribue le même code à toutes les tailles d'un vêtement produit des rejets systématiques sur les places de marché, des erreurs de préparation de commande en entrepôt et des statistiques inexploitables. La question suivante est celle du lien entre les variantes et leur produit parent, et elle demande de choisir : soit le SKU de la variante dérive de celui du parent par un suffixe, ce qui est lisible mais réintroduit de l'information dans l'identifiant, soit les deux sont indépendants et le lien vit dans une relation explicite du modèle de données. La seconde option est plus robuste et se recommande dès que le catalogue dépasse quelques centaines de références, parce qu'elle survit aux regroupements et aux séparations de gammes, opérations plus fréquentes qu'on ne le croit. Dans les deux cas, la règle absolue est qu'un SKU ne désigne qu'une seule chose : jamais le parent et la variante à la fois, jamais deux variantes différentes selon le contexte. Un dernier cas mérite attention, celui des lots et des produits vendus par plusieurs, qui constituent des articles à part entière, avec leur propre identifiant et leur propre code à barres. Les traiter comme des quantités du produit unitaire donne un stock faux et des expéditions erronées, et c'est une erreur que l'on retrouve dans une majorité de reprises de catalogue.

Tenir la cohérence entre tous les flux

Un catalogue moderne alimente plusieurs destinations : un flux vers un comparateur ou une régie publicitaire, un ou plusieurs flux vers des places de marché, un connecteur vers un logiciel de gestion, un export comptable, un moteur de recommandation, un outil de mesure d'audience. Chacun a ses exigences, et la tentation est de bricoler un identifiant spécifique pour chacun, ce qui produit à terme un enchevêtrement que personne ne sait plus démêler. La règle qui évite cela tient en une phrase : un seul identifiant fait autorité, tous les autres sont des correspondances qui lui sont rattachées, et cette correspondance est stockée, jamais recalculée. Le cas le plus sensible est celui de l'identifiant transmis aux flux publicitaires, souvent appelé identifiant d'article, qui sert à rapprocher les ventes des dépenses. Le modifier revient à perdre tout l'historique de performance du produit et à repartir de zéro sur son apprentissage, ce qui a un coût direct. Il doit donc être défini une fois, aligné sur le SKU de la variante, et ne plus jamais bouger, même lors d'une migration de plateforme. C'est d'ailleurs le moment le plus dangereux : une migration réattribue les identifiants techniques internes, et si le flux les utilisait, tout le catalogue apparaît comme neuf du jour au lendemain. La parade consiste à ne jamais exposer l'identifiant technique de la base dans un flux, quel qu'il soit, et à toujours passer par la référence métier, ce qui est la même discipline que celle exposée dans notre article sur la manière de modéliser un catalogue produit en JSON plutôt qu'en base relationnelle. La mesure d'audience obéit à la même exigence : l'identifiant envoyé dans les événements du commerce électronique doit être celui du flux, sans quoi les rapprochements entre navigation et ventes deviennent impossibles.

Faire vivre les identifiants dans le temps

Un identifiant stable n'est pas un identifiant figé pour l'éternité, c'est un identifiant qui ne change jamais pour un article donné. La nuance compte, car un catalogue vit : des produits disparaissent, reviennent, évoluent, et chacune de ces situations appelle une décision de principe qu'il vaut mieux avoir prise à froid. Le cas du produit supprimé se traite par une mise hors vente plutôt que par une suppression : l'article conserve son identifiant, cesse d'être vendable et d'apparaître dans les flux, mais reste rattachable aux commandes passées et à l'historique. Supprimer purement et simplement une ligne de catalogue transforme les anciennes commandes en références orphelines, ce qui complique tout, du service après vente à la comptabilité. Le cas du produit qui revient en stock après plusieurs années se règle alors de lui même, l'identifiant étant resté disponible et intact. Le cas véritablement délicat est celui du produit modifié : à partir de quel degré de changement s'agit il d'un article nouveau ? La règle usuelle, cohérente avec les règles internationales des codes à barres, est que tout changement affectant ce que le client reçoit, la contenance, la composition, la quantité par lot, la compatibilité, crée un article nouveau, avec un identifiant nouveau ; en revanche une nouvelle photographie, une description réécrite, un changement de prix ou de packaging purement graphique ne changent rien. Trancher cette question au cas par cas produit des incohérences, l'écrire une fois dans une note de deux paragraphes règle le sujet durablement. Reste le cas des reprises de fournisseurs, où un produit identique arrive sous une nouvelle référence fabricant : c'est le même article pour le client, il conserve donc son identifiant interne, et seule la correspondance externe change, ce qui illustre bien pourquoi ces deux niveaux doivent rester distincts.

Détecter les incohérences avant qu'elles ne coûtent

Un contrôle automatique hebdomadaire suffit à maintenir un catalogue sain, et il porte sur une demi douzaine de vérifications qui se scriptent en une journée. La première est l'unicité : aucun SKU ne doit apparaître deux fois, aucun GTIN non plus, et un doublon signale soit une erreur de saisie, soit un produit dupliqué par accident lors d'un import. La deuxième est la validité formelle des codes à barres, dont le dernier chiffre est une clé de contrôle calculée à partir des précédents : un code dont la clé ne tombe pas juste est faux à coup sûr, et cette vérification se fait hors ligne, sans interroger le moindre service. La troisième est la complétude : toute variante vendable doit avoir un SKU, et toute variante qui devrait en avoir un doit avoir un GTIN ou, à défaut, un couple marque et référence fabricant. La quatrième est la stabilité dans le temps, contrôlée en comparant l'export du jour avec celui de la semaine précédente : tout identifiant disparu ou modifié doit être justifié, et cette comparaison est le seul moyen de détecter une réattribution silencieuse provoquée par un import mal paramétré. La cinquième est la cohérence entre canaux, vérifiée en rapprochant les identifiants présents dans chaque flux avec le catalogue de référence, ce qui fait apparaître les produits présents sur une place de marché et supprimés de la boutique, cas qui se termine invariablement par une commande impossible à honorer. La sixième, enfin, porte sur les adresses publiques des fiches, qui ne sont pas des identifiants mais se comportent comme tels du point de vue des moteurs et des liens entrants. Ces contrôles n'ont d'intérêt que s'ils débouchent sur une action, ce qui suppose qu'ils produisent une liste courte et non un rapport de trois cents lignes que personne ne lira, et qu'ils désignent nommément le produit concerné plutôt qu'un numéro de ligne dans un fichier. Une septième vérification mérite d'être ajoutée dès que la boutique alimente des données structurées : les identifiants annoncés dans le balisage de la fiche produit doivent être exactement ceux du flux, faute de quoi le moteur voit deux offres distinctes pour un même article, l'une venant de la page, l'autre du flux marchand. Cette incohérence ne provoque aucune erreur visible et se traduit simplement par des fiches qui n'obtiennent jamais les affichages enrichis attendus, ce que nous détaillons dans notre article sur les données structurées d'une fiche produit e-commerce.

Ce qu'il faut faire quand le mal est déjà fait

La situation la plus courante n'est pas le catalogue neuf mais le catalogue existant, avec ses identifiants incohérents accumulés sur dix ans, ses doublons et ses codes inventés. La reprise se mène en quatre temps, et le premier consiste à ne rien changer : il s'agit d'établir l'inventaire complet, produit par produit, en notant pour chacun tous les identifiants existants dans tous les systèmes. Ce document, souvent le premier de ce genre dans l'entreprise, révèle à lui seul l'ampleur du sujet et sert de référence à tout ce qui suit. Le deuxième temps consiste à choisir l'identifiant qui fera autorité, et le bon choix est presque toujours celui qui est déjà utilisé par le système le plus difficile à modifier, en général le logiciel de gestion ou l'entrepôt, plutôt que celui qui semble le plus propre. Le troisième temps est la construction d'une table de correspondance entre l'identifiant retenu et tous les autres, qui devient un actif permanent de l'entreprise et non un fichier de transition : c'est elle qui permettra, dans trois ans, de comprendre une commande ancienne ou de rapprocher un historique de ventes. Le quatrième temps est la convergence progressive, canal par canal, en commençant par ceux dont l'historique n'a pas de valeur et en terminant par les flux publicitaires, dont le changement coûte le plus cher. Ce qu'il ne faut surtout pas faire, c'est renuméroter le catalogue d'un coup pour repartir sur des bases propres : l'opération casse simultanément les commandes en cours, l'historique de performance, les correspondances avec les fournisseurs et les places de marché, pour un gain esthétique. Un catalogue vit très bien avec des identifiants hérités et laids, à condition qu'ils soient uniques et stables, ce qui est le seul critère qui compte réellement.