Loïc BoninLB
← Veille

ia

La mémoire pour agents ia expliquée

8 juillet 2026·4 min de lecture

Pourquoi les agents perdent la mémoire et comment résoudre le problème

La persistance de la mémoire est un point important des agents de développement. En cours de session, l'accumulation de lectures de fichiers et d'historiques sature rapidement la fenêtre de contexte des modèles de langage, faisant s'envoler la consommation de jetons et dégradant la pertinence des réponses. Face à cette limite physique, les environnements de développement et les outils en ligne de commande (comme Claude Code, Cursor ou Antigravity) délaissent les sessions sans état pour concevoir des structures de mémoire persistante et structurée que nous allons voir dans cet article.

L'amorçage déclaratif et l'injection de contexte

Au démarrage d'une conversation, les agents commencent sans aucun historique. Pour leur donner des repères immédiats sans gaspiller de ressources, le système effectue une étape d'amorçage.

Le fichier de configuration, comme le fichier de contexte local de Claude Code ou les règles de Cursor, est lu par l'interface de développement au lancement de l'outil. Cette interface l'injecte dans le message système, qui constitue la directive prioritaire lue par le modèle avant de traiter la demande de l'utilisateur.

Le format moderne de règles de Cursor pousse cette logique plus loin en utilisant des filtres basés sur des masques de recherche de fichiers. Lorsque l'agent ouvre un document, l'éditeur vérifie si le chemin correspond à l'un des masques définis. Si c'est le cas, les instructions associées sont ajoutées de manière dynamique au contexte de l'agent. De même, Antigravity utilise un dossier de personnalisation locale pour charger des instructions de comportement et des compétences spécialisées en fonction des besoins de la tâche.

La persistance en cours de session : les Memory Stores d'Anthropic

Conserver l'historique complet des discussions en cours de session pose un double problème : cela augmente la taille de la conversation, ce qui ralentit les réponses, et cela dilue l'attention du modèle sur des détails obsolètes ou sans importance.

Pour y répondre, Anthropic a introduit les Memory Stores pour les Claude Managed Agents : un espace de stockage persistant créé par l'application hôte via l'API des agents managés. Lors du démarrage d'une session, cet espace est monté directement dans l'environnement d'exécution de l'agent sous la forme d'un répertoire partagé (situé par défaut dans le chemin système /mnt/memory/{nom-du-store}/). L'agent peut alors lire et écrire des fichiers dans ce dossier en cours de session en utilisant ses outils de fichiers habituels ou des commandes de terminal de base, sans passer par un mécanisme d'extraction séparé. Pour consolidé les mémoires manuellement, une opération de maintenance optionnelle, la « dreaming session », existe.

L'avantage principal de cette approche tient à l'accès programmatique complet que conserve l'application qui pilote l'agent sur ces fichiers, en dehors même de la session, via l'API REST. Il devient ainsi possible d'injecter des données initiales (seeding), d'auditer en direct ce que l'agent écrit, ou d'exporter l'historique vers des bases de données internes. Chaque écriture de l'agent est enregistrée comme une version immuable associée à la session en cours, permettant une traçabilité totale et une correction manuelle si le modèle enregistre une information erronée.

Pour faire simple, pendant que le collaborateur (l'agent) travaille dans la pièce, il pioche et range des dossiers dans un tiroir physique à sa portée. Le superviseur de l'entreprise (votre application) peut ouvrir ce même tiroir à tout moment pour vérifier les documents, en ajouter de nouveaux ou corriger une fiche mal classée, sans jamais perturber le travail en cours.

La cartographie sémantique : indexation vectorielle contre graphe structurel

Le code possède une structure logique stricte que la recherche de texte classique ou sémantique ne peut appréhender de manière optimale. Plusieurs approches existe pour indexer un projet de développement, en voici deux :

  • L'indexation vectorielle sémantique

Les outils comme Cursor découpent le code en segments, calculent des coordonnées mathématiques représentant leur sens sémantique et recherchent les morceaux les plus proches de la requête de l'utilisateur. Pour éviter de recalculer ces coordonnées à chaque modification de fichier, l'éditeur s'appuie sur des arbres de vérification sémantiques, qui comparent les signatures des fichiers pour ne re-indexer que les portions modifiées. La recherche vectorielle s'apparente à chercher des recettes dans un livre de cuisine en parcourant l'index des mots-clés. On trouve des pages contenant les ingrédients demandés, mais sans comprendre comment les étapes s'enchaînent.

  • Le graphe de connaissances structurel

À l'inverse de la recherche vectorielle, le serveur de protocole de contexte codebase-memory-mcp de DeusData s'appuie sur un analyseur syntaxique pour examiner l'arbre de syntaxe abstraite du code. Il ne stocke pas de texte, mais crée un graphe représentant les connexions réelles du projet : les dépendances d'une fonction, les classes qui en héritent ou les routes réseau qui aboutissent à un contrôleur. L'agent interroge ce graphe de relations en direct via le protocole d'outils partagés. Le graphe de relations est le schéma de plomberie d'un immeuble. Si vous fermez une vanne, le schéma vous indique immédiatement quels appartements n'auront plus d'eau, sans vous obliger à inspecter chaque pièce du bâtiment.

Le serveur de DeusData indexe la plupart des bases de code en quelques millisecondes. Un dépôt de la taille du noyau Linux (environ 28 millions de lignes) prend autour de trois minutes pour une indexation complète. En s'appuyant sur Tree-Sitter tree-sitter/tree-sitter pour l'analyse syntaxique, et des requêtes structurelles performantes (base de données en graphe), il permet aux agents d'obtenir des réponses ultra rapide une fois l'index construit. Cette approche réduit la consommation de jetons de plus de 99% par rapport à une recherche textuelle exhaustive. De plus, elle prend en charge le partage d'index pré-calculés à l'échelle de l'équipe (Team-Shared Graph Artifacts), évitant de recalculer l'analyse sémantique sur chaque poste de travail pour un projet partagé.

L'organisation des architectures à long terme

Lorsque les tâches de développement s'étendent sur plusieurs heures ou plusieurs jours, les sessions uniques saturent et les agents doivent s'organiser en structures distribuées et persistantes. Voici deux approches, développées indépendamment par des acteurs différents, qui illustrent ce mouvement.

Le découpage à long terme de ByteDance : DeerFlow

Pour les tâches complexes nécessitant des minutes ou des heures de travail (long-horizon), le projet DeerFlow de ByteDance propose un environnement de coordination où un agent principal supervise des sous-agents spécialisés. Chaque sous-agent travaille dans un contexte isolé. Il ne voit ni le contexte de l'agent principal ni celui des autres sous-agents, et communique uniquement via des rapports de synthèse structurés, ce qui limite les interférences sans nécessiter une sandbox d'exécution distincte pour chacun.

Pour maintenir la fluidité du contexte sur la durée, ce système met en œuvre une politique de gestion agressive : il compresse les conversations en résumant les sous-tâches terminées, externalise les résultats intermédiaires sur le système de fichiers local et gère la récupération des erreurs lors des interruptions d'outils en injectant des résultats fictifs pour éviter le blocage des modèles de raisonnement. De plus, sa mémoire persistante intègre un filtre de déduplication lors de l'écriture pour éviter l'accumulation infinie de préférences similaires au fil des sessions. Une passerelle de messagerie connectée à des outils de communication (comme Slack) permet de notifier l'utilisateur et d'échanger avec lui en cours d'exécution.

Le pipeline de consolidation d'agentmemory

En parallèle de ces systèmes de fichiers bruts et de ces patterns d'orchestration, des bibliothèques indépendantes comme agentmemory apportent une structure inspirée du cerveau humain pour lutter contre l'oubli et le coût des jetons. Ce projet, compatible avec de nombreux agents et harness (dont Claude Code, Codex ou Hermes), n'est rattaché à aucun des deux systèmes précédents : c'est une couche de mémoire ouverte, pensée pour fonctionner indépendamment de l'outil qui pilote l'agent.

Cette bibliothèque s'organise autour d'un pipeline de consolidation à quatre niveaux, calqué sur les strates de la mémoire humaine : une couche de travail qui capture les observations brutes de la session en cours, une couche épisodique qui résume ce qui s'est passé une fois la session terminée, une couche sémantique qui en extrait des faits et des patterns durables, et une couche procédurale qui capitalise sur les workflows et les décisions récurrentes.

Chaque interaction passe par un filtre de déduplication basé sur l'empreinte numérique SHA-256 et un scanner de confidentialité qui supprime les clés d'API et les secrets. Le système modélise ensuite la courbe de l'oubli (courbe d'Ebbinghaus) : les souvenirs consultés fréquemment sont renforcés, tandis que les faits obsolètes ou contradictoires sont détectés et supprimés lors de balayages de nettoyage planifiés en arrière-plan. Ce serveur de mémoire permet à n'importe quel agent compatible MCP de conserver un profil de projet à jour, injecté sous forme de résumé compact lors des lancements de session.

Un article de veille sur agentmemory est disponible ici

Conclusion

Les fenêtres de contexte géantes ne résoudront pas la dérive de l'attention ni le coût des appels d'API. La viabilité des agents de développement dépendra de notre capacité à structurer, versionner et gouverner la mémoire en dehors des modèles de langage, en la traitant comme un véritable système d'exploitation de la connaissance.

Liens Utiles:

IAdéveloppement agentiqueAgent