Chaque session d'agent de codage démarre à vide. Claude Code le dit dans sa propre documentation : chaque session commence avec une fenêtre de contexte vierge. L'outil ne se souvient de rien de ce que vous lui avez dit hier, sauf si quelque chose en dehors de la conversation l'a transmis. Apprendre à maintenir le contexte d'une session d'IA à l'autre n'est donc pas une astuce unique ; c'est savoir à laquelle de quatre couches appartient un élément de contexte donné, et l'y placer avant la fin de la session.
Ce guide parcourt les quatre couches dans l'ordre : les fichiers d'instructions que l'outil lit au lancement, les notes que l'outil écrit pour lui-même, la reprise de session, et le compte rendu de travail partagé qu'aucune des trois premières ne fournit. Les trois premières sont des fonctionnalités de Claude Code, Codex et Gemini CLI. La quatrième est là où Sharkly intervient, car une Task qui porte l'objectif, la discussion, les exécutions et la validation est la seule couche qu'une seconde personne peut lire. Si vous hésitez encore entre discuter et assigner, notre guide pour discuter avec un agent IA ou assigner une Task est le volet complémentaire.
TL;DR
Le contexte survit à une session à quatre endroits. Les fichiers d'instructions (CLAUDE.md, AGENTS.md, GEMINI.md) portent les règles que l'outil doit respecter à chaque fois. La mémoire automatique porte les corrections et les préférences que l'outil a apprises. La reprise de session prolonge une conversation pour une seule personne sur une seule machine. Le compte rendu de travail, une Task avec sa description, ses commentaires et son journal d'exécution, porte ce qui a été décidé, ce qui a été exécuté et ce qu'une personne a validé ; c'est la seule couche qui soit partagée. Placez chaque type de contexte dans sa couche et la fenêtre de contexte vierge cesse d'être une perte.
Couche 1 : les fichiers d'instructions que l'outil lit au lancement
Les fichiers d'instructions sont du contexte que vous écrivez une fois et que l'outil charge à chaque session. Chaque CLI majeur en possède un, et leur résolution suit des mécanismes similaires.
| Outil | Fichier | Mode de résolution |
|---|---|---|
| Claude Code | CLAUDE.md (projet ou .claude/CLAUDE.md), ~/.claude/CLAUDE.md (utilisateur), CLAUDE.local.md (personnel, ignoré par git) |
Chargement depuis le répertoire de travail et tous les répertoires parents, concaténés de la racine vers le bas ; les fichiers des sous-répertoires se chargent à la demande |
| Codex | AGENTS.md, avec ~/.codex/AGENTS.md pour la portée globale et AGENTS.override.md pour les remplacements temporaires |
Concaténation depuis la racine Git vers le bas, plafonnée par project_doc_max_bytes, 32 Kio par défaut |
| Gemini CLI | GEMINI.md, avec ~/.gemini/GEMINI.md pour la portée globale |
Découverte globale, par espace de travail et à la volée ; /memory show affiche le résultat fusionné |
Deux habitudes permettent de tirer parti de cette couche. Restez concis : les recommandations de Claude Code visent moins de 200 lignes par fichier, car l'adhérence diminue à mesure que le fichier grossit. Et consignez les faits que vous devriez sinon réexpliquer, comme les commandes de build, les conventions, et la règle que vous avez saisie dans le chat la session précédente. Si un dépôt possède déjà un AGENTS.md, un CLAUDE.md qui ne contient que @AGENTS.md l'importe, si bien que les deux outils lisent une seule source. Tout ce qui se trouve dans cette couche relève du contexte et non de l'application stricte ; la documentation de la mémoire de Claude Code précise clairement que c'est un hook, et non une instruction, qui bloque une action.
Couche 2 : les notes que l'outil écrit pour lui-même
La mémoire automatique de Claude Code est la couche dont on oublie l'existence. Pendant qu'il travaille, Claude enregistre des notes sur votre rôle et vos préférences, les corrections que vous lui fournissez, le contexte du projet qu'il ne peut pas déduire du code, et où trouver des éléments en dehors du dépôt. Elles résident dans ~/.claude/projects/<project>/memory/, indexées par un MEMORY.md dont les 200 premières lignes ou 25 Ko se chargent au début de chaque session. Les fichiers thématiques se chargent à la demande.
Trois limites méritent attention. La mémoire automatique est propre à chaque dépôt, mais partagée entre les worktrees. Elle est locale à la machine, donc les notes de votre ordinateur de bureau n'existent pas sur votre portable. Et elle survit à /compact, car la compaction réécrit la conversation, pas les fichiers sur le disque. Pour voir ce qui a été enregistré, exécutez /memory ; pour la désactiver, définissez autoMemoryEnabled sur false ou exportez CLAUDE_CODE_DISABLE_AUTO_MEMORY=1.
Utilisez cette couche pour le genre de choses que vous dites une fois et attendez qu'elles restent : « toujours utiliser pnpm », « les tests d'API nécessitent un Redis local ». Ne vous y fiez pas pour des décisions dont un coéquipier a besoin ; elle n'appartient qu'à vous.
Couche 3 : la reprise de session
Parfois, le contexte dont vous avez besoin est la conversation elle-même. Claude Code conserve les sessions sur le disque : claude --continue rouvre la conversation la plus récente dans le répertoire courant, claude --resume <id-or-name> en rouvre une précise, et --fork-session crée un nouvel ID de session pour que vous puissiez créer une branche depuis un checkpoint sans l'écraser. Renommez une session avec /rename avant de faire /clear afin de pouvoir la retrouver. Codex propose codex resume pour rouvrir une conversation récente du dépôt courant.
La reprise a un coût. Chaque requête transporte la conversation entière, si bien qu'une session longue consomme plus pour une question d'une ligne qu'une session neuve. /compact avec une instruction de focus, comme /compact Focus on the migration plan, échange du détail contre de la place. Ce qui survit à la compaction, c'est le résumé plus tout ce que les fichiers d'instructions rechargent ; tout ce qui a été fourni uniquement dans la conversation et non résumé est perdu. Considérez la reprise comme un pont le temps d'une pause déjeuner, pas comme la mémoire de l'équipe.
Couche 4 : le compte rendu de travail
Aucune des trois premières couches ne répond à la question qu'un coéquipier pose le jeudi : qu'a fait l'agent mardi, pourquoi, et qui l'a validé ? Les fichiers d'instructions contiennent des règles. La mémoire automatique contient les préférences d'une personne. Une session reprise contient la conversation d'une personne sur une machine. La décision, l'exécution et la validation nécessitent un compte rendu partagé, et ce compte rendu est une Task.
Dans Sharkly, une exécution adossée à une tâche inclut le titre et la description de la Task, les commentaires récents et le commentaire qui a déclenché l'exécution, les instructions et Skills de l'Agent, ainsi que les dépôts configurés pour la Task. C'est cela, le transfert de contexte : l'exécution suivante part de la Task, et non de la mémoire de la session précédente. La progression, les événements de trace et le résultat reviennent dans la Task, et le journal d'exécution consigne pourquoi une exécution a été mise en file d'attente, quand elle a démarré et pris fin, les appels d'outils, la source du déclenchement et les détails d'échec.
Deux règles issues de la documentation produit déterminent où placer les choses, et toutes deux sont des règles de délimitation plutôt que des fonctionnalités. Les sessions de chat d'Agent autonomes appartiennent à la personne qui les a créées et les autres membres n'y ont pas accès ; si l'équipe a besoin d'une conclusion, copiez-la dans la description de la Task ou dans un commentaire. Et le chat d'Agent sur une Task n'est pas un commentaire : il n'apparaît pas dans l'Activité, donc une décision prise à cet endroit reste invisible tant que quelqu'un ne l'écrit pas. Notre présentation de la gestion de projet avec Claude Code montre la Task transportant un changement, depuis la création de l'issue jusqu'à la revue.
Une dernière distinction mérite d'être citée, car c'est exactement le piège dont traite cet article. Un Crew peut activer la réutilisation du répertoire partagé des Tasks, si bien que l'exécution d'un Agent membre ultérieur hérite des modifications locales du membre précédent sur le même Computer. Ce réglage partage l'état du système de fichiers, et non la session du fournisseur de l'Agent précédent. Les fichiers sont transmis ; la conversation du modèle ne l'est pas. Si le second Agent a besoin du raisonnement du premier, celui-ci doit se trouver dans la Task.
Placer chaque type de contexte dans sa couche
| Type de contexte | Couche | Exemple |
|---|---|---|
| Règle valable à chaque session | Fichier d'instructions | Lancer la suite de tests avant de committer |
| Correction ou préférence | Mémoire automatique | Utiliser pnpm, pas npm |
| Exploration inachevée | Reprise de session | Le fil de débogage d'hier |
| Procédure réutilisable partagée par plusieurs Agents | Skill | La checklist de release |
| Objectif, périmètre, critères d'acceptation | Description de la Task | L'exigence en cours de développement |
| Décisions, preuves, résultats de revue | Commentaires de la Task | Pourquoi l'option B a été choisie |
| Ce qui a été exécuté, quand, et comment cela s'est terminé | Journal d'exécution | L'exécution de migration échouée |
Les Skills méritent leur propre ligne. Un Skill regroupe des instructions réutilisables et des fichiers de support pour des consignes destinées à s'appliquer de façon répétée, et un Skill découvert dans un répertoire Runtime local peut être importé dans l'organisation pour qu'il cesse de vivre sur un seul portable. Notre guide sur les Skills dans Sharkly couvre la portée et le rattachement, et notre article sur ce qu'est un skill d'agent de codage couvre le format de fichier.
Utilisez les fichiers d'instructions et la mémoire automatique lorsque le contexte concerne votre façon de travailler. Utilisez une Task lorsque le contexte concerne ce que l'équipe construit et que quelqu'un d'autre pourrait avoir besoin de le lire. Sharkly ne remplace pas Claude Code, Codex ou d'autres outils d'exécution ; il ajoute le compte rendu partagé que ces outils ne conservent pas.
FAQ
Est-ce que /compact fait perdre mon CLAUDE.md ? Non. Le CLAUDE.md à la racine du projet est relu depuis le disque après la compaction. Les instructions fournies uniquement dans la conversation peuvent être perdues ; déplacez-les dans le fichier.
La mémoire automatique est-elle partagée avec mon équipe ? Non. Elle est stockée dans votre répertoire personnel, par dépôt, et jamais synchronisée. Le contexte visible par l'équipe doit figurer dans un fichier d'instructions versionné ou dans une Task.
Un Agent dans Sharkly peut-il se souvenir d'une exécution précédente ? Il reçoit la Task, ses commentaires récents et le commentaire déclencheur à chaque exécution, ce qui constitue la forme durable du souvenir. Il ne reçoit pas la conversation privée de l'exécution précédente. Voir les Agents dans Sharkly pour ce qu'inclut une exécution.
Et les serveurs de mémoire MCP ? Ils ajoutent un cinquième espace de stockage que le modèle peut interroger, utile pour le rappel structurel d'une base de code. Ils n'enregistrent toujours pas qui a validé un changement, donc associez-les à un compte rendu de travail plutôt que de les y substituer.
