Un ERP ne tombe (presque) jamais en panne d’un coup. Il s’essouffle progressivement, contournement après contournement, jusqu’à ce que ces contournements ne soient plus perçus comme des anomalies mais comme « la façon dont on travaille ici ». C’est là le vrai risque : pas la panne, l’habitude. Six signaux permettent de repérer ce point de bascule avant qu’il ne devienne un problème de gouvernance, de coût ou — dans certains contextes — de valorisation.
Ces signaux ne se lisent jamais isolément : un ERP qui coche une ou deux cases sur six n’est pas nécessairement en fin de vie. C’est leur accumulation, et surtout leur ancienneté, qui doit alerter.
Les 6 signaux à surveiller
Des tableurs Excel comblent ce que l'ERP ne sait plus faire
Quand une partie du pilotage réel de l’activité vit dans des fichiers Excel parallèles — reporting consolidé, suivi de trésorerie, gestion de stock affinée — c’est que l’ERP ne couvre plus le besoin métier.
Le signal n’est pas l’existence d’Excel en soi (il aura toujours sa place), mais le fait qu’il devienne la source de vérité sur des processus qui devraient être nativement dans le système.
Des développements spécifiques que plus personne ne sait maintenir
Chaque spécifique codé « pour aller vite » à l’époque devient, dix ans plus tard, une boîte noire.
Le vrai indicateur d’alerte : le nombre de personnes dans l’organisation capables d’expliquer pourquoi tel spécifique existe et ce qu’il casserait si on le retirait. Quand ce nombre approche zéro, la dette technique est déjà activée, même si rien n’a encore cassé.
Un temps de clôture ou de reporting qui s'allonge sans raison apparente
Une clôture mensuelle qui glisse de 5 à 8 jours sur deux ans, sans changement de périmètre ni de volumétrie identifiable, n’est presque jamais un problème de méthode ou d’équipe. C’est le symptôme d’un système qui demande de plus en plus de manipulations manuelles pour produire le même résultat.
Des doubles saisies entre systèmes qui ne communiquent pas
Quand une donnée doit être ressaisie manuellement dans un second outil parce que l’ERP ne s’interface plus proprement avec le reste du SI (CRM, paie, outil métier), le risque n’est pas seulement la perte de temps : c’est l’écart de données entre les deux systèmes, qui finit toujours par se payer au moment d’un contrôle ou d’un audit.
Un éditeur qui a annoncé une fin de support ou de mises à jour majeures
C’est le signal le plus visible, mais pas forcément le plus urgent à traiter isolément — chaque éditeur a son propre rythme, et il vaut mieux le connaître précisément que réagir à un titre alarmiste.
Deux illustrations, à titre d’exemple parmi d’autres éditeurs (Sage, Cegid, Dynamics, ERP maison ont chacun leur propre cycle) : côté SAP, la maintenance mainstream d’ECC (EHP 6-8) s’arrête fin 2027, avec une extension payante possible jusqu’à fin 2030 ; côté Oracle, le Premier Support d’E-Business Suite 12.2 a été repoussé d’un an chaque année depuis 2018 et court aujourd’hui au moins jusqu’en 2037.
Une fin de support annoncée — ou au contraire une échéance lointaine — doit être vérifiée précisément avant toute décision : le déclencheur d’un diagnostic, ce n’est pas le titre de l’annonce, c’est la date réelle qui s’y cache.
Des recrutements IT qui peinent, faute de candidats formés à un système vieillissant
Quand un poste reste ouvert plusieurs mois parce que les compétences recherchées (une techno ERP ancienne, une version obsolète) n’attirent plus de profils juniors ou confirmés, l’organisation devient dépendante d’un nombre décroissant d’experts internes ou externes. C’est un signal de vulnérabilité au moins aussi sérieux qu’un problème technique.
Et concrètement, combien coûte l'inaction ?
Selon une étude Forrester menée auprès de décideurs IT américains (The State Of Technical Debt In The US, 2024),
- les entreprises consacrent en moyenne 20 % de leur budget IT à la gestion de la dette technique, et
- 30 % d’entre elles évoluent avec un niveau de dette qualifié d’élevé ou de critique.
Une estimation plus ancienne mais du même ordre de grandeur, avancée par McKinsey dès 2020 et toujours reprise par le cabinet en 2023 (Tech debt: Reclaiming tech equity), évaluait la dette technique cumulée à 20-40 % de la valeur totale du parc technologique d’une entreprise.
Ces chiffres sont mondiaux et tous secteurs confondus — il n’existe pas, à notre connaissance, d’étude équivalente calibrée sur les seules PME/ETI françaises et leurs ERP — mais l’ordre de grandeur donne une idée du coût de l’immobilisme, même quand aucun de ces coûts n’apparaît comme une ligne budgétaire dédiée.
Cas particulier : cession, levée de fonds — quand un repreneur ausculte votre SI
Un signal souvent sous-estimé, parce qu’il ne relève pas directement de l’IT : la préparation d’une cession, d’une levée de fonds ou d’une opération de croissance externe change la façon dont le système d’information est regardé — et par qui.
Lors d’un audit d’acquisition, un repreneur ou un fonds d’investissement examine la qualité et la maintenabilité du SI au même titre que les indicateurs financiers. Un ERP daté, mal documenté ou dépendant d’une poignée d’experts internes n’invalide pas une opération, mais il génère des questions, des due diligences plus longues et, dans certains cas, une provision de risque qui pèse sur la négociation.
Ce point ne concerne pas que les dirigeants en phase active de cession : dès qu’une trajectoire de croissance externe ou d’ouverture de capital est envisagée à moyen terme, c’est un bon moment pour objectiver l’état réel du SI — avant qu’un tiers extérieur ne le fasse à sa place, dans un calendrier qu’on ne maîtrise plus.
FAQ
Faut-il changer d'ERP dès le premier signal repéré ?
Non. Un signal isolé appelle une vigilance, pas une décision de migration. C’est l’accumulation de plusieurs signaux, et leur tendance dans le temps (est-ce que ça s’aggrave ?), qui doit déclencher un diagnostic formel plutôt qu’un remplacement immédiat.
Un ERP développé en interne ou fortement personnalisé pose-t-il systématiquement problème ?
Non plus. Un ERP très personnalisé n’est un problème que si cette personnalisation n’est plus documentée ni maintenable par personne. Un développement spécifique récent, documenté et porté par une équipe identifiée n’est pas de la dette technique — c’est un choix d’architecture assumé.
Et si plusieurs signaux sont présents en même temps, comment prioriser ?
En général, l’alerte vient d’abord sur les signaux qui touchent à la continuité de service (fin de support éditeur, expertise interne qui se raréfie), puis de ceux qui touchent à la fiabilité des données (doubles saisies, Excel parallèle), et enfin de ceux qui touchent à la performance opérationnelle (temps de clôture, de reporting).
Un diagnostic structuré permet de les hiérarchiser objectivement plutôt qu’au ressenti.
Combien de temps dure le diagnostic avant de savoir si un changement d'ERP est nécessaire ?
Un diagnostic sérieux — cartographie des spécifiques, état des interfaces, analyse des flux manuels, entretiens avec les équipes concernées — se mène en règle générale sur quelques semaines.
C’est volontairement plus court qu’un projet de refonte : l’objectif est de statuer sur la nécessité et l’urgence, pas de concevoir la solution cible.
PREREQUIS et la modernisation ERP
Chez PREREQUIS, nous accompagnons depuis 25 ans la modernisation des environnements ERP sans logique d’éditeur imposée. Nos équipes interviennent sur une très large variété d’environnements SAP (S/4HANA, ECC), Oracle (ERP Cloud/Fusion, E-Business Suite, NetSuite), ou hybrides.
Notre approche part systématiquement du même principe : comprendre précisément ce qui doit changer — et pourquoi — avant de recommander comment, plutôt que de partir d’une solution pour lui trouver un problème à résoudre.
Cette logique de diagnostic avant préconisation est au cœur de notre expertise Mise en place et refonte d’ERP, et se retrouve dans notre approche plus large de la création de valeur par un SI optimisé. Nos consultants interviennent aussi bien sur l’audit de l’existant que sur le pilotage et la mise en œuvre fonctionnelle et/ou technique de bout en bout d’un projet de refonte, avec la même exigence de séniorité sur chaque éditeur du portefeuille.
Envie d’objectiver la situation de votre SI ?
👉Échangez avec un consultant PREREQUIS — un premier échange suffit pour savoir si un diagnostic approfondi a du sens pour vous.
POUR ALLER PLUS LOIN
Sources
- Forrester, The State Of Technical Debt In The US, 2024
- McKinsey Digital, Tech debt: Reclaiming tech equity, octobre 2020
- SAP, stratégie de maintenance SAP Business Suite 7 / S/4HANA (support.sap.com)
- Oracle, EBS 12.2 Premier Support Extended Through At Least 2037, 25 mars 2026 (blogs.oracle.com/ebstech)
