Ne plus voir l'ERP, usine à données, sous le seul angle de l'outil de gestion
Dans beaucoup d'organisations, l'ERP est encore présenté comme un outil de gestion, un projet d'efficacité opérationnelle, un sujet « métier ». C'est vrai, mais incomplet. Parce que l'ERP est aussi une usine à données. Il enregistre les ventes, les achats, les stocks, la production, la finance et parfois les ressources humaines. Il impose des référentiels, des formats, des règles de saisie. Et il fabrique, jour après jour, une partie du patrimoine informationnel de l'entreprise, souvent plus que n'importe quelle autre application.
Cette réalité saute généralement aux yeux lors d'un changement d'ERP.
L'énergie et le budget se concentrent sur le cœur applicatif, la reprise des processus, la formation, les paramétrages et la bascule. Et le contexte data autour, BI, interfaces, master data, usages aval, passe au second plan.
Non par négligence, mais parce que le calendrier et la pression du go-live aspirent tout.
C'est pourtant une erreur classique, et surtout une erreur coûteuse. La migration est soi-disant « réussie », puis l'on découvre que les tableaux de bord ne remontent plus, que les flux ne sont pas stabilisés, que les définitions métiers divergent et que la fiabilité des indicateurs devient un sujet politique.
Le point de rupture est souvent là. Sans alignement data, l'ERP finit par se refermer sur lui-même. Il devient un silo, non pas parce qu'il est mal choisi, mais parce que l'on a oublié qu'il devait nourrir un écosystème. Et ce défaut se paie ensuite dans tous les projets aval, digitalisation, pilotage, automatisation, IA...
La question change alors de nature. Il ne s'agit plus de choisir un outil, il s'agit de choisir une fondation.
Une stratégie data sans ERP ouvert, c'est de la théorie
Une stratégie data peut être séduisante sur le papier, mais elle devient purement théorique si l'ERP n'est pas conçu pour exposer et recevoir des données de manière maîtrisée. Les API, les services, les connecteurs natifs, l'événementiel… tout cela n’a rien à voir avec un quelconque « luxe technique ». C'est tout simplement la condition pour alimenter correctement des applications digitales, des portails, des outils métiers, et, de plus en plus, des briques d'IA.
Pourtant, cette ouverture ne va pas de soi. Un ERP peut proposer des interfaces, tout en restant difficile à intégrer. Les formats peuvent être incohérents, les modèles de données peu lisibles, les droits d'accès trop grossiers. L'entreprise se retrouve alors à bricoler des extractions, des scripts, des intégrations point à point. Elle produit de la data, mais au prix d'une dette technique, ce qui rend l'architecture fragile, et donc coûteuse à maintenir.
Le vrai sujet apparaît lorsqu’on externalise des processus. Un portail client, une application terrain, une brique e-commerce, un configurateur ou un agent IA, tous ces éléments déplacent des interactions en dehors de l'ERP, mais ils n'effacent pas le besoin d'une « source de vérité ». Si l'ERP reste cette source, il faut des flux bidirectionnels robustes, tracés, et un modèle de données clair. Sinon, l'entreprise fabrique des incohérences et des doublons. Un client existe deux fois, un prix diverge, un stock n'est pas à jour, une commande est saisie au mauvais endroit.
L'ouverture, ici, est une vraie discipline d'intégration.
C'est aussi à ce moment là que les arbitrages deviennent visibles. Veut-on que l'ERP porte toutes les règles, ou seulement une partie ? Jusqu'où laisse-t-on les applications aval enrichir la donnée ? Quelles écritures sont autorisées dans le cœur ? L'ERP ouvert n'est pas l'ERP permissif, c'est « juste » l'ERP qui sait précisément ce qu'il expose, à qui, et comment.
La gouvernance et le catalogue de données, un facteur clé des projets d'ERP souvent négligé
Quiconque l’a déjà vécu sait qu’un changement d'ERP est souvent vécu comme une contrainte, alors qu’il peut aussi être une occasion rare d'urbaniser son système d’information : revoir les flux, clarifier les usages, documenter ce qui circule, ce qui est redondant, ce qui est critique. Autrement dit, de remettre de la lisibilité dans un système d'information qui s'est parfois construit par couches successives.
C'est là que le catalogue de données prend une valeur très concrète. Un data catalog, au sens large, sert à tenir l'inventaire des données, à les décrire, à les organiser, et à donner du contexte aux équipes qui en ont besoin. Gartner, par exemple, définit le data catalog comme un inventaire des données actives, soutenu par la découverte, la description et l'organisation des ensembles de données, afin d'aider les acteurs à trouver et comprendre un dataset pour en extraire de la valeur. Dans un projet ERP, il est un outil de lucidité. Il permet de savoir où les données de l'ERP sont utilisées, par qui, et pour quoi. Il permet aussi de poser une question très simple avant de migrer : qu'est-ce qui dépend de quoi ?
Sans cette visibilité, la migration peut vite se transformer en partie de dés, où l’on avance dans le flou sur toutes les dépendances. Avec un catalogue, on peut au contraire cartographier les objets métiers, identifier les données sensibles, repérer les flux critiques, mesurer la qualité et préparer des usages plus avancés. C'est aussi le moment où les master data cessent d'être une notion abstraite. Les données de référence, clients, produits, fournisseurs, employés, sites, structurent les transactions et conditionnent la cohérence de l'ensemble.
Le chantier de gouvernance se joue alors sur des choix très pratiques. Qui est responsable de quel référentiel ? Où est la version de référence ? Dans l'ERP, dans un référentiel centralisé, dans un dispositif de MDM ? Et qui tranche quand deux définitions s'opposent ?
"Migrer ou changer son ERP, ce n'est jamais un petit sujet. Comme tout projet, 80% du succès réside dans la préparation. Un ERP, au fond, ce sont des processus, des données et des interfaces (humaines/ techniques avec le reste du SI). Maîtriser interfaces et données avant de démarrer, c'est déjà accomplir une grande partie du travail. C'est exactement là qu'une démarche de data gouvernance, et en premier lieu le data catalogue, prend tout son sens." partage Alexis de Saint-Jean, Product Marketing Director chez Blueway, a Softproject company.
Des sociétés de conseil et des éditeurs de logiciels s'inscrivent précisément dans cet univers où l'ERP ne peut plus être pensé hors de ses flux et d’une vision globale du patrimoine de données de l’entreprise. En effet, sinon, sans gouvernance et sans outillage de catalogage, beaucoup d’entreprises sont en quelque sorte condamnées à réapprendre leur propre SI à chaque projet.
À l'inverse, maîtriser son patrimoine de données conditionne la réussite du projet ERP, parce que cela réduit l'inconnu, donc le risque… donc le coût.
Garantie de la qualité des données : un enjeu partagé entre ERP et data
Une fois le socle posé, la question se déplace naturellement vers la qualité. Parce que la donnée n'a pas besoin d'être parfaite. Elle a juste besoin d'être fiable là où elle est utilisée. Et, dans un SI connecté, une erreur se propage vite.
La chaîne de valeur est connue, mais elle est souvent mal exécutée. L'ERP doit porter des référentiels et des règles propres (validation de champs, contrôles de cohérence, règles de gestion, etc.). La gouvernance data, elle, doit apporter des contrôles transverses, des validations, des enrichissements et parfois des mécanismes de consolidation. Il s’agit finalement plus d’un partage que d’une délégation.
Prenez un référentiel client, avec une adresse mal structurée, un doublon, une segmentation incohérente… La conséquence n'est pas seulement un CRM « plus sale ». Elle touche la facturation, le recouvrement, la logistique, puis les outils analytiques. Même chose pour un référentiel article. Une unité de mesure mal gérée peut faire diverger un stock. Un prix mal saisi peut produire des écarts entre canal e-commerce et point de vente. Un droit d'accès trop large peut exposer des données sensibles à des utilisateurs qui n'en ont pas besoin.
C'est ici qu'une approche de Master Data Management peut aider, sans être un passage obligé. Le MDM vise à maintenir une version fiable et à jour des données de référence (parfois appelée « golden record »). Il ne remplace pas l'ERP. Il organise la qualité et la cohérence des données maîtres quand elles vivent dans plusieurs systèmes, et quand l'entreprise ne peut plus compter sur un seul outil pour arbitrer.
L'enjeu, au fond, est de limiter les erreurs en cascade. Si l'ERP alimente tout, l'entreprise ne peut pas se permettre de traiter la qualité comme une question de reporting. Elle doit la traiter comme une question d'exploitation.
Sécurité et confidentialité : ne pas ouvrir l'ERP sans garde-fous
L'ouverture est devenue un critère de modernité, mais elle est aussi une exposition. Plus l'ERP est accessible via API, plus il faut maîtriser l'authentification, les autorisations, le chiffrement, les logs, la segmentation des droits et le cloisonnement des données sensibles. La tension est réelle, il faut réussir à servir le digital et l'IA tout en réduisant la surface d'attaque.
Sur ce terrain, les principes de base restent étonnamment stables. Le principe de moindre privilège, par exemple, consiste à limiter les accès aux seules données dont un utilisateur a besoin. La CNIL rappelle que ce principe permet de limiter les conséquences d'une usurpation de compte ou d'une erreur de manipulation. Appliqué à un ERP ouvert, cela implique des rôles fins, des permissions contrôlées, et une séparation claire entre lecture, écriture et administration.
La traçabilité est l'autre pilier. Pour les données personnelles, la CNIL, toujours, souligne que la gestion des profils peut s'accompagner d'un système de journalisation afin de tracer les activités et détecter les anomalies, comme les accès frauduleux ou les usages abusifs. Dans un SI moderne, cela se traduit par des logs exploitables, centralisés, et reliés à des processus de réponse à incident. L'ANSSI, de son côté, rappelle l'importance de structurer une politique de journalisation et d'en réévaluer périodiquement la pertinence dans une démarche d'amélioration continue.
L'ouverture de l'ERP n'est acceptable que si elle est gouvernée. Et la conformité se joue autant dans les pratiques que dans l'outil.
Un ERP peut proposer toutes les fonctions de sécurité, si les droits ne sont pas revus, si les logs ne sont pas exploités et si les exceptions deviennent la norme, l'entreprise se raconte clairement des histoires.
Faire travailler ensemble DSI, métiers, data et sécurité dès le choix de l'ERP
À la fin, la plupart des erreurs viennent d'un mauvais casting. Dans ces cas (à ne pas reproduire), l'ERP est choisi par les métiers, la data est portée par une autre équipe, la sécurité arrive plus tard (souvent sous la forme d'un contrôle) et l'intégration est confiée à une équipe projet en charge de « faire tenir » ce qui n'a pas été pensé ensemble en amont. Tout faux.
Le bon réflexe ici consiste à évaluer un ERP non seulement sur ses fonctions métiers, mais aussi sur son écosystème data, son intégrabilité, et sa capacité à tenir un modèle de sécurité robuste.
Cela suppose évidemment un cadrage des usages dès le départ :
- Quelles applications devront se connecter ?
- Quels flux devront être bidirectionnels ?
- Quelles données sont sensibles ?
- Quelles obligations s'appliquent ?
- Quel niveau de traçabilité est attendu ?
Cela suppose également de trancher la question de la « source de vérité » pour chaque domaine, et de formaliser les responsabilités.
Dans ce cadre, des acteurs comme TVH Consulting peuvent aider à comparer les différents ERP du marché sans se limiter à la démonstration fonctionnelle, en replaçant la décision dans l'architecture du SI et dans la réalité du patrimoine de données. L'objectif n'est pas d'alourdir le projet, mais de réduire l'inconnu.
Encore une fois, un ERP (bien choisi) n'est pas seulement un outil de gestion, c'est une fondation, un pilier très important, pour un SI agile, fiable et gouverné, capable d'absorber le digital et l'IA, en toute cohérence !