Un agent IA qui « oublie » ce que vous venez de lui dire n’a pas de bug. Il fonctionne exactement comme prévu : un grand modèle de langage ne retient rien d’une requête à l’autre. Tout ce qui ressemble à de la mémoire est une couche que l’on construit autour de lui.
Comprendre la mémoire d’un agent IA, c’est démêler trois mécanismes que l’on confond sans cesse : la fenêtre de contexte, le RAG (retrieval-augmented generation, génération augmentée par la recherche) et l’état persistant. Ils ne résolvent pas le même problème. Les empiler au hasard produit des agents lents, chers et amnésiques. Les articuler proprement change tout.
pourquoi un agent perd le fil
Repartons de la base. Un modèle de langage est une fonction sans mémoire : vous lui envoyez du texte, il renvoie du texte. Entre deux appels, rien ne subsiste. La « conversation » que vous croyez tenir n’existe que parce qu’on lui réinjecte, à chaque tour, l’historique complet.
La mémoire d’un agent ne sert donc pas à le rendre plus intelligent. Elle répond à une question pratique : quelles informations placer sous ses yeux, au bon moment, pour qu’il agisse juste ? Trop peu, il invente ou se contredit. Trop, il se noie et coûte une fortune en tokens. Tout l’art tient dans cet arbitrage.
Et cet arbitrage se joue sur trois couches distinctes.
couche 1 : la fenêtre de contexte, mémoire de travail
La fenêtre de contexte, c’est tout ce que le modèle « voit » pendant un appel : votre instruction système, l’historique de l’échange, les documents collés, la dernière question. C’est sa mémoire de travail, immédiate et totale. Ce qui s’y trouve, il le connaît parfaitement. Ce qui n’y est pas n’existe pas pour lui.
Cette couche a deux limites dures. La première est une taille maximale, mesurée en tokens (unités de texte, à peu près des fragments de mots). Les modèles récents en encaissent des centaines de milliers, parfois davantage, mais ce plafond reste fini. La seconde limite est plus sournoise : au-delà d’un certain volume, le modèle traite moins bien l’information noyée au milieu d’un long contexte que celle placée au début ou à la fin. Phénomène bien documenté sous le nom de « lost in the middle ».
La fenêtre de contexte est donc rapide et fidèle, mais volatile et bornée. Elle excelle pour le tour de conversation en cours. Elle est inadaptée pour se souvenir d’un échange tenu il y a trois semaines, ou pour fouiller une base documentaire de dix mille pages. D’où la deuxième couche.
couche 2 : le RAG, retrouver la bonne information au bon moment
Le principe du RAG est simple à énoncer : plutôt que de tout charger dans le contexte, on stocke la connaissance à l’extérieur et on n’en récupère que les morceaux pertinents au moment de répondre.
Concrètement, on découpe les documents en passages, on les transforme en embeddings (représentations numériques du sens, où deux textes proches en signification sont proches en valeurs) et on les range dans une base vectorielle. À chaque question, on convertit la requête en embedding, on cherche les passages les plus proches, et on les injecte dans la fenêtre de contexte. L’agent répond alors « augmenté » par ces extraits.
Le RAG résout ce que le contexte ne peut pas : la mémoire de masse. Une documentation entière, des archives de tickets, un historique de conversations sur des mois. On n’a plus besoin de tout montrer au modèle, seulement le pertinent.
Mais le RAG déplace le problème vers la qualité de la recherche. Si la récupération ramène les mauvais passages, l’agent répond avec assurance… à côté. Trois leviers décident de sa fiabilité :
- Le découpage : des passages trop longs diluent le signal, trop courts perdent le contexte. Le bon grain dépend du corpus.
- La pertinence : la recherche par similarité sémantique seule rate souvent les termes exacts. La combiner à une recherche par mots-clés (recherche hybride) rattrape beaucoup d’échecs.
- Le reranking : un second tri, plus fin, des passages candidats avant injection, qui améliore nettement la précision finale.
Le RAG n’est pas un interrupteur que l’on active. C’est un pipeline que l’on règle.
couche 3 : l’état persistant, ce que l’agent ne doit jamais oublier
Reste une catégorie d’information que ni le contexte ni le RAG ne traitent bien : les faits structurés et durables. Le prénom de l’utilisateur, ses préférences, l’étape en cours d’un processus, le solde d’un compte, la liste des tâches déjà accomplies.
Ces données n’ont rien à faire dans une base vectorielle : on ne les « cherche » pas par similarité, on les lit par clé. Elles vivent dans un état persistant classique : une base de données, un fichier, une table SQLite, un magasin clé-valeur. L’agent y écrit et y lit explicitement, comme n’importe quel programme.
C’est la couche la plus négligée, et la plus structurante. Un agent qui mémorise vos préférences entre deux sessions, qui reprend une tâche interrompue là où il l’avait laissée, qui ne redemande pas trois fois la même chose : cette continuité ne vient pas du modèle. Elle vient d’un état que vous avez conçu, mis à jour à chaque action décisive.
La règle est nette : tout ce qui doit survivre de façon exacte et durable n’appartient ni au contexte ni au RAG. Il appartient à l’état.
RAG ou contexte long : un faux débat
À chaque saut de capacité des modèles, la même prophétie revient : les fenêtres de contexte deviennent si grandes que le RAG serait condamné. Pourquoi s’embêter à indexer si l’on peut tout coller dedans ?
Le raisonnement séduit, mais confond trois choses différentes : le possible, le fiable et le rentable. Oui, on peut techniquement charger un corpus entier dans un long contexte. Non, ce n’est ni le plus fiable ni le plus économique.
Trois raisons font tenir le RAG, indépendamment de la taille des fenêtres. Le coût d’abord : facturer des centaines de milliers de tokens à chaque appel, alors que dix passages suffiraient, n’a aucun sens à l’échelle. La latence ensuite : un contexte gigantesque ralentit chaque réponse. La pertinence enfin : noyer la bonne information dans un océan de texte dégrade la qualité, là où une récupération ciblée la met en évidence.
La vraie question n’est donc pas « RAG ou contexte long ». C’est : quelle information mérite d’occuper le contexte à cet instant précis ? Le contexte long est un budget plus généreux, pas une dispense de réfléchir à ce qu’on y met.
combiner les trois couches sans dette
Un agent solide ne choisit pas une couche. Il les fait travailler ensemble, chacune à son poste. Une architecture type ressemble à ceci :
- L’état persistant détient l’identité et la progression : qui est l’utilisateur, où en est la tâche, quelles décisions sont actées. On le lit au démarrage de chaque session.
- Le RAG détient la connaissance de masse : documentation, archives, historique long. On y puise à la demande, en fonction de la requête.
- La fenêtre de contexte assemble, à chaque tour, le strict nécessaire : l’instruction système, les faits d’état pertinents, les passages récupérés, l’échange en cours.
La dette technique surgit quand ces frontières se brouillent : des préférences utilisateur enfouies dans une base vectorielle qu’on n’arrive plus à mettre à jour proprement, un historique de conversation gonflé qu’on réinjecte intégralement à chaque appel, des faits critiques laissés à la merci de la récupération sémantique. Chaque couche a un rôle. Lui en faire jouer un autre se paie plus tard.
les pièges qui reviennent le plus souvent
Quelques pièges reviennent assez pour mériter d’être nommés.
Le premier est la contamination de contexte : on accumule l’historique sans jamais le résumer ni l’élaguer. Au fil de la conversation, le contexte enfle, le modèle ralentit, la facture grimpe, et la qualité baisse à mesure que l’information utile se dilue. La parade : résumer périodiquement les vieux tours, ne garder que les faits saillants, basculer le reste dans l’état ou le RAG.
Le deuxième est l’oubli silencieux. L’agent semble avoir mémorisé une consigne parce qu’elle figurait dans le contexte… jusqu’à ce qu’elle en sorte, faute d’avoir été écrite dans l’état. Ce qui doit durer doit être persisté explicitement, jamais supposé.
Le troisième est le coût des tokens traité comme une variable d’ajustement de fin de projet. La mémoire est le premier poste de dépense d’un agent en production. Une conception qui ne distingue pas ce qui mérite le contexte de ce qui peut rester dehors devient vite intenable à l’échelle.
cadrer la mémoire d’un agent avant d’écrire une ligne
Avant de programmer quoi que ce soit, il vaut mieux trancher ces questions. Elles décident de l’architecture bien plus que le choix du modèle.
- Quelles informations doivent survivre entre deux sessions ? -> état persistant.
- Quelles connaissances sont trop volumineuses pour le contexte mais consultables ? -> RAG.
- Que faut-il absolument sous les yeux du modèle à chaque tour ? -> contexte, et rien de plus.
- Comment l’historique sera-t-il résumé ou élagué quand il grossit ?
- Quels faits sont si critiques qu’ils ne doivent jamais dépendre d’une récupération approximative ?
La mémoire d’un agent IA n’est pas une fonctionnalité que l’on branche. C’est une décision d’architecture, prise tôt ou subie plus tard. Les modèles changeront, les fenêtres de contexte s’élargiront encore, les bases vectorielles évolueront. Mais la distinction entre travailler, retrouver et persister, elle, ne périmera pas. C’est elle qui sépare un agent qui suit le fil d’un agent qui le perd.
Questions frequentes
Quelle est la différence entre la fenêtre de contexte et la mémoire d’un agent IA ?
La fenêtre de contexte est la mémoire de travail immédiate : ce que le modèle voit pendant un appel. La « mémoire » d’un agent, au sens large, désigne l’ensemble des couches qu’on construit autour, dont le contexte n’est qu’une partie, aux côtés du RAG et de l’état persistant.
Le RAG devient-il inutile avec les fenêtres de contexte géantes ?
Non. Même quand tout charger devient techniquement possible, le RAG reste préférable pour le coût, la latence et la pertinence. Récupérer dix passages ciblés bat presque toujours l’injection d’un corpus entier, qui dilue l’information utile et alourdit chaque réponse.
Où stocker les préférences durables d’un utilisateur ?
Dans un état persistant classique : base de données, fichier ou table SQLite, lu par clé. Ces faits structurés ne relèvent pas de la recherche sémantique du RAG, et le contexte les perd dès qu’il se vide.
Comment éviter qu’un agent sature son contexte au fil d’une longue conversation ?
En résumant périodiquement les anciens tours, en ne conservant que les faits saillants et en déportant le reste vers l’état ou le RAG. Réinjecter tout l’historique brut à chaque appel dégrade la qualité et fait exploser le coût en tokens.
