39. Les migrations : transformer l'état sans perdre le contrôle
Pourquoi ce chapitre existe
Une migration à grande échelle modifie plus que des données ou des serveurs. Elle affecte les utilisateurs, les équipes, les contrats, les opérations et la possibilité d'expliquer ce qui s'est passé. Son risque vient souvent de son caractère différé : une erreur peut rester cachée dans un lot ancien, une intégration peut continuer à utiliser l'ancien format, ou une exception manuelle peut ne jamais rejoindre le nouveau système.
Une migration responsable est un produit temporaire. Elle possède un objectif, des utilisateurs concernés, un plan d'expérience, des critères de réussite, une opération de réparation et une fin explicite.
Les idées essentielles
- Une migration doit distinguer préparation, transformation, validation, bascule et nettoyage.
- Les comptes, invariants, échantillons et exceptions sont des preuves de contenu, pas des tâches annexes.
- La communication et l'accompagnement sont des mécanismes de sécurité lorsque des utilisateurs ou équipes changent leurs habitudes.
- La capacité de reprendre, réconcilier ou compenser doit être conçue avant l'exécution à grande échelle.
Concevoir une migration comme une suite de contrôles
Avant le premier lot, définir qui est concerné, quelle source fait autorité, quels états sont attendus, quels écarts sont acceptables et quelle action est possible en cas d'anomalie. Exécuter ensuite par lots permet d'observer la durée, les erreurs et les cas non modélisés sans engager tout le patrimoine.
| Phase | Question de contrôle | Preuve ou action |
|---|---|---|
| Préparation | Les formes anciennes et nouvelles peuvent-elles coexister ? | Compatibilité, sauvegarde, accès, runbook |
| Transformation | Le lot a-t-il modifié les bons objets ? | Comptes, idempotence, journal d'exécution |
| Validation | Le sens et les invariants sont-ils préservés ? | Échantillons, rapprochement, contrôles métier |
| Bascule | Les lecteurs et utilisateurs utilisent-ils le nouveau chemin ? | Métriques d'usage, support, cohortes |
| Nettoyage | L'ancien état et les outils temporaires peuvent-ils disparaître ? | Adoption confirmée, archivage, retrait de compatibilité |
Traiter les exceptions comme un flux de travail
Une migration réelle rencontre des dossiers incomplets, des droits insuffisants, des données corrompues et des cas métier hors modèle. Les ignorer jusqu'à la fin crée une file invisible qui bloque la clôture. Chaque exception doit être classée : correction automatique, traitement manuel, décision métier, abandon justifié ou défaut du plan. Le volume et l'âge de cette file sont des indicateurs de qualité de migration.
Anti-patterns
Définir le succès par le nombre d'objets traités
Un compteur à 100 % peut inclure des transformations erronées et exclure des consommateurs toujours actifs sur l'ancien chemin. Le succès combine volume, invariants, adoption, capacité de support et retrait effectif de la double maintenance.
Effectuer une bascule irréversible sans exercice
Une procédure rarement exécutée contient souvent des droits manquants, durées irréalistes ou étapes ambiguës. Un pilote, une répétition sur environnement représentatif ou une restauration exercée révèle ces contraintes avant qu'elles ne touchent tout le périmètre.
Sous-estimer la migration des usages humains
Changer un outil, un export ou une règle de support sans accompagnement pousse les personnes à créer des contournements. Communication, documentation courte, période d'assistance et collecte de feedback font partie de la sécurité de transition.
Bonnes pratiques
Installer une gouvernance légère de migration
Une revue régulière des métriques, exceptions, risques, décisions et prochaines bascules maintient le contexte partagé. Elle ne doit pas devenir un comité qui réapprouve chaque lot ; elle doit pouvoir arrêter ou adapter la trajectoire lorsqu'un signal le justifie.
Préserver l'audit et la réparabilité
Conserver l'identité du lot, la version de l'outil, les entrées, résultats et décisions d'exception permet d'expliquer et de corriger une erreur. La rétention de ces traces doit respecter la confidentialité et l'obligation métier, mais ne peut être remplacée par la mémoire de l'équipe.
Checklist — Une migration est-elle prête à s'élargir ?
- L'objectif, le périmètre, les personnes concernées et la source de vérité sont-ils explicites ?
- Quels invariants, comptes et échantillons valident le contenu transformé ?
- Le lot est-il idempotent, journalisé et capable de reprise ?
- Comment les exceptions sont-elles qualifiées, résolues et suivies ?
- Quel signal confirme l'adoption avant de supprimer l'ancien chemin ?
- Quel plan de compensation, restauration ou communication s'applique si l'hypothèse est fausse ?
À retenir
Une migration réussie ne déplace pas seulement un état. Elle conserve la capacité de vérifier, d'expliquer et de réparer chaque étape, tout en accompagnant les usages qui donnent à cet état sa valeur réelle.