Vous avez choisi votre nouvel ERP, bouclé le go-live, et les équipes saisissent dans le nouveau système. Le projet est terminé, pensez-vous. Sauf que l’ancien ERP tourne encore. Les licences sont facturées, les serveurs consomment, un administrateur maintient le système « au cas où ». Six mois passent, puis un an, puis deux.
Ce scénario est courant. Et il est coûteux. Selon un article d’ERP Today, les organisations devraient allouer 15 à 20 % de leur budget total d’implémentation ERP spécifiquement au décommissionnement du système legacy. Celles qui ne le font pas se retrouvent avec un « ERP fantôme » qui draine des ressources sans produire de valeur.
Ce guide propose un plan structuré en huit étapes pour éteindre proprement un ancien ERP. Pas un article sur « pourquoi migrer » (ce sujet est traité dans notre guide de l’audit ERP), mais un plan opérationnel pour le « comment éteindre » sans perdre vos données, votre conformité ni votre sommeil.
Pourquoi le décommissionnement est un projet à part entière
Les risques d’un « on éteindra plus tard »
La tentation est forte de repousser l’extinction de l’ancien système. Les utilisateurs veulent pouvoir « vérifier dans l’ancien » pendant quelques mois. L’équipe projet est fatiguée après le go-live. Le budget est consommé.
Le problème est que « plus tard » ne vient jamais. Sans date butoir formalisée, l’ancien ERP reste en service par inertie. Les accès ne sont pas révoqués, les mises à jour de sécurité ne sont plus appliquées, et le système devient un vecteur de risque cyber croissant. ERP Today rapporte que les grandes entreprises qui conservent un legacy non sécurisé s’exposent à des coûts potentiels de 4,2 à 7,3 millions de dollars par an, en incluant l’exposition aux rançongiciels et les pertes d’efficacité (ERP Today, 2025).
Le décommissionnement doit donc être planifié dès le lancement du projet de migration, avec un budget dédié, un responsable identifié et un calendrier engageant.
Coûts cachés du maintien d’un ERP fantôme
Un ERP legacy en survie artificielle génère des coûts dans quatre catégories :
- Licences : les contrats éditeurs continuent de courir tant que le système est en production. Même en mode « consultation seule », la plupart des éditeurs facturent les utilisateurs nommés.
- Infrastructure : serveurs, stockage, sauvegardes, supervision. Sur un hébergement on-premise, le coût annuel d’un environnement ERP legacy se chiffre souvent entre 50 000 et 150 000 euros pour une ETI.
- Compétences : maintenir un système vieillissant exige des profils rares (COBOL, RPG, ABAP ancien). Ces compétences coûtent cher et se raréfient.
- Risque réglementaire : un système non maintenu ne reçoit plus les correctifs de sécurité ni les mises à jour fiscales. Le risque de non-conformité augmente chaque mois.
Selon TJC Group, certains secteurs comme la banque et l’assurance consacrent jusqu’à 75 % de leur budget IT à la préservation de systèmes legacy (TJC Group). Sans atteindre ces proportions, une ETI industrielle peut facilement gaspiller 100 000 à 200 000 euros par an sur un ERP fantôme.
Les 8 étapes du plan de décommissionnement
Étape 1 : inventaire des dépendances
Avant de débrancher quoi que ce soit, cartographiez tout ce qui touche à l’ancien système :
- Interfaces entrantes et sortantes : EDI fournisseurs, flux bancaires, connecteurs CRM, synchronisation e-commerce, exports BI.
- Rapports et états : identifiez les états encore générés depuis l’ancien système. Certains utilisateurs contournent le nouveau système en allant chercher « leur » rapport dans l’ancien.
- Flux batch et tâches planifiées : traitements de nuit, purges automatiques, calculs de prix, recalculs de stock.
- Accès directs à la base : requêtes SQL ad hoc, macros Excel connectées, outils de reporting tiers.
Livrable attendu : une matrice de dépendances avec, pour chaque flux, le statut (migré vers le nouveau système, à migrer, à supprimer) et le responsable métier.
Étape 2 : cartographie des obligations d’archivage légal
L’archivage des données n’est pas optionnel. Les durées de conservation varient selon les pays, et les ignorer expose l’entreprise à des sanctions lors d’un contrôle fiscal.
| Pays | Durée de conservation comptable | Base légale |
|---|---|---|
| France | 10 ans | Art. L123-22 Code de commerce |
| Allemagne | 8 à 10 ans (8 ans pour les pièces comptables depuis janvier 2025, 10 ans pour les bilans et livres) | HGB §257 / GoBD |
| Belgique | 7 ans (standard fiscal), 10 ans pour les pièces servant de base comptable | Code de droit économique |
Conséquence pratique : vous ne pouvez pas simplement « supprimer la base de données ». Il faut extraire, archiver dans un format pérenne et garantir l’accès en lecture pendant toute la durée légale.
Pour les entreprises soumises au RGPD, le DPO doit également valider la stratégie de purge des données personnelles (article 17 du RGPD, droit à l’effacement). Les données personnelles qui ne relèvent pas d’une obligation légale de conservation doivent être supprimées ou anonymisées.
Étape 3 : extraction et archivage des données historiques
L’extraction doit couvrir trois périmètres :
- Données transactionnelles : écritures comptables, factures, commandes, mouvements de stock. Ce sont les données soumises aux obligations d’archivage légal.
- Données de référence : plans de comptes, fiches articles, fiches clients/fournisseurs. Elles sont nécessaires pour donner du sens aux transactions archivées.
- Paramétrages et documentation : les règles de gestion, les workflows, les droits d’accès. Utiles en cas d’audit ou de litige pour prouver que le système fonctionnait selon les règles en vigueur.
Les formats d’archivage pérennes à privilégier :
- PDF/A-3 : pour les documents (factures, rapports) avec pièces jointes incorporées.
- XML structuré (SAF-T, FEC) : pour les données comptables, lisibles par les outils de contrôle fiscal.
- Export SQL ou CSV structuré : pour les données transactionnelles volumineuses, accompagnées d’un dictionnaire de données.
Point critique : l’archive doit être validée avant l’extinction du système source. Lancez des contrôles de cohérence (totaux de contrôle, nombre d’écritures, soldes comptables) entre l’ancien système et l’archive. Une archive incomplète découverte après extinction est un problème majeur.
Étape 4 : plan de cohabitation et période de double run
Le double run, cette période où les deux systèmes fonctionnent en parallèle, est inévitable mais doit être borné dans le temps. Au-delà de trois à six mois, les utilisateurs cessent de saisir rigoureusement dans le nouveau système puisqu’ils savent que l’ancien est encore là « en filet de sécurité ».
Le plan de cohabitation doit définir :
- La date de début : généralement le jour du go-live du nouveau système.
- La date de fin ferme : communiquée à tous les utilisateurs dès le go-live. Cette date doit être validée par la direction générale pour qu’elle ait un poids suffisant.
- Les règles de saisie : pendant le double run, seul le nouveau système est le système de référence. L’ancien est en mode « consultation seule » (pas de nouvelles écritures).
- Les critères de sortie : quels indicateurs doivent être au vert pour passer à l’étape suivante (par exemple, zéro écart de rapprochement comptable entre les deux systèmes sur le dernier mois clôturé).
Étape 5 : déconnexion progressive des interfaces
La déconnexion des interfaces est l’étape la plus technique. Procédez par ordre de criticité inverse : commencez par les flux les moins critiques pour monter en confiance.
Séquence recommandée :
- Reporting et BI : redirigez les sources de données vers le nouveau système. Vérifiez que les tableaux de bord produisent les mêmes résultats.
- Flux secondaires : synchronisation CRM, portail fournisseurs, outils RH connectés.
- Flux financiers : exports comptables, interfaces bancaires, déclarations fiscales. Ces flux sont les derniers à basculer car ils sont les plus sensibles.
- EDI partenaires : prévenez vos partenaires commerciaux du changement de format ou de canal. Un EDI coupé sans préavis peut bloquer une chaîne d’approvisionnement.
Chaque déconnexion doit être documentée (date, responsable, test de non-régression) et réversible pendant 48 heures en cas de problème.
Étape 6 : désactivation des accès utilisateurs et révocation des licences
Procédez en deux temps :
- Passage en lecture seule : désactivez toutes les transactions de saisie. Les utilisateurs peuvent encore consulter, mais plus créer ni modifier.
- Révocation complète : après la période de consultation (typiquement un à deux mois en lecture seule), fermez tous les accès.
Documentez les accès révoqués dans un registre (qui avait accès à quoi, date de révocation). Ce registre est utile en cas d’audit de conformité.
Côté éditeur, notifiez formellement la fin d’utilisation et négociez la résiliation du contrat de maintenance. Certains éditeurs imposent des préavis de six à douze mois : vérifiez vos clauses contractuelles dès le début du projet de décommissionnement.
Étape 7 : audit de complétude avant extinction définitive
Avant d’appuyer sur le bouton « off », passez en revue cette checklist :
- Toutes les données soumises à obligation légale de conservation ont été archivées et validées
- Les archives sont lisibles indépendamment du système source (test d’ouverture sur un poste vierge)
- Aucune interface active ne pointe encore vers l’ancien système
- Tous les accès utilisateurs sont révoqués
- Les licences éditeur sont résiliées ou en cours de résiliation
- Le DPO a validé la conformité RGPD de la stratégie de purge
- Un rapport de clôture est rédigé et archivé (périmètre, dates, décisions, anomalies résiduelles)
- La direction générale a formellement validé l’extinction
Cet audit doit être réalisé par une personne différente de celle qui a piloté le décommissionnement. Le regard croisé évite les angles morts.
Étape 8 : extinction infrastructure et clôture du contrat éditeur
L’extinction technique couvre :
- Arrêt des services applicatifs : serveur d’applications, serveur de base de données, middleware.
- Sauvegarde finale : une dernière sauvegarde complète de l’environnement, stockée hors site, conservée selon la politique de rétention définie à l’étape 2.
- Démontage de l’infrastructure : restitution des serveurs physiques, résiliation des machines virtuelles, suppression des environnements cloud.
- Clôture contractuelle : confirmation écrite de fin de contrat avec l’éditeur, récupération du certificat de destruction des données si applicable.
Conservez la documentation technique (schémas d’architecture, procédures d’exploitation) pendant au moins cinq ans. En cas de litige ou d’audit, elle permet de prouver que le système a été exploité et éteint dans les règles.
Erreurs fréquentes et comment les éviter
Garder l’ancien ERP « au cas où » pendant trois ans
C’est l’erreur la plus répandue. La justification est toujours la même : « on ne sait jamais, si on a besoin de vérifier quelque chose ». En pratique, après six mois, les consultations dans l’ancien système deviennent anecdotiques. Après un an, elles sont quasi nulles.
La solution : archivez les données (étape 3), donnez accès à l’archive en lecture, et éteignez le système. L’archive remplit la fonction de consultation sans les coûts de maintien en vie d’un environnement complet.
Oublier les obligations FEC et SAF-T sur les données archivées
En France, l’administration fiscale peut demander le Fichier des Écritures Comptables (FEC) sur les dix derniers exercices. Si vos données sont archivées dans un format propriétaire illisible sans l’ancien système, vous êtes en infraction.
La parade : exportez le FEC de chaque exercice au format normé (XML conforme à l’article A.47 A-1 du Livre des procédures fiscales) avant d’éteindre le système. Pour les entreprises opérant en Scandinavie ou en Europe de l’Est, le format SAF-T s’impose selon les mêmes principes.
Checklist récapitulative
Voici les jalons clés du plan de décommissionnement, à intégrer dans votre planning projet dès le lancement de la migration :
| Phase | Jalon | Délai indicatif |
|---|---|---|
| Cadrage | Inventaire des dépendances terminé | M-6 avant extinction |
| Cadrage | Obligations d’archivage cartographiées | M-6 |
| Extraction | Données historiques extraites et validées | M-3 |
| Cohabitation | Fin du double run | M-2 |
| Déconnexion | Toutes les interfaces basculées | M-1 |
| Clôture | Accès révoqués, audit de complétude passé | M-0 |
| Clôture | Infrastructure éteinte, contrat éditeur clôturé | M+1 |
Le calendrier typique s’étale sur six à neuf mois après le go-live du nouveau système. Le raccourcir en dessous de quatre mois est risqué. Le laisser dépasser douze mois, c’est accepter de payer pour un système qui ne sert plus.
Pour aller plus loin sur les aspects techniques de la migration de données, consultez notre guide méthodologique sur la migration de données ERP. Si vous êtes en phase d’évaluation de votre système actuel, notre méthodologie d’audit ERP en 7 dimensions vous aidera à objectiver le diagnostic. Et si la dépendance éditeur est un sujet de préoccupation, notre guide sur le vendor lock-in ERP propose un cadre d’analyse et une stratégie de sortie structurée.
