Un incident se répète, les équipes corrigent dans l’urgence, puis le même problème revient quelques jours plus tard. La méthode des 5 pourquoi aide à dépasser le symptôme pour remonter vers une cause sur laquelle l’organisation peut réellement agir, aussi bien en qualité qu’en management IT ou en gestion de projet. Je présente ici son fonctionnement, une démarche concrète, un exemple dans un service numérique et les limites à connaître.
Une méthode simple pour traiter les causes plutôt que les symptômes
- Objectif : identifier la cause profonde d’un problème au lieu de corriger uniquement ses effets.
- Principe : poser plusieurs fois la question « pourquoi ? », chaque réponse servant de point de départ à la suivante.
- Règle pratique : cinq questions constituent un repère, pas une obligation mécanique.
- Bon usage : travailler à partir de faits vérifiés et avec les personnes qui connaissent réellement le processus.
- Limite : un problème complexe peut avoir plusieurs branches causales et demander un diagramme d’Ishikawa ou une analyse de données.
Ce que cherche réellement la méthode des cinq pourquoi
La question de départ doit décrire un écart observable, pas désigner un responsable. « Le serveur est tombé à 10 h 15 » est exploitable. « L’équipe infrastructure a mal travaillé » enferme immédiatement l’analyse dans un jugement et empêche de regarder le processus.
On part ensuite du fait constaté et l’on remonte progressivement la chaîne de causes. Chaque réponse doit être suffisamment précise pour être vérifiée. Si l’on répond « parce que le système est mal géré », je considère que l’on n’a pas encore avancé : il faut préciser quel réglage, quelle décision, quelle absence de contrôle ou quelle étape du processus a permis l’incident.
Pourquoi le chiffre cinq n’est pas une règle rigide
Le nom de la méthode vient d’un constat pratique : cinq itérations suffisent souvent pour passer d’un effet visible à une cause organisationnelle ou technique. Dans certains cas, trois questions suffisent. Dans d’autres, il en faudra sept ou huit, notamment lorsque plusieurs niveaux de procédure, d’outillage et de gouvernance interviennent.
Je recommande de s’arrêter lorsque l’équipe atteint une cause sur laquelle elle peut agir et dont la correction réduit réellement le risque de récidive. Une réponse qui accuse une personne n’est généralement pas une cause racine. Il faut demander ce qui, dans le système, a rendu l’erreur possible ou difficile à détecter.
Comment mener l’analyse sans tourner en rond
Une séance efficace tient souvent en 30 à 60 minutes pour un problème circonscrit. Elle réunit idéalement trois à six personnes, avec un animateur capable de maintenir le débat sur les faits et de reformuler les réponses trop vagues.
- Décrire le problème avec une date, un lieu, un impact et un écart par rapport à la situation attendue.
- Rassembler les faits disponibles : journaux techniques, tickets, mesures, captures, procédures ou témoignages concordants.
- Poser le premier pourquoi à partir du problème, sans chercher immédiatement un coupable.
- Vérifier chaque réponse avant de l’utiliser comme nouvelle question.
- Identifier la cause maîtrisable, c’est-à-dire celle sur laquelle une action préventive est possible.
- Décider, attribuer et contrôler l’action avec un responsable, une échéance et un indicateur de résultat.
Je conseille de noter l’analyse sous forme d’une chaîne très visible. Pour chaque niveau, on peut ajouter une colonne « preuve » et une colonne « action ». Cela évite les raisonnements séduisants mais invérifiables, un piège fréquent lorsque l’équipe connaît déjà une solution qu’elle souhaite justifier.
| Élément | Question utile | Exemple de preuve |
|---|---|---|
| Problème | Que s’est-il passé exactement ? | 18 tickets clients reçus entre 9 h et 11 h |
| Cause immédiate | Pourquoi l’écart est-il apparu ? | Une version erronée a été déployée |
| Cause du processus | Pourquoi cette erreur n’a-t-elle pas été détectée ? | Aucun test automatique sur le scénario concerné |
| Cause organisationnelle | Pourquoi ce contrôle n’existe-t-il pas ? | Le périmètre des tests n’a jamais été défini |
| Action | Que change-t-on durablement ? | Ajouter le test et l’intégrer à la validation de livraison |
Un exemple concret dans un service IT
Prenons un incident courant : une application métier devient indisponible après une mise en production. L’équipe pourrait se contenter de restaurer la version précédente. Cette correction rétablit le service, mais elle ne dit rien sur la raison pour laquelle l’erreur a franchi les contrôles.
La chaîne de questionnement
- Pourquoi l’application était-elle indisponible ? Parce qu’une configuration incompatible a été chargée en production.
- Pourquoi cette configuration était-elle incompatible ? Parce que le fichier utilisé ne correspondait pas à la version déployée.
- Pourquoi le mauvais fichier a-t-il été utilisé ? Parce que la sélection se faisait manuellement dans un répertoire partagé.
- Pourquoi la sélection était-elle manuelle ? Parce que le pipeline de déploiement ne contrôlait pas la version du fichier.
- Pourquoi ce contrôle n’avait-il pas été prévu ? Parce que le processus de livraison ne comportait pas de critère explicite sur la gestion des configurations.
La cause utile n’est donc pas simplement « le mauvais fichier a été choisi ». Une action durable peut combiner le versionnage des configurations, une vérification automatique dans le pipeline et une règle de validation avant mise en production. L’équipe peut ensuite suivre le taux d’échec des déploiements et vérifier, sur les livraisons suivantes, que le risque a réellement diminué.
Cet exemple montre aussi pourquoi la méthode est intéressante en management IT. Elle transforme une discussion parfois personnelle en conversation sur les interfaces entre outils, rôles et processus. Elle ne remplace pas les logs ni l’analyse technique, mais elle aide à relier les faits techniques aux décisions de gouvernance.
Quand l’utiliser et avec quels outils la compléter
La méthode fonctionne très bien pour un problème délimité, répétitif et relativement linéaire : défaut qualité, retard causé par une étape oubliée, incident de production, erreur de saisie ou non-conformité documentaire. Elle est particulièrement utile au démarrage d’une démarche d’amélioration continue, car elle demande peu de matériel et peut être menée directement avec l’équipe concernée.
Elle devient moins fiable lorsque plusieurs causes indépendantes produisent le même résultat. Une panne informatique peut par exemple combiner une saturation réseau, une dépendance externe et une alerte mal configurée. Dans ce cas, une seule chaîne de pourquoi risque de privilégier la première explication proposée.
| Situation | Outil pertinent | Pourquoi |
|---|---|---|
| Problème simple et ciblé | Cinq pourquoi | Rapide pour remonter une chaîne causale |
| Nombreuses causes possibles | Diagramme d’Ishikawa | Structure les causes par méthode, matériel, milieu, main-d’œuvre et mesure |
| Incident majeur ou récurrent | 8D ou analyse de cause racine formalisée | Encadre les preuves, les actions et la vérification d’efficacité |
| Processus mesurable | Analyse de données | Confirme la fréquence, la corrélation et l’évolution du problème |
| Amélioration progressive | PDCA | Relie l’analyse, l’action, le contrôle et l’ajustement |
Dans la pratique, je commence souvent par un diagramme de causes lorsque le sujet est transversal, puis j’applique le questionnement à chaque branche importante. Cette combinaison est plus robuste qu’une chaîne unique et reste suffisamment légère pour une équipe projet ou un service qualité.
Les erreurs qui affaiblissent l’analyse
Confondre cause racine et faute individuelle
Répondre « parce que l’opérateur s’est trompé » ne permet pas de prévenir la prochaine erreur. Il faut examiner la formation, la lisibilité de l’instruction, la charge de travail, l’ergonomie de l’outil et les contrôles disponibles. Une personne peut être impliquée dans l’événement sans être la cause suffisante du problème.
Forcer cinq réponses
Le chiffre cinq donne une structure, mais il ne garantit pas la qualité du raisonnement. Si l’équipe invente des réponses pour atteindre la cinquième question, elle fabrique une histoire cohérente plutôt qu’une analyse fiable. Mieux vaut s’arrêter après quatre niveaux solides ou poursuivre jusqu’à une cause vérifiable.
Partir d’une solution déjà choisie
Installer un nouvel outil, recruter une personne ou ajouter une validation peut sembler rassurant. Pourtant, l’action doit venir de l’analyse, pas l’inverse. Je demande toujours : quelle preuve montre que cette mesure réduira la cause identifiée ? Si personne ne peut répondre, le diagnostic mérite d’être repris.
Lire aussi : Diagramme de Pareto - Priorisez vos actions efficacement
Oublier la vérification après l’action
Une action n’est pas efficace parce qu’elle a été réalisée. Il faut définir un indicateur, une période d’observation et un seuil acceptable. Par exemple, on peut vérifier pendant quatre semaines le nombre d’incidents similaires, le délai de résolution ou le taux de conformité avant et après le changement.
Faire des cinq pourquoi un réflexe de management utile
La meilleure utilisation de cette méthode ne consiste pas à remplir un formulaire après chaque incident. Elle consiste à créer un espace où les équipes peuvent examiner un problème sans crainte, avec des faits accessibles et des décisions suivies dans le temps.
Pour commencer, choisissez un problème récent dont l’impact est concret. Décrivez-le en une phrase, réunissez les personnes directement concernées, testez chaque réponse avec des preuves, puis transformez la cause retenue en action mesurable. La qualité de la discussion compte davantage que le nombre exact de questions.
Employé avec cette discipline, le questionnement devient un outil simple mais puissant pour améliorer les processus, fiabiliser les projets numériques et éviter que le management ne se contente de traiter les mêmes symptômes à répétition.
