Comment fonctionne vraiment la mémoire des agents
Posez deux fois la même question à un chatbot dans deux sessions différentes et il vous répondra comme un inconnu à chaque fois. Ce n'est pas un bug — c'est le comportement par défaut. Un modèle de langage brut n'a aucune mémoire entre les appels. Tout ce qu'il « retient » à l'intérieur d'une conversation vit dans la fenêtre de contexte, et lorsque cette conversation se termine, tout disparaît.
La mémoire est la machinerie que vous ajoutez pour corriger cela : les systèmes qui décident ce qu'un agent doit conserver, où le stocker et comment récupérer le bon élément au bon moment. En 2026, cela a cessé d'être une quête secondaire pour devenir un élément à part entière de la conception des agents, avec ses propres benchmarks, ses frameworks et une véritable littérature de recherche. Cette page en est la carte.
- Comprendre pourquoi une fenêtre de contexte n'est pas de la mémoire — et où se situe réellement la frontière
- Distinguer les quatre types de mémoire qu'utilisent les agents : de travail, épisodique, sémantique, procédurale
- Comparer les quatre patterns de stockage : contexte complet, vecteur/RAG, graphe de connaissances et compaction/résumé
- Voir comment Claude, ChatGPT et Gemini implémentent chacun la mémoire aujourd'hui
- Choisir une approche de mémoire pour votre propre agent sans la surdimensionner
L'idée à retenir : contexte ≠ mémoire
La confusion la plus courante consiste à considérer une grande fenêtre de contexte comme de la « mémoire ». Ce n'en est pas. La fenêtre de contexte est un espace de travail pour un seul tour — elle est remplie de zéro à chaque appel, elle est finie et elle coûte cher. L'attention se dégrade aussi tout au long de celle-ci (l'effet « perdu au milieu » abordé dans Context Engineering).
La mémoire est différente de trois manières :
| Fenêtre de contexte | Mémoire | |
|---|---|---|
| Durée de vie | Une requête | À travers les sessions, les jours, pour toujours |
| Taille | Plafond fixe de tokens | Effectivement illimitée (stockage externe) |
| Coût | Payé à chaque tour | Payé une fois à l'écriture ; peu coûteux à référencer |
| Accès | Tout, toujours visible | Sélectif — ne récupère que ce qui est pertinent |
Tout l'enjeu de la mémoire des agents consiste à déplacer la bonne information entre ces deux espaces : écrire les faits durables hors de la fenêtre pour ne pas les payer à chaque tour, et ne les ramener dedans que lorsque cette étape précise en a besoin. Réussissez ce flux et un agent peut fonctionner pendant des semaines avec une fenêtre de contexte qui ne contient jamais que quelques milliers de tokens pertinents.
Les quatre types de mémoire
En empruntant (librement) aux sciences cognitives, l'écosystème des agents de 2026 a convergé vers quatre catégories. Vous avez rarement besoin des quatre — mais les nommer vous évite de construire un seul amas qui fait tout mal.
- Ce qui se trouve dans la fenêtre de contexte en ce moment — la tâche en cours, les derniers tours, les résultats d'outils de cette étape. Volatile par conception. C'est le brouillon, pas l'archive. Bien la gérer relève du context engineering ; ce n'est pas de la persistance.
- Des choses précises qui se sont produites, avec un horodatage. « Mardi l'utilisateur a dit que le paiement était cassé ; mercredi le support l'a marqué comme résolu. » La mémoire épisodique est intrinsèquement temporelle — l'ordre et le moment comptent. C'est ce qui permet à un agent de raisonner sur une histoire plutôt que sur un instantané.
- Des faits durables et des préférences, dépouillés du moment où vous les avez appris. « L'utilisateur préfère les unités métriques. » « Ce client est sur le plan entreprise. » La mémoire sémantique est largement atemporelle — elle représente ce que l'agent croit être actuellement vrai, pas l'événement au cours duquel il l'a découvert.
- Comment faire quelque chose — compétences réutilisables, workflows et routines apprises. La moins mature des quatre en pratique. Dans des outils comme Claude Code, elle vit souvent sous forme de fichiers d'instructions (CLAUDE.md) et de compétences réutilisables plutôt que dans un stockage automatique.
Un test utile : si vous répondriez par « quand cela s'est-il produit ? » c'est épisodique ; si vous répondriez par « qu'est-ce qui est vrai ? » c'est sémantique ; si vous répondriez par « voici comment » c'est procédural ; et si cela n'a d'importance que pour les quelques secondes à venir, c'est de la mémoire de travail et cela n'a pas besoin d'être persisté du tout.
Les quatre patterns de stockage
Une fois que vous savez quoi mémoriser, vous choisissez comment le stocker et le récupérer. Il existe quatre patterns dominants, à peu près par ordre de complexité. La plupart des systèmes réels en combinent deux ou trois.
1. Contexte complet (tout entasser dedans)
Conservez l'historique entier et renvoyez-le à chaque tour. Zéro infrastructure, rappel parfait — jusqu'à ce que vous atteigniez le plafond de tokens, la courbe de coût ou le « perdu au milieu ». Convient aux assistants courts ; une impasse pour tout ce qui dure longtemps. C'est la référence que tous les autres patterns améliorent.
2. Mémoire vecteur / RAG
Écrivez chaque souvenir sous forme d'embedding dans une base de données vectorielle ; au moment de la requête, encodez le tour en cours et récupérez les top-k souvenirs les plus similaires. Il s'agit de génération augmentée par récupération pointée vers l'historique de conversation plutôt que vers des documents. Peu coûteux, scalable, et le choix par défaut pour le rappel sémantique de faits et de préférences.
Sa faiblesse : similarité ≠ pertinence pour les questions temporelles ou multi-sauts. « Qu'avons-nous décidé après la coupe budgétaire ? » est une question d'ordre, et la similarité cosinus n'a aucune notion du temps ni du chaînage de deux faits.
3. Mémoire par graphe de connaissances
Stockez les souvenirs sous forme d'entités et de relations — nœuds et arêtes, souvent avec des horodatages sur les arêtes. Pour répondre à une question, vous parcourez le graphe plutôt que d'effectuer une correspondance floue de vecteurs. C'est ce qui rend le raisonnement multi-sauts et temporel abordable (« qui a remplacé la personne qui possédait le compte au sujet duquel l'utilisateur s'est plaint ? »). Des frameworks comme Zep/Graphiti ont bâti tout leur argumentaire autour des graphes de connaissances temporels. Le coût, c'est de l'ingénierie réelle : extraction, résolution d'entités et maintien du graphe pour l'empêcher de pourrir.
4. Compaction & résumé
Compressez périodiquement l'historique en cours en un résumé distillé et poursuivez à partir de là — en échangeant le rappel mot à mot contre une fenêtre plus petite et moins coûteuse. C'est ce que fait /compact dans Claude Code, et ce que fait l'« auto-résumé » dans de nombreux produits de chat. C'est la forme la moins coûteuse de mémoire à long terme et souvent la première dont vous avez réellement besoin. Son risque : le résumé abandonne silencieusement le seul détail dont vous aviez besoin. Voir Long-Running Agent Harnesses pour voir comment cela se déroule lors d'exécutions de plusieurs heures.
Les systèmes réels superposent ces patterns. Une pile courante en 2026 : compaction pour la conversation en cours, vecteur pour les faits sémantiques, et un graphe par-dessus uniquement lorsque des requêtes temporelles/multi-sauts apparaissent réellement dans votre trafic. Ne construisez pas le graphe avant de ressentir la douleur que le graphe résout.
Comment les trois grands le font
Chaque assistant majeur embarque désormais une forme de mémoire. Ce ne sont pas la même chose, et les différences comptent.
| Produit | Ce qu'il mémorise | Comment cela fonctionne (grosso modo) |
|---|---|---|
| Claude | Deux couches : une mémoire au niveau de l'application de vos préférences, et un outil de mémoire destiné aux développeurs pour les agents. | La mémoire de l'app Claude stocke des faits à travers les chats ; l'outil de mémoire de l'API plus l'édition de contexte permet à un agent d'écrire des notes dans un stockage côté client et d'élaguer automatiquement les résultats d'outils obsolètes pour survivre aux longues exécutions. |
| ChatGPT | Les « souvenirs enregistrés » (faits explicites) plus une référence à vos conversations passées. | Un mélange de faits énoncés par l'utilisateur et de préférences extraites automatiquement, injectés dans le contexte système lors des tours ultérieurs. Modifiable et activable/désactivable par l'utilisateur. |
| Gemini | Un contexte personnel tiré de vos conversations et, optionnellement, de la surface plus large de votre compte Google. | Rappelle des détails des conversations précédentes et peut personnaliser en utilisant le contexte du compte, sous réserve de vos contrôles de confidentialité. |
Deux enseignements. Premièrement, la mémoire grand public est essentiellement sémantique — préférences et faits — et non un rejeu épisodique complet. Deuxièmement, si vous construisez un agent, la mémoire intégrée du produit n'est pas votre système de mémoire ; c'est vous qui possédez cette couche, en utilisant des primitives comme l'outil de mémoire de Claude ou un framework externe.
Transformer un modèle brut en un agent preneur de notes (la mémoire réelle la moins chère)
You have a file called MEMORY.md that persists between our sessions. At the END of each session, append any durable facts worth keeping: - my stable preferences (tools, formats, style) - decisions we made and WHY - open threads to resume next time At the START of each session, read MEMORY.md first and use it. Keep it under 30 lines — when it grows past that, consolidate and delete anything stale. Never store secrets or credentials.
Ce seul pattern — écrire des notes durables dans un fichier externe, les relire la fois suivante — représente le 80/20 de la mémoire des agents. La majeure partie de la machinerie de frameworks ci-dessous n'est qu'une version plus automatique et plus scalable de exactement cela.
Mesurer la mémoire : le benchmark LoCoMo
On ne peut pas améliorer ce qu'on ne peut pas mesurer, et la mémoire était difficile à mesurer jusqu'à l'arrivée des benchmarks. Le plus cité est LoCoMo (« Evaluating Very Long-Term Conversational Memory of LLM Agents ») : des conversations multi-sessions très longues — des centaines de tours répartis sur des dizaines de sessions — avec des paires question-réponse en cinq déclinaisons : single-hop, multi-sauts (inter-sessions), raisonnement temporel, domaine ouvert et adversarial.
Ce que LoCoMo révèle, c'est le pattern autour duquel concevoir : les systèmes s'en sortent bien sur le rappel factuel single-hop et s'effondrent sur les questions temporelles et multi-sauts. Ce mode d'échec est exactement la raison d'être de la mémoire par graphe de connaissances — c'est le pattern qui fait le plus progresser ces deux catégories. Lorsque vous évaluez la mémoire de votre propre agent, pondérez fortement les cas multi-sauts et temporels ; le rappel single-hop flatte presque tout.
Choisir une approche sans surconstruire
- Ne faites rien. La mémoire de travail (la fenêtre de contexte) suffit. Ajouter ici un stockage de mémoire n'est que du surcoût pur.
- Commencez par de la prise de notes dans un fichier externe, ou la mémoire intégrée du produit. Cela couvre la plupart des besoins « souviens-toi de mes préférences » à un coût quasi nul.
- Ajoutez la compaction/résumé. Conservez les faits porteurs, abandonnez le récit coup par coup. C'est là que vivent les agents de longue durée.
- Ajoutez la mémoire vecteur/RAG. Récupérez les top-k souvenirs pertinents par tour au lieu de tout renvoyer.
- Ce n'est que maintenant qu'il faut recourir à un graphe de connaissances — ou à un framework géré (Mem0, Letta, Zep, LangMem) qui vous en fournit un sans avoir à coder à la main l'extraction et la résolution d'entités.
Le piège est de commencer à l'étape cinq. La mémoire par graphe est impressionnante dans les démos et coûteuse en production. Gravissez l'échelle ; arrêtez-vous au premier barreau qui résout votre problème réel.
Check yourself
0/4En résumé
La mémoire n'est pas une fonctionnalité que l'on active — c'est un flux que l'on conçoit : ce qui quitte la fenêtre, où c'est stocké et comment cela revient. Nommez les quatre types de mémoire pour ne pas construire un seul amas pour tous. Commencez par le pattern de stockage le moins cher qui résout votre problème et ne montez que lorsque vous ressentez la douleur du suivant. Et mesurez avec des cas temporels et multi-sauts, car le rappel single-hop fait paraître tout plus intelligent que ce ne l'est.
La mémoire est l'autre moitié du Context Engineering : le context engineering décide ce qui remplit la fenêtre ce tour-ci ; la mémoire décide ce qui survit entre les tours. Ensemble, ils sont ce qui distingue un chatbot d'un agent qui s'améliore à mesure que vous travaillez avec lui.
Sources & lectures complémentaires
- Evaluating Very Long-Term Conversational Memory of LLM Agents (LoCoMo) — le benchmark canonique ; page du projet.
- Effective context engineering for AI agents — Anthropic sur la compaction, la prise de notes et la récupération juste-à-temps.
- Claude memory tool & context editing docs — la primitive destinée aux développeurs.
- Agent Memory Techniques — 30 notebooks exécutables couvrant les tampons de conversation, les stockages vectoriels, les graphes de connaissances, la mémoire épisodique/sémantique, Mem0, Letta, Zep, Graphiti et LoCoMo.
- The State of AI Agent Memory 2026 — rapport de fournisseur sur les architectures de mémoire et les benchmarks (à lire avec la prudence habituelle vis-à-vis des chiffres auto-déclarés).
- Sur AILmanac également : Context Engineering · Long-Running Agent Harnesses · RAG · Claude app memory · Memory & Context Editing (API).