Définir les objectifs et périmètre du plan de cutover
Avant toute action, un plan de cutover doit expliciter clairement ce qui bascule, ce qui reste, et surtout pourquoi. Cela signifie identifier précisément les systèmes, données et services concernés par la bascule en production. Par exemple, une migration d'infrastructure AWS ne traite pas de la même manière un monolithe applicatif et un écosystème microservices distribué. Le plan doit aussi définir les objectifs mesurables du cutover : durée d'indisponibilité acceptable (RTO), volume de données à synchroniser, nombre d'utilisateurs impactés et chronologie précise. Trop souvent, les équipes commencent la bascule sans avoir convenu ensemble du périmètre exact, ce qui génère des malentendus critiques en plein cutover. En fixant le périmètre en amont, vous divisez le problème global en tranches gérables et vous créez un référent commun : chaque acteur sait ce qui est in scope et ce qui ne l'est pas. Cela réduit drastiquement les décisions de dernière minute et les dérives de périmètre qui paralysent une bascule en direct. Le document de périmètre doit aussi lister les dépendances externes (API tiers, services partenaires, bases de données distribuées) pour que le plan tienne compte de leurs contraintes propres.
Détailler les étapes séquentielles et leurs conditions de succès
Un bon plan de cutover fonctionne comme une recette précise : chaque étape suit un ordre logique, avec des conditions d'entrée et de sortie explicites. Typiquement, vous avez une phase de préparation (synchronisation finale des données, vérifications critiques), une phase de bascule (point de non-retour où le trafic basculé vers AWS), et une phase de validation (tout fonctionne-t-il sur la nouvelle infrastructure ?). Entre chaque étape, le plan doit énumérer les contrôles ou vérifications qui doivent passer avant de passer à la suivante. Par exemple, avant la bascule du trafic, le plan doit vérifier que les tests de charge en staging ont réussi, que la synchronisation des données est à jour et que les équipes de support sont prêtes. Documenter ces conditions prévient les raccourcis dangereux ; le jour du cutover, sous pression temporelle, il est tentant de sauter des étapes si elles ne sont pas explicitement écrites. Le plan doit aussi intégrer des étapes de rollback à chaque point critique : si la validation en phase X échoue, comment revient-on en arrière sans perte de données ? Ces retours en arrière doivent aussi être documentés et testés une ou deux fois avant le jour J pour que ce ne soit pas une improvisation le jour du cutover réel.
Assigner les rôles et responsabilités de chaque acteur
Un cutover implique des dizaines de personnes : ingénieurs infrastructure, développeurs, responsables bases de données, équipes réseau, support client, chefs de projet. Sans une clarté absolue sur qui fait quoi, vous vous retrouvez avec du chaos, des doublons ou des tâches oubliées au moment critique. Le plan doit nommer les responsabilités de manière RACI : qui est Responsible (exécute), Accountable (rend des comptes), Consulted (est informé avant la décision), Informed (reçoit des infos après). Par exemple, le lead infrastructure est Responsible de la basculade réseau, le DBA est Responsible de la synchronisation finale des données, l'équipe support est Responsible des vérifications utilisateur en post-cutover, et le CTO ou DSI est Accountable de tout. Chaque acteur doit aussi avoir un contact direct assigné pour des décisions rapides en cas de dérive (délai qui s'allonge, erreur inattendue). Trop de cutover échouent parce que les gens attendent des autorisations d'une hiérarchie absent ou parce que le responsable clé est en réunion quand il faudrait trancher vite. Le plan doit inclure les contacts, numéros directs et canaux de communication privilégiés (Slack room dédiée au cutover, par exemple) pour qu'aucune question ne reste en suspens plus de 10 minutes.
Documenter les scénarios de rollback et leur seuil de déclenchement
Tout plan doit répondre à la question redoutée : « Et si ça ne marche pas ? » Documenter le rollback ne signifie pas lister vaguement « on revient à l'ancienne infra » ; cela signifie décrire précisément comment retrouver un état stable en moins de 30 ou 60 minutes. Pour chaque étape du cutover, vous devez définir un seuil d'abandon : par exemple, si après 15 minutes la base de données n'a pas fini de synchroniser, ou si les erreurs applicatives dépassent 5 % du trafic, vous déclenchez le rollback. Ces seuils doivent être convenus à l'avance, de préférence quantifiés, et notifiés à tous les acteurs avant le cutover. Sinon, le jour J, vous aurez une discussion stérile entre un responsable qui veut attendre, un autre qui veut revenir en arrière et un troisième qui ne sait pas quels chiffres regarder. Le plan doit aussi clarifier comment revenir à l'ancienne infrastructure : basculer les DNS, fermer les connexions en cours, restaurer les données depuis une sauvegarde datant de quelle heure exactement, redémarrer les services critiques dans quel ordre. Cette séquence de rollback doit être testée en entier une ou deux fois sur un clône de votre environnement de production pour que ce ne soit pas la première fois le jour du cutover réel. Enfin, le plan doit stipuler qui peut décider du rollback : généralement le CTO ou le responsable du projet en accord avec le responsable métier, avec un escalade très rapide pour ne pas laisser l'incertitude planer plus de quelques minutes.
Créer un checklist d'exécution minute-par-minute pour le jour J
Le plan global est une chose ; le jour du cutover, vous avez besoin d'une checklist d'exécution très granulaire, minute par minute ou heure par heure selon la complexité. Cette checklist énumère chaque action concise (par exemple, « 14h30 : vérifier que la réplication de DB est stable depuis 10 minutes », « 14h45 : basculer le DNS en production », « 15h00 : lancer les tests de fumée sur le site principal »), avec qui l'exécute et où elle l'enregistre. Cette checklist doit être imprimée ou partagée en temps réel dans un document accessible à tous les participants, afin que chacun sache où vous en êtes. Beaucoup d'équipes partent avec un plan bien structuré mais sans cette concrétisation minute-par-minute, et elles finissent à regarder leur montre sans savoir quoi faire exactement. La checklist doit aussi intégrer les étapes de communication vers le service client ou les utilisateurs : « 14h00 : envoyer un message de statut indiquant que la migration est en cours » et « 15h30 : confirmer aux clients que le service est stable ». Enfin, cette checklist doit être revue lors d'une réunion de « dress rehearsal » (répétition générale) une ou deux jours avant le cutover réel, où tous les acteurs passent en revue chaque étape exactement comme ils vont l'exécuter, pour repérer les oublis, les ambiguïtés ou les dépendances oubliées.
Valider et tester le plan en condition quasi-réelle
Un plan reste une abstraction jusqu'à ce qu'il soit testé. Avant de l'exécuter en production, vous devez le valider au moins une fois en environnement de staging ou de pré-production, en reproduisant autant que possible les conditions réelles : même volume de données, même charge réseau, même nombre d'acteurs et même chronologie. Ce test de validation remplit plusieurs rôles. D'abord, il repère les étapes oubliées ou les dépendances sous-estimées : par exemple, vous découvrez que la synchronisation des données prend deux heures alors que le plan en prévoyait une. Ensuite, il familiarise chaque acteur avec son rôle : un développeur qui n'a jamais fait de cutover sait désormais ce qu'il doit vraiment faire et en combien de temps. Enfin, il teste concrètement les procédures de rollback pour confirmer qu'elles fonctionnent vraiment ; sinon, vous découvrez un problème en production au lieu de l'environnement de test. Le test lui-même doit être documenté : notons les durées réelles de chaque étape, les obstacles rencontrés, les ajustements apportés au plan. Un jour avant le cutover réel, vous organisez une réunion de révision finale où vous discutez des apprentissages du test et vous finalisez le plan avec les chiffres réels et les leçons apprises. C'est aussi le moment de faire une dernière vérification que tous les outils et accès de chacun fonctionnent (connectivité AWS, permissions de modification sur les DNS, accès aux bases de données, etc.). Beaucoup de cutover commencent avec un quart d'heure de retard simple parce qu'un acteur découvre qu'il n'a pas les bons accès.
Intégrer le suivi en temps réel et la communication continue
Pendant le cutover lui-même, le plan ne suffit plus ; vous devez aussi orchestrer comment l'équipe suit et communique sur sa progression. Cela signifie mettre en place un dashboard ou un registre de statut partagé en temps réel où on note chaque étape terminée, chaque problème détecté et chaque ajustement décidé. Un exemple simple : une feuille de calcul ouverte sur un écran partagé, ou une application de suivi de tâches en direct. Chaque acteur note ce qu'il fait quand il le fait, et la personne coordonnant le cutover s'assure que personne n'attend et que les étapes ne s'entrelacent pas inopinément. Parallèlement, la communication doit être structurée : une personne dédiée informe les autres équipes (support client, métier) tous les quarts d'heure ou demi-heure sur l'état d'avancement. Cela prévient les questions paralysantes qui interrompent les responsables critiques. Et à la fin du cutover, vous exécutez une réunion de clôture brève pour confirmer que tout est stable avant de laisser les gens se reposer : « Tous les tests passent ? Aucun problème remonté par les utilisateurs ? Oui ? Excellent, fin du cutover confirmée, on se reparle demain pour le post-mortem. »