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.
Cinq causes qui reviennent dans tous les post-mortems
Les projets diffèrent, les mécanismes d’échec se répètent. Cinq reviennent systématiquement :
- 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. Reléguée en fin de planning, après le paramétrage et les développements, elle hérite de tous les retards. Elle découvre donc les problèmes en dernier, quand plus rien n’est négociable.
- Des tests sur échantillons de confort. Cinq cents articles propres passent la recette sans accroc. Les deux millions d’enregistrements réels, avec leurs doublons et leurs exceptions historiques, ne l’ont jamais traversée.
- L’effet tunnel du planning en ligne droite. Cadrage, développement, recette, bascule : chaque phase absorbe le retard de la précédente, et c’est toujours la confrontation aux données réelles qui recule. Le tunnel s’ouvre au pire moment : le Go-Live.
- Une chaîne incapable d’absorber la correction. Un batch monolithique échoue en bloc : un enregistrement bloquant, et on rejoue tout. Sans une chaîne conçue pour isoler et rejouer les erreurs, chaque anomalie découverte tard coûte une fenêtre de bascule.
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, en dizaines de millions d’euros dans les cas documentés (Gifi, Revlon, Hershey’s, Haribo).
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.
À quoi reconnaît-on une migration qui ne ratera pas
Quelques signes ne trompent pas, et ils sont vérifiables bien avant le Go-Live :
- le périmètre a été mesuré sur les données réelles, pas estimé en atelier ;
- des runs complets tournent dès les premières semaines, sur des données de production ;
- chaque rejet est localisé, qualifié et rejouable individuellement ;
- un dry run à volumétrie réelle a validé la chaîne de bout en bout.
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. 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.
La complexité ne disparaît pas pour autant. Mais elle cesse d’être subie : elle se maîtrise.