Du symptôme à la cause : méthodes comparées
Choisir la méthode d'analyse de causes adaptée à la complexité et à la criticité d'un incident récurrent.
À retenir
- La gestion des problèmes traite la cause pour éviter la récurrence, contrairement à la gestion des incidents qui restaure le service.
- Le choix de la méthode d'analyse doit correspondre à la complexité réelle de l'incident.
- Distinguer facteur déclenchant, cause contributive et cause racine évite des actions correctives superficielles.
- Un atelier collectif avec le diagramme d'Ishikawa révèle des angles morts individuels.
Pourquoi la gestion des problèmes existe
La gestion des incidents restaure le service ; la gestion des problèmes cherche à empêcher que l'incident se reproduise, en traitant la cause sous-jacente. Confondre les deux conduit à traiter sans cesse les mêmes symptômes.
Trois méthodes comparées
| Méthode | Quand l'utiliser | Limite |
|---|---|---|
| 5 pourquoi | Incident simple, cause probablement unique | Peut s'arrêter trop tôt si l'animateur manque de rigueur |
| Diagramme d'Ishikawa (causes/effets) | Cause multifactorielle (main d'œuvre, méthode, matériel, milieu) | Demande un atelier structuré, plus long |
| Arbre des causes | Incident grave avec plusieurs facteurs concourants et enchaînement d'événements | Nécessite une collecte de preuves rigoureuse |
Point clé
le choix de la méthode dépend de la complexité réelle de l'incident, pas des habitudes de l'équipe. Un incident électrique avec trois facteurs concomitants ne se résout pas avec un simple 5 pourquoi.
Exemple de 5 pourquoi appliqué
- Pourquoi la salle a-t-elle surchauffé ? Le CRAC n°2 s'est arrêté.
- Pourquoi s'est-il arrêté ? Une alarme de pression haute l'a coupé.
- Pourquoi la pression était-elle haute ? Le filtre à air était colmaté.
- Pourquoi le filtre était-il colmaté ? La maintenance préventive prévue n'a pas été réalisée.
- Pourquoi n'a-t-elle pas été réalisée ? Le planning de maintenance n'envoie pas d'alerte automatique de retard.
Cause racine : absence d'alerte automatique sur retard de maintenance préventive, pas simplement « filtre encrassé ».
Attention
s'arrêter à la troisième question (« filtre colmaté ») produit une action corrective superficielle (nettoyer le filtre) qui ne traite pas la cause organisationnelle réelle.
Distinguer cause racine, cause contributive et facteur déclenchant
- Facteur déclenchant : l'événement immédiat qui a précipité l'incident (le filtre colmaté qui bloque le flux d'air).
- Cause contributive : un facteur qui aggrave sans être la cause première (température extérieure élevée ce jour-là).
- Cause racine : le dysfonctionnement structurel qui, corrigé, empêche la récurrence (absence d'alerte de planning).
Sur le terrain
un post-mortem qui liste uniquement des facteurs déclenchants sans remonter à une cause racine produit des actions correctives qui ne tiennent jamais dans la durée.
Diagramme d'Ishikawa — les 5M appliqués au data center
| Catégorie | Exemple de question |
|---|---|
| Main d'œuvre | La compétence ou la charge de l'équipe était-elle adaptée ? |
| Méthode | La procédure de maintenance était-elle correcte et suivie ? |
| Matériel | L'équipement était-il en fin de vie ou mal dimensionné ? |
| Milieu | Les conditions environnementales étaient-elles atypiques ? |
| Mesure | Disposait-on des bons indicateurs pour détecter la dérive à temps ? |
Astuce
faites systématiquement remplir les 5M en atelier collectif plutôt qu'en solo ; les angles morts d'un technicien sont souvent visibles pour un collègue d'une autre spécialité.
Choisir la méthode selon la gravité
Pour un incident P3/P4 isolé, un 5 pourquoi documenté en 20 minutes suffit. Pour un incident P1 avec plusieurs causes concourantes (électrique + procédure + environnement), un arbre des causes formel avec preuves horodatées est nécessaire pour un rapport client ou une revue de direction.