Claude Code Dreaming : la mémoire qui s'améliore

Le Dreaming, la couche qui réorganise la mémoire entre les sessions

Le Dreaming de Claude Code est un processus asynchrone planifié qui relit les sessions passées d’un agent et son magasin de mémoire, puis produit une mémoire réorganisée : doublons fusionnés, entrées périmées remplacées, nouveaux patterns mis en avant. En clair, c’est la couche de curation qui empêche la mémoire d’un agent de se dégrader au fil des runs.

Anthropic a présenté la fonctionnalité au Code with Claude 2026 dans le cadre de la plateforme Managed Agents. Le nom est un clin d’œil assumé à la consolidation de la mémoire pendant le sommeil chez les organismes vivants : pendant qu’il « rêve », l’agent rejoue son passé pour en extraire ce qui mérite d’être retenu. Sur les tests menés par le cabinet juridique Harvey, les taux de complétion des tâches ont été multipliés par environ six après l’activation du Dreaming (Anthropic, 2026).

J’ai suivi de près les évolutions de Claude Code, des Dynamic Workflows aux Outcomes et graders. Le Dreaming est la pièce manquante du puzzle « agent qui s’améliore tout seul » : ce guide en détaille le fonctionnement, l’API, les résultats et les limites.

Le problème que le Dreaming résout : la décadence de la mémoire

La mémoire incrémentale d’un agent se dégrade mécaniquement avec le temps. C’est le problème central que le Dreaming vient corriger.

Quand un agent travaille, il écrit dans son magasin de mémoire au fil de l’eau. Ces écritures sont locales et incrémentales : l’agent ajoute une note quand il découvre un contournement, corrige un détail quand il se trompe, enregistre une préférence quand l’utilisateur en exprime une. Sur une seule session, c’est efficace.

Le problème apparaît sur la durée. Au bout de plusieurs dizaines de sessions, le magasin accumule trois types de bruit :

• Des doublons : la même information notée sous des formulations différentes au fil des runs.
• Des contradictions : une entrée écrite il y a trois semaines qui dit le contraire d’une entrée d’hier.
• Des entrées périmées : un workaround pour un bug désormais corrigé, une convention de code abandonnée.

Sans nettoyage, ce bruit consomme du contexte et dégrade la qualité des décisions de l’agent. La mémoire devient un grenier encombré plutôt qu’un carnet de notes utile. Le Dreaming est précisément la passe de ménage qui maintient un signal élevé.

Le dream produit un magasin de sortie distinct : le magasin d’entree n’est jamais modifie.

Comment fonctionne un dream concrètement

Un dream est un job asynchrone qui prend des entrées, exécute un pipeline de synthèse, et produit un nouveau magasin de mémoire séparé de l’original. Le détail compte, car la mécanique conditionne la sécurité de la fonctionnalité.

Les entrées : un magasin de mémoire et des transcriptions

Un dream prend deux types d’entrée :

• Un magasin de mémoire préexistant : le magasin que Claude va vérifier, dédupliquer et réorganiser.
• De 1 à 100 sessions : les transcriptions passées que Claude analyse pour en extraire patterns et insights, qu’il replie ensuite dans le magasin de sortie.

Si vous n’avez que des transcriptions et aucun magasin existant, la documentation recommande de créer un magasin vide et de le passer comme entrée memory_store.

Le traitement : une passe de synthèse, pas un éditeur de texte

Le pipeline lit le magasin et les transcriptions, puis synthétise une version réorganisée. Trois opérations structurent ce travail : les doublons sont fusionnés, les entrées périmées ou contredites sont remplacées par la valeur la plus récente, et les nouveaux insights sont mis en avant.

Ce que le Dreaming fait remonter, c’est précisément ce qu’aucune session isolée ne peut voir : les erreurs récurrentes, les workflows sur lesquels plusieurs agents convergent indépendamment, et les préférences partagées au sein d’une équipe d’agents. C’est une vue transversale, pas une simple compression.

Un champ instructions optionnel (jusqu’à 4 096 caractères) permet de piloter la synthèse : indiquer des zones de focus (« concentre-toi sur les préférences de style de code »), du contenu à préserver, ou des conventions de sortie. Attention toutefois : c’est une passe de synthèse sur les entrées, pas un éditeur appliqué au texte ligne par ligne. Une instruction du type « change la phrase X en Y » ne produit généralement aucun effet. Pour des éditions ciblées, il faut passer par l’API Memory Stores sur le magasin de sortie.

La sortie : un nouveau magasin, l’original intact

Point de sécurité essentiel : le magasin d’entrée n’est jamais modifié. Le dream produit un magasin de sortie distinct, dont l’identifiant apparaît dans outputs[] une fois le statut completed atteint. Vous pouvez alors l’inspecter via l’API Memory Stores ou dans la Console, puis décider :

• L’adopter : l’attacher aux futures sessions comme ressource memory_store, à la place de l’ancien ou en complément.
• Le jeter : le supprimer ou l’archiver si la curation ne vous convient pas.

Cette séparation entrée/sortie est ce qui rend le Dreaming utilisable en confiance : aucune opération n’est destructive sur la mémoire de référence.

Mémoire et Dreaming : deux couches complémentaires

La mémoire et le Dreaming ne sont pas la même chose, et l’un ne remplace pas l’autre. Comprendre la distinction évite les contresens.

Critère	Mémoire	Dreaming
Rôle	Couche d’écriture	Couche de curation
Quand	Pendant la session, en continu	Après les sessions, planifié
Portée	Une session à la fois	Plusieurs transcriptions à la fois (jusqu’à 100)
Action	Note ce que l’agent apprend	Fusionne, déduplique, réorganise, fait remonter les patterns
Vue	Locale, incrémentale	Transversale, cross-sessions
Disponibilité	Beta publique	Research preview

La formule d’Anthropic résume bien le partage des rôles : « la mémoire laisse chaque agent capturer ce qu’il apprend en travaillant ; le Dreaming raffine cette mémoire entre les sessions, en remontant les apprentissages partagés entre agents ». Vous avez besoin des deux. La mémoire écrit, le Dreaming nettoie.

Créer et suivre un dream via l’API

Le Dreaming s’utilise via l’API Managed Agents avec des en-têtes beta spécifiques. Voici la mécanique de base, indépendamment du langage de SDK.

Chaque requête Managed Agents exige l’en-tête beta managed-agents-2026-04-01. Les dreams ajoutent l’en-tête dreaming-2026-04-21. Les SDK officiels les positionnent automatiquement.

La création d’un dream passe par un appel POST sur /v1/dreams avec, dans le corps, un tableau inputs (le memory_store et les session_ids), un model, et un champ instructions optionnel :

dream = client.beta.dreams.create(
    inputs=[
        {"type": "memory_store", "memory_store_id": store_id},
        {"type": "sessions", "session_ids": [session_a, session_b]},
    ],
    model="claude-opus-4-8",
    instructions="Concentre-toi sur les préférences de style de code ; ignore les notes de debug ponctuelles.",
)
print(dream.id)  # drm_01...

La réponse est la ressource complète avec status: "pending". Comme les dreams sont asynchrones, vous interrogez ensuite le dream par son identifiant pour suivre sa progression. Le cycle de vie passe par cinq statuts.

Statut	Signification
pending	Dream créé et mis en file d’attente
running	Le pipeline traite ; usage se met à jour au fil de l’eau
completed	Terminé avec succès ; outputs[] contient le nouveau magasin
failed	Échec ; le magasin de sortie reste en l’état partiel
canceled	Annulé ; le magasin de sortie reste en l’état

Une fois le dream running, son champ session_id pointe vers la session sous-jacente qui exécute le pipeline. Vous pouvez streamer les événements de cette session pour observer en temps réel ce que le dream lit et écrit. Pour une exécution propre dans un agent piloté, ce niveau d’observabilité rejoint les bonnes pratiques des workflows dynamiques de Claude Code.

Limites techniques à connaître

Quelques garde-fous structurent l’usage du Dreaming en research preview.

• Sessions par dream : 100 maximum.
• Longueur des instructions : 4 096 caractères.
• Modèles supportés : claude-opus-4-8, claude-opus-4-7, claude-sonnet-4-6.
• Facturation : au tarif standard des tokens API du modèle choisi, le coût croissant à peu près linéairement avec le volume de sessions.

Archiver ou supprimer un magasin d’entrée ou une session en cours de run fait échouer le dream avec une erreur explicite (input_memory_store_unavailable ou input_session_unavailable). Tant qu’un dream est pending ou running, son magasin de sortie ne peut être ni archivé ni supprimé.

La boucle de retroaction peut ancrer une erreur ; un outcomes rubric strict la detecte des le run suivant.

Le risque d’hallucination et comment le maîtriser

Le Dreaming introduit un risque spécifique : la consolidation d’erreurs. C’est le point le plus important à comprendre avant de l’activer en production.

Le mécanisme est le suivant. Si une mémoire erronée est consolidée par un dream, puis renforcée à chaque passage suivant, une boucle de rétroaction positive peut l’ancrer de plus en plus profondément. Autrement dit, le Dreaming peut transformer une erreur isolée en conviction durable de l’agent. C’est l’inconvénient direct de sa force : il généralise les patterns, y compris les mauvais.

La parade recommandée par Anthropic est de coupler le Dreaming à un outcomes rubric strict. Le grader détecte alors la dérive dès le run suivant et la corrige avant qu’elle ne se propage. Cette articulation entre curation et évaluation est centrale ; j’en détaille la mise en place dans le guide sur les Outcomes et graders de Claude Code.

Deux protections supplémentaires sont intégrées par conception :

• Le magasin d’entrée reste intact : vous inspectez toujours le magasin de sortie avant de l’adopter, ce qui crée un point de validation humain naturel.
• Le contrôle du déclenchement : le Dreaming peut mettre à jour la mémoire automatiquement ou exiger une revue manuelle avant d’appliquer les changements. Sur des agents critiques, la revue manuelle est le réglage prudent.

Mon avis : une brique structurante, à manier avec méthode

Mon verdict : le Dreaming comble le dernier maillon manquant des agents persistants, mais ce n’est pas une fonctionnalité à activer aveuglément.

Ce qui me convainc, c’est la rigueur de la conception. La séparation entrée/sortie, l’asynchronisme, le pilotage par instructions et le couplage explicite aux outcomes montrent qu’Anthropic a pensé le Dreaming comme une couche d’infrastructure, pas comme un gadget. Le facteur six sur les taux de complétion observé chez Harvey, même s’il s’agit d’un cas d’usage précis, donne une idée de l’effet de levier quand la mémoire cross-sessions est bien organisée.

Ce qui appelle à la prudence, c’est le risque d’hallucination consolidée et le statut research preview. Tant que la fonctionnalité n’est pas en beta publique, je la réserve à des équipes qui maîtrisent déjà la mémoire et les graders. Pour une base solide, je recommande de commencer par bien structurer ses fichiers de contexte : les principes de CLAUDE.md et AGENTS.md restent le socle sur lequel le Dreaming vient ensuite construire.

L’essentiel à retenir : la mémoire écrit, le Dreaming réorganise, et le grader surveille. Si vous débutez avec l’agent de code d’Anthropic, commencez par le guide Claude Code pour débutant avant de vous attaquer à cette couche avancée.