# 🔍 Chercher la Vérité du Problème — Dig deeper **Chercher la Vérité du Problème** = ne JAMAIS résoudre en surface. Creuser jusqu'à la **cause racine** (root cause) pour résoudre le **vrai** problème. > **"Si j'avais une heure pour résoudre un problème, je passerais 55 minutes à le définir."** — Albert Einstein --- ## 🎯 Le principe ### ❌ Résoudre les symptômes (mauvais) --- ### ✅ Chercher la racine (bon) > 💡 **L'invariant** : "Résoudre la racine > masquer les symptômes." --- ## 🧠 Pourquoi c'est crucial ? Résoudre les symptômes : - ❌ **Problème revient** (symptôme masqué, pas éliminé) - ❌ **Complexité croissante** (patches sur patches) - ❌ **Perte de temps** (résoudre encore et encore) Résoudre la racine : - ✅ **Problème éliminé** définitivement - ✅ **Simplicité** (pas de workarounds) - ✅ **Temps gagné** long terme --- ## 📊 Méthode des 5 Pourquoi --- ## 🔍 Exemples concrets ### Exemple 1 : Bug en production #### Symptôme ``` Erreur: "Cannot read property 'name' of undefined" ``` #### ❌ Solution symptôme ```ts // Quick fix: ajouter un if const name = user?.name ?? "Unknown"; ``` **Problème** : Bug masqué. Pourquoi `user` est undefined ? --- #### ✅ Chercher la racine ``` Pourquoi 1: user est undefined → Parce que l'API retourne null Pourquoi 2: API retourne null → Parce que DB query ne trouve pas le user Pourquoi 3: DB query ne trouve pas le user → Parce que user_id incorrect Pourquoi 4: user_id incorrect → Parce que frontend envoie ID en string, backend attend number RACINE: Type mismatch entre frontend et backend ``` **Solution racine** : ```ts // Backend: valider et convertir const userId = parseInt(req.params.id, 10); if (isNaN(userId)) { return res.status(400).json({ error: "Invalid user ID" }); } ``` **Résultat** : Problème éliminé à la source. --- ### Exemple 2 : Performance #### Symptôme ``` Page met 5s à charger ``` #### ❌ Solution symptôme ```ts // Ajouter un loader ``` **Problème** : Masque la lenteur. Users attendent toujours 5s. --- #### ✅ Chercher la racine ``` Pourquoi 1: Page met 5s → Parce que fetch de 100 produits Pourquoi 2: Fetch 100 produits lent → Parce que 100 requêtes DB séparées (N+1) Pourquoi 3: 100 requêtes séparées → Parce que pas d'eager loading des relations RACINE: ORM mal utilisé (N+1 queries) ``` **Solution racine** : ```ts // Avant (N+1) const products = await Product.findAll(); for (const product of products) { product.category = await Category.findById(product.categoryId); } // Après (1 query) const products = await Product.findAll({ include: [Category], // Eager loading }); ``` **Résultat** : 100 requêtes → 1 requête. 5s → 200ms. --- ### Exemple 3 : Bug récurrent #### Symptôme ``` Même bug revient chaque sprint ``` #### ❌ Solution symptôme ``` "On va mieux tester" ``` **Problème** : Bug revient quand même. --- #### ✅ Chercher la racine ``` Pourquoi 1: Bug récurrent → Parce que zone de code fragile Pourquoi 2: Code fragile → Parce que logique complexe + pas de tests Pourquoi 3: Pas de tests → Parce que code difficilement testable (god class) Pourquoi 4: God class → Parce que refactoring jamais priorisé RACINE: Dette technique non gérée ``` **Solution racine** : ``` 1. Refactorer god class en services séparés 2. Ajouter tests unitaires 3. Politique: 20% du sprint = dette technique ``` **Résultat** : Bug ne revient plus. --- { process.exit(0); // Restart toutes les heures });`, description: "Masquer le symptôme, pas résoudre la cause" }, problem: "Memory leak toujours là, serveur restart = downtime", solution: "Diagnostiquer la cause du leak", goodExample: { code: `// 5 Pourquoi: // 1. Pourquoi memory leak ? → Cache grandit // 2. Pourquoi cache grandit ? → Pas d'éviction // 3. Pourquoi pas d'éviction ? → Pas de TTL // 4. Pourquoi pas de TTL ? → Oublié dans le design // Solution racine: const cache = new LRU({ max: 1000, ttl: 3600 });`, description: "Résoudre la racine, pas le symptôme" } }, { title: "Ajouter des couches de complexité", badExample: { code: `// Problème: API timeout parfois // Dev: "On va ajouter retry + circuit breaker" const response = await retry( () => circuitBreaker.fire(() => api.call()), { retries: 3 } );`, description: "Complexité pour masquer instabilité" }, problem: "API toujours instable, complexité ajoutée", solution: "Fixer l'API elle-même", goodExample: { code: `// 5 Pourquoi: // 1. Pourquoi timeout ? → Réponse > 30s // 2. Pourquoi > 30s ? → Query DB lente // 3. Pourquoi query lente ? → Full table scan // 4. Pourquoi full scan ? → Pas d'index // Solution racine: CREATE INDEX idx_users_email ON users(email);`, description: "Fixer la cause, pas ajouter patchs" } }, { title: "Blâmer l'utilisateur", badExample: { code: `// User: "L'app crash quand je fais X" // Dev: "Ne faites pas X alors" // Documentation: "⚠️ Ne pas faire X, ça crash l'app"`, description: "Rejeter la faute sur l'utilisateur" }, problem: "Problème non résolu, mauvaise UX", solution: "Comprendre pourquoi X cause un crash", goodExample: { code: `// 5 Pourquoi: // 1. Pourquoi crash si X ? → Exception non catchée // 2. Pourquoi exception ? → Division par 0 // 3. Pourquoi division par 0 ? → Input vide // 4. Pourquoi input vide ? → Pas de validation // Solution racine: if (!input || input === 0) { throw new Error('Input must be > 0'); }`, description: "Fixer le bug, pas documenter le workaround" } } ]} /> --- ## 🧪 Techniques de diagnostic ### 1. **5 Pourquoi (Toyota)** ``` Problème: Feature déployée avec bugs Pourquoi 1 ? → Pas de tests Pourquoi 2 ? → Pas le temps Pourquoi 3 ? → Sprint trop court Pourquoi 4 ? → Trop de features promises Pourquoi 5 ? → Pas de priorisation Racine: Manque de priorisation Solution: Story mapping + focus sur moins de features ``` --- ### 2. **Ishikawa (Fishbone Diagram)** ```mermaid graph LR A[Effet:
Bugs en prod] --> B[Cause 1:
Code] A --> C[Cause 2:
Process] A --> D[Cause 3:
Équipe] B --> E[Pas de tests] B --> F[Complexité élevée] C --> G[Pas de review] C --> H[Deploy trop rapide] D --> I[Manque expertise] D --> J[Fatigue équipe] style A fill:#ef4444,stroke:#991b1b,stroke-width:3px,color:#fff ``` --- ### 3. **Post-mortem (après incident)** ``` 1. Timeline: Que s'est-il passé ? 2. Impact: Qui a été affecté ? 3. Root Cause: Quelle est la vraie cause ? 4. Fix: Comment corriger définitivement ? 5. Prevention: Comment éviter que ça se reproduise ? ``` --- ### 4. **Rubber Duck Debugging** ``` Expliquer le problème à voix haute (à un canard): "Alors, le bug c'est que... ah attend... si je fais ça... c'est parce que... OH ! Je vois le problème maintenant !" ``` **Bénéfice** : Verbaliser force la réflexion profonde. --- --- foncer vers solution", }, { text: "Le plus vite possible est le mieux", isCorrect: false, explanation: "Au contraire, prendre le temps de comprendre", }, { text: "Tester 100 solutions jusqu'à ce que ça marche", isCorrect: false, explanation: "Pas efficace sans comprendre la racine", }, ], }, ]} /> --- ## 🗺️ Carte mentale de synthèse --- ## 🚀 Résultat attendu En maîtrisant la recherche de vérité du problème, tu deviens capable de : - **Distinguer** symptômes vs causes racines - **Creuser** avec les 5 Pourquoi jusqu'à la vérité - **Résoudre** définitivement au lieu de patcher - **Éviter** la complexité accidentelle (masquer symptômes) Et surtout : Tu cesses de coder des solutions rapides. **Tu résous les vrais problèmes.** Ne résous jamais en surface. Creuse jusqu'à la racine.