Analyse des causes racines (5 pourquoi)
Présentation
L’analyse des causes racines (ACR) est une méthode structurée de résolution de problèmes : vous commencez par un énoncé du problème, puis vous demandez "Pourquoi ?" cinq fois de suite. Chaque réponse sert de base à la question suivante. L’objectif est de dépasser les symptômes afin 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 support client et du service
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é du problème clair — ce qui s’est passé, quand, et quel a été l’impact.
Demandez "Pourquoi cela s’est-il produit ?" et enregistrez la réponse (Réponse 1).
Demandez "Pourquoi la Réponse 1 s’est-elle produite ?" et enregistrez 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 traiter par une modification de processus ou de système — c’est la cause racine.
Définissez les actions correctives : attribuez à chaque action un propriétaire et une date d’échéance.
Conseil : une bonne cause racine renvoie à un processus ou à un système, pas à une personne. Si votre réponse est un nom, demandez encore pourquoi.
Exemple
Énoncé du problème : La page de paiement a été indisponible pendant trois heures le 12 août — environ 18 000 dollars de commandes perdues et plus de 40 tickets au service d’assistance. (Enquête réalisé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 mise en production 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 déploiement ne comporte aucune étape de test de performance.
Cause racine : Le processus de déploiement 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 déploiement et former l’équipe (responsable d’ingénierie, 20 août)
À bientôt !
Khawaja Rizwan
