Claude Code : quand utiliser /compact et quand ouvrir une nouvelle session

Dans Claude Code, /compact résume les parties les plus anciennes de la conversation sous une forme plus courte et structurée. La commande libère ainsi de la place dans la fenêtre de contexte active tout en essayant de conserver l’objectif, les décisions importantes et l’état actuel du projet. Elle est surtout utile lorsque la tâche n’a pas changé et que l’approche reste bonne, mais que les logs, sorties d’outils, diff et discussions intermédiaires ont rendu la session trop lourde.

Cependant, /compact ne répare pas automatiquement une session déjà confuse. Après la compaction, le contexte actif ne contient plus chaque détail ancien mot pour mot. Un message d’erreur exact, une piste déjà rejetée, une contrainte temporaire ou une instruction donnée uniquement dans le chat peuvent devenir moins visibles. Si Claude mélange plusieurs tâches, répète une solution qui a échoué ou s’appuie sur une hypothèse d’architecture erronée, il est généralement plus sûr de préparer un transfert court et de repartir dans une session propre.

Que fait /compact dans Claude Code et dans Claude Web ?

Dans Claude Code, /compact résume les anciens échanges et libère du contexte sans modifier à lui seul les fichiers du projet. Claude Code peut aussi déclencher automatiquement une compaction lorsque la limite approche, et vous pouvez lancer la commande manuellement avant que la session devienne lente ou trop bruyante.

Les conversations classiques de Claude Web ne proposent pas de commande /compact à l’utilisateur. Lorsque l’exécution de code est activée et qu’une longue conversation approche de la limite de contexte, Claude peut résumer automatiquement les messages anciens et continuer. L’interface peut parfois indiquer que Claude « organise ses idées ». L’historique complet est conservé, mais le contexte de travail actif utilise un résumé au lieu de renvoyer toute la transcription mot à mot.

Question	Claude Code	Claude Web
Déclenchement	Manuellement avec /compact ou automatiquement	Gestion automatique près de la limite
L’utilisateur peut-il lancer la même commande ?	Oui	Non, aucune commande de chat équivalente
La conversation continue-t-elle ?	Oui, dans la même session	Oui, dans le même chat
Objectif principal	Libérer du contexte pour poursuivre la même tâche de développement	Prolonger les longues conversations avec moins d’interruptions
Risque principal	Les erreurs exactes et contraintes présentes seulement dans le chat peuvent être atténuées dans le résumé	Les anciens détails peuvent être moins présents dans le contexte actif

/compact, /clear, /rewind ou nouvelle session : que choisir ?

Choix	Ce qui change	Quand l’utiliser	Quand l’éviter
Continuer	Aucun reset ni résumé	Claude se souvient du symptôme, des contraintes et de la dernière preuve	La session boucle, mélange des tâches ou reprend des idées rejetées
/compact	Résume les anciens tours, libère du contexte et conserve la session	Même tâche, bonne direction, mais trop de logs ou de sorties d’outils	La compréhension centrale est fausse ou les détails historiques exacts sont indispensables
/clear	Démarre une conversation vide dans le processus actuel ; l’ancienne session reste accessible via /resume	Vous voulez un chat propre sans changer le répertoire de travail ni les fichiers	Vous devez annuler des modifications de code ; /clear ne restaure pas les fichiers
/rewind	Ouvre des checkpoints pour restaurer le code, la conversation ou résumer une plage choisie	Les derniers tours ont dévié et vous identifiez un bon checkpoint	Les changements viennent de Bash, d’outils externes, d’éditions manuelles ou de la plupart des sous-agents
Session séparée	Repart avec un contexte propre dans un autre terminal, une autre fenêtre ou un workspace isolé	Changement de tâche, nouvelle réflexion d’architecture ou travail parallèle	Le seul problème est un excès de logs dans une session qui comprend encore bien la tâche

/clear démarre déjà une nouvelle conversation vide. Dans ce guide, « session séparée » désigne une frontière plus volontaire : un autre terminal ou une autre fenêtre, éventuellement une branche ou un worktree distinct, et un transfert explicite ne contenant que des faits vérifiés.

Commencez par distinguer un problème de contexte d’un problème de diagnostic

Imaginons une correction d’import CSV. Si amount est vide, le système doit renvoyer une erreur de validation et ne rien écrire. Claude a déjà modifié le handler deux fois, rouvert les mêmes fichiers et propose maintenant de reprendre la première implémentation.

Ne compactez pas et ne redémarrez pas tout de suite. Lancez d’abord le test le plus ciblé :

npm test -- tests/import/empty-amount.test.ts

Interprétez ensuite le résultat :

• Le test n’existe pas ou vérifie un autre comportement : le premier problème est une spécification ambiguë ou une reproduction insuffisante. Une nouvelle session ne créera pas de preuve.
• Le test reproduit correctement le symptôme et Claude exploite bien le résultat : continuez dans la session actuelle.
• Le test échoue de façon stable, mais Claude oublie des causes déjà exclues, élargit la portée ou répète d’anciennes idées : une dégradation du contexte devient probable.

Il n’existe aucun nombre officiel de tokens ou de messages qui fixe le bon moment pour compacter. Utilisez 60 % à 80 % de contexte occupé comme rappel pour examiner la session, pas comme seuil rigide. Le signal le plus fiable reste le comportement : Claude peut-il encore énoncer précisément l’objectif, les contraintes, les faits vérifiés et la prochaine commande de validation ?

Quand faut-il exécuter /compact ?

Préférez /compact lorsque toutes les conditions suivantes sont réunies :

1. Vous travaillez toujours sur la même tâche et le même dépôt.
2. Claude comprend correctement l’objectif et les fichiers autorisés.
3. La direction actuelle est étayée par des tests ou des logs, et non par une simple supposition.
4. Le contexte est surtout occupé par de longs logs, des sorties de build, des diff répétés ou des discussions intermédiaires.
5. Les faits à ne pas perdre peuvent tenir en quelques phrases.

Avant de compacter, inspectez l’arbre de travail :

git status --short
git diff

Exécutez ensuite /context pour voir si la fenêtre est consommée par les messages, les outils, les définitions MCP ou CLAUDE.md. Si le vrai problème est un premier prompt gigantesque, de grosses pièces jointes, trop de définitions d’outils ou un fichier mémoire surdimensionné, il peut ne pas y avoir assez d’anciens tours à résumer.

Le CLAUDE.md à la racine du projet est rechargé après /compact. Les instructions qui n’existaient que dans la conversation sont moins durables. Placez les règles permanentes dans un CLAUDE.md concis et reformulez explicitement les faits propres à la tâche avant et après la compaction.

Vérifiez le contexte immédiatement après la compaction

Ne laissez pas Claude modifier des fichiers juste après /compact. Envoyez d’abord ce prompt de contrôle :

Nous venons de compacter le contexte. Avant de modifier le moindre fichier, réponds à quatre questions :
1. Quel symptôme précis corrigeons-nous et quel résultat attendons-nous ?
2. Quelle approche a déjà été testée puis rejetée, et pourquoi ?
3. Quels fichiers peuvent être modifiés et qu’est-ce qui ne doit pas changer ?
4. Quelle unique commande allons-nous exécuter ensuite pour tester l’hypothèse ?

Si une réponse ne peut pas être déduite du contexte actuel, indique l’information manquante au lieu de l’inventer.

Dans l’exemple, Claude doit au minimum rappeler que :

• un amount vide doit produire une erreur de validation sans écriture de données ;
• Number(value || 0) a été rejeté, car il transforme une valeur vide en zéro valide ;
• la portée est limitée au parser et au test ciblé ;
• l’étape suivante est un test étroit ou une commande de traçage, pas une refonte complète du système d’import.

Si les réponses sont exactes, poursuivez dans la même session. Si elles sont vagues, reprennent la solution rejetée ou ajoutent le README et le format CSV public au périmètre, ne faites pas confiance au résumé. Préparez un transfert, puis utilisez /clear ou une session séparée.

Quand /compact n’est pas le bon outil

1. La tâche a changé

Vous avez commencé par un bug de validation, puis ajouté une mise à jour du README, un changement de déploiement et un second problème d’API. La compaction résumera tout ensemble ; elle ne créera pas de frontières nettes. Déplacez la deuxième tâche vers une autre session.

2. L’hypothèse centrale de Claude est déjà fausse

Si Claude continue de traiter une valeur vide comme zéro ou comprend mal le chemin d’écriture, le problème n’est pas seulement la longueur de la conversation. Une session propre, ancrée dans des faits vérifiés, est souvent plus rapide.

3. Des détails exacts doivent être conservés mot pour mot

Certaines lignes d’erreur, requêtes SQL, positions dans la stack, champs de protocole ou contraintes de sécurité ne peuvent pas dépendre uniquement d’un résumé. Conservez le fragment minimal nécessaire dans la note de transfert ou un fichier local.

4. Une seule entrée est déjà trop volumineuse

Si le premier prompt contient un énorme log, des pièces jointes ou de nombreuses définitions d’outils, il n’existe pas de conversation antérieure à plusieurs tours à compacter. Réduisez l’entrée, référencez les fichiers par leur chemin ou désactivez les serveurs MCP inutiles.

5. Il ne reste même plus assez de place pour produire le résumé

/compact peut échouer si la fenêtre est tellement remplie que le résumé lui-même ne tient plus. Appuyez deux fois sur Esc, revenez de quelques tours et réessayez. Si cela échoue encore, utilisez /clear ; la session précédente restera accessible via /resume.

Quand /rewind est-il préférable à /compact ?

Utilisez /rewind, ou appuyez deux fois sur Esc lorsque le champ de saisie est vide, si le problème se concentre dans les derniers tours. Le menu de checkpoints permet de :

• restaurer à la fois le code et la conversation ;
• restaurer la conversation en conservant les fichiers actuels ;
• restaurer le code en conservant la conversation ;
• résumer l’historique à partir d’un point choisi ;
• résumer tout ce qui précède un point choisi.

C’est utile lorsque les trois derniers tours ont dévié, mais que le contexte plus ancien reste correct.

Les checkpoints suivent principalement les modifications effectuées par les outils d’édition de fichiers de Claude. Les changements issus de commandes Bash, de programmes externes, d’éditions manuelles ou de la plupart des sous-agents peuvent ne pas être restaurés. Ils ne remplacent pas non plus Git : utilisez des branches, des commits ou vérifiez au minimum git diff aux étapes importantes.

Comment transférer la tâche en toute sécurité vers une nouvelle session

La nouvelle session n’a pas besoin de toute la transcription. Elle a besoin de faits vérifiés, de l’état actuel des fichiers et d’une seule prochaine étape.

Commencez par vérifier :

git status --short
git diff

Puis envoyez un transfert concis :

Objectif : un amount vide renvoie une erreur de validation et n’écrit aucune donnée.
Arbre de travail : vérifier d’abord git status et git diff ; ne pas supposer qu’il est propre.
Fichiers cibles : parser/amount.ts, tests/import/empty-amount.test.ts
Reproduction : npm test -- tests/import/empty-amount.test.ts
Résultat actuel : le test échoue.
Approche rejetée : Number(value || 0), car elle transforme une valeur vide en zéro.
Contraintes : ne pas modifier le format CSV public et ne pas refactoriser les modules sans rapport.
Question ouverte : à quelle couche distinguer une valeur vide d’un 0 légitime ?
Étape suivante : suivre value du CSV parser jusqu’à la validation branch et proposer une seule hypothèse vérifiable.

Avant toute modification, reformuler l’objectif, les contraintes, l’approche rejetée et la prochaine commande de validation.

N’incluez pas d’API Key, de cookies, de contenu .env, de données personnelles ni de logs bruts complets. Si une ligne d’erreur est nécessaire, conservez uniquement le fragment minimal et le chemin du log local.

Décider en une minute

1. Reproduire d’abord. Exécutez le test ou la commande la plus petite qui prouve le symptôme.
2. La session reste-t-elle précise ? Si Claude se souvient de l’objectif, des contraintes et du dernier résultat, continuez.
3. Le problème est-il surtout du bruit ? Même tâche, bonne direction et trop de logs : utilisez /compact.
4. Seuls les derniers tours sont-ils mauvais ? Utilisez /rewind pour restaurer ou résumer une zone ciblée.
5. La tâche a-t-elle changé ou la compréhension s’est-elle dégradée ? Utilisez /clear ou une session séparée avec transfert.
6. Vérifier avant de modifier. Faites reformuler les faits à Claude avant d’autoriser de nouveaux changements.

Questions fréquentes

Que fait exactement /compact dans Claude Code ?

La commande résume l’ancienne partie d’une conversation multi-tour dans une représentation plus courte, afin de libérer de la place et de poursuivre la même session. Elle ne modifie pas elle-même les fichiers du projet.

/compact supprime-t-il le chat original ou le code ?

Son objectif est de compacter le contexte actif, pas de supprimer du code. La transcription de la session reste disponible, mais les tours suivants s’appuient surtout sur le résumé et le contenu actif ; les détails critiques doivent donc être vérifiés explicitement.

Quand utiliser /compact plutôt qu’une nouvelle session ?

Utilisez /compact si la tâche et l’approche restent correctes et que le principal problème vient des logs ou sorties intermédiaires accumulés. Recommencez si les tâches se mélangent, si des solutions rejetées réapparaissent, si des contraintes se perdent ou si l’architecture est mal comprise.

Que signifie Compact dans Claude Web ?

Claude Web peut résumer automatiquement les anciens messages lorsqu’un long chat approche de la limite de contexte. Ce n’est pas la commande /compact de Claude Code et cela ne demande généralement aucune action manuelle. La gestion automatique du contexte dépend de l’activation de l’exécution de code.

Quelle différence entre /clear et l’ouverture d’un autre terminal ?

/clear démarre une conversation vide dans le processus Claude Code actuel, tandis que l’ancienne session peut être reprise avec /resume. Un autre terminal ou une autre fenêtre convient mieux à l’isolation des tâches, au travail parallèle ou à une branche ou un worktree séparé.

Références officielles

• Mode interactif de Claude Code et /clear
• Checkpoints et /rewind dans Claude Code
• Erreurs de limite de contexte et /compact
• Comportement de CLAUDE.md après compaction
• Claude Web : limites d’usage, de longueur et gestion automatique du contexte