Pourquoi un plan de rollback est indispensable avant le cutover
Un plan de rollback n'est pas un accessoire facultatif, c'est le filet de sécurité qui autorise l'équipe à basculer en production avec confiance. Lorsqu'une migration critique révèle un incident sérieux dès les premières heures en live (corruption de données, service dégradé en-deçà des seuils acceptables, ou incompatibilité système non détectée en préproduction), la capacité à revenir rapidement à l'infrastructure source détermine si l'interruption dure vingt minutes ou plusieurs heures. Sans stratégie de rollback définie, testée et documentée, l'équipe fait face à un dilemme paralysant : persister dans un système défaillant ou improviser une restauration manuelle sous pression, ce qui allonge l'incident et augmente le risque d'erreurs humaines. Pour les migrations vers AWS impliquant des données sensibles ou des services critiques, un plan de rollback complet et répété réduit le stress psychologique du cutover lui-même, car chacun sait que le risque d'une décision est borné à un temps de retour prédéfini. C'est d'ailleurs pourquoi les meilleures pratiques du secteur exigent que le rollback soit testé au moins une fois en conditions réelles de préproduction avant le jour J.
Critères et conditions du déclenchement du rollback
Décider de lancer un rollback doit être un processus objectif, pas une réaction panique. Avant le cutover, l'équipe doit définir explicitement les conditions qui justifient un rollback immédiat, car ces conditions déterinent aussi la durée d'observation acceptable après bascule. Une condition typique est la perte de données : si les logs d'application ou de base de données révèlent une corruption au-delà d'un seuil acceptable (par exemple, plus de 1 % des écritures du cutover sont invalides), le rollback doit être lancé sans attendre. Une autre est la dégradation critique de performance : si le temps de réponse moyen des APIs de production dépasse 5 secondes pendant plus de 5 minutes consécutives, ce qui indique un problème d'architecture ou de ressource dans le nouvel environnement AWS, le rollback bascule immédiatement les utilisateurs vers l'ancien système. De même, si un service clé (authentification, paiement) devient inaccessible ou revient des erreurs 5xx en continu après 15 minutes, le retour à l'infrastructure source doit être lancé sans débat. Pour les migrations complexes, on peut aussi inclure des critères secondaires comme le nombre d'erreurs applicatives anormales (un pic d'erreurs non expliqué) ou une alerte monitoring qui déclenche un seuil prédéfini. L'essentiel est de documenter ces critères AVANT le cutover, idéalement dans le runbook opérationnel, avec des seuils mesurables et non subjectifs. Cela évite les décisions faites sous pression et garantit que toute l'équipe agit selon le même référentiel.
Stratégies techniques de rollback selon l'architecture
La technique de rollback varie fortement selon ce qui a été migré et comment. Pour une application stateless hébergée sur des instances EC2 derrière un load balancer, le rollback peut être aussi simple qu'une modification du groupe de sécurité ou du DNS, qui bascule le trafic instantanément vers les anciens serveurs restés actifs en parallèle. Si l'infrastructure source a été mise hors ligne après la bascule (approche zero-downtime sans doublure), un rollback exige de redémarrer et de vérifier les anciens serveurs, ce qui ajoute quelques minutes de travail manuel et requiert que personne n'ait shutdown ou supprimé les ressources. Pour les bases de données, le rollback est plus délicat : si seule la base AWS a reçu des écritures depuis le cutover, il faut soit restaurer la base source à partir d'une sauvegarde très récente (quelques secondes avant le cutover), soit maintenir une réplication bidirectionnelle pendant une fenêtre de rollback (souvent 2 à 4 heures après cutover). Une approche common est la réplication WAL (Write-Ahead Log) ou la réplication logique, qui enregistre chaque modification en temps quasi-réel et permet de rejeter les écritures post-cutover sur la base source sans perte. Pour les services sans état (files d'attente, caches), le rollback est généralement transparent : les requêtes enregistrées dans la queue AWS se retraiter sur l'ancienne infra sans problème, à condition que l'ancienne application reste en écoute. Les migrations hybrides (cloud AWS + on-premises) bénéficient souvent d'un rollback plus rapide, car les ressources on-premises peuvent rester chaudes et prêtes. L'essentiel est de choisir la stratégie cohérente avec le RTO (Recovery Time Objective) toléré : si l'organisation accepte 5 minutes d'indisponibilité, une restauration manuelle suffit ; si elle exige un basculement en moins de 30 secondes, une bascule DNS automatique ou load balancer est nécessaire.
Synchronisation bidirectionnelle et fenêtre de rollback limitée
Maintenir la capacité de rollback trop longtemps après le cutover devient techniquement complexe et coûteux. C'est pourquoi les meilleures pratiques définissent une fenêtre de rollback bornée, typiquement 2 à 4 heures après le passage live. Dans cette fenêtre, l'infrastructure source doit rester active et capable de recevoir du trafic, et les données doivent rester synchronisées de sorte qu'un retour n'entraîne pas de perte ou de duplication anormale. Pour les bases de données, cela signifie mettre en place une réplication bidirectionnelle (bi-directional replication) pendant ces heures critiques : chaque écriture sur la nouvelle base AWS est dupliquée en quasi-temps réel sur la base source, et inversement si un rollback survient. Des outils comme AWS DMS (Database Migration Service) avec l'option de réplication continue, ou des solutions tierces comme Debezium ou GoldenGate, permettent cette synchronisation. Au-delà de la fenêtre (après 4 heures par exemple), l'équipe décide généralement de fermer l'infrastructure source et d'arrêter la réplication, car prolonger au-delà devient un coût fixe non justifié et augmente le risque de divergence des données si personne ne surveil active la réplication. L'autre avantage de bornir la fenêtre est psychologique : elle pousse l'équipe à surveiller activement les premières heures post-cutover, ce qui est exactement quand les problèmes sont les plus susceptibles d'apparaître. Après la fermeture de la fenêtre, l'ancienne infra est gracieusement éteinte, les ressources AWS sont confirmées stables et la migration est considérée comme définitive.
Runbook et responsabilités pour exécuter le rollback
Un plan de rollback sans runbook exécutable est un plan sur papier. Le runbook doit être une séquence pas-à-pas, testée et approuvée, que n'importe quel ingénieur de l'équipe peut exécuter sous pression en 5 à 10 minutes maximum. Elle commence par la décision go/no-go : qui a le droit de déclarer un rollback nécessaire (il faut au moins deux décideurs pour éviter les faux positifs) et qui contacte qui (incident commander, ops lead, etc.). Ensuite vient le plan de communication : notifier les stakeholders, les utilisateurs (via statuspage), l'équipe produit, afin d'éviter que des décisions contradictoires soient prises pendant le rollback. La phase d'exécution technique est ensuite très précise : arrêter le traffic vers la nouvelle infra AWS (via DNS, load balancer ou groupe de sécurité), vérifier que l'ancienne infra est opérationnelle, basculer le traffic vers elle, vérifier la santé du service (quelques tests fonctionnels clés), et confirmer que les données critiques sont intègres. Chaque étape doit avoir un propriétaire assigné et un temps limite (par exemple : 60 secondes pour basculer le DNS, 2 minutes pour valider la santé du service), au-delà duquel on escalade plutôt que d'attendre. Ce découpage chronométré évite qu'un rollback censé durer 5 minutes ne s'étire en une demi-heure d'hésitation.
Tests du rollback en préproduction et itérations
Un rollback n'a de valeur réelle que s'il a été testé, au moins une fois, en conditions aussi réalistes que possible. Cela signifie simuler un cutover complet vers l'infra AWS en préproduction ou en staging, puis déclencher un rollback intentionnel et mesurer le temps réel d'exécution, les erreurs rencontrées, et les ajustements nécessaires. Le test doit inclure les données : charger une copie suffisamment grande de la base production (au moins quelques millions de lignes pour les tables critiques) pour que la réplication soit représentative, puis simuler des écritures post-cutover et vérifier que le rollback ramène les données à l'état exact du cutover sans corruption ni duplication. L'équipe notera aussi les pièges découverts : par exemple, un script de rollback qui suppose que les certificats SSL sont présents sur la vieille infra, mais qui ne sont pas, ou une synchronisation qui traîne parce qu'un index est manquant en production. Ces tests permettent aussi de valider les timings annoncés dans le runbook : si le test montre que le rollback DNS prend 15 minutes au lieu des 2 minutes promises, le runbook doit être révisé avant le jour J. Les itérations suite aux tests sont normales et attendues ; elles renforcent la confiance et évitent les mauvaises surprises. Enfin, réexécuter le test partiellement chaque trimestre ou avant un gros cutover renforce la muscle mémoire de l'équipe et détecte les déviations (par ex. : une dépendance a changé et le rollback n'en tient plus compte).