Pourquoi tant de migrations ERP échouent en production
Un planning de migration peut séparer cadrage, développement, tests et bascule. Cette organisation devient risquée si elle repousse la confrontation aux données réelles jusqu’à la recette : les écarts sont alors découverts quand il reste peu de temps pour les traiter.
Une migration n’est pas aboutie quand le code est écrit. Elle est aboutie quand elle est stabilisée par l’exécution.
Examiner les sources autant que la cible
Le modèle cible, ses interfaces et son paramétrage doivent être vérifiés. L’état des données sources demande la même attention, notamment :
- une documentation incomplète ou obsolète ;
- des règles métier implicites, jamais écrites, parfois contradictoires ;
- des années d’historique avec des exceptions jamais traitées ;
- des volumétries réelles très au-dessus des estimations.
Une spécification peut documenter ces difficultés. L’extraction et les contrôles sur les données réelles permettent d’en vérifier la portée et de repérer les cas qui n’y figurent pas.
Cinq risques à examiner dans le planning
Ces risques peuvent se combiner. Leur présence et leur poids doivent être évalués sur le projet :
- L’audit sacrifié. Le projet démarre sur des hypothèses parce que l’audit de données a été réduit à une revue documentaire. Le périmètre réel, personne ne l’a mesuré.
- La migration traitée comme un sous-projet technique. Placée après le paramétrage et les développements, elle peut hériter de leurs retards et manquer de temps pour qualifier les données ou obtenir les arbitrages métier.
- Des tests sur échantillons de confort. Par exemple, cinq cents articles propres peuvent passer la recette sans que les doublons et exceptions d’un périmètre de deux millions d’enregistrements aient été testés.
- L’effet tunnel du planning. Si chaque phase attend la fin de la précédente, les retards peuvent réduire le temps disponible pour les répétitions et la correction des écarts.
- Une chaîne incapable d’absorber la correction. Sans points de reprise ni isolation des erreurs, un enregistrement bloquant peut imposer de rejouer tout un lot. Prévoyez le suivi et le rejeu des erreurs, avec des scripts ou une plateforme, puis mesurez la durée de reprise.
Le vrai risque : découvrir trop tard
Des écarts peuvent subsister malgré les contrôles. Les découvrir en production ajoute une contrainte : il faut les corriger alors que l’activité dépend déjà de la cible et que les possibilités de retour arrière peuvent être réduites.
Plus on repousse la confrontation aux données réelles, plus on laisse d’incertitudes au Go-Live. Des rapports publics décrivent des perturbations et coûts de programmes ERP ; ils ne permettent toutefois pas d’attribuer toutes les pertes à la seule migration de données.
Renverser la logique
L’alternative consiste à exécuter tôt, sur des périmètres réels, et à corriger en boucle. Chaque run devient une source d’apprentissage : il révèle les cas limites, fait émerger les règles implicites, et permet de stabiliser progressivement.
C’est le principe des boucles Run / Fix de notre méthodologie : le système de migration s’exécute périmètre après périmètre, chaque écart est analysé, corrigé, rejoué. La fiabilité se construit itération après itération, longtemps avant la bascule.
Les preuves à réunir avant le Go-Live
Ces preuves éclairent la décision de bascule, sans garantir l’absence d’incident :
- le périmètre a été mesuré sur les données réelles, pas estimé en atelier ;
- des répétitions complètes sont planifiées et exécutées sur le périmètre réel, avec des valeurs et des processus métier réconciliés ;
- chaque rejet est localisé et qualifié, avec un mécanisme de reprise qui tient compte de ses dépendances ;
- un dry run à volumétrie réelle a validé la chaîne de bout en bout.
Les résultats de ces contrôles, les écarts restants et le plan de retour arrière permettent aux responsables de décider si la bascule est acceptable. Pour une vue d’ensemble du sujet (périmètre, approches de bascule, coûts), consultez notre guide de la migration de données ERP.
L’objectif est de rendre les risques mesurables et les décisions explicites avant la mise en production.