On nous a vendu cet outil comme le remède miracle à la superficialité. Mais, entre nous, poser cinq fois la même question à un ingénieur fatigué ou à un manager sous pression ne garantit absolument pas d'arriver à la "cause racine". C'est même souvent l'inverse qui se produit : on finit par valider ses propres préjugés sous couvert d'une démarche structurée. Et c'est précisément là que le bât blesse.
Les racines industrielles d'un outil devenu obsolète
Pour comprendre là où ça coince, il faut remonter aux origines de la méthode. Sakichi Toyoda, le fondateur de Toyota, a conçu cette approche pour le monde de la production physique. À l'époque, si une machine s'arrêtait, c'était généralement à cause d'un problème mécanique identifiable. Un engrenage cassé, un manque de lubrification, un moteur en surchauffe. Dans ce contexte de déterminisme industriel, la linéarité avait du sens. On cherchait une pièce défectueuse, on la remplaçait, et l'affaire était classée.
Sauf que nous ne sommes plus en 1950. Aujourd'hui, 85 % de nos problèmes opérationnels dans le secteur tertiaire ou technologique ne sont pas liés à une rupture mécanique, mais à des défaillances de communication, des bugs logiciels imprévisibles ou des processus mal alignés. Le monde a changé, mais nos outils de diagnostic sont restés bloqués à l'ère de la vapeur. Je reste convaincu que s'obstiner à utiliser les 5 pourquoi dans un environnement agile, c'est comme essayer de réparer un smartphone avec un marteau : on risque surtout de casser ce qui fonctionnait encore.
Le mythe de la cause racine unique
Le terme même de "cause racine" est un poison sémantique. Il suggère qu'en creusant assez profondément, on finira par trouver une seule et unique source au mal. Or, dans un système complexe, il n'y a jamais UNE cause. Il y a une convergence de conditions favorables à l'échec. Imaginez un crash informatique majeur : est-ce la faute du développeur qui a poussé le code ? De l'outil de test qui n'a rien vu ? Du manager qui a réduit les délais de 20 % ? Ou de la latence réseau qui a grimpé à 150ms ce matin-là ? La méthode des 5 pourquoi vous force à choisir un seul chemin, sacrifiant tous les autres sur l'autel de la simplicité.
Une structure pensée pour la répétition, pas pour l'innovation
Toyota utilisait cet outil pour la standardisation. Le but était que chaque ouvrier puisse diagnostiquer un problème sans avoir besoin d'un ingénieur. C'est noble, certes. Mais cette standardisation tue l'exploration. En limitant l'analyse à une suite de "pourquoi", on empêche l'émergence de questions plus riches comme "comment cela s'est-il produit ?" ou "qu'est-ce qui a permis à cette erreur de ne pas être détectée plus tôt ?". Reste que pour beaucoup de chefs d'entreprise, la rapidité de la méthode l'emporte sur la pertinence du résultat.
Le piège de la linéarité : pourquoi le "pourquoi" nous ment
Le plus gros défaut de la méthode réside dans sa forme même. C'est une ligne. Or, la causalité est un arbre, voire une toile d'araignée. En forçant l'analyste à suivre un fil unique, on crée un biais de sélection massif. Si vous commencez votre premier "pourquoi" par une erreur humaine, vous finirez inévitablement par conclure qu'il faut "mieux former le personnel" ou "être plus vigilant". C'est d'une pauvreté affligeante.
Prenez un exemple concret que j'ai observé récemment dans une startup de la FinTech. Un serveur tombe. Pourquoi ? La base de données était saturée. Pourquoi ? Une requête de log tournait en boucle. Pourquoi ? Le script n'avait pas de limite de temps. Pourquoi ? Le développeur a oublié de la paramétrer. Pourquoi ? Il était pressé par la mise en production. Résultat : on blâme le stress ou le développeur. On a totalement ignoré que l'architecture système était sous-dimensionnée de 40 %, que le monitoring n'a pas envoyé d'alerte et que le processus de revue de code avait été court-circuité par la direction. On a suivi une ligne, et on a raté la forêt.
L'influence fatale de l'animateur sur le résultat
La méthode est incroyablement subjective. Selon la personne qui pose les questions, le point d'arrivée sera totalement différent. Un expert technique s'arrêtera sur un problème de firmware, tandis qu'un RH pointera un manque de cohésion. Cette variabilité prouve que l'outil n'est pas scientifique. C'est un exercice de narration où l'on construit une histoire qui nous arrange. Bref, on ne découvre pas la vérité, on invente une explication plausible qui ne fâche personne (ou qui désigne un coupable idéal).
L'absence de reproductibilité des analyses
Si vous donnez le même incident à trois groupes différents utilisant les 5 pourquoi, vous obtiendrez trois "causes racines" distinctes. C'est là où ça devient gênant pour une méthode censée apporter de la rigueur. Dans une étude portant sur la sécurité industrielle, il a été démontré que la divergence des résultats augmentait avec la complexité du système. Plus le problème est grave, moins la méthode est fiable. C'est un comble, non ?
Le biais de confirmation déguisé en logique
Nous avons tous une idée préconçue de la cause d'un problème avant même de commencer l'analyse. Les 5 pourquoi servent alors d'alibi intellectuel pour confirmer ce que l'on pensait déjà. On oriente les réponses pour arriver à la conclusion souhaitée. C'est humain, mais c'est l'opposé d'une démarche d'amélioration continue sérieuse.
La limite psychologique des cinq étapes
Pourquoi cinq ? Pourquoi pas trois ou douze ? Ce chiffre est totalement arbitraire. Parfois, la solution est évidente au bout du deuxième pourquoi. Parfois, il en faudrait vingt pour commencer à effleurer la complexité organisationnelle. En fixant cet horizon de cinq, on crée une pression pour s'arrêter là, même si on n'a fait que gratter la surface. On finit par inventer des causes bidons pour remplir les dernières cases du formulaire.
L'effet tunnel ou comment confirmer ses propres préjugés
Quand on utilise cet outil, on entre dans un tunnel. On ne regarde plus à gauche ou à droite. On ne se demande pas quelles conditions étaient présentes alors qu'elles n'auraient pas dû l'être. On cherche uniquement une séquence d'événements. C'est ce qu'on appelle la pensée séquentielle, et c'est le pire ennemi de la résilience organisationnelle. Le problème, c'est que cette méthode ne permet pas de comprendre les couplages serrés entre les différents services d'une entreprise.
Imaginez un service client qui explose suite à une promotion mal gérée. Si vous demandez pourquoi, on vous dira que le marketing n'a pas prévenu le support. Mais si vous creusez vraiment, vous verrez que le budget de communication a été validé le vendredi soir pour un lancement le lundi, que l'outil de CRM était en maintenance et que le responsable du support était en congé sans remplaçant. Les 5 pourquoi vont isoler un de ces facteurs et ignorer les autres. On traite un symptôme, pas la pathologie globale.
Pourquoi vos équipes détestent cet exercice (et elles ont raison)
Si vous voulez plomber l'ambiance d'une réunion, lancez un "5 pourquoi" après un échec. Pour les employés, cela ressemble souvent à un interrogatoire de police. Chaque "pourquoi" est perçu comme une accusation déguisée. Au lieu de favoriser l'apprentissage, on déclenche des mécanismes de défense. Les gens commencent à cacher des informations ou à rejeter la faute sur les départements voisins. C'est le début de la politique de bureau et la fin de la transparence.
Là où ça devient vraiment toxique, c'est quand la méthode est utilisée pour désigner un responsable humain. "Pourquoi l'erreur a-t-elle eu lieu ? Parce que Jean a cliqué sur le mauvais bouton." À partir de là, la messe est dite. On oublie de se demander pourquoi le système a permis à Jean de faire une erreur fatale avec un simple clic. Une organisation saine devrait protéger ses membres contre leurs propres erreurs inévitables, pas les pointer du doigt avec une méthode datant de l'époque des usines de coton.
La quête illusoire de la "cause unique" dans un monde systémique
Le monde moderne est régi par la complexité. Un système complexe est un système où le tout est supérieur à la somme des parties. Dans un tel environnement, les échecs ne sont pas causés par des composants défaillants, mais par des interactions inattendues entre des composants qui fonctionnent pourtant normalement. C'est ce que l'expert en sécurité Charles Perrow appelait les "accidents normaux".
Les 5 pourquoi sont incapables de capturer ces interactions. Ils cherchent un coupable (une pièce, une personne, un logiciel) alors qu'il faudrait analyser des relations. L'analyse systémique nous apprend que la performance d'un système dépend de la qualité de ses interfaces. Si vous passez 100 % de votre temps à chercher des "causes racines" individuelles, vous ne verrez jamais les failles structurelles de votre organisation. C'est un peu comme essayer de comprendre pourquoi une forêt brûle en analysant chaque arbre séparément sans regarder la météo ou la gestion des sols.
Les 4 erreurs fatales qui ruinent vos post-mortems
Malgré ses défauts, beaucoup s'entêtent à utiliser cet outil. Si vous faites partie de ceux-là, sachez que vous tombez probablement dans l'un de ces quatre pièges classiques qui rendent l'exercice totalement inutile, voire contre-productif pour la sécurité de vos opérations.
D'abord, il y a l'arrêt prématuré. On s'arrête dès qu'on trouve une explication qui nous convient politiquement. Ensuite, le saut logique : on passe d'un pourquoi à un autre sans preuve factuelle, juste par intuition. La troisième erreur est de se focaliser sur l'individu plutôt que sur le processus. Enfin, la plus grave : ne pas vérifier si la "cause" identifiée, une fois corrigée, empêche réellement le problème de revenir. Spoiler : souvent, non.
Erreur 1 : Le biais de l'expert
L'expert qui mène l'analyse croit déjà connaître la réponse. Il utilise les questions pour amener le groupe à sa propre conclusion. C'est une forme de manipulation intellectuelle qui tue toute intelligence collective. J'ai vu des directeurs techniques orienter des 5 pourquoi pour justifier l'achat d'un nouveau logiciel dont ils avaient envie depuis des mois. Pratique, mais malhonnête.
Erreur 2 : La confusion entre corrélation et causalité
Ce n'est pas parce que deux événements se suivent qu'ils sont liés par un rapport de cause à effet. La méthode des 5 pourquoi pousse à créer ces liens artificiels. "Pourquoi le serveur a crashé ? Parce qu'il y avait une mise à jour Windows." Peut-être, ou peut-être que c'était juste une coïncidence et que la vraie raison était une surcharge électrique. La méthode ne demande jamais de preuves statistiques ou de vérifications croisées.
Quelles alternatives pour une vraie résolution de problèmes ?
Si on range les 5 pourquoi au musée, qu'est-ce qu'on utilise à la place ? Il existe des outils bien plus robustes qui acceptent la complexité au lieu de la nier. Le diagramme d'Ishikawa (ou arête de poisson) est déjà un pas en avant, car il permet de visualiser plusieurs catégories de causes simultanément. Mais on peut aller plus loin avec des méthodes comme l'analyse de barrières ou la méthode STAMP (System-Theoretic Accident Model and Processes).
Ces approches ne cherchent pas "pourquoi", mais "comment". Elles analysent les contrôles qui ont échoué et les marges de sécurité qui se sont évaporées. C'est beaucoup plus long, certes. Cela demande plus de neurones. Mais au moins, les solutions qui en découlent ont une chance réelle de rendre le système plus solide sur le long terme. On n'est plus dans le sparadrap, on est dans la chirurgie structurelle.
Le diagramme d'Ishikawa : une vision multidimensionnelle
Contrairement à la ligne droite des 5 pourquoi, Ishikawa force à regarder dans plusieurs directions : Main-d'œuvre, Matériel, Méthode, Milieu, Matière. Cela permet de voir que le problème de Jean (Main-d'œuvre) est peut-être lié à un outil mal conçu (Matériel) et à une température trop élevée dans le bureau (Milieu) qui a réduit sa concentration. C'est déjà beaucoup plus proche de la réalité du terrain.
La méthode de l'arbre des causes
Utilisée dans l'industrie aéronautique et nucléaire, cette méthode part de l'accident et remonte dans le temps en ouvrant des branches à chaque fois que plusieurs faits ont été nécessaires pour produire l'événement suivant. C'est visuel, c'est factuel, et ça interdit de se contenter d'une seule explication. C'est l'outil de prédilection pour ceux qui ne veulent pas se mentir.
Questions fréquentes sur l'analyse de cause racine
Peut-on combiner les 5 pourquoi avec d'autres méthodes ?
C'est possible, mais risqué. Souvent, la simplicité des 5 pourquoi finit par "contaminer" les autres outils. Si vous l'utilisez, faites-le uniquement pour des problèmes triviaux et techniques, jamais pour des problèmes humains ou organisationnels. Reste que, quitte à investir du temps, autant utiliser un outil sérieux dès le départ.
Pourquoi la méthode est-elle encore si populaire en entreprise ?
Parce qu'elle ne coûte rien et qu'elle donne l'illusion de la maîtrise. Elle rassure les managers qui veulent des réponses rapides et des plans d'action immédiats. C'est le "fast-food" du management : c'est facile à consommer, ça remplit l'estomac sur le moment, mais c'est mauvais pour la santé de l'entreprise à long terme.
Existe-t-il des cas où les 5 pourquoi sont pertinents ?
Oui, pour des systèmes linéaires simples. Si votre grille-pain ne marche plus, les 5 pourquoi vous aideront. Si votre chaîne de production de stylos s'arrête parce qu'une courroie a lâché, ça marche aussi. Dès que l'humain ou le logiciel entre en jeu, la méthode devient obsolète.
Le verdict : l'essentiel pour ne plus se tromper de diagnostic
Pour finir, il est temps d'admettre que la méthode des 5 pourquoi est un vestige d'un monde qui n'existe plus. Elle nous donne un faux sentiment de sécurité en simplifiant à l'extrême des situations qui exigeraient de la nuance et de la profondeur. En cherchant une cause racine unique, on s'aveugle volontairement sur la réalité de nos organisations. Le problème n'est pas tant l'outil lui-même, mais l'usage paresseux qu'on en fait pour éviter de poser les vraies questions, celles qui dérangent.
Si vous voulez vraiment progresser, arrêtez de demander "pourquoi" comme un enfant de quatre ans. Commencez à demander "quelles sont les conditions qui ont rendu cet échec possible ?". Changez votre focale. Passez de la recherche de coupables à la compréhension des systèmes. C'est moins confortable, c'est plus lent, mais c'est le seul chemin vers une véritable résilience. Autant dire que le chemin est encore long pour beaucoup de boîtes, mais le jeu en vaut la chandelle.
Voici les points de vigilance pour vos prochaines analyses :
- Ne vous contentez jamais d'une seule chaîne de causalité pour un incident majeur.
- Bannissez l'erreur humaine comme conclusion finale d'une investigation.
- Impliquez des personnes qui n'étaient pas directement liées à l'incident pour éviter les biais.
- Vérifiez systématiquement les données chiffrées avant de valider une hypothèse.
- Acceptez que certains problèmes n'ont pas de solution simple ou unique.
Honnêtement, c'est flou pour beaucoup de gens, mais la gestion de l'échec est une compétence en soi. Elle ne se résume pas à une liste de questions pré-formatées. Elle demande de l'empathie, une vision systémique et une bonne dose d'honnêteté intellectuelle. Soit dit en passant, ceux qui prétendent le contraire ont souvent quelque chose à vous vendre, ou quelque chose à se reprocher.