Migration de données : risques, checklist et bonnes pratiques pour les systèmes legacy

Une migration de données échoue rarement à cause du pipeline technique. Elle échoue à cause de ce qui n’allait déjà pas dans les données avant que quiconque ne commence à les déplacer.

Un tel projet peut avoir une architecture ETL irréprochable, un schéma cible bien testé et une équipe compétente, tout en produisant malgré tout un système auquel personne ne fait confiance. Pourquoi ? Parce que les doublons, les champs manquants et les formats incohérents qui vivaient discrètement dans l’ancien système sont transférés intacts dans le nouveau.

C’est encore plus vrai lorsque la source est un système legacy. Les équipes budgétisent généralement du temps pour l’extraction, la logique de transformation et les tests de la nouvelle plateforme. Elles budgétisent rarement un temps équivalent pour comprendre ce qui ne va réellement pas dans les données qu’elles s’apprêtent à déplacer.

Résultat : des problèmes accumulés pendant des années sont fidèlement reproduits dans un système censé les corriger.

Ce guide couvre ce qu’est une migration de données, pourquoi les systèmes legacy compliquent particulièrement l’exercice, les risques qui causent réellement l’échec ou le blocage des projets, une checklist pratique à dérouler avant de s’engager, et ce à quoi ressemble une approche de dédoublonnage et de réconciliation en pratique — illustrée par un cas réel ayant consolidé 17 systèmes distincts en un référentiel unique de confiance.

Qu'est-ce qu'une migration de données ?

Une migration de données consiste à déplacer des données d’un système source vers un système cible, tout en préservant leur exactitude, leur cohérence, leur complétude et leur traçabilité.

Le terme couvre des situations très variées : passer d’un ancien CRM à un nouveau, fusionner plusieurs ERP après une acquisition, migrer vers une plateforme cloud ou consolider plusieurs bases en un référentiel unique.

Mais le défi sous-jacent reste le même : s’assurer que ce qui arrive dans le système cible est digne de confiance, pas seulement présent.

C’est là que la distinction avec un système legacy devient importante. Une migration entre deux systèmes modernes part généralement d’une base de données raisonnablement structurée. Une migration depuis un système legacy part rarement de cette position.

Pourquoi les systèmes legacy compliquent la migration de données

Un système legacy, en termes concrets, est un système IT — souvent un ERP, un mainframe ou une base de données fonctionnant sur des plateformes comme IBM AS/400 ou Db2 — qui fait toujours son travail, mais ne peut plus être mis à niveau ni connecté facilement à des outils plus récents.

Les organisations continuent à s’appuyer sur ces systèmes parce que les remplacer est perturbateur. Mais cette dépendance signifie que des années de données s’y sont accumulées avec les standards de qualité en vigueur à l’époque — des standards rarement documentés et rarement cohérents.

C’est ce qui distingue ce type de projet d’une migration entre systèmes modernes. Un transfert entre deux environnements récents a généralement des schémas clairs des deux côtés et des hypothèses raisonnables sur la qualité des données. Une source legacy, en général, n’a ni l’un ni l’autre.

Le système a été construit, modifié et étendu sur des années, parfois des décennies, souvent par des personnes qui ne sont plus dans l’entreprise. Les données qu’il contient reflètent chaque changement de process, chaque fusion, chaque contournement et chaque règle métier informelle ajoutée en chemin.

La conséquence pratique, c’est que la connectivité elle-même devient une contrainte. Les outils ETL modernes sont conçus autour de sources de données modernes : bases cloud, API REST, schémas bien documentés. Des plateformes legacy comme AS/400 et Db2 nécessitent souvent des connecteurs dédiés simplement pour lire les données de façon fiable, avant même que le travail de qualité ne puisse commencer.

Un plan qui suppose qu’une connectivité standard fonctionnera sur une source legacy repose souvent sur la première hypothèse qui se brise.

Pourquoi les risques de migration sont surtout des risques de qualité des données, pas des risques techniques

La plupart des cadres de gestion des risques se concentrent sur les points de défaillance techniques : extraction incomplète, transformations cassées, interruption pendant la bascule.

Ces risques sont réels. Mais ce sont aussi ceux pour lesquels les équipes se préparent par défaut.

Les risques qui font réellement dérailler les projets sont souvent des risques de qualité des données.

Risques courants d'une migration de données

Les risques les plus coûteux ne se manifestent pas toujours comme des erreurs techniques. Ils apparaissent souvent après la mise en production, quand les équipes commencent à exploiter le nouveau système et découvrent que les données ne sont pas fiables.

• Les doublons se multiplient à l’arrivée. Un fournisseur ou un client qui existait sous trois noms légèrement différents dans l’ancien système ne se fusionne pas automatiquement simplement parce qu’il arrive dans une nouvelle base. Il devient trois fiches dans un système censé être plus propre.
• Des données disparaissent silencieusement dans les champs non mappés. Les systèmes legacy contiennent souvent des champs que personne n’utilise au quotidien, mais qui portent encore un historique métier pertinent. Si le mapping ne les prend pas en compte, cet historique disparaît sans que personne ne s’en aperçoive immédiatement.
• Les formats incohérents cassent la logique en aval. Une date stockée en texte à un endroit et en valeur structurée à un autre peut “réussir” au sens technique, tout en cassant discrètement chaque rapport ou règle qui dépend d’un format cohérent.
• Plus personne ne comprend pleinement les données source. La connaissance institutionnelle de certains champs, codes ou exceptions métier est souvent partie avec les personnes qui ont construit ou maintenu le système legacy.
• Les règles métier n’ont jamais été documentées. Une logique qui vivait dans la tête d’un analyste — par exemple “ce code de statut signifie inactif” — n’a aucune définition formelle à transférer avec les données elles-mêmes.
• La réconciliation intervient trop tard. Vérifier que la source et la cible correspondent est souvent laissé pour après la bascule, alors que corriger un écart implique déjà de toucher un système en production.

Aucun de ces problèmes ne se manifeste comme une tâche échouée. Ils apparaissent des mois plus tard, sous la forme d’un rapport qui ne se réconcilie pas ou d’un processus qui a discrètement cessé de fonctionner.

Migrer la donnée vs migrer le système

Les deux sont souvent planifiés comme un seul et même projet, mais ce ne sont pas le même problème.

Migrer le système est un exercice d’infrastructure : déployer la nouvelle plateforme, la configurer, la connecter aux outils nécessaires et préparer la bascule technique.

Migrer la donnée est un exercice de qualité : décider ce qui constitue une fiche valide, résoudre les doublons, réconcilier les champs, vérifier les formats et s’assurer que ce qui arrive dans le nouveau système est réellement exploitable.

Une bascule système techniquement réussie avec des données non corrigées n’est pas un succès. C’est une façon plus rapide et plus coûteuse de conserver les mêmes problèmes — désormais plus difficiles à corriger parce qu’ils sont incrustés dans un système que tout le monde suppose propre.

Migration de données vs migration ETL

Les outils ETL sont conçus pour déplacer et transformer des données d’un système à un autre. C’est un travail différent de s’assurer que les données déplacées sont exactes, dédupliquées, complètes et fiables.

Un pipeline peut extraire, transformer et charger chaque enregistrement d’une source legacy sans accroc technique, tout en chargeant malgré tout trois versions du même client, un champ date que personne ne sait interpréter de façon cohérente et un identifiant fiscal déjà faux dans la source.

Une migration ETL peut déplacer les données. Mais sans profilage, dédoublonnage, réconciliation et traçabilité, elle peut aussi déplacer les erreurs.

Cette garantie nécessite une couche de qualité des données travaillant en parallèle de la logique de transformation, pas à sa place : profilage, matching et réconciliation doivent être appliqués avant ou pendant le transfert, et non supposés parce que le pipeline s’est exécuté avec succès.

Exemples de migration de données

Le même défi sous-jacent se retrouve dans plusieurs scénarios courants :

• Migration d’un ancien CRM vers un CRM moderne — consolider des fiches clients qui ont dérivé au fil d’années de saisie manuelle et de variations régionales.
• Migration AS/400 ou Db2 vers une base moderne — quitter une infrastructure de l’ère mainframe en préservant des décennies de données métier accumulées.
• Migration ERP — réconcilier des données fournisseurs, produits et financières que plusieurs modules ont touchées indépendamment au fil du temps.
• Migration vers Microsoft Dynamics ou une plateforme moderne équivalente — souvent le déclencheur qui fait enfin émerger des années de données source non corrigées.
• Consolidation de plusieurs systèmes CRM ou ERP en un référentiel unique — le scénario au cœur du cas CCI Paris Île-de-France détaillé plus loin.
• Migration vers un data warehouse ou une plateforme analytique cloud — où les incohérences de format source deviennent immédiatement visibles dès que des tableaux de bord en dépendent.

Ces exemples montrent une même réalité : la destination technique peut changer, mais la qualité des données source détermine si la migration crée de la confiance ou déplace simplement les problèmes existants.

Comment savoir si une migration de données a réellement réussi

Une migration qui s’achève dans les délais n’est pas forcément une migration qui a fonctionné. Quelques indicateurs révèlent généralement le résultat réel :

• Taux de doublons après bascule. Si la même entité apparaît encore plusieurs fois dans le nouveau système, la migration a déplacé la donnée sans résoudre sa qualité sous-jacente.
• Écarts de réconciliation. Des différences inexpliquées entre le nombre de fiches source et cible signalent généralement une perte silencieuse de données pendant le mapping, pas un transfert propre.
• Délai avant le premier signalement “ce chiffre semble faux”. Un nouveau système contesté quelques semaines après sa mise en service est un signal fort que des problèmes source non corrigés ont fait le voyage avec les données.
• Volume de corrections manuelles post-migration. Si les équipes corrigent encore les mêmes catégories d’erreurs des mois après la bascule, la migration a traité l’infrastructure, mais pas la qualité des données.

Ces signaux comptent parce qu’un projet de migration est généralement jugé terminé au moment où la bascule technique réussit — bien avant que quiconque ne puisse dire si les données à l’intérieur sont réellement fiables.

Checklist de risque pour la migration de données

Un moyen rapide d’évaluer l’exposition avant de migrer :

• Les fiches source ont-elles été profilées pour détecter les doublons avant le début du mapping ?
• Tous les champs critiques sont-ils mappés, y compris ceux rarement utilisés mais toujours pertinents pour le métier ?
• Les incohérences de format — dates, identifiants, devises — sont-elles identifiées à travers les systèmes source ?
• Existe-t-il un processus défini pour fusionner les doublons plutôt que de tous les reporter ?
• Chaque fiche migrée peut-elle être retracée jusqu’à sa source d’origine à des fins d’audit ?
• Existe-t-il un plan de retour en arrière ou de réconciliation si des écarts apparaissent après la bascule ?
• Les équipes métier — pas seulement l’IT — sont-elles impliquées pour définir à quoi ressemble une fiche “correcte” ?
• La qualité des données est-elle validée après la migration, et pas seulement supposée parce que le travail technique s’est terminé ?

Si plusieurs réponses sont incertaines, le risque n’est pas seulement technique. C’est le signe que des problèmes de qualité peuvent être reportés dans le nouveau système sans être résolus.

Vous ne savez pas si vos données source sont prêtes à migrer ?

Lancez un Flash Audit avant de figer le mapping pour identifier les doublons, formats incohérents, champs non mappés et risques qualité dans vos systèmes legacy.

Comment aborder la migration de données depuis des systèmes legacy

Une migration qui tient combine quatre pratiques, appliquées avant la bascule technique plutôt qu’après.

Profiler avant de mapper

Comprendre l’état réel des données source — doublons, champs manquants, formats incohérents — doit intervenir avant que le mapping des champs ne soit finalisé, pas être découvert en cours de migration.

Le profilage permet de voir ce qui existe réellement dans le système legacy avant de décider comment les données doivent être déplacées vers le système cible.

Résoudre les doublons à la source

Le matching flou et le full-text join peuvent identifier des fiches faisant référence à la même entité même quand les noms, le formatage ou l’ordre des mots diffèrent. Cela permet de capter des correspondances qu’une règle de correspondance exacte simple manquerait.

L’objectif n’est pas seulement de déplacer toutes les fiches. Il est de décider quelles fiches méritent de devenir des données fiables dans le nouveau système.

Réconcilier avec des référentiels faisant autorité

Des registres externes — identifiants fiscaux, bases d’adresses, référentiels nationaux — peuvent valider et enrichir les fiches pendant la migration, plutôt que de reporter sans contrôle ce qui existait dans le système legacy.

Migrer par lots contrôlés et traçables

Déplacer les données par étapes, avec validation entre chaque lot, permet de détecter les problèmes tôt plutôt que de les découvrir après la bascule complète.

La traçabilité est essentielle : chaque fiche migrée doit pouvoir être expliquée après le transfert, et pas simplement supposée correcte.

En pratique : consolider 17 systèmes CRM en un Golden Record

La Chambre de Commerce et d’Industrie Paris Île-de-France a mené un projet de 3 ans pour consolider 17 systèmes CRM distincts en un référentiel unique de confiance, ou “Golden Record”, dans le cadre d’une réorganisation plus large.

La multitude de sources, de champs et de formats impliqués représentait une complexité importante pour l’équipe. Les traitements de nettoyage, formatage, dédoublonnage et enrichissement ont été industrialisés dans des workflows répétables et programmables.

Le projet a mobilisé du matching flou et du full-text join pour aligner les fiches entre systèmes malgré leurs origines différentes, ainsi que des référentiels nationaux comme la Base Adresse Nationale et la Base Sirene pour valider et mettre à jour les fiches pendant la consolidation.

Ce cas montre qu’une migration réussie ne consiste pas seulement à déplacer les données. Elle consiste à les consolider, les dédoublonner, les enrichir et les rendre traçables avant leur exploitation dans le système cible.

Logiciel de migration legacy : que rechercher

Tous les outils de données ne gèrent pas bien les sources legacy. Les systèmes de l’ère mainframe et AS/400, en particulier, nécessitent une connectivité spécifique que les outils ETL généralistes ne couvrent pas toujours nativement.

Les capacités qui comptent le plus sont :

• Connectivité native aux bases legacy, incluant IBM Db2 et AS/400, pas seulement les bases cloud modernes.
• Matching flou et full-text, pour capter les doublons qu’une règle de correspondance exacte manquerait, surtout lorsque les conventions de nommage legacy sont incohérentes.
• Profilage des données avant mapping, pour connaître l’état réel des données source avant que les décisions de mapping ne soient figées.
• Réconciliation avec des référentiels faisant autorité, pour valider et enrichir les fiches pendant la migration plutôt qu’après.
• Migration par lots traçables, avec points de contrôle de validation, plutôt qu’une bascule unique tout-ou-rien.
• Gestion des règles en No-Code, pour que les équipes métier puissent définir à quoi ressemble une fiche valide ou dupliquée sans dépendre d’un backlog de développement.
• Historique d’audit et record lineage, pour expliquer chaque fiche migrée après la bascule.
• Monitoring post-migration, pour éviter que la qualité ne se dégrade immédiatement après la mise en production.

Sans profilage, matching, réconciliation et traçabilité intégrés, un outil de migration peut déplacer les données efficacement tout en déplaçant chaque problème de qualité existant avec elles.

Où se positionne Tale of Data

Tale of Data se connecte directement aux sources legacy — y compris IBM Db2 et AS/400 — aux côtés des bases modernes, fichiers et plateformes cloud, pour que la migration ne commence pas par un contournement de connectivité.

Concrètement, cela signifie profiler les données source pour faire émerger doublons, champs manquants et formats incohérents avant que le mapping de migration ne soit finalisé ; résoudre les doublons par matching flou et full-text ; réconcilier les fiches avec des données de référence externes, incluant les registres nationaux d’entreprises ; valider et enrichir les données pendant le transfert ; puis migrer par lots contrôlés et traçables avec un historique d’audit complet.

La plateforme ne remplace pas le système cible. Tale of Data se positionne comme la couche de qualité et de contrôle entre les sources legacy et le système cible — celle qui décide ce qui mérite réellement de faire le voyage.

Conclusion

Une migration legacy ne réussit pas parce que les données ont été déplacées. Elle réussit quand le nouveau système démarre avec des données plus propres, réconciliées et traçables que l’ancien.

Pour les organisations qui remplacent des systèmes legacy, modernisent leur infrastructure ou consolident plusieurs applications, la question la plus importante n’est pas seulement : “pouvons-nous migrer les données ?” C’est plutôt : “pouvons-nous faire confiance aux données une fois arrivées ?”

Vous ne savez pas exactement où en sont vos données source avant de migrer ?

Demandez un Flash Audit gratuit pour identifier les doublons, formats incohérents, champs non mappés et risques qualité dans vos systèmes legacy avant la migration.

Si vous souhaitez aller plus loin, démarrez un essai gratuit et testez le profilage, le dédoublonnage et la réconciliation sur vos propres données.