Migration de données : transférer le sens, pas seulement les lignes

La migration de données est la partie de tout changement de système qui détermine si le projet a réussi, et c’est la partie que la plupart des plans traitent comme un simple bouton d’exportation. Déplacer des lignes, c’est trivial. Le vrai travail, c’est de transférer le sens : des champs détournés de leur usage il y a des années, le même client présent quatre fois, un historique qu’un organisme de réglementation peut exiger, et des totaux qui doivent concorder au dollar près de l’autre côté. Une migration bien faite est un processus répété, reproductible et rapproché, avec un retour arrière possible — pas une fin de semaine héroïque. Faite ainsi, c’est aussi le moment où l’organisation nettoie enfin des données dont elle s’excuse depuis que l’ancien système était neuf.

Là où ça dérape :

Les champs ne veulent pas dire ce que leur nom indique. Tout système de longue date a un champ qui a changé de sens en 2016, un code de statut qui veut dire une chose avant une certaine date et une autre après, et une colonne de notes qui fait le travail de cinq champs manquants. Une migration dont la correspondance est établie à partir du schéma plutôt que des données reproduit les étiquettes et perd le sens.

L’identité n’est pas résolue, et le désordre vous suit. Le même client saisi quatre fois, avec trois orthographes, ne devient pas un seul client parce qu’on change de base de données. Si le traitement des doublons n’est pas une étape explicite avec des règles explicites — ce qui fait que deux fiches n’en sont qu’une, laquelle l’emporte pour chaque champ — le nouveau système hérite des querelles de l’ancien dès le premier jour.

L’historique est abandonné parce qu’il dérange. Les équipes migrent les dossiers ouverts et abandonnent discrètement les dossiers fermés, puis découvrent la piste de vérification, l’obligation de conservation de sept ans, ou la conversation de renouvellement qui exige de savoir ce qui s’est passé en 2021. Ce qui migre, ce qui est archivé en lecture seule et ce qui est vraiment supprimé relève d’une décision à prendre délibérément — au Canada, en tenant compte de la LPRPDE (PIPEDA) et de la Loi 25 du Québec — et non d’un effet secondaire de ce que l’exportation a pu traiter.

Le rapprochement à l’œil. Ouvrir le nouveau système, vérifier dix fiches au hasard et crier victoire, c’est comme ça que des migrations passent le vendredi et échouent à la fin du mois. Si le nombre de fiches, les totaux financiers et des comparaisons champ par champ sur un échantillon ne sont pas calculés des deux côtés et mis en concordance, personne ne sait vraiment si la migration a fonctionné — on sait seulement qu’elle a l’air correcte.

Une bascule à sens unique, sans retour arrière. La migration exécutée une seule fois, à la main, pendant la fin de semaine de mise en service, ne peut être ni répétée ni annulée. Quand un problème surgit — et il en surgit — le choix se fait entre avancer tant bien que mal avec des données erronées et une restauration imprévue qui fait perdre des jours de nouveau travail. Les deux sont évitables avec un plan qui prévoyait une deuxième tentative.

Comment on le bâtit vraiment :

Profiler les vraies données avant de promettre quoi que ce soit. Avant d’établir la correspondance d’un seul champ : taux de valeurs nulles, distribution des valeurs, fiches orphelines, dates antérieures à la fondation de l’entreprise, et champs dont le contenu ne correspond pas au nom. Le profilage représente quelques jours de travail qui font passer l’estimation de la migration d’une supposition à un plan, et c’est là que chaque mauvaise surprise coûte le moins cher à découvrir.

Établir la correspondance champ par champ, avec un responsable et un registre des décisions. Chaque champ source reçoit une destination, une règle de transformation ou une décision explicite de le laisser derrière — et le nom de la personne qui a tranché. Le document de correspondance est le contrat de toute la migration; quand un chiffre semble faux en mars, le registre dit ce qui a été décidé et pourquoi, au lieu d’un projet d’archéologie.

Bâtir la migration comme un script reproductible, et la répéter. La migration s’exécute sous forme de code, de bout en bout, sur une copie — puis encore, et encore, chaque répétition corrigeant ce qu’elle a révélé et réduisant la durée d’exécution. Au moment de la vraie bascule, la question intéressante n’est plus de savoir si ça fonctionne, mais à quel point les chiffres correspondent à la dernière répétition. Une migration manuelle exécutée une seule fois, c’est la répétition zéro, faite en production.

Rapprocher avec des chiffres des deux côtés. Des décomptes par type de fiche, des sommes financières par période et des comparaisons aléatoires champ par champ au niveau des fiches, calculés de façon indépendante sur la source et sur la destination, puis mis en concordance. Les écarts sont expliqués, pas ignorés — un écart connu et documenté est acceptable; un écart inexpliqué arrête tout.

Basculer par étapes, avec l’ancien système gelé et consultable. Le système source passe en lecture seule au moment de la bascule pour que rien ne diverge, et reste consultable pour que tout litige puisse être vérifié. Quand le risque le justifie, une courte exploitation en parallèle sur un processus valide le nouveau système contre la réalité avant que le reste suive. Le retour arrière est un point de décision prévu au plan, pas une improvisation.

Archiver la source et fixer une date de fin. L’ancienne base de données est conservée en lecture seule, avec des accès définis et une durée de conservation définie, et la date de mise hors service est consignée par écrit. Les migrations qui ne se terminent jamais officiellement laissent l’organisation payer deux systèmes et ne se fier qu’à moitié à chacun — exactement la situation que le projet devait éliminer.

La question de l’IA :

Une migration, c’est de la mise en correspondance, et la mise en correspondance est maintenant beaucoup plus rapide : l’IA lit le schéma d’un système patrimonial et son contenu réel, prépare une première version des correspondances de champs, signale les colonnes détournées de leur usage, propose des règles de détection des doublons et écrit le code de transformation — le travail qui rendait les soumissions de migration si lourdes. Ce qu’elle ne fait pas, c’est assumer le résultat. Savoir si deux fiches semblables désignent un seul client, quel historique l’organisme de réglementation peut exiger et ce qu’un rapprochement concordant doit démontrer, ce sont des décisions qu’une personne responsable doit prendre, parce que le coût d’une erreur tombe des mois plus tard, en production, sur vous.

VX-N utilise l’IA dans ses outils de profilage, de correspondance, de transformation et de rapprochement — c’est une des raisons pour lesquelles des migrations chiffrées en mois sont répétées et livrées en quelques semaines, avec des chiffres vérifiés des deux côtés plutôt que tenus pour acquis.

Notre verdict : Migrez moins que vous le pensez, et plus délibérément que le bouton d’exportation le laisse croire. Les dossiers ouverts et l’historique que les opérations consultent vraiment migrent au complet, nettoyés et rapprochés; l’historique ancien va dans une archive en lecture seule, assortie d’une décision de conservation; les données réellement mortes sont documentées et laissées derrière. N’acceptez jamais un plan de migration sans profilage préalable, sans répétition ou sans rapprochement des deux côtés — chacune de ces absences mène à l’échec correspondant. Et voyez la migration comme l’occasion unique de régler l’identité et le sens : transférer fidèlement dans un nouveau système des données qu’on sait sales, c’est payer pour un nouveau départ et le refuser.

Combien de temps prend la migration des données d’un système patrimonial?

Ce qui détermine vraiment la durée, c’est le sens, pas le volume — un million de lignes propres se déplacent plus vite que cinquante mille lignes avec des champs détournés et des doublons non résolus. Après le profilage, l’estimation est réelle; les répétitions ramènent ensuite la bascule elle-même à quelques heures. Une migration chiffrée avant que quiconque ait regardé les vraies données, c’est une soumission pour un autre jeu de données.

Est-ce que ça change quelque chose que la destination soit Salesforce, SAP ou un système sur mesure?

Moins que ce que les fournisseurs laissent entendre. La destination change la mécanique de chargement et les objets qui existent pour recevoir les données; le travail difficile — profilage, correspondance, résolution des identités, rapprochement — est identique. Une équipe qui n’a jamais chargé qu’une seule plateforme a tendance à être forte sur la mécanique et muette sur le sens.

Quelle part de l’historique devrions-nous transférer?

Transférez ce que les opérations consultent et ce que vous êtes tenus de conserver; archivez le reste en lecture seule. Le bon partage est une décision d’affaires et de conformité, prise par type de fiche, pas un réglage technique par défaut. Tout transférer ralentit le nouveau système et importe le vieux désordre; ne transférer que les dossiers ouverts détruit discrètement la piste de vérification.

Nos données sont en désordre. Faut-il les nettoyer avant ou pendant la migration?

Pendant, sous forme de règles de transformation explicites dans le script de migration — pas avant, à la main, dans l’ancien système. Le nettoyage scripté est répété, reproductible et documenté dans le registre des décisions; le nettoyage manuel préalable est un effort impossible à reproduire, qui se périme pendant que le projet avance, et personne ne peut dire ensuite exactement ce qui a été modifié.

Peut-on migrer sans interruption de service?

Presque, en procédant par étapes : l’historique est transféré à l’avance, les répétitions réduisent l’écart, et la bascule finale ne déplace que ce qui a changé depuis — habituellement une fenêtre de quelques heures, planifiée quand les opérations sont calmes. Une vraie synchronisation sans aucune interruption est réalisable, mais vaut rarement sa complexité en dehors des opérations qui fonctionnent jour et nuit.

Dernière révision le 28 août 2026