Référentiel produit unique : la seule décision qui sauve une migration

Il y a une question que je pose au début de chaque mission. Une seule. Et la réponse prédit à 80 % si la migration va tenir trois ans ou exploser dans six mois.

“Quel est votre référentiel produit unique ?”

Si la réponse est “euh, on a Odoo, mais on modifie aussi dans Shopify, et parfois Excel pour les fiches”, la migration va échouer. Peut-être pas tout de suite. Mais elle va échouer.

Pourquoi c’est si critique

Un produit, dans une marque qui scale, vit dans plusieurs systèmes simultanément : ERP, e-commerce, marketplaces, PIM, catalogue print, CRM. Si chacun de ces systèmes peut être l’origine d’une modification, vous avez plusieurs sources de vérité qui divergent. Et quand elles divergent, vous avez :

• Stocks faux
• Prix incohérents entre canaux
• Fiches produit qui se contredisent
• Marketplaces qui rejettent les imports
• Comptabilité qui ne tombe pas juste

Une seule règle saine : un produit a UNE source de vérité, et UNE SEULE. Tous les autres systèmes la consomment.

Comment choisir la source de vérité

Trois options, dans l’ordre de préférence pour une marque DTC :

1. Odoo (mon préféré)

Si vous avez Odoo, faites-en le master. C’est ce pour quoi il est fait, il a un PIM intégré, il connecte à votre comptabilité, il gère le multi-entrepôts, et il est là pour rester.

2. PIM dédié (Akeneo, Plytix)

Si vous avez un catalogue très complexe (variantes, médias, traductions, marketplaces multiples), un PIM dédié vaut son investissement. Akeneo est le standard, Plytix est plus accessible.

3. Shopify (à éviter sauf cas simple)

Shopify peut faire le job pour une mono-marque, mono-pays, < 1 000 SKU. Au-delà, il devient le maillon faible.

Jamais : un fichier Excel partagé, un Google Sheet, une base SQL maison.

La règle de propagation

Une fois la source choisie, la règle est inflexible :

Source de vérité (Odoo) ──▶ Système consommateur (Shopify, marketplaces, CRM)
                            │
                            └─▶ Modifications interdites côté consommateur

Chaque consommateur reçoit la donnée, l’affiche, l’enrichit éventuellement (SEO Shopify, tags marketplaces), mais ne modifie jamais le master.

Comment imposer la règle en pratique

C’est là que ça se joue, et c’est rarement technique. C’est organisationnel.

1. Documenter la règle : un schéma, accroché au mur s’il faut. “Tout produit naît dans Odoo. Toujours.”
2. Verrouiller les UI consommatrices : dans Shopify, les champs critiques (titre, description, prix, variantes) sont en lecture seule pour 99 % des utilisateurs. Le bouton “modifier” est désactivé.
3. Process écrit : si quelqu’un veut modifier un produit, il modifie dans Odoo. Toujours.
4. Audit régulier : un cron quotidien qui vérifie que les drifts entre Odoo et les consommateurs sont à zéro.

Le coût de ne pas faire ça

Trois clients en deux ans ont refusé cette approche au démarrage (“on est habitués à modifier dans Shopify, c’est plus rapide”). Tous les trois m’ont rappelé entre 6 et 12 mois plus tard pour reprendre la migration en urgence.

Le pivot est techniquement simple. Le pivot organisationnel est douloureux. Faites-le au début, pas après.