La mémoire des agents IA en 2026 : Mem0, Letta, Zep et comparaison des plateformes cloud.

En lançant une nouvelle session avec la plupart des agents IA, on a affaire à un inconnu. Il ne connaît ni votre nom, ni ce que vous développez, ni même le fait qu’il ait passé une heure avec vous hier à essayer de résoudre le même bug. La solution habituelle consistait à coller l’ancien transcript dans la prochaine demande, mais cela représentait toujours un coût : plus de tokens, des réponses plus lentes, une précision moindre. En 2026, ce coût est devenu trop élevé pour être supporté, ce qui a conduit à l’apparition de couches de mémoire conçues spécifiquement pour le remplacer.

Quelques chiffres illustrent l’ampleur de ce changement. L’algorithme de troisième génération de Mem0 obtient 94,4 points sur LongMemEval tout en utilisant environ 7 000 tokens par requête, alors que l’utilisation de l’historique complet entraîne 25 000 tokens ou plus ; sa latence p95 a diminué de 91 %, passant de 17,12 secondes à 1,44 seconde. Le graphe de connaissances temporel de Zep a obtenu 94,8 % de scores dans le test Deep Memory Retrieval contre 93,4 % pour MemGPT, avec des temps de réponse environ 90 % plus courts. Anthropic a mis en ligne la mémoire persistante pour les Claude Managed Agents en bêta publique le 23 avril 2026, et Rakuten, l’un des premiers à l’adopter, a constaté une réduction de 97 % des erreurs lors de la première tentative, une baisse de 27 % des coûts et une réduction de 34 % de la latence pour les agents chargés d’actions prolongées. AWS et Microsoft ont eux aussi transformé cette même idée en produits pour leurs clouds. En mai 2026, OWASP a lancé un projet dédié intitulé Agent Memory Guard, car une mémoire persistante entre sessions est devenue une cible pour les attaquants.

Ce qui suit est une présentation de ce domaine : ce qu’est réellement la mémoire, comment les systèmes principaux sont construits, ce que les benchmarks vous révèlent et ce qu’ils ne vous révèlent pas, où la mémoire échoue, et où elle se dirige.

Le problème de l’amnésie

Tout ceux qui ont déployé un agent au cours des dernières années connaissent ce problème. Au cours d’une même session, le modèle fonctionne parfaitement. Entre les sessions, il se comporte comme un poisson rouge. Chaque connexion commence à zéro, chaque préférence doit être demandée à nouveau, et chaque information concernant l’utilisateur, le projet ou le flux de travail doit être reconstituée à partir d’une transcription brute ou insérée dans l’instruction du système, jusqu’à ce que le coût lié au contexte devienne dominant par rapport aux autres dépenses de déploiement.

Les produits grand public ont tenté de combler cette lacune. OpenAI a mis ChatGPT Memory à disposition de tous les forfaits payants d’ici septembre 2024, l’a élargi en avril 2025 pour prendre en compte chaque conversation antérieure, puis l’a rendu accessible aux utilisateurs gratuits en juin 2025. Anthropic a ajouté une fonction de mémoire automatique à Claude en octobre 2025, l’a rendue gratuite pour tout le monde en mars 2026, et a lancé un outil de mémoire programmable pour Claude Managed Agents en version bêta publique, qui met à disposition un répertoire /memory persistant contenant des fichiers conservés entre les sessions. Il s’agit de fonctionnalités utiles, mais aucune d’elles n’est un composant que l’on puisse intégrer dans son propre agent.

Pour les développeurs, l’alternative peu élégante qui consiste à rejouer toute l’histoire à chaque appel semble acceptable dans une démo, mais elle devient inutilisable à grande échelle. LongMemEval, un benchmark de NeurIPS 2024 consacré à la mémoire des assistants de conversation, l’a quantifié. Lorsque les historiques atteignaient environ 115 000 tokens, même les modèles de très long contexte perdaient de 30 à 60 points d’exactitude absolue par rapport à un oracle qui recevait directement les preuves pertinentes. GPT-4o, en lisant l’ensemble de l’histoire, obtenait des résultats compris entre environ 60,6 % et 64 %, contre un plafond d’exactitude de 87 % à 92 % pour l’oracle. Une fenêtre de un million de tokens ne vous sauve pas non plus ; elle se contente de fournir un champ encore plus vaste dans lequel le modèle risque de perdre la bonne information.

D’ici 2026, le domaine a abouti à une idée plus claire : la mémoire est un composant à part entière. Il ne s’agit ni d’un tour de passe-passe lié aux fenêtres de contexte, ni d’un index RAG basé sur des journaux de conversation, ni d’un modèle de prompt. C’est un stockage de première classe disposant de sa propre méthode d’écriture, de règles d’éviction, d’une API de récupération, d’un modèle de sécurité et de benchmarks. Les activités se déroulent en même temps en quatre endroits :

• SDK open source : Mem0, Letta, Zep avec Graphiti, Cognee, LangMem et Memori.
• Produits des hyperscalers : AWS Bedrock AgentCore Memory, la mémoire à portée utilisateur de Microsoft Foundry, et la mémoire des Claude Managed Agents d’Anthropic.
• Recherche : A-MEM, HippoRAG 2, MemoryOS, M3-Agent pour les entrées multimodales, MemRL pour des agents en évolution continue, AgeMem, ainsi que le Fine-tuning de mémoire sparse de Meta.

Dans le modèle : DeepSeek V4 (mars 2026) a introduit Engram, une architecture de mémoire de type O(1) basée sur le hachage qui permet de gérer un contexte de 1 million de tokens à peu près au même coût qu’un contexte de 128 000 tokens, et atteint 97 % de précision dans les tests de type « aiguille dans une botte de foin » à cette longueur. La frontière entre la mémoire intégrée au modèle et la mémoire stockée en dehors du modèle devient de plus en plus floue.

Le rapport de Mem0 intitulé « State of AI Agent Memory 2026 » qualifie ce résultat d’ingénierie de la mémoire : une discipline de production dotée de ses propres benchmarks, compromis et pratiques opérationnelles, suivant la voie empruntée par l’ingénierie des prompts pour aboutir à l’ingénierie du contexte. Le reste de cet article utilise ce vocabulaire, s’appuyant sur l’étude Mem0 ECAI 2025 et son mises à jour d’avril 2026, l’étude Zep, les benchmarks LongMemEval et LoCoMo, le framework CoALA, les travaux MemGPT et Letta, HippoRAG 2, MemoryOS, M3-Agent, le déploiement Claude Managed Agents, AgentCore Memory ainsi que les directives d’OWASP.

Les fenêtres de contexte, RAG et les journaux de conversation ne sont pas de la mémoire

Trois confusions surgissent dans presque toutes les réunions consacrées à « ajoutons de la mémoire », et il est utile de les clarifier avant que les architectures ne deviennent compréhensibles.

Une fenêtre de contexte n’est pas de la mémoire. Cette fenêtre a une durée de vie courte, est volatile et se recharge à chaque tour. La mémoire, quant à elle, persiste entre les sessions et dispose de son propre niveau de stockage, de règles d’évolution ainsi que d’une politique d’oubli. Elles se complètent mutuellement, sans pour autant se remplacer l’une l’autre. LongMemEval a montré que même les modèles de pointe disposant de fenêtres de plusieurs millions de tokens perdent plus de 30 % de leur précision lorsqu’ils doivent se remémorer des faits provenant de sessions antérieures sans couche de mémoire.

RAG n’est pas de la mémoire. La génération améliorée par récupération classique cherche dans un corpus statique, des documents qui existent déjà avant que l’agent ne s’adresse à quiconque. La mémoire, quant à elle, consulte le passé de l’agent : messages, appels d’outils, faits énoncés par l’utilisateur, résumés en dérivé. La caractéristique distinctive en 2026 réside dans la voie d’écriture. Un index RAG est principalement en mode ajout uniquement et sans état, tandis que la mémoire évolue avec le temps, peut contenir des versions contradictoires d’un fait, doit être corrigée en cas d’erreur et est écrite par l’agent lui-même.

Un journal de conversation n’est pas de la mémoire. Une transcription conserve tout, y compris le bruit. La mémoire devrait conserver des faits extraits tels que « l’utilisateur préfère les unités métriques », « la date limite du troisième trimestre a été déplacée au 14 novembre » ou « la clé API de Stripe a été renouvelée le 2026-04-12 », chacun accompagné de sa source et d’une période de validité, plutôt que 80 000 tokens de bavardages anodins. Cette compression, réalisée avec un taux élevé de rappel et publiée derrière une API que l’agent et l’équipe de sécurité peuvent auditer, constitue toute la fonction d’une couche de mémoire.

Tous les systèmes ci-dessous visent le même objectif : l’agent doit agir comme s’il existait des mois d’histoire partagée, mais la consommation en ressources doit rester inférieure à celle d’une relecture du contexte complet, l’agent ne doit pas inventer de faits sur son utilisateur, et personne ne doit pouvoir insérer des données erronées dans ce qu’il se souvient.

Le vocabulaire partagé de CoALA

Presque tous les frameworks actuels, qu’il s’agisse de Mem0, Letta, LangMem, Cognee, Memori ou AgentCore, s’inspirent de la même taxonomie. Elle provient de CoALA, l’étude publiée en 2023 par Princeton et CMU sur les architectures cognitives pour les agents linguistiques, qui a associé quatre types de mémoire humaine aux agents LLM :

• Mémoire de travail correspond à la fenêtre de contexte active, c’est-à-dire aux variables utilisées au cours du cycle décisionnel actuel. Elle est volatile.
• Mémoire épisodique stocke des expériences passées spécifiques, avec leur moment et leur récit : « L’utilisateur a demandé des informations sur les webhooks Stripe le 4 mars et a rencontré l’erreur X. »
• Mémoire sémantique contient des faits généralisés : « L’utilisateur préfère des réponses concises », « L’année fiscale d’ACME se termine le 30 septembre. »

Mémoire procédurale : elle concerne les compétences, les routines et le code. Elle se trouve généralement dans les poids du modèle, les prompts système et les registres d’outils, bien que de plus en plus de systèmes l’écrivent en temps de exécution. LangMem gère un stockage de règles de prompts, tandis qu’A-MEM conserve un réseau évolutif de notes.

Cette distinction est importante car chaque fournisseur adopte une approche différente. Mem0 est principalement sémantique. Zep prend en charge la mémoire épisodique et temporellement sémantique sur la base d’un graphe de connaissances. Letta propose une machine à mémoire virtuelle couvrant les quatre types. LangMem fournit des stockages séparés pour la mémoire sémantique, épisodique et procédurale. A-MEM fusionne la mémoire épisodique et sémantique grâce à des liens de type Zettelkasten, tandis que Memori serialise tout en SQL. Connaître le type pour lequel un système est optimisé permet de prendre la moitié des décisions architecturales.

Mem0 : extraire, puis mettre à jour

Mem0 (Y Combinator W24, ayant levé 24 millions de dollars en octobre 2025 auprès de Basis Set, Peak XV, GitHub Fund et Kindred Ventures) est devenu en 2026 la couche mémoire open source par défaut, tout comme pgvector était devenu l’index vectoriel par défaut deux ans plus tôt : il gérait les 80 % des cas courants en seulement trois lignes de code Python et fonctionnait correctement en production. À la mi-2026, il comptait plus de 41 000 étoiles sur GitHub, plus de 14 millions de téléchargements et 80 000 développeurs inscrits, les appels API passant de 35 millions au premier trimestre 2025 à 186 millions au troisième.

Le design est délibérément simple. Mem0 se situe entre le modèle et un stockage vectoriel et exécute un processus en deux étapes à chaque interaction :

1. Extraction. Le dernier échange entre l’utilisateur et l’assistant, ainsi que le contexte antérieur, est envoyé à un extracteur LLM qui propose des faits potentiels. La compression a lieu ici.

Mise à jour. Pour chaque candidat, Mem0 récupère les souvenirs enregistrés les plus similaires et demande au modèle, à l’aide d’une instruction d’utilisation d’outil, de choisir parmi ADD (un nouveau fait), UPDATE (améliorer un fait existant), DELETE (le candidat contredit un fait enregistré) ou NOOP.

Quelles modifications a apporté la version 3

L’algorithme v3, intégré le 14 avril 2026, est ce qui a fait de Mem0 le choix standard. Trois révisions majeures ont eu un impact significatif :

• Extraction en une seule passe, uniquement des ajouts. Au lieu que le modèle doive choisir entre ADD, UPDATE, DELETE et NOOP à chaque étape — ce qui implique deux appels au LLM et une grande quantité de tokens — v3 effectue une seule passe d’extraction qui ne produit que de nouveaux faits, et considère les faits générés par l’agent comme équivalents à ceux indiqués par l’utilisateur. La suppression des doublons et le lien entre entités ont lieu par la suite, en dehors du chemin principal de traitement.

Récupération multi-signaux. Trois méthodes d’évaluation s’exécutent en parallèle et fusionnent en un seul score : similitude sémantique dense, correspondance de mots-clés BM25 et correspondance d’entités. Ce mélange s’adapte en fonction des signaux disponibles au moment de la requête.

Lien d’entités plutôt que graphe. La version v3 a complètement abandonné la variante basée sur Neo4j. Les entités sont désormais extraites à l’aide de spaCy, sans implication d’un LLM, et stockées dans une collection vectorielle {collection}_entities où chaque ligne contient une liste linked_memory_ids. Cette structure en hub-and-spoke conserve la plupart des fonctionnalités offertes par un graphe à un coût d’exploitation bien inférieur.

Résultats rapportés :

• LoCoMo : 92,5 en général, avec +29,6 pour les questions temporelles et +23,1 pour les questions multi-étapes par rapport à l’utilisation du contexte complet.
• LongMemEval : 94,4 au total, avec +53,6 pour les questions relatives à l’assistant en session unique, +42,1 pour le raisonnement temporel et +16,7 pour les mises à jour de connaissances.
• BEAM avec 1 M et 10 M de tokens : 64,1 et 48,6.
• Cost en tokens : environ 7 000 par appel de récupération, contre 25 000 ou plus pour le contexte complet, soit une réduction d’environ 90 %.
• Latence p95 : 1,44 seconde contre 17,12, soit une réduction d’environ 91 %.
• Comparaison avec OpenAI Memory : 66,88 % contre 52,90 % sur un score global avec un LLM en tant que juge, ce qui représente une amélioration relative de 26 %.

Impact en environnement de production

La documentation d’intégration de Mem0 énumère 21 frameworks et plateformes, tant en Python qu’en TypeScript, parmi lesquels LangChain, LangGraph, LlamaIndex, CrewAI, AutoGen, le SDK AI de Vercel, AgentOps et Raycast, ainsi que 20 backends de stockage vectoriel incluant Qdrant, Chroma, Weaviate, Pinecone et pgvector. Il peut également fonctionner en tant que serveur MCP, ce qui permet à Claude Code, Cursor ou tout autre client compatible MCP de communiquer avec lui. Les agents vocaux s’y intégrent naturellement, avec des intégrations dédiées pour ElevenLabs Conversational AI (outils asynchrones addMemories et retrieveMemories via des appels de fonction), LiveKit et Pipecat.

L’histoire de client le plus citée est celle de RevisionDojo, une plateforme éducative qui a remplacé son système de personnalisation en contexte complet par Mem0 et a constaté une baisse de 40 % des coûts liés aux tokens, ainsi qu’un apprentissage plus personnalisé. Mem0 affirme que des milliers d’équipes, allant de startups à des entreprises du Fortune 500, l’utilisent en production, mais peu de noms d’entreprises importantes sont rendus publics.

Letta : la mémoire en tant que système d’exploitation à mémoire virtuelle

Tandis que Mem0 joue le rôle d’une API de complément, Letta agit comme un système d’exploitation. Elle a été développée en 2024 par le Sky Computing Lab de Berkeley en tant que successeur opérationnel du papier MemGPT (arXiv:2310.08560), et elle traite la fenêtre de contexte du modèle comme de la RAM, en chargeant et en déchargeant intentionnellement les informations. Elle comporte trois niveaux distincts :

• Mémoire de base : équivalent à la RAM, il s’agit d’un petit bloc toujours présent dans le contexte, contenant l’identité, la personnalité et l’état de la tâche en cours.

Mémoire de rappel fonctionne comme une mémoire cache disque : historique des conversations consultable, stocké en dehors de la fenêtre.

Mémoire d’archivage constitue un stockage froid : faits sémantiques à long terme que l’agent enregistre lui-même.

Trois choix de conception distinguent Letta de tous les autres produits disponibles.

Mémoire auto-éditable. L’agent gère sa propre mémoire au cours du cycle d’exécution à l’aide d’outils tels que core_memory_append, archival_memory_insert et memory_replace. Aucun extracteur distinct ne fonctionne en arrière-plan. Le modèle décide au moment du raisonnement ce qui mérite d’être conservé.

Calcul en mode veille. Vous pouvez associer un agent distinct en mode veille qui fonctionne de manière asynchrone lorsque l’agent principal est inactif. Cet agent analyse l’historique des conversations, les fichiers générés et les traces des outils, afin de produire un résumé du contexte appris que l’agent principal charge lors de sa prochaine action. L’agent en mode veille peut utiliser un modèle différent, généralement plus volumineux, que celui de l’agent principal ; ainsi, vous consommez moins de ressources pendant le traitement des demandes et plus lors de la consolidation des informations. Cela est l’inverse de la manière dont fonctionne normalement l’inférence autoregressive, et cela rappelle comment le cerveau transforme les souvenirs épisodiques en souvenirs sémantiques pendant le sommeil.

Fichier d’agent (.af). Letta a mis en open source un format de sérialisation qui regroupe le prompt système, des blocs de mémoire modifiables, du code et des schémas d’outils, ainsi que les paramètres du modèle dans un seul fichier. De tels fichiers peuvent être sauvegardés en tant que points de contrôle, versionnés et déplacés entre des environnements compatibles, ce qui constitue l’équivalent le plus proche dans ce domaine d’une image Docker pour des agents à état. Lors de l’exportation, les secrets sont supprimés.

Letta Code et son score Terminal-Bench

À la fin de 2025, Letta a lancé Letta Code, un agent de codage en ligne de commande open source basé sur son SDK d’agents à état. L’argument avancé est qu’un outil basé sur des sessions comme Cursor, Aider ou Cline commence à zéro à chaque fois, tandis qu’un agent à état accumule des connaissances sur la structure d’un projet, vos préférences, les sessions de débogage précédentes et les conventions d’équipe. Vous disposez d’un agent par projet, qui existe aussi longtemps que ce dernier.

L’affirmation concernant les performances est concrète. Sur Terminal-Bench, Letta Code occupe la première place parmi les agents open source indépendants des modèles, avec un score global de 42,5 % (quatrième au classement général et deuxième parmi les agents basés sur Claude 4 Sonnet) ; le code de cet agent compte moins de 200 lignes en plus du SDK. Il peut basculer entre Claude, GPT, Gemini, GLM et Kimi tout en conservant sa mémoire, telle que conçue dans le scénario Agent File.

Zep et Graphiti : un graphe de connaissances temporel

Tant Mem0 que Letta utilisent un stockage vectoriel comme substrat principal. Zep (arXiv:2501.13956) adopte une approche inverse en modélisant la mémoire comme un graphe de connaissances temporel. Graphiti, son moteur à noyau ouvert, repose sur trois couches de sous-graphes ainsi que sur un modèle bitemporal qui enregistre séparément le moment où quelque chose s’est produit et celui où le système l’a découvert.

• Le sous-graphe d’épisodes conserve les entrées brutes et haute fidélité (messages de conversation, documents JSON, captures transactives), chacune marquée de l’heure de l’événement original. Il n’est jamais réécrit.
• Le sous-graphe des entités sémantiques contient les entités et faits extraits, représentés sous forme de vecteurs de 1024 dimensions reliés par des relations typées. Les entités disposent d’intervalls de validité.
• Le sous-graphe de la communauté forme des clusters de haut ordre au niveau des entités à l’aide d’une détection de communautés par propagation d’étiquettes, qui s’actualise de manière incrémentale, contrairement à la méthode Leiden.

Le modèle bitemporal est la partie la plus difficile à reproduire avec un simple stockage vectoriel. Chaque arête dans Graphiti comporte quatre timestamps :

t_valid    : when this fact started being true in the world
t_invalid  : when it stopped being true (open if still true)
t'_created : when the system first learned the fact
t'_expired : when the system superseded or removed it

Ce design permet à Zep de répondre à la question « En quoi croyait l’agent mardi dernier ? » tout aussi facilement qu’à « Quelle est la situation actuelle ? ». Les équipes de conformité et quiconque défend les décisions antérieures des agents ont justement besoin de cela. Lorsqu’un utilisateur change d’employeur, l’ancien n’est pas supprimé : l’information antérieure est marquée avec t_invalid, la nouvelle est ajoutée, et les deux restent recherchables.

Résultats rapportés dans l’étude sur Zep : 94,8 % en matière de récupération de mémoire profonde contre 93,4 % pour MemGPT ; une précision jusqu’à 18,5 % supérieure sur LongMemEval, avec une latence d’environ 90 % inférieure par rapport à l’utilisation du contexte complet. Des comparaisons indépendantes montrent que la récupération de type graphe, y compris Graphiti, est d’environ 35 % plus précise que la récupération vectorielle seule pour les requêtes relationnelles à plusieurs étapes.

Plus d’options open source

Ces trois solutions ne sont pas les seules. Plusieurs autres conceptions méritent également d’être prises en compte.

Cognee

Cognee (environ 12 000 étoiles sur GitHub d’ici le milieu de 2026) regroupe un graphe, un stockage vectoriel et un stockage relationnel derrière une seule API. L’ingestion s’effectue via un pipeline en six étapes appelé « cognify », suivi d’une phase d’affinage automatique nommée « memify » qui élimine les nœuds obsolètes, réajuste le poids des arêtes en fonction de leur fréquence d’utilisation et ajoute des faits dérivés. Quatorze modes de récupération sont disponibles, allant de la simple similarité vectorielle à une exploration de graphe guidée par une chaîne de pensée, et incluent un serveur MCP.

LangMem

Le SDK de LangChain propose un système de mémoire en deux points d’intégration : une voie principale composée d’outils synchrones que l’agent appelle au cours d’une étape, et un gestionnaire en arrière-plan qui extrait, consolide et élimine les doublons de manière asynchrone. Il dispose de stockages sémantiques, épisodiques et procéduraux de premier ordre, et il est le seul SDK majeur à considérer la mémoire procédurale, telle que « lorsque l’utilisateur demande ‘le plus rapidement possible’, augmenter la priorité », comme une fonctionnalité principale.

Memori

Memori (Memori Cloud lancé le 2 mars 2026) enregistre la mémoire dans SQLite ou Postgres plutôt que dans une base de données vectorielle. Cela vous permet d’avoir un contrôle total sur les données sans avoir à mettre en place de nouvelle infrastructure, et le projet affirme une réduction des coûts d’inférence de 80 % à 98 % en ne transmettant que le contexte pertinent extrait avec SQL. Une seule ligne de code Python suffit pour ajouter une mémoire persistante à un agent OpenAI, Anthropic ou LangChain.

A-MEM

A-MEM (NeurIPS 2025, arXiv:2502.12110) transforme chaque mémoire en une note de type Zettelkasten atomique dotée d’attributs structurés. Une nouvelle note fait référence à des notes plus anciennes et met à jour leurs attributs en fonction des nouvelles informations, permettant ainsi au réseau de continuer à évoluer. C’est l’architecture la plus « vivante » dans la littérature de recherche, et elle surpasse les solutions actuelles sur LoCoMo pour six modèles de base.

HippoRAG 2

HippoRAG 2 (ICML 2025, arXiv:2502.14802) extrait des triples de graphes de connaissances ouverts à partir de passages et relie des synonymes pour former ce que les auteurs appellent un index hippocampal artificiel. Lors d’une requête, il applique le Personalized PageRank à partir de nœuds de départ, imitant ainsi le mécanisme de complétion des motifs hippocampaux. Il affiche une amélioration de 7 % par rapport aux meilleures solutions basées sur des mémoires denses, et il sert de plus en plus comme couche de récupération dans les architectures de type Zep et Cognee.

MemoryOS

MemoryOS (EMNLP 2025 Oral, arXiv:2506.06326) est le cousin de recherche de Letta. Il formalise trois niveaux de mémoire personnelle : à court terme, à moyen terme et à long terme, avec des règles de transition explicites : un principe premier entré, premier sorti du court terme vers le moyen terme, ainsi qu’une organisation en pages segmentées du moyen terme vers le long terme. Quatre modules (stockage, mise à jour, récupération, génération) fonctionnent à travers ces niveaux. Sur les bases de données LoCoMo avec GPT-4o-mini, il obtient une amélioration de +48,36 % en F1 et de +46,18 % en BLEU-1, ce qui représente la plus grande amélioration jamais rapportée pour un article de 2025 sur cette base de test. On peut s’attendre à ce que la pagination de niveau intermédiaire soit intégrée dans les SDK de production d’ici 2026.

MemRL

MemRL (janvier 2026) représente la nouvelle direction à surveiller. Il considère la mémoire comme un substrat pour l’apprentissage par renforcement. Chaque interaction est enregistrée sous forme de triplet (Intent, Experience, Utility), où la valeur d’utilité correspond à une Q-value apprise indiquant dans quelle mesure cette expérience a été utile pour des intentions similaires. Un mécanisme de récupération en deux phases met en évidence les expériences passées les plus utiles pour la tâche en cours, et les valeurs Q s’actualisent au fur et à mesure que l’agent agit. La mémoire de l’agent devient ainsi plus intelligente, et non simplement plus volumineuse, ce qui représente le mieux possible l’apprentissage à partir de l’expérience sans avoir recours aux poids du modèle.

SuperLocalMemory

SuperLocalMemory (arXiv:2603.02240) va dans la direction opposée, en s’éloignant du cloud pour se concentrer sur le dispositif. Ce système multi-agents axé sur l’approche locale repose sur SQLite avec une recherche de texte complet FTS5, il clusterise son graphe de connaissances à l’aide de Leiden, coordonne les opérations via une couche déclenchée par des événements avec un suivi de l’origine de chaque agent, et se protège contre la contamination grâce à une évaluation de fiabilité bayésienne, tout cela sans dépendance au cloud et sans appel à un LLM dans le processus de récupération. Associé à l’ensemble SQLite-AI, qui regroupe l’inference, la récupération, la mémoire, l’analyse et la synchronisation dans un seul fichier, il constitue une option fiable pour la protection de la vie privée des agents personnels, des charges de travail réglementées et des déploiements en périphérie.

AgeMem

AgeMem (2026) étend les quatre opérations de mise à jour de Mem0 à six outils, à savoir ADD, UPDATE, DELETE, RETRIEVE, SUMMARY et FILTER, et intègre des règles TTL afin que les souvenirs anciens expirent. Son objectif correspond à un enjeu que le domaine n’a commencé à prendre au sérieux qu cette année : une base de données qui ne cesse de croître finit par se nuire à elle-même.

Les hyperscalers entrent en scène

Le plus grand développement de 2026 est que les fournisseurs de services cloud ont cessé de rester en retrait. Les trois principaux d’entre eux ont mis sur le marché des solutions de mémoire en tant que produits de premier plan en l’espace d’environ six mois.

AWS Bedrock AgentCore Memory

Présenté lors du AWS Summit New York en 2025 et affiné progressivement tout au long de 2026, AgentCore Memory est la version commercialisée d’Amazon :

• Mémoire à court terme : enregistre l’état étape par étape au cours d’une session.

Mémoire à long terme extrait automatiquement les préférences de l’utilisateur, les faits clés et les résumés des sessions au fil du temps.

Épisodes structurés (disponibles généralement en 2026) capturent le contexte, les raisonnements, les actions et les résultats de chaque épisode, permettant ainsi aux agents d’apprendre à partir de leurs trajectoires passées et non seulement des faits.

Métadonnées relatives à la mémoire à long terme (mai 2026) permettent de taguer, filtrer et récupérer des informations grâce à des attributs structurés en complément de la recherche sémantique.

Notifications en flux continu (mars 2026) éliminent la nécessité de vérifier périodiquement les modifications de la mémoire.

Stockage géré des sessions (aperçu mars 2026) conserve l’état du système de fichiers lorsque un agent est arrêté puis repris.

Prix : 0,75 $ par 1 000 enregistrements pour les opérations mémoire, avec l’inférence d’extraction incluse. AgentCore Runtime ajoute 0,0895 $ par vCPU-heure et 0,00945 $ par GB-heure ; le temps passé à attendre des opérations I/O est gratuit, ce qui est important car les charges de travail d’agent passent de 30 % à 70 % de leur temps total à attendre.

Mémoire ciblée par utilisateur dans Microsoft Foundry

La couche de mémoire persistante de Microsoft Foundry, annoncée comme disponible en général lors de Build 2026, présente une structure différente :

• Partitionnement par utilisateur. La mémoire de chaque utilisateur se trouve dans son propre conteneur Azure Cosmos DB, partitionnée en fonction de l’identité, ce qui permet aux contextes de rester séparés et d’être gérés un par un.
• Signaux sélectionnés et pérennes, tels que les préférences, les intentions récurrentes et les résultats résumés, plutôt que des transcriptions brutes. La transcription reste stockée dans le système de stockage des conversations côté serveur, seuls les signaux compressés devenant une mémoire durable.
• DevUI, un débogueur local basé sur un navigateur permettant d’observer en temps réel l’exécution de l’agent, les lectures et écritures en mémoire, ainsi que son comportement d’orchestration.
• Outils d’évaluation avec suivi, tests de réexécution et tests automatisés de type « red-teaming » sur les chemins de décision de l’agent, ce qui est important car une mémoire spécifique à l’utilisateur entraîne des modes de défaillance propres à cet utilisateur.

Le choix est clair : Microsoft sépare au niveau du stockage le contexte de session à courte durée de vie de la mémoire utilisateur pérenne, évitant ainsi la dégradation lente qui survient lorsque un seul système doit assumer les deux fonctions.

Mémoire des agents gérés Anthropic Claude

Anthropic fournit l’étude de cas présentant le plus grand volume de production de l’année. La fonctionnalité de mémoire pour les agents gérés Claude a été mise en bêta publique le 23 avril 2026. La persistance s’effectue sous forme de fichiers dans un système de fichiers que l’agent, ou vous via l’API ou la Console Claude, peut exporter, modifier et gérer.

Les résultats des premiers utilisateurs sont exceptionnellement concrets :

• Rakuten utilise cette mémoire afin que les agents chargés de tâches longues durée évitent de répéter des erreurs antérieures, et indique que les erreurs à la première tentative ont été réduites de 97 %, les coûts de 27 % et la latence de 34 %, tout cela dans des limites observables propres au espace de travail. C’est le chiffre le plus cité en 2026 montrant que l’utilisation de la mémoire se paie par elle-même.
• Netflix conserve le contexte entre les sessions, y compris les informations obtenues au fil de plusieurs échanges ainsi que les corrections apportées par un réviseur humain au cours de la conversation, ce qui remplace les mises à jour manuelles des instructions.

Wisedocs effectue une vérification des documents sur les agents gérés et constate des contrôles 30 % plus rapides, grâce aux enregistrements mémoire indiquant quels problèmes se reproduisent dans quels modèles, ce qui permet aux agents d’éviter des analyses redondantes.

Ando utilise la mémoire entre les sessions au sein d’un flux de travail financier composé de nombreuses étapes.

Anthropic a également présenté une fonction de recherche appelée « dreaming » : un processus de réflexion hors ligne dans lequel les agents gérés rejouent les résultats de tâches antérieures afin d’en tirer des leçons durables. Il s’agit de la même idée que le calcul en mode sommeil de Letta, mais mis en œuvre à l’échelle des hyperscalers.

Ce qui relie ces trois offres, c’est le fait que la mémoire a cessé d’être un choix lié à un SDK pour devenir une fonctionnalité de plateforme. Cela modifie la position des fournisseurs open source, puisque Mem0, Letta et Zep concurrencent désormais le cloud que chaque client utilise déjà. Leurs arguments portent sur la portabilité (Agent File), la spécialisation (le modèle bi-temporel de Zep) et le coût (l’approche basée sur SQL de Memori).

Mémoire qui voit et entend

Tous les systèmes mentionnés ci-dessus partent du principe que la mémoire est un texte. En 2026, cette hypothèse a été remise en question, et la seconde moitié de l’année a vu la mémoire d’images, de vidéos et de voix se développer en un domaine de recherche à part entière.

M3-Agent de ByteDance Seed (arXiv:2508.09736) est la conception de référence principale. Il prend en charge des entrées visuelles et auditives en direct et crée un graphe de mémoire multimodal axé sur les entités : chaque personne, objet ou lieu devient un nœud, et l’agent relie les identifiants faciaux et vocaux au même nœud. Cela permet de répondre à des questions telles que « Que a dit l’homme à côté de Sarah au sujet du projet la semaine dernière ? », ce que ne peut pas faire un système basé uniquement sur du texte. Il exécute deux processus : une boucle de mémorisation extrait continuellement des visages, des voix et des faits sémantiques à partir de l’audio et de la vidéo en flux vers le graphe, tandis qu’une boucle de contrôle distincte analyse ce graphe pour répondre aux questions.

Afin de tester cette catégorie de systèmes, l’équipe a publié M3-Bench, comprenant 100 vidéos en perspective de robot nouvellement enregistrées ainsi que 929 vidéos provenant d’Internet, couvrant divers scénarios. Ces vidéos sont accompagnées de paires question-réponse visant à évaluer la compréhension humaine, l’extraction de connaissances générales et le raisonnement intermodal. M3-Agent surpasse les meilleurs modèles de vision-langage existants (Gemini 1.5 Pro et GPT-4o), avec des écarts de 6,7, 7,7 et 5,3 points respectivement sur les tests M3-Bench-robot, M3-Bench-web et VideoMME-long.

Les travaux connexes se multiplient. M2A propose une mémoire hybride à deux niveaux pour une interaction multimodale personnalisée. VideoAgent conserve des descriptions d’événements généraux ainsi que des informations sur l’état des objets suivis, tandis que WorldMM superpose des mémoires épisodiques, sémantiques et visuelles aux flux vidéo. Mem-Gallery (arXiv:2601.03515) est un benchmark conçu pour mesurer la manière dont la mémoire est conservée, organisée et évoluée au cours de longues conversations multimodales.

Les enjeux pratiques sont simples. Une webcam, un écran partagé, une ligne vocale ou un document rempli de graphiques indiquent à un agent que les systèmes basés uniquement sur du texte ne suffisent pas. D’ici un an environ, les grands SDK devraient proposer des éléments de construction de mémoire multimodale, et le graphe centré sur l’entité développé par M3-Agent semble être la solution la plus fiable pour servir de modèle.

Ce que mesurent les benchmarks

Quatre benchmarks servent de référence à la plupart des comparaisons.

• LongMemEval (NeurIPS 2024, arXiv:2410.10813) comprend 500 questions couvrant cinq compétences, insérées dans des historiques de conversation de longueurs variables : environ 115 K tokens pour la version S et près de 1,5 M tokens sur 500 sessions pour la version M. La principale conclusion est que les assistants commerciaux perdent 30 % de leur précision en ce qui concerne la mémoire inter-sessions, et jusqu’à 60 % dans les catégories les plus difficiles.

LoCoMo (ACL 2024) se concentre sur les conversations longues impliquant des questions complexes basées sur le temps et des questions à plusieurs étapes. Mem0 obtient +29,6 en ce qui concerne les aspects temporels et +23,1 pour les questions à plusieurs étapes, tandis que MemoryOS affiche une amélioration de +48,36 % sur l’indice F1 par rapport aux références GPT-4o-mini.

Deep Memory Retrieval provient du travail MemGPT. Zep obtient 94,8 % contre 93,4 % pour MemGPT.

M3-Bench est le premier benchmark sérieux de mémoire à long terme multimodale, utilisant des vidéos de robots et du web. M3-Agent devance Gemini 1.5 Pro et GPT-4o de 5 à 8 points.

Diverses versions plus récentes sont également prises en compte. Les sondes BEAM évaluent la mémoire à 1 M et 10 M de tokens, tandis que Mem0 v3 obtient des scores de 64,1 et 48,6. Context-Bench, développé par Letta en 2026, évalue l’ingénierie contextuelle agente, c’est-à-dire si un modèle sait quoi placer dans son propre contexte et quand. MemoryAgentBench (ICLR 2026, arXiv:2507.05257) est le nouvel outil le plus important. Sa méthode consiste à injecter un document une seule fois puis à le interroger répétitivement : les textes longs sont divisés en blocs de 512 ou 4 096 tokens et traités dans le cadre d’échanges multi-étapes. Deux ensembles de données spécifiquement conçus, EventQA et FactConsolidation, vérifient la récupération d’informations, l’apprentissage en temps de test ainsi que la gestion des faits contradictoires. MemBench (arXiv:2506.21605) ajoute une autre dimension en évaluant les agents selon leur efficacité, leur efficience et leur capacité, tout en notant séparément la mémoire factuelle et réflexive, ainsi que le fait de participer activement par rapport à une simple observation. D’ici la fin de 2026, ces deux outils seront probablement ceux qui serviront de référence par défaut.

La manière de se demander ce qu’un système de mémoire fait réellement, le rôle joué par LongMemEval pour les chats en 2025.

Avertissement : chaque fournisseur effectue des tests de performance avec la configuration qui met le mieux en valeur son architecture, il convient donc de se référer aux analyses par catégorie plutôt qu’aux titres principaux. En environnement de production, le coût des tokens et la latence comptent autant que la précision. Rejouer tout le contenu constitue une référence légitime, et toute couche de mémoire qui ne parvient pas à surpasser cette référence sur ces deux critères en même temps devrait en être gênée. D’ici 2026, tous les systèmes majeurs dépasseront cette barre.

Comparaison des conceptions

Analyse point par point :

• Sous-strate. Mem0 utilise un stockage vectoriel avec des liens de type hub-and-spoke entre les entités. Letta emploie une hiérarchie de mémoire virtuelle en plusieurs niveaux, Zep un graphe de connaissances temporel sur Neo4j, Cognee un graphe unifié ainsi que des stockages vectoriels et relationnels, et Memori SQL. AgentCore est géré à l’intérieur de Bedrock, Microsoft Foundry utilise Cosmos DB partitionné par utilisateur, et les Agents gérés d’Anthropic reposent sur un système de fichiers.
• Types de mémoire pris en charge. Mem0 couvre la mémoire sémantique et les entités. Letta prend en charge les quatre types définis par CoALA. Zep gère la mémoire épisodique, temporellement sémantique et communautaire. LangMem dispose de stockages sémantiques, épisodiques et procéduraux ; Memori propose une mémoire sémantique et épisodique en SQL ; AgentCore gère des épisodes structurés ; quant à Foundry, il ne prend en charge que les signaux à longue durée de vie.

Chemin d’écriture. Mem0 v3 effectue une extraction en une seule passe avec déduplication ultérieure. Letta modifie la mémoire à l’intérieur du boucle et la consolide pendant le temps de sommeil. Zep écrit des bords bi-temporels, AgentCore intègre l’inférence d’extraction dans son prix, et Foundry sélectionne les signaux tandis que le texte brut reste stocké dans le magasin de conversations.

Raisonnement temporel. Mem0 conserve des métadonnées de timestamp. Letta dispose de timestamps d’archivage ainsi que d’un traitement pendant le temps de sommeil. Zep est nativement bi-temporel et mène l’industrie dans ce domaine. AgentCore étiquette la mémoire à long terme avec des métadonnées, et Foundry gère le temps de manière implicite à travers les types de signaux.

Signaux de récupération. Mem0 fusionne les scores sémantiques, BM25 et d’entité. Zep combine la parcours de graphe, les vecteurs, BM25 et le temps. Cognee propose 14 modes, tandis que Memori s’appuie sur des requêtes SQL.

Portabilité. Letta utilise la norme ouverte .af et Anthropic permet l’export vers un système de fichiers. D’autres solutions offrent des exports spécifiques au fabricant.

Adéquation optimale. Mem0 convient à la personnalisation immédiate, aux agents vocaux et aux applications grand public. Letta est adaptée aux agents fonctionnant en continu, de type système d’exploitation, ainsi qu’aux agents de programmation. Zep s’adresse aux entreprises soumises à des réglementations nécessitant une auditabilité, aux équipes de recherche et développement de Cognee qui souhaitent un contrôle graphique, ainsi qu’aux petites équipes de Memori préférant SQL. AgentCore convient aux environnements AWS, Foundry aux environnements Microsoft, et Claude Managed Agents à quiconque utilise déjà la plateforme Claude.

Point clé concernant les titres. Mem0 : 94,4 sur LongMemEval. Zep : 94,8 % sur DMR. MemoryOS : +48,36 % de F1 sur LoCoMo. Letta Code : 42,5 % sur Terminal-Bench, premier parmi les agents open source. HippoRAG 2 : +7 % en matière de mémoire associative. Anthropic avec Rakuten : 97 % moins d’erreurs en première passe, un coût inférieur de 27 % et une latence réduite de 34 %. M3-Agent : 5 à 8 points d’avance sur les références vision-langage dans les benchmarks multimodaux.

Lorsque la mémoire est devenue une surface d’attaque

En mai 2026, la mémoire des agents a cessé d’être uniquement une question de précision et de coût pour devenir également un enjeu de sécurité.

Les signaux d’alerte sont apparus plus tôt dans l’année. Microsoft Security a écrit en février 2026 sur le « Poisoning des recommandations par l’IA », pratique consistant à manipuler la mémoire d’un assistant à des fins lucratives. Radware a ensuite présenté une démonstration de concept intitulée ZombieAgent : un fichier piégé dans un e-mail insère une entrée dans la mémoire d’un agent ChatGPT connecté à la boîte aux lettres de la victime, de sorte que chaque interaction déclenche cette entrée contaminée et fuit des données par le biais de canaux secondaires codés en URL. Un scénario d’entreprise rapporté montrait un agent d’analyse financière détourné accepter un résultat intermédiaire contaminé et lancer un flux de travail permettant de transférer des fonds sans autorisation, avant même qu’une personne ne puisse l’examiner.

Le poisonage de la mémoire est une pratique différente de l’injection de prompts ordinaire, pour trois raisons :

• Persistence. L’injection de commandes corrompt une seule réponse. Une mémoire contaminée corrompt toutes les réponses ultérieures qui accèdent à la clé concernée.
• Cachement efficace. Une entrée contaminée ressemble exactement à un contexte stocké légitime.
• Autonomie. Les agents agissent sur la mémoire via des appels d’outils, ce qui permet à une mémoire contaminée de provoquer des effets secondaires dans le monde réel sans aucune intervention humaine.

La défense est intervenue rapidement. OWASP a inclus le poisonage de mémoire dans sa liste des 10 problèmes majeurs pour les applications agnitives en 2026 sous le code ASI06 (Poisonage de mémoire et de contexte), et a publié l’implémentation de référence Agent Memory Guard à la mi-2026 :

• Bases de référence SHA-256 basées sur des clés de mémoire immuables telles que identity.user_id, ce qui permet d’identifier toute modification extérieure non autorisée.

Politiques de sécurité YAML qui associent les détections (tentatives d’injection, fuites de données sensibles, modifications de clés protégées, changements rapides, anomalies de taille) à des actions : allow, redact, quarantine ou block.

Feuille de route vers v0.4.0 (3e trimestre 2026) incluant une détection d’anomalies basée sur l’IA, une protection des bases de données vectorielles et un tableau de bord de surveillance en temps réel.

Un minimum raisonnable pour toute mise en œuvre mémoire cette année comprend des TTL, des fenêtres de validité, un enregistrement de l’origine à chaque écriture, des références cryptographiques pour les clés d’identité, des tests adversariaux réguliers, ainsi qu’une étape d’approbation humaine avant toute utilisation d’outils gérant des données financières ou sensibles. L’étude de référence sur les attaques et les défenses se trouve à l’adresse arXiv:2601.05504, et le Microsoft Agent Governance Toolkit intègre désormais des mesures d’atténuation ASI06 explicites.

Problèmes que personne n’a résolus

Même avec un ensemble de mesures de sécurité en place, beaucoup de choses restent non résolues :

• Mémoire obsolète. Un fait valable aujourd’hui peut devenir faux demain, et les stockages en écriture seule se détériorent avec le temps. Les TTL et les intervalles de validité constituent une solution, mais ils ne sont pas encore la norme par défaut.
• Identité entre sessions. Déterminer si deux sessions concernent la même personne ou le même projet est le sous-problème le plus difficile à résoudre, en particulier dans un espace de noms Mem0 multi-locataires comptant des milliers d’identités.
• Limite de récupération. La précision atteint son maximum avec trois à cinq blocs de mémoire récupérés, puis diminue. La fusion des signaux vectoriels, des mots-clés, des entités et de la récence constitue la méthode de référence en production, d’où le passage à plusieurs signaux dans Mem0 v3.

Comptabilité des coûts. L’affirmation « la mémoire économise des tokens » n’est valable que lorsque les appels de l’LLM basés sur l’extraction et la mise à jour coûtent moins que les tokens de contexte qu’ils permettent d’économiser. Pour les agents à faible volume, le calcul peut parfois s’inverser, ce qui fait que le coût par résultat réussi est le seul chiffre fiable.

Hierarchie mal classée. L’étude xMemory de 2026 a révélé que 44,91 % des mémoires étaient réaffectées entre différents niveaux d’hiérarchie au sein d’un système en fonctionnement, ce qui montre que la classification linéaire ou ponctuelle échoue. Les systèmes qui effectuent une reclassement, tels que A-MEM, memify de Cognee, les agents Letta’s sleep-time et le mécanisme de pagination intermédiaire de MemoryOS, sont déjà des vainqueurs précoce.

Évaluation limitée. LongMemEval et LoCoMo sont fiables, mais ne prennent en compte que le texte et sont conçus pour les conversations. M3-Bench et Mem-Gallery s’étendent vers le domaine multimodal, tandis que Context-Bench et Terminal-Bench visent les agents capables d’utiliser des outils. Personne n’a encore créé de test complet couvrant l’ensemble des fonctionnalités d’un agent.

Lignée floue entre les hyperscalers et le logiciel open source. Le taux de 97 % atteint par Rakuten avec Anthropic Managed Agents exerce une pression sur tous les fournisseurs de logiciel open source pour qu’ils obtiennent des résultats comparables.

Sélection en fonction de la situation

Un guide pratique pour 2026 :

• Personnalisation des consommateurs et agents vocaux : Mem0. Il s’intègre rapidement, grâce à des SDK matures compatibles avec 13 frameworks, 20 bases de données vectorielles et 3 plateformes vocales.
• Agents et coachs personnels à long terme : Letta. La hiérarchie du système d’exploitation ainsi que le calcul pendant les périodes de veille s’adaptent parfaitement aux tâches sur plusieurs semaines.
• Agents de codage sur une base de code privée : Letta Code, avec un agent à état unique par projet.
• Entreprises soumises à des réglementations nécessitant une audit : Zep avec Graphiti. Le modèle bitemporal en est la caractéristique principale.
• Équipes de recherche et développement souhaitant un contrôle graphique : Cognee, ou HippoRAG 2 en sous-couche.
• Équipes déjà utilisant LangGraph : LangMem, offrant le coût d’intégration le plus bas ainsi que la seule mémoire procédurale de première classe.
• Équipes qui souhaitent simplement utiliser SQL : Memori.
• Entreprises utilisant AWS : Bedrock AgentCore Memory, avec un tarif pay-as-you-go, des versions généralement disponibles et des notifications en streaming.
• Magasins Microsoft : mémoire ciblée par utilisateur d’Azure AI Foundry, avec partitionnement de Cosmos DB, débogage via DevUI et évaluations intégrées.
• Équipes sur la plateforme Claude : mémoire des agents gérés par Claude, portable sous forme de fichiers, et bénéficiant du meilleur taux de satisfaction client publié pour 2026.
• Agents multimodaux avec vision ou voix : modèle M3-Agent basé sur un graphe centré sur l’entité reliant les identifiants faciaux et vocaux. Aucun SDK de production n’existe encore, il faut donc le créer soi-même.
• Travaux réglementés nécessitant un haut niveau de confiance dans les domaines juridique, sanitaire ou financier : Zep ou Cognee, ainsi que des politiques OWASP Agent Memory Guard, des TTL et un historique d’audit. Jamais d’archive à écriture seule.

Où va la mémoire à l’avenir

En regardant vers la fin de 2026 et 2027, plusieurs tendances se détachent.

• La mémoire fait son entrée dans l’architecture. L’Engram de DeepSeek V4 constitue le meilleur exemple à cet égard : un système de récupération basé sur l’hashing avec complexité O(1) capable de gérer 1 million de tokens à un coût approximatif équivalent à celui de 128 K, atteignant même 97 % de précision dans les tests de type « aiguille dans une botte de foin » à cette échelle. Une conception à deux voies sépare la récupération des connaissances statiques du traitement en mémoire de travail dynamique, ce qui représente le plus proche que soit parvenu un modèle de pointe à considérer la mémoire comme un élément architectural et non simplement une astuce liée à la fenêtre de contexte.

La mémoire et l’apprentissage continu convergent. L’étude de Meta sur le fin-tuning à mémoire sparse (arXiv:2510.15103) a montré que l’apprentissage de nouveaux faits via des couches mémoire entraînait une dégradation de la performance sur les tâches non entraînées de seulement 11 %, contre 89 % pour un fin-tuning complet et 71 % pour LoRA. Cela dissipe la frontière entre une couche mémoire externe et une mémoire intégrée aux paramètres. Les modèles de pointe en 2027 pourraient intégrer des couches mémoire sparse natives servant de voie à faible oubli entre le stockage mémoire d’un agent et les poids du modèle.

La mémoire en tant que substrat pour l’RL. Le système MemRL, qui enregistre les intentions, les expériences et l’utilité tout en mettant à jour les valeurs Q à partir des résultats, transforme le rappel en signal d’amélioration de la politique. Les SDK de production l’adopteront probablement d’ici la fin de 2026 sous un nom tel que récupération pondérée par les résultats.

La récupération et la mémoire s’unifient. HippoRAG 2, A-MEM, MemoryOS ainsi que le stockage lié aux entités de Mem0 traitent tous l’historique d’un agent comme un corpus supplémentaire au sein d’un graphe. Les architectures futures proposeront une seule API de récupération pour les documents et la mémoire des agents, grâce à un backend hybride commun.

La consolidation pendant le sommeil devient la norme. Les agents de Letta conçus pour fonctionner pendant le sommeil, les systèmes de rêve d’Anthropic et la pagination segmentée de MemoryOS partagent une même idée : une réflexion hors ligne qui transforme des traces épisodiques éphémères en connaissances sémantiques durables. On peut s’attendre à ce que chaque framework majeur propose sa propre version d’ici la fin de 2026.

Mémoire multimodale dans les SDKs. Des benchmarks tels que Mem-Gallery et M3-Bench vont dans ce sens. Le graphe de M3-Agent est le design qui aura le plus de chances d’apparaître dans Mem0, Letta ou Zep d’ici 2027.

La gouvernance se transforme en réglementation. Après ZombieAgent et ASI06, les journaux d’audit, les règles de conservation des données et l’oubli consenti deviendront des exigences obligatoires pour les produits, et les auditeurs travaillant selon SOC 2 et ISO 42001 commenceront à poser directement des questions sur l’hygiène de la mémoire.

La mémoire procédurale prend son essor. La plupart des travaux menés jusqu’à présent ont porté sur la mémoire sémantique et épisodique. Le stockage procédural de LangMem, les notes évolutives d’A-MEM, le noyau auto-édité de Letta ainsi que les fonctionnalités de rêve d’Anthropic indiquent tous qu’un objectif plus ambitieux est en vue : des agents capables de mettre à jour leur propre comportement, et non seulement leurs propres connaissances factuelles.

Mémoire partagée entre les agents. Les équipes d’agents travaillant en essaim ont besoin d’un espace que chaque membre puisse lire et écrire, car les stockages privés par agent ne suffisent pas. Un tableau noir avec des protocoles de transfert, ainsi qu’une séparation claire entre une mémoire en temps réel pour l’exécution actuelle et une mémoire persistante entre les exécutions, sont essentiels. Les API multi-locataires de Mem0, le stockage d’archivage partagé de Letta, la portabilité des fichiers d’agent, ainsi que des recherches comme SRMT pour le repérage de chemins multi-agents, représentent des premiers pas dans ce domaine.

Mémoire privée et locale. SuperLocalMemory et SQLite-AI offrent une alternative crédible aux solutions exclusivement basées sur le cloud : SQLite, FTS5, l’évaluation bayésienne de la fiabilité et le clustering Leiden, tout cela sur le dispositif, sans utilisation d’IA de langage dans le processus de récupération des données. Apple, Google et Microsoft travaillent chacun sur des environnements d’exécution d’agents au niveau du système d’exploitation qui privilégient d’abord la mémoire locale, et des solutions natives SQL telles que Memori ainsi que des pipelines d’extraction de type Mem0 devraient être intégrés aux SDK mobiles d’ici la fin de 2026.

L’ingénieur en mémoire devient un poste professionnel. Le rapport de Mem0 présente l’ingénierie en mémoire comme une discipline à part entière, aux côtés de l’ingénierie des prompts et du contexte, avec quatre niveaux de mémoire (utilisateur, agent, équipe et flux de travail), chacun ayant des responsables, des règles de conservation et des profils de risque distincts. On peut s’attendre à ce que ce poste apparaisse dans les offres d’emploi pour l’infrastructure IA d’ici 2027.

Le point clé pratique

Pendant la majeure partie de l’ère des LLM, la gestion de la mémoire n’était qu’une solution provisoire : un prompt système caché, l’utilisation de RAG sur des conversations anciennes, ou une fenêtre de traitement de un million de tokens coûtant 5 dollars par requête, sans pour autant permettre d’obtenir la bonne réponse. En 2026, elle est devenue une couche à part entière, avec des fournisseurs, des produits cloud, des benchmarks, des méthodes d’écriture, un modèle de sécurité ainsi que ses propres modes de défaillance.

Si votre agent demande encore le nom de l’utilisateur le lundi, vous renoncez à bien plus que simplement à la précision. Vous continuez de payer pour un contexte complet tout en obtenant des résultats que pourrait surpasser une recherche dans une mémoire de 7 000 tokens, et vous laissez ainsi une surface d’attaque non gérée ouverte, tandis que des concurrents tels que Mem0 v3, les agents Letta sleep-time, le graphe temporel de Zep, AgentCore, la mémoire partitionnée Cosmos de Foundry ou les agents gérés par Claude comptent déjà leurs économies. La combinaison 97 % / 27 % / 34 % de Rakuten constitue désormais la référence pour une mémoire qui se rembourse elle-même, et la réduction de 40 % des tokens proposée par RevisionDojo correspond à la version destinée aux petites équipes. M3-Agent montre la voie grâce à la vision et à la voix, OWASP Agent Memory Guard fournit le système de sécurité, et le fin-tuning de mémoire Sparse de Meta laisse entrevoir comment la mémoire et les poids finiront par se fusionner.

L’année à venir en matière de conception d’agents ne dépendra pas de nouveaux modèles de base. Elle dépendra plutôt du fait de traiter la mémoire comme un système : à écrire, évaluer, gérer, protéger, consolider et améliorer comme n’importe quel autre logiciel de production. Les agents qui réussiront ne seront pas ceux disposant des plus grandes capacités de stockage. Ce seront ceux qui se souviennent réellement, qui se souviennent à travers différentes modalités et qui se souviennent de manière sécurisée.