Analyse des causes profondes

La plupart des résolutions de problèmes s'attaquent aux symptômes, pas aux causes.

Le déploiement a échoué? Annulez et redéployez. Un bogue en production? Appliquez un correctif d'urgence. La compilation est lente? Ajoutez plus de serveurs de compilation.

Ces correctifs s'attaquent à la douleur immédiate. Le problème disparaît... jusqu'à ce qu'il revienne. Parce que vous n'avez pas corrigé ce qui l'a causé.

L'analyse des causes profondes signifie demander « pourquoi? » jusqu'à ce que vous trouviez la cause systémique — la chose qui, si elle était corrigée, empêcherait le problème de se reproduire.

Le déploiement n'a pas échoué à cause d'un problème aléatoire. Il a échoué parce que la suite de tests est instable. La suite de tests est instable parce que les tests partagent un état. Les tests partagent un état parce que le framework de test n'a pas été bien compris lors de sa mise en place.

Corrigez le symptôme immédiat (réessayez le déploiement) et vous réessaierez demain. Corrigez la cause profonde (corrigez la compréhension du framework de test) et les déploiements cesseront d'échouer.

L'analyse des causes profondes prend plus de temps au départ. Mais elle permet d'économiser exponentiellement plus de temps en prévenant la récurrence.

Les cinq pourquoi sont la technique d'analyse des causes profondes la plus simple : continuez à demander « pourquoi? » jusqu'à ce que vous atteigniez une cause profonde, généralement après environ cinq itérations.

Exemple :

Problème : La production est tombée pendant 2 heures.

1. Pourquoi? Une mauvaise configuration a été déployée.
2. Pourquoi? Le changement de configuration n'a pas été testé.
3. Pourquoi? Nous n'avons pas de tests de changement de configuration.
4. Pourquoi? La configuration est gérée séparément du code.
5. Pourquoi? L'équipe d'infrastructure l'a configurée avant que l'équipe de développement n'adopte GitOps.

Cause profonde : Séparation historique de la configuration et du code dans le pipeline de déploiement.

Contre-mesure : Déplacer la configuration dans le même dépôt et le même pipeline CI/CD que le code de l'application.

Pièges des cinq pourquoi :

• S'arrêter trop tôt : « L'erreur humaine » n'est jamais une cause profonde. Pourquoi l'erreur s'est-elle produite? Quel système l'a permise?
• Linéaire : Les vrais problèmes ont souvent plusieurs causes. Les cinq pourquoi peuvent manquer des chaînes causales parallèles.
• Basé sur l'opinion : Sans données, vous pourriez demander « pourquoi? » et obtenir de la spéculation au lieu de faits.
• Recherche de coupables : Si les cinq pourquoi dégénèrent en « qui a fait une erreur? », ils sont mal utilisés.

Les cinq pourquoi fonctionnent mieux comme point de départ, complétés par des données et plusieurs perspectives.

Le diagramme d'Ishikawa, aussi appelé arête de poisson ou diagramme de cause à effet, aide à explorer simultanément plusieurs catégories de causes.

Le problème est la « tête » du poisson. Les principales catégories de causes sont les « arêtes ». Les sous-causes se ramifient à partir de chaque arête.

Catégories courantes (les 6 M) :

• Main-d'œuvre : Personnes, compétences, formation
• Méthode : Processus, procédures
• Machine : Outils, équipement, systèmes
• Matière : Intrants, données, dépendances
• Mesure : Métriques, surveillance, rétroaction
• Milieu : Facteurs externes, contexte

Pour les logiciels, vous pourriez adapter :

• Personnes : Compétences, communication, structure d'équipe
• Processus : Flux de travail, transferts, politiques
• Technologie : Outils, infrastructure, architecture
• Données : Intrants, état, dépendances
• Mesure : Visibilité, surveillance, alertes
• Environnement : Services externes, charge, contexte

Le diagramme aide les équipes à réfléchir aux causes de manière systématique plutôt que de s'ancrer sur la première idée. Il révèle que les problèmes ont généralement plusieurs causes contributives.