La méthode des 5 pourquoi : guide pratique pour l’utiliser

Qu’est-ce que la méthode des 5 pourquoi et d’où vient-elle ?

Définition et principe de base : une analyse qui remonte aux causes racines

La méthode des 5 pourquoi est une technique de résolution de problèmes simple mais redoutablement efficace. Elle consiste à poser la question « Pourquoi ? » à plusieurs reprises, généralement cinq fois, pour passer d’un symptôme visible à la cause racine d’un dysfonctionnement. L’idée n’est pas de s’arrêter à la première explication venue, mais de creuser jusqu’à trouver la défaillance fondamentale qui, une fois corrigée, empêchera le problème de revenir.

Contrairement à ce que son nom pourrait laisser croire, le nombre « 5 » n’est pas une règle absolue. Il arrive que trois questions suffisent, ou qu’il en faille sept. L’important est d’enchaîner les « Pourquoi » jusqu’à ce que la cause identifiée soit sous contrôle, c’est‑à‑dire modifiable par une action concrète. On parle alors d’identification des causes réelles, et non de simples conséquences.

Origine : Sakichi Toyoda, Toyota et le Lean

La méthode a vu le jour dans les années 1930 chez Toyota, sous l’impulsion de Sakichi Toyoda. C’est Taiichi Ohno, le père du système de production Toyota, qui l’a popularisée en affirmant : « Répéter cinq fois pourquoi rend la nature du problème et sa solution claires. » Intégrée au Lean, au Kaizen et au Six Sigma, cette approche est aujourd’hui un outil standard de l’amélioration continue dans l’industrie, les services et même l’informatique.

Son grand avantage ? Elle ne nécessite aucun outil statistique complexe. Un tableau, un marqueur et un esprit curieux suffisent pour démarrer une analyse.

Quand utiliser les 5 pourquoi ? Les situations idéales

Problèmes récurrents, incidents qualité, bugs informatiques

La méthode s’applique à tous les contextes où l’on observe un écart entre ce qui est attendu et ce qui se produit. En production, une machine qui tombe en panne toutes les semaines ; dans un service client, des réclamations qui se répètent ; en développement logiciel, un bug qui revient sans cesse. Chaque fois, l’enjeu est de résoudre non pas le symptôme, mais le défaut profond.

Elle est particulièrement utile lorsqu’on ne dispose pas d’une grande quantité de données chiffrées ou d’un temps d’analyse très long. Attention cependant : si le problème est complexe et implique plusieurs causes entremêlées, les 5 pourquoi seuls peuvent être trop linéaires. Il faudra alors les combiner avec d’autres méthodes.

Différence avec le diagramme d’Ishikawa ou le 8D

Le diagramme d’Ishikawa (ou arbre des causes) explore les causes potentielles de façon large, en les classant par catégories (main‑d’œuvre, machine, méthode, matière, milieu, mesure). Les 5 pourquoi, eux, suivent une seule chaîne causale. L’un ne remplace pas l’autre : on peut utiliser Ishikawa pour générer des hypothèses, puis les 5 pourquoi pour creuser les pistes les plus prometteuses.

La méthode 8D, utilisée dans l’automobile, est plus lourde et structurée. Les 5 pourquoi y sont souvent intégrés comme l’une des techniques pour identifier les causes racines. En résumé : si vous avez besoin d’une analyse rapide et pragmatique, les 5 pourquoi sont parfaits.

Les étapes clés pour mettre en place l’analyse des 5 pourquoi

Étape 1 : Former une équipe pluridisciplinaire et définir précisément le problème

Un problème bien posé est à moitié résolu. Réunissez deux à quatre personnes qui connaissent le sujet : opérateurs, techniciens, responsable qualité. Notez le constat de manière factuelle : « Le taux de rebut sur la ligne A a augmenté de 15 % cette semaine. » Évitez les jugements du type « Les opérateurs sont négligents ». Restez sur l’effet mesurable.

Étape 2 : Poser le premier « Pourquoi » – remonter à la cause immédiate

Demandez à l’équipe : « Pourquoi ce taux de rebut a‑t‑il augmenté ? » La première réponse est souvent une cause directe : « Parce que la pièce se fissure en sortie de moule. » Notez‑la. Ne vous arrêtez pas là. La première cause n’est jamais la racine.

Étape 3 : Enchaîner les questions suivantes jusqu’à la cause racine

Reprenez la réponse précédente et demandez à nouveau « Pourquoi ? ». Par exemple : « Pourquoi la pièce se fissure ? » → « Parce que la température du moule est trop basse. » → « Pourquoi la température est‑elle trop basse ? » → « Parce que le thermocouple est déréglé. » → « Pourquoi est‑il déréglé ? » → « Parce que la maintenance n’a pas été faite depuis six mois. » → « Pourquoi n’a‑t‑elle pas été faite ? » → « Parce que le planning de maintenance n’inclut pas ce capteur. » Vous venez d’identifier la cause racine : un planning incomplet.

Le nombre de fois varie. Le but est d’arriver à une cause sur laquelle vous pouvez agir. Si la réponse devient « Parce que le budget est insuffisant », vous êtes peut‑être allé trop loin ou vous devez changer de levier.

Étape 4 : Valider la cause racine et définir des actions correctives

Une fois la cause profonde trouvée, vérifiez qu’elle est bien la seule responsable (par un test, une observation ou un avis d’expert). Ensuite, imaginez des solutions : mettre à jour le planning, ajouter un contrôle automatique, former le personnel. Chaque action doit être spécifique, avec un responsable et une date. Le plus important : vérifiez plus tard que le problème ne réapparaît pas. Sinon, recommencez l’analyse – la vraie cause était peut‑être ailleurs.

Exemples concrets pour comprendre la résolution de problème avec les 5 pourquoi

Exemple industriel : une machine qui tombe en panne

Problème : La presse hydraulique s’arrête trois fois par semaine.

1. Pourquoi ? → Le capteur de pression déclenche une alarme.
2. Pourquoi ? → La pression chute brutalement à cause d’une fuite.
3. Pourquoi ? → Un joint torique est usé.
4. Pourquoi ? → Le joint n’a pas été remplacé lors de la dernière maintenance.
5. Pourquoi ? → La gamme de maintenance ne mentionne pas ce joint.

Cause racine : procédure de maintenance incomplète. Solution : mettre à jour la gamme et former les techniciens. Résultat : la panne disparaît.

Exemple en service client : réclamations répétées

Problème : Des clients se plaignent de recevoir des factures avec un montant erroné.

1. Pourquoi ? → Un code promotionnel n’a pas été appliqué.
2. Pourquoi ? → Le logiciel de facturation ne prend pas en compte ce type de code.
3. Pourquoi ? → La mise à jour du système n’a pas été faite.
4. Pourquoi ? → L’équipe technique n’a pas été informée du changement.
5. Pourquoi ? → Aucun processus de communication entre le marketing et l’IT.

Cause racine : absence de canal de transmission. Solution : mettre en place une réunion hebdomadaire et un ticket dédié.

Exemple IT : un bug récurrent

Problème : L’écran de connexion plante une fois sur dix.

1. Pourquoi ? → Une variable est nulle dans le code.
2. Pourquoi ? → La fonction de validation ne gère pas les cas vides.
3. Pourquoi ? → Le développeur a oublié ce cas de test.
4. Pourquoi ? → La revue de code n’a pas relevé l’oubli.
5. Pourquoi ? → Aucune checklist de revue n’existe pour les cas limites.

Cause racine : processus de revue défaillant. Solution : créer une checklist standard et former les relecteurs.

Pièges à éviter et limites de l’outil

Subjectivité et biais de confirmation

Si vous menez l’analyse seul ou avec des personnes qui partagent votre avis, vous risquez de sauter vers une cause que vous attendiez. Impliquez toujours des gens de terrain et remettez en question chaque réponse. Demandez des preuves : « As‑tu vu la fuite toi‑même ? » ou « Peut‑on reproduire le défaut en laboratoire ? »

Quand le nombre de « Pourquoi » ne suffit pas

Certains problèmes ont plusieurs causes racines enchevêtrées. Par exemple, une panne peut venir à la fois d’un défaut de conception, d’une mauvaise maintenance et d’un manque de formation. Les 5 pourquoi, pris seuls, ne suivent qu’un fil. Dans ce cas, utilisez le diagramme d’Ishikawa en amont pour cartographier toutes les causes potentielles, puis appliquez les 5 pourquoi sur chaque branche.

De même, si la cause racine identifiée est hors de votre contrôle (politique d’entreprise, budget décidé ailleurs), vous pouvez chercher une cause plus proche ou élargir l’analyse avec un PDCA ou un DMAIC.

Erreurs fréquentes à éviter

• S’arrêter à la première réponse blâmable : « Parce que l’opérateur n’a pas vérifié. » Creusez plus loin : pourquoi n’a‑t‑il pas vérifié ?
• Poser des questions orientées : « Pourquoi n’as‑tu pas suivi la procédure ? » préférer « Que s’est‑il passé ? »
• Confondre cause et effet : reformulez toujours le problème avant de commencer.
• Négliger le suivi : une action corrective non vérifiée ne sert à rien.

Comment intégrer les 5 pourquoi dans une démarche d’amélioration continue

Lien avec le Lean, Kaizen, Six Sigma

Les 5 pourquoi sont souvent l’outil de première ligne dans les ateliers Lean. Un opérateur peut les utiliser seul pour un petit problème, ou lors d’un chantier Kaizen pour creuser une non‑conformité. Dans Six Sigma (DMAIC), ils sont placés dans la phase « Analyze » pour identifier les causes racines avant de définir des solutions.

Ils fonctionnent aussi très bien avec le PDCA : une fois la cause trouvée, on planifie les actions (Plan), on les teste (Do), on vérifie l’efficacité (Check) et on standardise (Act).

Template et checklist pour une mise en place rapide

Pour gagner du temps, créez une fiche simple avec cinq lignes « Pourquoi ? ». En face de chaque ligne, notez la réponse. À la fin, une case « Cause racine » et une case « Actions ». Vous pouvez télécharger un modèle vierge sur notre site (lien à insérer). Accrochez‑le dans l’atelier, partagez‑le sur votre intranet. Plus l’outil est accessible, plus il sera utilisé.

Conseils pour animer un atelier

• Respectez le temps : 15 à 30 minutes maximum par analyse.
• Utilisez un paperboard pour écrire visiblement chaque réponse.
• Encouragez la franchise : dites que personne n’est jugé, on cherche le système, pas les coupables.
• Quand vous arrivez à une cause racine, demandez à l’équipe : « Si on corrige ça, le problème disparaît‑il vraiment ? » Une façon simple de valider.

Rappel final : les 5 pourquoi ne sont pas une baguette magique, mais un formidable accélérateur de réflexion. Bien utilisés, ils transforment une réunion de plainte en session de résolution de problèmes efficace.