Analyse des causes racines (ACR) : les 5 pourquoi
Bref
L’analyse des causes racines (ACR) par la méthode des 5 pourquoi est une technique de résolution de problèmes structurée qui commence par un énoncé du problème et consiste à demander «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 du processus ou du système que vous pouvez réellement corriger.
Qui peut l’utiliser
Équipes produit et ingénierie
Équipes opérationnelles 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 des incidents récurrents
Comment l’utiliser
Rédigez un énoncé du problème clair — ce qui s’est produit, quand et quel a été l’impact.
Demandez "Pourquoi cela s’est-il produit ?" et notez la réponse (Réponse 1).
Demandez "Pourquoi la Réponse 1 s’est-elle produite ?" et notez la réponse (Réponse 2).
Répétez pour les Réponses 3, 4 et 5.
Arrêtez-vous lorsque vous identifiez une cause que vous pouvez corriger par une modification du processus ou du système — il s’agit de la cause racine.
Définissez les actions correctives : attribuez à chacune un propriétaire et une date d’échéance.
Astuce : une bonne cause racine vise un processus ou un système, pas une personne. Si votre réponse est un nom, demandez pourquoi une fois de plus.
Exemple
Énoncé du problème : La page de paiement a été indisponible pendant 3 heures le 12 août — environ 18 000 dollars de commandes perdues et plus de 40 tickets au service d’assistance. (Enquête menée le 13 août par l’équipe 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 sa mise en production.
Pourquoi 5 : La checklist de la version ne comporte pas d’étape de test de performance.
Cause racine : Le processus de déploiement n’inclut pas d’étape obligatoire de tests de charge et de performance.
Actions correctives :
Ajouter un test de charge automatisé au pipeline CI (responsable DevOps, 30 août)
Configurer des alertes mémoire à 80 % d’utilisation (équipe SRE, 22 août)
Mettre à jour la checklist de la version et former l’équipe (manager ingénierie, 20 août)
Cordialement !
Khawaja Rizwan
