Vos fiches produit ne disent pas la même chose selon l'outil où vous les ouvrez. L'ERP affiche un poids, le site marchand en affiche un autre, le flux envoyé à Google a encore une troisième version de la couleur. Personne n'a menti : chaque outil a été rempli par quelqu'un, à un moment, avec de bonnes intentions. Un référentiel produit sert à régler ça, mais pas comme on l'imagine souvent.
Je pilote des projets où un ERP, un site et parfois des outils marketing doivent partager les mêmes produits. Ma conviction, après plusieurs intégrations : le problème n'est presque jamais l'outil. C'est qu'on n'a jamais décidé, donnée par donnée, laquelle fait foi. Voici comment je m'y prends, et où la méthode s'arrête.
01Ce qu'est un référentiel produit, et ce qu'il n'est pas
Un référentiel produit, c'est l'endroit où vit la version qui fait foi de chaque donnée de base d'un produit : sa référence, son nom, son unité, ses dimensions, ses variantes. Les autres outils lisent cette version, ils ne la réinventent pas. En anglais, on parle de master data, et de MDM (master data management) pour la discipline qui la gère.
Ce n'est pas forcément un logiciel. Dans une petite entreprise, le référentiel peut très bien être l'ERP, à condition que tout le monde accepte que l'ERP gagne en cas de désaccord. Ce n'est pas non plus un grand nettoyage ponctuel : un fichier propre le lundi redevient sale le vendredi si deux outils ont encore le droit d'écrire la même donnée.
Une vidéo d'IBM Technology résume bien l'enjeu, avec un exemple de client plutôt que de produit : la gestion des données de référence sert à établir la vue unique d'une personne, d'un lieu ou d'une chose. Le même client y existe sous quatre noms dans quatre applications. IBM vend des outils de MDM, il faut le savoir en la regardant, mais l'exemple est juste. Remplacez le client par un produit et vous avez la situation de beaucoup de sites marchands.
02Trois données qui doivent faire foi : la référence, l'unité, la variante
Toutes les données produit ne se valent pas. Trois d'entre elles cassent tout quand elles divergent.
La référence
La référence (le SKU) est la clé qui relie tout le reste. La documentation de Google Merchant Center est très claire sur ce point : l'identifiant doit être unique, rester le même lors des mises à jour et être identique dans tous les pays et toutes les langues. La même page précise qu'un GTIN deviné ou incorrect fait refuser le produit. Mieux vaut un champ vide qu'un champ faux.
L'unité
Un produit acheté par carton et vendu à l'unité a deux unités, et c'est normal. Ce qui ne l'est pas, c'est de laisser chaque outil supposer la sienne. Odoo donne un bon modèle : chaque catégorie d'unités de mesure a une unité de référence, et le logiciel ne convertit qu'entre unités d'une même catégorie. Douzaines à l'achat, unités en stock : la conversion est explicite et automatique.
La variante
Un tee-shirt en quatre couleurs et cinq tailles, ce sont vingt variantes dans Odoo, chacune avec son propre SKU, son stock et son prix. Côté moteur de recherche, Google Search Central demande la même chose dans les données structurées : un identifiant unique par variante et un identifiant de groupe, le SKU parent, avec les propriétés communes comme la marque rangées au niveau du groupe. Si votre ERP et votre site ne découpent pas les variantes de la même façon, aucune synchronisation ne tiendra.
03Ce que j'ai vu se casser quand la référence n'était pas explicite
Sur un projet, deux outils échangeaient des dimensions. L'un travaillait en centimètres, l'autre en millimètres, et rien dans le fichier ne le disait. Le résultat n'était pas une petite erreur sur une fiche : c'est tout un rendu qui sortait déformé. On a mis du temps à comprendre, parce que chaque outil, pris seul, était cohérent. Depuis, j'applique une règle simple : la donnée de référence doit être explicite. Une dimension sans unité écrite à côté n'est pas une donnée, c'est une devinette.
Sur une intégration entre un ERP et un site marchand, la spécification a bougé presque à chaque réunion. Je l'ai fait évoluer version après version, pour que tout le monde parle du même document. C'est la même idée appliquée au papier : une seule version fait foi, et on sait laquelle. J'ai raconté ce chantier dans l'article sur la spécification d'intégration entre un ERP et un site marchand.
Chez Moonworkers, mon entreprise, la logique est poussée plus loin pour les calculs de paie. Un oracle écrit à partir des textes du HMRC sert de référence, et on rejoue les calculs contre lui. Il a trouvé quatre erreurs d'un penny dues à une règle d'arrondi. Ce n'est pas un référentiel produit, mais c'est le même réflexe : écrire quelque part ce qui est vrai, puis comparer le reste à cette vérité. La méthode est détaillée dans l'article sur tester un calcul avec un oracle.
Et pour ce blog, le calendrier des articles est un fichier versionné qui fait foi : statut, date prévue, mot-clé. L'outil de publication le lit, il ne garde pas sa propre copie. Quand je change une date, je la change à un seul endroit.
04Construire un premier référentiel produit en cinq étapes
Voici l'ordre que je suis. Il tient en quelques jours de travail pour un catalogue de taille raisonnable, et il ne demande aucun achat.
1. Lister les données et les outils
Un tableau simple : en lignes, les données produit (référence, nom, description, unité de vente, unité d'achat, poids, dimensions, variantes, prix, stock, images). En colonnes, les outils qui les contiennent : ERP, site, flux publicitaire, outil de devis. Dans chaque case, une croix si l'outil contient la donnée, et un E s'il peut l'écrire.
2. Désigner un seul maître par donnée
Pour chaque ligne, un seul outil garde le droit d'écrire. Souvent l'ERP pour la référence, l'unité, le prix et le stock, et le site ou un outil de contenu pour la description et les images. Toute ligne avec deux E est un conflit à trancher en réunion, pas à laisser filer.
3. Écrire les règles de format
Le format de la référence, les unités autorisées et leur écriture (mm ou cm, jamais les deux), la liste des attributs de variante et leurs valeurs permises. Une page suffit. Elle va dans la spécification d'intégration, versionnée.
4. Nettoyer une fois, à partir du maître
On exporte le maître, on corrige les doublons et les champs vides, on ne remplit pas un GTIN qu'on ne connaît pas. Puis on écrase les copies à partir de cette version. Ne jamais nettoyer dans deux outils en parallèle.
5. Brancher la synchronisation dans un seul sens
Le maître pousse, les autres reçoivent. Le rythme (immédiat ou par lot planifié) se choisit donnée par donnée : le stock a besoin d'aller vite, une description beaucoup moins. J'ai détaillé ce choix dans l'article sur l'API temps réel ou le flux batch, et le cas concret d'un connecteur entre Odoo et PrestaShop montre où il coince.
05Les limites : quand un logiciel de MDM n'est pas la réponse
Cette méthode a un coût : elle oblige à trancher des questions que l'organisation évitait. Qui a le droit de modifier un prix ? Le marketing peut-il renommer un produit sans passer par l'ERP ? Ces réunions sont parfois plus difficiles que la partie technique, et je ne connais pas de raccourci.
Elle a aussi un plafond. Quand les produits viennent de dizaines de fournisseurs, avec des fiches dans des formats différents, ou quand plusieurs filiales ont chacune leur ERP, un outil dédié (un PIM ou une solution de MDM) peut devenir justifié. Je ne fais pas de refonte d'ERP ni de déploiement de ces outils lourds : ce sont des projets longs, qui ont leurs propres spécialistes.
Ce que je déconseille, c'est d'acheter l'outil avant d'avoir fait les étapes 1 à 3. Un logiciel de MDM rapproche des enregistrements selon des règles. Si personne n'a décidé ces règles, il rapprochera mal, plus vite. Et si vous en êtes au choix de l'ERP lui-même, la question du référentiel fait partie des critères, comme je l'explique dans l'article sur le choix d'un ERP pour une PME.
06Par où commencer lundi
Prenez dix produits au hasard, dont au moins un avec des variantes. Ouvrez-les dans chaque outil et notez les écarts : référence, unité, poids, couleur. Ce petit relevé dit en une heure si votre problème est un détail ou une question de fond.
Ensuite, faites le tableau de l'étape 1, même incomplet, et apportez-le à la prochaine réunion avec une seule question : pour chaque ligne, qui gagne en cas de désaccord ? C'est souvent la première fois que la question est posée à voix haute.
Si vous voulez un regard extérieur sur ce chantier, je fais ce type de diagnostic en quelques jours, puis la mise en place avec l'équipe ; mes services et les missions déjà menées donnent une idée de la façon de travailler. On peut en parler.