Une migration de données consiste à transférer les informations d’un ancien outil (ERP, CRM, base Access, tableurs) vers un nouveau, en les nettoyant et en les transformant, sans perte ni altération, puis à prouver que le résultat est correct. Pour ne rien perdre, elle suit six étapes : inventaire et périmètre, profilage et nettoyage, règles de correspondance, migrations à blanc répétées, contrôles de réconciliation chiffrés, puis bascule encadrée par une décision go/no-go et un plan de retour arrière. Le point clé : la qualité des données est l’affaire du métier, pas seulement de l’équipe technique.
La migration est souvent traitée comme une tâche de fin de projet, « on importera les données à la fin ». C’est l’une des principales causes de retard au démarrage d’une nouvelle application. Voici la méthode et la checklist que nous appliquons.
Pourquoi les migrations de données tournent-elles mal ?
Les problèmes rencontrés sont remarquablement constants d’un projet à l’autre :
- La qualité réelle des données est découverte trop tard : doublons, champs détournés de leur usage (« le fax sert à stocker le portable du gérant »), codes obsolètes, dates en texte libre.
- Les règles implicites ne sont écrites nulle part : un statut « 9 » qui signifie « client douteux » depuis quinze ans, connu de deux personnes.
- Personne n’est désigné pour arbitrer quel doublon conserver ou comment traiter une donnée incohérente.
- La migration n’est jamais répétée avant le jour J, et le premier essai complet a lieu pendant la bascule.
- Aucun contrôle chiffré ne permet de dire objectivement que tout est passé.
Chacun de ces risques se traite par une étape de la checklist.
Étape 1 : inventorier les sources et décider du périmètre
Commencez par dresser la carte des données : quels outils, quelles tables ou quels fichiers, quels volumes, qui les alimente et qui les utilise. On découvre presque toujours des sources oubliées : un tableur de suivi des garanties, une base de prix spéciaux, les pièces jointes stockées sur un serveur de fichiers.
Puis décidez, famille par famille, de ce qui sera repris. Toute donnée n’a pas vocation à rejoindre le nouvel outil.
| Famille de données | Option courante | Point d’attention |
|---|---|---|
| Référentiels (clients, fournisseurs, articles) | Reprise complète des éléments actifs, après nettoyage | Doublons, codes obsolètes, identifiants (SIREN, EAN) manquants |
| Documents ouverts (commandes, devis, factures non soldées) | Reprise intégrale | Cohérence des montants et des statuts |
| Historique récent | Reprise limitée à ce qui sert au quotidien | Utilité réelle à valider avec le métier |
| Historique ancien | Archive en lecture seule, consultable | Durées de conservation légales et RGPD |
| Pièces jointes | Reprise sélective ou lien vers l’archive | Volume, droits d’accès, formats |
| Paramétrage (taux, règles, tarifs) | Ressaisie contrôlée ou reprise | Souvent plus fiable de reconstruire que de migrer |
Le RGPD ajoute une contrainte utile : les données personnelles ne peuvent pas être conservées sans limite. La CNIL distingue la base active, l’archivage intermédiaire (données qui ne servent plus à l’objectif initial mais doivent être gardées, par exemple pour une obligation légale) et l’archivage définitif. Une migration est l’occasion idéale d’appliquer ces règles, plutôt que de transporter vingt ans de prospects inactifs dans un nouvel outil.
Données personnelles : les précautions pendant la migration
Une migration manipule souvent l’intégralité des données clients, salariés ou patients. Trois précautions :
- Minimiser : le principe de minimisation de l’article 5 du RGPD s’applique ; on ne reprend que ce qui est nécessaire.
- Protéger les environnements de test comme la production : accès limités, chiffrement, effacement des copies à la fin du projet.
- Anonymiser ou pseudonymiser quand des données réelles ne sont pas indispensables, en suivant les recommandations de la CNIL sur l’anonymisation.
Étape 2 : profiler et nettoyer les données
Le profilage consiste à analyser automatiquement les données existantes : taux de remplissage de chaque champ, valeurs distinctes, formats, doublons probables, incohérences entre tables. Il transforme une impression (« notre base est propre ») en constat chiffré.
Le nettoyage vient ensuite, et il ne peut pas être entièrement automatisé. Le guide d’implémentation de Microsoft Dynamics 365 le formule bien : les utilisateurs qui connaissent le mieux leurs données doivent être les garants de leur nettoyage. Un script détecte deux fiches « Dupont SA » et « DUPONT S.A. » ; seul le commercial sait laquelle porte le bon contact et les bonnes conditions.
Organisez le nettoyage dans l’ancien outil, avant la migration, et nommez un propriétaire par famille de données. C’est aussi le moment de poser les bases d’un référentiel unique, sujet que nous développons dans notre article sur les données de référence.
Étape 3 : écrire les règles de correspondance
La table de correspondance (mapping) décrit, champ par champ, d’où vient chaque donnée du nouvel outil et comment elle est transformée. Elle répond à des questions très concrètes :
- Le champ « Nom » de l’ancien outil devient-il « Raison sociale » ou « Nom commercial » ?
- Les quatorze statuts historiques se ramènent-ils aux cinq statuts du nouvel outil ? Selon quelle règle ?
- Que fait-on d’une valeur vide dans un champ désormais obligatoire : valeur par défaut, rejet, correction manuelle ?
- Comment conserver le lien avec l’ancien identifiant, pour pouvoir retrouver une pièce et contrôler ?
Cette table est validée par le métier, ligne par ligne, et versionnée : elle évolue à chaque migration à blanc. Conservez systématiquement l’identifiant d’origine dans le nouvel outil : c’est ce qui rend les contrôles et les corrections possibles.
Étape 4 : répéter avec des migrations à blanc
Une migration à blanc est une exécution complète de la migration dans un environnement de test, avec les données réelles. C’est la seule façon de découvrir les vrais problèmes, de mesurer la durée réelle et de fiabiliser les scripts.
Le guide de Microsoft sur la bascule recommande de répéter cette opération dans des conditions aussi proches que possible du jour J (mêmes données, mêmes outils, mêmes personnes, même enchaînement) et de recommencer jusqu’à ce que tout se déroule sans accroc. Chaque répétition produit une liste d’anomalies, corrigées avant la suivante.
Les migrations à blanc alimentent aussi la recette de l’application : tester les écrans avec des données réelles migrées révèle des problèmes invisibles avec des données fictives (libellés trop longs, volumes, caractères spéciaux).
Étape 5 : prouver que rien n’a été perdu
Une migration réussie se démontre avec des contrôles de réconciliation, définis à l’avance et signés par le métier.
| Type de contrôle | Exemple | Qui valide |
|---|---|---|
| Comptages | Nombre de clients actifs, d’articles, de commandes ouvertes : source = cible, écarts expliqués | Équipe projet |
| Totaux financiers | Encours clients, solde des factures ouvertes, valeur du stock : à l’euro près | Comptabilité, contrôle de gestion |
| Contrôles de rejet | Liste des enregistrements rejetés, avec motif et traitement | Propriétaire de la donnée |
| Échantillons | Quelques dizaines de fiches tirées au hasard comparées champ par champ | Utilisateurs métier |
| Cas sensibles | Les plus gros clients, les comptes à conditions particulières, les dossiers en litige | Responsables métier |
| Contrôles fonctionnels | Créer une commande sur un client migré, la facturer, l’expédier | Référents métier |
Un écart n’est pas forcément une erreur : des doublons fusionnés réduisent légitimement le nombre de clients. Mais chaque écart doit être expliqué et documenté. Un rapport de migration qui dit seulement « import terminé avec succès » ne prouve rien.
Étape 6 : préparer et réussir la bascule
La bascule (cutover) est le moment où l’on passe de l’ancien outil au nouveau. Microsoft rappelle qu’elle tient souvent sur un « week-end de bascule » de moins de 48 heures, pendant lequel aucun des deux outils n’est pleinement utilisable. Elle se prépare comme une opération :
- Un plan minuté : chaque tâche avec son ordre, son responsable, son suppléant, ses instructions et sa vérification.
- Un gel des saisies annoncé à l’avance dans l’ancien outil, puis son passage en lecture seule.
- Une reprise anticipée des données stables quelques jours avant, pour ne migrer le jour J que les données vivantes et les écarts.
- Des critères go/no-go écrits : seuils de rejets acceptables, contrôles de réconciliation passés, tests fonctionnels réussis.
- Un plan de retour arrière : jusqu’à quel moment peut-on revenir à l’ancien outil, et comment ?
- Une communication claire aux utilisateurs, aux clients et aux fournisseurs concernés.
Après la bascule, prévoyez une période d’accompagnement renforcé de quelques semaines, et gardez l’ancien outil accessible en lecture seule le temps de lever les derniers doutes. Si l’ancien outil doit encore échanger avec d’autres applications, comme lors d’une modernisation progressive, ces flux temporaires font partie du plan.
La checklist récapitulative
- Cartographie de toutes les sources, avec volumes et propriétaires
- Périmètre décidé par famille : reprise, archive ou abandon
- Durées de conservation vérifiées pour les données personnelles
- Profilage réalisé et anomalies chiffrées
- Nettoyage mené dans l’ancien outil par les propriétaires des données
- Table de correspondance validée par le métier et versionnée
- Identifiant d’origine conservé dans le nouvel outil
- Au moins une migration à blanc complète sans incident, chronométrée
- Contrôles de réconciliation définis, exécutés et signés
- Plan de bascule minuté, critères go/no-go et plan de retour arrière
- Ancien outil en lecture seule, puis archivé
Une migration de données est avant tout un projet d’intégration et de qualité des données. Qu’il s’agisse de quitter un outil maison, de passer d’un ERP à un autre ou de reprendre l’historique de Sage ou d’Odoo dans une application sur mesure, la méthode reste la même.
Vous préparez un changement d’outil et voulez évaluer l’ampleur de la reprise de données ? Décrivez votre situation dans notre diagnostic de projet : en deux minutes, vous obtenez une première analyse.
