Logigramme de réponse aux incidents : de la première alerte au postmortem

À trois heures du matin, personne ne lit une politique d'incident de dix pages. L'ingénieur d'astreinte doit savoir quatre choses très vite : est-ce réel, est-ce un incident, qui d'autre doit être informé et que faire en premier. Un logigramme d'une page répond à ces questions dans l'ordre où elles se posent, et c'est la partie de la politique que les gens suivent vraiment.

Cet article construit un logigramme de réponse aux incidents pour une équipe d'ingénierie qui exploite un service en production : le triage, les critères de déclaration d'un incident, la gravité et les rôles, l'atténuation et le postmortem qui boucle la boucle. Il se termine par des conseils de dessin qui gardent un logigramme utilisable sous pression.

Ce que le logigramme doit trancher

Un processus d'incident est une suite de décisions séparées par quelques activités de longue durée. Les décisions ont leur place sur le schéma, sous forme de questions aux réponses étiquetées :

• L'alerte est-elle réelle et exploitable ? Sinon, le problème, c'est l'alerte.
• Est-ce un incident ? Sinon, c'est du travail ordinaire avec un ticket.
• Quelle est sa gravité ? La gravité décide de qui est appelé et de qui est informé.
• Le service est-il rétabli ? Sinon, essayez l'atténuation suivante ou escaladez.

Tout le reste, comme la façon d'annuler un déploiement ou de basculer une base de données, relève des runbooks vers lesquels le schéma renvoie.

Quand déclarer un incident

Déclarer est l'étape devant laquelle les équipes hésitent, et cette hésitation coûte cher. Le chapitre Managing Incidents du livre SRE de Google plaide pour une déclaration précoce : mieux vaut déclarer, trouver une correction simple et clore l'incident que lancer le processus des heures après le début d'un problème qui s'aggrave. L'équipe de ce chapitre déclare un incident dès que l'une de ces conditions est vraie :

1. Une deuxième équipe est nécessaire pour résoudre le problème.
2. La panne est visible par les clients.
3. Le problème n'est pas résolu après une heure d'analyse concentrée.

Inscrivez vos propres critères sur le schéma, à côté de la décision. Des critères clairs suppriment le coût social de la déclaration.

Les rôles

Le même chapitre décrit une structure fondée sur l'Incident Command System. Même une petite équipe gagne à nommer les rôles, car la défaillance la plus courante est qu'une seule personne les tienne tous :

Le responsable de l'incident tient aussi un document d'incident vivant et passe la main de façon explicite en fin de garde : le responsable sortant annonce la passation et attend une confirmation.

Les compétences de gestion d'incident s'émoussent quand on ne s'en sert pas. Le même chapitre suggère d'appliquer ce cadre aux changements opérationnels qui touchent plusieurs équipes ou fuseaux horaires, et de rejouer d'anciens incidents en jeu de rôle, pour que le processus soit familier avant le prochain incident réel. Faire parcourir le logigramme à un nouvel ingénieur d'astreinte avec un ancien incident est une façon peu coûteuse de commencer.

Les niveaux de gravité

Les définitions de gravité varient d'une entreprise à l'autre ; prenez celles-ci comme un exemple et inscrivez les vôtres sur le schéma :

Le logigramme, étape par étape

1. Acquitter et trier. Quand l'alerte se déclenche, acquittez-la pour arrêter l'escalade de l'appel, puis évaluez la portée et l'impact.
2. Réelle et exploitable ? Une alerte fausse ou inexploitable est ajustée ou supprimée, puis close.
3. Est-ce un incident ? Appliquez les critères. Sinon, traitez-le comme du travail normal avec un ticket.
4. Déclarer. Nommez le responsable de l'incident, ouvrez un canal et le document d'incident.
5. Gravité. Pour SEV-1 et SEV-2, un responsable de la communication publie sur la page de statut et envoie des points réguliers.
6. Atténuer d'abord. Revenez en arrière, basculez, désactivez le feature flag ou délestez la charge. La première priorité du livre SRE est d'arrêter l'hémorragie, de rétablir le service et de préserver les preuves ; la cause racine vient plus tard.
7. Rétabli ? Sinon, essayez l'atténuation suivante ou escaladez, et bouclez.
8. Résoudre. Confirmez avec les métriques, continuez à surveiller et rendez le système à l'exploitation normale.
9. Postmortem et actions. Rédigez un postmortem sans reproche, faites-le relire et clôturez l'incident quand les actions sont suivies.

Comment le lire :

• Oui va à droite, Non vers le bas. Chaque décision suit la même convention : le chemin principal avance vers la droite et les sorties anticipées descendent.
• À gauche, la première réponse. L'alerte est acquittée et triée. Les alertes qui ne sont ni réelles ni exploitables, et les événements qui ne sont pas des incidents, se terminent à Done.
• Troisième colonne, l'incident. Il est déclaré, sa gravité est évaluée, puis il est atténué. SEV-1 et SEV-2 ajoutent un responsable de la communication à droite.
• La boucle. La décision « Service restored? » vous renvoie à l'atténuation jusqu'à ce que la réponse soit oui.
• Colonne de droite, la clôture. Résolvez, rédigez le postmortem sans reproche et clôturez quand les actions sont suivies.
• Les notes contiennent les critères de déclaration et les niveaux de gravité, pour que personne n'ait à ouvrir un autre document.

Le postmortem boucle la boucle

Le chapitre Postmortem Culture du livre SRE liste des déclencheurs courants, comme une indisponibilité ou une dégradation visible par les utilisateurs au-delà d'un seuil, et toute perte de données. Un postmortem est sans reproche lorsqu'il cherche les causes contributives dans les systèmes et les processus sans blâmer les personnes ; sinon, les gens cessent de signaler les problèmes. Dessinez le postmortem sur le schéma comme un document avec un responsable et une échéance, et ne marquez pas l'incident comme clos tant que ses actions ne sont pas suivies.

Les incidents de sécurité demandent plus que ce schéma : la préservation des preuves, des étapes juridiques et réglementaires, et souvent une équipe distincte. Le NIST SP 800-61 Rev. 3, publié en avril 2025, en est la référence habituelle. Reliez une branche sécurité à ce processus plutôt que d'en improviser une.

Conseils de dessin pour les logigrammes utilisés sous pression

• Un seul début, des fins claires. Chaque chemin doit aboutir quelque part, même si c'est « Done ».
• Des décisions sous forme de questions oui ou non, avec les deux sorties étiquetées, et Oui et Non qui partent toujours des mêmes côtés.
• Rendez les boucles explicites. « Essayer l'atténuation suivante » est une boucle, pas une note de bas de page.
• Quinze formes au maximum. Les détails vont dans les runbooks liés depuis les étapes.
• Montrez où la responsabilité change de mains. Pour une version avec un couloir par rôle, partez du modèle de logigramme interfonctionnel.
• Placez-le là où regardent les ingénieurs d'astreinte. Liez ou intégrez le diagramme en direct dans le runbook plutôt que d'y coller une capture d'écran.

Si votre processus implique de nombreuses équipes et des passations formelles, un diagramme BPMN peut le modéliser plus précisément ; pour l'astreinte, un logigramme est plus facile à suivre.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Depuis le pack Logigramme, ajoutez un Début / Fin pour le départ et pour chaque fin, un Processus pour chaque étape et une Décision pour chaque question.
3. Ajoutez un Document pour le postmortem.
4. Reliez les formes. La forme Décision affiche Y sur son coin droit et N sur son coin inférieur : dessinez donc Oui vers la droite et Non vers le bas, étiquetez les deux et renvoyez la sortie « service non rétabli » vers l'atténuation.
5. Ajoutez des nœuds Note du pack Base avec vos critères de déclaration et vos niveaux de gravité.

L'exemple utilise 15 nœuds de diagramme et reste dans les limites de l'offre Free. La page créateur de logigrammes présente les autres formes et la disposition en couloirs.

FAQ

Qui doit être responsable du logigramme de réponse aux incidents ? L'équipe qui gère la rotation d'astreinte. Révisez-le après chaque incident où quelqu'un ne savait pas quoi faire ensuite.

Chaque alerte doit-elle devenir un incident ? Non. La plupart des alertes doivent être traitées comme du travail ordinaire. Déclarez quand vos critères sont remplis, et déclarez tôt en cas de doute.

Faut-il un responsable de l'incident pour les petits incidents ? Quelqu'un doit garder la vue d'ensemble. Dans un petit incident, l'ingénieur d'astreinte est le responsable, et le dire à voix haute évite que deux personnes corrigent la même chose de deux façons différentes.

Quand rédiger le postmortem ? Rapidement, tant que les détails sont frais. Fixez une échéance que votre équipe peut tenir, inscrivez-la sur le schéma et suivez les actions.

Le logigramme doit-il couvrir les incidents de sécurité ? Ajoutez une branche qui les confie à votre processus de gestion des incidents de sécurité. Il comporte des étapes différentes, comme la préservation des preuves et l'examen juridique.

Commencez gratuitement — un siège, sans carte bancaire.