Comment Debugger N'importe Quel Bug en 15 Minutes

---

title: "Comment Debugger N'importe Quel Bug en 15 Minutes" description: "La méthode systématique pour trouver et corriger les bugs rapidement. Framework en 5 étapes." date: "2025-12-15" author: "Équipe Raicode" tags: ["debugging", "développement", "méthodologie", "productivité", "bonnes pratiques"] category: "Développement" image: "/blog/debugger-bug-15-minutes-hero.png" ogImage: "/blog/debugger-bug-15-minutes-hero.png" keywords: ["debugger bug", "debugging méthode", "trouver bug", "résoudre erreur", "debugging rapide"]

Le scénario classique : Un bug apparaît. Vous passez 4 heures à mettre des console.log partout. Vous essayez des trucs au hasard. Vous finissez par trouver que c'était une typo.

Il y a une meilleure façon.

Voici la méthode systématique que j'utilise pour résoudre 90% des bugs en moins de 15 minutes.

---

Le Framework RAPID

R - Reproduire
A - Analyser
P - Proposer des hypothèses
I - Investiguer
D - Documenter

Chaque étape a un objectif précis et un temps limite. L'idée : arrêter de tourner en rond.

---

Étape 1 : Reproduire (3 minutes)

L'Objectif

Un bug que vous ne pouvez pas reproduire est un bug que vous ne pouvez pas corriger.

Les Questions à Poser

□ Quel est le comportement attendu ?
□ Quel est le comportement observé ?
□ Comment reproduire le bug ?
□ Est-ce reproductible à 100% ?
□ Depuis quand ça arrive ?
□ Ça marchait avant ? Qu'est-ce qui a changé ?

Le Template de Reproduction

## Bug Report

**Attendu:** Cliquer sur "Sauvegarder" enregistre le formulaire
**Observé:** Rien ne se passe, pas d'erreur visible

**Étapes pour reproduire:**
1. Aller sur /profile/edit
2. Modifier le champ "nom"
3. Cliquer sur "Sauvegarder"

**Environnement:**
- Navigateur: Chrome 120
- OS: macOS 14
- Utilisateur: [email protected]

**Reproductible:** Oui, 100% du temps
**Depuis:** Mise à jour de vendredi

Si le Bug N'est Pas Reproductible

// Ajoutez du logging temporaire
try {
  await saveProfile(data);
} catch (error) {
  // Log TOUT
  console.error('Save failed:', {
    error,
    data,
    userId: user.id,
    timestamp: new Date().toISOString(),
    navigator: navigator.userAgent
  });

  // Envoyez à un service de monitoring
  Sentry.captureException(error, { extra: { data, userId: user.id } });
}

---

Étape 2 : Analyser (3 minutes)

L'Objectif

Comprendre le contexte avant de toucher au code.

Les Sources d'Information

1. Console du navigateur

// Erreurs JavaScript
// Network errors (failed requests)
// Warnings

2. Logs serveur

# Filtrer par timestamp
tail -f /var/log/app.log | grep "2025-12-15"

# Filtrer par erreur
grep -i "error\|exception" /var/log/app.log

3. Network Tab

□ La requête part-elle ?
□ Quel status code ?
□ Payload correct ?
□ Réponse attendue ?

4. Git History

# Qu'est-ce qui a changé récemment ?
git log --oneline -20

# Fichiers modifiés
git diff HEAD~5 --name-only

# Qui a touché à ce fichier ?
git blame src/components/Form.tsx

Le Pattern de Diagnostic

[Symptôme] → [Où ça casse] → [Pourquoi ça casse]

Symptôme: Le bouton ne fait rien
↓
Où: Handler onClick non appelé ? Requête échoue ? State pas mis à jour ?
↓
Pourquoi: Event non attaché ? Erreur réseau ? Bug de logique ?

---

Étape 3 : Proposer des Hypothèses (2 minutes)

L'Objectif

Lister les causes possibles AVANT de commencer à chercher.

Le Template d'Hypothèses

## Hypothèses (par probabilité)

1. **Handler non attaché** (haute)
   - Vérifier: console.log dans onClick
   - Si vrai: Problème de binding ou de rendu

2. **Requête échoue silencieusement** (moyenne)
   - Vérifier: Network tab, catch manquant
   - Si vrai: Erreur serveur ou réseau

3. **State non mis à jour** (moyenne)
   - Vérifier: React DevTools, console.log state
   - Si vrai: Problème de mutation ou de async

4. **Formulaire invalide** (basse)
   - Vérifier: Validation, required fields
   - Si vrai: Validation bloquante silencieuse

Pourquoi Lister Avant de Chercher

• Évite le "tunnel vision" sur une seule cause
• Force à réfléchir avant d'agir
• Permet de prioriser par probabilité
• Documente la démarche

---

Étape 4 : Investiguer (5 minutes)

L'Objectif

Tester chaque hypothèse méthodiquement.

Les Outils de Debug

1. Console.log Stratégique

// ❌ Mauvais : console.log partout
console.log('here');
console.log('here2');
console.log(data);

// ✅ Bon : console.log avec contexte
console.log('[Form] Submit clicked', { formData });
console.log('[Form] Validation result', { isValid, errors });
console.log('[API] Request sent', { endpoint, payload });
console.log('[API] Response received', { status, data });

2. Debugger (Breakpoints)

// Arrêtez l'exécution exactement où vous voulez
function handleSubmit(data) {
  debugger; // L'exécution s'arrête ici

  // Inspectez les variables dans DevTools
  // Exécutez pas à pas
}

3. React DevTools

- Inspectez les props
- Inspectez le state
- Vérifiez les re-renders
- Profiler les performances

4. Network Tab Avancé

- Filtrez par type (XHR, Fetch)
- Vérifiez les headers
- Comparez request/response
- Rejouez la requête (Copy as cURL)

La Technique du "Bisect"

# Le bug est apparu quelque part entre deux commits

# 1. Identifier le dernier commit "bon"
git log --oneline

# 2. Bisect automatique
git bisect start
git bisect bad HEAD
git bisect good abc1234

# 3. Git vous propose un commit intermédiaire
# Testez, puis dites si c'est good ou bad
git bisect good  # ou
git bisect bad

# 4. Répétez jusqu'à trouver le commit coupable

La Technique du "Binary Search" dans le Code

// Le bug est quelque part dans cette fonction

function complexFunction(data) {
  // Étape 1: Divisez en deux
  console.log('Checkpoint 1', data);

  const step1 = processFirst(data);
  console.log('Checkpoint 2', step1);  // Bug avant ou après ?

  const step2 = processSecond(step1);
  console.log('Checkpoint 3', step2);

  const result = finalize(step2);
  console.log('Checkpoint 4', result);

  return result;
}

// Si Checkpoint 2 est déjà faux, le bug est dans processFirst
// Répétez le processus dans processFirst

---

Étape 5 : Documenter (2 minutes)

L'Objectif

Ne jamais résoudre le même bug deux fois.

Le Template de Résolution

## Bug Fix: Bouton Sauvegarder ne fonctionne pas

**Cause:** Le handler onClick utilisait une référence stale du state
à cause d'un useCallback sans dépendances.

**Solution:**
```javascript
// Avant
const handleSubmit = useCallback(() => {
  saveData(formData); // formData était stale
}, []); // ❌ Dépendances manquantes

// Après
const handleSubmit = useCallback(() => {
  saveData(formData);
}, [formData]); // ✅ formData en dépendance

Prévention: Activer eslint-plugin-react-hooks avec "exhaustive-deps" en warning.

Temps de résolution: 12 minutes Commit: abc1234

### Où Documenter

1. Dans le commit message (détaillé)
2. Dans le ticket/issue (pour le PM)
3. Dans un wiki interne (pour les patterns récurrents)
4. Dans les commentaires de code (si piège subtil)

---

## Les Patterns de Bugs Courants

### Pattern #1 : Async/Await Oublié

```javascript
// ❌ Bug
async function loadData() {
  const data = fetchData(); // Oubli du await !
  console.log(data); // Promise, pas les données
}

// ✅ Fix
async function loadData() {
  const data = await fetchData();
  console.log(data);
}

Signal : [object Promise] dans les logs ou comportement asynchrone inattendu.

Pattern #2 : Référence Stale (React)

// ❌ Bug
const [count, setCount] = useState(0);

useEffect(() => {
  const interval = setInterval(() => {
    console.log(count); // Toujours 0 !
  }, 1000);
  return () => clearInterval(interval);
}, []); // Dépendance manquante

// ✅ Fix
useEffect(() => {
  const interval = setInterval(() => {
    setCount(c => c + 1); // Utilise le callback
  }, 1000);
  return () => clearInterval(interval);
}, []);

Signal : Valeurs "figées" dans des callbacks ou effects.

Pattern #3 : Mutation d'État

// ❌ Bug
const [items, setItems] = useState([1, 2, 3]);

function addItem() {
  items.push(4); // Mutation directe !
  setItems(items); // Même référence, pas de re-render
}

// ✅ Fix
function addItem() {
  setItems([...items, 4]); // Nouvelle référence
}

Signal : Le state semble changer mais l'UI ne se met pas à jour.

Pattern #4 : Race Condition

// ❌ Bug
async function search(query) {
  const results = await fetchResults(query);
  setResults(results); // Peut écraser des résultats plus récents !
}

// ✅ Fix avec AbortController
function Search() {
  const [results, setResults] = useState([]);

  useEffect(() => {
    const controller = new AbortController();

    async function doSearch() {
      try {
        const data = await fetchResults(query, {
          signal: controller.signal
        });
        setResults(data);
      } catch (e) {
        if (e.name !== 'AbortError') throw e;
      }
    }

    doSearch();
    return () => controller.abort();
  }, [query]);
}

Signal : Résultats incohérents avec des requêtes rapides.

Pattern #5 : Null/Undefined Non Géré

// ❌ Bug
function UserProfile({ user }) {
  return <div>{user.profile.avatar}</div>;
  // TypeError si user ou profile est null
}

// ✅ Fix
function UserProfile({ user }) {
  return <div>{user?.profile?.avatar ?? 'default.png'}</div>;
}

Signal : Cannot read property 'x' of null/undefined.

---

Les Outils Indispensables

Pour le Frontend

| Outil | Usage | |-------|-------| | Chrome DevTools | Debug général, Network, Performance | | React DevTools | State, props, re-renders | | Redux DevTools | Actions, state changes | | Lighthouse | Performance, SEO, Accessibilité |

Pour le Backend

| Outil | Usage | |-------|-------| | VS Code Debugger | Breakpoints, step-through | | Postman/Insomnia | Test API manuel | | curl | Requêtes rapides | | jq | Parse JSON en CLI |

Pour le Monitoring

| Outil | Usage | |-------|-------| | Sentry | Errors frontend/backend | | LogRocket | Session replay | | Datadog | Logs, metrics, APM | | Grafana | Visualisation metrics |

---

Le Timer de Debug

⏱️ 0:00 - 3:00  → Reproduire
⏱️ 3:00 - 6:00  → Analyser
⏱️ 6:00 - 8:00  → Hypothèses
⏱️ 8:00 - 13:00 → Investiguer
⏱️ 13:00 - 15:00 → Documenter

Total: 15 minutes

Si Après 15 Minutes Vous N'avez Pas Trouvé

1. Prenez une pause (5-10 min)
2. Expliquez le bug à quelqu'un (rubber duck debugging)
3. Demandez de l'aide avec vos hypothèses documentées
4. Dormez dessus si ce n'est pas urgent

Le cerveau continue à travailler en arrière-plan. Beaucoup de bugs se résolvent après une pause.

---

Le Mot de la Fin

Debugger n'est pas une question de talent. C'est une question de méthode.

Les meilleurs développeurs ne sont pas ceux qui écrivent du code sans bugs. Ce sont ceux qui trouvent et corrigent les bugs rapidement et systématiquement.

La prochaine fois qu'un bug apparaît, résistez à l'envie de mettre des console.log partout. Prenez 2 minutes pour formuler des hypothèses. Vous gagnerez des heures.

---

Des bugs récurrents dans votre application ? On peut auditer votre codebase et mettre en place des outils de monitoring pour les détecter avant vos utilisateurs. Parlons-en