Il est 2 h du matin, quelque chose est en panne, et la seule personne qui connaît la solution est dans un avion. Qu'il s'agisse d'un traitement de paiements en échec, d'un serveur à l'arrêt ou d'une file de commandes bloquée, l'heure qui suit dépend d'une chose : le savoir est-il écrit, ou seulement dans la tête de quelqu'un ? Le runbook est la façon de l'écrire. Ce guide explique ce qu'est un runbook, en quoi il diffère d'une procédure standard et comment en rédiger un que les gens ouvrent réellement sous pression.
Qu'est-ce qu'un runbook ?
Un runbook est un guide court et pratique pour gérer une situation précise : une tâche récurrente, une panne connue ou un incident. Il indique à la personne d'astreinte ce qui a déclenché la situation, qui en est responsable, quoi faire exactement, comment revenir en arrière si cela empire et qui appeler. Le test d'un bon runbook est simple : un collègue compétent qui n'a jamais fait cette tâche pourrait-il le suivre seul, de nuit, sans vous appeler ?
Runbook ou procédure standard : quelle différence ?
Les deux se recoupent, et beaucoup d'équipes emploient ces mots indifféremment. Une distinction utile :
- Une procédure opérationnelle standard (SOP) décrit comment le travail courant doit toujours être fait, par exemple intégrer un fournisseur ou clôturer le mois. Elle vise la cohérence et la conformité, et se lit généralement à l'avance.
- Un runbook décrit comment réagir à un événement précis ou exécuter une tâche opérationnelle donnée, souvent sous pression. Il vise la rapidité et la sécurité, et se lit sur le moment.
Une procédure peut être détaillée et un peu formelle. Un runbook doit être direct : phrases courtes, commandes exactes, pas de longs exposés. Renvoyez du runbook vers la procédure quand quelqu'un a besoin du « pourquoi ».
Quand faut-il écrire un runbook ?
On ne peut pas tout documenter : commencez là où cela fait mal. Écrivez un runbook quand :
- Une tâche est répétée et coûteuse si elle est mal faite, comme les exports de paie mensuels ou une mise en production.
- Un incident s'est produit deux fois. La deuxième fois est le signal.
- Une seule personne sait faire quelque chose. C'est un risque, pas un atout.
- Une tâche est rare mais critique, comme une restauration de sauvegarde. Personne ne se souvient des procédures rares.
- Les nouveaux arrivants posent sans cesse les mêmes questions.
Que doit contenir un runbook ?
Gardez les mêmes cinq parties dans chaque runbook, pour que chacun sache toujours où chercher.
- Déclencheur. Quand utiliser ce runbook : l'alerte, le symptôme ou la date au calendrier. « Taux d'erreur du paiement supérieur à 5 % pendant dix minutes » est un déclencheur. « Quand ça va mal » n'en est pas un.
- Responsable. Une personne ou un rôle nommé, chargé de le garder exact, avec la date de la dernière revue.
- Étapes. Une liste numérotée, une action par étape, dans l'ordre, chacune avec le résultat attendu pour que le lecteur sache que cela a fonctionné.
- Retour arrière. Comment revenir à l'état précédent si une étape échoue ou aggrave la situation. Écrivez-le avant d'en avoir besoin.
- Escalade. Qui contacter si les étapes ne règlent pas le problème, dans quel ordre, comment, et après combien de minutes d'essais.
Comment rédiger des étapes que l'on suit vraiment ?
Une action par étape
« Redémarrez le service et vérifiez les journaux » fait deux étapes. Séparez-les, pour qu'une personne stressée ne saute pas la moitié.
Soyez précis
Donnez la vraie commande, le chemin de menu exact ou le lien réel. « Ouvrez le panneau d'administration » oblige à deviner. À 2 h du matin, le copier-coller vaut mieux que l'interprétation.
Décrivez à quoi ressemble le succès
Après chaque étape clé, écrivez ce que le lecteur doit voir : « La page d'état affiche En cours. » Sinon, il sait qu'il doit s'arrêter et escalader plutôt que continuer à l'aveugle.
Un court exemple
Voici le plan d'un runbook pour une file de commandes bloquée :
- Déclencheur : plus de 50 commandes en attente depuis plus de 15 minutes.
- Responsable : la responsable des opérations ; dernière revue en septembre.
- Étapes : vérifier la page d'état du prestataire de paiement ; redémarrer le worker de la file ; confirmer que le nombre de commandes en attente baisse en cinq minutes.
- Retour arrière : si le redémarrage crée des commandes en double, mettre le worker en pause et suivre le guide de nettoyage des doublons.
- Escalade : si la file n'avance pas après 20 minutes, appeler l'ingénieur d'astreinte, puis la direction des opérations.
Comment tester un runbook ?
Un runbook non testé est une hypothèse. Donnez-le à quelqu'un qui ne l'a pas écrit et demandez-lui de le suivre, idéalement dans un environnement sûr ou lors d'un exercice, pendant que vous observez en silence. Chaque endroit où la personne hésite, pose une question ou improvise est une lacune à corriger. Faites ces exercices une ou deux fois par an pour les runbooks critiques. Après chaque incident réel, ajoutez une question au retour d'expérience : le runbook a-t-il aidé, et qu'est-ce qui l'aurait amélioré ?
Comment garder un runbook à jour ?
- Donnez à chaque runbook un responsable et une date de revue. Chaque trimestre pour les critiques, deux fois par an pour les autres.
- Mettez-le à jour après chaque usage. Celui qui vient de le suivre sait mieux que quiconque ce qui était faux ou manquant : intégrez la correction à la clôture de l'incident.
- Liez-le au changement. Quand un système, un outil ou un fournisseur change, la mise à jour des runbooks concernés figure sur la même liste de contrôle.
- Gardez-le trouvable. Un runbook parfait dans un dossier oublié ne sert à rien. Rangez-les au même endroit, avec des noms clairs, et reliez-les à l'alerte elle-même quand c'est possible.
Où ranger vos runbooks ?
Un document partagé ou un wiki suffit pour démarrer. Plus que l'outil, ce qui compte, c'est que les runbooks soient proches du travail. Si vous suivez déjà opérations, tâches et KPI dans FulcrumGrid Command Center, vous pouvez relier chaque runbook au projet ou à l'indicateur qu'il protège, et attribuer les dates de revue à leurs responsables comme n'importe quelle tâche, pour qu'ils n'expirent pas en silence. Mais commencez par ce que votre équipe ouvrira vraiment.
Choisissez l'incident qui a le plus fait mal le trimestre dernier, écrivez son runbook cette semaine et testez-le avec une personne nouvelle. Un seul bon runbook apportera plus à votre équipe qu'un classeur plein de runbooks jamais testés.
Questions fréquentes
Un runbook est-il la même chose qu'un playbook ?
Les termes se recoupent. Beaucoup d'équipes réservent le runbook aux actions techniques ou opérationnelles précises, pas à pas, et le playbook à une stratégie plus large, comme gérer un incident majeur ou une escalade client, qui peut renvoyer à plusieurs runbooks.
Quelle longueur doit avoir un runbook ?
Aussi court que possible, idéalement une ou deux pages. S'il lui faut davantage, découpez-le en runbooks plus petits ou renvoyez vers des documents de contexte au lieu d'enterrer les étapes.
Qui doit écrire le runbook ?
La personne qui fait la tâche aujourd'hui doit le rédiger, car elle connaît les détails. Quelqu'un qui ne l'a jamais faite doit ensuite le tester et le corriger, car il repère les hypothèses manquantes.
À quelle fréquence réviser les runbooks ?
Révisez les runbooks critiques chaque trimestre et les autres deux fois par an. Mettez-en un à jour juste après son usage lors d'un incident réel ou quand le système concerné change.
FulcrumGrid Command Center
Gardez vos runbooks liés au travail
FulcrumGrid Command Center vous aide à suivre tâches, responsables et KPI au même endroit, pour que les revues de runbooks soient attribuées et que rien ne se périme en silence.