La méthode des 5 pourquoi est une technique simple d’analyse des causes racines : on énonce un problème, on demande « pourquoi cela s’est-il produit ? », on répond par un fait, puis on recommence jusqu’à atteindre une cause que l’on peut corriger durablement. Popularisée par le système de production de Toyota, elle fonctionne bien parce qu’elle ne demande ni logiciel ni statistiques, seulement quelques minutes de discussion honnête. Le chiffre cinq est une règle empirique, pas une loi : parfois trois questions suffisent, parfois il en faut sept.
Les étapes d’une analyse des 5 pourquoi
- Définissez précisément le problème. Rédigez une phrase factuelle : ce qui s’est passé, où, quand et dans quelle ampleur. « Les commandes sont un désastre » n’est pas un énoncé de problème ; « 14 commandes ont été expédiées avec plus de 2 jours de retard en septembre » en est un.
- Réunissez les bonnes personnes. Incluez ceux qui font le travail, pas seulement ceux qui l’encadrent. Trois à cinq personnes suffisent.
- Demandez pourquoi et répondez à partir de preuves. Chaque réponse doit pouvoir être vérifiée dans un enregistrement, un journal ou par l’observation, pas être une supposition.
- Continuez jusqu’à une cause de processus ou de système. Arrêtez-vous quand le « pourquoi » suivant sort de votre périmètre ou quand corriger la cause empêcherait le retour du problème.
- Testez la chaîne à l’envers. Relisez de la cause racine jusqu’au problème en ajoutant « donc » à chaque étape. Si la logique casse, une étape est fausse.
- Convenez d’actions et de responsables. Une cause racine sans action n’est qu’une histoire intéressante.
Un exemple concret
Problème : un client a reçu sa commande avec deux jours de retard.
- Pourquoi est-elle arrivée en retard ? Elle a été préparée le jour 3 au lieu du jour 1.
- Pourquoi la préparation a-t-elle été retardée ? Elle ne démarre qu’après validation manuelle de la commande.
- Pourquoi la validation a-t-elle tardé ? Le seul validateur était en congé et personne d’autre ne pouvait valider.
- Pourquoi personne d’autre ne le pouvait-il ? Le droit de validation a été attribué à une seule personne lors de la mise en place du processus.
- Pourquoi n’y avait-il pas de suppléant ? Le processus ne prévoit aucun remplacement en cas d’absence et personne n’est chargé de le revoir.
La cause racine est une lacune de processus, pas un employé négligent. La solution : désigner un validateur suppléant, fixer une règle d’escalade si une commande attend plus de 24 heures, et confier la responsabilité du processus à quelqu’un. Notez que la première réponse (« préparée en retard ») aurait conduit à une correction très différente, et plus faible.
Les erreurs courantes
Chercher un coupable
Si la chaîne se termine par « Sam a oublié », vous vous êtes arrêté trop tôt. Demandez pourquoi le processus a permis que la mémoire d’une seule personne soit l’unique garde-fou. Le blâme pousse chacun à cacher l’information, et votre prochaine analyse partira de données faussées.
S’arrêter aux symptômes
« Le rapport était en retard parce que les données étaient en retard » décrit une seconde fois le problème. Une vraie cause racine est quelque chose qui, une fois modifié, empêche la récidive. Si vous pouviez corriger la réponse et que le problème puisse revenir, poursuivez.
Le biais de la cause unique
Les incidents réels ont souvent plusieurs causes contributives, qu’une chaîne linéaire peut masquer. Si un « pourquoi » a deux réponses plausibles, suivez les deux branches et consignez chacune comme une chaîne distincte plutôt que de choisir la plus commode.
Quand préférer un diagramme d’Ishikawa
Les 5 pourquoi conviennent aux problèmes dont le fil est assez net : une échéance manquée, une erreur répétée, une défaillance isolée. Quand la cause est floue ou le problème complexe, utilisez un diagramme d’Ishikawa (en arêtes de poisson). Vous classez les causes possibles par catégories, comme les personnes, le processus, les outils, les matières, l’environnement et la mesure, puis vous creusez les plus probables. Beaucoup d’équipes combinent les deux : remue-méninges avec Ishikawa, puis 5 pourquoi sur chaque branche prometteuse.
Transformer les conclusions en actions suivies
L’analyse ne sert que si quelque chose change. Avant la fin de la réunion, convertissez chaque cause racine en action comportant ces éléments :
- Une tâche précise : « Ajouter un validateur suppléant pour les commandes » plutôt que « améliorer la couverture ».
- Un seul responsable nommé : une personne, pas une équipe.
- Une échéance : réaliste et visible de tous les intéressés.
- Un critère de réussite : comment saurez-vous que cela a marché, par exemple zéro retard d’expédition lié à la validation sur les 30 prochains jours.
- Une revue de suivi : une date pour confirmer que la correction tient et que le problème n’est pas revenu.
L’endroit où vit la liste d’actions compte autant que l’analyse. Si elle dort dans un document que personne ne rouvre, le même problème reviendra en quelques mois. FulcrumGrid Command Center est un endroit où garder ces actions avec responsables, échéances et statut en vue, afin que les points ouverts d’une analyse soient examinés avec le reste. Tout outil de suivi fiable fait l’affaire s’il est consulté régulièrement.
Questions fréquentes
Qu’est-ce que la méthode des 5 pourquoi ?
C’est une technique d’analyse des causes racines où l’on demande « pourquoi ? » plusieurs fois, en répondant chaque fois à partir de preuves, jusqu’à atteindre une cause de processus ou de système que l’on peut corriger. Cinq est un repère ; le bon nombre est celui qu’il faut.
Faut-il toujours exactement cinq pourquoi ?
Non. Arrêtez-vous quand vous atteignez une cause qui, une fois corrigée, empêcherait le retour du problème. Cela peut prendre trois questions, ou plus de cinq.
Quand utiliser plutôt un diagramme d’Ishikawa ?
Quand le problème est complexe ou la cause floue, car il permet d’explorer plusieurs catégories de causes à la fois. Vous pouvez ensuite appliquer les 5 pourquoi aux branches les plus probables.
Comment éviter de chercher un coupable ?
Demandez pourquoi le processus a permis l’erreur, pas qui l’a commise. Si votre chaîne se termine sur un nom ou un mot vague comme négligence, continuez à creuser le système autour de la personne.
Comment s’assurer que les actions sont menées à terme ?
Donnez à chaque action un responsable, une échéance et un critère de réussite, puis passez la liste en revue régulièrement. La garder dans un outil de suivi partagé plutôt que dans un document ponctuel rend le suivi bien plus probable.
FulcrumGrid Command Center
Ne laissez pas les actions correctives se perdre
FulcrumGrid Command Center permet de suivre les actions correctives avec responsables et échéances à côté de vos autres opérations, pour que les décisions de vos séances des 5 pourquoi soient vraiment menées à bien.