Il y a une compétence qui sépare l'utilisateur professionnel de l'utilisateur frustré, et ce n'est ni le prompt ni l'outillage : c'est de savoir quand s'arrêter. La session qui s'enlise, tout le monde la connaît : une correction qui ne marche pas, une deuxième qui casse autre chose, et une heure plus tard vous êtes en train de supplier un agent noyé dans ses propres tentatives.
Tout ce chapitre découle d'une chose que vous savez depuis le chapitre 2 : le contexte est une mémoire de travail qui se remplit, et un contexte pollué produit un Claude qui dérive. C'est le chapitre le plus court du guide, et peut-être le plus rentable : quelques réflexes d'hygiène qui transforment les mauvaises journées en petits détours.
La session fourre-tout
Le symptôme d'abord. Un fil unique, ouvert lundi matin, encore vivant jeudi soir : on y a corrigé un bug, ajouté deux fonctionnalités, discuté du déploiement, recollé trois fois le même fichier. L'anti-pattern est si répandu que l'écosystème anglophone l'a baptisé kitchen sink session, et qu'il ouvrira le bestiaire du chapitre 13 sous son nom français : la session fourre-tout.
Ce qui se passe dedans est mécanique. Chaque échange s'ajoute au contexte, y compris les fausses pistes, les versions abandonnées, les corrections annulées. Claude ne fait pas le tri : tout pèse dans sa mémoire de travail, et le code abandonné d'il y a deux heures pèse autant que votre consigne d'il y a deux minutes. Les réponses se dégradent, alors on corrige plus, donc on pollue plus : la spirale s'auto-alimente.
Un /context de temps en temps rend la chose visible : quand la fenêtre est bien entamée et que la tâche patine, ce n'est plus un hasard, c'est une cause.
La règle des deux corrections
D'où la règle la plus simple de tout le guide : au bout de deux allers-retours ratés, stop. Pas trois, pas cinq. Deux échecs consécutifs sur la même correction signifient rarement que Claude manque d'efforts ; ils signifient que le problème est mal posé, ou que le contexte est déjà trop pollué pour qu'il le voie clairement. Insister, c'est demander une meilleure réponse à un interlocuteur qu'on a soi-même embrouillé.
Un /clear et un meilleur prompt battent dix rustines, à chaque fois.
Je me suis imposé cette règle après l'avoir enfreinte assez souvent pour connaître la suite par cœur : la troisième rustine tient rarement, la quatrième casse autre chose, et à la dixième plus personne ne sait ce qui marche encore.
Interrompre tôt, rembobiner
Avant même la règle des deux corrections, il y a le réflexe d'interruption : dès que vous voyez Claude partir dans une mauvaise direction, coupez. Le laisser terminer une mauvaise idée par politesse coûte des tokens, du temps, et surtout du contexte pollué qu'il faudra nettoyer. Et quand le mal est fait, ne demandez pas à Claude d'annuler ce qu'il vient d'écrire : chaque « défais ça » ajoute encore une couche au fil. Quatre gestes couvrent toutes les situations.
- 01 · ÉchapInterrompre, préciser, relancer : un geste d'efficacité, pas une impolitesse.
- 02 · /rewindRamène la session à un checkpoint antérieur : vous repartez d'un état sain, comme si la mauvaise piste n'avait jamais existé, au lieu d'empiler une réparation sur une erreur. Une réserve à connaître : le checkpoint ne rattrape que ce que Claude a écrit avec ses outils d'édition, pas ce qu'une commande du terminal a modifié au passage. C'est un filet de session, ce n'est pas git.
- 03 · /clearLe grand nettoyage : tout le fil disparaît, on repart d'un prompt propre.
- 04 · /compactLe nettoyage partiel : la conversation est résumée pour libérer de la place.
/clear ou /compact
Restent les deux gestes de nettoyage, souvent confondus, jamais interchangeables.
/clear quand
- vous changez de sujet ou de tâche
- deux corrections viennent de rater
- le fil est encombré de fausses pistes et de code abandonné
- vous pouvez reformuler le besoin en un prompt propre
/compact quand
- la même tâche continue mais le fil devient long
- les décisions prises comptent plus que le détail des échanges
- vous pouvez cibler le résumé : « garde le plan et les choix d'API »
/clear vide tout : brutal, gratuit, sain. Si cette perspective vous inquiète, c'est le signe que des choses importantes ne vivent que dans la conversation, et c'est ça, le vrai problème : les décisions appartiennent à CLAUDE.md ou à la spec, le code à git, les comportements aux tests. /compact, lui, résume le fil pour libérer de la place ; utile en milieu de tâche, à condition de s'en souvenir : un résumé perd toujours quelque chose. Utilisez-le ciblé, en disant ce qui doit survivre. Voici la règle des deux corrections et le /clear en action.
❯ Non, toujours pas. Le menu se ferme encore au clic. · Claude empile une troisième rustine... J'ai ajouté un setTimeout pour retarder la fermeture... ❯ /clear ❯ Le menu mobile se ferme dès qu'on clique dedans. Le ❯ handler « clic extérieur » vit dans Nav.tsx. Un clic ❯ interne ne doit pas le déclencher. Corrige et vérifie. · Claude relit Nav.tsx... Corrigé : le handler ignore les clics issus du menu.
Le setTimeout de la troisième tentative est un signal d'alarme classique.
Quand les corrections deviennent des contorsions, le contexte est déjà perdu.
Le prompt d'après /clear, lui, tient en trois lignes et réussit du premier coup : il nomme le fichier, le mécanisme et la contrainte, tout ce que les deux échecs avaient permis d'apprendre.
Jetable ne veut pas dire éphémère
Une nuance s'impose, sinon ce chapitre laisserait croire qu'une session ne vaut que le temps où elle reste ouverte. Jetable veut dire qu'on peut la vider sans rien perdre d'important, parce que l'important vit ailleurs. Ça ne veut pas dire qu'il faut tout recommencer chaque matin.
Une conversation est enregistrée localement. claude --continue reprend la dernière, claude --resume vous propose la liste, et /rename donne à la session un nom qui vous parlera encore dans trois jours. Le geste utile consiste à traiter les sessions comme des branches : une par chantier, nommée comme lui, reprise quand vous y revenez. Vous cessez alors de payer la réexplication du contexte à chaque retour, ce qui rejoint l'économie du cache de prompt détaillée au chapitre 10.
Chaque erreur est une info
Dernier réflexe, celui qui transforme la discipline en capital. Une erreur de Claude n'est pas seulement à corriger, elle est à capitaliser, et elle a deux destinations possibles.
- Une convention ou un piège du projet« Importer la config via le module dédié, jamais en direct » : elle devient une ligne de CLAUDE.md, comme au chapitre 3. L'erreur ne se reproduira plus, dans aucune session.
- Un comportement qui peut se casserElle devient un test, comme au chapitre 6 : la régression sonnera l'alarme toute seule.
Questions fréquentes sur l'hygiène de session
Pourquoi Claude tourne-t-il en rond sur un bug ?
Presque toujours à cause du contexte, pas du modèle. Après plusieurs tentatives ratées, la conversation contient les fausses pistes, les versions abandonnées et les rustines, et Claude s'appuie sur tout cela autant que sur votre dernière consigne. Chaque nouvel essai aggrave la pollution qui cause les échecs. La sortie n'est pas d'insister : appliquez la règle des deux corrections, faites /clear, et reformulez le problème en un prompt propre qui intègre ce que les échecs vous ont appris.
Quand utiliser /clear ou /compact ?
/clear vide entièrement le contexte : c'est le bon choix quand vous changez de sujet, quand deux corrections ont raté ou quand le fil est pollué de fausses pistes. /compact résume la conversation pour libérer de la place : utile quand la même tâche continue, à condition de l'employer de façon ciblée, en précisant ce qui doit survivre au résumé. Dans le doute, /clear : ce qui mérite d'être conservé doit de toute façon vivre dans un fichier, pas dans la conversation.
Comment reprendre une session Claude Code plus tard ?
Les conversations sont enregistrées localement : claude --continue reprend la dernière, claude --resume affiche la liste pour choisir, et /rename donne à une session un nom réutilisable. La bonne pratique consiste à traiter les sessions comme des branches, une par chantier, ce qui évite de réexpliquer le contexte à chaque retour. Attention à ne pas confondre avec /rewind, qui revient en arrière à l'intérieur d'une session : ses checkpoints ne restaurent que les fichiers modifiés par les outils d'édition de Claude, pas ceux qu'une commande du terminal a touchés. C'est un filet de session, pas un substitut à git.
Comment reprendre une session Claude Code sans tout perdre ?
En ne stockant rien d'important dans la conversation elle-même. Les décisions vont dans CLAUDE.md ou dans une spec versionnée, le code va dans git, les comportements attendus vont dans des tests. Une session devient alors jetable : vous pouvez faire /clear sans état d'âme, la suivante repart de fichiers à jour. Et pour revenir en arrière à l'intérieur d'une session, /rewind ramène le travail à un checkpoint antérieur, avant la mauvaise piste.
À quoi sert la touche Échap pendant que Claude travaille ?
Échap interrompt Claude immédiatement, sans casser la session : vous reprenez la main, précisez ou corrigez la consigne, et il repart. C'est le réflexe à prendre dès que vous le voyez partir dans une mauvaise direction : laisser un agent terminer une mauvaise idée coûte des tokens, du temps, et surtout du contexte pollué qu'il faudra nettoyer ensuite. Interrompre tôt est un geste d'efficacité, pas une impolitesse.
La suiteL'hygiène est en place : cadrer, vérifier, itérer proprement. L'acte III change d'échelle : au chapitre 8, Claude cesse d'être un développeur pour devenir une équipe entière, un rôle à la fois. Et une mise en garde pour la route : au cours de ce chapitre, quelqu'un réussira à annuler le rendez-vous d'un parfait inconnu. Tous les tests étaient verts.
David Silvera
Développeur mobile & web freelance · 15 ans · Android, iOS, React Native, Next.js
Ce guide est tiré de ma pratique quotidienne : ce site lui-même est développé avec Claude, selon la méthode qu'il enseigne. J'accompagne aussi les équipes qui veulent monter en compétence : audit de pratique, formation, mise en place d'outillage.
Discutons de votre équipe