Analyse des causes racines — méthode des 5 pourquoi
Bref
L’analyse des causes racines par la méthode des 5 pourquoi est une technique structurée de résolution de problèmes dans laquelle vous commencez par un énoncé du problème et demandez « Pourquoi ? » cinq fois de suite. Chaque réponse sert de base à la question suivante. L’objectif est d’aller au-delà des symptômes et de mettre au jour la défaillance d’un processus ou d’un système que vous pouvez réellement corriger.
Qui peut l’utiliser
Équipes produit et ingénierie
Équipes opérations et DevOps
Équipes du service client et d’assistance
Chefs de projet
Équipes d’assurance qualité
Toute personne enquêtant sur des problèmes ou incidents récurrents
Comment l’utiliser
Rédigez un énoncé clair du problème — ce qui s’est passé, quand et quel a été l’impact.
Demandez "Pourquoi cela s’est-il produit ?" et consignez la réponse (Réponse 1).
Demandez "Pourquoi la Réponse 1 s’est-elle produite ?" et consignez la réponse (Réponse 2).
Répétez pour les Réponses 3, 4 et 5.
Arrêtez-vous lorsque vous atteignez une cause que vous pouvez corriger par un changement de processus ou de système — c’est la cause racine.
Définissez des actions correctives : assignez à chaque action un propriétaire et une date d’échéance.
Astuce : une bonne cause racine porte sur un processus ou un système, pas sur une personne. Si votre réponse est un nom, demandez "Pourquoi ?" une fois de plus.
Exemple
Énoncé du problème : La page de paiement était indisponible pendant 3 heures le 12 août — environ 18 000 dollars de commandes perdues et plus de 40 tickets d’assistance. (Investigation menée le 13 août par l’équipe de la plateforme.)
Pourquoi 1 : Le serveur de paiement a manqué de mémoire et a planté.
Pourquoi 2 : Le service de paiement présente une fuite de mémoire.
Pourquoi 3 : La version du 8 août ne ferme pas les anciennes connexions à la base de données.
Pourquoi 4 : La version n’a jamais été testée en charge avant d’être mise en production.
Pourquoi 5 : La checklist de la version ne contient pas d’étape de test de performance.
Cause racine : Le processus de mise en production ne comporte pas d’étape obligatoire de test de charge ou de performance.
Actions correctives :
Ajouter un test de charge automatisé dans le pipeline CI (responsable DevOps, 30 août)
Définir des alertes mémoire à 80% d’utilisation (équipe SRE, 22 août)
Mettre à jour la checklist de la version et former l’équipe (responsable ingénierie, 20 août)
À bientôt !
Khawaja Rizwan
