La maintenance d’un ERP on-premise de dix ans coûte, année après année, un peu plus cher pour un peu moins de valeur. Selon Gartner, d’ici 2025 les entreprises consacreront 40 % de leur budget IT à la dette technique. Les organisations qui maintiennent des systèmes legacy dépensent en moyenne entre 60 et 80 % de leur budget informatique à entretenir le passé --- au détriment de tout projet de transformation.
Pourtant, lancer un projet de replatforming ERP sans un business case solide, c’est s’exposer à deux échecs : le projet ne sera pas financé, ou il sera lancé avec un budget mal calibré et mourra au premier dépassement.
Cet article donne aux DSI et DAF une méthode structurée pour construire un dossier décisionnel qui résiste aux objections de la direction générale.
ERP legacy : de quoi parle-t-on exactement en 2026 ?
Définition d’un ERP legacy : critères techniques et commerciaux
Un ERP devient “legacy” lorsqu’il combine au moins trois des caractéristiques suivantes :
- Architecture technique dépassée : serveur on-premise propriétaire, base de données non supportée, interface client-serveur Win32 ou Java 6.
- Version hors du cycle de support mainstream de l’éditeur : pas de nouveaux correctifs de sécurité, pas de mise à jour réglementaire incluse.
- Absence d’API REST native : les intégrations se font par échange de fichiers plats ou par accès direct à la base de données.
- Dépendance à des compétences rares : développement ABAP, Progress 4GL, COBOL, RPG/AS400 --- des profils dont le marché se contracte chaque année.
- Écart fonctionnel croissant : les demandes métier s’accumulent en backlog sans calendrier de livraison.
Le critère le plus objectif reste le support éditeur. La date de fin de maintenance mainstream de SAP ECC 6.0 (Enhancement Packages 6 à 8) est fixée au 31 décembre 2027 --- et SAP a réaffirmé à plusieurs reprises que cette date ne serait pas repoussée (Rimini Street). Pourtant, selon Gartner et CIO research, seuls 39 % des clients SAP ECC avaient licencié S/4HANA fin 2024 (SAVIC Technologies) : plus de 60 % du parc installé n’a pas encore commencé sa migration.
La zone grise : l’ERP maintenu mais plus développé
La situation la plus fréquente dans les ETI françaises n’est pas un ERP clairement “en fin de vie” : c’est un ERP qui tourne, qui est maintenu par un prestataire historique, mais qui ne reçoit plus de nouvelles fonctionnalités. L’éditeur a arrêté le développement actif (ou a été racheté), le prestataire applique des patchs de sécurité, et les métiers vivent avec des lacunes fonctionnelles qu’ils compensent par Excel.
Ce cas --- que l’on peut appeler la “zombification” du SI --- est plus difficile à objectiver que la fin d’un support éditeur, car il n’y a pas de date butoir. Il faut alors se concentrer sur les coûts d’exploitation pour construire le dossier.
Panorama des ERP fréquemment concernés
- ERP métier on-premise des années 2000 : Sage 100, Cegid PMI, Divalto Weavy (anciennes générations), Sylob.
- AS/400 et applicatifs RPG : encore présents dans les ETI industrielles du Grand Est et de Normandie.
- SAP ECC 6.0 : la deadline 2027 en fait le cas le plus médiatisé.
- Microsoft Dynamics NAV : migré depuis vers Business Central, mais les installations NAV 2009-2015 en mode “on-premise gelé” existent encore.
- Logiciels métier développés en interne sur COBOL, Progress ou Clipper dans les années 1990-2000.
Les 7 signaux d’alerte qui indiquent qu’il faut agir
1. Le coût de maintenance (TMA) dépasse le coût d’un nouvel ERP sur 5 ans
C’est le signal financier le plus clair. Prenez vos factures de TMA des 3 dernières années, intégrez les coûts internes (administrateurs système, DBA, key users mobilisés sur les incidents), et projetez sur 5 ans avec une hypothèse de croissance conservatrice de 5 % par an. Comparez avec un TCO SaaS sur la même durée. Dans beaucoup de cas, le coût du statu quo dépasse déjà le coût de la migration.
2. Les compétences internes sont rares et vieillissantes
Si votre stabilité opérationnelle dépend d’une ou deux personnes maîtrisant un langage que les jeunes développeurs n’apprennent plus (ABAP version ancienne, Progress 4GL, RPG), vous êtes exposé à un risque de “bus factor” critique. Le départ d’un développeur COBOL en 2026 peut coûter 6 à 18 mois de recrutement et 180 à 250 euros de l’heure pour un freelance spécialisé.
3. L’éditeur a annoncé une fin de support
Il s’agit du déclencheur le plus dur à ignorer en COMEX. SAP ECC 2027 est l’exemple canonique. Mais il y a aussi les branches Dynamics NAV non migrées, les plateformes Oracle E-Business Suite dont certaines configurations perdent leur support étendu, et les ERP régionaux rachetés par des acteurs plus grands qui arrêtent progressivement le développement de l’ancienne gamme.
4. L’intégration des nouvelles réglementations nécessite des développements coûteux
Facturation électronique obligatoire en France dès septembre 2026 pour les grandes entreprises (PPF + opérateurs de dématérialisation), CSRD pour les entreprises de plus de 250 salariés, TVA en temps réel en Espagne, e-reporting en Allemagne --- chaque nouvelle obligation réglementaire est un chantier de développement sur un système qui ne l’a pas prévu. Si votre ERP legacy génère un devis de 80 000 à 200 000 euros par obligation réglementaire, la justification du replatforming devient arithmétique.
5. L’expérience utilisateur détériore la productivité et retient les talents
Un ERP avec une interface Win32 de 2005 crée un frein au recrutement des profils juniors et génère des coûts d’erreur de saisie mesurables. Selon une étude citée par RecordPoint, 48 % des travailleurs interrogés gaspillent plus de 3 heures par jour à cause de systèmes inefficaces, soit une perte de productivité estimée à 28 000 livres sterling par salarié et par an en contexte britannique. La traduction en contexte ETI française donne des chiffres qui s’argumentent facilement devant un DRH ou un responsable commercial.
6. L’ERP ne peut pas s’interfacer avec les outils modernes
L’absence d’API REST native empêche l’intégration naturelle avec les outils de e-commerce (Shopify, PrestaShop), de CRM (HubSpot, Salesforce), d’automatisation comptable ou d’analytics (Power BI, Tableau). Chaque intégration est un développement sur mesure qui coûte entre 20 000 et 80 000 euros par connecteur, et qui casse à chaque montée de version du système tiers.
7. La dette technique bloque les projets de transformation digitale
Un projet IA, une initiative d’automatisation RPA ou un projet de portail fournisseurs butte systématiquement sur les limites du SI central. La dette technique devient un frein stratégique quantifiable : combien de projets ont été ajournés, réduits ou annulés à cause des contraintes de l’ERP legacy ? Ce recensement, fait avec les directions métier, produit une liste d’opportunités manquées qui se chiffrent.
Remplacement, upgrade ou coexistence : cartographier les options
Avant de construire le business case d’un replatforming, il faut poser les quatre options réellement sur la table. Un bon dossier décisionnel ne présente pas une seule recommandation : il articule les quatre scénarios avec leurs coûts, délais et risques respectifs.
Option 1 --- Upgrade majeur (rester chez l’éditeur actuel)
Vous restez dans l’écosystème de l’éditeur mais montez de version. C’est le cas SAP ECC → S/4HANA, Sage 100 → Sage X3, Odoo 13 → Odoo 17. L’avantage : la continuité des processus, la conservation partielle du paramétrage existant, et une relation commerciale établie. L’inconvénient : un upgrade majeur avec plus de 40 % de customisations finit souvent en re-implémentation déguisée, à un coût équivalent au replatforming mais avec moins de remise en question des processus. Voir notre analyse des upgrades ERP majeurs pour le détail des coûts cachés.
Option 2 --- Replatforming complet (changer d’éditeur)
Vous choisissez une nouvelle plateforme ERP et réimplémentez de zéro. C’est l’option la plus structurante et la plus coûteuse à court terme, mais aussi celle qui offre le plus de gains fonctionnels et la meilleure réduction du coût de possession à 5 ans. Elle oblige à revoir les processus plutôt qu’à les reproduire --- ce qui est souvent l’occasion de corriger des inefficacités que le legacy avait enkystées.
Option 3 --- Coexistence temporaire (bimodalité)
Pour les grands groupes ou les ETI multi-entités, une approche consiste à déployer le nouvel ERP sur les nouvelles entités ou les nouvelles lignes d’activité, en maintenant le système legacy pour les périmètres stabilisés. C’est l’approche “two-speed IT”. Elle réduit le risque de bascule mais génère des coûts d’interfaçage et une complexité de gouvernance SI qui se facture sur plusieurs années.
Option 4 --- Architecture composable (remplacement module par module)
Vous conservez le coeur ERP legacy et remplacez progressivement les modules périphériques par des solutions SaaS spécialisées : un WMS cloud, un CRM moderne, un outil de e-procurement, une solution de business intelligence. C’est l’approche “best-of-breed” qui minimise le risque de bascule mais génère une multiplication des systèmes à intégrer et à maintenir.
Tableau de décision
| Option | Coût initial | Risque opérationnel | Gain fonctionnel | Recommandé si… |
|---|---|---|---|---|
| Upgrade majeur | Moyen | Moyen | Limité | < 20 % de customisations, éditeur actif |
| Replatforming complet | Élevé | Élevé (pendant le projet) | Maximum | > 40 % de customisations, éditeur inactif |
| Coexistence | Faible à court terme | Faible | Partiel | Multi-entités, rythmes différents |
| Composable | Moyen | Faible | Partiel | ERP core solide, lacunes périphériques |
Construire le business case : méthode en 5 étapes
Étape 1 --- Quantifier le coût réel du statu quo
C’est l’étape la plus négligée et la plus décisive. Le coût apparent du statu quo (licences annuelles + TMA) est systématiquement sous-estimé. Pour l’objectiver, construisez un tableau sur 5 ans qui intègre :
Coûts directs mesurables :
- Maintenance et TMA (contrat + interventions hors contrat)
- Licences et mises à jour
- Infrastructure serveur (matériel, hébergement, sauvegardes)
- Coûts de développement des nouvelles obligations réglementaires
Coûts indirects à estimer :
- Heures internes mobilisées sur les incidents (nombre de tickets × temps de résolution moyen × coût horaire interne)
- Coût des contournements Excel : recensez les tableurs parallèles et estimez le temps de saisie double, les erreurs de réconciliation, les retards de clôture
- Opportunités manquées : projets reportés, recrutements plus difficiles, limitations commerciales liées à l’absence d’intégration e-commerce
Exemple représentatif (fictif) : Une ETI industrielle de 150 M€ de CA payait 380 000 euros par an de TMA + infrastructure pour un ERP de 2009. L’ajout des coûts cachés (12 ETP partiellement mobilisés sur la gestion des incidents, 3 projets de transformation bloqués) portait le coût réel du statu quo à 620 000 euros par an. Sur 5 ans avec 7 % de croissance annuelle des coûts de maintenance, le total atteignait 3,6 millions d’euros.
Étape 2 --- Estimer le coût complet de la migration
Le TCO d’une migration ERP comporte plusieurs postes que les devis d’intégrateurs minimisent systématiquement. Pour une ETI de 100 à 500 salariés, voici les fourchettes de référence :
| Poste | Fourchette |
|---|---|
| Licences et abonnements (3 premières années) | 150 000 — 600 000 € |
| Intégration et paramétrage (intégrateur) | 200 000 — 900 000 € |
| Reprise de données (migration + nettoyage) | 30 000 — 150 000 € |
| Formation et change management | 40 000 — 120 000 € |
| Ressources internes mobilisées (key users) | 50 000 — 200 000 € |
| Double run (ancienne + nouvelle plateforme, 3-6 mois) | 20 000 — 80 000 € |
| Réintégrations périphériques | 30 000 — 200 000 € |
| Total indicatif ETI 100-500 salariés | 520 000 — 2 250 000 € |
Ces fourchettes sont larges parce que le coût dépend fortement du volume de customisations existantes, de la qualité des données maîtres, et du nombre de systèmes périphériques à réintégrer. Notre guide du TCO ERP sur 5 ans détaille ces postes pour les principaux éditeurs.
Étape 3 --- Projeter les bénéfices sur 5 ans
Les bénéfices d’un replatforming se répartissent en trois catégories :
Bénéfices directs mesurables :
- Réduction du coût de TMA (typiquement 60 à 70 % de réduction en passant en SaaS cloud, selon Forrester)
- Suppression des coûts d’infrastructure on-premise
- Élimination des coûts de développement réglementaire (inclus dans l’abonnement SaaS)
Gains de productivité :
- Réduction du temps de clôture mensuelle (gains courants : 2 à 5 jours sur des clôtures de 10-15 jours)
- Automatisation des réconciliations inter-modules
- Suppression des doubles saisies et des tableurs parallèles
Gains stratégiques :
- Déblocage des projets de transformation (e-commerce, analytics, automatisation)
- Amélioration de la capacité de recrutement (interface moderne, travail hybride natif)
- Réduction du risque de conformité réglementaire (mises à jour incluses)
Quantifiez chaque bénéfice avec une fourchette basse et haute, et documentez l’hypothèse. Un gain de productivité de 15 minutes par jour pour 50 utilisateurs se chiffre : 50 × 0,25 heure × 220 jours × 45 €/heure = 123 750 euros par an.
Étape 4 --- Calculer le point mort et le payback period
Le payback period est l’indicateur central pour un COMEX : à partir de quand l’investissement se rembourse-t-il ?
Formule simplifiée :
Payback = Coût total migration / (Économies annuelles + Gains annuels)Pour l’exemple représentatif ci-dessus : coût de migration 900 000 euros, économies annuelles (TMA + infrastructure) 350 000 euros, gains productivité estimés 120 000 euros → payback en 1,9 an. Au-delà, le nouvel ERP génère un retour net positif.
Présentez toujours trois scénarios : hypothèse basse, hypothèse centrale, hypothèse haute. Un COMEX qui voit que même le scénario pessimiste retourne l’investissement en 3 ans décide plus facilement que face à une projection unique de 2 ans que personne ne croit.
Étape 5 --- Présenter les risques du statu quo vs les risques de la migration
La direction générale n’achète pas un ROI : elle arbitre entre deux familles de risques. Votre business case doit les présenter en vis-à-vis.
| Risque du statu quo | Risque de la migration |
|---|---|
| Panne critique sans support éditeur | Dépassement de budget (+20 à +50 %) |
| Non-conformité réglementaire (amendes, blocage opérationnel) | Retard de go-live (6 à 18 mois de dépassement courant) |
| Départ des compétences legacy (bus factor) | Résistance au changement et perte de productivité temporaire |
| Blocage des projets stratégiques | Interruption partielle pendant la bascule |
| Perte de compétitivité face aux concurrents modernisés | Surcoût des intégrations périphériques |
La clé est de quantifier les risques du statu quo autant que les risques de la migration. Un risque de non-conformité réglementaire représente potentiellement x % du CA en amende. Un arrêt opérationnel de 48 heures sur un ERP de production représente un manque à gagner chiffrable.
Les 5 erreurs classiques dans un business case ERP
1. Sous-estimer le change management. Les organisations considèrent en général que la formation représente 5 à 10 % du budget. La réalité des projets réussis se situe entre 15 et 20 %. Un projet qui économise sur la formation récupère ces coûts en perte de productivité post-go-live.
2. Oublier les intégrations périphériques. Pour une ETI, le nombre de flux entrants et sortants de l’ERP dépasse régulièrement 30 à 60 points d’intégration actifs. Recenser et chiffrer ces interfaces avant de boucler le budget est non négociable.
3. Comparer des TCO incomparables. Comparer le coût d’une licence SaaS annuelle avec le coût total de possession sur 10 ans d’un ERP on-premise est une erreur fréquente dans les deux sens : soit le SaaS semble trop cher sur une année, soit le legacy semble bon marché parce qu’on a oublié les coûts cachés.
4. Ne pas inclure le coût de la dette technique accumulée pendant le gel. Chaque année sans migration est une année de dette supplémentaire. Les projets reportés ont un coût d’opportunité, les nouvelles règles réglementaires génèrent des développements one-shot, la dette de données maîtres s’accumule.
5. Présenter uniquement les bénéfices sans quantifier les risques. Un business case qui ne présente que les gains est perçu comme un document commercial, pas comme un document décisionnel. Les décideurs avisés cherchent les hypothèses conservatrices et les risques associés : donnez-les-leur.
Modèle de présentation COMEX : ce que les décideurs veulent voir
Le dossier pour le COMEX ne doit pas reproduire les 40 pages de votre analyse interne. Il se résume à une présentation de 10 à 12 slides avec un fil directeur binaire : le coût du statu quo vs le coût de l’action.
La slide de synthèse “3 options, 1 recommandation”
Présentez les trois scénarios viables (upgrade, replatforming, coexistence) en une slide avec trois colonnes : coût total 5 ans, délai du projet, niveau de risque opérationnel. Indiquez clairement votre recommandation et les deux critères décisifs qui la justifient.
Le tableau comparatif coût/risque/délai
Un tableau 3 × 3 suffit. Colorez en rouge les cases à risque élevé, en orange les cases à risque moyen, en vert les cases favorables. L’objectif est visuel : les décideurs doivent comprendre en 10 secondes pourquoi l’option recommandée est préférable.
La question des ressources internes
Le COMEX posera inévitablement la question : “Qui va porter ce projet ?”. Anticipez-la avec un organigramme de projet simplifié : sponsor (DG ou DAF), chef de projet interne (DSI ou profil dédié), représentants métier par domaine (finance, supply chain, commercial, RH). Chiffrez les jours-homme sur 18 mois et estimez la charge par rapport au temps plein de chaque contributeur.
Par où commencer : les 3 premières actions concrètes
Si vous avez terminé la lecture de cet article avec la conviction qu’un replatforming s’impose, voici les trois premières actions à mener dans les 30 jours :
-
Lancer l’audit interne. Réunissez DSI, DAF et 2-3 key users pour une session de 4 heures sur la grille d’audit décrite dans notre guide d’évaluation ERP avant migration. Vous sortirez avec un score sur 100 points et une liste des lacunes prioritaires.
-
Quantifier le coût réel du statu quo. Demandez à votre contrôle de gestion de consolider les factures de TMA des 3 dernières années, les coûts d’infrastructure et une estimation du temps interne. C’est la première slide de votre futur business case.
-
Identifier 3 projets bloqués par le legacy. Dans chaque direction métier, demandez : “Qu’auriez-vous fait avec un ERP moderne que vous ne pouvez pas faire aujourd’hui ?”. Ces projets représentent le coût d’opportunité du statu quo --- le levier le plus convaincant pour un COMEX.
Pour aller plus loin, consultez notre comparatif TCO ERP sur 5 ans pour chiffrer précisément le coût de possession des principales plateformes, et notre guide de décommissionnement d’un ERP legacy pour anticiper dès maintenant la phase d’extinction du système actuel.
