Five Whys (Les 5 Pourquoi)
Posez "Pourquoi ?" cinq fois. La méthode des 5 Pourquoi de Toyota transforme un symptôme de surface en cause racine actionnable, en moins de 30 minutes.
Description
La méthode des 5 Pourquoi est une technique d'analyse de cause racine qui consiste à poser itérativement la question "Pourquoi ?" pour remonter d'un symptôme observable jusqu'à la cause fondamentale d'un problème produit. Inventée par Sakichi Toyoda dans les années 1930 et formalisée par Taiichi Ohno au sein du Toyota Production System, cette approche reste l'un des outils de diagnostic les plus utilisés en product management. Votre dashboard affiche une chute de 15 % de l'activation des nouveaux utilisateurs. Votre réflexe : ajouter un tooltip, modifier l'onboarding, lancer un A/B test. Vous traitez le symptôme. Trois sprints plus tard, le chiffre n'a pas bougé parce que le vrai problème était ailleurs : un email de confirmation qui arrivait en spam. La méthode des 5 Pourquoi vous aurait fait économiser ces trois sprints. En posant "Pourquoi ?" de manière systématique, vous construisez une chaîne causale qui relie le symptôme visible à sa cause racine. Chaque réponse devient la question suivante, et la profondeur de l'analyse augmente à chaque itération. Comme l'a formulé Taiichi Ohno, architecte du Toyota Production System : "By repeating why five times, the nature of the problem as well as its solution becomes clear." Le chiffre 5 n'est pas une règle absolue : parfois 3 itérations suffisent, parfois il en faut 7. L'important est de continuer jusqu'à atteindre une cause sur laquelle vous pouvez agir directement : la contre-mesure. Dans le vocabulaire Toyota, une contre-mesure n'est pas un palliatif sur le symptôme mais une action corrective ciblant la cause racine elle-même. C'est la différence entre "relancer manuellement les emails" et "corriger la configuration SPF du domaine". La force de cette technique réside dans sa simplicité radicale. Pas de matrice, pas de scoring, pas de template complexe. Un problème, une question répétée, un crayon. C'est ce qui en fait un outil particulièrement adapté aux équipes produit qui ont besoin d'un diagnostic rapide avant de prioriser une correction dans le backlog. Elle se combine naturellement avec un diagramme d'Ishikawa pour les problèmes multi-causaux, ou avec le framework RICE pour prioriser les contre-mesures identifiées.
Objectifs
- Identifier les problèmes
- Améliorer la collaboration d'équipe
- Réduire les risques produit
Utilisé par
- -Toyota (a développé et systématisé la méthode au sein du Toyota Production System pour l'amélioration continue de ses chaînes de production)
- -Amazon (utilise les 5 Pourquoi dans ses post-mortems obligatoires après chaque incident de service majeur)
- -Spotify (intègre la technique dans ses rituels d'équipe pour diagnostiquer les problèmes de vélocité et de qualité produit)
Avantages
- Diagnostic en 30 minutes. Pas besoin de data warehouse ou de workshop de 2 jours. Un problème, un tableau blanc et 5 questions suffisent pour identifier la cause racine.
- Élimine le "solution jumping". Force l'équipe à résister à l'envie de coder immédiatement et à valider le diagnostic avant d'investir un sprint.
- Accessible à toute l'équipe. Aucune expertise statistique requise. Un PM junior, un dev ou un designer peuvent facilement faciliter la session.
- Crée un alignement immédiat. La chaîne causale visible sur un tableau blanc aligne instantanément stakeholders et équipe sur le vrai problème.
Limites
- Monocausal par défaut. La technique suit un seul fil logique. Si votre problème a plusieurs causes racines indépendantes, combinez avec un diagramme d'Ishikawa.
- Qualité dépendante du facilitateur. Un "Pourquoi ?" mal posé ou une réponse trop vague déraille toute la chaîne. Exigez des réponses factuelles et vérifiables.
- Biais de confirmation. L'équipe peut inconsciemment orienter la chaîne vers une cause qu'elle "sent" déjà. Invitez des personnes extérieures au problème.
- Ne remplace pas l'analyse quantitative. Pour les problèmes à grande échelle (churn systémique, performance globale), les 5 Pourquoi sont un point de départ, pas une conclusion.
Comment appliquer Five Whys (Les 5 Pourquoi)
- 1
Identifier le problème observable
Formulez le symptôme de manière factuelle et mesurable. Pas "l'onboarding ne marche pas" mais "le taux d'activation est passé de 45 % à 30 % sur les 2 dernières semaines". Un problème bien posé est déjà à moitié résolu. Écrivez-le en haut du tableau blanc pour que toute l'équipe le voie.
- 2
Poser le premier "Pourquoi ?"
Demandez : "Pourquoi ce problème se produit-il ?" Répondez avec des faits, pas des opinions. Si la réponse est "parce que les utilisateurs ne comprennent pas", challengez : quelles données le prouvent ? Un log, un enregistrement Hotjar, un ticket support. La rigueur du premier Pourquoi conditionne toute la chaîne causale.
- 3
Itérer les Pourquoi suivants
Prenez la réponse précédente et posez à nouveau "Pourquoi ?". Répétez 3 à 5 fois (le chiffre 5 est indicatif, pas absolu). À chaque itération, vous descendez d'un niveau dans la chaîne causale. Si vous tournez en rond ou si les réponses deviennent spéculatives, c'est le signal que vous avez besoin de données supplémentaires avant de continuer.
- 4
Identifier la cause racine
Vous avez atteint la cause racine quand la réponse pointe vers un élément sur lequel vous pouvez agir directement : un processus, une configuration, une décision. Si vous ne pouvez rien changer à ce niveau (ex: "parce que le marché a changé"), remontez d'un cran. La cause racine actionnable est juste au-dessus.
- 5
Définir la contre-mesure
Formulez une action corrective qui cible la cause racine, pas le symptôme. Assignez un owner, une deadline et un critère de succès mesurable. Planifiez un check-in à 2 semaines pour vérifier que le symptôme initial a effectivement disparu. Si ce n'est pas le cas, votre cause racine était probablement incorrecte : relancez l'analyse.