Mémoire courte et longue

Pourquoi la mémoire est le vrai goulot d'étranglement

Un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire ne « se souvient » de rien au sens où un programme classique retiendrait une variable en mémoire vive entre deux appels. Chaque requête au modèle repart d'une fenêtre de texte reconstituée à partir de zéro : l'historique de conversation, les résultats d'outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire, les instructions système. Tout ce que l'agent semble « savoir » d'un tour à l'autre n'est en réalité que du texte réinjecté explicitement dans le promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire suivant.

Cette réalité change la nature du problème. Concevoir la mémoire d'un agent, ce n'est pas choisir une base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire : c'est décider quoi réinjecter, dans quel ordre, sous quelle forme, et surtout quoi ne pas réinjecter. Un agent qui garde tout devient lent, cher et parfois moins précis. Un agent qui oublie mal perd le fil d'une tâche à mi-parcours. La mémoire est un arbitrage permanent entre coût, pertinence et fiabilité, pas une fonctionnalité qu'on active une fois pour toutes.

Un modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire n'a pas de mémoire persistante intrinsèque entre deux appels API. Ce qu'on appelle « la mémoire d'un agent » désigne toujours un mécanisme externe au modèle : un historique conservé côté application, une base vectoriellebase vectorielleIABase spécialisée qui indexe des embeddings pour retrouver rapidement les passages les plus proches d'une requête (cœur du RAG).Voir dans le glossaire interrogée avant l'appel, un résumé stocké quelque part. Le modèle lui-même ne conserve aucun état d'un appel à l'autre.

La fenêtre de contexte : une ressource finie et coûteuse

La fenêtre de contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire (context window) désigne la quantité totale de texte — mesurée en tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire, pas en caractères — que le modèle peut recevoir en entrée à un instant donné, instructions système, historique et sortie attendue compris. Les modèles actuels annoncent des fenêtres allant de 128 000 à plusieurs millions de tokens selon les fournisseurs, mais ce chiffre maximal masque deux réalités opérationnelles.

D'abord, un token n'est pas un mot. En français, on compte en moyenne entre 1,3 et 1,8 token par mot selon la ponctuation et les accents ; un document de dix pages représente déjà plusieurs milliers de tokens. Ensuite, et c'est le point le plus souvent ignoré, le coût de traitement n'est pas linéaire avec la taille du contexte : le mécanisme d'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire interne d'un transformeur a une complexité qui croît avec le carré de la longueur de séquence dans son implémentation naïve. Les fournisseurs optimisent cette complexité (attention par fenêtres glissantes, mise en cache des clés-valeurs), mais en pratique, la latence et le coût par appel augmentent bien plus vite que la taille du contexte ne le suggère intuitivement.

Il existe aussi un phénomène documenté et vérifiable empiriquement : la dégradation de rappelrappelIAProportion des cas positifs réels effectivement détectés par un modèle. Sur un jeu déséquilibré, c'est un indicateur bien plus parlant que l'exactitude globale.Voir dans le glossaire au milieu du contexte, parfois appelée lost in the middle. Un modèle retrouve plus fiablement une information placée au début ou à la fin d'un long contexte qu'une information noyée au centre. Ce n'est pas une légende — plusieurs benchmarks publics le montrent de façon reproductible sur des tâches de type « aiguille dans une botte de foin ». Concrètement, empiler cinquante pages de documentation dans le contexte d'un agent ne garantit pas que l'instruction critique placée en page vingt-cinq sera correctement exploitée.

Disposer d'une fenêtre de contexte de un million de tokens ne dispense donc pas de gérer la mémoire avec discipline. Un contexte surchargé coûte plus cher, répond plus lentement, et n'améliore pas mécaniquement la qualité des réponses — il peut même la dégrader en diluant l'information utile parmi du texte non pertinent. La taille disponible n'est pas un objectif à remplir.

Mémoire courte : l'historique de la conversation en cours

La mémoire courte, ou mémoire de travail, correspond à l'historique des tours d'une même session : les messages utilisateur, les réponses du modèle, les appels d'outils et leurs résultats. C'est la forme de mémoire la plus simple à implémenter — il suffit d'accumuler les messages dans une liste et de la renvoyer intégralement à chaque appel — et c'est aussi celle qui atteint ses limites le plus vite.

Dans un agent qui exécute une tâche longue (recherche multi-étapes, débogage itératif, navigation dans un système de fichiers), chaque appel d'outil ajoute des messages : la décision du modèle, la requête envoyée, la réponse brute de l'outil. Un agent qui explore une arborescence de fichiers ou interroge une API verbeuse peut saturer une fenêtre de contexte de 128 000 tokens en une vingtaine de tours seulement, sans qu'aucune information stratégique nouvelle n'ait été ajoutée — la majorité du volume est constituée de résultats bruts d'outils, souvent redondants.

Trois stratégies pratiques permettent de contenir cette croissance :

• Troncature simple — ne conserver que les N derniers tours. Rapide et gratuite en calcul, mais elle supprime des informations potentiellement encore pertinentes sans discernement.
• Résumé progressif (compaction) — lorsqu'un seuil de tokens est atteint, un appel dédié au modèle condense les tours anciens en un résumé court, qui remplace l'historique détaillé tout en préservant les décisions et faits clés.
• Filtrage sélectif des résultats d'outils — tronquer ou résumer spécifiquement les sorties volumineuses (listings de fichiers, réponses API longues) tout en conservant intact le raisonnement du modèle, qui est en général bien plus court.

Un résumé généré par le modèle lui-même, à un point de pivot de la conversation, préserve la continuité logique de la tâche — objectif, contraintes, décisions déjà prises — alors qu'une troncature aveugle peut faire disparaître une instruction donnée par l'utilisateur en tout début d'échange. Le coût d'un appel de résumé supplémentaire est presque toujours inférieur au coût de renvoyer l'historique complet à chaque tour sur une tâche longue.

Mémoire longue : ce qui doit survivre à la session

La mémoire longue regroupe tout ce qui doit persister au-delà d'une seule session de conversation : préférences d'un utilisateur, faits appris lors d'échanges précédents, documentation métier, historique de tickets déjà traités. Contrairement à la mémoire courte, elle n'est jamais chargée en intégralité dans le contexte — elle est interrogée au moment où on en a besoin, puis seule la portion pertinente est injectée dans le prompt.

Trois architectures de stockage couvrent la majorité des cas d'usage :

La base vectorielle est la brique la plus associée à la mémoire longue, en particulier via la RAG (retrieval-augmented generation) : les échanges passés ou les documents de référence sont découpés, encodés et indexés, puis une requête de similarité récupère les fragments les plus proches sémantiquement de la question en cours avant de les injecter dans le prompt. Le store clé-valeur, plus simple, convient mieux aux faits ponctuels et structurés — « l'utilisateur préfère les réponses en anglais », « le projet cible utilise PostgreSQL 15 » — qui n'ont pas besoin d'une recherche sémantique pour être retrouvés.

Un agent de support technique traite un ticket. À l'ouverture de la conversation, il interroge un store clé-valeur pour récupérer le plan d'abonnement du client et son historique de tickets résolus, puis une base vectorielle pour retrouver les articles de documentation les plus proches du problème décrit. Seuls ces éléments filtrés — quelques centaines de tokens — sont injectés dans le contexte, pas l'intégralité de l'historique du compte client qui pourrait représenter des dizaines de milliers de tokens accumulés sur plusieurs années.

L'oubli volontaire : une fonctionnalité, pas un défaut

Concevoir un agent qui oublie délibérément semble contre-intuitif, mais c'est une nécessité opérationnelle. Un système qui accumule tout sans jamais rien retirer finit par présenter trois symptômes convergents : coût croissant par appel, latence croissante, et dilution de l'information pertinente dans un volume de texte que le modèle traite moins fiablement — le phénomène de dégradation au milieu du contexte évoqué plus haut s'aggrave mécaniquement avec la taille du contexte.

L'oubli doit être conçu, pas subi. Cela signifie définir explicitement une politique : que devient une information une fois qu'elle sort de la fenêtre active ? Trois issues sont possibles, et un système de mémoire robuste les combine généralement toutes les trois selon la nature de l'information :

1. Suppression pure — l'information disparaît. Approprié pour du bruit opérationnel sans valeur de rétention (accusés de réception d'outils, messages de progression intermédiaires).
2. Compression — l'information est résumée puis conservée sous forme condensée. Approprié pour le contexte conversationnel qui garde une valeur informative réduite mais non nulle.
3. Externalisation — l'information sort du contexte actif mais reste accessible via une requête ultérieure dans un store persistant. Approprié pour tout ce qui a une probabilité non négligeable d'être redemandé plus tard.

Une erreur fréquente consiste à tronquer l'historique en ne regardant que l'ordre chronologique, sans distinguer le rôle des messages. Si l'instruction système ou une contrainte critique donnée par l'utilisateur au tout début de la session se trouve mécaniquement écartée par une troncature « garder les N derniers messages », l'agent continue à fonctionner sans erreur visible — mais en ignorant silencieusement une règle que l'utilisateur croit toujours active. Ce type de régression est particulièrement difficile à diagnostiquer parce qu'il ne produit aucune erreur, seulement un comportement progressivement différent de ce qui était attendu.

Construire une politique de mémoire : les questions à trancher

Avant d'implémenter un mécanisme de mémoire, il est plus utile de répondre à quelques questions de conception que de choisir un outil. La technologie de stockage — Postgres avec extension vectorielle, base vectorielle dédiée, simple fichier JSON — est secondaire face aux décisions suivantes :

• Quelles informations ont une durée de vie limitée à la session, et lesquelles doivent survivre à la fermeture de la conversation ?
• Quel est le seuil de déclenchement de la compaction, et sur quel critère — nombre de tokens, nombre de tours, temps écoulé ?
• Les instructions système et les contraintes explicites de l'utilisateur sont-elles protégées d'une troncature automatique, ou risquent-elles d'être écartées comme n'importe quel autre message ?
• Quelle latence supplémentaire un appel de récupération en mémoire longue (recherche vectorielle, requête clé-valeur) introduit-il dans le temps de réponse total, et est-elle acceptable pour l'usage visé ?
• Comment mesure-t-on qu'un résumé de compaction n'a pas fait perdre une information critique — existe-t-il un test de non-régression sur des scénarios longs ?

Interroger une base vectorielle ou un store externe ajoute une latence réseau et un appel supplémentaire au pipeline, même si le volume de tokens réinjecté reste faible. Sur un agent à fort volume, cette latence cumulée peut devenir le facteur limitant avant même le coût des appels au modèle. La mémoire longue résout un problème de pertinence et de coût en tokens, pas un problème de vitesse.

Checklist avant mise en production

• La croissance de l'historique de conversation est bornée par un mécanisme explicite (troncature, compaction ou les deux), pas laissée à la taille maximale de la fenêtre de contexte.
• Les instructions système et contraintes utilisateur critiques sont exclues de toute troncature automatique, ou reconduites systématiquement dans chaque résumé.
• Les résultats d'outils volumineux (listings, réponses API brutes) sont filtrés ou résumés avant réinjection, séparément du raisonnement du modèle.
• Un store de mémoire longue existe pour toute information ayant une probabilité réelle d'être redemandée après la fin de la session.
• Le coût et la latence de chaque récupération en mémoire longue sont mesurés, pas seulement le coût des appels au modèle.
• Un test de non-régression vérifie qu'une information injectée en début de tâche longue reste exploitée correctement après plusieurs cycles de compaction.

La mémoire d'un agent n'est jamais un composant qu'on installe une fois. C'est un arbitrage continu entre ce qu'il faut garder sous la main, ce qu'il faut résumer, et ce qu'il faut aller rechercher au bon moment — et cet arbitrage se règle en observant le comportement réel de l'agent sur des tâches longues, pas en maximisant la taille de la fenêtre de contexte disponible.