Ralentissement des ERP : où se cache la vraie cause

En plus de 30 ans passés à travailler avec les données, j’ai vu le même scénario se répéter plus de fois que je ne saurais les compter. Une entreprise exploite un ERP qui a été personnalisé, année après année, pour correspondre exactement à sa façon de fonctionner. Le premier jour, tout tourne à merveille, puis, lentement, le système commence à ralentir. Un rapport qui prenait autrefois quelques secondes se met à durer plusieurs minutes, et l’écran qui se chargeait instantanément commence à tourner dans le vide. Personne ne peut désigner le moment où cela s’est produit, parce qu’il n’y a jamais eu d’instant unique où tout a cassé, le problème s’est simplement installé peu à peu chez tout le monde au fil du temps.

Peu importe en réalité de quel ERP il s’agit, qu’il s’agisse de SAP, de Microsoft Dynamics, d’Oracle, ou d’une plateforme conçue spécifiquement pour votre secteur. Sous le capot, ils se comportent tous de manière très semblable, et ils finissent par se heurter exactement au même mur. Le système que tout le monde montre du doigt est rarement celui qui est réellement en cause.

Voici pourquoi cela compte davantage en 2026 que jamais auparavant. Presque tout ce qui figure sur la feuille de route de cette année repose sur ces mêmes données en dessous, parce que la planification assistée par l’IA, l’analytique en temps réel et la migration vers le cloud puisent toutes à la même source. Les dépenses le confirment, puisque Gartner prévoit que 62 % des dépenses consacrées aux ERP cloud iront aux solutions dotées d’IA d’ici 2027, contre seulement 14 % en 2024 (Gartner, 2025). Chacune de ces ambitions ne sera jamais plus rapide que la couche qui l’alimente. Vous pouvez acheter les outils les plus avancés du marché, mais si la fondation qui les soutient est lente, alors ils seront lents eux aussi. Le risque se lit déjà dans les chiffres, puisque Gartner prévoit que les organisations abandonneront 60 % de leurs projets d’IA d’ici 2026 partout où ces projets ne s’appuient pas sur des données prêtes pour l’IA (Gartner, 2025).

Il est utile de se rappeler à quelle époque la plupart de ces systèmes ont d’abord été conçus. L’ERP qui fait tourner votre entreprise a, selon toute vraisemblance, été construit bien avant que l’IA d’aujourd’hui n’existe. Il a été pensé pour enregistrer des transactions et produire des rapports destinés à être lus par des personnes, plutôt que pour alimenter des modèles qui raisonnent seuls sur vos données. Nous demandons aujourd’hui à une fondation bâtie pour une mission d’en assumer une tout autre, et la tension apparaît exactement là où on l’attend, en dessous, dans les données.

Pourquoi le ralentissement se situe-t-il presque toujours dans la base de données, et non dans l’application ?

Lorsqu’un ERP semble poussif, l’instinct naturel consiste à regarder directement du côté de l’application. On se tourne vers une nouvelle version, davantage de mémoire, ou un serveur plus rapide. Cette approche fait parfois gagner un peu de temps, mais la véritable cause se trouve généralement une couche plus bas, dans les données elles-mêmes.

Chaque recommandation que produit un module d’IA, chaque tableau de bord qui se rafraîchit et chaque flux de travail automatisé doit d’abord accomplir le même travail silencieux. Il lui faut trouver les bonnes données, les combiner, puis renvoyer une réponse. Lorsque les tables situées en dessous ont grossi bien au-delà de tout ce pour quoi elles avaient été conçues, et que l’indexation n’a pas suivi le rythme, ce travail prend de plus en plus de temps à se terminer. L’application attend les données, l’utilisateur attend l’application, et l’intelligence que vous avez ajoutée par-dessus hérite de chaque parcelle de ce délai.

C’est la partie qui surprend vraiment les gens. La nouvelle fonctionnalité impressionnante n’est presque jamais le véritable goulot d’étranglement, tandis que la couche de données peu glamour qui se trouve en dessous l’est généralement. La recherche empirique le confirme, une étude menée auprès de 110 experts du secteur a révélé que la gestion des big data et la contextualisation des données figurent parmi les facteurs les plus déterminants de la réactivité avec laquelle un ERP traite ses données (Bandara et al., Information Systems Frontiers, 2023).

Que se passe-t-il lorsque la fondation ne peut plus suivre ?

La défaillance, ici, est rarement spectaculaire de la manière à laquelle on s’attend. Il n’y a pas de panne, et aucune alarme ne se déclenche soudainement. Ce qui se produit à la place est bien plus discret, et d’une certaine façon c’est en réalité pire encore.

Le planificateur qui attend trop longtemps une réponse se met à récupérer les chiffres dans un tableur et à décider à la main. Le module d’IA que vous avez payé une belle somme devient lentement guère plus qu’une décoration. L’équipe analytique, lassée de chiffres périmés, construit ses propres extractions de son côté, et bientôt trois versions de la vérité circulent dans trois réunions différentes. Personne n’a jamais décidé de cesser de faire confiance au système, chacun a simplement et discrètement cessé de s’appuyer dessus.

Voilà le véritable coût de tout ce problème. Ce n’est pas une ligne sur une facture, mais un ensemble de capacités que l’entreprise a discrètement passées par pertes et profits, et une équipe dirigeante qui prend des décisions sur des chiffres déjà vieux de plusieurs heures.

Une couche de données rapide n’a rien de magique, elle est soigneusement entretenue

La bonne nouvelle, ici, c’est que rien de tout cela n’est mystérieux ni hors de votre portée. Une couche de données réactive n’est pas une affaire de chance ni simplement de budget plus important à dépenser. Elle est le résultat direct de quelques éléments importants dont on prend correctement soin au fil du temps.

Les données elles-mêmes doivent être exactes et cohérentes, afin que les systèmes qui les lisent puissent se fier à ce qu’ils y trouvent. L’indexation et le partitionnement doivent correspondre à la façon dont l’application lit réellement les données aujourd’hui, et non à celle que quelqu’un imaginait lors de la mise en service du système il y a des années. Et les personnalisations qui se sont accumulées au fil du temps, celles que tout le monde redoute un peu de toucher, doivent être véritablement comprises et documentées plutôt que simplement héritées et craintes. Rien de ce travail n’a quoi que ce soit d’exotique, c’est de l’ingénierie soignée et réfléchie. C’est exactement le genre de chose que l’on néglige quand tout le monde est débordé, et exactement le genre de chose qui décide en silence si vos projets de 2026 décollent ou s’enlisent.

Comment y remédier ? Commencez par mesurer, pas par deviner

S’il y a une chose que je répète aux clients avant qu’ils ne greffent quoi que ce soit de nouveau sur une plateforme vieillissante, c’est tout simplement celle-ci. Vous devez d’abord mesurer le système, parce qu’une plateforme qui n’a jamais été profilée ne peut être optimisée avec une réelle assurance, et qu’un système portant des années de croissance et de personnalisation se comporte rarement comme chacun le suppose.

Concrètement, cela suppose de travailler à travers quelques étapes précises et délibérées :

• Examinez les rapports et les traitements de planification les plus lourds sur un cycle d’activité réel, plutôt qu’un après-midi tranquille, et repérez exactement où ils ralentissent.
• Vérifiez la qualité des données directement à la source, parce que les lacunes qui y résident sont ce qui dégrade tout le reste construit par-dessus.
• Cartographiez les personnalisations et les connexions entre les systèmes, puis retirez tout ce qui ne mérite plus sa place et documentez tout ce qui demeure.
• Établissez dès maintenant une base de référence claire, afin que, lorsque le travail d’IA ou d’analytique entrera en service, vous puissiez prouver ce qu’il a changé au lieu de simplement le deviner.

Avec un ERP packagé, une contrainte façonne l’ensemble de ce travail. Vous ne pouvez généralement pas réécrire l’application de l’éditeur, et votre liberté de modifier la structure sous-jacente est elle aussi souvent assez limitée. Le travail doit donc se faire avec les leviers que vous contrôlez, tout en bas, au niveau de la base de données. Si vous fonctionnez sous SQL Server, Query Store est l’un des outils les plus utiles dont vous disposez précisément à cette fin. Il vous montre quelles requêtes sont lentes et comment elles se sont comportées dans le temps, et il vous permet de figer un bon plan d’exécution sans toucher à une seule ligne du code de l’éditeur. Sur un système que vous n’avez pas le droit de reconstruire, c’est à peu près ce qui se rapproche le plus de prendre le volant.

Pourquoi anticiper le ralentissement de l’ERP vaut mieux qu’attendre

Les entreprises qui passeront 2026 dans la frustration seront celles qui auront acheté de l’intelligence puis oublié de l’alimenter correctement. Celles qui prendront véritablement de l’avance auront regardé une couche plus bas et traité la fondation tant que c’était encore un choix, plutôt qu’une urgence. Voilà toute la différence entre elles, et cela tient à la capacité du sol sous une ambition à en porter le poids.

Si vous projetez quelque chose d’ambitieux avec vos données cette année, et c’est assurément le cas de la plupart d’entre nous, alors il vaut vraiment la peine de regarder vers le bas avant de commencer à bâtir vers le haut.

Votre infrastructure de données est-elle prête à soutenir vos ambitions pour 2026 ?