Qu’est-ce qu’un incident ?
Un incident, c’est quand quelque chose qui fonctionnait ne fonctionne plus. L’utilisateur ne peut plus travailler (ou moins bien), et il nous appelle (souvent un peu stressé).
À ne pas confondre avec une demande : “Je voudrais un deuxième écran” n’est pas un incident. “Mon écran ne s’allume plus” en est un.
Pourquoi formaliser la gestion des incidents ?
Parce que sans méthode, on se retrouve à :
- Traiter en priorité celui qui crie le plus fort
- Oublier des incidents en cours
- Résoudre dix fois le même problème sans jamais s’attaquer à la cause
- Ne pas savoir répondre quand la direction demande “ça arrive souvent, ça ?”
Les étapes de la gestion d’un incident
1. Identification et enregistrement
Tout incident doit être enregistré, même s’il est résolu en 30 secondes. Cela permet :
- De garder une trace
- De détecter les problèmes récurrents
- De justifier la charge de travail de l’équipe (si, si, c’est utile)
Informations minimales à collecter :
- Qui est impacté ?
- Quel service/application ne fonctionne pas ?
- Depuis quand ?
- Quel est l’impact ? (1 personne ? 50 ? toute l’entreprise ?)
2. Classification et priorisation
Tous les incidents ne se valent pas. Un serveur de production en panne à 9h un lundi, ce n’est pas la même chose qu’une imprimante capricieuse dans une salle de réunion.
La priorité dépend généralement de :
- L’impact : combien de personnes sont touchées ?
- L’urgence : peuvent-elles contourner le problème ? Y a-t-il une deadline ?
| Impact / Urgence | Haute | Moyenne | Basse |
|---|---|---|---|
| Élevé | Critique | Haute | Moyenne |
| Moyen | Haute | Moyenne | Basse |
| Faible | Moyenne | Basse | Basse |
3. Diagnostic
C’est là qu’on enfile sa casquette de détective :
- Qu’est-ce qui a changé récemment ? (mise à jour, modification, nouveau matériel)
- Le problème est-il reproductible ?
- D’autres utilisateurs sont-ils impactés ?
- Les logs disent-ils quelque chose d’utile ? (spoiler : pas toujours)
4. Résolution (ou escalade)
Si on sait résoudre : on résout.
Si on ne sait pas, on escalade. Escalader n’est pas un aveu de faiblesse, c’est de la lucidité. Mieux vaut passer la main rapidement que de bloquer un incident critique pendant 2 heures “parce qu’on va bien finir par trouver”.
5. Clôture
Avant de clôturer :
- Vérifier avec l’utilisateur que le problème est bien résolu (pas juste de notre point de vue)
- Documenter la solution (pour la prochaine fois)
- Se poser la question : est-ce que ça va se reproduire ? Si oui, ouvrir un ticket de problème.
Incident vs Problème
Un incident : “Le serveur mail est en panne.” Un problème : “Le serveur mail tombe en panne tous les lundis matin depuis un mois.”
L’incident, on le traite. Le problème, on l’analyse pour trouver la cause racine et éviter que les incidents se reproduisent.
Les erreurs classiques
- Ne pas enregistrer les incidents : “C’était rapide, pas besoin de ticket.” Si, justement.
- Sous-estimer l’impact : “C’est juste Martine de la compta.” Sauf que Martine fait la paie.
- Résoudre sans comprendre : “J’ai redémarré et ça marche.” Super, mais pourquoi c’était en panne ?
- Oublier de communiquer : L’utilisateur attend. Un petit message “on est dessus” fait des miracles.
En résumé
- Enregistrer systématiquement
- Prioriser intelligemment
- Diagnostiquer méthodiquement
- Résoudre (ou escalader) rapidement
- Documenter pour le futur
- Communiquer tout au long du processus