Développer son propre PIM revient à construire une base de données produit avec une interface de saisie, ce qui se fait vite. Le coût apparaît ensuite, sur les fonctions que personne n'avait chiffrées : règles de complétude par canal, statuts de traduction, gestion des médias et de leurs déclinaisons, droits par rôle, exports par plateforme, montées de version. Le projet se juge donc sur trois ans, pas sur la première livraison.
Construire ou adopter : les critères examinés ici
Les trois coûts d'un PIM développé en interne
Le coût de couverture. Un référentiel ne se résume pas à stocker des attributs. Les fonctions qui font sa valeur, contrôle, statuts, médias, exports, représentent l'essentiel du développement et sont découvertes au fil de l'eau.
Le coût de maintenance. Un outil interne demande une équipe disponible en continu, pour les corrections, les évolutions du modèle et les montées de version des briques techniques sous-jacentes.
Le coût de dépendance. Quand la connaissance du code repose sur une ou deux personnes, leur départ transforme un actif en risque.
Ce qu'on construit vraiment quand on construit un PIM
La décision se prend souvent sur une intuition juste : nos produits sont spécifiques, une base et quelques écrans suffiront. Cette intuition est juste sur le périmètre visible et fausse sur le reste.
Ce qui est visible, c'est le modèle de données et la saisie. Une équipe technique compétente livre cela en quelques semaines, et la démonstration interne est convaincante.
Ce qui ne l'est pas, c'est tout ce qui transforme une base en référentiel : des règles de complétude qui varient selon la destination, des statuts qui bloquent la publication d'une traduction en cours, une gestion des médias avec leurs déclinaisons et leurs droits, des droits d'accès par rôle et par famille de données, un historique des modifications par champ, et autant d'exports que de canaux, chacun avec son format et sa nomenclature.
Aucune de ces fonctions n'est difficile prise isolément. Leur somme représente plusieurs années-homme, et c'est exactement ce qu'une plateforme apporte déjà.
Ce qui manque presque toujours à la version 1
Cinq manques reviennent dans les référentiels internes que nous reprenons.
Les règles de complétude par canal, absentes ou codées en dur.
Les statuts de traduction, remplacés par des colonnes par langue.
Les médias, laissés sur un serveur avec un nom de fichier.
L'historique des modifications, jamais prévu au départ.
Les exports, développés un par un à chaque nouveau canal.
Le cinquième manque est celui qui coûte le plus. Chaque nouvelle destination demande un développement spécifique, alors qu'une plateforme traite le sujet par paramétrage. C'est le point où l'écart de coût s'inverse, généralement au deuxième ou troisième canal.
Le coût qui arrive après la livraison
Un outil interne n'est pas livré, il est entretenu. Cette différence explique la plupart des mauvaises surprises budgétaires.
Il faut d'abord suivre les briques techniques. Un framework, une base de données et une bibliothèque de traitement d'images ont leurs propres cycles de version, avec des correctifs de sécurité à appliquer. Sur une plateforme, ce travail est mutualisé entre tous ses utilisateurs. Sur un outil interne, il est intégralement à votre charge.
Il faut ensuite faire évoluer le modèle. Un catalogue vivant ajoute des familles, des attributs, des langues. Sur une plateforme, un paramétrage suffit le plus souvent. Sur un outil interne, chaque évolution passe par du développement, une recette et une mise en production.
Il faut enfin assumer la formation et la documentation. Six mois après la livraison, les nouveaux arrivants n'ont ni support ni communauté, et la connaissance se transmet oralement. C'est ce que nous constatons régulièrement lors des reprises que nous menons comme intégrateur PIM/DAM.
Les cas où construire se justifie
Ils existent, et les ignorer rendrait cet article malhonnête.
Une base produit qui alimente un seul canal, sans médias, sans multilingue et sans exports normés. Une plateforme serait surdimensionnée.
Certains secteurs manipulent des objets qu'aucune plateforme ne modélise correctement. Le développement se justifie alors sur ce noyau précis, pas sur tout le référentiel.
Une organisation qui dispose d'une équipe de développement stable, avec une feuille de route et un budget de maintenance identifiés, peut porter un outil dans la durée.
La troisième situation mérite une précision : il s'agit d'une équipe dédiée au produit interne, pas de développeurs déjà affectés à d'autres priorités. C'est la condition la plus souvent surestimée.
La voie intermédiaire qu'on oublie
Le débat est souvent posé comme un choix binaire, alors qu'il ne l'est pas.
Une plateforme ouverte permet de construire votre modèle de données sans partir de zéro. Vous définissez vos objets, vos attributs et vos relations comme dans un développement interne, mais vous héritez de tout le reste : contrôle de complétude, statuts, médias, droits, historique, exports. Le sur-mesure porte alors sur ce qui vous est spécifique, pas sur les fonctions que tout référentiel doit avoir.
C'est cette voie que nous privilégions. Elle répond à la raison qui pousse à développer, la spécificité du catalogue, sans en payer le prix, qui est la reconstruction de fonctions déjà résolues ailleurs.
Construire ou adopter, selon votre équipe
Le critère décisif est la capacité à maintenir dans la durée, pas la capacité à construire.
Adopter, dans la quasi-totalité des cas. La complexité vient du modèle de données, et une plateforme ouverte laisse la liberté nécessaire sans exiger de reconstruire les fondations.
Adopter également. Les exigences documentaires et réglementaires demandent des fonctions médias et des statuts qu'un développement interne sous-estime systématiquement.
Adopter dès le deuxième canal. Chaque plateforme de vente ajoute un export, et c'est précisément là qu'un outil interne devient un puits de développement.
Dans les trois cas, posez la question de la maintenance sur trois ans avant celle du développement initial. C'est elle qui décide.
Partenaire-intégrateur officiel Pimcore sur le marché français, nous construisons des modèles de données adaptés à chaque catalogue sur une plateforme ouverte, et nous reprenons régulièrement des référentiels développés en interne pour les faire évoluer sans repartir de zéro.
Vous voulez savoir ce que couvrirait déjà une plateforme sur votre périmètre ?
Notre Blog
Nos derniers articles
Tendances, conseils, retours d’expérience : nos articles décryptent les sujets clés de votre transformation.
Faut-il développer son propre PIM en interne ?
Développer son propre PIM revient à construire une base de données produit avec une interface de saisie, ce qui se fait vite. Le coût apparaît ensuite, sur les fonctions que personne n’avait chiffrées : règles de complétude par canal, statuts de traduction, gestion des médias et de leurs déclinaisons, droits par rôle, exports par plateforme, montées de version. Le projet se juge donc sur trois ans, pas sur la première livraison.
DAM ou GED : lequel pour vos fichiers produits ?
Une GED conserve les documents de l’entreprise et en assure la traçabilité : contrats, procédures, pièces réglementaires, avec versions, archivage et valeur probante. Un DAM organise les fichiers destinés à être diffusés : visuels, plans, notices, certificats, avec métadonnées, déclinaisons par canal et droits d’usage. Les deux se croisent sur un point, le document technique produit, et ce croisement explique la plupart des confusions.
PIM ou CMS : pourquoi le site ne suffit pas
Un CMS gère des pages et leur publication sur un site. Un PIM gère la donnée produit et sa diffusion vers tous les canaux, site compris. Avec un seul canal, le back-office du CMS couvre les besoins de saisie. Dès qu'une marketplace, un portail revendeurs ou un catalogue imprimé s'ajoute, le site n'est plus la source de la donnée produit : il devient un canal de diffusion parmi d'autres.