01 Une migration de données ERP, c'est quoi exactement ?
Une migration de données ERP consiste à transférer les données d'un système de gestion vers un autre : d'un ERP historique vers S/4HANA, d'un legacy maison vers IFS, ou de plusieurs instances fusionnées vers une seule. Mais la définition honnête est plus exigeante. Il s'agit de reconstruire un patrimoine de données dans un modèle qui ne l'attend pas.
Deux chantiers demandent des responsabilités explicites. La migration de système couvre installation, paramétrage et formation. La migration de données couvre extraction, transformation, qualification et chargement. Ils se contraignent mutuellement et demandent un planning partagé avec l’intégrateur et les équipes métier.
Il faut comprendre le modèle cible et ses interfaces autant que l’histoire des sources. Des données sources mal connues créent des risques qu’un déploiement techniquement réussi ne résout pas.
Vous migrez un référentiel technique (Windchill, 3DEXPERIENCE, Teamcenter) plutôt qu'un système de gestion ? Les structures produit obéissent à d'autres règles : voir le guide de la migration de données PLM.
02 Le maillon qui décide du succès du projet
Une perturbation ERP peut affecter la fabrication, les expéditions et le service client. Notre article sur le coût d’une migration ratée examine les rapports de Revlon, Hershey et de la Navy en distinguant effets sur les ventes, charges supplémentaires et dépenses de programme.
Ces rapports n’isolent pas la migration de données comme cause unique. Pour votre programme, une valeur fausse chargée dans un ERP qui pilote production, stocks et facturation constitue un risque concret à tester avant la bascule.
03 Quelles données migrer, et lesquelles laisser derrière
Tout migrer est une erreur aussi coûteuse que de migrer trop peu. Le périmètre se décide par catégorie :
- Les données de référence (articles, nomenclatures, clients, fournisseurs, plan comptable) : le cœur du chantier. Elles doivent être qualifiées, dédoublonnées et conformées au modèle cible. C'est là que se joue la qualité du futur système ;
- Les données transactionnelles ouvertes (commandes en cours, stocks, encours de production, écritures non soldées) : indispensables à la continuité d'activité, et les plus sensibles au timing de la bascule ;
- L’historique : décidez ce qui doit rester opérationnel dans la cible et ce qui peut demeurer dans une archive consultable, selon les besoins d’accès et de conservation. Comparez les coûts sur votre périmètre réel.
04 Tout commence par l'audit des données réelles
Avant d'arbitrer quoi que ce soit, il faut savoir ce qui existe vraiment : volumétries effectives, doublons, objets orphelins, référentiels divergents, exceptions accumulées. L'audit de données est la phase qu'on néglige toujours, et c'est pourtant celle qui conditionne toutes les autres.
Un audit sérieux extrait et profile l'intégralité des données sources, pas un échantillon de confort. Son livrable est une cartographie chiffrée du risque : ce qui passe tel quel, ce qui demande une règle, ce qui exige un arbitrage métier. Sans lui, le planning du projet repose sur des hypothèses. Or les hypothèses sont exactement ce qui fait échouer les migrations.
05 Big bang, phasé, fil de l'eau : choisir son approche
La stratégie de bascule détermine quand la responsabilité passe du système source à la cible. Choisissez-la après avoir mesuré volumes, dépendances, interruption acceptable et besoins de coexistence.
La bascule big bang transfère le périmètre convenu dans une seule fenêtre. Elle concentre le risque opérationnel : durée, critères d’acceptation et retour arrière doivent être répétés.
La bascule phasée procède par site, domaine ou famille de données. Chaque vague demande une frontière cohérente, des interfaces temporaires et un responsable pour les données partagées.
La migration au fil de l’eau transfère progressivement les données pendant la coexistence. Définissez le système de référence par famille et la propagation des changements ; une synchronisation bidirectionnelle n’est nécessaire que lorsque les deux systèmes doivent écrire.
Dans chaque cas, une chaîne répétable avec suivi et rejeu permet de corriger les écarts avant la bascule.
Comparer les stratégies de bascule | Stratégie | Organisation | Contrainte principale | Preuve avant bascule |
|---|
| Big bang | Une fenêtre pour le périmètre convenu | Interruption et reprise après les premières transactions en cible | Répétition à volumétrie réelle, réconciliation chronométrée et retour arrière testé |
| Phasée | Vagues successives par périmètre cohérent | Données partagées et interfaces temporaires entre vagues | Carte des dépendances, responsabilités et réconciliation entre systèmes |
| Fil de l’eau | Transfert progressif pendant la coexistence | Capture des changements et écritures concurrentes | Retard de réplication mesuré, règles de conflit et réconciliation finale |
06 Ce que l’outillage de migration doit permettre
L’outillage doit rendre les transformations, le suivi des chargements et les corrections répétables. Des scripts ou une plateforme dédiée peuvent répondre à ce besoin : les exigences portent sur la reproductibilité et la visibilité des erreurs.
Une chaîne asynchrone avec statut et rejeu par enregistrement est une approche possible. Prévoyez des répétitions du périmètre complet et suivez ce que chacune établit : écarts restants, contrôles métier et durée de bascule.
07 Les cinq phases d'une migration maîtrisée
Notre méthodologie complète détaille chaque phase ; en résumé :
- 01 · Audit : mesurer le périmètre réel, les volumétries, les anomalies. La réalité avant les hypothèses ;
- 02 · Build : construire une chaîne configurable, traçable et répétable, avec statuts, réconciliation et rejeu ;
- 03 · Run / Fix : exécuter sur des périmètres réels, corriger chaque écart, boucler jusqu'à stabilisation ;
- 04 · Dry Run : la répétition générale, à volumétrie réelle, sur la chaîne complète ;
- 05 · Go-Live : basculer après revue des critères d’acceptation, des écarts restants et des modalités de retour arrière.
08 Les pièges qui coûtent le plus cher
Cinq risques à intégrer au plan de migration :
- Valider uniquement sur des échantillons propres. Utilisez des cas difficiles pendant le développement et une réconciliation du périmètre complet avant la recette.
- Confondre donnée valide et donnée qualifiée. Une donnée correcte dans l'ancien système peut violer le modèle cible. S/4HANA en est l'exemple type : MATDOC, ACDOCA et le journal universel ne pardonnent pas les reprises non conformées ;
- Faire confiance aux outils natifs. Les passerelles standard déplacent des enregistrements, pas des structures. Le cas Windchill vers 3DEXPERIENCE le montre : liens, nomenclatures et cycles de vie doivent être reconstruits, pas copiés ;
- Découvrir les volumétries au chargement. Les estimations initiales peuvent omettre des sources ou de l’historique ; mesurez et rapprochez le périmètre tôt.
- Geler le code trop tôt, les données trop tard. Les données vivent jusqu'au jour de la bascule : la chaîne doit absorber les deltas, pas les subir.
09 Ce qui détermine le budget
L’estimation tient compte des systèmes sources, familles de données, interfaces, historiques et dépendances. La volumétrie compte, tout comme les règles et arbitrages nécessaires pour rendre les données utilisables en cible.
Avant l’audit, listez ces éléments et identifiez les référents métier disponibles pour arbitrer. Un nombre de systèmes ou un pourcentage du coût des licences ERP ne suffit pas à chiffrer le travail.
L’audit de préparation est cadré et chiffré séparément. Ses constats servent à estimer les transformations, itérations, réconciliations et opérations de bascule.
10 Un cas réel anonymisé : plusieurs sites, plusieurs vérités
Un groupe industriel, quatre sites de production, migrait un ERP maison et deux systèmes locaux vers une instance S/4HANA. L’intégrateur était en place, la conception fonctionnelle validée et le chantier données prévu sur deux mois en fin de planning.
Constat de l’audit. Le périmètre annoncé était de 250 000 articles actifs ; l’extraction en a révélé 412 000. Deux sites continuaient de créer des articles dans un legacy supposé arrêté depuis 2019. Parmi eux, 61 000 doublons entre sites portaient des codifications ou unités différentes ; dans 9 000 cas, les fournisseurs déclarés comme source unique divergeaient.
Intervention. Les doublons candidats ont été regroupés avec leurs usages et stocks, puis routés aux responsables de site pour arbitrage. La chaîne a conservé la trace des décisions. Les conversions d’unités ont été reconstruites sous forme de règles explicites.
Résultat. L’arbitrage a mobilisé les quatre équipes de site à temps partiel pendant onze semaines, et le Go-Live a été décalé d’un trimestre. La chaîne a effectué 28 passes complètes. Pendant la bascule, 351 000 articles ont été chargés ; 240 rejets ont été qualifiés et rejoués dans la fenêtre. Aucun arrêt de production.
Ce cas montre l’effet du cadrage : rendre visible l’effort d’arbitrage alors que le calendrier peut encore être ajusté. Les volumes et résultats décrivent cette mission ; ils ne constituent pas un engagement pour un autre programme.
11 Checklist de migration des données ERP
Les vérifications à rattacher au planning, avec une preuve et un responsable pour chacune.
- Inventorier et extraire chaque source du périmètre, y compris les systèmes supposés inactifs ; vérifier ce statut ;
- Mesurer les enregistrements et anomalies : comptages par famille, doublons, objets orphelins et écarts au modèle cible ;
- Séparer règles automatiques et décisions métier, puis réserver le temps d’arbitrage dans le planning ;
- Nommer un responsable métier par famille de données, habilité à décider ;
- Convenir du périmètre historique, des besoins de consultation et de conservation ;
- Rendre la chaîne répétable, avec statut et rejeu par enregistrement ;
- Tester les valeurs et les processus métier, puis réconcilier le périmètre complet ; voir ce que chaque test établit ;
- Préparer les changements après extraction : capturer, transformer et réconcilier les deltas ;
- Exécuter un dry run à volumétrie réelle, interfaces cibles et réconciliation chronométrée comprises ;
- Convenir du responsable, des seuils et de l’heure limite du retour arrière avant la fenêtre de bascule.