Exploitation
Runbook d’incident : écrire le guide que l’équipe utilisera vraiment
Comment transformer la connaissance dispersée en procédures d’incident courtes, testables et réellement utilisables sous pression.
Par La rédaction DEV N SI ·
Lorsqu’un service tombe en panne, l’équipe n’a pas besoin d’un document exhaustif. Elle a besoin d’un point de départ fiable : comment confirmer l’incident, quelles actions sont sûres, quand arrêter les essais et qui contacter. C’est le rôle d’un runbook. Un bon runbook ne remplace pas l’expertise. Il réduit la charge mentale et empêche que les premières minutes dépendent uniquement de la présence de la personne qui connaît le mieux le système.
Partir d’un symptôme observable
Un titre comme « procédure serveur » aide peu. Préférez un déclencheur concret : « l’application ne répond plus », « la file de messages augmente » ou « l’espace disque dépasse 90 % ». L’opérateur doit pouvoir reconnaître immédiatement la situation concernée.
Le début du document précise ensuite comment confirmer le symptôme avec deux ou trois vérifications simples. L’objectif est d’éviter une intervention lourde sur la base d’une alerte isolée ou mal interprétée.
Séparer diagnostic, contention et résolution
Sous pression, ces trois intentions se confondent facilement. Le diagnostic collecte les faits. La contention limite l’impact, par exemple en désactivant temporairement une fonctionnalité. La résolution traite la cause ou rétablit le service.
Chaque action doit indiquer le résultat attendu et le critère d’arrêt. Si une commande ne produit pas l’effet prévu, le runbook doit orienter vers l’escalade plutôt que multiplier les manipulations improvisées.
Documenter les risques avant les commandes
Une procédure utile mentionne les prérequis, les droits nécessaires et les conséquences possibles. Redémarrer un composant peut interrompre des traitements ; vider un cache peut augmenter brutalement la charge ; relancer une synchronisation peut créer des doublons.
Ces avertissements doivent apparaître au moment de l’action, pas dans une annexe. Lorsque c’est possible, privilégiez des commandes en lecture seule pour les premières vérifications et prévoyez un retour arrière explicite.
Rendre l’escalade opérationnelle
« Contacter l’administrateur » n’est pas une consigne suffisante. Le document doit préciser le rôle à joindre, le canal, les horaires éventuels et les informations à transmettre : heure de début, utilisateurs touchés, changements récents, messages d’erreur et actions déjà réalisées.
Une escalade bien préparée évite de recommencer le diagnostic depuis zéro et accélère la prise de décision.
Tester et améliorer après usage
Le meilleur test consiste à confier le runbook à une personne qui n’a pas participé à sa rédaction, dans un environnement sans risque. Les hésitations révèlent les hypothèses implicites, les accès manquants et les termes ambigus.
Après chaque incident, quelques minutes suffisent pour corriger les étapes devenues obsolètes. Le nom d’un responsable et la date du dernier test doivent rester visibles en haut du document.
Prochaine étape
Choisissez l’alerte la plus fréquente des trois derniers mois. Écrivez une page avec le symptôme, trois vérifications, deux actions sûres et un chemin d’escalade, puis faites-la exécuter par un collègue.
Ressources complémentaires
Pour compléter ce chantier, consultez notre guide pour transformer la supervision en alertes actionnables.
Pour compléter ce chantier, consultez notre guide pour auditer les fragilités de l’infrastructure.
Pour compléter ce chantier, consultez notre guide pour tester le plan de reprise.
Pour compléter ce chantier, consultez notre guide pour préparer la réaction à un incident de phishing.
Continuité · Exploitation · Incident · Runbook