Mots-clés : 5 Pourquoi, analyse des causes racines, arbre des causes, INRS, postmortem, erreur humaine, Jefferson Memorial, Toyota
Dans les formations aux 5 Pourquoi, un exemple revient sans cesse. Les pierres du Jefferson Memorial s’abîment. Pourquoi ? On les lave trop souvent. Pourquoi ? À cause des fientes d’oiseaux, attirés par des araignées, elles-mêmes attirées par des moucherons, qui viennent pour les projecteurs. On allume donc les lumières une heure plus tard, et le problème disparaît. Les archives racontent autre chose. L’essai a surtout eu lieu au Lincoln Memorial, l’eau du nettoyage menaçait davantage la pierre, et l’éclairage retardé a été abandonné après les plaintes des touristes.
Une seule chaîne de pourquoi avait caché plusieurs causes et une contrainte. L’enjeu dépasse les monuments : dans un grand centre hospitalier, 302 analyses de causes ont surtout produit des actions faibles, et plusieurs types d’événements se sont répétés. Cet article reprend le cas, puis le compare à deux postmortems réels, celui de GitLab et celui d’AWS, et à l’arbre des causes de l’INRS. Vous repartirez avec des règles pour savoir quand s’arrêter, et un script qui signale les pourquoi qui s’arrêtent sur une personne ou sur un « manque ».
Le cas d’école tient en une chaîne, une action et un chiffre
En septembre 2018, un équipementier automobile, Nexteer, publie un support de
formation aux 5 Pourquoi pour ses fournisseurs. En annexe, une diapositive
intitulée « A good example » raconte l’histoire du
- Le mémorial se dégrade plus vite, parce qu’il est lavé plus souvent.
- Il est lavé plus souvent, parce qu’il reçoit plus de fientes.
- Il reçoit plus de fientes, parce que plus d’oiseaux viennent.
- Plus d’oiseaux viennent, parce que plus d’araignées vivent autour.
- Plus d’araignées vivent autour, parce que plus d’insectes volent au crépuscule.
- Plus d’insectes volent au crépuscule, parce que l’éclairage les attire.
La diapositive se demande ensuite s’il faut aller plus loin. Pourquoi la lumière attire-t-elle les insectes ? La réponse ne serait pas « within their control », donc on s’arrête. Elle envisage aussi de s’arrêter plus tôt : enduire la pierre d’un produit hydrofuge pour supporter les lavages, ou traiter les araignées aux pesticides. C’est possible, juge-t-elle, mais d’autres causes restent à considérer. Les gardes retiennent l’éclairage. Action : allumer une heure plus tard. Résultat annoncé : « Bird dropping problem reduced by 90%! »
L’histoire plaît parce que chaque réponse appelle la suivante, que l’action est
gratuite et que le résultat est un chiffre. Elle compte d’ailleurs six
pourquoi, pas cinq, ce qui n’a pas d’importance : le
Les archives montrent d’autres causes, un autre mémorial, un essai abandonné
En avril 1990, une dépêche
En mai 1992, Carla Helfferich raconte la suite dans une
Joel Gross a reconstitué toute l’affaire en 2014, dans une
L’essai d’éclairage dure six semaines, les lundis, mercredis et vendredis, avec 85 % de moucherons en moins. En janvier 1992, le Park Service étudie encore un changement permanent. En septembre 1995, l’idée est abandonnée, à cause du « nombre écrasant de plaintes de touristes venus prendre des photos ».
Le même article de 1995 décrit les autres mesures prises en cinq ans : des fils, des pics, des filets et du plastique transparent, contre les oiseaux, les araignées et les moucherons. Selon Gross, elles ont peu réduit le nettoyage.
Les sources ne s’accordent ni sur l’année de l’essai ni sur le chiffre : 90 % selon la chronique de 1992, 85 % selon Gross. Elles s’accordent sur l’essentiel, résumé dans ce tableau :
| Point | Version racontée | Archives |
|---|---|---|
| Lieu | Jefferson Memorial | Surtout le Lincoln Memorial |
| Menace | Lavages fréquents | L’eau du lavage qui pénètre la pierre fissurée |
| Ce qui est mesuré | Fientes, −90 % | Moucherons morts, −85 % ou −90 % |
| Statut | Solution | Essai de six semaines |
| Suite | Problème réglé | Abandonné en 1995, après les plaintes des touristes |
Personne n’a mesuré une baisse de 90 % des fientes. Et l’action retenue n’a jamais été appliquée durablement.
Une chaîne de pourquoi choisit une branche et cache les autres
La chaîne racontée n’est pas fausse : chacun de ses maillons est plausible, et l’essai a bien réduit les moucherons. Son défaut est ce qu’elle laisse de côté. À chaque pourquoi, elle ne retient qu’une réponse. Or la pierre ne s’abîme pas seulement parce qu’on la lave : il faut aussi que l’eau entre dans le marbre, et qu’elle y apporte des polluants. La figure compare les deux lectures, étape par étape.
- La chaîne racontée en formation : sept faits, une seule branche, et une action sur l'éclairage. L'arbre documenté suit la même colonne, avec un maillon de plus, l'eau dans le marbre, et les oiseaux et les araignées réunis.
- Les archives ajoutent deux branches. La pierre s'érode parce que l'eau entre dans le marbre ET que l'air apporte des polluants. L'eau entre parce qu'on lave à grande eau ET que le marbre est fissuré.
- Une contrainte bloque l'action choisie : les touristes veulent photographier le mémorial éclairé.
- En parallèle, le Park Service agit sur une autre branche : fils, pics et filets contre les oiseaux et les araignées, avec peu d'effet sur le nettoyage.
Ce que la chaîne ne voit pas a deux origines. D’abord, elle cherche une cause
et s’arrête dès qu’elle en tient une. La fiche de l’
Même l’exemple d’Ohno n’échappe pas à la critique. Mark Graban montre en 2026,
sur le
GitLab et AWS ont corrigé les conditions, pas la personne
Le 31 janvier 2017, un ingénieur de GitLab supprime le répertoire de données de
la base principale, au lieu de celui de la base secondaire. GitLab.com reste
indisponible environ 18 heures. Le
La première explique la panne en cinq pourquoi. Le répertoire a été supprimé par accident. Il fallait le vider parce que la réplication s’était arrêtée et que reconstruire la base secondaire exigeait un répertoire vide, une étape ni automatisée ni bien documentée. La réplication s’était arrêtée à cause d’un pic de charge. Le pic venait de deux choses à la fois : une hausse du spam, et un traitement qui supprimait un employé de GitLab et ses données. L’employé avait été signalé pour abus par un troll, dans un système où il était trop facile d’ignorer les détails d’un signalement.
La seconde chaîne explique pourquoi la restauration a pris plus de 18 heures, en
huit pourquoi. Les sauvegardes pg_dump échouaient sans bruit : elles
utilisaient PostgreSQL 9.2 contre une base en 9.6. Les courriels d’échec étaient
rejetés faute de signature
GitLab ne s’arrête pas à l’erreur de l’ingénieur, qui n’est que le premier pourquoi. Et ses actions visent chacune une cause de la chaîne :
| Pourquoi du postmortem | Action de GitLab |
|---|---|
| Répertoire du primaire supprimé par accident | Invite de commande plus distincte d’un hôte à l’autre |
| Reconstruction du secondaire ni automatisée ni documentée | Documentation et runbooks de réplication |
Sauvegardes pg_dump en échec silencieux | Surveillance des sauvegardes avec Prometheus |
| Procédure de sauvegarde jamais testée, sans responsable | Tests automatiques de restauration, un responsable désigné |
Un mois plus tard, le 28 février 2017, le service S3 d’AWS tombe dans la région
us-east-1. Le
S’arrêter sur une personne ou sur un manque ferme l’analyse
Deux règles reviennent dans les méthodes sérieuses. La première interdit de
s’arrêter sur une personne. Le centre de sécurité des patients des anciens
combattants américains (
La seconde interdit les causes formulées comme un manque. La règle 2 du VA
exclut les descriptions négatives des énoncés de cause. L’INRS dit la même chose
en français. Dans son guide
Le postmortem de GitLab contient justement un fait négatif : une étape « ni automatisée ni documentée ». La formule désigne déjà le remède, automatiser et documenter, au lieu du fait : un ingénieur reconstruisait la base secondaire à la main. Le remède est peut-être le bon, mais la formulation empêche d’en envisager un autre.
Derrière ces deux règles, il y a une idée plus large. Richard Cook l’écrit en
titre de la septième thèse de
L’arbre des causes remplace « pourquoi ? » par « qu’a-t-il fallu ? »
En France, l’
L’arbre se construit à partir du dommage, avec deux questions pour chaque fait :
- « Qu’a-t-il fallu pour que le fait (Y) apparaisse ? »
- « (X) a-t-il été nécessaire à lui seul pour que (Y) apparaisse ? Ou, en d’autres termes, a-t-il fallu autre chose ? »
La seconde question est celle qui manque à la chaîne du mémorial. Elle
transforme chaque maillon en nœud, relié à ses causes par un enchaînement, une
John Allspaw arrive au même endroit par l’informatique. Dans
Un script repère les pourquoi qui s’arrêtent trop tôt
Ces règles sont assez mécaniques pour qu’un script en vérifie une partie. Le programme ci-dessous représente une analyse comme un arbre : chaque fait pointe vers ses causes. Il signale quatre choses :
- les maillons qui n’ont qu’une seule cause, où il faut demander « a-t-il fallu autre chose ? » ;
- les faits négatifs (« pas », « ni », « aucun », « absence », « manque »…) ;
- les jugements (« trop », « mal », « mauvais », « insuffisant ») ;
- les erreurs humaines sans cause antérieure, selon la règle 3 du VA.
Il l’applique à quatre analyses : la chaîne racontée du mémorial, une chaîne naïve sur la panne de S3, construite pour l’exemple, la première chaîne de GitLab, et l’arbre documenté du mémorial. Le bouton Run l’exécute dans votre navigateur.
import re
NEGATIF = re.compile(r"\b(pas|ni|aucun|aucune|absence|manque|sans|jamais)\b")
HUMAIN = re.compile(r"par accident|erreur humaine|inattention|négligence|oubli")
JUGEMENT = re.compile(r"\b(trop|mal|mauvais|insuffisant)\b")
def verifier(nom, arbre):
"""Vérifie une analyse : chaque clé est un fait, sa valeur ses causes."""
faits = set(arbre) | {c for causes in arbre.values() for c in causes}
maillons = [fait for fait in faits if arbre.get(fait)]
uniques = [fait for fait in maillons if len(arbre[fait]) == 1]
print(f"{nom} : {len(faits)} faits")
print(f" ! une seule cause : {len(uniques)} maillons sur {len(maillons)}")
for fait in sorted(faits):
if NEGATIF.search(fait):
print(f" ! fait négatif : « {fait} »")
if JUGEMENT.search(fait):
print(f" ! jugement : « {fait} »")
if HUMAIN.search(fait) and not arbre.get(fait):
print(f" ! s'arrête sur une erreur humaine : « {fait} »")
def chaine(*faits):
"""Transforme une chaîne de pourquoi en arbre à une seule branche."""
return {effet: [cause] for effet, cause in zip(faits, faits[1:])}
verifier("Mémorial, version racontée", chaine(
"Le mémorial se dégrade plus vite",
"Il est lavé plus souvent",
"Il reçoit plus de fientes",
"Plus d'oiseaux viennent",
"Plus d'araignées vivent autour",
"Plus d'insectes volent au crépuscule",
"L'éclairage attire les insectes",
))
verifier("S3, chaîne naïve", chaine(
"S3 indisponible dans us-east-1",
"Plus de serveurs retirés que prévu",
"Une entrée mal saisie, par erreur humaine",
))
verifier("GitLab, problème 1", {
"GitLab.com indisponible environ 18 heures": [
"Répertoire du primaire supprimé par accident"],
"Répertoire du primaire supprimé par accident": [
"Secondaire à reconstruire, étape ni automatisée ni documentée"],
"Secondaire à reconstruire, étape ni automatisée ni documentée": [
"Réplication arrêtée par un pic de charge"],
"Réplication arrêtée par un pic de charge": [
"Hausse du spam", "Suppression en cours d'un employé"],
"Suppression en cours d'un employé": [
"Signalement d'un troll, détails trop faciles à ignorer"],
})
verifier("Mémorial, arbre documenté", {
"Pierre qui s'érode": ["Eau infiltrée dans le marbre", "Polluants de l'air"],
"Eau infiltrée dans le marbre": ["Lavages à grande eau", "Fissures du marbre"],
"Lavages à grande eau": ["Fientes et insectes à nettoyer"],
"Fientes et insectes à nettoyer": ["Oiseaux et araignées"],
"Oiseaux et araignées": ["Moucherons au crépuscule"],
"Moucherons au crépuscule": ["Projecteurs allumés au crépuscule"],
})Voici sa sortie, avec Python 3.14 :
Mémorial, version racontée : 7 faits
! une seule cause : 6 maillons sur 6
S3, chaîne naïve : 3 faits
! une seule cause : 2 maillons sur 2
! jugement : « Une entrée mal saisie, par erreur humaine »
! s'arrête sur une erreur humaine : « Une entrée mal saisie, par erreur humaine »
GitLab, problème 1 : 7 faits
! une seule cause : 4 maillons sur 5
! fait négatif : « Secondaire à reconstruire, étape ni automatisée ni documentée »
! jugement : « Signalement d'un troll, détails trop faciles à ignorer »
Mémorial, arbre documenté : 9 faits
! une seule cause : 4 maillons sur 6La chaîne racontée du mémorial passe toutes les règles de forme. Elle n’a ni manque, ni jugement, ni coupable. Son seul défaut est structurel : six maillons sur six n’ont qu’une cause. C’est pourquoi elle semble si propre. La chaîne naïve de S3 cumule les défauts : elle juge (« mal saisie ») et s’arrête sur l’erreur humaine. GitLab, lui, continue après l’accident, et l’un de ses maillons a deux causes. Il garde un fait négatif et un jugement, que la reformulation de l’INRS corrigerait.
Le script vérifie la forme, pas la vérité. Une analyse peut passer toutes les règles et rester fausse. Ses expressions régulières se trompent aussi dans les deux sens. Elles signalent « le pas de vis est usé », où « pas » est un nom, et laissent passer « défaut de formation », un manque formulé sans négation. Le script dit où regarder, pas quoi conclure.
Une analyse se juge à la force de ses actions, pas au nombre de pourquoi
Une analyse de causes sert à choisir des actions. C’est donc sur ces actions
qu’il faut la juger. En 2017, Kellogg et ses coauteurs ont examiné 302 analyses
de causes, menées en huit ans dans un grand centre hospitalier universitaire.
Leur étude est parue dans
GitLab et AWS ont choisi des actions plus fortes : un outil qui refuse les retraits dangereux, des tests automatiques de restauration, un responsable nommé. Au mémorial, l’éclairage retardé était une action forte, puisqu’elle supprimait une condition. Elle a échoué sur une contrainte que l’analyse n’avait pas cherchée. Les fils et les filets, qui laissaient la condition en place, ont peu changé le nettoyage.
De ces cas et de ces sources, on peut tirer des règles d’arrêt :
- Le nombre ne compte pas. On s’arrête quand on atteint un fait sur lequel agir, que ce soit au troisième pourquoi ou au huitième.
- Écrire des faits. Pas de manque, pas de jugement : « il parlait avec un collègue », pas « il ne faisait pas attention ».
- Ne jamais s’arrêter sur une personne. Toute erreur humaine a une cause antérieure, comme la commande de GitLab ou l’outil d’AWS.
- Demander à chaque maillon : a-t-il fallu autre chose ? C’est ce qui transforme la chaîne en arbre.
- Vérifier chaque réponse sur place. Les consultants des mémoriaux ont trouvé l’eau en examinant la pierre, pas en déduisant.
- Chercher les contraintes avant de choisir. Une action qui supprime une cause peut se heurter à un autre objectif, comme les photos des touristes.
Au mémorial, il manquait une question, pas un pourquoi de plus
Le cas d’école n’a pas la fin qu’on raconte. Les moucherons ont bien diminué, pendant un essai de quelques semaines mené surtout au Lincoln Memorial, puis la solution a été abandonnée. La pierre, elle, souffrait surtout de l’eau. Chaque pourquoi de la chaîne était juste. Ce qui manquait, c’est la question suivante, « a-t-il fallu autre chose ? », qui aurait montré l’eau, les fissures, les polluants et les touristes avant de choisir l’éclairage.
À retenir, et à appliquer au prochain postmortem : à chaque pourquoi, demandez
aussi « a-t-il fallu autre chose ? », et n’arrêtez jamais l’analyse sur une
personne ou sur un manque. Chaque cause retenue devient ensuite une ligne d’un
plan d’action
Références
- Le cas du mémorial : Nexteer,
Supplier 3L5Y Trainingnexteer.comSupport de formation de Nexteer aux 5 Pourquoi (2018). (2018) ; Associated Press,« Toxic effects of nature are aging Lincoln and Jefferson memorials »deseret.comDeseret News, 17 avril 1990. , Deseret News, 1990 ; C. Helfferich,« Unfortunately ecological Abe »gi.alaska.eduAlaska Science Forum, université d'Alaska à Fairbanks, 1992. , Alaska Science Forum, 1992 ; J. Gross,« 5 Whys Folklore: The Truth Behind a Monumental Mystery »thekaizone.comThe KaiZone, 2014 (source secondaire). , The KaiZone, 2014 (source secondaire, qui cite le New York Times de janvier 1992 et le Chicago Tribune de septembre 1995). - La méthode et ses critiques : Lean Enterprise Institute,
5 Whyslean.orgLexique du Lean Enterprise Institute : 5 Whys. , d’après T. Ohno, Toyota Production System, Productivity Press, 1988, p. 17 ; IHI,5 Whys: Finding the Root Causeihi.orgInstitute for Healthcare Improvement : 5 Whys, Finding the Root Cause. ; M. Paradies,« Teruyuki Minoura (Toyota exec) talks about problems with 5 Whys »taproot.comTapRooT, 2007 (source secondaire). , TapRooT, 2007 (source secondaire) ; M. Graban,« Ohno’s 5 Whys Example Is Actually Seven Whys »leanblog.orgLean Blog, 2026. , Lean Blog, 2026 ; A. J. Card,« The problem with ‘5 whys’ »doi.orgBMJ Quality & Safety 26(8), 2017, p. 671-677. , BMJ Quality & Safety, 2017. - Postmortems : GitLab,
« Postmortem of database outage of January 31 »about.gitlab.comGitLab, 10 février 2017. , 2017 ; Amazon Web Services,« Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region »aws.amazon.comAWS, 2017. , 2017. - Causalité et erreur humaine : New Jersey Department of Health,
RCA trainingnj.govFormation aux analyses de causes, 2008. (2008), qui reprend les règles du VA NCPS ; Betsy Lehman Center,« The 5 rules of causation »navigator.betsylehmancenterma.govBetsy Lehman Center : The 5 rules of causation. ; R. I. Cook,How Complex Systems Failhow.complexsystems.failHow Complex Systems Fail, 1998. (1998) ; J. Allspaw,« The Infinite Hows (or, the Dangers Of The Five Whys) »kitchensoap.comKitchen Soap, 2014. , 2014, qui cite S. Dekker. - Arbre des causes : INRS,
La méthode de l’arbre des causes. L’analyse de l’accident du travailinrs.frINRS, ED 6163, 3e édition, 2025. , ED 6163, 3e édition, 2025. - Force des actions : K. M. Kellogg et al.,
« Our current approach to root cause analysis: is it contributing to our failure to improve patient safety? »pubmed.ncbi.nlm.nih.govBMJ Quality & Safety 26(5), 2017, p. 381-387. , BMJ Quality & Safety, 2017.