Pimcore vs. AtroCore : Comparaison de deux plateformes MDM open source

Pimcore et AtroCore sont deux des plateformes open source les plus largement discutées pour la gestion des données de référence (MDM) et la gestion des informations produit (PIM). Toutes deux visent à établir une source unique de vérité pour les données produit et de référence. Mais elles adoptent des approches très différentes en matière d'architecture, de configuration, de licence et de répartition du travail au quotidien.

Pimcore : une plateforme numérique intégrée

Pimcore s'est repositionné ces dernières années en tant que plateforme de gestion de l'expérience produit (PXM), combinant PIM, MDM, DAM, CMS et commerce numérique dans un seul système. Elle cible les organisations qui souhaitent un environnement unique pour couvrir des structures de données complexes et la publication omnicanal.

Pimcore est construite sur le framework Symfony. Ses objets de données prennent en charge l'héritage, les classifications et les structures multi-domaines, ce qui la rend pratique lorsque les capacités CMS ou de commerce numérique doivent coexister avec PIM et MDM dans le même environnement.

Le compromis réside dans la complexité. La création de nouvelles classes d'objets de données ou l'implémentation de logiques métier personnalisées nécessitent généralement des développeurs. Les changements structurels ne se font pas dans l'interface utilisateur. Pour les organisations aux exigences stables et bien définies avec une équipe d'ingénierie interne, c'est acceptable. Pour les autres, cela ajoute des frictions et des coûts d'implémentation.

AtroCore : une plateforme modulaire axée sur la configuration

AtroCore est une plateforme MDM et PIM open source modulaire construite autour d'un principe unique : les personnes qui comprennent les données doivent pouvoir configurer le système, pas seulement celles qui écrivent le code. Elle est sous licence MIT, auto-hébergeable ou déployable en local, et conçue pour que les administrateurs gèrent l'essentiel du travail de configuration sans ouvrir un environnement de développement.

AtroPIM est construit sur AtroCore et étend la plateforme avec des capacités dédiées de gestion des informations produit. Les fabricants, les distributeurs et les détaillants l'utilisent pour gérer des catalogues produits complexes sur plusieurs canaux et systèmes.

Un administrateur dans AtroCore peut configurer :

• le modèle de données : champs, attributs, relations, entités de différents types, y compris les hiérarchies
• les interfaces utilisateur : profils de mise en page et différentes vues par glisser-déposer
• les pipelines de données : comment les données se déplacent automatiquement entre les entités source et de préparation, y compris la logique de transformation et de normalisation
• les règles de correspondance : comment les enregistrements sont comparés et identifiés comme doublons entre les sources
• les règles de vérification de la qualité des données : les conditions qui signalent, classent ou bloquent les enregistrements en fonction de l'exhaustivité, du format ou de la cohérence
• la logique de consolidation : comment les valeurs en conflit provenant de plusieurs sources sont résolues, y compris les règles de survivance qui déterminent quelle source l'emporte par champ
• les notifications et l'automatisation : les règles, les conditions et les actions automatiques
• la validation des données : champs obligatoires, formats, valeurs autorisées

Tout cela sans code ni déploiement.

Un fabricant avec lequel nous travaillons avait besoin d'ajouter un nouveau groupe d'attributs pour les spécifications d'emballage dans 12 000 SKU. Un administrateur a créé le groupe d'attributs dans AtroCore, l'a assigné à l'entité pertinente, a défini les règles d'héritage et a publié la modification. L'opération a pris moins d'une heure. Dans un système dépendant des développeurs, la même tâche reste dans un carnet de commandes, passe par un sprint et arrive en production plusieurs semaines plus tard, moment auquel les exigences ont souvent changé.

Les cycles d'implémentation s'accélèrent. Le délai de mise sur le marché pour les changements du modèle de données passe de semaines à heures. Les fabricants et distributeurs de taille moyenne en bénéficient le plus : une complexité de données suffisante pour nécessiter une véritable couche MDM, mais pas la capacité d'ingénierie interne pour traiter chaque changement de configuration comme un projet logiciel.

Architecture et philosophie de conception

Pimcore utilise Symfony comme fondation et l'étend en un écosystème multifonctionnel. Son architecture suit une philosophie de conception monolithique où PIM, MDM, DAM et CMS travaillent ensemble par une couche de base de données partagée et une API. Une personnalisation approfondie est possible, mais elle nécessite généralement une implication développeur importante. Du côté de la base de données, Pimcore s'exécute sur MySQL ou MariaDB via Doctrine DBAL. L'interface Studio nécessite également Elasticsearch ou OpenSearch comme moteur de recherche obligatoire pour filtrer et interroger les grands ensembles de données, une dépendance d'infrastructure supplémentaire que les équipes auto-hébergées ou locales doivent planifier.

AtroCore est construit sur des normes PHP ouvertes (PSR-7, PSR-11, PSR-15), utilise Doctrine DBAL pour l'interaction avec la base de données et FastRoute pour le routage HTTP. L'architecture s'inspire de Laminas/Mezzio et Symfony mais sans leur complexité. PostgreSQL, MySQL et MariaDB sont tous supportés comme moteur de base de données principal, sans dépendance obligatoire de moteur de recherche.

Le choix de la base de données compte à grande échelle. PostgreSQL gère les requêtes complexes sur les grands ensembles de données significativement mieux que MySQL ou MariaDB. Pour les implémentations MDM gérant des millions d'enregistrements sur plusieurs domaines, cet écart de performance est réel. Les équipes exécutant AtroCore sur PostgreSQL obtiennent cette capacité supplémentaire en option standard, ce qui en fait l'option d'infrastructure la plus solide pour les cas d'usage MDM à haut volume.

Modélisation des données et flexibilité structurelle

La modélisation des données de Pimcore est sophistiquée mais menée par les développeurs. Les types d'objets complexes, les modèles d'héritage et les classifications structurées sont réalisables. Pour y arriver, il faut généralement que les programmeurs définissent les classes d'objets et implémentent la logique pour répondre aux besoins architecturaux plus larges, ce que l'équipe de données produit ne gère pas seule.

AtroCore utilise une approche de modélisation sans code. Les utilisateurs peuvent créer ou modifier des entités, des champs, des attributs et des relations via l'interface d'administration sans toucher au code. Les règles d'héritage sont configurables par champ. Les classifications et les associations peuvent être appliquées à n'importe quel domaine, y compris les domaines personnalisés. Des champs personnalisés peuvent être ajoutés directement via l'interface d'administration dans les relations plusieurs-à-plusieurs. Lorsqu'une catégorie de produit nécessite un nouvel ensemble d'attributs techniques, ou lorsqu'une entité fournisseur a besoin qu'un champ de conformité soit ajouté avant un audit, ces changements se font dans l'interface, pas dans une file d'attente de tickets.

Expérience utilisateur et facilité d'utilisation administrative

Le panneau d'administration Pimcore couvre un large éventail de tâches de contenu et de données. La courbe d'apprentissage est raide, en particulier pour les gestionnaires de catalogues qui ne travaillent qu'avec des données produit. L'interface d'administration héritée a été construite sur ExtJS et n'était pas mobile.

Pimcore Studio, lancé avec la version 2025.1, remplace cette interface par une interface moderne basée sur React construite sur Ant Design, TypeScript et Redux. Elle est plus rapide, visuellement plus propre et plus accessible aux utilisateurs non techniques. La version 2026.1 a supprimé l'interface d'administration héritée, faisant de Studio la seule interface. L'écart de convivialité mobile qui existait depuis des années s'est réduit, mais Studio est un changement récent et les équipes sur les anciennes versions de Pimcore n'en ont pas encore bénéficié.

L'interface d'AtroCore est mobile dès le départ et fonctionne sur tous les appareils sans étape de configuration supplémentaire. Mais l'accès mobile n'est pas le principal différenciateur pour la plupart des équipes de données. Ce qui compte davantage, c'est que les gestionnaires de catalogues, les responsables de données et les propriétaires de produits puissent faire un travail significatif sans aide au développement. Les profils de mise en page, la visibilité des champs, les modes d'affichage et les configurations spécifiques à l'utilisateur sont tous gérés via l'interface. Un responsable de données peut ajuster les champs qui apparaissent dans une vue grille pour son équipe sans remplir un ticket d'assistance. Un chef de produit peut définir des règles de validation pour une nouvelle catégorie de produit le même jour où la catégorie est créée.

Fonctionnalité MDM

Le framework MDM de Pimcore prend en charge les domaines de données de référence complexes avec des types d'objets avancés, des structures d'héritage, des attributs multilingues, des taxonomies hiérarchiques et des graphes de relations détaillés. La couche MDM gère la gestion des versions, les flux de travail, les règles de qualité des données, les contrôles de validation, les processus d'approbation et les pistes d'audit. La capacité est réelle. Pour y arriver, il faut du temps développeur et une planification architecturale.

La couche MDM d'AtroCore est entièrement configurable par l'interface : entités, champs et attributs multilingues, taxonomies hiérarchiques avec support multi-parents, relations, flux de travail de responsable de données, règles de qualité des données, déduplication, création d'enregistrement d'or, validation, historique des modifications et gouvernance basée sur les rôles. Ce ne sont pas des substituts légers aux fonctionnalités d'entreprise. Ce sont les mêmes capacités, construites pour être exploitées par les personnes responsables de la qualité des données plutôt que par les développeurs maintenant la plateforme en leur nom.

Pour les équipes qui ont besoin de plus, l'architecture modulaire d'AtroCore permet d'ajouter de nouvelles entités ou fonctionnalités de gouvernance via la configuration ou les modules légers. L'augmentation de la complexité MDM ne signifie pas l'augmentation de la dépendance aux développeurs.

La différence la plus pratique entre les deux plateformes réside dans la vitesse d'itération de la gouvernance. Une nouvelle règle de validation dans AtroCore est un changement de configuration. Dans Pimcore, c'est une tâche de développement. Au cours d'une année, ces différences s'accumulent considérablement pour les équipes gérant des catalogues produits ou des données de fournisseurs en évolution.

Extensibilité et maintenance

Pimcore prend en charge un développement personnalisé étendu via les bundles Symfony et son système de plugins. Les flux de travail complexes, les intégrations et les modules spécifiques au domaine peuvent être construits pour les organisations ayant de fortes capacités d'ingénierie interne. C'est un ajustement solide pour les entreprises qui traitent leur couche MDM comme un produit logiciel maintenu par une équipe interne.

Le modèle d'extensibilité d'AtroCore est stratifié. La plupart des exigences se résolvent au niveau de la configuration : un nouveau type d'entité, un champ personnalisé, une règle de flux de travail, une condition de correspondance. Quand la configuration ne suffit pas, la bibliothèque de modules couvre le prochain niveau : automatisation avancée de la qualité des données, orchestration de flux de travail avancée, intégrations plus profondes. Le développement de modules personnalisés existe pour les exigences au-delà de cela. Dans les projets que nous avons implémentés, la plupart des fabricants atteignent la production sans toucher au code personnalisé. Quand ils ont besoin d'un module, il étend un noyau stable plutôt que d'appliquer un correctif autour. Cette distinction compte pour la maintenance à long terme : les mises à jour restent prévisibles et le système n'accumule pas de dette technique à partir de correctifs ponctuels.

Intégration

Pimcore est API-first mais manque de connecteurs natifs. L'intégration avec les systèmes externes dépend de fournisseurs tiers ou du développement personnalisé.

AtroCore comprend des connecteurs natifs pour les plateformes CRM largement utilisées, notamment Salesforce et HubSpot, les systèmes ERP, notamment SAP et Microsoft Dynamics, et les plateformes e-commerce, notamment Shopify et WooCommerce. Chaque connecteur est entièrement personnalisable via l'interface. Les nouveaux scénarios d'intégration peuvent être configurés sans écrire de middleware personnalisé. Pour les fabricants et distributeurs exécutant des paysages de systèmes complexes, cela réduit à la fois le coût et le délai d'intégration.

Licence, communauté et coûts

Pimcore a fonctionné sous une licence GPLv3 pendant 15 ans. À partir de la version 2025.1, elle s'est convertie à la licence Pimcore Open Core (POCL). La version 2024.4 a été la dernière version GPLv3. La POCL est source-disponible : vous pouvez consulter, modifier et utiliser le code, mais la redistribution et la relicence sont restreintes. Ce n'est pas de l'open source au sens traditionnel.

L'édition Community reste gratuite pour les organisations ayant un chiffre d'affaires annuel inférieur à 5 millions d'euros, les organismes à but non lucratif et les institutions académiques. Au-delà de ce seuil, une licence commerciale est requise. L'édition Professional commence à 8 400 euros par an ; l'édition Enterprise à environ 25 200 euros par an. Les équipes sur les anciennes versions de Pimcore doivent également noter que le support GPLv3 prend fin à la fin de 2026, après quoi les correctifs de sécurité ne seront plus disponibles pour les versions antérieures à 2025.1.

Pour les entreprises déjà sur les éditions Professional ou Enterprise en vertu d'un accord commercial, le changement POCL ne change rien. Mais pour les équipes sur l'édition Community qui envisagent de mettre à niveau, ou pour les équipes d'approvisionnement évaluant le risque de licence, c'est une considération importante. Les dispositions de copyleft de la GPLv3 créaient des frictions juridiques dans les environnements d'entreprise : risque de contamination de licence, complexité des audits, conflits avec des réglementations comme NIS2. La POCL supprime ces frictions. Le coût est que Pimcore n'est plus un véritable logiciel libre pour les organisations au-dessus du seuil de chiffre d'affaires.

AtroCore est sous licence MIT sans seuil de chiffre d'affaires et sans niveaux d'édition pour la plateforme de base. Un fabricant avec 50 millions d'euros de chiffre d'affaires annuel exécute la même base de code qu'une startup : les mêmes fonctionnalités, le même accès au code source, la même capacité à s'auto-héberger sans une conversation de licence. Pour les équipes d'approvisionnement dans les fabricants et distributeurs de taille moyenne, cela supprime une catégorie de risque qui est devenue de plus en plus pertinente à mesure que d'autres plateformes se sont déplacées dans la direction de Pimcore. Le coût total de possession est inférieur pour les déploiements axés sur MDM : pas de dépendances d'infrastructure obligatoires, pas de frais de licence et une configuration sans code qui réduit les coûts de conseil en implémentation. Des modules payants existent pour des capacités étendues spécifiques, mais la fonctionnalité MDM de base n'entraîne aucun coût de licence indépendamment de la taille de l'entreprise.

Pimcore a la plus grande communauté et un plus long historique. Pour les organisations évaluant la maturité de l'écosystème aux côtés de la capacité de la plateforme, c'est une véritable entrée dans la décision. Cela n'annule pas les frais de licence ou la configuration dépendante du développeur pour les équipes exécutant les opérations MDM quotidiennes, mais cela compte lors de l'évaluation des options de support à long terme et de la disponibilité des partenaires.

Pimcore vs. AtroCore : Comparaison côte à côte

Quand utiliser chaque plateforme

Elles ne résolvant pas le même problème.

Pimcore convient aux organisations qui ont besoin de CMS, de commerce, de DAM et de MDM sous un même toit et qui disposent d'une équipe de développement pour la gérer. Les entreprises dirigées par l'ingénierie avec des exigences stables et bien définies et une appétit pour la gestion de l'expérience omnicanal obtiennent une véritable valeur de sa profondeur. Les équipes au-dessus du seuil de 5 millions d'euros de chiffre d'affaires doivent factoriser les coûts de licence aux côtés des coûts de mise en œuvre lors de l'évaluation du coût total de possession.

Le véritable coût pour les équipes axées sur MDM n'est pas la licence. C'est le temps développeur dépensé pour les changements qui auraient dû prendre un après-midi. AtroCore est construit autour de cette contrainte. Les structures de données, les règles de gouvernance et les processus métier changent, et dans la fabrication et la distribution, ils changent souvent. Les administrateurs configurent les modèles de données, les flux de travail, les règles de correspondance et la logique de fusion via l'interface. Le système s'étend à mesure que les exigences croissent : d'abord par la configuration, ensuite par les modules, et par le développement personnalisé seulement quand c'est véritablement nécessaire.

Les équipes techniques obtiennent une plateforme stable et maintenable. Les équipes métier obtiennent la capacité d'agir sur les données sans acheminer chaque changement par un carnet de commandes d'ingénierie.