La routine en 6 étapes que je suis à chaque session. Ensuite, de quoi tenir
une session longue sans perdre en qualité ni cramer ton quota : /context,
/compact, /clear, /rewind, /resume.
La boucle en 6 étapes
Chaque session de développement suit le même cycle, toujours dans le même ordre.
Étape 1, brainstormer (5 min)
Objectif : explorer les options avant de s'engager.
"Brainstorme un système de [ta feature] pour [ton projet]. Contexte : [pourquoi tu la veux, quel problème elle résout]."
Claude explore 3-4 approches et compare avantages et inconvénients. Tu tranches.
Astuce : même pour les features qui te semblent simples, brainstorme d'abord. Claude repère souvent des cas limites ou des opportunités que tu n'aurais pas envisagés.
Étape 2, planifier (10 min)
Objectif : transformer le choix en plan d'action.
"Écris le plan d'implémentation pour l'approche qu'on a choisie."
Claude produit un plan tâche par tâche avec les fichiers concernés et les commandes de vérification. Tu relis et tu valides. Dernier point de contrôle avant l'exécution.
Quoi vérifier dans le plan :
- L'ordre des tâches est-il logique ?
- Est-ce qu'il manque quelque chose d'évident ?
- Le scope est-il raisonnable pour une session ?
Étape 3, exécuter (20-40 min)
Objectif : Claude code, tu supervises.
"Exécute le plan."
Claude travaille tâche par tâche, en autonomie. Entre chaque étape, il lance automatiquement les vérifications (typecheck, lint). Si une vérification échoue, il corrige avant de continuer.
Pendant ce temps, toi :
- Tu observes la progression dans le chat
- Tu interviens si Claude te pose une question
- Tu ne touches à rien dans les fichiers, laisse-le finir
Quand interrompre : si Claude part clairement dans la mauvaise direction, appuie sur Échap tout de suite. Chaque minute de plus, ce sont des tokens dépensés pour rien et du contexte pollué. Pour une simple remarque, attends la fin de l'étape en cours.
Étape 4, vérifier visuellement (5-10 min)
Objectif : tester dans le navigateur.
Ouvre localhost:3000 et teste toi-même. Claude peut ouvrir tes pages avec Claude in Chrome (claude --chrome), mais c'est toi qui sais si l'expérience est bonne pour tes utilisateurs. Tu es le testeur final.
Voici ce que tu vérifies :
- La feature fonctionne comme prévu (cas nominal)
- Les cas d'erreur sont gérés (mauvaise saisie, données manquantes)
- Le design est cohérent avec le reste de l'app
- Le responsive fonctionne (réduis la fenêtre pour simuler mobile)
- Les textes sont en français avec les bons accents
Si quelque chose ne va pas, dis-le précisément :
"Le bouton est trop petit sur mobile, le texte déborde de la card à droite, et la couleur du badge 'Brouillon' devrait être grise au lieu de bleue."
Étape 5, review et commit (5 min)
Objectif : valider la qualité et sauvegarder.
/code-review(ou son alias/review) → Claude relit tout le code modifié dans un sub-agent en arrière-plan et signale les bugs : cas oubliés, logique fausse, incohérences avec le reste du code.
Tu peux régler la profondeur, de low (peu de remarques, toutes sûres) à max (beaucoup de remarques, dont certaines incertaines), et ajouter --fix pour qu'il applique les corrections :
/code-review high --fix
Deux commandes voisines : /simplify nettoie le code (doublons, simplifications) sans chercher de bugs, et /security-review cherche les failles. Le niveau ultra de /code-review lance une revue multi-agents dans le cloud : 3 essais offerts sur Pro et Max, ensuite ça passe en crédits d'usage. Garde-le pour les grosses PR.
Pour le commit, demande simplement :
"Commite avec un message clair."
Claude analyse les changements et crée un commit Git propre avec un message descriptif. La commande /commit que tu vois dans certains tutos n'est pas native : elle vient du plugin commit-commands (chapitre 16).
Pourquoi la review est importante : même si Claude a écrit le code, il
peut contenir des erreurs subtiles. /code-review apporte un regard neuf,
comme demander à un collègue de relire ton travail. Sur Panettone, j'ai un
commit entier de corrections trouvées par la review.
Étape 6, sauvegarder le contexte (2 min)
Objectif : préparer la prochaine session.
"Mets à jour la mémoire projet avec les décisions de cette session."
Claude sauvegarde :
- Les décisions architecturales prises et leur justification
- Les patterns confirmés comme fonctionnels
- Les erreurs rencontrées et leurs solutions
- L'état d'avancement du projet
La prochaine session démarrera avec tout ce contexte. Claude Code tient aussi une mémoire automatique entre les sessions : le fonctionnement est au chapitre 10.
Le timing typique d'une session
| Étape | Durée | Qui fait quoi |
|---|---|---|
| Brainstorm | 5 min | Claude propose, tu choisis |
| Planification | 10 min | Claude rédige, tu valides |
| Exécution | 20-40 min | Claude code, tu supervises |
| Vérification visuelle | 5-10 min | Tu testes dans le navigateur |
| Review + commit | 5 min | Claude relit et sauvegarde |
| Mémoire | 2 min | Claude met à jour le contexte |
| Total | 45-70 min | 1 feature complète livrée |
Quand sauter des étapes ?
Le cycle complet vaut pour les features moyennes à grosses. Pour les petits ajustements, adapte :
| Type de tâche | Étapes à suivre | Exemple |
|---|---|---|
| Bug fix simple | Exécuter → Vérifier → Commit | "Le bouton 'Sauvegarder' ne fonctionne pas" |
| Ajustement UI | Exécuter → Vérifier → Commit | "Augmente l'espacement entre les cards" |
| Feature moyenne | Planifier → Exécuter → Vérifier → Review → Commit | "Ajoute un filtre par statut sur la liste" |
| Feature majeure | Brainstorm → Planifier → Exécuter → Vérifier → Review → Commit → Mémoire | "Système de paiement Stripe complet" |
Le cycle devient automatique en 2-3 sessions.
Les réflexes en session longue
Ces réflexes viennent des best practices partagées par Boris Cherny (créateur de Claude Code), de la communauté, et de mes propres mesures. Ils jouent sur la qualité des sessions longues, et sur ta facture.
/context, savoir ce qui occupe la place
Avant de relancer une grosse instruction ou de décider si tu dois faire de la place, tape /context. Claude affiche une grille de ta fenêtre de contexte (tout ce que le modèle a sous les yeux à ce moment) : prompt système, outils chargés, fichiers d'instructions, mémoire, skills, historique, avec des suggestions pour alléger. /context all donne le détail complet.
Ne confonds pas avec ses deux voisines, elles ne répondent pas à la même question :
| Commande | La question | Ce que tu vois |
|---|---|---|
/context | Qu'est-ce qui prend la place ? | La répartition de la fenêtre en ce moment |
/usage (alias /cost et /stats) | Combien j'ai consommé ? | Une estimation en dollars, la répartition par skill, sub-agent, plugin et serveur MCP, et une ligne sur le cache (taux de réussite, cause probable quand il rate) |
/insights | Comment je travaille ? | Un rapport HTML qui analyse tes dernières sessions |
Exemple : tu viens de terminer une feature de 40 minutes et tu hésites à attaquer la suivante. Tu tapes /context pour voir ce qui traîne encore dans la fenêtre avant de décider entre continuer, compacter ou repartir de zéro.
À faire : lance /context systématiquement avant de démarrer une nouvelle phase du cycle (nouvelle feature, nouveau brainstorm).
Quand faire de la place : les seuils de 40, 60 et 80 %
Les repères de la communauté : sous 40 % de contexte, tu es à l'aise. Entre 40 et 60 %, tu surveilles. Au-dessus de 60 %, tu fais de la place avant d'attaquer une nouvelle feature. Au-dessus de 80 %, zone rouge.
Ces repères sont nés quand la fenêtre faisait 200 000 tokens. Dans Claude Code, Opus 5.5, Fable 5.1, Sonnet 5.5 et Haiku 5.5 ont maintenant 1M de tokens de contexte. 40 % de 1M, c'est 400 000 tokens : une conversation énorme. Deux problèmes arrivent bien avant les pourcentages :
- La qualité. Plus la conversation est longue, plus Claude risque d'oublier des consignes noyées au milieu (le phénomène "Lost in the Middle"). C'est ce que la communauté appelle la "dumb zone" : règles oubliées, choix incohérents.
- Le coût. À chaque message, toute la conversation est renvoyée au modèle. Une session à 400 000 tokens te coûte ce paquet à chaque échange, même en cache.
Mon repère à moi : je change de tâche, je fais /clear, quel que soit le pourcentage.
Voir le pourcentage en permanence. /context te le donne quand tu le demandes. Pour l'avoir sous les yeux à chaque message, il faut une status line : la ligne d'infos que Claude Code affiche sous la zone de saisie. Celle de claude-carbon, le plugin gratuit que j'ai écrit, montre le modèle et le remplissage du contexte en %, à côté du coût et du CO2 de la session :
mon-app ⌥ main | 🟢 Opus 5.5 ▓▓▓░░░░░░░ 35% | $0.50 · 65gCO₂ | Use 24% ↻13:00
Pour l'installer, demande-le à Claude : "Installe claude-carbon en suivant le README de github.com/gwittebolle/claude-carbon". Il prend la commande qui va avec ton système. Relance ensuite Claude Code. La status line s'affiche dans le terminal, y compris celui de VS Code. Le panneau de l'extension VS Code et l'app desktop n'en ont pas : dans l'app desktop, tape /carbon-panel pour voir le remplissage du contexte dans un panneau.
Si tu laisses faire, Claude Code compacte tout seul : c'est l'auto-compact. Sur les modèles 1M, il se déclenche par défaut juste avant la limite, vers 967 000 tokens. Tu peux l'avancer :
/autocompact 400000
La valeur va de 100 000 à 1M de tokens. /autocompact auto revient au réglage par défaut, et le réglage autoCompactWindow dans tes settings le rend permanent. Si tu préfères l'ancienne fenêtre de 200 000 tokens, la variable d'environnement CLAUDE_CODE_DISABLE_1M_CONTEXT=1 la rétablit.
/clear, /compact, /rewind, /recap : faire de la place sans se tromper
Elles se ressemblent, et se tromper de commande coûte cher.
| Commande | Ce qu'elle fait | Ce que ça coûte | Quand |
|---|---|---|---|
/clear | Vide la conversation. Tu repars de zéro, CLAUDE.md rechargé | Rien. Remet aussi le compteur de /usage à zéro | Tu changes de sujet |
/compact [consignes] | Relit toute la conversation et la remplace par un résumé | Une fraction si le cache est chaud. Si le cache a expiré, l'opération la plus chère de ta journée | Même tâche, tu manques de place |
/rewind (ou Esc Esc) | Revient à un point antérieur de la conversation et du code | Moins cher que compacter : tu reviens à un début de conversation déjà en cache | Claude est parti dans le décor |
/recap | Te fait un résumé de la session | Garde le cache | Tu reviens d'une pause et tu as perdu le fil |
Compacter n'est pas gratuit. /compact demande à Claude de relire toute la conversation puis d'écrire un résumé, et le texte produit (l'output) est ce qui coûte le plus cher au token. Compacter par réflexe alors qu'on n'a plus besoin de ce qui précède, c'est payer un résumé qu'on ne lira jamais.
D'où la règle : compacte quand tu veux continuer la même tâche et que tu manques de place. Efface quand tu changes de sujet.
Quand tu compactes, dis-lui quoi garder :
/compact Garde les décisions sur le schéma Stripe et la liste des fichiers modifiés
Ou écris-le une fois pour toutes dans une section Compact instructions de ton CLAUDE.md (chapitre 3).
Le réflexe complet : /rename pour nommer la session, puis /clear. Tu
repars sur une base propre et tu peux retrouver la session d'avant avec
/resume si besoin.
Après un /compact : relis les fichiers clés de ta tâche en cours. Le résumé laisse filer des détails, relire les fichiers les remet en contexte.
Pourquoi tout ce qui entre coûte longtemps
À chaque message, Claude Code renvoie la conversation entière depuis le premier mot. Le modèle n'a aucune mémoire entre deux appels : s'il a l'air de suivre la conversation, c'est parce qu'on lui renvoie tout à chaque fois.
Heureusement, il y a le cache.
Anthropic garde de côté le début de ta requête, déjà traité. Au message suivant, si ce début est identique caractère pour caractère, il est relu au lieu d'être recalculé : dix fois moins cher en général, vingt fois sur Opus 5.5 et Sonnet 5.5. Change un seul caractère en amont, et tout ce qui suit repasse au prix fort. Le cache est aussi ce qui rend les réponses plus rapides.
Claude Code range chaque requête pour que ce qui bouge le moins soit en tête :
Le cache a une durée de vie :
| Situation | Conversation principale | Sub-agents, forks et compaction |
|---|---|---|
| Abonnement Claude, dans ton quota | 1 heure | 5 minutes |
| Crédits d'usage, clé API, fournisseur cloud (Bedrock, Google Cloud, Foundry) | 5 minutes | 5 minutes |
Passé ce délai, le premier message relit toute la conversation sans cache. Sur une session longue, c'est cher. Sur Pro et Max, quand tu reprends une grosse session avec /resume après une longue pause, Claude Code te propose de repartir d'un résumé plutôt que de tout relire : accepte.
63 514 tokens avant même mon premier message : c'est ce que pèse chez moi une session vide (prompt système, outils, CLAUDE.md, mémoire), dont 98,6 % lus en cache. Sur 30 jours, j'ai compté 147 reprises à froid et 11 changements de modèle, chacun payé plein pot.
Conséquences pratiques :
- Un fichier de 3 000 lignes ouvert au troisième message te suit jusqu'au
/clear. Dis à Claude où chercher plutôt que de le laisser fouiller. - Changer de modèle, c'est changer de prof : tout est relu. Choisis-le au démarrage. L'effort, lui, se change sans casser le cache sur Opus 5.5, Sonnet 5.5, Haiku 5.5 et Fable 5.1.
- Après une pause de plus d'une heure (ou de cinq minutes en crédits d'usage), le prochain message relit tout sans cache. Si tu reviens sur un autre sujet, fais
/clear.
Le détail chiffré (prix du cache, ce qui le casse, comment vérifier) est au chapitre 19.
/rewind, revenir en arrière
Parfois Claude part dans une mauvaise direction : mauvaise approche technique, code qui casse tout, ou bug en cascade. Ne corrige pas dans le même contexte, le contexte est déjà pollué par la mauvaise approche.
Typiquement, Claude vient de refactorer un composant et la page affiche 12 erreurs console. Tu tapes Esc Esc pour rollback code + conversation d'un coup au lieu de debugger.
Comment : tape Esc Esc (double Échap) ou /rewind. Tu choisis un message précédent, et Claude annule les modifications de code ET remonte la conversation à ce point. Un Ctrl+Z géant.
Dans le menu de /rewind, l'option "Summarize up to here" résume la conversation jusqu'au message choisi. Utile quand le début de la session est long mais ne sert plus, alors que la suite compte encore.
Pourquoi /rewind bat la correction manuelle : quand Claude corrige un bug
qu'il vient de créer, il a les mauvaises instructions en mémoire. Avec
/rewind, il repart du bon contexte et prend un chemin différent. Et comme il
revient à un début de conversation déjà en cache, c'est moins cher qu'un
/compact.
Pas à pas : une feature qui part en vrille
Imagine : tu veux ajouter un système de filtres sur une liste de tâches.
- Tu brainstormes, tu planifies, tu lances
Exécute le plan. - Claude commence bien, puis décide de refactorer tout ton composant
TaskListpour intégrer les filtres. Il casse la pagination au passage. - Tu testes
localhost:3000, la liste est vide, la console crache 12 erreurs. Debug à chaud = piège. - Tu tapes
Esc Esc. Claude rollback le code et la conversation, ton repo revient à l'état d'avant la dérive. - Tu relances
/contextpour vérifier ce qui reste dans la fenêtre. - Tu replanifies en étant plus précis : "Ajoute les filtres sans toucher à la pagination existante. Crée un composant
TaskFiltersséparé qui prendtasksen props et retournefilteredTasks." - Tu relances l'exécution. Cette fois le scope est clair, Claude livre propre en 15 minutes.
Total : 5 minutes perdues sur la première tentative, et pas de debug à chaud.
/resume, /rename, /branch, /fork : retrouver et dupliquer une session
Si ton terminal a crashé ou que ton Mac a redémarré, la session n'est pas perdue.
/renamedonne un nom à la session en cours. Fais-le avant un/clear, tu la retrouveras plus vite./resumeliste tes sessions récentes. Tu choisis, Claude recharge la conversation. Depuis le terminal,claude --continuereprend directement la dernière./branch [nom]crée une branche de la conversation à ce point et t'y bascule. Tu essaies une autre direction, l'original reste intact et tu y reviens avec/resume./forkcopie la conversation dans une session de fond, qui travaille dans son propre worktree (une copie de travail Git séparée) avant de toucher au code. Tu continues ici pendant que la copie avance. Elle relit le cache de la conversation d'origine.
Le matin, tu rouvres ton laptop et tu veux reprendre la feature Stripe d'hier soir. Tu lances claude, tu tapes /resume, tu choisis "stripe-checkout" dans la liste.
Attention au lendemain matin : une session reprise après une nuit a perdu
son cache. Le premier message relit toute la conversation au prix fort. Si
Claude Code te propose de reprendre depuis un résumé, accepte. Et vérifie avec
/context ce que tu traînes avant de relancer.
Commiter souvent
Commite dès qu'une tâche est terminée, au moins une fois par heure. Pourquoi ?
- Chaque commit est un point de sauvegarde que tu contrôles.
/rewindrevient en arrière dans la session, un commit reste après la fin de la session - Plus tu commites, plus le filet de sécurité est fin
- Signal mental aussi : "cette tâche est finie, je passe à la suivante"
Après chaque feature ou correction :
/code-review, puis "commite". Pas besoin d'attendre d'avoir fini 3 features.
Question
Tu es sur Max, dans ton quota. Ta session fait 300 000 tokens. Tu pars déjeuner 1 h 30, tu reviens et tu envoies un message dans la même session. Que se passe-t-il ?
Choisis une réponse pour voir l'explication.
À retenir
- Brainstorm, plan, exécution, vérification, review, mémoire : au bout de 2-3 sessions, tu ne réfléchis plus à l'ordre.
/contextpour voir ce qui occupe la fenêtre,/usagepour ce que tu as consommé.- Nouveau sujet :
/clear, gratuit./compactsert quand tu manques de place sur la même tâche, et/rewindquand Claude a pris une fausse route. - Sur 1M de contexte, surveille la qualité et le coût de chaque message plus que les pourcentages. Et après une pause de plus d'une heure (cinq minutes en crédits d'usage), le message suivant relit tout sans cache.
Quiz de fin de partie
Partie 2 : Communiquer et planifier
6 questions. La partie est validée à partir de 5 bonnes réponses.