Mémoire des agents : ce que les tests d’Anthropic sur le « dreaming » changent pour Claude Code

En une phrase : Anthropic montre qu’un agent se souvient mieux quand il écrit peu, juge lui-même ce qui compte et fait relire ses notes à froid ; dans Claude Code, cette relecture reste à votre charge.

Le 6 novembre 2026, Anthropic a publié « The components of agent memory », un billet de son équipe d’ingénierie signé Lance Martin. Il décrit comment Claude garde des connaissances d’une session à l’autre, et surtout le « dreaming » : une phase menée hors conversation où le modèle relit ses journaux pour corriger et réorganiser ses notes. Le billet s’appuie sur plusieurs évaluations internes, de Pokémon Rouge à des dossiers juridiques.

La question utile pour un développeur qui utilise un agent de code n’est pas « Claude rêve-t-il ? », mais : quels gains sont mesurés, dans quelles conditions, et que peut-on en tirer dès maintenant dans Claude Code ? Le Latent n’a refait aucune des expériences : les chiffres ci-dessous sont ceux d’Anthropic et de l’article de recherche cité, relus le 7 novembre 2026.

Ce qu’Anthropic appelle mémoire

Le billet définit la mémoire d’agent comme ce que Claude apprend par l’expérience et conserve entre deux sessions, sous forme de texte qu’il peut relire. Elle exclut trois autres mécanismes : la modification des poids du modèle, l’apprentissage à l’intérieur d’une seule conversation et la compaction (le résumé qui remplace les anciens échanges quand la fenêtre de contexte est pleine). Concrètement, ce sont des fichiers dans un dossier, que Claude écrit, relit et réorganise.

Le « dreaming » reprend une idée publiée en avril 2025 par Letta et l’université de Berkeley sous le nom de « sleep-time compute » : utiliser le temps mort entre deux interactions pour retravailler le contexte déjà disponible. Anthropic l’applique à quatre usages : corriger une note fausse, construire un wiki de pages liées, faire remonter certaines notes pour qu’elles soient chargées d’office, et orienter la mémoire vers un objectif.

Les résultats publiés, tâche par tâche

Source : billet d’Anthropic, 6 novembre 2026, relevé le 7 novembre 2026.

Trois enseignements ressortent. D’abord, les modèles récents mémorisent mieux en écrivant moins : Sonnet 3.7 archivait tout, y compris ce qui s’affiche déjà à l’écran, et passait son temps à fouiller ses propres fichiers (17 étapes à créer et supprimer des fichiers sans jouer, relève Anthropic). Ensuite, les consignes rigides nuisent aux modèles les plus forts : imposer « n’enregistrer que les échecs » a fait perdre à Opus 5 et Opus 4.7 une bonne partie du gain apporté par la mémoire, alors que le même type de pilotage aide les modèles plus anciens. Enfin, la qualité dépend de l’organisation : dans la tâche sur les contrats, ce sont des agents qui écrasaient le travail des autres dans une table commune qui ont fait disparaître 16 faits (57 moins 41, calcul du Latent).

Ce que les chiffres ne montrent pas

Le billet est honnête sur ses limites, mais elles se lisent en fin de section. Sur une tâche LAB où chaque critère pouvait être retrouvé par simple recherche dans un seul document, le wiki n’a apporté aucun gain net. Sur une autre, il a fini plus volumineux que les documents qu’il devait résumer, ce qu’Anthropic compare à la carte à l’échelle 1 de Borges. D’après les chiffres d’Anthropic, le wiki seul plafonne à 48 %, sous la recherche seule (53 %) : il complète la recherche, il ne la remplace pas, une logique proche de la génération augmentée par la recherche.

L’article fondateur de Letta et Berkeley, que le billet cite sans en reprendre les chiffres, précise où la méthode paie. Sur ses jeux de calcul mathématique, préparer le contexte à l’avance permet d’atteindre la même précision avec environ cinq fois moins de calcul au moment de la question, et jusqu’à 13 % et 18 % de précision en plus en augmentant ce travail préalable. Le coût moyen par question baisse de 2,5 fois quand dix questions portent sur le même contexte. Mais sur leur cas d’agent de programmation, le gain se limite à environ 1,5 fois moins de tokens avec un petit budget, et la méthode classique redevient meilleure quand le budget est élevé. Les auteurs concluent que la préparation à froid sert surtout quand les questions futures sont prévisibles à partir du contexte.

Ce dernier point recoupe le constat d’Anthropic sur les tâches juridiques : le wiki aide quand il faut croiser plusieurs documents, pas quand une recherche ciblée suffit. Enfin, plusieurs modèles cités (Fable 5, Opus 5.5, Sonnet 5.5) ne sont décrits que par une ou deux phrases, et Anthropic ne publie ni le protocole complet ni les écarts entre exécutions : ce sont des résultats d’une seule partie de Pokémon par modèle, comme le précise le billet.

Ce que ça change dans Claude Code aujourd’hui

Le billet ne dit pas que le « dreaming » est disponible dans Claude Code. Il présente la mémoire automatique de l’outil comme une illustration de couche injectée maintenue petite, « avec Claude qui l’entretient pendant la session ». La documentation de Claude Code décrit deux mécanismes, tous deux chargés au début de chaque session :

Source : documentation Claude Code, relevée le 7 novembre 2026.

La même documentation relève qu’un fichier d’instructions plus long consomme plus de contexte et « réduit l’adhésion » aux consignes, ce que le billet d’Anthropic rappelle aussi. Elle précise que la mémoire du fil principal n’est pas transmise aux sous-agents, sauf en cas de fork, et que Claude Code supprime les anciennes transcriptions de session après la durée de conservation réglée par cleanupPeriodDays, sans toucher aux fichiers de mémoire.

Ce dernier détail a une conséquence que ni le billet ni la documentation ne formulent (lecture du Latent) : la correction par « dreaming » décrite par Anthropic repose sur la transcription d’origine, qui sert de vérité de référence pour vérifier une note. Une note fausse peut donc survivre dans MEMORY.md à la transcription qui aurait permis de la corriger, et elle sera rechargée à chaque session, comme la note erronée sur le Centre Pokémon du mont Sélénite qui a fait échouer une partie entière dans l’expérience d’Anthropic.

Que faire, selon votre usage

• Vous codez seul avec Claude Code : laissez la mémoire automatique active, mais ouvrez de temps en temps /memory pour relire et supprimer les notes périmées. C’est le rôle que joue le « dreaming » dans les tests d’Anthropic, et rien n’indique qu’il soit automatisé dans l’outil.
• Vous écrivez un CLAUDE.md d’équipe : dites à quoi sert la mémoire plutôt que de fixer ce qu’il faut y mettre. Avec les modèles récents, une règle comme « n’enregistrer que les échecs » a fait perdre une partie du gain, selon Anthropic. Gardez le fichier court.
• Vous travaillez avec un modèle plus ancien : l’inverse vaut. Demander explicitement de relire la mémoire avant de répondre et de tester ses hypothèses a presque doublé le score de Sonnet 4.6.
• Vous construisez un agent sur un gros fonds documentaire : un wiki entretenu par l’agent vaut l’effort quand les questions croisent plusieurs documents ; pour des recherches dans un seul document, la recherche simple suffit et coûte moins de calcul.
• Vous ne voulez pas de mémoire persistante (machine partagée, client sensible) : désactivez-la avec autoMemoryEnabled: false dans les réglages du projet ou la variable CLAUDE_CODE_DISABLE_AUTO_MEMORY=1, d’après la documentation.

Pour les bases, voir notre explication de ce qu’est un agent d’IA et de ses risques et celle sur les tokens et la fenêtre de contexte. D’autres lectures de résultats publiés sont rassemblées dans les comparatifs du Labo, dont notre analyse de GDPx, le classement d’agents de SemiAnalysis.