Gestion d'incident majeur — runbook ITIL 4
Déclarer, piloter et clôturer un incident majeur : rôles, communication, priorisation et post-mortem sans blâme.
- #itil
- #incident-response
- #troubleshooting
Déclarer
Un incident est majeur si l'impact métier est fort (service critique indisponible, nombreux utilisateurs, risque financier ou réglementaire). En cas de doute : déclarer, on peut toujours déclasser.
Matrice de priorité :
| Impact \ Urgence | Haute | Moyenne | Basse |
|---|---|---|---|
| Élevé | P1 | P2 | P3 |
| Moyen | P2 | P3 | P4 |
| Faible | P3 | P4 | P4 |
Rôles
- Incident manager : pilote, décide, ne dépanne pas lui-même.
- Responsable technique : coordonne le diagnostic.
- Communication : points d'avancement réguliers aux parties prenantes.
- Scribe : chronologie horodatée de chaque action et décision.
Déroulé
- Ouvrir le ticket P1 et le canal de crise (visio + canal écrit).
- Évaluer l'impact, informer le métier (premier message < 15 min).
- Restaurer d'abord : contournement, retour arrière du dernier changement, bascule — la cause racine viendra ensuite.
- Points d'état toutes les 30 min : impact, actions en cours, prochaine communication.
- Confirmer le rétablissement avec le métier avant clôture.
Modèle de communication
[P1 – en cours] Paiement en ligne indisponible Impact : 100 % des paiements échouent depuis 14 h 05. Actions : retour arrière de la version 3.12 en cours. Prochain point : 14 h 45.
Post-mortem sans blâme
Sous 5 jours ouvrés : chronologie, détection (comment et en combien de temps), cause racine (5 pourquoi), ce qui a aidé ou freiné, actions correctives avec responsable et échéance. On cherche les failles du système, pas un coupable.
Indicateurs
MTTA (prise en compte), MTTR (rétablissement), nombre d'incidents liés à un changement, taux de récidive.