Faire écrire le manuel des incidents courants

Quand l’employer

À employer juste après la première mise en service, quand les pannes possibles sont connues et qu'aucune n'est encore survenue. À ne pas employer pendant un incident.

Les 4 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.

{PRODUIT_EN_SERVICE}

Quel produit est en service, et de quelles pièces dépend-il pour fonctionner ?

Pourquoi ce trou existe. Un manuel d'incident se construit sur la liste des pièces qui peuvent tomber. Sans cette liste, il traite des pannes imaginaires.

Si vous ne savez pas répondre. Reprenez le plan de mise en service : tout ce qui y est cité, base, hébergement, service extérieur, est une pièce qui peut tomber.

{QUI_REPOND}

Qui répond quand quelque chose ne marche plus, et à quelles heures ?

Pourquoi ce trou existe. Un manuel s'écrit pour son lecteur. Écrit pour un ingénieur alors qu'un gérant le lira, il ne sert à rien le jour venu.

Si vous ne savez pas répondre. C'est vous, et probablement seul. Écrivez le manuel pour vous-même dans six mois, quand vous aurez tout oublié.

{INCIDENTS_PROBABLES}

Quelles pannes sont plausibles, compte tenu de ce dont le produit dépend ?

Pourquoi ce trou existe. Un manuel qui traite trente pannes ne sert pas : il faut les cinq qui arriveront, traitées jusqu'au bout.

Si vous ne savez pas répondre. Prenez-en cinq : le produit ne répond plus, un service extérieur refuse, la base est pleine, une clé a expiré, une mise en service a mal tourné.

{LIMITE_D_ACTION}

Qu'est-ce que le lecteur du manuel n'a pas le droit de faire seul ?

Pourquoi ce trou existe. Un manuel qui n'a pas de limite conduit un lecteur pressé à tenter une manipulation irréversible pour rétablir le service.

Si vous ne savez pas répondre. Interdisez au minimum toute suppression de données, toute restauration de sauvegarde et toute modification directe de la base sans second avis.

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, et tu écris pour quelqu'un qui n'est pas développeur, qui lira ce texte un dimanche soir, sous stress, sur un téléphone. Ton mandat est qu'il sache quoi faire, dans quel ordre, et où s'arrêter.

## 2. CONTEXTE FACTUEL

Produit en service et pièces dont il dépend : {PRODUIT_EN_SERVICE}
Qui répond et à quelles heures : {QUI_REPOND}
Pannes plausibles : {INCIDENTS_PROBABLES}
Ce que le lecteur ne fait pas seul : {LIMITE_D_ACTION}

Le lecteur ne sait pas lire le code et n'a pas le temps d'apprendre. Toute étape formulée en termes techniques est une étape qui ne sera pas exécutée.

## 3. DEMANDE BORNÉE

Écris le manuel.

Ce que je veux, pour chacune des pannes citées et pour elles seules :
1. le symptôme, formulé comme ce que voit la personne qui appelle ;
2. le premier constat à faire, avec l'adresse à ouvrir ou l'écran à regarder ;
3. la mesure d'urgence qui rétablit le service, quand elle existe, ou la mention qu'il n'y en a pas ;
4. ce qu'il faut noter avant d'agir, pour que la cause reste analysable après coup ;
5. la limite : le point précis où le lecteur s'arrête et appelle, avec qui appeler ;
6. ce qu'il faut dire aux utilisateurs pendant la panne, rédigé, prêt à être envoyé.

Ce que je ne veux pas : une panne qui ne figure pas dans ma liste, une étape exigeant de lire des journaux techniques, une manipulation irréversible, un renvoi vers de la documentation extérieure.

## 4. FORMAT DE SORTIE EXIGÉ

Une fiche par panne, toutes construites sur les mêmes six rubriques, dans le même ordre. Chaque fiche tient sur un écran de téléphone. Le message aux utilisateurs est écrit en français, prêt à envoyer, sans blanc à compléter sauf l'heure.

Ta réponse est refusable si une fiche dépasse un écran, si une étape est irréversible sans avertissement, ou si la limite d'action manque sur une fiche.

Ce que vous devez recevoir

• Une fiche par panne, toutes bâties sur les mêmes six rubriques.
• Un symptôme formulé comme ce que voit la personne qui appelle.
• Un premier constat qui tient à une adresse à ouvrir ou un écran à regarder.
• Ce qu'il faut noter avant d'agir, pour que la cause reste analysable.
• Une limite d'action explicite, avec la personne à appeler.
• Un message aux utilisateurs rédigé, prêt à envoyer.

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.

• Une fiche exige de lire des journaux techniques, ce que le lecteur ne sait pas faire.
• Une manipulation irréversible est proposée sans avertissement ni limite.
• La limite d'action manque sur une fiche, ce qui laisse le lecteur seul face à un choix grave.
• Une panne absente de votre liste a été ajoutée, diluant les cinq qui comptent.
• Le message aux utilisateurs est décrit au lieu d'être rédigé.
• Une fiche renvoie à une documentation extérieure, inaccessible le soir de l'incident.

Selon pour qui vous construisez

Pour moi.

Écrivez le manuel pour vous-même dans six mois. Le futur vous ne se souviendra ni des noms de fichiers ni des raisons.

Pour mon employeur.

Faites relire chaque fiche par la personne qui répondra réellement au téléphone. Elle vous dira ce qu'elle ne saura pas faire.

Pour un client.

Le manuel fait partie du livrable et conditionne la fin de mission. Sans lui, vous restez le seul recours du client indéfiniment.