Un lecteur m'a écrit la semaine dernière : « J'ai cliqué sur "migrer", l'écran est resté figé quarante minutes, et quand j'ai rouvert, il manquait les deux tiers de mon historique. » Il migrait sa messagerie. Il avait lu trois articles qui lui expliquaient que la migration de données consistait à « transférer des informations d'un système à un autre ». Techniquement vrai. Inutile au possible.
Parce que le problème n'est jamais le transfert. Le problème, c'est tout ce qui l'entoure : ce qu'on oublie de compter, ce qu'on croit avoir sauvegardé, et le moment exact où l'on appuie sur le bouton. Après six migrations menées sur des périmètres très différents — un intranet d'entreprise, une base SQL de 400 Go, un simple changement de PC familial — j'ai fini par comprendre que la partie visible ne représente qu'un quart du travail.
Points clés à retenir
- Une migration réussie se joue à 70 % avant la bascule : inventaire, cartographie, nettoyage.
- Le passage à blanc (une répétition générale sur copie) est l'étape que tout le monde saute. C'est celle qui sauve.
- Ne migrez jamais un vendredi. Jamais.
- Comptez toujours une période de double fonctionnement après la bascule : l'ancien système reste accessible, en lecture seule.
- La validation post-migration se fait sur des critères définis avant, pas sur une impression générale.
- Le plus gros risque n'est pas technique : c'est ce que personne n'a documenté parce que « tout le monde sait comment ça marche ».
Migrer ses données vers un nouveau système : ce qui se joue vraiment
La définition classique — déplacer des données d'un environnement vers un autre — décrit le voyage, pas le danger. Ce qui casse une migration, ce sont les dépendances invisibles : une macro Excel qui pointe vers un chemin réseau, un champ « date de naissance » stocké en texte libre, un dossier partagé que trois personnes utilisent sans que ce soit écrit nulle part.
J'ai découvert ça à mes dépens sur ma deuxième migration. L'inventaire annonçait 12 000 fichiers. Après transfert, il en manquait 340. Pas perdus : jamais comptés, parce qu'ils vivaient dans une arborescence que le logiciel de scan avait ignorée. On a passé deux jours à les retrouver à la main.
L'audit et l'inventaire : la moitié du travail, et personne ne veut la faire
Avant de toucher à quoi que ce soit, listez. Volume total, types de fichiers, formats, dates de dernière modification, propriétaires. Sur une migration récente, cette étape a révélé que 38 % des données n'avaient pas été ouvertes depuis plus de trois ans. On ne les a pas migrées. On les a archivées à part, sur un disque séparé, avec un index. Résultat : le volume à transférer a fondu de près d'un tiers, et la durée de bascule est passée de quatorze heures à cinq.
Ce tri n'est pas de l'optimisation, c'est de la survie. Plus vous déplacez de déchets, plus vous multipliez les occasions qu'un déchet casse quelque chose.
- Ce que vous comptez vraiment : le nombre d'objets (pas le poids), le nombre de dépendances entre eux, le nombre de personnes qui y accèdent.
- Combien de formats différents cohabitent ? Si vous en avez plus de cinq, prévoyez une phase de conversion.
- Qui est propriétaire de quoi ? Une donnée sans propriétaire identifié ne sera jamais validée par personne.
Cartographie et nettoyage : mapper avant de déplacer
Cartographier, c'est dessiner les liens. Quel fichier alimente quel autre. Quelle base est lue par quelle application. Cette carte devient votre plan de bascule : elle vous dit dans quel ordre migrer, parce que certaines briques doivent arriver avant d'autres.
Le nettoyage vient après, jamais avant le mapping. Sinon vous nettoyez des doublons que vous allez recréer en recopiant une arborescence mal comprise. Sur la base de 400 Go, cette inversion d'ordre m'a coûté une semaine entière. Franchement, je m'en veux encore.
Les méthodes de transfert : ce que chacune supporte réellement
Aucune méthode n'est bonne dans l'absolu. Tout dépend du volume, de la distance, et de votre tolérance à l'interruption de service. Voici ce que j'ai réellement utilisé, avec les chiffres observés.
| Méthode | Volume pratique | Vitesse observée | Quand la choisir |
|---|---|---|---|
| Disque externe | Jusqu'à quelques To | 80–120 Mo/s en USB 3 | Migration physique, hors ligne, sans réseau fiable |
| Réseau local (LAN) | Illimité en théorie | Dépend du réseau, souvent 200 Mo/s à 1 Gb/s | Serveur à serveur dans le même bâtiment |
| Outil natif de l'OS | Petits volumes | Variable, peu prévisible | Passage d'un poste à un autre, données personnelles |
| Outil ETL spécialisé | Bases structurées | Dépend de la transformation | Quand les schémas source et cible diffèrent |
| À blanc intégral | — | Coût doublé | Toujours, avant la vraie bascule |
Pour les bases de données, un outil ETL (Talend, par exemple, ou son équivalent open source) devient nécessaire dès que le schéma cible ne colle pas exactement au schéma source. Sur une migration où une colonne « client » éclatait en trois tables, l'écrire à la main aurait pris des jours. L'outil l'a fait en une nuit, mais il a fallu une semaine pour paramétrer les règles correctement.
La migration à blanc : le test que tout le monde saute
Une migration à blanc, c'est la répétition générale. Vous exécutez tout le processus sur une copie, sans toucher à la production. Vous chronométrez, vous notez ce qui casse, vous recommencez.
Sur ma dernière grosse bascule, on a fait trois passages à blanc. Le premier a planté à 40 % (encodage de caractères mal géré). Le deuxième a tourné mais a mis onze heures au lieu des cinq prévues. Le troisième s'est déroulé en quatre heures quarante, sans incident.
Spoiler : sans ces trois répétitions, la vraie migration aurait échoué publiquement, en pleine journée de travail.
Un plan de migration, concrètement, ça ressemble à quoi ?
On me demande souvent un exemple de plan. Le voici, dans l'ordre où je le tiens aujourd'hui :
- Inventaire et classification des données (avec archivage séparé de ce qu'on ne migre pas).
- Cartographie des dépendances entre fichiers, bases et applications.
- Nettoyage et normalisation des formats.
- Choix de la méthode de transfert, testée sur un échantillon.
- Passage à blanc complet, chronométré, sur copie.
- Fenêtre de bascule annoncée, avec gel des modifications.
- Bascule réelle, puis double fonctionnement pendant deux à quatre semaines.
- Validation sur critères définis avant l'opération, puis décommissionnement de l'ancien système.
L'étape 8 est celle qu'on oublie le plus. Garder l'ancien système en lecture seule quelques semaines, c'est votre filet de sécurité. Ça ne coûte presque rien et ça évite les regrets.
Ce qui rate toujours un peu, même bien préparé
Quelque chose échoue. Systématiquement. La question n'est pas « est-ce que ça va casser ? » mais « qu'est-ce qui va casser, et est-ce que je saurai le détecter ? ».
Sur les migrations que j'ai menées, les ratés les plus fréquents n'étaient jamais techniques. Ils étaient humains : une personne qui avait renommé ses dossiers la veille, un mot de passe oublié pour un service tiers, une règle métier que quelqu'un appliquait « de tête » depuis cinq ans et que personne n'avait documentée.
D'où ma conviction : la migration informatique n'est pas un projet d'infrastructure. C'est un projet de documentation. Vous déplacez des données, mais ce qui décide du succès, c'est la qualité de ce que vous savez d'elles.
Un dernier conseil, que je répète à chaque fois : définissez vos critères de réussite avant de commencer. Pas « ça a l'air bon », mais « les 12 000 fiches clients sont présentes, les 340 fichiers retrouvés, la recherche renvoie les mêmes résultats sur un échantillon de 50 requêtes ». Le jour où vous vous demandez si la migration est réussie, il est déjà trop tard pour poser la question.
Et si vous devez migrer vers un nouveau système ce trimestre, commencez par l'inventaire. Aujourd'hui. Le reste suivra beaucoup plus facilement que vous ne le pensez.
