Le questionnement initial
Je travaillais sur SAP Commerce Cloud — Hybris pour les intimes — et je manipulais quotidiennement des catalogues, des classification systems, des sync jobs entre Staged et Online. Sur le papier, ça ressemblait à de la gestion de données produit. En pratique, quelque chose clochait.
Un jour, un collègue m'a demandé : "C'est quoi la différence entre ce qu'on fait là et un vrai PIM ?"
J'ai ouvert la bouche. Rien n'est sorti.
Je savais qu'Hybris avait un module PCM. Je savais que PIM signifiait Product Information Management. Mais je ne savais pas expliquer clairement où s'arrêtait l'un et où commençait l'autre.
Cette question m'a hanté pendant quelques temps. Elle m'a poussé à creuser, à comparer, et finalement à construire mon propre PIM minimal pour vraiment comprendre ce qui manquait.
Voici ce voyage.
Première étape : comprendre ce qu'est réellement un PIM
J'ai commencé par revenir aux fondamentaux. Un PIM, c'est quoi exactement ?
La définition simple : un système qui centralise toutes les informations produit, les enrichit, et les diffuse vers différents canaux de vente. La source de vérité unique pour tout ce qui concerne vos produits.
Mais cette définition ne suffit pas. Ce qui distingue un vrai PIM d'une simple base de données produit, ce sont plusieurs caractéristiques que j'ai découvertes en étudiant Akeneo, Pimcore, Salsify et d'autres :
Les familles de produits. Pas les catégories — les familles. Une famille, c'est un gabarit qui définit quels attributs un produit doit avoir. Un t-shirt et un téléphone n'ont pas les mêmes champs à remplir. La famille impose cette structure.
La complétude. Un PIM sait vous dire : "Cette fiche est complète à 73% pour le canal e-commerce français." Il mesure la qualité des données, pas juste leur présence.
Le workflow éditorial. Brouillon, en révision, approuvé, publié. Un cycle de vie avec des étapes, des rôles, des validations.
La publication multicanale. Le PIM ne se contente pas de stocker. Il pousse les données vers votre site e-commerce, vers Amazon, vers votre catalogue papier — chacun avec ses propres exigences.
Hybris PCM
Hybris a les briques. Il a des catalogues, des classification systems, des attributs. Il peut même synchroniser des données entre environnements.
Le classification system d'Hybris ressemble à une famille qu'on peut retrouver dans un PIM dédié, mais ce n'est pas obligatoire. Vous pouvez créer des produits sans structure imposée. La complétude ? Inexistante nativement. Le workflow ? Basique, orienté staging technique plutôt que gouvernance éditoriale.
Et surtout, la philosophie est différente. Hybris synchronise un catalogue Staged vers Online ; c'est une copie interne. Un PIM publie vers des systèmes externes. Il ne duplique pas, il diffuse.
Une métaphore darwinienne
Avant de modéliser, j'avais besoin d'un vocabulaire qui me parle.
"Famille", "classification", "type produit" — ces termes me semblaient trop techniques, trop froids. Je cherchais une métaphore qui capture l'idée d'héritage, de variation, d'évolution.
Je l'ai trouvée dans la biologie.
Pensez à votre catalogue comme à un arbre phylogénétique. Une famille de produits, c'est comme un groupe d'espèces qui partagent un ancêtre commun et donc des caractéristiques communes. Le "génome" d'un t-shirt (taille, couleur, matière) est différent de celui d'un smartphone (mémoire, processeur, taille d'écran).
Un produit parent avec ses variantes, c'est comme une espèce avec ses mutations. Le t-shirt "Classic V-Neck" existe en bleu, rouge, noir — des variations sur un même thème génétique.
Et la publication vers différents canaux ? C'est la diffusion de l'espèce dans différents écosystèmes, chacun avec ses contraintes d'adaptation.
Cette métaphore m'a aidé à penser mon modèle. Ce qui est commun va dans la famille. Ce qui varie va dans les variantes. Ce qui se diffuse va dans les canaux.
Construire le modèle
Mon objectif : un PIM simple à implémenter. Assez complet pour alimenter une vraie plateforme e-commerce. Assez léger pour tenir dans un side-project.
Le cœur du modèle tient en quelques concepts. Des familles qui regroupent des attributs — chaque attribut ayant son type : texte, nombre, liste de valeurs. Des produits qui appartiennent à une famille et peuvent être parents ou variantes. J'ai limité à deux niveaux : un produit parent avec ses enfants directs, pas de sous-variantes. Pourquoi ? Parce que c'est ce que les marketplaces supportent. Amazon, Shopify, Prestashop — tous fonctionnent ainsi. Si vous avez besoin de plus de niveaux, vous êtes probablement dans un cas de configurateur industriel, pas de PIM commercial.
Ensuite, les canaux et les langues. Un même produit peut avoir une description différente pour votre site français et pour Amazon Allemagne. Les valeurs d'attributs sont donc stockées par canal et par langue.
Et puis les catégories pour l'arborescence de navigation, les médias pour les images et documents. Une dizaine d'entités en tout. Assez pour être utile, assez peu pour rester maintenable.
Mais une base de données produit n'est pas un PIM. Ce qui fait la différence, c'est la gouvernance.
J'ai ajouté un cycle de vie aux produits : brouillon, en révision, approuvé, publié, archivé. Avec des règles de transition simples — qui peut passer un produit d'un statut à l'autre, et dans quel ordre.
Un statut global ne suffisait pas. Un produit peut être publié sur votre site français mais pas encore sur Amazon. J'ai donc ajouté un statut par canal, avec la date de dernière publication et les éventuelles erreurs. D'un coup d'œil, je vois maintenant : "Ce produit est approuvé, publié sur e-commerce FR, en erreur sur Amazon DE."
La publication : là où tout prend sens
C'est ici que la différence avec Hybris devient flagrante.
Un sync job Hybris copie des données d'un catalogue interne à un autre. C'est une réplication.
Un job de publication PIM envoie des données vers des systèmes externes. C'est une syndication.
Le principe est simple : un job interroge le PIM, récupère les produits approuvés, collecte leurs attributs et variantes pour le canal cible, construit un payload adapté au format attendu, et envoie. Puis il met à jour le statut de publication.
Prenez un e-commerce headless. Le job construit un objet avec les infos du parent, la liste des variantes avec leurs SKU et prix, les URLs des médias. Il envoie ça à l'API du front. Si ça passe, il note la date. Si ça échoue, il stocke l'erreur.
Le produit reste dans le PIM. Il n'est pas dupliqué. Il est diffusé.
C'est cette logique de diffusion qui m'a fait comprendre ce qui manquait à Hybris. PCM réplique en interne. Un PIM publie vers l'extérieur. La différence paraît subtile, mais elle change tout dans la façon de penser son architecture.
Ce qu'on peut construire avec ce socle
En arrivant au bout de ce projet, j'ai réalisé que ce modèle minimal ouvre plusieurs possibilités.
Un mini-PIM SaaS pour les petits e-commerçants qui veulent mieux qu'une feuille Excel mais n'ont pas besoin d'Akeneo. Un back-office e-commerce headless où le PIM gère le contenu et un front séparé gère l'expérience. Un hub de syndication multicanal pour pousser vers Amazon, Cdiscount, Google Shopping — un mini-Lengow maison. Un product hub interne pour centraliser des données éparpillées entre ERP, fichiers Excel et têtes de commerciaux. Ou encore un PIM augmenté par l'IA, où des LLM génèrent des descriptions et suggèrent des attributs manquants.
Ce que ce voyage m'a appris
Construire mon propre PIM m'a forcé à comprendre chaque concept en profondeur. Pourquoi une famille n'est pas une catégorie. Pourquoi deux niveaux de variantes suffisent pour le commerce. Pourquoi le statut par canal change tout.
Le message que je retiens : vous n'avez pas besoin d'un mastodonte pour démarrer. Un modèle de données propre, quelques règles de workflow bien pensées, et une logique de publication claire — ça suffit pour un PIM utile.
Et maintenant ?
Ce PIM minimal est une fondation. Les prochaines étapes possibles : calculer la complétude par famille et par canal, brancher un LLM pour l'enrichissement automatique, créer des connecteurs vers Shopify ou Amazon, permettre l'import en masse depuis un CSV ou un ERP.
Mais tout ça, c'est de l'optimisation. Le cœur est là : familles, attributs, produits, variantes, canaux, statuts, publication.