Migration de données : les 10 erreurs qui coûtent cher

J'ai passé les dernières années à migrer des données dans des contextes enterprise : ERP, CLM (Contract Lifecycle Management), plateformes procurement, référentiels fournisseurs. Des projets avec des centaines de milliers d'enregistrements, des dizaines de systèmes sources, et des deadlines qui ne bougent pas.

Voici les erreurs que j'ai vues — et parfois commises. Certaines m'ont coûté des semaines. D'autres ont failli faire dérailler des go-lives. Toutes sont évitables.

1. Croire que les données sources sont propres

C'est l'erreur numéro un. Celle qui fait dérailler plus de projets que toutes les autres combinées.

Ce qu'on se dit : "Les données sont dans le système depuis 10 ans, elles doivent être fiables."

La réalité : 10 ans de saisies manuelles, de contournements, de "on verra plus tard", de migrations précédentes mal finies. Des doublons partout. Des champs obligatoires vides. Des formats incohérents. Des données orphelines dont plus personne ne connaît l'origine.

Ce que j'aurais dû faire : Profiler les données sources dès le début. Pas un audit rapide — une analyse systématique. Taux de remplissage par champ. Distribution des valeurs. Détection des doublons. Cohérence des relations. Avant même de parler de mapping.

💡 Règle : Prévoyez 30% du temps projet pour le nettoyage des données. Si on vous dit que ce n'est pas nécessaire, doublez ce pourcentage.

2. Impliquer les métiers trop tard

La migration de données est souvent vue comme un projet IT. C'est une erreur fondamentale.

Ce qui se passe : L'équipe technique définit les mappings, construit les scripts, fait des tests. Puis, deux semaines avant le go-live, on montre le résultat aux métiers. "Mais ce champ, on ne l'utilise plus depuis 2019." "Ces catégories ne correspondent pas à notre nouvelle organisation." "Il manque toute la donnée du site de Lyon."

Ce que j'aurais dû faire : Impliquer un référent métier par domaine de données dès le jour 1. Pas pour valider à la fin — pour co-construire. Ce sont eux qui savent quelles données ont de la valeur, lesquelles sont obsolètes, et comment elles doivent être transformées pour le nouveau système.

💡 Règle : Si le métier découvre des problèmes de données le jour de la recette, c'est que vous avez échoué trois mois plus tôt.

3. Faire un big bang

Tout migrer d'un coup, un week-end, et croiser les doigts.

L'attrait : C'est plus simple à planifier. Un seul cutover. Pas de période de double saisie.

Le piège : Si quelque chose se passe mal, tout se passe mal. Vous découvrez les problèmes en production, avec des utilisateurs qui attendent, et aucune marge de manœuvre.

Ce que je fais maintenant : Migration par vagues. D'abord les données de référence (référentiels, configurations). Puis les données maîtres (fournisseurs, clients, produits). Enfin les données transactionnelles (contrats, commandes, factures). Chaque vague est validée avant de passer à la suivante.

Oui, c'est plus long. Oui, ça demande plus de coordination. Mais quand la vague 2 révèle un problème de mapping, vous n'avez pas 500 utilisateurs bloqués.

4. Ignorer les dépendances entre données

Les données ne vivent pas en isolation. Un contrat référence un fournisseur. Un fournisseur a des contacts. Un contact a des rôles. Migrer dans le mauvais ordre, c'est garantir des erreurs d'intégrité.

L'erreur classique : Migrer les contrats avant les fournisseurs. Le système cible refuse les enregistrements car la clé étrangère n'existe pas. Ou pire : il les accepte avec une valeur par défaut, et vous perdez le lien.

Ce que je fais maintenant : Cartographier toutes les dépendances avant d'écrire une seule ligne de code. Construire un graphe de dépendances. Définir l'ordre de migration en fonction de ce graphe. Et tester cet ordre sur un échantillon avant de passer à l'échelle.

5. Pas de plan de rollback

"On n'en aura pas besoin."

C'est exactement ce qu'on dit avant d'en avoir désespérément besoin.

Ce qui se passe : La migration s'exécute. Des erreurs apparaissent. On corrige en live. D'autres erreurs. On patche. Le système cible est maintenant dans un état incohérent, mi-migré, mi-corrigé manuellement. Impossible de revenir en arrière. Impossible d'avancer proprement.

Ce que je fais maintenant : Chaque migration a un plan de rollback testé. Pas juste "on restaurera le backup" — un vrai plan qui dit exactement quoi faire, dans quel ordre, en combien de temps. Et on le teste. En conditions réelles.

⚠️ Règle : Un rollback non testé n'est pas un rollback. C'est un espoir.

6. Confondre migration et transformation

La migration, c'est déplacer des données d'un système à un autre. La transformation, c'est changer la structure, les règles métier, les processus.

L'erreur : Profiter de la migration pour "nettoyer" les données, "harmoniser" les référentiels, "simplifier" les catégories. Tout en même temps.

Pourquoi c'est dangereux : Vous ne savez plus si un problème vient de la migration technique ou de la transformation métier. Les tests deviennent impossibles à interpréter. Les métiers ne reconnaissent plus leurs données.

Ce que je fais maintenant : Séparer clairement les deux. D'abord migrer "as-is" (à l'identique). Valider que les données sont bien passées. Ensuite seulement, transformer. Ça permet de débugger chaque étape indépendamment.

7. Sous-estimer les délais (systématiquement)

Tout le monde le fait. Moi le premier.

L'estimation optimiste : "Le mapping est défini, il ne reste qu'à coder les scripts."

Ce qui se passe vraiment : Le mapping révèle des cas non prévus. Les données sources ont des exceptions. L'API du système cible a des limitations non documentées. Les tests trouvent des bugs. Les corrections créent des régressions. Les métiers changent d'avis sur un champ.

Ma règle maintenant : Prendre mon estimation initiale et la multiplier par 2,5. Ce n'est pas du pessimisme — c'est de l'expérience. Et si je finis en avance, tout le monde est content.

8. Tester avec des données "propres"

Créer un jeu de données de test parfait, bien formaté, sans cas limites. Les tests passent. La migration échoue en prod.

Pourquoi : Les vraies données sont sales. Elles ont des caractères spéciaux, des valeurs nulles là où on ne les attend pas, des longueurs qui dépassent les limites, des encodages bizarres, des dates au format américain mélangées avec des dates européennes.

Ce que je fais maintenant : Tester avec un extrait représentatif des vraies données. Pas 10 lignes choisies — 10 000 lignes échantillonnées aléatoirement. Avec tous leurs défauts.

Et inclure spécifiquement les cas limites connus : le fournisseur avec un nom de 500 caractères, le contrat sans date de fin, l'adresse avec des émojis (oui, ça arrive).

9. Oublier l'historique

Migrer l'état actuel des données, c'est bien. Mais quid de l'historique ?

Questions qu'on oublie de poser :

• Les anciennes versions des contrats, on les garde ?
• L'historique des modifications, il est migré ?
• Les pièces jointes archivées, elles vont où ?
• Les données supprimées (soft delete), on les reprend ?

Pourquoi c'est critique : Pour l'audit, la conformité, les litiges. Deux ans après la migration, quelqu'un aura besoin de prouver ce qu'un contrat disait en 2019. Si l'historique n'a pas été migré, bonne chance.

Ce que je fais maintenant : Poser explicitement la question de l'historique pour chaque type de donnée. Documenter la décision. Et si on décide de ne pas migrer l'historique, s'assurer que l'ancien système reste accessible en lecture.

10. Déclarer victoire trop tôt

"La migration est terminée, les données sont dans le nouveau système."

Non. La migration est terminée quand les utilisateurs travaillent normalement depuis trois mois sans découvrir de problème de données.

Ce qu'on oublie :

• Les processus de fin de mois qui n'ont pas encore tourné
• Les rapports annuels qui n'ont pas été générés
• Les cas d'usage rares mais critiques (clôture d'exercice, audit externe)
• Les intégrations avec d'autres systèmes qui n'ont pas encore été sollicitées

Ce que je fais maintenant : Définir une période d'hypercare post-migration. Minimum un mois, idéalement un trimestre. Avec une équipe dédiée qui surveille, qui répond aux tickets, qui documente les anomalies. La migration n'est officiellement terminée qu'à la fin de cette période.

La checklist que j'utilise maintenant

Après plusieurs projets, j'ai formalisé une checklist que je sors à chaque nouveau projet de migration :

Avant de commencer :

• Données sources profilées et documentées
• Référent métier identifié par domaine
• Dépendances entre entités cartographiées
• Ordre de migration défini
• Critères de succès définis et mesurables

Pendant le développement :

• Tests sur données réelles (pas de jeu de test idéalisé)
• Plan de rollback documenté et testé
• Validation métier à chaque étape
• Gestion explicite de l'historique

Avant le go-live :

• Dry-run complet en conditions réelles
• Temps de migration mesuré et compatible avec la fenêtre
• Communication utilisateurs préparée
• Équipe de support mobilisée

Après le go-live :

• Période d'hypercare planifiée
• Monitoring des anomalies en place
• Processus d'escalade défini
• Documentation à jour

Le vrai secret

Après tout ça, le vrai secret d'une migration réussie tient en une phrase : la migration de données est un projet métier, pas un projet technique.

Les scripts, les ETL, les APIs — c'est la partie facile. La partie difficile, c'est de comprendre ce que les données signifient, pourquoi elles sont dans cet état, et ce qu'elles doivent devenir.

Et ça, aucun outil ne le fera à votre place.

Vous avez vécu des migrations compliquées ?