Faire écrire le plan de mise en service et son retour arrière

Quand l’employer

À employer avant chaque mise en service, y compris les petites. À ne pas employer pendant un incident : un plan écrit sous pression est un plan que personne ne relit.

Les 5 trous à remplir avant d’envoyer

Chaque trou est une décision déjà prise. Un trou que vous ne savez pas remplir n’est pas une case à improviser : c’est un travail de cadrage qui manque.

{CE_QUI_EST_MIS_EN_SERVICE}

Quels incréments partent en service, et lesquels restent en arrière ?

Pourquoi ce trou existe. Une mise en service dont le contenu n'est pas écrit ne peut pas être annulée proprement : on ne saura pas ce qu'il faut retirer.

Si vous ne savez pas répondre. Listez les incréments acceptés depuis la dernière mise en service. Ce qui n'a pas été accepté ne part pas.

{CHANGEMENT_DE_DONNEES}

Cette mise en service modifie-t-elle la structure ou le contenu des données existantes ?

Pourquoi ce trou existe. Le code se remet en arrière facilement, les données non. C'est la seule question qui décide si un retour arrière est possible.

Si vous ne savez pas répondre. Cherchez un fichier de migration dans ce qui part. S'il y en a un, la réponse est oui, et le plan change de nature.

{FENETRE_ET_UTILISATEURS}

Quand la mise en service a-t-elle lieu, et qui utilise le produit à ce moment-là ?

Pourquoi ce trou existe. Une mise en service pendant les heures d'usage transforme un incident mineur en appel de tous les utilisateurs en même temps.

Si vous ne savez pas répondre. Choisissez le creux d'activité et prévenez avant. Une mise en service annoncée qui échoue se pardonne, une surprise qui échoue ne se pardonne pas.

{SIGNAUX_DE_SUCCES}

Que devez-vous voir dans les dix minutes qui suivent pour dire que cela a marché ?

Pourquoi ce trou existe. Sans signaux définis à l'avance, on déclare le succès parce que le déploiement s'est terminé, ce qui n'est pas la même chose.

Si vous ne savez pas répondre. Prenez trois signaux observables : la page d'accueil répond, un utilisateur se connecte, une opération complète va jusqu'au bout.

{QUI_DECIDE_DU_RETOUR}

Qui décide du retour arrière, et à partir de quel constat ?

Pourquoi ce trou existe. Le retour arrière décidé au jugement se décide toujours trop tard. Décidé sur un critère écrit, il se décide à temps.

Si vous ne savez pas répondre. C'est vous. Écrivez le seuil avant : au bout de combien de minutes sans signal de succès vous revenez en arrière, sans discuter.

Le corps du gabarit

Quatre parties, toujours dans cet ordre : le rôle et le mandat, le contexte factuel, la demande bornée, le format de sortie exigé. Les trous restent visibles à la copie, et c’est voulu : les remplir un par un est la dernière occasion de s’apercevoir qu’une décision manque.

## 1. RÔLE ET MANDAT

Tu es responsable de l'exploitation. Ton mandat est d'écrire le plan qu'une personne pressée pourra suivre sans réfléchir, et le retour arrière qu'elle pourra déclencher sans autorisation. Tu n'exécutes rien : tu écris le plan.

## 2. CONTEXTE FACTUEL

Contenu de la mise en service : {CE_QUI_EST_MIS_EN_SERVICE}
Changement de données inclus ou non : {CHANGEMENT_DE_DONNEES}
Moment et utilisateurs présents : {FENETRE_ET_UTILISATEURS}
Signaux de succès attendus : {SIGNAUX_DE_SUCCES}
Décideur du retour arrière et critère : {QUI_DECIDE_DU_RETOUR}

Le plan doit être exécutable par quelqu'un qui n'a pas participé à la construction. Toute étape qui suppose de comprendre le code est une étape mal écrite.

## 3. DEMANDE BORNÉE

Écris le plan.

Ce que je veux :
1. la liste de ce qui doit être vrai avant de commencer, chaque ligne se répondant par oui ou par non ;
2. les étapes de la mise en service, numérotées, avec pour chacune le résultat attendu à l'écran ;
3. la vérification des signaux de succès, avec ce que je fais et ce que je dois voir ;
4. le retour arrière, écrit avec le même niveau de détail que la mise en service ;
5. ce que le retour arrière ne rattrape pas, en toutes lettres, en particulier du côté des données ;
6. la liste des personnes à prévenir, avant et après, avec le message à leur envoyer.

Ce que je ne veux pas : une étape qui suppose de lire le code, un retour arrière décrit en une phrase, une estimation de durée présentée comme une garantie, une mise en service qui commence par une modification manuelle non écrite.

## 4. FORMAT DE SORTIE EXIGÉ

Le retour arrière occupe autant de place que la mise en service. La liste de ce qui ne se rattrape pas est obligatoire, même quand elle est vide, auquel cas tu écris qu'elle est vide et pourquoi. Les étapes sont numérotées et se suivent sans choix à faire.

Ta réponse est refusable si le retour arrière est plus court que le plan, si la liste de ce qui ne se rattrape pas manque, ou si une étape demande de décider quelque chose au moment de l'exécution.

Ce que vous devez recevoir

• Une liste de conditions préalables, chacune se répondant par oui ou par non.
• Des étapes numérotées, chacune avec le résultat attendu à l'écran.
• Une vérification des signaux de succès, exprimée en gestes et en constats.
• Un retour arrière détaillé au même niveau que la mise en service.
• La liste explicite de ce que le retour arrière ne rattrape pas.
• La liste des personnes à prévenir, avant et après, avec le message.

Ce qui doit vous faire refuser

Ces motifs sont écrits comme des constats : « un fichier hors périmètre a été modifié » se vérifie, « le travail manque de rigueur » ne se vérifie pas.

• Le retour arrière tient en une phrase alors que la mise en service en compte vingt.
• La liste de ce qui ne se rattrape pas manque, ce qui laisse croire que tout est réversible.
• Une étape exige de décider quelque chose au moment de l'exécution, sous pression.
• Le plan commence par une modification manuelle qui n'est écrite nulle part.
• Les signaux de succès sont remplacés par la fin du déploiement, ce qui ne prouve rien.
• Le plan suppose que l'exécutant comprend le code, donc n'est utilisable que par son auteur.

Selon pour qui vous construisez

Pour mon employeur.

La fenêtre de mise en service et la liste des personnes prévenues se valident auprès du responsable métier. Une mise en service correcte au mauvais moment reste une faute.

Pour un client.

Le plan et son retour arrière sont remis au client avant la mise en service, pas après. C'est la pièce qui montre que le risque a été pensé.