D'où sort ce chiffre totem et pourquoi la technique des 5 pourquoi nous fascine-t-elle autant ?
On est loin du compte si l'on imagine que Sakichi Toyoda, le père fondateur de Toyota Industries, a pondu ce concept un matin de 1930 après une illumination mystique. C'est l'histoire d'un pragmatisme industriel poussé à son paroxysme. L'idée était simple : ne jamais se contenter des symptômes. Si une machine s'arrête en pleine chaîne de montage à Nagoya, on ne change pas juste le fusible. On demande pourquoi il a sauté. Puis pourquoi le roulement n'était pas lubrifié. Et ainsi de suite. Mais reste que cette méthode, pourtant née dans le cambouis des usines textiles, a fini par devenir une sorte de religion laïque du conseil en stratégie.
Une invention japonaise digérée par le Lean Management
Taiichi Ohno, le véritable architecte du Système de Production Toyota, a popularisé l'usage des 5 pourquoi dans les années 1950 pour instaurer une culture de la résolution de problèmes en temps réel. Le chiffre 5 a été choisi parce qu'il correspondait, statistiquement, au nombre moyen d'étapes nécessaires pour passer d'un effet technique superficiel à une décision managériale erronée. Sauf que dans 65% des cas analysés par les experts du Lean aujourd'hui, la rigueur de l'exercice compte plus que le décompte exact des questions. Or, à force de vouloir tout packager, on a transformé un outil d'exploration en une check-list rigide que les cadres remplissent entre deux cafés, sans vraiment creuser. Est-ce vraiment efficace ? Honnêtement, c'est flou tant que l'on n'intègre pas la part d'humain et de subjectivité inhérente à chaque enquête de terrain.
La variabilité du nombre de questions : entre mythe managérial et réalité du terrain
Autant le dire clairement : la réponse à la question combien de questions faut-il poser avant d'arriver à la cause profonde du problème dépend radicalement de la complexité du système que vous analysez. Si vous gérez une fuite d'eau dans un entrepôt de 2000 mètres carrés, trois pourquoi peuvent suffire à identifier un joint défectueux acheté chez un fournisseur low-cost. Mais si vous essayez de comprendre pourquoi le taux de rétention de vos ingénieurs a chuté de 15% en un semestre, préparez-vous à une plongée bien plus profonde. Là où ça coince, c'est quand on s'entête à vouloir une linéarité qui n'existe pas. La réalité est souvent un arbre, pas une ligne droite.
Le risque de l'arrêt prématuré ou de l'acharnement thérapeutique
Il arrive un moment où la question devient absurde. Si après le septième pourquoi vous en arrivez à remettre en question les lois de la thermodynamique ou le système capitaliste mondial, c'est que vous avez dépassé la zone d'action corrective. Je pense sincèrement que le plus grand danger n'est pas de ne pas poser assez de questions, mais de poser des questions qui ne mènent à aucune action concrète. Car à quoi bon savoir que le serveur a planté à cause d'une surcharge due à une campagne marketing si, au final, on ne peut pas modifier l'infrastructure ? D'où l'importance de savoir s'arrêter quand la réponse identifiée permet enfin de mettre en place un dispositif anti-erreur (le fameux Poka-Yoke) efficace et pérenne.
L'influence de la maturité des processus sur la profondeur de l'analyse
Dans une startup créée il y a 6 mois, les causes sont souvent évidentes : manque de ressources, absence de procédures, ou simple chaos créatif. Ici, deux ou trois pourquoi suffisent généralement à pointer le manque de structure. À l'opposé, dans une multinationale certifiée ISO 9001 où chaque geste est documenté depuis 20 ans, les erreurs sont plus sournoises. Elles se cachent dans les interstices des départements. Résultat : l'enquête nécessite souvent d'aller au-delà des 5 itérations classiques pour percer la carapace bureaucratique. Les statistiques montrent que dans les environnements hautement régulés, la cause racine se niche souvent au 8ème ou 9ème niveau de causalité, là où les responsabilités deviennent diluées entre plusieurs services.
Comment savoir si vous avez réellement atteint la cause profonde ?
C'est là que le bât blesse. Beaucoup de managers pensent avoir terminé quand ils désignent un coupable (l'erreur humaine). Grave erreur \! L'erreur humaine est presque toujours un symptôme, jamais une cause profonde. Si un opérateur se trompe dans la saisie d'un code de 12 chiffres, le pourquoi n'est pas qu'il est distrait, mais que le système autorise la saisie manuelle d'une donnée aussi critique sans vérification automatique. Ça change la donne, non ? On reconnaît que l'on a touché au but quand, en supprimant la cause identifiée, on est absolument certain que le problème ne pourra plus jamais réapparaître, peu importe qui manipule la machine.