Migration Cloud : préparer la bascule
Une infrastructure déployée ne constitue pas encore un service prêt à fonctionner. Les critères de passage doivent être construits avec ceux qui exploitent.
Publié le · À propos des dates
Mis à jour le
Le point de vue Spark
Une bascule réussie ne se résume pas à un environnement qui répond. Elle doit permettre aux utilisateurs de reprendre leur activité, aux équipes de traiter un incident et aux décideurs de savoir quand poursuivre ou revenir en arrière.
- Définir le service à reprendre et ses dépendances.
- Répéter les étapes sensibles avec des responsables identifiés.
- Décider du retour arrière avant l’arrivée de nouvelles transactions.
1. Définir ce qui doit fonctionner au premier matin
Un serveur disponible ne prouve pas qu’une commande peut être traitée. Une connexion réussie ne prouve pas qu’un utilisateur dispose des bons droits. La préparation commence donc par quelques parcours représentatifs : se connecter, réaliser une opération, échanger avec un système tiers et retrouver le résultat attendu.
Pour chaque parcours, nommez la personne qui le valide et les conditions nécessaires à son exécution. Les accès, les données, les interfaces et les horaires des traitements comptent autant que les composants techniques. Un traitement de nuit oublié peut révéler le défaut après le départ de l’équipe de bascule.
Le périmètre doit aussi préciser ce qui peut attendre. Une fonctionnalité secondaire indisponible n’appelle pas nécessairement la même décision qu’une impossibilité de traiter les opérations essentielles. Cette distinction doit être discutée avec les responsables de l’activité avant la fenêtre de migration.
2. Construire un déroulé qui permet de décider
AWS recommande un plan de bascule décrivant les activités, leur séquence, leurs durées et leurs responsables, ainsi qu’une procédure de retour arrière et des répétitions. C’est un cadre de préparation, à adapter au service concerné. Voir les recommandations AWS sur la préparation.
Notre proposition est d’ajouter une preuve attendue à chaque étape sensible. « Vérifier l’interface » est trop vague pour suivre une exécution sous contrainte de temps. « Confirmer la réception et le traitement de la transaction de contrôle » permet de savoir ce que l’équipe attend.
| Champ | Question à résoudre |
|---|---|
| Prérequis | Qu’est-ce qui doit être validé avant de commencer ? |
| Responsable et relais | Qui réalise et qui intervient en cas d’absence ? |
| Durée et limite | Quand faut-il alerter plutôt que continuer ? |
| Preuve | Quel résultat observable clôt l’étape ? |
| Décision | Qui autorise la suite, la correction ou l’arrêt ? |
La répétition sert à éprouver ces réponses. Une étape réalisée par une personne qui connaît tous les détails peut masquer un manque de documentation. Le passage de relais à un autre intervenant est un test utile de la clarté du déroulé.
3. Exemple : l’application fonctionne, mais les échanges attendent
Le même raisonnement s’applique aux dépendances moins visibles : résolution de noms, certificats, droits, planification des traitements et supervision. Chacune doit être reliée à un usage ou à une condition d’exploitation.
4. Traiter le retour arrière comme une opération sur les données
AWS distingue le retour avant modification des données et celui qui intervient après de nouvelles transactions. Dans le second cas, réactiver l’ancien environnement peut laisser de côté les opérations réalisées depuis la bascule. Voir les considérations AWS sur le retour arrière.
Notre recommandation est de nommer le moment où le retour devient plus complexe et d’expliciter ce qu’il implique : arrêt des écritures, rapprochement des opérations, reprise des échanges et vérification de la cohérence. Une sauvegarde disponible ne constitue pas à elle seule un plan de reprise du service.
La personne autorisée à décider doit disposer d’une estimation du temps nécessaire et des conséquences métier. Il faut aussi préserver une marge pour exécuter la décision : attendre la fin de la fenêtre pour discuter du retour peut rendre l’option inutilisable.
5. Préparer la sortie de la mobilisation exceptionnelle
- Service : les parcours essentiels ont-ils été validés par les personnes concernées ?
- Exploitation : les alertes, accès et procédures sont-ils utilisables ?
- Support : qui prend en charge les incidents après la bascule ?
- Données : les échanges et rapprochements nécessaires sont-ils confirmés ?
- Transition : à quelles conditions retire-t-on l’ancien environnement ?
- Capitalisation : quelles étapes doivent être corrigées avant la prochaine vague ?
La fin de la fenêtre technique et la fin de la transition sont deux jalons différents. Leur distinction permet de maintenir le bon niveau de suivi sans prolonger indéfiniment une organisation exceptionnelle.
Sources et périmètre
Les références AWS étayent la préparation et le retour arrière. La fiche et le scénario sont des propositions Spark, sans résultat client revendiqué.
Avant de mobiliser un renfort pour cette préparation, précisez sa contribution et ses interfaces : notre guide pour cadrer une mission de consultant Cloud propose un brief et des critères de choix.
Retrouvez nos prochains points de vue Cloud, Data et Pilotage sur la page LinkedIn Spark Conseil.
