Pourquoi la fenêtre de maintenance est la contrainte majeure du cutover
La fenêtre de maintenance est l'intervalle de temps pendant lequel votre infrastructure change d'état : les services s'arrêtent sur l'ancienne plateforme, les données se synchronisent, et vous basculez sur AWS. C'est le moment où les utilisateurs finaux perdent accès à l'application, et c'est aussi le moment où le risque de perte de données ou d'incohérence applicative est le plus élevé. Contrairement à ce que certaines équipes imaginent, la fenêtre n'est pas un simple redémarrage : c'est une cascade d'opérations interdépendantes où chaque minute compte parce qu'elle impacte directement votre SLA et la confiance de vos utilisateurs. Une fenêtre bien planifiée ne dure que quelques heures ; une fenêtre mal ordonnancée peut s'étirer sur une demi-journée ou plus, transformant une maintenance « standard » en incident critique. C'est pourquoi Stralya insiste pour que cette fenêtre soit décrite en détail dans le plan de cutover, avec des timings précis pour chaque étape et des seuils d'escalade définis à l'avance. Si vous attendez le jour J pour découvrir que la synchronisation des données prend deux fois plus longtemps que prévu, ou que l'équipe réseau n'a pas validé les routes DNS, vous serez en retard et votre fenêtre gonflera inexorablement.
Les activités critiques qui consomment la fenêtre
Pendant la fenêtre de maintenance, plusieurs activités doivent se dérouler en séquence ou en parallèle, et c'est la plus longue d'entre elles qui détermine la durée totale. Identifions les principales. La première est l'arrêt des services actifs sur l'infrastructure source : applications, workers en arrière-plan, caches distribués. Cette étape semble simple mais elle ne l'est pas si vous avez des services qui refusent de s'arrêter proprement (timeouts, reconnexions persistantes) ou des tâches asynchrones en vol qui doivent finir avant l'arrêt pour ne pas être perdues. Généralement, il faut prévoir 15 à 30 minutes ici, avec des vérifications que aucun job critique n'a été interrompu. La seconde est la synchronisation des données : il faut s'assurer que toutes les modifications en base de données depuis la dernière réplication planifiée sont copiées vers la cible AWS, et que les volumes de fichiers partagés ou les caches sont à jour. Si votre source de données a une charge importante jusqu'au dernier moment (ordres en cours, uploads d'utilisateurs), cette synchronisation peut se bloquer ou être imprécise. C'est pourquoi on la combine souvent avec un mode « en lecture seule » : on arrête les écritures avant d'arrêter les services, on sync, et seulement après on coupe. Cela peut ajouter 30 à 60 minutes selon le volume de données. La troisième activité est la basculement du trafic lui-même : DNS (changement des enregistrements pour pointer sur AWS), load balancer (si vous en utilisez un), routes réseau internes (si c'est une architecture hybride). Chacune de ces opérations doit être vérifiée pour s'assurer que le trafic arrive vraiment à la bonne destination. Comptez 15 à 45 minutes selon votre architecture. Enfin, la validation santé : une fois le trafic basculé, il faut tester rapidement que les applications répondent, que les connexions aux services tiers (APIs, bases de données, queues) fonctionnent, et que quelques scénarios métier critiques passent. C'est la phase la plus rapide si vous avez pré-écrit les tests (10 à 30 minutes), mais la plus longue si vous découvrez des problèmes inattendus (potentiellement plusieurs heures).
Réduire la fenêtre : stratégies et trade-offs
La tentation est grande de vouloir réduire la fenêtre au maximum, mais il y a des limites physiques et logiques qu'il faut respecter. Voici les vrais leviers. Le premier est de pré-synchroniser le maximum de données bien avant la fenêtre. Si vous avez une réplication continue depuis deux semaines, la delta sync (synchronisation des seules modifications récentes) sera très courte. C'est pourquoi Stralya recommande une phase de réplication long-term de 4 à 8 semaines avant cutover : la fenêtre devient plus courte parce que vous ne synchronisez que quelques gigaoctets d'écritures récentes, pas l'intégralité de votre base. Second levier : paralléliser ce qui peut l'être. Pendant que les données se synchronisent, vous pouvez en parallèle commencer à configurer les alertes de monitoring sur AWS, valider les routes DNS (pas d'application de la route, juste la vérification de sa syntaxe), ou préparer les rollback. Chaque minute économisée par parallélisation est une minute gagnée sur la fenêtre totale. Troisième levier : utiliser des outils de cutover « sans downtime » ou « minimal downtime ». Certaines solutions (par exemple Continuous Replication avec failover automatisé) permettent de basculer le trafic en quelques secondes une fois que la source et la cible sont synchronisées, au lieu d'attendre une validation manuelle. Cela ne supprime pas la fenêtre (il y a toujours un instant où les données doivent être figées pour la sync finale), mais la réduit drastiquement. Quatrième levier : automatiser les validations. Si vous avez un suite de tests Selenium ou API qui tournent automatiquement après le basculement, au lieu de tester manuellement chaque flux, vous gagnez 20 à 40 minutes. Le trade-off principal ici est le temps d'investissement : automatiser les tests prend 3 à 5 jours de dev, mais vous récupérez cette semaine par les fenêtres future plus courtes. Enfin, le dernier levier est la tolérance au risque : accepter un downtime légèrement plus court signifie accepter un risque légèrement plus élevé de découvrir un problème après basculement, ce qui allongerait le monitoring post-cutover ou nécessiterait un rollback. C'est un choix d'affaires : une banque ne fera jamais ce choix, une startup peut l'envisager. Stralya aide ses clients à définir ce seuil en fonction de leur contexte métier et technique.
Dépendances critiques qui peuvent allonger la fenêtre
Même la meilleure planification peut être dérangée par des dépendances cachées qui émergent pendant la fenêtre. La première, et souvent la plus sournoise, est la synchronisation de données incomplète ou lente. Imaginez que votre base de données source fait 500 Go, mais que le débit réseau entre votre datacenter et AWS n'est que de 100 Mbps (un lien standard non optimisé). La sync mathematique de 500 Go à 100 Mbps prend environ 11 heures. Si vous aviez prévu une fenêtre de 4 heures, vous avez un problème. C'est pourquoi Stralya recommande de prédire très tôt le débit réel et d'ajuster le timing ou l'infrastructure réseau (circuit privé, accélérateur de transfert) bien avant la fenêtre. Deuxième dépendance critique : les services tiers qui ne répondent pas pendant la fenêtre. Vous avez basculé le trafic vers AWS, mais votre API de paiement, votre fournisseur d'authentification externe ou votre CDN est en maintenance justement ce jour-là. Aucun test ne vous l'a révélé parce que vous aviez mocké ces services. Cela force l'équipe à soit attendre, soit rollback. C'est pourquoi il faut vérifier le statut de tous les services tiers critiques la veille de la fenêtre, et avoir un plan B si l'un d'eux est indisponible. Troisième dépendance : la propagation DNS. Changer un enregistrement DNS ne veut pas dire que tout le monde y accède instantanément. Le TTL (time-to-live) détermine combien de temps les clients vont garder l'ancienne adresse en cache. Si vous aviez un TTL de 3600 secondes (1 heure), et que vous changez l'IP à T+0, certains clients n'arriveront à la nouvelle adresse qu'à T+1 heure. Pour contourner ce problème, il faut baisser le TTL 24 ou 48 heures avant la fenêtre (par exemple le passer à 60 secondes), attendre que tout le monde l'ait adopté, puis faire le change pendant la fenêtre. Beaucoup d'équipes oublient cette étape et découvrent le problème live. Quatrième dépendance : les firewall rules et les sécurité groupe qui n'ont pas été synchronisées. Vous avez configuré les règles AWS correctement sur votre VPC, mais une règle d'un edge firewall d'entreprise bloque toujours l'ancienne IP source. Le trafic arrive sur AWS mais n'en ressort pas. Cela ajoute des heures de débogage. Stralya insiste pour que ces dépendances soient documentées dans le plan de cutover, avec des propriétaires clairement nommés et des timeouts définis : si la sync de données ne finit pas en 6 heures, on rollback automatiquement au lieu d'attendre indéfiniment.
Chronologie et checkpoints clés à valider avant et pendant la fenêtre
Une fenêtre bien exécutée suit une chronologie définie, avec des checkpoints clés à chaque étape. Idéalement, cette chronologie est décrite dans un document partagé (un runbook, ou une playbook) que toute l'équipe connaît et peut exécuter point par point. Voici une structure type. J-7 jours avant la fenêtre : vérifier que les pré-réquisits sont ok (capacité AWS provisionée et testée, réplication longue durée en cours depuis au moins 2 semaines, TTL DNS baissé depuis 48 heures). J-1 jour : test de cutover complet sur une copie (migration fictive du données de test pour valider tous les scripts, toutes les configurations). J-2 heures avant la fenêtre : notification officielle aux utilisateurs (message dans l'app, mail, page statut). T-60 minutes : communication interne finale à l'équipe IT, préparation des terminaux, vérification que personne ne fait d'update système ou de redémarrage qui pourrait gêner. T-0 (fenêtre ouverte) : arrêt des services source, début de la sync. À ce moment, vous lancez aussi un monitoring continu : logs, métriques CPU/mémoire, connexions réseau. Un responsable unique doit piloter et annoncer chaque étape. T+30 min environ : fin de la sync de données, basculement DNS, basculement des load balancers. T+60 min : validation santé complète (tests auto, tests manuels spot). T+90 min : monitoring stable, réduction du personnel en garde. T+120 min ou plus : escalade si un problème non prévu émerge (rollback ou résolution technique). Après la fenêtre, le suivi continue : monitoring 24h sur 24, escalade rapide si une anomalie est détectée. Chaque checkpoint doit avoir un propriétaire (« c'est Marylène qui valide la sync de données », « c'est Jérôme qui bascule le DNS »). Si un checkpoint échoue ou dure trop longtemps, la procédure d'escalade déclenche soit un rollback soit une extension de fenêtre (mais pas d'attente indéfinie). Cela semble académique, mais c'est la différence entre une fenêtre de 2 heures et une fenêtre d'une demi-journée : c'est l'absence de ownership clair et de trigger d'escalade qui fait trainer.
Rollback et plans de secours : gérer l'imprévu
Même avec une excellente planification, quelque chose peut toujours s'écarter du plan. C'est pourquoi toute fenêtre de maintenance doit avoir un plan de rollback documenté et testé. Le rollback est l'opération inverse : vous basculez le trafic vers l'ancienne infrastructure et vous re-synchronisez les données qui auraient pu être écrites sur AWS entre-temps. La question critique est : en combien de temps pouvez-vous rollback ? Si la réponse est « 10 minutes », vous pouvez être plus agressif dans votre fenêtre. Si c'est « 2 heures », vous devez être plus conservateur. Stralya recommande que le rollback soit toujours plus rapide que l'exécution forward, ce qui signifie que vous devez conserver l'ancienne infrastructure opérationnelle pendant 24 à 48 heures après cutover réussi, le temps que tout le monde sache que la migration est stable. C'est un coût, mais c'est le coût de la sécurité. Deuxième point : quand déclenchez-vous le rollback ? C'est une décision stressante en live, et elle doit être pré-définie. Par exemple, « si la validation santé révèle plus de 5 % d'erreurs après 30 min de basculement, rollback automatique ». Ou « si la sync de données n'est pas terminée après 6 heures, rollback et reprogrammation ». Ces seuils doivent être convenus d'avance, pas débattus live. Troisième point : les données écrites après basculement. Si vous avez roulé back après 2 heures sur AWS, et que vous voulez relancer une migration corrigée, que se passe-t-il avec les données que les utilisateurs ont écrites pendant ces 2 heures ? En général, elles sont perdues et vous devez en avertir les utilisateurs. C'est un risque reputationnel majeur qui pousse les équipes à être très prudentes avec les seuils de rollback. Enfin, un plan de secours ne se teste pas en live. Au minimum une semaine avant la fenêtre, vous devez simuler un rollback (sur environnement de test ou sur une réplication test de données réelles) pour s'assurer que vos scripts fonctionnent, que les équipes les connaissent, et que le timing est réaliste. Trop d'équipes découvrent pendant la fenêtre que leur script de rollback est cassé ou que personne n'a les mots de passe des anciens serveurs. C'est inacceptable et c'est une source majeure de fenêtres qui s'allongent. Stralya insiste pour que le rollback soit une partie intégrante du plan de cutover, pas une pensée secondaire.