Dans tout projet, une partie du savoir-faire opérationnel finit par se concentrer dans la tête de quelques personnes. Celui qui sait relancer la procédure de validation budgétaire, celle qui connaît la séquence exacte pour préparer un comité de pilotage, l’expert qui seul maîtrise le paramétrage d’un outil métier. Cette concentration de connaissances tacites constitue un risque rarement inscrit dans les registres de risques, mais dont les conséquences sont bien réelles: retards en cas d’absence, goulots d’étranglement récurrents et transitions chaotiques quand un collaborateur quitte l’équipe.
Le runbook est l’un des outils les plus simples pour réduire ce risque. Issu à l’origine du monde des opérations informatiques, où il désigne un document regroupant les procédures pas à pas pour traiter des incidents ou des tâches récurrentes, le runbook s’applique à tout contexte où des actions doivent être exécutées de manière fiable et reproductible.
Ce que contient un runbook (et ce qu’il n’est pas)
Un runbook est un document opérationnel qui décrit, étape par étape, comment exécuter une tâche ou réagir à une situation donnée. Chaque procédure inclut un déclencheur (quand l’appliquer), les prérequis nécessaires, la séquence d’actions à réaliser, les résultats attendus à chaque étape et la marche à suivre en cas d’anomalie.
Il est utile de distinguer le runbook de deux documents voisins. Le playbook, terme souvent utilisé de manière interchangeable, désigne plutôt un guide stratégique qui décrit l’approche générale face à une catégorie de situations, sans détailler chaque manipulation. La SOP (Standard Operating Procedure, procédure opérationnelle standard) est un document formel, souvent lié à des exigences réglementaires ou de conformité. Le runbook se situe entre les deux: suffisamment détaillé pour être suivi par quelqu’un qui découvre la tâche, mais moins formel qu’une SOP certifiée.
Trois situations où le runbook change la donne
La première est la gestion des tâches récurrentes dont la fréquence est trop faible pour que la mémoire musculaire s’installe. La clôture mensuelle d’un budget projet, la préparation d’un comité de pilotage, la mise à jour d’un tableau de bord consolidé: ces tâches reviennent assez souvent pour justifier un processus, mais pas assez pour qu’on se souvienne de chaque détail d’une occurrence à l’autre. Sans runbook, chaque exécution comporte son lot d’approximations et d’oublis.
La deuxième concerne les incidents prévisibles. Tout projet traverse des situations qui ne sont pas des surprises mais des événements attendus: un fournisseur qui livre en retard, un environnement de recette qui devient indisponible, une demande de changement de périmètre. Disposer d’un runbook pour ces scénarios permet de réagir méthodiquement plutôt que dans l’urgence, en suivant une procédure déjà validée.
La troisième est le passage de relais, qu’il s’agisse d’une rotation au sein de l’équipe, d’un remplacement temporaire ou d’une transition de phase. Dans les organisations où la continuité opérationnelle repose sur des processus documentés plutôt que sur la disponibilité de quelques individus, le runbook s’avère un outil de résilience dont l’utilité dépasse largement le périmètre IT.
Le runbook au-delà de l’informatique
L’association entre runbook et IT est historiquement forte, mais réductrice. Le principe de documenter des procédures opérationnelles détaillées existe dans des domaines bien antérieurs à l’informatique. Les procédures de vol de la NASA pour les missions Apollo étaient, dans leur essence, des runbooks: des séquences d’actions précises, avec des points de contrôle et des procédures de repli en cas de déviation. L’industrie pharmaceutique, la maintenance aéronautique et la gestion hospitalière utilisent des documents analogues depuis des décennies.
En gestion de projet non-IT, le runbook trouve sa place partout où la fiabilité d’exécution est critique: organisation d’événements, déploiement de programmes de formation, lancement de produits, campagnes de migration de données. Le point commun est toujours le même: une séquence d’actions qui doit être exécutée correctement, potentiellement par des personnes qui ne l’ont jamais réalisée auparavant.
Les pièges à éviter
Le premier piège est de rédiger des runbooks trop génériques. Une instruction comme “vérifier que tout est en ordre” n’aide personne, car ce qui constitue “l’ordre” varie selon l’observateur. Les étapes doivent être suffisamment précises pour qu’une personne compétente mais non familière avec la tâche puisse les suivre sans interprétation.
Le deuxième piège est de ne jamais mettre à jour le runbook après sa création. Un document qui décrit une procédure obsolète est plus dangereux que l’absence de document, car il inspire une fausse confiance. Chaque exécution devrait être l’occasion de vérifier que les étapes correspondent encore à la réalité et de corriger les écarts.
Le troisième est de vouloir tout documenter. Un runbook est pertinent pour les tâches à la fois critiques et reproductibles. Documenter des activités triviales ou des situations uniques produit une masse documentaire que personne ne consulte, ce qui finit par discréditer l’ensemble de la démarche.
Par où commencer
L’approche la plus pragmatique consiste à identifier les trois ou quatre procédures dont l’absence de documentation a déjà causé des problèmes: retards liés à l’indisponibilité d’un expert, erreurs lors d’un remplacement, temps perdu à retrouver une séquence d’actions oubliée. Ces irritants concrets fournissent le meilleur point de départ, car ils garantissent que le runbook sera utilisé dès sa création.
Le format importe peu au début. Un document partagé, un wiki interne ou même un tableur structuré suffisent. Ce qui compte, c’est que le document soit accessible à l’ensemble de l’équipe, versionné pour qu’on puisse suivre les modifications et rédigé par la personne qui exécute réellement la tâche, car elle seule connaît les détails qui font la différence entre une procédure théorique et un guide réellement utilisable. Un bon test de validation consiste d’ailleurs à confier le runbook à un collègue moins expérimenté et à lui demander de suivre les étapes: les zones d’ombre, les hypothèses implicites et les raccourcis involontaires apparaissent immédiatement.