Contexte
Une application qui a vécu accumule un patrimoine de données que son schéma d'origine ne sait plus porter : colonnes détournées de leur usage, valeurs libres là où il faudrait des références, doublons apparus au fil des imports. Refondre l'application impose de reprendre ces données, et c'est presque toujours la partie la plus risquée du projet.
Le problème
Le risque n'est pas technique au sens strict, il est opérationnel.
- Une migration qui échoue à mi-parcours laisse un système dans un état incohérent
- Les données existantes contiennent des cas que personne n'avait documentés
- L'activité ne peut pas s'arrêter le temps de la reprise
- Sans contrôle de réconciliation, personne ne peut affirmer que rien n'a été perdu
La solution
Une migration traitée comme un logiciel : versionnée, testée, rejouable autant de fois que nécessaire.
- Cartographie de l'existant, y compris les cas non documentés découverts en route
- Nettoyage et normalisation avant transformation, pas pendant
- Scripts de migration rejouables, produisant le même résultat à chaque exécution
- Réconciliation systématique : comptages, totaux et contrôles d'intégrité entre source et cible
- Répétitions complètes sur copie avant toute exécution réelle
- Procédure de retour arrière définie et testée avant la bascule
Mon rôle
Analyse du schéma existant, conception du schéma cible, écriture des scripts et des contrôles, exécution des répétitions et pilotage de la bascule. J'ai également mis en place l'automatisation qui permet de rejouer l'ensemble sur un environnement neuf.
Contraintes
- Aucune interruption de service acceptable pendant la reprise
- Intégrité vérifiable, et non simplement supposée
- Scripts rejouables : une exécution partielle ne doit jamais laisser d'état intermédiaire
- Retour arrière possible jusqu'au dernier moment
- Volume de données imposant de traiter par lots plutôt qu'en une passe
Résultat
La bascule s'est faite sans coupure, et les contrôles de réconciliation permettent d'affirmer, chiffres à l'appui, que rien n'a été perdu.
- Les scripts sont rejouables, donc réutilisables pour les environnements de test
- Les écarts découverts dans les données historiques ont été traités explicitement, pas silencieusement
- Le nouveau schéma porte les règles que l'ancien laissait à la charge de l'application
Les résultats sont décrits par la capacité livrée. Aucune mesure de performance commerciale n'est avancée ici : les chiffres d'usage appartiennent au client, et je ne publie pas de métriques que je ne peux pas justifier.