Les « Cinq pourquoi » ont pour vocation de trouver la cause sous-jacente d'un problème en éliminant les couches de problèmes superficiels qui sont en fait les symptômes du problème, et non sa cause. En demandant à plusieurs reprises « Pourquoi ? » et en examinant les réponses, vous pouvez découvrir les causes les plus profondes et souvent négligées d'un problème. 

L'objectif est d'en arriver au point où les questions supplémentaires ne fournissent plus d'informations pertinentes et où vous aurez identifié la cause racine. Une fois que vous aurez identifié la cause racine, vous pourrez mettre en œuvre des solutions pratiques pour y remédier et éviter que le problème ne se reproduise.

Exemple de modèle des « Cinq pourquoi » en action

Voici un exemple d'application du modèle d'analyse des « Cinq pourquoi » à un problème :

Énoncé du problème: l'application logicielle plante fréquemment en cas de forte charge utilisateur, ce qui nuit à l'expérience utilisateur.

1. Pourquoi le logiciel plante-t-il en cas de forte charge utilisateur ?

• Réponse : le serveur est submergé par les demandes simultanées des utilisateurs.

2. Pourquoi le serveur est-il submergé par les demandes simultanées des utilisateurs ?

• Réponse : la capacité du serveur doit être adaptée de manière appropriée pour gérer les fortes charges de trafic.

3. Pourquoi la capacité du serveur n'a-t-elle pas été adaptée pour faire face à de fortes charges de trafic ?

• Réponse : l'équipe n'a pas effectué de surveillance proactive ni de tests de charge pendant le développement. 

4. Pourquoi n'y a-t-il pas eu de surveillance proactive ni de tests de charge pendant le développement ?

• Réponse : l'équipe de développement ne disposait pas des outils ni de l'expertise nécessaires pour les tests de charge.

5. Pourquoi l'équipe de développement n'a-t-elle pas les outils ni l'expertise nécessaires pour les tests de charge ?

• Réponse : le périmètre initial du projet n'incluait pas les tests de charge, et l'équipe n'avait pas accès aux ressources appropriées pour les tests de charge. 

Cause racine : les pannes logicielles liées à une forte charge utilisateur sont dues à l'absence de tests de charge dans le périmètre initial du projet et au manque d'accès aux ressources et à l'expertise nécessaires pour les tests de charge.

Solution : pour éviter de futurs plantages liés à de fortes charges utilisateur, l'équipe devrait inclure les tests de charge dans son processus de développement logiciel, et garantir l'accès aux ressources et à l'expertise requises pour les tests de charge. Cela permettra d'identifier et de résoudre les problèmes de performances au début du cycle de développement, garantissant ainsi une expérience utilisateur plus fluide lors du déploiement du logiciel.

Dans cet exemple, l'analyse des « Cinq pourquoi » a révélé la cause racine des fréquents plantages liés à une forte charge utilisateur : l'absence de tests de charge dans le périmètre initial du projet et le manque de ressources pour effectuer des tests de charge pendant le développement. 

La solution résout directement ce problème, ce qui crée un effet domino qui résout les symptômes ultérieurs et, en fin de compte, l'énoncé du problème initial. 

En intégrant les tests de charge au processus de développement logiciel et en garantissant la disponibilité des ressources et de l'expertise requises, nous éviterons de futurs plantages. Cela aidera également l'équipe à améliorer l'expérience utilisateur.