Qu'est-ce qu'une migration de données, et pourquoi échoue-t-elle ?
Une migration de données est le transfert organisé des informations d'un ancien système vers un nouveau, en trois temps : extraire, transformer, charger. La partie technique est rarement la plus difficile ; ce qui fait échouer une migration, c'est de la découvrir trop tard.
Les causes d'échec se ressemblent d'un projet à l'autre :
- la migration est planifiée comme une tâche de la dernière semaine, alors qu'elle conditionne la recette ;
- les données sont plus sales que prévu : doublons, champs détournés, formats incohérents ;
- personne côté métier n'est chargé de trancher (« quelle fiche garder ? ») ;
- aucun contrôle chiffré ne prouve que tout est arrivé, si bien que la confiance des utilisateurs s'effondre au premier écart.
La bonne pratique consiste à commencer la migration dès le cadrage, en parallèle de la construction du logiciel, et à tester le nouvel outil avec des données migrées plutôt qu'avec des données inventées.
Étape 1 : inventorier les sources de données
Avant d'écrire une ligne de code, listez tous les endroits où vivent les données, y compris ceux que personne n'ose avouer. L'inventaire révèle souvent un fichier Excel parallèle qui fait foi pour une équipe.
| Source | Ce qu'on y trouve | Piège typique |
|---|---|---|
| Classeurs Excel partagés | Clients, tarifs, plannings, suivis | Dates saisies en texte, cellules fusionnées, onglets « copie de » devenus la référence |
| Base Access ou FileMaker | Dossiers, historiques, états imprimés | Règles métier cachées dans des requêtes et des macros |
| Ancien ERP ou logiciel d'éditeur | Articles, commandes, factures, comptes | Exports incomplets, codes internes non documentés |
| Dossiers réseau et boîtes e-mail | Pièces jointes, contrats, photos | Fichiers sans lien fiable avec le bon client |
Pour chaque source, notez le volume, le propriétaire métier, la fréquence de mise à jour et la façon d'en extraire les données. Si l'ancien logiciel appartient à un éditeur ou à un prestataire, vérifiez dès maintenant ce que votre contrat prévoit pour l'export : c'est la question de la réversibilité. Le cas particulier des bases bureautiques est traité dans la page migrer une base Access ou FileMaker.
Étape 2 : nettoyer et dédoublonner
Nettoyer, c'est corriger ou écarter les données fausses avant de les transférer, parce qu'une donnée sale importée dans un outil neuf discrédite l'outil. Le nettoyage se fait par règles, appliquées automatiquement, et non à la main fiche par fiche.
- Normaliser : téléphones au même format, codes postaux sur cinq caractères (un tableur qui les traite comme des nombres transforme 01000 en 1000), majuscules et accents homogènes, pays écrits d'une seule façon.
- Dédoublonner : choisir une clé de rapprochement (SIRET, adresse e-mail, nom et code postal), lister les doublons probables, puis décider quelle fiche survit et ce qu'elle récupère des autres, comme l'historique de commandes.
- Écarter : fiches de test, clients fermés depuis longtemps, champs remplis de « à voir ».
Les cas ambigus ne relèvent pas du prestataire : « SARL Martin » à Mâcon et « Martin et fils » à la même adresse sont-ils le même client ? Seul quelqu'un du métier peut le dire. Prévoyez une liste d'arbitrages, traitée par une personne désignée, avec une date limite.
Étape 3 : faire correspondre les champs
La table de correspondance indique, pour chaque donnée de l'ancien système, où elle va dans le nouveau et quelle règle la transforme. C'est le document central de la migration, à faire valider par le métier.
| Ancien champ | Nouveau champ | Règle de transformation |
|---|---|---|
| Client.Tel (texte libre, parfois deux numéros) | contact.telephone et contact.telephone_2 | Séparer, normaliser au format international |
| Statut : « OK », « ok », « Oui », « actif » | client.actif (oui ou non) | Liste fermée de valeurs, le reste en anomalie |
| Commentaire contenant « relancer le 12/03 » | tâche de relance datée | Extraction quand le motif est reconnu, sinon note |
| Remise saisie en euros ou en pourcentage | remise.type et remise.valeur | Détection du symbole, contrôle des valeurs aberrantes |
La correspondance fait aussi apparaître ce qui ne sera pas repris : anciens champs inutilisés, historiques trop anciens, tables abandonnées. Ce qui n'est pas migré doit être décidé et écrit, pas oublié.
Étapes 4 et 5 : migrer à blanc et contrôler la cohérence
Une migration à blanc est une exécution complète de la migration sur une copie, sans toucher à la production, pour mesurer ce qui passe, ce qui casse et combien de temps cela prend. On en fait plusieurs, jusqu'à ce que le résultat soit stable.
Cela suppose un programme de migration rejouable de bout en bout, et non une suite de manipulations manuelles. Chaque exécution produit un rapport : lignes lues, lignes chargées, lignes rejetées avec leur motif. La durée mesurée sert à dimensionner la fenêtre de bascule.
| Contrôle | Exemple | Qui le valide |
|---|---|---|
| Comptages | Même nombre de clients actifs, de contrats, de factures par année | Le prestataire, rapport automatique |
| Totaux | Chiffre d'affaires facturé par année identique au centime | La comptabilité |
| Intégrité | Aucune intervention rattachée à un client inexistant | Le prestataire |
| Soldes | Encours clients et stocks identiques à la date de coupure | La comptabilité, la logistique |
| Échantillon | Vingt fiches choisies par les utilisateurs, comparées à l'écran | Les utilisateurs clés |
La CNIL recommande de développer et de tester sur des données fictives ou anonymisées ; lorsqu'un test exige des données réelles, elle admet un environnement de pré-production, à condition qu'il soit configuré et sécurisé au même niveau que la production. Les migrations à blanc sur de vraies données personnelles relèvent de ce cas. Ces contrôles font partie de la recette du logiciel.
Étape 6 : la bascule et la période de double run
La bascule est le moment où le nouveau logiciel devient la référence. Elle se prépare comme une opération : date choisie hors pic d'activité, gel des saisies dans l'ancien système, dernière migration, contrôles, décision explicite de mise en service, et plan de retour arrière si un contrôle échoue.
Le double run consiste à faire tourner l'ancien et le nouveau système en parallèle pendant quelques jours ou semaines. Il rassure, mais il a un coût : si les utilisateurs doivent tout saisir deux fois, ils décrochent vite. Deux variantes sont plus légères :
- Ancien système en lecture seule : on travaille dans le nouveau, on vérifie dans l'ancien.
- Synchronisation pendant la transition : les données sont recopiées automatiquement, et l'on bascule les équipes par groupes.
C'est cette seconde approche qu'a suivie YMHB Web pour Cap Vert Operations : passage de MongoDB à Supabase vérifié champ par champ, synchronisation pendant toute la transition, 10 000 enregistrements migrés sans perte, et bascule des équipes terrain en août 2026, au signal du client.
Après la bascule : archiver l'ancien système et respecter le RGPD
L'ancien système ne s'éteint pas le jour de la bascule : il doit rester consultable aussi longtemps que des obligations légales ou des litiges possibles l'exigent. Il doit aussi cesser de servir au quotidien.
Le RGPD fixe deux principes qui s'appliquent directement à une migration. Selon son article 5, les données doivent être limitées à ce qui est nécessaire au regard des finalités (minimisation) et conservées pendant une durée n'excédant pas celle nécessaire (limitation de la conservation). Reprendre tout l'historique « au cas où » va à l'encontre de ces deux règles.
La CNIL distingue la base active, l'archivage intermédiaire et l'archivage définitif. Elle cite des durées fixées par des textes (les données de facturation se conservent dix ans en application du Code de commerce, le double du bulletin de paie cinq ans selon le Code du travail) et donne en exemple les données d'un candidat non retenu, conservées deux ans au plus. Les données en archivage intermédiaire doivent être séparées de la base active, physiquement ou par des droits d'accès restreints.
- Exportez l'ancien système dans des formats ouverts et lisibles sans le logiciel d'origine.
- Limitez l'accès aux archives à quelques personnes habilitées.
- Fixez une date de suppression pour chaque catégorie, puis résiliez licences et hébergement de l'ancien outil.
Registre des traitements, contrat de sous-traitance, durées par type de données : ces points sont repris dans le guide RGPD et logiciel métier.
Les pièges courants d'une migration
- Découvrir les données à la fin : la qualité réelle des données se mesure au cadrage, sur un export complet.
- Migrer à la main : une manipulation non rejouable ne peut ni être vérifiée ni être refaite le jour J.
- Oublier les pièces jointes : photos, PDF et contrats doivent suivre leur fiche, avec des chemins de fichiers vérifiés.
- Ignorer les règles cachées : une remise calculée par une macro, une exclusion dans une requête. Comparez les résultats des deux systèmes sur les mêmes données.
- Laisser l'ancien système ouvert en écriture après la bascule : deux vérités apparaissent en quelques jours.
- Négliger les identifiants : numéros de clients, de factures et de contrats doivent être conservés, ou leur correspondance archivée, pour retrouver un document cité dans un vieux courrier.
Pour un logiciel ancien que l'on remplace par étapes plutôt qu'en une fois, voir aussi moderniser un logiciel ancien sans tout casser.
Questions fréquentes
- Combien de temps garder l'ancien logiciel après une migration ?
- L'ancien logiciel, ou plutôt ses données, doit rester consultable tant qu'une obligation légale ou un risque de litige le justifie. La CNIL rappelle par exemple que les données de facturation se conservent dix ans en application du Code de commerce. Il n'est pas nécessaire de garder le logiciel lui-même : un export complet dans des formats ouverts, accessible à quelques personnes habilitées, suffit souvent.
- Faut-il migrer tout l'historique dans le nouveau logiciel ?
- Non, il n'est généralement pas utile de migrer tout l'historique dans le nouveau logiciel. Le RGPD impose de limiter les données à ce qui est nécessaire. La pratique courante consiste à reprendre les clients actifs, les contrats en cours et quelques années d'historique utiles au quotidien, puis à archiver le reste dans un format lisible, séparé de la base active.
- Qu'est-ce qu'une migration à blanc ?
- Une migration à blanc est une exécution complète de la migration des données sur une copie, sans toucher au système en production. Elle permet de mesurer les rejets, de vérifier les comptages et les totaux, et de chronométrer l'opération. On en réalise plusieurs, en corrigeant les règles à chaque fois, jusqu'à obtenir un résultat stable avant la bascule réelle.
- Que faire si l'éditeur de l'ancien logiciel ne fournit pas d'export ?
- Si l'éditeur de l'ancien logiciel ne fournit pas d'export, commencez par relire le contrat : une clause de réversibilité peut l'obliger à restituer les données dans un format exploitable. À défaut, les données peuvent parfois être extraites de la base ou des états imprimables, à condition d'en avoir le droit. Un avocat peut aider à apprécier la situation contractuelle en cas de blocage.
- Qui doit valider une migration de données ?
- Une migration de données est validée par le métier, pas seulement par le prestataire technique. Le prestataire produit les rapports de comptage et d'intégrité ; la comptabilité valide les totaux et les soldes ; les utilisateurs clés contrôlent un échantillon de fiches. La décision de bascule revient au dirigeant ou au chef de projet interne, sur la base de ces contrôles.
À lire aussi
- Migrer une base Access ou FileMaker vers le web
- Remplacer Excel par un logiciel de gestion sur mesure
- Moderniser un logiciel ancien sans tout casser
- RGPD et logiciel métier : obligations concrètes
- Combien de temps conserver les données clients ?
- Cap Vert : logiciel métier et application terrain hors ligne