Les runbooks sont souvent écrits pour les audits, pas pour les gens sous stress
Publié sur LinkedIn le 3 juillet 2026
Un runbook peut être conforme, validé, rangé dans le bon répertoire, daté, versionné, relu et pourtant inutilisable le jour où la production tombe.
C’est dur à entendre, mais c’est fréquent.
Parce que beaucoup de runbooks sont écrits pour prouver qu’une procédure existe.
Pas pour aider quelqu’un à agir vite, sous pression, avec une information imparfaite, à 3h du matin.
Un bon runbook n’est pas un roman technique.
Ce n’est pas une encyclopédie du SI.
Ce n’est pas une collection de captures d’écran.
Ce n’est pas une procédure de cinquante pages que personne n’ose ouvrir pendant une crise.
Un bon runbook doit permettre de passer à l’action.
Il doit dire quoi faire, dans quel ordre, par qui, avec quels prérequis, quels points de contrôle, quels critères d’arrêt et quels risques connus.
Il doit distinguer l’essentiel du contexte.
Il doit éviter le jargon inutile.
Il doit donner les contacts utiles.
Il doit préciser les dépendances.
Il doit indiquer les validations nécessaires.
Il doit prévoir les cas d’échec.
Il doit être accessible même si le SI principal est indisponible.
La vraie question n’est pas :
“Avons-nous un runbook ?”
La vraie question est :
“Une personne compétente, mais fatiguée et sous stress, peut-elle l’utiliser sans improviser dangereusement ?”
Pendant une crise, la charge cognitive explose.
Les équipes doivent diagnostiquer, contenir, communiquer, décider, restaurer, surveiller, documenter et parfois répondre à plusieurs niveaux de management en même temps.
Dans ce contexte, chaque phrase floue coûte du temps.
Chaque prérequis oublié crée un blocage.
Chaque dépendance non indiquée déclenche une mauvaise surprise.
Chaque contact obsolète ajoute de la friction.
Un runbook efficace doit être testé comme un composant de production.
On l’exécute.
On mesure les délais.
On repère les ambiguïtés.
On corrige les étapes.
On supprime le bruit.
On ajoute les contrôles manquants.
On rejoue.
C’est là que le document devient utile.
Pas quand il est approuvé.
Quand il fonctionne.
Test simple : confier la procédure à une personne qui connaît bien le domaine, mais ne l’a pas écrite.
Si elle bloque, hésite ou improvise, le runbook doit être revu.
Un bon runbook n’est jamais parfait du premier coup.
Il s’améliore avec les exercices PRA, les incidents réels, les retours d’expérience, les changements d’architecture et les nouvelles dépendances.
Il doit vivre avec le SI.
Sinon, il devient une archive polie.
Et en crise, une archive polie ne redémarre rien.
Elle donne juste l’illusion que quelqu’un avait prévu quelque chose.
La résilience opérationnelle exige des procédures courtes, testées, lisibles et actionnables.
Des runbooks pour les équipes.
Pas seulement pour les audits.
PS : Si vous découvrez mon contenu (veille CERT, Post), je vous invite à me suivre sur LinkedIn
hashtag#Runbook hashtag#RésilienceIT hashtag#PRA hashtag#PCA hashtag#GestionDeCrise hashtag#ProductionIT hashtag#DSI hashtag#RSSI
