Sur un chantier, ça arrive. Un ouvrier pose une cloison, et derrière, une gaine électrique qui n'était pas sur le plan. Une fissure dans un enduit qu'on croyait solide. Un carrelage décollé le lendemain de la pose. Ce n'est pas un signe que le chantier est raté — c'est le chantier. Les vrais professionnels ne paniquent pas devant ces moments. Ils sortent le bon outil, ils identifient le problème, ils corrigent, et ils continuent.
Dans cette fiche, tu apprends à lire une erreur, décrire un bug précisément, reconnaître quand la table de travail est trop chargée — et récupérer d'un état cassé sans tout perdre.
"Le premier bug N'EST PAS un échec. C'est le process. Même les devs seniors passent 50% de leur temps à débugger."
Cette fiche n'est pas un aveu que les choses vont mal. C'est une compétence — la plus utile du cycle de développement. Savoir récupérer d'un état cassé, c'est ce qui sépare quelqu'un qui avance de quelqu'un qui abandonne.
Le message d'erreur est ton allié. Il ne te juge pas, il ne te dit pas que tu as raté — il te dit exactement où chercher.
Quand tu vois quelque chose de rouge dans le terminal ou dans le navigateur, ton réflexe doit être : copier l'erreur entière et la donner à Claude.
Pas le premier bout. Pas un résumé. L'erreur entière.
Claude va identifier la cause et te proposer une solution. Dans 80% des cas, c'est réglé en une réponse. Le reste du temps, tu répètes : tu colles la nouvelle erreur, et ainsi de suite.
Une erreur rouge dans le terminal, c'est direct — on copie-colle. Mais un bug, c'est différent : quelque chose se comporte autrement que prévu, sans forcément d'erreur visible.
Pour ces cas, utilise ce template de description :
Exemple concret :
Ce template fonctionne parce qu'il force à être précis. "Ça marche pas" n'aide ni toi ni Claude. "J'attendais X, j'ai obtenu Y, voici comment reproduire" — là, Claude a tout ce qu'il faut pour diagnostiquer.
Il existe un phénomène invisible mais redoutable : le context rot (pourrissement du contexte).
Ça ressemble à ça :
Quand tu observes ces symptômes, résiste à l'envie de penser que Claude "est devenu nul". Ce n'est pas Claude — c'est la table de travail trop chargée. Après une longue session, la fenêtre de contexte se remplit de fils de conversation, d'erreurs successives, de corrections, de back-and-forth. Claude essaie de tout tenir en tête en même temps et commence à perdre le fil.
La solution est simple et radicale :
Puis redonne le contexte essentiel : la story sur laquelle tu travailles, et rien de plus. Pas toute l'histoire de la session. Juste ce dont Claude a besoin maintenant.
Tes fichiers sont intacts. Seule la conversation est vidée. Tu repars sur une table propre avec un collaborateur qui a la tête claire.
Tu as enchaîné plusieurs modifications, quelque chose a lâché, et maintenant l'app ne démarre même plus. Voici le protocole, du moins invasif au plus radical.
Étape 1 — Voir où tu en esCette commande affiche tes derniers commits avec leurs messages. Chaque ligne, c'est une "photo de chantier" que tu as prise. Cherche le dernier commit qui précède le problème.
Étape 2 — Revenir en arrière sur les modifications non commitéesSi tu n'as pas encore commité les derniers changements et que tu veux les abandonner :
Cette commande annule toutes les modifications depuis le dernier commit. L'app revient exactement à l'état de ta dernière photo de chantier.
Une fois exécutée, les modifications non commitées sont perdues. Utilise-la quand tu es sûr de vouloir repartir de l'état du dernier commit.
Si tu veux garder tes modifications mais les écarter temporairement pour tester quelque chose :
Tes modifications sont mises "en pause". Pour les récupérer plus tard :
**Étape 4 — /rewind (annuler la dernière action Claude)**
Si Claude vient juste de faire quelque chose qui ne te convient pas et que tu n'as pas encore touché à autre chose :
C'est le Ctrl+Z du chantier. Il annule la dernière action de Claude Code.
Regarde la date de ton dernier commit. Git log te le montre. Rien n'est perdu tant que tu as commité régulièrement. C'est exactement pour ça qu'on commite après chaque story.
Résumé rapide selon ce que tu traverses :
| Situation | Solution |
|---|---|
| Erreur rouge dans le terminal | Copier l'erreur entière → la donner à Claude |
| Bug silencieux (comportement inattendu) | Template "J'attendais / J'ai obtenu / Étapes" → donner à Claude |
| Claude répond de façon incohérente | /clear → redonne seulement la story en cours |
| L'app ne démarre plus, modifs non commitées | git checkout -- . pour revenir au dernier commit |
| Tu veux garder tes modifs mais tester l'état précédent | git stash pour mettre en pause |
| Claude vient de faire quelque chose de mauvais | /rewind pour annuler |
| Symptôme | Cause probable | Solution | |
|---|---|---|---|
| git: command not found | Git n'est pas installé ou pas dans le PATH | Installe Git depuis git-scm.com. Sur Windows, utilise Git Bash | |
| git log ne montre rien | Aucun commit n'a été fait | Lance git init si ce n'est pas encore fait, puis git add . && git commit -m "init" | |
| git checkout -- . ne change rien | Les fichiers modifiés ne sont pas trackés par Git | Vérifie avec git status quels fichiers sont affectés | |
| Claude continue à être incohérent même après /clear | La story en cours est trop vague ou contradictoire avec d'autres fichiers | Relance /brik:corriger story pour clarifier la story avant de continuer | |
| L'erreur dans le terminal défile trop vite | Scroll dans le terminal, ou utilise npm run dev 2>&1 \ | head -50 pour voir les 50 premières lignes | Cherche la première ligne rouge — c'est souvent là que le problème est identifié |
| Je suis bloqué depuis plus de 30 minutes sur la même erreur | Le problème dépasse ce que Claude peut corriger dans ce contexte | /clear, puis décris le problème depuis le début : ce que tu construisais, l'erreur exacte, les solutions déjà essayées |
Tu as les outils pour construire et récupérer quand ça déraille. Story après story, commit après commit, ton app prend forme. Quand toutes les stories du sprint sont validées, il sera temps de sauvegarder et de partager.
-> Fiche suivante : Sauvegarder et partager