ITIL 4 est un cadre de référence, pas une checklist à appliquer mécaniquement. La différence entre une équipe qui bénéficie d’ITIL et une équipe qui souffre d’ITIL tient souvent à cette distinction.
La pratique de gestion des incidents : l’essentiel
ITIL définit un incident comme « une interruption non planifiée ou une réduction de la qualité d’un service ». La gestion des incidents a un objectif unique : rétablir le service le plus vite possible.
Ce que l’on confond souvent avec un incident : un problème (cause racine) ou un changement. Mélanger les trois dans le même processus crée de la confusion et ralentit la résolution.
Classification : deux niveaux suffisent pour commencer
| Priorité | Critère | Objectif de rétablissement |
|---|---|---|
| P1 - Critique | Service indisponible, impact > 50 utilisateurs | 1 heure |
| P2 - Majeur | Dégradation significative | 4 heures |
| P3 - Mineur | Impact limité, contournement disponible | 24 heures |
Commencez simple. Une grille à 5 niveaux non utilisée vaut moins qu’une grille à 3 niveaux rigoureusement appliquée.
Le war room : coordination sans chaos
Quand un incident P1 se déclenche, la première erreur est de laisser chacun agir de son côté en se mettant à jour par messages Slack éparpillés.
Structure minimale pour un war room efficace :
- Incident Commander : une personne (et une seule) qui coordonne, prend les décisions, communique vers les parties prenantes
- Tech Lead : l’expert technique qui diagnostique et applique les corrections
- Communication : une personne qui tient les parties prenantes informées (toutes les 15-30 minutes en P1)
Ce n’est pas une hiérarchie permanente — c’est un rôle de circonstance.
Le post-mortem blame-free : apprendre sans punir
## Post-mortem : [Nom de l'incident] — [Date]
**Durée** : 47 minutes (14h23 → 15h10)
**Impact** : Service API indisponible pour 100% des utilisateurs
**Chronologie**
- 14h23 : Alertes Prometheus déclenchées (taux d'erreur > 50%)
- 14h31 : Identification du composant défaillant (base de données)
- 14h52 : Décision de rollback prise
- 15h10 : Service rétabli
**Cause racine**
Migration de schéma appliquée sans test sur un jeu de données représentatif.
**Ce qui a bien fonctionné**
- Détection rapide grâce aux alertes (8 minutes)
- Communication claire vers les utilisateurs
**Actions correctives**
- [ ] Ajouter les migrations dans la suite de tests de charge — @alice, avant 15/03
- [ ] Créer un environnement de staging avec des données production anonymisées — @bob, avant 30/03Mesurer pour améliorer
Les métriques fondamentales en gestion des incidents :
- MTTA (Mean Time To Acknowledge) : combien de temps avant qu’un humain prenne connaissance de l’alerte ?
- MTTR (Mean Time To Restore) : combien de temps pour rétablir le service ?
- Taux de récurrence : quel pourcentage d’incidents est une répétition ?
Notre formation ITIL 4 approfondit ces pratiques avec des mises en situation réelles.