Gestion du contexte dans Claude Code : /context, /compact, CLAUDE.md et Obsidian

Vous démarrez une session Claude Code avec une demande précise. Une heure plus tard, Claude relit des fichiers déjà examinés, oublie une décision prise vingt messages auparavant ou applique une ancienne consigne au lieu de votre correction. Pour une personne qui débute, le modèle semble soudain moins compétent.

Le problème vient plus souvent d’une fenêtre de contexte encombrée. La conversation, le contenu des fichiers, les sorties de commandes, les instructions du projet, les outils et les réponses de Claude se partagent un espace de travail limité. Lorsque cet espace contient trop de recherches abandonnées et de journaux volumineux, les faits importants deviennent moins visibles.

Gérer le contexte ne revient donc pas seulement à économiser quelques tokens. Il faut décider de ce dont Claude a besoin pour la tâche actuelle, de ce qui mérite une règle durable, de ce qui peut être résumé et du moment où la conversation doit se terminer. Cette méthode reste utilisable même si les notions de tokens, de mémoire de projet ou de session enregistrée sont nouvelles pour vous.

À retenir

• Lancez /context pour voir ce qui occupe la fenêtre actuelle avant de supposer qu’une longue session est la cause du problème.
• Utilisez /compact lorsque la tâche reste la même mais que la conversation est devenue trop volumineuse. Ajoutez une consigne de focalisation pour préserver les décisions essentielles.
• Utilisez /clear quand vous passez à une tâche sans rapport. L’ancienne conversation reste enregistrée et peut être reprise ; la nouvelle repart sans historique conversationnel et recharge la mémoire du projet.
• Utilisez /memory pour consulter et modifier les instructions persistantes et la mémoire automatique. Pour savoir quels fichiers de mémoire sont réellement chargés, utilisez /context.
• Utilisez /usage pour consulter le coût de la session, les limites du forfait et l’activité. /cost est un alias de /usage ; /stats en est aussi un et ouvre l’onglet Stats.
• Avant une compactation ou un passage de relais, laissez un reçu court avec les décisions, les fichiers, les vérifications et la prochaine action.

La fenêtre de contexte est le bureau de Claude

La fenêtre de contexte rassemble les informations que Claude peut prendre en compte pendant le tour actuel. Imaginez un bureau de travail, pas un stockage permanent. Un bureau rangé contient la tâche, deux fichiers utiles, un message d’erreur court et les critères de réussite. Un bureau saturé contient plusieurs pistes abandonnées, des journaux de build complets, des questions annexes, des lectures en double et des règles contradictoires.

L’espace est consommé par davantage d’éléments que le chat visible :

Ce qui utilise le contexte	Source de bruit	Meilleure habitude
Historique de conversation	Les questions annexes et décisions remplacées restent présentes	Séparer les tâches sans rapport et noter la décision actuelle
Lecture de fichiers	Des répertoires entiers ou de gros fichiers générés sont chargés	Rechercher d’abord, puis lire uniquement les fichiers ou plages utiles
Résultats des outils	Les mêmes tests et longs journaux s’accumulent	Garder la première cause et le résultat final
CLAUDE.md et règles	Des consignes générales, dupliquées ou incompatibles se chargent à répétition	Garder les règles permanentes courtes et limiter les autres par chemin
Skills et descriptions d’outils	Les capacités actives occupent aussi le contexte initial	Ne conserver que les capacités requises pour le travail

Claude Code peut compacter automatiquement la conversation lorsque la fenêtre approche de sa limite. Cela évite un arrêt brutal, mais le résumé automatique doit tout de même choisir ce qui compte. Une compactation manuelle et ciblée avant un changement de phase donne un cap plus clair.

Ce que fait réellement chaque commande

Ces commandes se ressemblent, mais ne résolvent pas le même problème. Saisissez-les au début d’un message dans une session interactive Claude Code.

flowchart TD
  A["Lancer /context"] --> B{"La tâche reste-t-elle la même ?"}
  B -->|Oui| C["Utiliser /compact avec des instructions"]
  B -->|Non| D["Consigner l'état et utiliser /clear"]

/context : inspecter la fenêtre actuelle

/context affiche l’utilisation actuelle sous la forme d’une grille colorée et propose des optimisations pour les outils lourds, la mémoire trop volumineuse et les alertes de capacité. /context all fournit le détail par élément.

/context
/context all

Lancez cette commande au début d’un travail long pour établir une référence, après une grande phase de recherche pour mesurer son poids et avant /compact pour choisir les informations à mettre en avant. Il s’agit d’un diagnostic : afficher la grille ne supprime rien.

/compact [instructions] : résumer et poursuivre

/compact remplace l’historique de conversation par un résumé structuré afin de poursuivre la même tâche avec plus d’espace. Le texte facultatif indique au mécanisme de résumé ce qu’il doit préserver en priorité.

/compact preserve the accepted API contract, changed files, failing test, commands already run, and next action

Utilisez cette commande lorsque l’objectif reste identique. Par exemple, vous corrigez toujours le même problème d’authentification, mais la recherche a produit une longue conversation. Le résumé ne garantit pas la conservation de chaque phrase : les règles critiques doivent déjà se trouver dans CLAUDE.md, une spécification ou une note de transmission.

/clear [nom] : démarrer une autre conversation

/clear ouvre une nouvelle conversation avec un contexte conversationnel vide. Vous pouvez donner un nom à la conversation précédente. Claude Code conserve la mémoire du projet et l’ancienne conversation reste enregistrée pour /resume.

/clear correctif-auth-termine

Utilisez cette commande lorsque la demande suivante possède un autre objectif, d’autres fichiers ou un autre historique de décisions. Une règle simple : si un collègue comprendrait mieux la nouvelle tâche sans lire l’ancienne discussion, créez cette séparation avec /clear.

Le travail antérieur n’est pas supprimé. Les sessions interactives sont enregistrées en continu et peuvent être rouvertes avec /resume, claude --resume ou claude --continue pour la session la plus récente du répertoire.

/memory : consulter les consignes persistantes

/memory répertorie les emplacements de CLAUDE.md et CLAUDE.local.md, permet d’ouvrir ou de créer ces fichiers, affiche les entrées de mémoire automatique et permet d’activer ou de désactiver celle-ci. Cette commande répond à la question : « Où cette information réutilisable doit-elle être conservée ? »

/memory

Elle ne prouve pas que chaque fichier répertorié est actif dans le contexte courant. Lancez /context et examinez la section des fichiers de mémoire pour le vérifier. Le CLAUDE.md du projet est une consigne d’équipe qui peut être versionnée ; la mémoire automatique est une information locale liée au dépôt et partagée entre ses worktrees, mais pas entre plusieurs machines.

/usage, /cost et /stats : inspecter l’utilisation, pas le contexte

/usage présente le coût de la session, les limites du forfait et les statistiques d’activité. Sur les abonnements compatibles, la commande détaille aussi l’utilisation des skills, sous-agents, plugins et serveurs MCP. /cost est un alias de /usage. /stats est également un alias et ouvre l’onglet Stats.

/usage
/cost
/stats

Ces commandes ne répondent pas à la même question que /context. L’utilisation décrit la consommation et les limites ; le contexte montre ce qui occupe actuellement l’espace de travail du modèle. Effacer ou compacter une conversation n’annule pas l’utilisation déjà facturée.

Définir le budget de contexte avant de commencer

Évitez de commencer une grande tâche par « lis tout le dépôt et corrige-le ». Fournissez une fiche courte avec l’objectif, le périmètre, les exclusions, la condition de réussite et les commandes de vérification. Les premières lectures deviennent intentionnelles et la future compactation dispose d’une structure stable.

## Fiche de tâche
- Objectif : corriger la boucle de redirection des sessions expirées.
- Dans le périmètre : src/auth/ et tests/auth/session.test.ts
- Hors périmètre : refonte de l'interface et migration du fournisseur d'identité
- Terminé lorsque : une session expirée redirige une seule fois vers /login et le test de régression réussit
- Vérifier avec : npm test -- tests/auth/session.test.ts
- Approbation humaine requise pour : modifier la durée du cookie ou le comportement de l'API publique

Effectuez une recherche ciblée avant de charger les fichiers. Vous pouvez copier ces commandes dans un terminal et adapter les chemins :

rg -n "expired session|redirect loop|set-cookie" src tests
git diff --stat
git status --short
npm test -- tests/auth/session.test.ts

L’ordre est utile. rg repère les fichiers probables ; git diff --stat et git status révèlent le travail existant à ne pas écraser ; le test ciblé fournit une ligne d’arrivée mesurable. Claude reçoit ainsi quelques éléments pertinents plutôt qu’un instantané complet du dépôt.

Laisser un reçu avant la compactation

Avant /compact, /clear ou un transfert vers une autre session, rédigez un reçu court. Il ne reproduit pas le chat : il contient l’état minimal nécessaire pour poursuivre sans recommencer l’enquête.

## Reçu de transmission
- Objectif :
- Diagnostic actuel :
- Décisions déjà acceptées :
- Fichiers modifiés :
- Commandes exécutées et résultats :
- Modifications non commitées de l'utilisateur à préserver :
- Risque restant :
- Prochaine action :

Conservez ce reçu dans un document du projet s’il doit être partagé, ou placez sa version complétée dans l’instruction de focalisation de /compact. Notez les résultats, pas les sorties brutes. « Le test échoue dans session.test.ts:84 parce que deux redirections sont émises » est exploitable ; deux cents lignes répétées de stack trace ne le sont pas.

Ce qui survit à la compactation

La compactation ne traite pas toutes les informations de la même manière. Le comportement dépend de la façon dont chaque instruction est entrée dans le contexte :

Mécanisme	Comportement après /compact
Prompt système et style de sortie	Restent inchangés, car ils ne font pas partie de l’historique de conversation
CLAUDE.md à la racine et règles non limitées	Sont réinjectés depuis le disque
Mémoire automatique	Est réinjectée depuis le disque
Règles avec un frontmatter paths:	Restent absentes jusqu’à ce que Claude lise un fichier correspondant
CLAUDE.md imbriqué dans un sous-répertoire	Reste absent jusqu’à la lecture d’un fichier de ce sous-répertoire
Contenu des skills invoqués	Est réinjecté dans les limites documentées par skill et au total
Hooks	Continuent à s’exécuter comme du code ; ils ne sont pas du contexte conversationnel

L’information la plus fragile est celle qui n’existe que dans le chat. Le résumé peut la représenter, mais certains détails peuvent disparaître. Si Claude doit toujours respecter une règle, placez-la dans le CLAUDE.md de la racine ou dans un autre fichier persistant adapté. Si une règle ne concerne qu’un dossier, gardez-la ciblée, mais attendez-vous à ce qu’elle ne revienne qu’après la lecture d’un fichier correspondant.

Vous pouvez aussi orienter la compactation depuis CLAUDE.md :

# CLAUDE.md

## Compact instructions
- Preserve the current objective, accepted decisions, and out-of-scope areas.
- Preserve changed files, verification commands, test results, and blockers.
- Keep only log lines that explain the root cause.
- Preserve uncommitted user changes and the next safe action.

Gardez cette section concise. CLAUDE.md consomme lui-même du contexte au début de chaque conversation ; le transformer en manuel exhaustif recrée le problème qu’il doit éviter.

Répartition entre la personne et l’agent

Claude peut inspecter, résumer, rechercher, tester et proposer. Une personne reste responsable des décisions dont les conséquences ne peuvent pas être déduites de façon sûre depuis le dépôt.

Claude Code peut prendre en charge	Une personne doit décider
Trouver les fichiers utiles et réduire un long journal à la cause principale	L’objectif métier et les compromis acceptables
Signaler la pression sur le contexte et suggérer une compactation	Si deux tâches sont réellement liées
Rédiger un reçu à partir du travail observé	Les opérations destructrices, l’usage d’identifiants et les changements en production
Exécuter les vérifications convenues	Les changements de sécurité, de comportement public ou de conservation des données
Mettre à jour une règle après une approbation explicite	Résoudre les exigences contradictoires des parties prenantes

Ne demandez pas à l’agent de décider ce qui ne doit jamais être perdu tout en laissant cette décision dans la conversation déjà encombrée. La personne définit les contraintes durables ; l’agent les consigne à l’endroit convenu et vérifie leur chargement.

Quatre cas d’usage concrets

Cas 1 : refactorisation de l’authentification sur plusieurs fichiers

Situation : l’enquête touche le middleware, les cookies, les tests d’intégration et la configuration de déploiement. Tout charger dans une seule conversation complique l’implémentation.

Périmètre de l’agent : cartographier le chemin d’authentification par recherche, résumer la documentation et conserver dans le contexte principal uniquement le contrat choisi, les fichiers cibles et le résultat du test ciblé.

Décision humaine : approuver les changements de durée des cookies, de déconnexion ou de compatibilité, car il s’agit de décisions produit et sécurité.

Séquence : partez de la fiche, lancez /context après l’enquête, inscrivez la conception acceptée dans le reçu, puis utilisez /compact focus on the accepted auth contract and regression test avant l’édition.

Cas 2 : diagnostiquer un déploiement en échec

Situation : plusieurs tentatives produisent presque les mêmes journaux et la seule ligne utile se perd au milieu des installations et avertissements.

Périmètre de l’agent : comparer les tentatives, isoler la première erreur causale, noter l’environnement et la commande exacte en échec, puis écarter les sorties dupliquées du résumé de travail.

Décision humaine : approuver toute modification des identifiants, de la configuration du fournisseur ou un retour arrière. L’agent peut établir le diagnostic, mais ne doit pas élargir les accès ni modifier la politique de production sans accord.

Séquence : conservez la commande en échec et la ligne causale dans le reçu. Compactez si le même incident continue ; effacez uniquement après vérification du déploiement ou lors du passage à une fonctionnalité distincte.

Cas 3 : produire et relire un article technique

Situation : les sources, règles éditoriales, tests du code, notes de traduction et contrôles visuels peuvent saturer la conversation de rédaction.

Périmètre de l’agent : garder les sources dans une note de recherche, les règles durables dans CLAUDE.md et l’article final en MDX. Il doit restituer les faits confirmés, vérifier le code et les liens, sans inventer d’expérience, de benchmark ni de résultat client.

Décision humaine : choisir le public, la promesse commerciale et l’appel à l’action principal.

Séquence : séparez recherche et rédaction, compactez autour du plan approuvé et notez le slug, les langues, les fichiers, les contrôles et l’état du déploiement dans le reçu.

Cas 4 : passer d’un bug à une nouvelle fonctionnalité

Situation : le correctif est terminé, mais la demande suivante concerne un tableau de bord sans rapport dans le même terminal.

Périmètre de l’agent : présenter le diff final et le résultat des tests, puis proposer une limite nette entre les tâches.

Décision humaine : confirmer qu’aucun suivi du bug ne doit rejoindre la tâche suivante.

Séquence : nommez ou consignez la session terminée, lancez /clear bug-fix-complete, puis commencez le tableau de bord avec une nouvelle fiche. Si un détail est nécessaire plus tard, utilisez /resume au lieu de transporter tout l’ancien historique.

Pièges concrets et corrections

Piège 1 : considérer /compact comme une mémoire parfaite

Le résumé est sélectif et une contrainte citée une fois peut disparaître. Correction : placez les règles durables dans CLAUDE.md ou une spécification et consignez les décisions acceptées avant la compactation.

Piège 2 : utiliser /clear alors que la tâche continue

Un effacement trop précoce retire l’ensemble de travail conversationnel et impose de reconstruire le diagnostic. Correction : si l’objectif et le test d’acceptation sont inchangés, compactez avec une consigne de focalisation ; effacez lorsque la limite entre tâches est réelle.

Piège 3 : croire que /memory montre ce qui est chargé

/memory sert à parcourir et modifier les fichiers persistants. Les fichiers imbriqués et règles ciblées peuvent ne pas être actifs. Correction : vérifiez la section Memory files avec /context et lisez un fichier correspondant si une règle ciblée doit revenir après compactage.

Piège 4 : mettre les contrôles obligatoires uniquement dans CLAUDE.md

CLAUDE.md fournit un contexte, pas une barrière de sécurité stricte. Correction : utilisez les permissions et hooks pour bloquer ou valider les actions ; réservez CLAUDE.md aux conventions courtes du projet.

Piège 5 : utiliser la mémoire automatique comme documentation d’équipe

La mémoire automatique reste locale à la machine. Elle est partagée entre les worktrees du même dépôt, mais pas avec les machines des collègues. Correction : placez les conventions partagées dans CLAUDE.md, les règles ou la documentation versionnée.

Piège 6 : confondre utilisation et contexte disponible

/usage peut afficher les coûts et limites alors que /context montre une fenêtre encombrée ou libre. Correction : utilisez /context pour choisir entre réduction, délégation, compactage et effacement ; utilisez /usage pour surveiller la consommation et les limites du forfait.

La place d’Obsidian et des fichiers du projet

Toutes les notes utiles ne doivent pas être chargées en permanence par Claude. Obsidian convient mieux aux recherches longues, pistes alternatives, comptes rendus et idées futures. Le dépôt convient mieux aux instructions partagées, spécifications, transmissions et contenus publiés.

Emplacement	Contenu adapté
CLAUDE.md du projet	Règles courtes utiles dans la plupart des sessions
.claude/rules/	Instructions limitées à un type de fichier ou un chemin
Documentation du projet	Décisions, spécifications et reçus partagés
Obsidian	Recherches longues, hypothèses, sources et idées en attente
Mémoire automatique	Préférences locales et découvertes récurrentes

Pour approfondir cette organisation, consultez le guide des bonnes pratiques de CLAUDE.md, le guide d’optimisation des tokens et le guide d’intégration de Claude Code avec Obsidian.

Une routine simple à chaque session

1. Cadrer : indiquez l’objectif, le périmètre, les exclusions, le test final et les validations humaines.
2. Réduire : recherchez d’abord et ne chargez que les fichiers et sorties nécessaires à la prochaine décision.
3. Inspecter : lancez /context après une recherche importante ou lorsque Claude commence à répéter son travail.
4. Consigner : notez les décisions, fichiers modifiés, vérifications et prochaine action.
5. Choisir : utilisez /compact pour la même tâche, /clear pour une nouvelle tâche et /resume pour reprendre un travail enregistré.

Pour réutiliser ce processus sans réécrire les modèles à chaque fois, consultez le guide pratique de prompts pour Claude Code.

Références officielles

• Explorer la fenêtre de contexte
• Référence des commandes
• Comment Claude mémorise votre projet
• Gérer les sessions

Ce que nous avons vérifié

Pour cette révision, nous avons comparé les noms des commandes et leurs alias actuels à la référence officielle : /cost et /stats redirigent tous deux vers /usage, et /stats ouvre l’onglet Stats. Nous avons aussi contrôlé dans le tableau officiel de la fenêtre de contexte ce qui est réinjecté après compactage et ce qui attend la lecture d’un fichier correspondant. Enfin, la documentation des sessions confirme que /clear démarre une nouvelle conversation sans supprimer la précédente et que le travail enregistré reste accessible avec les commandes de reprise. Les extraits de terminal et reçus Markdown ci-dessus sont des modèles prêts à copier ; adaptez les chemins et commandes de test au dépôt concerné.