La migration de données est le chantier le plus sous-estimé d’un projet ERP. Le paramétrage mobilise les ateliers, la formation capte l’attention de la direction, la conduite du changement occupe les consultants. Pendant ce temps, les données restent dans un coin, gérées par une équipe réduite qui découvre l’ampleur du problème à trois semaines du go-live.
Les retours terrain convergent : selon un rapport fréquemment cité par Gartner, 83 % des projets de migration de données dépassent leur budget ou leur calendrier (Oracle, reprenant Gartner). Bloor Research a mesuré des dépassements moyens de 30 % sur les coûts et de 41 % sur les délais dans ses enquêtes sectorielles (Bloor Research, via ResearchGate). Ces chiffres ne sont pas des fatalités : ils reflètent surtout un manque de méthode.
Cet article détaille une approche en sept étapes pour migrer les données d’un ERP ancien vers un ERP neuf, du premier inventaire jusqu’aux contrôles post-bascule.
Pourquoi la migration de données est le chantier le plus sous-estimé d’un projet ERP
Les trois causes d’échec les plus fréquentes
Les données sales. Un ERP de dix ans contient des doublons (le même fournisseur sous trois raisons sociales différentes), des orphelins (des lignes de commande pointant vers un article supprimé), des formats incohérents (dates en JJ/MM/AAAA dans un module, MM/DD/YYYY dans un autre) et des champs vides là où le nouvel ERP attend une valeur obligatoire. Le problème n’est pas technique, il est organisationnel : personne n’a jamais nommé un responsable de la qualité des données.
Le mapping incomplet. Le système source a un modèle de données. Le système cible en a un autre. Entre les deux, il y a un travail de traduction que l’intégrateur appelle le « mapping ». Quand ce mapping est fait en atelier sans les métiers (la compta, les achats, la logistique), il oublie les cas limites : les codes articles historiques, les conditions de prix en cascade, les tiers avec plusieurs adresses de livraison. Ces oublis se révèlent en dry run, parfois en production.
Les tests insuffisants. Un seul dry run avant le go-live, c’est un pari. Deux dry runs, c’est un minimum. Trois, c’est la norme dans les projets qui réussissent. Chaque répétition révèle des erreurs que la précédente n’avait pas testées, parce que le périmètre des scénarios s’élargit à mesure que les métiers comprennent ce qu’ils doivent vérifier.
Le vrai coût d’une migration ratée
Une migration ratée ne se mesure pas seulement en jours-hommes de correction. Elle se mesure en clôtures comptables retardées, en commandes bloquées, en factures rejetées par les clients, en stocks fantômes qui faussent le réapprovisionnement. Un CFO qui ne peut pas clôturer pendant deux mois après le go-live mobilise toute l’équipe finance sur du retraitement au lieu de piloter l’activité. Un directeur logistique qui découvre 30 % de doublons dans le fichier articles perd la confiance de ses équipes terrain.
Le coût de la préparation est prévisible et maîtrisable. Le coût d’une correction post-go-live ne l’est jamais.
Étape 1 : cartographier les données sources et cibles
Inventaire des objets métier
Le point de départ est un inventaire exhaustif des objets métier à migrer. Pas un inventaire technique (tables, champs, vues), un inventaire fonctionnel : quels sont les objets que les utilisateurs manipulent au quotidien et qui doivent exister dans le nouvel ERP pour que l’activité tourne le premier jour ?
La liste type pour une ETI industrielle ou de services :
- Tiers : clients, prospects, fournisseurs, sous-traitants (avec leurs contacts, adresses, conditions de paiement, RIB)
- Articles : références produits ou services, nomenclatures, gammes, unités de mesure, classifications
- Écritures comptables : balances d’ouverture, en-cours clients et fournisseurs, immobilisations
- Stocks : quantités en stock par emplacement, lots, numéros de série
- Commandes en cours : bons de commande ouverts (achats et ventes), livraisons partielles
- Documents : pièces jointes, scans de contrats, bons de livraison archivés
Chaque objet doit être documenté avec son volume (nombre d’enregistrements), sa criticité (bloquant pour le J1 ou migreable plus tard) et son propriétaire métier (qui validera la qualité).
Matrice de mapping source vers cible
Le mapping est un document de travail, pas un livrable de consultant qu’on range dans un dossier partagé. Il décrit, champ par champ, comment une donnée du système source se transforme pour entrer dans le système cible.
Un mapping de qualité contient au minimum :
| Élément | Contenu |
|---|---|
| Champ source | Nom technique + nom fonctionnel + exemple de valeur |
| Champ cible | Nom technique dans le nouvel ERP + format attendu |
| Règle de transformation | Concaténation, conversion de code, valeur par défaut, lookup dans une table de correspondance |
| Cas limites | Que fait-on si le champ source est vide ? Si la valeur n’existe pas dans la table cible ? |
| Responsable validation | Le référent métier qui signe la règle |
Ne pas faire ce travail en amont, c’est le faire en urgence pendant le dry run, avec des décisions prises au fil de l’eau qui ne seront documentées nulle part.
Étape 2 : auditer et nettoyer les données avant migration
Les cinq types de problèmes à traquer
Un audit de données avant migration cherche cinq familles de problèmes :
-
Les doublons. Le même client sous trois codes différents. Le même article avec un espace en trop dans le libellé. Deux fournisseurs qui sont en réalité la même entité juridique après une fusion. La déduplication est le chantier le plus consommateur de temps, mais aussi le plus rentable : chaque doublon éliminé avant migration, c’est un rapprochement comptable en moins après.
-
Les orphelins. Une ligne de commande qui pointe vers un article supprimé. Un contact rattaché à un client qui n’existe plus. Un mouvement de stock sur un emplacement fermé. Les orphelins cassent les contraintes d’intégrité référentielle du nouvel ERP, qui est souvent plus strict que l’ancien.
-
Les formats incohérents. Numéros de téléphone avec ou sans indicatif. Codes postaux à 4 chiffres dans un champ qui en attend 5. Dates dans trois formats différents selon le module d’origine. Montants avec virgule ou point décimal selon la locale du poste de saisie.
-
Les données obsolètes. Articles non commandés depuis cinq ans. Fournisseurs en cessation d’activité. Prospects jamais convertis depuis 2018. Migrer ces données pollue le nouvel ERP dès le premier jour. L’arbitrage « migrer ou archiver » doit être tranché par les métiers, pas par l’IT.
-
Les champs vides obligatoires. Le nouvel ERP exige un code TVA sur chaque fournisseur. L’ancien ne l’exigeait pas. Résultat : 40 % des fiches fournisseurs n’ont pas de code TVA. Il faut enrichir avant de migrer, pas après.
Outils de profiling et de qualité de données
Le choix de l’outillage dépend du volume et de la complexité :
-
Scripts SQL maison : suffisants pour une PME avec un périmètre limité (moins de 100 000 enregistrements, 3-4 objets métier). Le référent IT écrit des requêtes de comptage, de détection de doublons (GROUP BY + HAVING COUNT > 1), de vérification de formats (REGEXP). Avantage : zéro coût de licence. Inconvénient : pas de traçabilité ni de workflow de correction intégré.
-
Outils ETL avec profiling intégré : Talend Data Quality, Informatica Data Quality, Microsoft SSIS + DQS. Ces outils proposent un profiling automatique (distribution des valeurs, taux de remplissage, détection d’anomalies) et des règles de standardisation (normalisation d’adresses, matching flou pour la déduplication). Adaptés aux ETI avec des volumes importants ou des sources hétérogènes.
-
Modules natifs de l’ERP cible : SAP Information Steward (pour les migrations vers S/4HANA), les data import tools de Dynamics 365, l’assistant d’importation Odoo. Moins puissants que les outils dédiés, mais intégrés au workflow de chargement.
Dans tous les cas, le profiling doit produire un rapport chiffré : taux de remplissage par champ, nombre de doublons détectés, distribution des valeurs aberrantes. Ce rapport est le tableau de bord du data steward pendant toute la phase de nettoyage.
Étape 3 : concevoir le pipeline ETL (Extract, Transform, Load)
Choix de l’outil ETL vs scripts manuels vs connecteurs natifs
L’acronyme ETL désigne les trois phases du transfert : extraction des données du système source, transformation selon les règles de mapping, chargement dans le système cible. Le choix de l’approche dépend de plusieurs facteurs.
Scripts manuels (Python, SQL, PowerShell). Pour les petites migrations (une seule source, quelques dizaines de milliers d’enregistrements, un mapping simple). Avantage : flexibilité totale, pas de licence. Risque : pas de gestion d’erreurs standardisée, pas de rejeu automatique, documentation souvent absente.
Outils ETL professionnels (Talend, Informatica PowerCenter, Microsoft SSIS, Apache NiFi). Pour les migrations complexes avec sources multiples, transformations en cascade, et besoin de traçabilité. Ces outils offrent un designer visuel des flux, une gestion des rejets (enregistrements en erreur redirigés vers une table de quarantaine), et des logs exploitables. Le coût de licence se justifie dès que le volume dépasse 200 000 enregistrements ou que les sources dépassent trois systèmes.
Connecteurs natifs de l’ERP. SAP Migration Cockpit, les Data Entities de Dynamics 365, les fichiers CSV de l’import Odoo. Ces connecteurs couvrent les objets standard (clients, articles, écritures d’ouverture) mais montrent leurs limites sur les objets custom, les historiques volumineux ou les transformations complexes. Ils sont un bon complément, rarement un outil suffisant à eux seuls.
Gestion des transformations complexes
Certaines transformations méritent une attention particulière :
Codes articles. L’ancien ERP utilise un codage alphanumérique libre (« CABLE-CUI-3x2.5-100M »), le nouveau impose un code structuré à 12 chiffres. La table de correspondance doit être construite avec les achats et la production, pas par l’IT seul.
Multi-devises. Les écritures en devises étrangères doivent être migrées avec le cours de change historique, pas le cours du jour. Le mapping doit préciser quelle table de cours utiliser et comment traiter les écarts de conversion.
Historiques. Migrer cinq ans d’écritures comptables dans le détail ou seulement les soldes d’ouverture ? Migrer l’historique des commandes ou seulement les commandes ouvertes ? Chaque choix a un coût (volume de données, temps de chargement, complexité des tests) et une valeur (comparabilité inter-exercices, traçabilité pour les auditeurs). L’arbitrage est un arbitrage métier, pas technique.
Étape 4 : exécuter les dry runs et valider
Planning des répétitions
Un dry run est une répétition générale de la migration, exécutée dans un environnement de test avec des données réelles (ou un échantillon représentatif). Son objectif n’est pas de « voir si ça marche », mais de mesurer ce qui ne marche pas et de corriger avant la vraie bascule.
Dry run 1 : validation technique. Le pipeline ETL tourne-t-il de bout en bout sans erreur bloquante ? Les volumes sont-ils cohérents (nombre d’enregistrements chargés vs extraits) ? Les temps de chargement sont-ils compatibles avec la fenêtre de bascule prévue ? Ce premier passage révèle les erreurs de mapping grossières, les problèmes de formats et les contraintes d’intégrité non anticipées.
Dry run 2 : validation fonctionnelle. Les référents métier vérifient que les données migrées sont exploitables. Le commercial retrouve-t-il ses clients avec les bonnes conditions de paiement ? Le comptable retrouve-t-il les soldes d’ouverture ? Le logisticien retrouve-t-il ses stocks par emplacement ? Ce deuxième passage mobilise les métiers pendant deux à cinq jours.
Dry run 3 : répétition générale. Exécuté dans des conditions aussi proches que possible de la bascule réelle : même fenêtre horaire, même séquençage des chargements, mêmes contrôles post-migration. C’est le test de la procédure, pas seulement des données. Si le dry run 3 se passe sans incident majeur, le go/no-go de la migration finale peut être prononcé.
Stratégie de validation
La validation repose sur trois mécanismes complémentaires :
-
Rapprochement par comptage. Nombre d’enregistrements extraits vs chargés, par objet métier. Tout écart doit être expliqué (rejets, filtres, déduplications volontaires).
-
Rapprochement comptable. Totaux des balances d’ouverture, des en-cours clients et fournisseurs, des stocks valorisés. Le contrôle de gestion doit valider que les totaux dans le nouvel ERP correspondent à ceux de l’ancien, à l’euro près.
-
Tests utilisateurs sur échantillon. Les référents métier ouvrent 20 à 50 fiches au hasard et vérifient visuellement que les informations sont complètes et correctes. Ce contrôle par sondage détecte les erreurs systématiques (un champ décalé d’une colonne dans le mapping, une règle de transformation qui inverse deux codes).
Étape 5 : migration finale et bascule (cutover)
Fenêtre de bascule : gel des transactions et séquençage
La bascule est le moment où les données quittent définitivement l’ancien système pour alimenter le nouveau. C’est une opération irréversible dans les faits (même si un rollback est possible en théorie), et elle doit être planifiée avec la rigueur d’une opération chirurgicale.
Le gel des transactions. Pendant la fenêtre de bascule, aucune transaction ne doit être saisie dans l’ancien système. Cela signifie : plus de commandes, plus de réceptions, plus d’écritures comptables. La durée du gel dépend du volume de données et de la vitesse du pipeline ETL. Pour une ETI typique, compter entre 24 et 72 heures. Ce gel doit être planifié avec les métiers (un week-end prolongé, une période creuse, la fin d’un mois comptable clôturé).
Le séquençage des chargements. L’ordre de chargement respecte les dépendances entre objets : d’abord les données de référence (plan comptable, unités de mesure, devises), puis les tiers (clients, fournisseurs), puis les articles, puis les en-cours (commandes ouvertes, stocks), et enfin les écritures comptables d’ouverture. Charger les commandes avant les articles, c’est créer des orphelins dès le premier chargement.
Plan de rollback en cas d’échec
Un plan de rollback n’est pas un luxe, c’est une obligation. Il doit répondre à trois questions :
-
À quel moment décide-t-on de revenir en arrière ? Définir les critères de go/no-go post-chargement : écart comptable supérieur à un seuil, taux de rejet supérieur à 5 %, impossibilité de valider un processus critique (facturation, clôture).
-
Comment revient-on en arrière ? L’ancien système est-il encore opérationnel ? Les données saisies dans le nouveau système pendant les premières heures de test sont-elles récupérables ? Un snapshot de l’ancien système pris juste avant la bascule est le filet de sécurité minimal.
-
Combien de temps le rollback prend-il ? Si la réponse est « 48 heures », et que l’entreprise ne peut pas se permettre 48 heures sans ERP, il faut un plan B (fonctionnement dégradé, saisie manuelle, bascule partielle).
Étape 6 : contrôles post-migration et stabilisation
Rapprochements automatisés
Les premières 48 heures après la bascule sont critiques. Un jeu de contrôles automatisés doit tourner en continu :
- Comptages d’enregistrements par objet métier, comparés aux comptages de l’extraction finale
- Totaux comptables : balance générale, balance auxiliaire clients, balance auxiliaire fournisseurs, stock valorisé
- Intégrité référentielle : aucune commande ne pointe vers un article inexistant, aucune écriture ne pointe vers un compte supprimé
- Complétude des champs obligatoires : aucun tiers sans code TVA, aucun article sans unité de mesure
Ces contrôles doivent être scriptés et exécutés en un clic, pas réalisés manuellement dans un tableur. L’objectif est de détecter un problème en minutes, pas en jours.
Période d’hypercare et processus de correction
L’hypercare est une période de support renforcé qui suit immédiatement le go-live, en général de quatre à douze semaines. Pendant cette période :
-
Un guichet unique centralise les signalements des utilisateurs (e-mail dédié, canal Teams/Slack, outil de ticketing). Chaque signalement est qualifié : erreur de migration (donnée absente ou incorrecte), erreur de paramétrage (le système fonctionne mais pas comme attendu), ou erreur utilisateur (formation complémentaire nécessaire).
-
Un data steward (ou référent données) traite les corrections de données au fil de l’eau. Ce rôle, souvent assuré par un utilisateur clé métier, est le point de contact entre les équipes fonctionnelles et l’équipe technique.
-
Un comité de suivi hebdomadaire passe en revue les indicateurs de stabilisation : nombre de tickets ouverts, délai de clôture comptable, taux de rejet des factures entrantes et sortantes, écarts de stock constatés lors des inventaires partiels.
La fin de l’hypercare est prononcée quand les indicateurs reviennent à un niveau comparable à celui de l’ancien système. Pas avant.
Checklist récapitulative de la migration de données ERP
| Étape | Livrables | Critères de validation |
|---|---|---|
| 1. Cartographie | Inventaire des objets métier, matrice de mapping | Mapping signé par chaque référent métier |
| 2. Audit et nettoyage | Rapport de profiling, plan de déduplication | Taux de doublons réduit sous 2 %, champs obligatoires remplis à 100 % |
| 3. Pipeline ETL | Flux ETL développés et documentés, table de correspondance des codes | Pipeline exécutable de bout en bout sans erreur bloquante |
| 4. Dry runs | 3 dry runs documentés, PV de validation métier | Écarts comptables inférieurs à 0,01 %, taux de rejet inférieur à 1 % |
| 5. Cutover | Procédure de bascule chronométrée, plan de rollback | Bascule exécutée dans la fenêtre prévue, rollback testé |
| 6. Contrôles post-migration | Scripts de rapprochement, tableau de bord de stabilisation | Zéro écart comptable, intégrité référentielle confirmée |
| 7. Hypercare | Guichet unique opérationnel, comité de suivi | Indicateurs revenus au niveau pré-migration sous 4-12 semaines |
Migration big-bang vs migration incrémentale : quel choix ?
Deux grandes approches coexistent, chacune avec ses avantages et ses inconvénients.
La migration big-bang bascule toutes les données en une seule opération, pendant un week-end ou une période de fermeture. Avantage : une seule coupure, un seul effort de coordination, un seul jeu de contrôles post-migration. Inconvénient : si la bascule échoue, le rollback concerne l’intégralité du périmètre. C’est l’approche la plus courante pour les ETI mono-site.
La migration incrémentale (ou par vagues) bascule les données par entité, par site ou par module. Avantage : chaque vague est plus petite, plus facile à tester et plus facile à corriger. Inconvénient : les systèmes source et cible coexistent pendant des semaines ou des mois, ce qui nécessite des interfaces de synchronisation temporaires et une gestion de la période de double saisie. C’est l’approche privilégiée pour les groupes multi-sites ou les migrations très volumineuses.
Le choix dépend du nombre de sites, du volume de données, de la tolérance à l’arrêt de l’activité et de la capacité de l’équipe projet à gérer la complexité d’une coexistence temporaire.
Les rôles clés de la migration de données
Trois rôles sont indispensables et souvent absents de l’organigramme projet :
Le data steward. Ni IT, ni métier : un profil hybride qui comprend le modèle de données et les règles de gestion. Il pilote le nettoyage, tranche les cas de déduplication ambigus, et valide les règles de transformation. Sans data steward, les décisions de mapping sont prises par l’intégrateur, qui ne connaît pas l’historique des données.
Le référent métier. Un par domaine fonctionnel (finance, achats, logistique, commercial). Il valide que les données migrées correspondent à la réalité métier. Il signe les PV de dry run. Il est le dernier rempart avant le go-live.
Le responsable du cutover. Il orchestre la bascule comme un chef d’orchestre : il gère le séquençage, surveille les temps de chargement, déclenche les contrôles, et prononce le go/no-go. Ce rôle est souvent tenu par le chef de projet ERP, mais il mérite une responsabilité dédiée sur les migrations volumineuses.
Ce qu’il ne faut pas oublier
Quelques points que les équipes projet découvrent trop tard :
-
Les pièces jointes. Contrats scannés, bons de livraison signés, photos de produits. Elles ne sont pas dans les tables métier, elles sont dans un blob storage ou un répertoire réseau. Il faut les migrer aussi, ou accepter de perdre l’accès.
-
Les workflows et les signatures électroniques. Un bon de commande validé dans l’ancien système n’a plus de statut « validé » dans le nouveau. Faut-il reconstituer l’historique de validation ou repartir à zéro ?
-
Les droits d’accès. Le mapping des profils utilisateurs entre l’ancien et le nouveau système est rarement un copier-coller. Les rôles ont changé, les modules ont été réorganisés, les règles de ségrégation des tâches (SoD) ne sont pas les mêmes.
-
L’arbitrage historique. Migrer cinq ans de commandes fermées a un coût (volume, temps de chargement, complexité des tests) et une valeur (reporting comparatif, traçabilité pour les auditeurs). Si la valeur ne justifie pas le coût, archiver dans un datawarehouse ou un outil de consultation dédié, et ne migrer dans l’ERP que les données vivantes.
Pour approfondir le sujet, consultez notre guide complet de la migration ERP qui couvre l’ensemble du projet de changement de système, notre guide d’implémentation ERP 2026 pour la méthodologie projet globale, et notre checklist de tests et recette ERP pour structurer la phase de validation qui suit la migration de données.
