Claude Code perd le contexte entre les sessions : garder décisions et tâches d'un projet

Lundi, vous passez deux heures avec Claude Code à choisir comment gérer les remboursements partiels d’une boutique. Mardi matin, vous ouvrez une nouvelle session et Claude propose exactement la solution que vous aviez écartée la veille. Ce n’est pas une panne : c’est le fonctionnement normal de l’outil. Comprendre ce qui est gardé, et ce qui ne l’est pas, permet de choisir où écrire chaque information pour qu’elle survive.

Pourquoi chaque session repart de zéro

La documentation de Claude Code le dit sans détour : chaque nouvelle session démarre avec une fenêtre de contexte vide, sans l’historique des conversations précédentes. La fenêtre de contexte, c’est tout ce que le modèle « voit » à un instant donné : vos messages, ses réponses, les fichiers lus, les sorties de commandes, les instructions système.

Au lancement, Claude Code y charge quelques éléments seulement :

• vos fichiers CLAUDE.md ;
• le début de la mémoire automatique (le fichier MEMORY.md) ;
• des informations sur l’environnement et l’état git du dépôt ;
• la liste des outils et des serveurs MCP disponibles.

Tout ce qui a été dit dans les conversations précédentes, en revanche, n’y est pas. La décision de lundi n’existe plus pour Claude, sauf si elle a été écrite quelque part qu’il relit.

La compaction : quand la session elle-même oublie

Le problème existe aussi à l’intérieur d’une seule session. La fenêtre de contexte se remplit vite, et la documentation indique que les performances baissent à mesure qu’elle se remplit : Claude peut « oublier » des consignes données au début ou faire davantage d’erreurs.

À l’approche de la limite, Claude Code fait de la place automatiquement. Il efface d’abord les anciennes sorties d’outils, puis résume la conversation si nécessaire. Vos demandes et les extraits de code importants sont conservés, mais les consignes détaillées données tôt dans la conversation peuvent disparaître.

Après une compaction, voici ce qui revient et ce qui se perd :

Élément	Après compaction
CLAUDE.md à la racine du projet	Relu sur le disque et réinjecté
Mémoire automatique, outils MCP	Rechargés automatiquement
Fichiers lus ou modifiés pendant la session	Jusqu’à cinq relus, les plus récemment modifiés d’abord ; un fichier trop long revient comme simple référence
CLAUDE.md des sous-dossiers, règles limitées à certains chemins	Résumés avec le reste, rechargés quand Claude lit, écrit ou modifie un fichier concerné
Consignes données seulement dans la conversation	Remplacées par le résumé, avec un risque de perte

La conclusion de la documentation est simple : une règle qui doit durer va dans CLAUDE.md, pas dans la conversation.

Ce que Claude Code propose aujourd’hui

Les fichiers CLAUDE.md, à plusieurs niveaux

CLAUDE.md est un fichier Markdown que vous écrivez et que Claude lit au début de chaque session. Il existe à quatre niveaux, chargés du plus large au plus précis :

• politique gérée par l’organisation (par exemple /etc/claude-code/CLAUDE.md sous Linux), pour tous les utilisateurs d’une machine ;
• utilisateur, ~/.claude/CLAUDE.md, pour vos préférences dans tous vos projets ;
• projet, ./CLAUDE.md ou ./.claude/CLAUDE.md, partagé avec l’équipe par git ;
• local, ./CLAUDE.local.md, vos réglages personnels pour ce projet, à exclure de git.

La commande /init génère un premier fichier à partir du code, /memory liste et ouvre les fichiers chargés, /context montre ce qui occupe la fenêtre.

Les limites sont connues. Claude traite ces fichiers comme du contexte, pas comme une configuration imposée. La documentation conseille de rester sous 200 lignes par fichier : au-delà, le fichier coûte plus de contexte et les consignes sont moins bien suivies. Elle recommande d’y mettre les décisions d’architecture propres au projet, mais d’en exclure les informations qui changent souvent. Une liste de tâches en cours n’a donc pas sa place ici.

La mémoire automatique

En plus de CLAUDE.md, Claude Code prend lui-même des notes : vos corrections, vos préférences, des commandes qu’il a apprises. Elle est activée par défaut en session locale et se règle avec /memory. Les notes sont rangées dans ~/.claude/projects/<projet>/memory/, un dossier par dépôt git ; les 200 premières lignes ou les 25 premiers Ko de MEMORY.md sont chargés à chaque session.

Limites : Claude décide seul de ce qui mérite d’être retenu, et ne note rien à chaque session. Surtout, cette mémoire reste sur votre machine : elle n’est partagée ni entre machines, ni avec les environnements cloud, ni avec vos collègues.

Reprendre une session

Claude Code enregistre chaque conversation dans un fichier local. Vous pouvez donc reprendre là où vous en étiez :

claude --continue          # rouvre la conversation la plus récente du dossier
claude --resume            # ouvre la liste des sessions
claude -n refonte-paiement # démarre une session nommée
claude --resume refonte-paiement

Une session reprise retrouve tout son historique, appels d’outils compris. C’est pratique pour une tâche étalée sur deux jours. Mais ces transcriptions sont locales, rattachées à un dossier, et supprimées par défaut au bout de 30 jours. Sur les offres Pro et Max, quand vous reprenez une session de plus de 100 000 tokens restée inactive plus d’une heure, Claude Code propose de repartir d’un résumé : chaque échange coûte alors moins cher, mais avec la même perte qu’une compaction. Et l’application de bureau, claude.ai/code et l’extension VS Code tiennent chacune leur propre liste de sessions.

Les commandes de gestion du contexte

• /clear vide le contexte entre deux tâches sans rapport ; la conversation précédente reste reprenable avec /resume.
• /compact remplace l’historique par un résumé, que vous pouvez orienter : /compact concentre-toi sur les changements d'API.
• Une section « Compact Instructions » dans CLAUDE.md indique ce qui doit toujours survivre au résumé, par exemple la liste des fichiers modifiés.

Les pratiques qui marchent

Un fichier de passation en fin de session

Une pratique consiste à terminer une session en demandant à Claude d’écrire une note de passation. Le modèle proposé par ClaudeCodeLab contient l’objectif (et ce qui en est exclu), l’état actuel (branche, fichiers modifiés), ce qui a changé et pourquoi, ce qui a été vérifié et surtout ce qui ne l’a pas été, les risques, et la consigne à donner à la session suivante. Son script range chaque note, datée, dans un dossier handoffs/. La session suivante commence par comparer la note à git status, puis reprend les vérifications restées en suspens.

La répartition est claire : CLAUDE.md porte les règles durables, le fichier de passation porte l’état temporaire de la tâche.

Un journal de décisions

Une décision prise en séance (« on garde les remboursements partiels côté back-office, pas côté API ») se perd dès que la session se termine. Un fichier docs/decisions.md, avec une entrée datée par décision, sa raison et les options écartées, évite de rouvrir le débat. Vous pouvez demander à Claude de l’alimenter au fil de l’eau et de le relire avant toute modification touchant le sujet.

Découper le travail

La documentation recommande de séparer exploration, plan et réalisation, et de faire écrire une spécification (SPEC.md) avant d’ouvrir une session neuve pour l’implémenter. Des sessions courtes, une par sujet et bien nommées, compactent moins et laissent une trace plus lisible qu’une seule session fourre-tout.

Ce qui manque quand on est plusieurs

Toutes ces pratiques reposent sur des fichiers dans le dépôt ou sur votre disque. Pour une personne seule sur un dépôt, cela suffit souvent. Dès que l’équipe grandit ou que le travail déborde du code, des trous apparaissent :

• Les décisions prises ailleurs ne rentrent pas dans le dépôt. Le choix arrêté avec le client en réunion, ou dans une conversation sur claude.ai, n’atterrit dans aucun CLAUDE.md, sauf si quelqu’un pense à le recopier.
• La mémoire automatique et les sessions sont personnelles. Ce que Claude a appris avec vous ne sert pas à votre collègue, et ses sessions ne sont pas les vôtres.
• Les fichiers de passation se contredisent. Deux personnes, deux branches, deux notes de passation : laquelle fait foi ?
• Les tâches n’ont ni responsable ni statut partagé. Une liste dans un fichier Markdown ne dit pas qui s’en occupe, ni ce qui a avancé depuis hier.
• Pas d’historique commun. On ne retrouve pas facilement pourquoi une règle a changé il y a trois mois, ni qui l’a décidé.

Le besoin, c’est un endroit hors du dépôt, lisible par chaque personne et par chaque assistant, où décisions et tâches sont écrites une fois.

Brancher une mémoire partagée par MCP

MCP (Model Context Protocol) permet de relier Claude Code à un service externe : Claude y lit et y écrit comme il lit vos fichiers. Pour un serveur distant, la commande est :

claude mcp add --transport http <nom> <url>

Par défaut, le serveur n’est disponible que pour vous dans le projet courant. Avec --scope user, il l’est dans tous vos projets ; avec --scope project, la configuration est écrite dans un .mcp.json à la racine du dépôt, partagé par git. Si le serveur demande une connexion OAuth, lancez /mcp dans Claude Code et suivez les étapes dans le navigateur.

Plusieurs types de serveurs existent : des serveurs de mémoire open source qui tournent sur votre machine, adaptés à un usage individuel, ou des outils d’équipe qui exposent leurs données par MCP.

Tavimi, pour le cas de l’équipe

Tavimi est la mémoire de travail partagée par une équipe et ses assistants IA, via MCP. Chaque projet a son espace, où l’on invite des personnes par courriel. Les notes y sont versionnées et rangées par catégories (décision, piège, référence), chacune avec ses titres obligatoires. Les tâches portent un statut, une échéance, un responsable et un journal daté. Quand un choix lui manque, l’agent pose la question sur la tâche plutôt que de deviner, et un humain y répond depuis l’interface web.

Le même espace est lu par Claude Code, par Claude sur claude.ai et par Claude Desktop :

claude mcp add --transport http tavimi https://app.tavimi.com/mcp

La connexion se fait ensuite par OAuth avec /mcp, en cochant les espaces que l’assistant peut voir. Le fonctionnement est détaillé sur la page Comment ça marche, et le cas des équipes de développement sur la page e-commerce. CLAUDE.md garde son rôle pour les règles du dépôt ; Tavimi prend ce qui doit être partagé au-delà.