Un CMS gère des pages et leur publication. Un PIM gère la donnée produit et sa diffusion vers tous les canaux, dont le site. Tant qu'il n'existe qu'un seul canal, le back-office du CMS donne l'illusion de suffire. Dès qu'une marketplace, un portail revendeurs ou un catalogue entrent en jeu, le site cesse d'être la source et redevient ce qu'il est : un consommateur de données parmi d'autres.
Site web et référentiel produit : ce que démêle cet article
Ce que le CMS ne sait pas faire
Il ne type pas la donnée. Une caractéristique saisie dans un champ de description n'est ni filtrable, ni comparable, ni exportable. Le CMS la traite comme du texte, parce que c'est son métier.
Il ne connaît qu'un canal. Un CMS publie sur son site. Il n'a pas de notion d'attribut obligatoire selon la destination, ni de mapping par plateforme.
Il ne gère pas les statuts de traduction. Une version linguistique en cours de relecture n'est pas distinguée d'une version validée, ce qui finit par partir en production.
Deux objets, deux responsabilités
Quatre critères suffisent à situer chacun dans son rôle, et le dernier est celui qui tranche.
| Critère | CMS | PIM |
|---|---|---|
| Objet géré | Pages, blocs, contenus éditoriaux | Objets produits et leurs attributs |
| Structure | Libre, orientée mise en page | Typée, par famille de produits |
| Destination | Le site qu'il pilote | Tous les canaux, dont le site |
| Contrôle avant publication | Sur la page | Sur la complétude par canal |
La dernière ligne est celle qui départage. Un CMS vérifie qu'une page est complète au sens de la mise en page. Un PIM vérifie qu'un produit est complet au sens de la destination visée, et cette vérification n'a pas le même objet selon qu'il s'agit d'un site, d'une marketplace ou d'un catalogue imprimé.
Les deux ne sont pas concurrents. Le CMS reste responsable de l'expérience et du contenu éditorial, le PIM de la donnée produit qui l'alimente.
Pourquoi le back-office donne l'illusion de suffire
Sur un site unique et un catalogue restreint, le back-office fait le travail, et c'est précisément ce qui piège.
Les fiches produits y sont saisissables, les images s'y déposent, les champs personnalisés existent. Une équipe de deux personnes tient l'ensemble sans difficulté apparente. Le coût n'apparaît pas parce qu'il n'y a rien à comparer.
Le problème est que cette organisation ne se teste que lorsqu'un deuxième consommateur apparaît. À ce moment, la donnée doit sortir du site, et l'on découvre qu'elle n'a jamais été structurée pour cela : les caractéristiques sont dans des descriptions, les unités varient, les visuels n'existent qu'au format web, et personne ne sait quelles fiches sont complètes.
Le second piège est la correction en aval. Une équipe qui corrige directement dans le back-office alors qu'un flux alimente le site verra sa correction disparaître au prochain export. Ce point revient dans presque tous les audits que nous menons comme intégrateur PIM/DAM.
Ce qui se casse au deuxième canal
L'ajout d'une destination révèle en quelques semaines ce qui manquait depuis des années.
Chaque plateforme impose ses attributs obligatoires et sa nomenclature. Un texte de description ne se convertit pas en attribut typé, il faut ressaisir.
Fiches techniques, notices, tarifs par partenaire. Rien de tout cela n'a sa place dans un CMS orienté vitrine.
Le site stocke des images compressées. La chaîne graphique attend de la haute définition, qui n'existe nulle part dans le CMS.
Dans les trois cas, la réponse improvisée est la même : un tableur d'export, repris à la main, maintenu en parallèle. C'est le moment précis où le catalogue commence à diverger d'un canal à l'autre.
Les signaux qui montrent que le site fait office de référentiel
Six situations indiquent que la donnée produit vit dans le CMS alors qu'elle ne devrait pas.
Les caractéristiques techniques sont dans le champ description.
Un export du site sert de base pour alimenter un autre canal.
Les corrections se font dans le back-office puis se perdent.
Personne ne sait quelles fiches sont incomplètes.
Les visuels n'existent qu'au format web.
Les traductions sont des pages dupliquées.
Trois signaux réunis suffisent à justifier un cadrage. Le quatrième est le plus révélateur : un CMS ne sait pas répondre à la question du taux de complétude, parce que la notion n'existe pas dans son modèle.
Ce que devient le CMS une fois le PIM en place
La mise en place d'un référentiel ne remplace pas le site, elle lui rend son rôle.
Après la mise en place d'un PIM, le CMS cesse de gouverner la donnée produit et redevient responsable de ce qu'il fait le mieux : l'expérience, la navigation, le contenu éditorial et la conversion. La règle qui rend cela possible tient en une phrase : aucune donnée produit ne se modifie dans le back-office du site. Sans cette discipline, les deux systèmes divergent en quelques semaines.
Concrètement, le référentiel pousse vers le site un sous-ensemble d'attributs, filtré par les règles de complétude et accompagné des visuels au format web. Le CMS conserve la main sur les pages de marque, les guides d'achat, les mises en avant et tout ce qui relève de l'éditorial, qui ne vient pas du catalogue.
Ce qu'il faut sortir du site selon votre activité
Le premier chantier n'est pas le même selon la nature de votre catalogue.
Sortez les attributs techniques et les unités. Tant qu'ils vivent dans des descriptions, ni les filtres du site ni les exports normés ne sont fiables.
Sortez la documentation. Notices, certificats et fiches normées n'ont pas leur place dans un CMS, et leur validité doit être contrôlée avant diffusion.
Sortez le mapping par canal. C'est ce qui vous permettra d'ouvrir une marketplace sans repartir d'un export retravaillé à la main.
Dans les trois cas, le site reste en place. Ce qui change, c'est qu'il cesse d'être l'endroit où la donnée est décidée.
Partenaire-intégrateur officiel Pimcore sur le marché français, nous sortons la donnée produit des back-offices de site pour la structurer en référentiel, puis nous réalimentons le site avec les attributs et les médias dont il a besoin. Le reste part vers les autres canaux depuis la même source.
Vous voulez savoir quelle part de votre donnée produit vit aujourd'hui dans votre site ?
Notre Blog
Nos derniers articles
Tendances, conseils, retours d’expérience : nos articles décryptent les sujets clés de votre transformation.
PIM ou CMS : pourquoi le site ne suffit pas
Un CMS gère des pages et leur publication. Un PIM gère la donnée produit et sa diffusion vers tous les canaux, dont le site. Tant qu’il n’existe qu’un seul canal, le back-office du CMS donne l’illusion de suffire. Dès qu’une marketplace, un portail revendeurs ou un catalogue entrent en jeu, le site cesse d’être la source et redevient ce qu’il est : un consommateur de données parmi d’autres.
Pourquoi choisir Pimcore pour un projet PIM/DAM
Automatiser un catalogue print consiste à faire alimenter des gabarits de mise en page directement par le référentiel produit, plutôt que de saisir ou de copier les données dans la maquette. La chaîne se lit en quatre temps : structurer la donnée, préparer les médias, concevoir les gabarits, puis générer et relire. Le préalable est un référentiel fiable : sans données typées et sans médias associés, l’automatisation produira des pages fausses plus vite qu’un studio ne produisait des pages justes.
Automatiser son catalogue print avec les données PIM
Automatiser un catalogue print consiste à faire alimenter des gabarits de mise en page directement par le référentiel produit, plutôt que de saisir ou de copier les données dans la maquette. La chaîne se lit en quatre temps : structurer la donnée, préparer les médias, concevoir les gabarits, puis générer et relire. Le préalable est un référentiel fiable : sans données typées et sans médias associés, l’automatisation produira des pages fausses plus vite qu’un studio ne produisait des pages justes.