5 Pourquoi : analyse des causes racines

Demandez pourquoi jusqu'à trouver une cause que vous pouvez corriger.

Essayez cette rétrospective en direct

Énoncé du problème

Que s'est-il passé exactement, où et quand ?

La version 4.2 a été livrée avec deux jours de retard, la troisième livraison en retard ce trimestre.
Les erreurs de paiement sont montées à 3 % des commandes après le déploiement de mardi.
Quarante tickets de support ont attendu plus de 48 heures une première réponse la semaine dernière.
Ce que nous savons

Quels faits et données décrivent le problème ?

Le build était vert vendredi, et la branche de release a été créée lundi.
Les logs d'erreurs montrent des timeouts du prestataire de paiement à partir de 14h05.
Deux de nos quatre relecteurs étaient en congé cette semaine-là.
Pourquoi est-ce arrivé ?

Qu'est-ce qui a directement causé le problème ?

Les tests finaux ont commencé tard parce que la dernière fonctionnalité a été fusionnée le jour de la livraison.
Le nouveau paramètre de relance a saturé l'API du prestataire de paiement de requêtes.
Personne n'était d'astreinte au support le lundi matin.

Qu'est-ce que la méthode des 5 Pourquoi\u00a0?

Les 5 Pourquoi sont une technique d'analyse des causes racines. Vous énoncez un problème, vous demandez pourquoi il s'est produit, puis vous redemandez pourquoi à chaque réponse jusqu'à atteindre une cause que l'équipe peut corriger. La méthode vient du Toyota Production System, et l'exemple des 5 pourquoi de Taiichi Ohno lui-même part d'une machine arrêtée et passe par un fusible grillé, un roulement mal lubrifié et un arbre de pompe usé pour arriver à la cause racine\u00a0: la pompe n'avait pas de crépine. Ce template 5 Pourquoi déroule toute la chaîne dans une seule rétrospective TeamRetro. Écrivez l'énoncé du problème dans la première colonne et les faits dont vous disposez déjà dans la deuxième. Chacun répond ensuite au premier pourquoi, «\u00a0Pourquoi est-ce arrivé\u00a0?\u00a0», dans la troisième colonne. L'équipe regroupe les réponses et vote pour la cause la plus probable. Dans la phase Discussion, vous ouvrez cette carte et posez les quatre pourquoi suivants sous forme de fil de commentaires, chaque réponse répondant à la précédente. La dernière réponse est votre cause racine, que vous copiez dans une action avec un responsable et une échéance. Les 5 Pourquoi fonctionnent le mieux quand un problème suit une ligne principale de cause à effet\u00a0: une livraison en retard, un incident récurrent, un défaut passé entre les mailles des tests. Suivre une chaîne jusqu'au bout empêche l'équipe de se contenter de la première réponse et fait passer la discussion de «\u00a0qui s'est trompé\u00a0» à «\u00a0qu'est-ce qui, dans le processus, a permis l'erreur\u00a0». Lorsqu'un problème a de nombreuses causes contributives, cartographiez-les d'abord, puis appliquez les 5 Pourquoi aux plus probables.

Format de rétrospective 5 Pourquoi

Énoncé du problème

Que s'est-il passé exactement, où et quand ?

Mettez-vous d'accord sur un seul énoncé du problème avant que quiconque ajoute une cause, et limitez-le à une seule carte. Soyez précis : ce qui s'est passé, où, quand et dans quelle ampleur, sans hypothèse sur la cause. « La version 4.2 a été livrée avec deux jours de retard » donne à l'équipe matière à demander pourquoi. « Les livraisons, c'est le chaos » ne le permet pas.

Ce que nous savons

Quels faits et données décrivent le problème ?

Rassemblez les faits avant les causes : chronologies, métriques, logs, retours clients et changements récents. Chaque réponse de la chaîne de pourquoi doit s'appuyer sur un élément noté ici ou sur quelque chose que l'équipe peut vérifier. Si un fait manque, notez-le et faites de sa recherche une action.

Pourquoi est-ce arrivé ?

Qu'est-ce qui a directement causé le problème ?

Chaque carte ici est un premier pourquoi, une cause directe du problème énoncé. Les réponses portent sur ce qui s'est passé, pas sur qui. Après le regroupement, votez pour la cause qui explique le plus probablement le problème. Dans la phase Discussion, ouvrez la carte la plus votée et posez les quatre pourquoi suivants sous forme de fil de commentaires, chaque réponse répondant à la précédente. Si deux réponses tiennent toutes les deux à un même niveau, répondez deux fois au même commentaire et suivez chaque branche.

Dans quels cas recourir à cette rétrospective ?

  • Un problème revient sans cesse après avoir été corrigé, et vous voulez trouver la cause que la dernière correction a manquée.
  • Après un incident, un défaut non détecté ou une échéance manquée, quand l'équipe doit comprendre pourquoi avant de décider quoi changer.
  • Un sujet d'une rétrospective a recueilli la plupart des votes et mérite d'être examiné sérieusement dans une séance dédiée.
  • Le problème semble suivre une ligne principale de cause à effet. S'il a de nombreuses causes contributives, cartographiez-les d'abord avec un diagramme d'Ishikawa.

Exemples de questions brise-glace

  • Quelle petite correction avez-vous déjà faite qui a résolu un problème bien plus important ?
  • Qu'avez-vous compris seulement après avoir demandé pourquoi plusieurs fois ?

Vous souhaitez un exercice d’échauffement que votre équipe puisse pratiquer, et pas seulement répondre à voix haute ? Découvrez des brise-glace gratuits →

Idées et conseils pour votre réunion de rétrospective

  • Mettez-vous d'accord à voix haute sur l'énoncé du problème avant le brainstorming et ajoutez-le comme seule carte dans Énoncé du problème. Le template règle le brainstorming sur Afficher les idées immédiatement, pour que chacun voie chaque carte dès qu'elle est ajoutée. Vous pouvez modifier ce réglage dans les paramètres de la réunion.
  • Le template règle la phase Discussion sur Tout discuter, pour que l'énoncé du problème et les faits restent à l'écran à côté de la cause la plus votée. Vous pouvez modifier ce réglage dans les paramètres de la réunion.
  • Déroulez la chaîne sous forme de fil de commentaires sur la cause la plus votée. Cette carte est le premier pourquoi. Ajoutez un commentaire qui répond à « Pourquoi est-ce arrivé ? », répondez-y avec la réponse suivante, et continuez ainsi. Les réponses s'imbriquent sur trois niveaux : la carte, un commentaire et trois réponses vous donnent donc cinq pourquoi.
  • Arrêtez-vous quand vous atteignez une cause que l'équipe peut changer, que cela prenne trois pourquoi ou sept. S'il vous en faut un sixième, ajoutez sur la carte un nouveau commentaire qui reprend là où la dernière réponse s'est arrêtée.
  • Interrogez le processus, pas la personne. Si une réponse aboutit à « quelqu'un a fait une erreur », demandez pourquoi le processus a laissé passer cette erreur.
  • Transformez la cause racine en contre-mesure. Ouvrez le menu de la dernière réponse, choisissez Copier en action, puis attribuez à l'action un responsable et une échéance. Passez-la en revue dans la phase Actions ouvertes d'une rétrospective ultérieure pour vérifier que la correction a fonctionné.

Foire aux questions

Qu'est-ce que la technique des 5 Pourquoi de Taiichi Ohno ?
C'est la pratique qui consiste à demander pourquoi, encore et encore, lorsqu'un problème survient, afin de dépasser le symptôme évident et d'atteindre la cause racine. Elle fait partie du Toyota Production System, que Taiichi Ohno a contribué à mettre en place, et son exemple d'une machine arrêtée atteint la cause racine, une pompe sans crépine, au cinquième pourquoi.
Comment utiliser les 5 Pourquoi ?
Partez d'un problème précis, demandez pourquoi il s'est produit, puis demandez pourquoi à chaque réponse jusqu'à atteindre une cause que vous pouvez corriger. Un exemple de 5 pourquoi : la livraison était en retard parce que les tests ont commencé le jour de la livraison, parce que la dernière fonctionnalité a été fusionnée le matin même, parce qu'elle a attendu trois jours sa revue, parce qu'une seule personne peut approuver les modifications de base de données, parce que personne d'autre n'a été formé au schéma. La solution consiste à former un deuxième approbateur, pas à demander aux gens de tester plus vite.
Quelles sont les techniques d'analyse des causes racines ?
Les techniques courantes sont les 5 Pourquoi, le diagramme d'Ishikawa, l'analyse de Pareto, l'analyse par arbre de défaillances et l'analyse des changements. Les 5 Pourquoi suivent une seule chaîne de cause à effet : lorsqu'un problème a plusieurs causes contributives, cartographiez-les d'abord avec une rétrospective Fishbone (diagramme d'Ishikawa), puis appliquez les 5 Pourquoi aux plus probables.
Comment rédiger une analyse des causes racines ?
Énoncez le problème avec des faits : ce qui s'est passé, où, quand et dans quelle ampleur. Remontez les causes jusqu'à une cause racine en vérifiant chaque étape à l'aide d'éléments probants, puis consignez les actions correctives avec leurs responsables, leurs échéances et la façon dont vous vérifierez qu'elles ont fonctionné. Dans ce template, le problème et les faits sont des colonnes, le fil de commentaires sur la cause principale constitue la chaîne de pourquoi, et les actions sont les actions correctives.
Quel est le meilleur template d'analyse des causes racines ?
Cela dépend du problème. Un template 5 Pourquoi convient à un problème qui suit une ligne principale de cause à effet, et un diagramme d'Ishikawa à un problème aux nombreuses causes possibles liées aux personnes, aux processus et aux outils. Dans les deux cas, ils fonctionnent mieux quand l'équipe les remplit ensemble, avec les faits sous les yeux et un responsable pour chaque correction.

Modèles associés

Rétrospective 4L

Ce que votre équipe a aimé, appris, manqué et souhaité

Rétrospective agile

Quatre questions pour faire le point sur votre dernier sprint et planifier des changements.

Rétrospective Ancres & Moteurs

Découvrez ce qui fait avancer votre équipe et ce qui la freine

Rétrospective de collaboration inter-équipes

Réduisez les frictions entre les équipes qui dépendent les unes des autres

Êtes-vous prêt à mener cette rétrospective ?Essayez cette rétrospective en direct