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.
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.
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.
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.
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.
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.
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.
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.
Le même défi sous-jacent se retrouve dans plusieurs scénarios courants :
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.
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 :
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.
Un moyen rapide d’évaluer l’exposition avant de migrer :
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.
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.
Une migration qui tient combine quatre pratiques, appliquées avant la bascule technique plutôt qu’après.
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.
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.
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.
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.
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.
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 :
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.
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.
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 ?”
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.