Pourquoi les ERP sont lents et coûteux à déployer — par conception

Joannes Vermorel

Toutes les quelques semaines, je rencontre un cadre qui est encore en train de “déployer l’ERP”. Le programme a démarré sous une précédente équipe de direction. Le budget est devenu un chiffre que personne ne souhaite répéter à voix haute. Et le post‑mortem, déjà à moitié rédigé, pointe du doigt le fournisseur, l’intégrateur, la “résistance au changement” ou l’unicité de l’entreprise. Cette histoire est si commune qu’elle est devenue du bruit de fond.

La vérité inconfortable, c’est que la plupart des déploiements ERP sont lents et coûteux pour des raisons structurelles. Pas parce que chaque équipe impliquée est incompétente. Ni même parce que les exigences étaient floues. Ils sont lents et coûteux parce que les incitations économiques et techniques qui ont façonné les ERP pendant des décennies les rendent lents et coûteux en tant que catégorie.¹

Dans mon livre Introduction to Supply Chain (Chapitre 5, “Information”, section “Systèmes de registres”), je consacre du temps à une idée étonnamment négligée : le logiciel qui enregistre les transactions est à la fois indispensable et fondamentalement limité. Son rôle est d’être un grand livre fiable—rien de plus. Lorsque les entreprises oublient cela, elles commencent à payer des prix “stratégiques” pour ce qui est, au fond, une machine administrative transactionnelle. C’est de cette incompréhension que naissent les problèmes.

La jungle des entités et le tapis roulant du fournisseur

Commençons par ce qu’est un ERP en pratique. C’est un système transactionnel, construit sur une base de données relationnelle, qui suit les ressources de l’entreprise et ses opérations routinières à travers de nombreux modules, de nombreux écrans, et un vaste catalogue d’“entités” (produits, clients, factures, commandes, etc.).¹

Voici la dynamique qui garantit silencieusement que les déploiements ERP continueront d’être pénibles.

Un fournisseur ERP ne construit pas de logiciels “pour vous”. Il construit des logiciels pour l’ensemble de sa clientèle, sur plusieurs décennies. Le produit grandit par accumulation. Chaque grand client apporte avec lui une poignée de concepts “incontournables”, d’exceptions, de flux de travail, de particularités réglementaires et de vocabulaires qui seront demandés comme des fonctionnalités de première classe. Les fournisseurs peuvent ajouter; ils ne retirent presque jamais rien. Il n’y a aucun avantage commercial à éliminer des entités obscures sur lesquelles certains clients historiques se reposent. Le résultat est un produit qui s’étend sans relâche, une entité à la fois, un module à la fois.¹

Cela importe car la complexité ne croît pas de façon linéaire. Supporter deux fois plus de fonctionnalités coûte bien plus que deux fois l’effort d’ingénierie, et la “cohésion sémantique” interne du produit se dégrade avec le temps.¹

Lors du premier déploiement, cette croissance est dissimulée par la stratégie commerciale. Les fournisseurs ERP vendent par modules; les entreprises clientes adoptent par modules. Un module maintenant, un autre dans six mois, encore un l’année prochaine. L’entreprise a l’illusion d’un progrès incrémental, et l’intégrateur peut étaler l’effort sur plusieurs phases.¹

Les mises à niveau sont l’instant où l’illusion s’effondre.

Même si vous restez avec le même fournisseur, les mises à niveau sont notoirement difficiles et s’étendent souvent sur plusieurs mois, voire des années.¹ La raison technique n’est pas mystérieuse : la migration n’est presque jamais une simple copie un-à-un. Le sens des entités évolue. Une table qui signifiait autrefois “commandes clients” est réaffectée pour représenter également les retours; la “correction” se concrétise par des quantités négatives, des indicateurs supplémentaires, des jointures additionnelles, des cas particuliers et des hypothèses en aval qui se dégradent silencieusement.¹

C’est ainsi que se manifeste le véritable problème : le problème de correspondance.

La majeure partie du travail ne consiste pas à “installer” le logiciel. Il s’agit de construire une correspondance entre deux dictionnaires incompatibles de l’entreprise : la sémantique de l’ancien ERP et celle du nouveau ERP. Et comme ces deux sémantiques sont façonnées par l’histoire du fournisseur, et non par votre entreprise seule, le nombre de concepts que vous devez réconcilier reflète l’ensemble de la clientèle accumulée du fournisseur. Votre entreprise paie pour naviguer dans un labyrinthe construit par tout le monde.

La personnalisation aggrave le problème. Lorsque le client et son intégrateur ajoutent des entités sur mesure, des écrans sur mesure, des flux de travail sur mesure — des éléments qui n’étaient pas viables pour le fournisseur — ces composants personnalisés deviennent un dialecte local. Par la suite, lorsque le fournisseur refactore (même légèrement), l’entreprise se voit contrainte d’effectuer une deuxième correspondance, bien plus pénible : du vieux dialecte personnalisé au nouveau dialecte standard, auquel s’ajoute toute personnalisation supplémentaire requise pour combler les lacunes.

Ce n’est pas un hasard. C’est ce qui se produit lorsqu’un produit voit son succès commercial dépendre d’une expansion continue de son périmètre tout en maintenant une compatibilité ascendante pour une clientèle diversifiée. C’est l’inévitabilité au ralenti d’une jungle d’entités.

Lorsque un système tente d’effectuer trois tâches

Le second problème structurel est encore plus répandu : les entreprises demandent de façon routinière à l’ERP d’exécuter trois tâches différentes simultanément.

Ils veulent que l’ERP enregistre les transactions (le grand livre), fournisse des analyses et des tableaux de bord (le “miroir”), et prenne des décisions (le “cerveau”). Les fournisseurs encouragent volontiers cela car regrouper ces fonctionnalités s’avère rentable: une fois que l’ERP est présenté comme “la plateforme qui fait fonctionner l’entreprise”, chaque module supplémentaire devient un “incontournable”.²

Pourtant, du point de vue de la conception logicielle, ces tâches vont dans des directions opposées.

Le traitement des transactions consiste en des mises à jour rapides et fiables ainsi qu’en une cohérence stricte. Le traitement analytique consiste à analyser de vastes ensembles de données, à agréger, découper et explorer. Ce sont des charges de travail différentes, souvent mises en œuvre avec des modèles de données différents et des compromis de performance différents; l’industrie a attribué des noms à cette distinction depuis des décennies (OLTP vs OLAP).³

Lorsque vous tentez de faire les deux avec un seul monolithe, vous créez un système qui est perpétuellement en conflit avec lui-même. Les opérations “lourdes” — rapports, analyses, fonctionnalités de pseudo-planification — rivalisent avec les opérations transactionnelles banales. Les utilisateurs perçoivent cela sous forme de lenteur, de délais d’attente, de traitements nocturnes, d’intégrations fragiles, et de l’éternel refrain selon lequel “le système ne peut pas faire cela.” Pendant ce temps, l’entreprise paie un supplément pour le privilège d’intégrer des contradictions dans l’architecture.

Il n’aide pas que “ERP” soit un nom trompeur. Historiquement, le “P” de planning évoque la promesse d’une intelligence. En réalité, la planification n’est, au mieux, qu’une préoccupation secondaire pour les ERP, et l’analytique prédictive tend à être en décalage avec leur conception transactionnelle de base.¹

Mon article de juin 2024 sur les logiciels d’entreprise soutenait que le gaspillage chronique de l’industrie provient du flou entre ces catégories et du fait de dépenser des sommes extravagantes pour les mauvaises choses. Le point fondamental, sans jargon, est simple : un grand livre n’est pas un moteur stratégique, et lui demander de l’être engendre de la complexité sans offrir les bénéfices escomptés.²

Si vous souhaitez une confirmation éclatante que je ne suis pas le seul à penser ainsi, regardez comment les principaux fournisseurs de cloud computing expliquent les systèmes de données : ils recommandent explicitement d’utiliser des systèmes transactionnels pour stocker et mettre à jour les enregistrements de manière fiable, et des systèmes analytiques pour générer des rapports et effectuer des analyses complexes. Ils ne prétendent pas qu’un seul mode de base de données excelle en tout; ils décrivent des rôles complémentaires.³

Les fournisseurs d’ERP vendent le rêve opposé : un système pour tout faire. Ce rêve est lucratif. La gueule de bois est payée par le client.

Le piège appelé “customization” et le travail appelé “migration”

La littérature tierce et la documentation des fournisseurs convergent vers un point que les praticiens connaissent déjà dans leurs tripes : la customization et la migration sont l’endroit où les projets vont mourir.

Un article de ScienceDirect sur la customization des ERP la décrit comme une “double-edged sword”, notant que si la customization peut améliorer l’ajustement, elle entraîne également une augmentation des coûts de mise en œuvre, une complexité accrue et des dépenses pour les mises à niveau ultérieures.⁴ C’est la version académique de ce que les intégrateurs intègrent silencieusement dans chaque proposition : toute déviation par rapport au chemin standard est une taxe future.

Même lorsque nous restons dans l’orbite des fournisseurs grand public, l’histoire reste la même. Les propres recommandations de Microsoft pour les implémentations de Dynamics 365 indiquent clairement que “Migrating data is a complex and time-consuming process,” puis énumèrent les types de travaux impliqués : analyser les sources, définir la portée, mapping et transformation des champs, chargement, tests, vérification et validation de la qualité des données.⁵

Lisez attentivement cette liste. Ce n’est pas une technologie exotique. Ce n’est pas “innovation.” C’est l’industrialisation du mapping et de la réconciliation.

C’est précisément pourquoi les programmes ERP s’étendent sur plusieurs années : le travail ne consiste pas à construire un nouveau logiciel ; il s’agit de traduire une entreprise vivante en un schéma tentaculaire, en constante évolution et façonné par le fournisseur, puis de répéter l’exercice lors des mises à niveau. Plus l’ERP essaie d’être le registre, le miroir et le cerveau, plus cette traduction devient un projet perpétuel plutôt qu’un exercice ponctuel.

Une alternative plus sensée : construire délibérément un petit registre

À ce stade, l’objection évidente apparaît : “Fine. ERPs are messy. But we need sophisticated features. We need planning. We need optimization. We can’t just build this ourselves.”

Cette objection contient la même erreur de catégorie que le pitch ERP.

Si vous limitez le périmètre au registre — la couche transactionnelle simple qui capture la sémantique métier et soutient les flux de travail routiniers — le problème devient radicalement plus simple. Pas simple au sens où cela ne nécessite aucune réflexion, mais simple dans la mesure où il s’agit principalement d’une application CRUD disciplinée.

Et c’est là que 2026 se distingue véritablement de 2015.

Des agents de codage existent désormais, spécifiquement conçus pour prendre une base de code, un ensemble de tâches et produire rapidement des modifications fonctionnelles. Claude Code d’Anthropic est un outil de codage agentique qui vit dans le terminal et aide à produire du code grâce à des commandes en langage naturel. Codex d’OpenAI a été présenté comme un agent d’ingénierie logicielle capable de gérer des tâches telles que l’écriture de fonctionnalités, la correction de bugs et la proposition de pull requests. xAI fournit des modèles Grok orientés codage qui peuvent être utilisés avec des éditeurs de code via des workflows d’agents communs.

Ces outils ne sont pas magiques. Un essai contrôlé randomisé publié par METR en juillet 2025 a même constaté que, dans un contexte particulier (des développeurs expérimentés travaillant sur des dépôts open-source familiers), l’utilisation d’outils d’IA ralentissait en moyenne les développeurs, car le temps passait de l’écriture à la révision et à la correction.⁶ Ce résultat est un rappel important : “agentic” ne signifie pas “automatic.”

Cependant, cela clarifie également l’endroit où l’avantage est le plus marqué : lorsque le travail est répétitif, bien délimité et sémantiquement contraint — exactement ce qu’un registre délibérément ennuyeux devrait être.

Voici ma recommandation, énoncée clairement : pour toute entreprise de taille importante — disons, avec un chiffre d’affaires annuel supérieur à 50M € — la position par défaut devrait être de construire en interne la couche de registre plutôt que d’acheter un monolithe ERP et de payer une décennie de loyer à son écosystème.

Pourquoi ?

Parce que le principal moteur de coût de la “modernization” des ERP est le schema mapping à travers des milliers d’entités façonnées par le fournisseur et des années de dérive sémantique accumulée. Si vous partez de zéro, vous pouvez construire une couche d’enregistrements alignée sur votre propre sémantique, et non un compromis conçu pour convenir à chaque entreprise du portefeuille du fournisseur. En pratique, le modèle de données résultant est souvent d’un ou deux ordres de grandeur inférieur. Non pas parce que votre entreprise est triviale, mais parce que vous cessez de payer pour les débris sémantiques laissés par d’autres clients.

Le déploiement change également de forme. Au lieu d’une transition héroïque après des années de spécification, vous pouvez itérer comme une équipe d’ingénierie sensée. Vous importez un instantané frais des données héritées. Vous laissez les employés interagir avec le nouveau système. Ils signalent des discordances entre le logiciel et les flux de travail réels. Vous ajustez le code. Vous réimportez. Vous répétez jusqu’à ce que le registre convienne. Cette approche est simplement la version disciplinée de ce que les recommandations de Microsoft impliquent déjà : le mapping, les tests, la validation et la répétition.⁵

Oui, cela nécessite des compétences en codage. Ces compétences peuvent être internes ou externalisées, mais elles doivent être réelles. Cela requiert également ce que j’appelle souvent la mechanical sympathy : une compréhension suffisante de la part de la direction pour orienter un projet technique sans être hypnotisée par les théâtralités du fournisseur. L’analogie que j’ai utilisée ailleurs est que les grands pilotes ne sont pas des ingénieurs mécaniques, mais ils en savent assez sur la machine pour en tirer le meilleur parti.⁷

C’est la partie que de nombreuses entreprises essaient d’éviter. Elles préfèrent externaliser la réflexion ainsi que la mise en œuvre. Elles préfèrent acheter l’illusion de sécurité.

Mais externaliser le registre de l’entreprise à un monolithe dont les incitations sont de croître, de regrouper et de verrouiller, ce n’est pas la sécurité. C’est la manière la plus lente d’acheter un logiciel que vous finirez par devoir remplacer de toute façon.

Si vous voulez de la planification et de l’optimization, traitez-les comme des préoccupations distinctes, superposées à un registre propre. Ne forcez pas le registre à devenir l’optimizer. N’entraînez pas l’optimization dans le projet de migration. D’abord, rendez les enregistrements précis, rapides et ennuyeux. Puis—et ce, seulement après—construisez des systèmes de décision pouvant être améliorés sans avoir à réécrire à chaque fois l’intégralité de la mémoire de l’entreprise.

Les déploiements ERP sont lents et coûteux parce que la catégorie des ERP a évolué sous des incitations qui les rendent lents et coûteux. La solution n’est pas une meilleure gestion de projet dans le même piège. La solution est d’arrêter de demander à un registre d’être un oracle, et d’arrêter de payer le bagage historique d’un fournisseur comme s’il était le vôtre.