Préparer une mise en production et son retour arrière

Objectif

Arriver au point de préparation de mise en production avec un périmètre clair, les preuves de préparation et un déroulé utilisable par les personnes qui vont intervenir.

Quand l'utiliser

Avant une livraison logicielle, une bascule de système ou une activation de fonctionnalité. En cycle en V ou hybride, rattachez ce travail au planning de bascule. En agile, préparez-le au fil des incréments pour que les dépendances et les essais de retour soient anticipés.

Pour démarrer

Rassemblez la version candidate, le périmètre, le bilan des tests, les anomalies, les dépendances, les changements de données et la procédure de retour. Chaque pièce porte un auteur, sa fonction et une date, ainsi que la version et l'environnement concernés.

Convenez du sens des mots : la mise à disposition d'une version, ou release, peut recouvrir plusieurs opérations. Déployer installe une version. Activer rend une fonction utilisable par les clients concernés. Ces deux opérations peuvent avoir des dates et des autorisations différentes. Google SRE, séparation des composants et des activations (nouvel onglet).

Étapes

1. Délimiter ce qui va changer

Listez les fonctions, les clients concernés, les interfaces et les données touchées. Séparez le périmètre inclus, exclu et encore à arbitrer. Indiquez la version exacte, l'environnement et la fenêtre proposée, avec son fuseau horaire.

Demandez aux métiers quelles activités doivent continuer pendant la bascule. Faites préciser les contraintes de clôture, de commandes en cours, de disponibilité des partenaires et d'assistance aux utilisateurs.

2. Vérifier les conditions avec leurs preuves

Pour chaque condition de passage, inscrivez la preuve, son état, la personne qui la vérifie et l'action restante. Une case cochée doit renvoyer à un résultat identifiable.

Confrontez la recette au périmètre effectivement exposé. Si une réduction de périmètre est envisagée, faites vérifier ses dépendances et formaliser sa validation. L'exemple ci-dessous applique les six critères propres au cas, sans les transformer en règle universelle.

3. Écrire le déroulé de bascule

Préparez une séquence avec, pour chaque opération : responsable et relais, prérequis, début prévu, durée estimée, résultat attendu et contrôle de fin. Positionnez les points où une décision de poursuivre est nécessaire.

Ajoutez les accès à vérifier, la sauvegarde ou les moyens de récupération adaptés, le canal de coordination et les messages aux métiers/support. Faites confirmer qui autorise le démarrage, qui peut interrompre l'opération et qui constate le rétablissement.

4. Répéter le retour et vérifier le service

Le retour arrière, ou rollback, remet tout ou partie du système dans un état antérieur. Faites examiner la compatibilité du code, du schéma et des données après les nouvelles écritures. Un retour technique peut laisser des traitements métier à reprendre. Microsoft Learn, mécanismes de récupération (nouvel onglet).

Dans un environnement d'essai représentatif, rejouez la procédure et contrôlez un parcours métier complet. Mesurez séparément la durée de l'opération technique et le temps jusqu'au service rétabli. Documentez les écarts avec la production. Faites définir une autre récupération si le retour est impossible ou risquerait d'aggraver la situation.

5. Préparer la surveillance et la décision

Convenez des signaux à observer, de leur source, des seuils d'arrêt et de la durée d'observation. Vérifiez aussi qu'il y a assez d'activité pour interpréter les résultats. Une exposition progressive peut limiter le nombre de clients affectés, lorsque l'architecture et les usages le permettent.

Présentez aux personnes habilitées les preuves disponibles, les conditions non satisfaites et les options à examiner. Consignez leur décision, le périmètre autorisé et les conditions associées. Après l'intervention, conservez les horaires réels, les contrôles et les suites confiées à l'exploitation.

Cas pratique — préparer la version du 6 octobre

Projet fictif Commandes et approbations, R-2026.41. Au 29 septembre, le dossier prépare le comité du 2 octobre et la version prévue le 6 octobre. Aucun résultat ultérieur n'est présumé.

Dans T15, rapprochez les critères de S05 des constats de S03 et du registre de release :

Le point à faire travailler en équipe : désactiver approbation_multi_niveaux ramène le circuit à un niveau, mais les commandes en cours restent bloquées à leur étape. Le registre annonce un historique lisible. La procédure manuelle de reprise reste à définir.

Préparez l'essai de retour avec l'exploitation et le métier : nouvelle commande, commande déjà en cours, historique et notifications. Demandez les résultats réellement observés. La lisibilité de l'historique ne démontre ni la reprise des commandes ni l'annulation d'un message déjà envoyé.

Question pour le comité : quel périmètre peut être envisagé le 6 octobre et quelles preuves restent à obtenir avant son autorisation ? S05 confie la décision au VP Engineering et à la CPO conjointement, avec avis du Head of Customer Success lorsque des clients pilotes sont activés. Dans ce cas, un GO conditionnel réduit explicitement le périmètre et ne suspend aucun des six critères sur le périmètre exposé.

Trame à reprendre dans votre préparation

Version, périmètre et clients concernés :
Fenêtre proposée et contraintes métier :
Condition / preuve datée / constat / action / responsable / échéance :
Séquence de bascule et contrôles de fin :
Personnes habilitées à démarrer, interrompre et constater le rétablissement :
Signal d'arrêt, seuil et source de mesure :
Procédure de récupération, données et opérations en cours :
Essai réellement exécuté, environnement, résultat et durées :
Décision tracée, périmètre autorisé et conditions :
Surveillance, assistance et transmission à l'exploitation :

Livrables et contrôle avant diffusion

Le dossier rassemble le bilan de préparation, le déroulé de bascule, la procédure de récupération et le relevé de décision lorsqu'elle a été prise.

• La version, les dates et le périmètre sont explicites.
• Chaque condition renvoie à une preuve ou à une action attribuée.
• Les opérations en cours et les effets sur les données sont traités.
• La répétition et ses résultats sont documentés.
• Les contacts, accès, signaux d'arrêt et contrôles après retour sont vérifiés.
• Le support connaît les changements et la conduite à tenir.

Pièges

• Confondre désactivation et rétablissement. Contrôlez les parcours métier après l'opération.
• Réduire le périmètre uniquement dans le support de comité. Vérifiez la configuration, les interfaces et les tests associés.
• Préparer le retour le soir de la bascule. Intégrez sa répétition au planning et réservez les personnes nécessaires.
• Déclarer le service sain sans usage observé. Rapprochez les erreurs, le trafic et les transactions métier.

Qui d'autre est concerné ?

La gestion de projet coordonne les contributions et le planning. Le Product Owner et les métiers précisent le périmètre et les parcours. Développement, test, exploitation et sécurité apportent leurs preuves. Le support prépare l'assistance. Les personnes habilitées autorisent le périmètre selon les règles de l'organisation.

Termes du glossaire

• Mise à disposition d'une version.
• Retour arrière.