Pourquoi tant de migrations ERP échouent en production
La plupart des projets de migration sont planifiés comme une ligne droite : on cadre, on développe, on teste, on bascule. Sur le papier, c’est rassurant. Dans les environnements ERP et PLM industriels, c’est précisément ce qui les fait échouer.
Une migration n’est pas aboutie quand le code est écrit. Elle est aboutie quand elle est stabilisée par l’exécution.
Le problème n’est pas le système cible
Quand une migration explose en fin de projet, le réflexe est d’accuser l’outil cible. Dans la réalité, le système cible fait rarement défaut. Ce sont les données sources qui réservent les surprises :
- 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.
Aucun de ces points ne se voit dans une spécification. Ils n’apparaissent qu’à l’exécution, sur des données réelles.
Le vrai risque : découvrir trop tard
Le danger n’est pas qu’il y ait des écarts. Il y en aura toujours. Le danger, c’est de les découvrir en production, au moment où la marge de correction est nulle et où le coût d’une erreur est maximal.
Plus on repousse la confrontation aux données réelles, plus on accumule de dette invisible. Et cette dette se paie comptant le jour du Go-Live.
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.
La mise en production n’est alors plus un saut dans le vide. C’est la dernière d’une longue série d’exécutions déjà maîtrisées.
La complexité ne disparaît pas pour autant. Mais elle cesse d’être subie : elle se maîtrise.