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 d’innombrables fois. Une entreprise exploite un ERP qu’elle a 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. De même, l’écran qui se chargeait instantanément commence à tourner dans le vide. Personne ne peut désigner le moment où cela s’est produit. En effet, il n’y a jamais eu d’instant unique où tout a cassé. Le problème s’est simplement installé peu à peu au fil du temps.

Au fond, peu importe de quel ERP il s’agit, qu’il s’agisse de SAP, de Microsoft Dynamics, d’Oracle ou d’une plateforme conçue pour votre secteur. Sous le capot, ils se comportent tous de manière très semblable. Par conséquent, 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.

Pourquoi le ralentissement des ERP compte-t-il plus que jamais en 2026 ?

Il compte davantage aujourd’hui parce que presque tout ce qui figure sur la feuille de route de cette année repose sur ces mêmes données en dessous. En effet, 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. Ainsi, 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é. Pourtant, ils seront lents eux aussi si la fondation qui les soutient est lente. Le risque se lit déjà dans les chiffres. Gartner prévoit en effet que les organisations abandonneront 60 % de leurs projets d’IA d’ici 2026 partout où des données prêtes pour l’IA ne les soutiennent pas (Gartner, 2025).

Il est aussi 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 précède presque certainement l’IA d’aujourd’hui. Ses concepteurs l’ont bâti pour enregistrer des transactions et produire des rapports destinés à des lecteurs humains, et non 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. Par conséquent, 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 ?

Le ralentissement se situe presque toujours dans la couche de données, et non dans l’application elle-même. Lorsqu’un ERP semble poussif, l’instinct naturel consiste à regarder directement du côté de l’application. On se tourne alors vers une nouvelle version, davantage de mémoire ou un serveur plus rapide. Cette approche fait parfois gagner un peu de temps. Cependant, 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. Or, les tables situées en dessous ont souvent grossi bien au-delà de ce pour quoi on les avait conçues, sans que l’indexation suive le rythme. Dès lors, 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 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. Au contraire, c’est généralement la couche de données peu glamour située en dessous. La recherche empirique le confirme. En effet, une étude menée auprès de 110 experts du secteur a examiné ce qui détermine la réactivité d’un ERP. Elle a révélé que la gestion des big data et la contextualisation des données figurent parmi les facteurs les plus déterminants (Bandara et al., Information Systems Frontiers, 2023).

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

Lorsque la fondation ne peut plus suivre, la défaillance 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. D’une certaine façon, c’est même 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. De son côté, l’équipe analytique, lassée de chiffres périmés, construit ses propres extractions. 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. C’est plutôt un ensemble de capacités que l’entreprise a discrètement passées par pertes et profits. C’est aussi 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, 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 de budget plus important. Au contraire, elle résulte directement 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, des années plus tôt. Restent enfin les personnalisations accumulées au fil du temps, celles que tout le monde redoute un peu de toucher. Votre équipe doit les comprendre et les documenter correctement, plutôt que de simplement en hériter et de les craindre.

Rien de ce travail n’a quoi que ce soit d’exotique. Il s’agit d’ingénierie soignée et réfléchie. En fait, c’est exactement le genre de chose que l’on néglige quand tout le monde est débordé. C’est aussi 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

Vous y remédiez en mesurant d’abord le système, plutôt qu’en devinant. 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 bien celle-ci. Vous ne pouvez pas optimiser avec assurance une plateforme que personne n’a jamais profilée. De plus, 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 quelques étapes précises et délibérées :

• Examinez les rapports et traitements de planification les plus lourds sur un cycle d’activité réel, puis repérez où ils ralentissent.
• Vérifiez la qualité des données directement à la source, car les lacunes qui s’y trouvent dégradent tout le reste.
• Cartographiez les personnalisations et les connexions entre systèmes, retirez ce qui ne mérite plus sa place et documentez le reste.
• Établissez dès maintenant une base de référence, afin de prouver plus tard ce que l’IA aura réellement changé.

Avec un ERP packagé, une contrainte façonne tout ce travail. En général, vous ne pouvez pas réécrire l’application de l’éditeur, et votre liberté de modifier la structure sous-jacente reste elle aussi limitée. Le travail doit donc se faire avec les leviers que vous contrôlez, au niveau de la base de données. Si vous fonctionnez sous SQL Server, Query Store est l’un des outils les plus utiles à cette fin. Il vous montre quelles requêtes sont lentes et comment elles se sont comportées dans le temps. De plus, 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, cela se rapproche autant que possible de prendre le volant.

Pourquoi anticiper le ralentissement des ERP vaut-il mieux qu’attendre ?

Anticiper le ralentissement des ERP vaut mieux qu’attendre parce que vous traitez la fondation tant que c’est encore un choix, plutôt qu’une urgence. 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 tôt. Voilà toute la différence entre elles. Tout 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 bâtir vers le haut.

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