Votre ERP a douze ans. Il tourne encore. Les utilisateurs s’en plaignent mais ne l’arrêtent pas. La DSI documente chaque année les risques dans son schéma directeur. Et chaque année, la migration est repoussée au budget suivant.
Ce n’est pas un problème d’argumentation technique. C’est un problème de traduction. Les COMEX ne votent pas pour des upgrades logiciels : ils votent pour des rendements sur investissement, des réductions de risque mesurées en euros, et des scénarios comparables. Tant que le DSI arrive avec des slides sur les CVE non patchées et les versions non supportées, la réponse sera la même : “ça marche encore, on verra l’an prochain.”
Ce guide propose une méthode en six étapes pour passer de l’argument technique à l’argument financier. Pas de théorie : des catégories de coûts précises, des formules de calcul, et une structure de présentation COMEX qui a fait ses preuves.
Pourquoi la dette technique ERP est difficile à chiffrer (et pourquoi le COMEX s’en fout)
Le problème de traduction DSI-COMEX
Un DSI qui parle de “fin de mainstream support” ou de “dette technique accumulée” utilise un vocabulaire qui ne déclenche aucune alerte dans la tête d’un DAF ou d’un DG. Ces concepts sont abstraits, le risque est diffus, et l’urgence est invisible.
Le COMEX, lui, raisonne en trois catégories : combien ça coûte aujourd’hui, combien ça va coûter demain, et quel est le risque si on ne fait rien. Si le DSI n’est pas capable de répondre précisément à ces trois questions avec des chiffres documentés et des hypothèses transparentes, le projet sera déprioritisé.
Les trois objections systématiques
Trois réponses reviennent invariablement quand une migration ERP est soumise au comité de direction :
- “Ça marche encore.” La disponibilité du système est interprétée comme une preuve que la situation est sous contrôle.
- “C’est trop risqué.” La migration est perçue comme le risque principal, alors que le statu quo comporte des risques croissants et invisibles.
- “On n’a pas le budget.” Le coût de la migration est connu (300 K€, 800 K€, 2 M€ selon l’éditeur et le périmètre). Le coût de l’inaction, lui, n’est jamais chiffré.
La méthode ci-dessous vise précisément à rendre le coût de l’inaction visible, comparable et défendable devant un comité de direction.
Définir la “dette technique ERP” : quatre catégories de coûts réels
Avant de chiffrer, il faut poser un cadre commun. La dette technique ERP recouvre quatre types de dettes distinctes, chacune avec ses propres leviers de coût.
Dette de maintenance
Un ERP on-premise de dix ans génère des coûts de maintenance croissants. Les licences continuent de courir sur des versions que l’éditeur ne fait plus évoluer. Les consultants spécialisés dans des versions anciennes (SAP ECC, NAV 2013, Sage 1000 v6) sont rares et donc chers. Les contrats AMS avec les intégrateurs tendent à augmenter à mesure que la documentation se raréfie et que les profils compétents partent à la retraite ou migrent vers les nouvelles versions.
La maintenance annuelle d’un ERP représente entre 18 et 22 % du coût initial de licence pour les éditeurs de premier rang. Ce taux n’inclut pas les coûts RH internes ni l’infrastructure.
Dette de sécurité
Les versions hors mainstream support ne reçoivent plus de correctifs de sécurité réguliers. SAP ECC 6.0 avec EHP 0 à 5 a perdu son mainstream support fin 2025 ; les EHP 6 à 8 l’ont jusqu’au 31 décembre 2027, date au-delà de laquelle seules des options d’extended maintenance payantes seront disponibles (SAP Support). Microsoft Dynamics NAV 2018, dernière version avant Business Central, a perdu son mainstream support en janvier 2023.
Un ERP non patché accumule des CVE qui peuvent être exploitées par des ransomwares. Le coût moyen d’une violation de données s’établissait à 4,45 M$ en 2023 selon le rapport IBM Cost of a Data Breach 2023, un chiffre en hausse constante depuis dix ans.
Dette d’intégration
Un ERP de première ou deuxième génération dispose rarement d’APIs REST modernes. Les connecteurs vers les outils actuels (marketplace e-commerce, BI cloud, RPA, outils de dématérialisation) ont souvent été développés en interne, sur des protocoles propriétaires qui cassent à chaque upgrade d’un partenaire.
Le résultat : chaque nouvelle intégration coûte plus cher qu’elle ne devrait, et la moindre évolution chez un éditeur tiers provoque des incidents en cascade.
Dette fonctionnelle
La plus difficile à quantifier est souvent la plus coûteuse. Les modules absents de l’ERP sont compensés par des fichiers Excel partagés, des applications satellites non gouvernées, des processus manuels qui mobilisent des ETP qualifiés sur des tâches sans valeur. Cette couche de Shadow IT n’apparaît dans aucun bilan, mais elle représente un coût RH réel et un risque opérationnel tangible.
Méthode en 6 étapes pour chiffrer la dette technique
Étape 1 : Inventaire des coûts de maintenance actuels
Commencez par agréger tous les coûts annuels directement liés à l’ERP actuel :
- Licences éditeur : le contrat de maintenance annuel (généralement 18-22 % du prix de licence initial)
- Contrat AMS/TMA avec l’intégrateur : nombre de jours réellement consommés vs contractualisés
- Infrastructure : serveurs on-premise (amortissement, électricité, salle serveurs), ou hébergement infogéré
- RH internes : temps des administrateurs fonctionnels et techniques dédiés à l’ERP en pourcentage de leurs postes
Cet agrégat constitue le coût de maintenance annuel de référence. Pour une ETI de 200 à 500 salariés sur un ERP on-premise de 10 ans, ce coût se situe typiquement entre 120 000 et 350 000 euros par an, selon le périmètre fonctionnel et les ressources internes mobilisées.
Benchmark de validation : si ce chiffre dépasse 20 % du coût initial du projet ERP par an, vous êtes dans la moyenne haute du marché. S’il dépasse 25 %, l’ERP coûte plus cher à maintenir qu’il n’en coûterait amorti sur un nouveau système.
Étape 2 : Mesurer le Shadow IT lié à l’ERP
Cette étape est la plus chronophage mais souvent la plus révélatrice. L’objectif est de recenser toutes les tâches qui devraient être réalisées dans l’ERP et qui sont en réalité effectuées en dehors.
Méthode pratique : conduisez des entretiens de 30 minutes avec les responsables des principales fonctions (comptabilité, achats, logistique, commerce, RH). Demandez-leur de lister les fichiers Excel qu’ils maintiennent, les exports manuels qu’ils font chaque semaine, et les tâches de saisie double.
Pour chaque tâche identifiée, estimez :
- Le temps hebdomadaire consacré (en heures)
- Le profil du ou des collaborateurs concernés (coût journalier moyen : 250 à 500 euros selon le niveau)
Formule : (heures/semaine × 52 semaines × taux horaire) × nombre de personnes concernées
Un cabinet d’achat qui exporte manuellement ses commandes vers un tableur pour les envoyer par email à ses fournisseurs parce que l’ERP ne dispose pas d’EDI : 3h/semaine × 1 personne × 350 euros/jour soit environ 7 000 euros par an pour cette seule tâche. Multipliez par 8 à 15 processus comparables dans une ETI de taille moyenne et vous dépassez rapidement les 60 000 à 100 000 euros annuels de coûts cachés.
Étape 3 : Valoriser les risques de sécurité et de conformité
Cette catégorie est la plus difficile à quantifier précisément, mais elle est souvent la plus convaincante devant un COMEX, parce qu’elle parle de risques d’entreprise, pas de risques informatiques.
Risque cyber : si l’ERP gère des données sensibles (facturation, données fournisseurs, données RH), une violation de données provenant d’une vulnérabilité non patchée peut coûter plusieurs millions d’euros. Le coût de 4,45 M$ avancé par IBM en 2023 est une moyenne mondiale ; pour les entreprises de taille intermédiaire européennes, le chiffre est souvent compris entre 1 et 3 M€, incluant les coûts de notification, de remédiation, de perte de clientèle et les amendes potentielles.
Risque RGPD : un ERP qui ne peut pas garantir la traçabilité des traitements, l’export des données personnelles ou la suppression sur demande expose l’entreprise à des amendes pouvant atteindre 4 % du chiffre d’affaires mondial.
Risque réglementaire sectoriel : facture électronique obligatoire, conformité NIS2, reporting CSRD, sérialisation pharmaceutique. Un ERP pré-2020 peut techniquement ne pas être en mesure de gérer ces obligations nativement, obligeant soit à des développements spécifiques coûteux, soit à des workarounds risqués.
Pour présenter ce risque au COMEX, exprimez-le sous forme de probabilité × impact : “Si nous estimons à 5 % la probabilité d’un incident cyber exploitant une vulnérabilité de l’ERP sur les 3 prochaines années, et si nous évaluons l’impact à 1,5 M€, le risque pondéré est de 75 000 euros par an.” Ce type de calcul est immédiatement compréhensible pour un DAF.
Étape 4 : Chiffrer le manque à gagner fonctionnel
Certaines fonctionnalités absentes de l’ERP ne créent pas seulement des coûts : elles empêchent des gains. Cette catégorie recouvre les opportunités auxquelles l’entreprise ne peut pas accéder à cause des limites du système.
Exemples concrets :
- Impossibilité de gérer plusieurs dépôts en temps réel → décision de ne pas ouvrir un entrepôt secondaire
- Absence de prévision de demande → surstock structurel estimable en jours de couverture × valeur du stock
- Pas de portail fournisseur → délai de traitement des factures fournisseurs plus long, perte d’escomptes pour paiement anticipé
Ces manques à gagner ne sont pas toujours chiffrables avec précision, mais une estimation documentée vaut mieux que rien. L’objectif est d’inclure au moins une ligne “manques à gagner” dans le tableau de synthèse, même approximative.
Étape 5 : Projeter les coûts sur 5 ans (inaction vs migration)
C’est la pièce maîtresse du business case. Le COMEX a besoin d’une comparaison dynamique, pas d’une photographie du moment.
Colonne “inaction” : additionner les coûts de maintenance (avec une hypothèse de croissance annuelle de 5 à 8 %, car les coûts de maintenance legacy augmentent mécaniquement à mesure que les profils se raréfient), le Shadow IT estimé, le risque pondéré et le manque à gagner. Sur 5 ans, avec une croissance des coûts, la somme dépasse très généralement le coût total d’une migration.
Colonne “migration” : coût projet (licences, implémentation, formation, conduite du changement, portage des données), amorti sur 5 à 7 ans, moins les économies attendues (réduction du Shadow IT, suppression de coûts de maintenance, gains de productivité). À partir de la troisième ou quatrième année, le coût annuel post-migration est généralement inférieur au coût de maintenance de l’ERP actuel.
Point de bascule : l’année à partir de laquelle le coût cumulé de l’inaction dépasse le coût cumulé de la migration, incluant la période de transition. Ce point est généralement entre l’an 2 et l’an 4 selon les hypothèses. Le présenter graphiquement est l’élément le plus percutant d’une présentation COMEX.
Note sur la conduite du changement : ne l’oubliez pas dans le coût de migration. Elle représente généralement 15 à 25 % du budget total du projet et est systématiquement sous-estimée dans les premiers chiffrages.
Étape 6 : Structurer la présentation COMEX
Un business case ERP qui convainc ne ressemble pas à une présentation technique. Il ressemble à un mémo stratégique avec des annexes chiffrées.
Structure recommandée :
- Slide de contexte (1 slide) : l’ERP actuel en chiffres — âge, version, date de fin de support, périmètre. Pas de jargon technique.
- Slide dette de maintenance (1 slide) : le coût annuel agrégé vs le benchmark marché. Mettre en évidence si on est au-dessus de la moyenne.
- Slide shadow IT et risques (1 slide) : les coûts cachés et le risque pondéré en euros.
- Slide point de bascule (1 slide) : la courbe “inaction vs migration” sur 5 ans. C’est le slide le plus important.
- Slide options (1 slide) : toujours présenter 3 scénarios (rester, migration partielle, migration complète) avec leur profil de risque et leur coût à 5 ans. Ne jamais arriver avec une seule option.
- Slide recommandation (1 slide) : le scénario recommandé, les prochaines étapes, le calendrier proposé, et le premier engagement demandé (financement d’un audit ou d’un POC, pas d’un projet complet).
Les 5 erreurs qui font échouer le business case devant le COMEX
1. Présenter des chiffres sans hypothèses documentées
Un DAF qui reçoit un tableau avec des coûts estimés va immédiatement demander : “D’où viennent ces chiffres ?” Si la réponse est floue, la crédibilité du business case s’effondre. Chaque ligne doit avoir une source : contrat, entretien, benchmark sectoriel, étude. Les estimations doivent être présentées comme telles, avec une fourchette basse et haute.
2. Proposer une seule option
Arriver avec un projet tout ou rien force le COMEX à choisir entre “oui” et “non”. La majorité des comités de direction, face à l’incertitude, choisissent “non”. Proposer trois scénarios (rester sur l’actuel, évolution incrémentale, remplacement complet) donne au comité le sentiment de choisir le meilleur chemin plutôt que d’approuver ou rejeter une proposition.
3. Sous-estimer le portage des données historiques
Le portage des données est le poste le plus souvent sous-évalué dans les premiers chiffrages. Sur un ERP de 10 ans avec des données partiellement normalisées, des champs libres, des codifications propriétaires et des historiques d’exercices comptables, le coût de migration des données peut représenter 20 à 35 % du budget projet total. Ne pas l’inclure correctement dès le départ crée une mauvaise surprise en cours de projet.
4. Ne parler que de sortie du risque
Un business case centré sur “ce qu’on évite” convainc moins bien qu’un business case qui intègre “ce qu’on gagne”. Les gains opérationnels post-migration (suppression du Shadow IT, réduction des délais de clôture comptable, meilleure visibilité des stocks, capacité à intégrer de nouveaux canaux de vente) doivent être chiffrés et présentés avec la même rigueur que les coûts évités.
5. Négliger la conduite du changement dans le budget
Intégrer la conduite du changement dans le budget dès la présentation COMEX évite deux problèmes fréquents : découvrir en cours de projet qu’il manque 15 % de budget, et se retrouver avec un ERP techniquement opérationnel mais rejeté par les utilisateurs. Une migration ERP sans conduite du changement robuste a deux fois plus de chances d’être qualifiée d’échec, même si le système fonctionne.
Les aides au financement à mentionner dans votre dossier
Une migration ERP dans une ETI française peut bénéficier de plusieurs dispositifs de financement qui réduisent le coût net du projet et peuvent faire pencher la balance lors d’une présentation COMEX :
- BPI France : les prêts de transformation digitale de BPI peuvent cofinancer des projets de modernisation ERP jusqu’à 50 % du coût éligible.
- OPCO : la partie formation (administrateurs, utilisateurs clés, équipes métier) est éligible aux prises en charge OPCO, ce qui peut représenter plusieurs dizaines de milliers d’euros sur un projet de taille moyenne.
- Crédit d’impôt innovation : si le projet inclut des développements spécifiques innovants, la partie R&D peut être éligible au CII, distinct du CIR.
Ces dispositifs ne financent pas un projet ERP dans son intégralité, mais ils réduisent le décaissement net et doivent figurer dans le tableau de coûts présenté au COMEX.
La vraie urgence : des fenêtres de migration qui se ferment
L’argument de l’urgence est souvent mal formulé. Il ne s’agit pas de “migrer avant 2027 parce que SAP l’a dit”. Il s’agit de reconnaître que les fenêtres favorables pour migrer sont limitées.
Un ERP se migre dans de bonnes conditions quand l’entreprise est stable (pas de fusion-acquisition en cours, pas de restructuration, pas de retournement de marché). Ces fenêtres durent rarement plus de 18 à 24 mois. Attendre la prochaine contrainte réglementaire ou le prochain incident de sécurité pour déclencher le projet, c’est prendre le risque de migrer en urgence, sans choix sur le calendrier, sans marge de négociation avec les prestataires, et sans budget conduite du changement correctement dimensionné.
Formulé ainsi, l’urgence n’est plus “SAP impose sa deadline” : elle devient “nous avons une fenêtre favorable maintenant, et nous risquons de ne pas en avoir une autre avant longtemps”.
Pour aller plus loin dans la préparation de votre dossier, consultez notre guide de décommissionnement d’un ERP legacy (ce qui se passe après le go-live du nouveau système) et notre comparatif TCO multi-éditeurs sur 5 ans pour benchmarker le coût total de possession de votre prochain système. Enfin, si votre ERP est encore sous contrat de maintenance, notre guide d’audit des coûts de maintenance ERP vous aidera à identifier les 20 à 30 % de budget récupérable immédiatement, sans attendre la migration.
