Fondamentaux de la gestion d'incidents¶
Comprendre ce qu'est un incident, comment le classifier et comment suivre son cycle de vie.
Qu'est-ce qu'un incident¶
Un incident est tout événement non planifie qui provoque une dégradation ou une interruption d'un service en production, affectant directement les utilisateurs ou la capacité opérationnelle de l'organisation.
La notion clé est l'impact mesurable : une alerte sans conséquence visible n'est pas un incident au sens ITSM du terme.
Incident, problème et événement¶
| Concept | Définition | Exemple |
|---|---|---|
| Événement | Changement d'état détecté dans le système | Alerte CPU > 80 % |
| Incident | Interruption ou dégradation de service non planifiee | API en erreur 500 pour 30 % des requêtes |
| Problème | Cause racine sous-jacente d'un ou plusieurs incidents | Fuite mémoire dans le service de paiement |
Un incident peut être clos une fois le service restaure, même si la cause racine n'est pas encore identifiée. Le problème persiste jusqu'à ce que la cause soit éliminée.
Classification par sévérité¶
La grille de sévérité (P1 a P4) permet de prioriser la réponse et d'activer le bon niveau d'escalade.
| Niveau | Libelle | Critères | Exemples |
|---|---|---|---|
| P1 | Critique | Service totalement indisponible ou données corrompues, impact > 20 % des utilisateurs | Panne de base de données principale, breach de sécurité |
| P2 | Majeur | Dégradation significative, fonctionnalité clé impactee, SLA en risque | Latences 5x la normale, échec de 10 % des paiements |
| P3 | Modere | Fonctionnalité secondaire impactee, contournement possible | Rapport PDF indisponible, envoi d'emails retarde |
| P4 | Mineur | Impact negligeable, aucun SLA en risque | Erreur d'affichage cosmitique, log parasite |
Impact vs urgence¶
La sévérité est le produit des deux dimensions suivantes :
quadrantChart
title Impact vs Urgence
x-axis Faible urgence --> Urgence elevee
y-axis Faible impact --> Impact eleve
quadrant-1 P1 - Traitement immediat
quadrant-2 P2 - Escalade rapide
quadrant-3 P4 - Ticket standard
quadrant-4 P3 - File normale- Impact : nombre d'utilisateurs touches, revenu en risque, risque de données
- Urgence : vitesse de dégradation, fenêtre de correction disponible, heure (pic ou hors-pic)
Ne pas tout classer en P1
La sur-classification est un anti-pattern courant. Quand tout est P1, rien ne l'est vraiment. Une grille de sévérité mal appliquee épuisé les équipes et dilue la réponse aux vrais incidents critiques. Appliquez les critères objectivement et revisez la classification en cours d'incident si la situation évolue.
Cycle de vie d'un incident¶
flowchart LR
A([Detection]) --> B([Triage])
B --> C([Declaration])
C --> D([Investigation])
D --> E([Mitigation])
E --> F([Resolution])
F --> G([Cloture])
G --> H([Post-mortem])Description des phases¶
| Phase | Objectif | Livrable |
|---|---|---|
| Détection | Identifier le symptome (alerte, signalement utilisateur) | Ticket ouvert |
| Triage | Confirmer l'incident, estimer la sévérité | Sévérité provisoire |
| Declaration | Activer le processus de réponse | Canal war room ouvert |
| Investigation | Identifier la zone d'impact et les hypothèses | Hypothèse principale |
| Mitigation | Réduire l'impact sans necessairement corriger la cause | Service partiellement restaure |
| Résolution | Corriger la cause, restaurer le service à l'état normal | Service confirme stable |
| Clôture | Valider la stabilité, notifier les parties prenantes | Notification de clôture |
| Post-mortem | Analyser les causes racines, planifier les actions correctives | Document post-mortem |
Bonnes pratiques fondamentales¶
- Declarez l'incident tôt, même en cas de doute : il est plus facile de declasser que de rattraper un incident non déclaré
- Separez la gestion de l'incident (restaurer le service) de la gestion du problème (éliminer la cause)
- Documentez en temps réel : chaque action, chaque hypothèse, chaque constat
- Revisez la sévérité toutes les 30 minutes sur un P1 en cours