Chapitre 10 — Mémoire de tâche à long horizon

Publié le: 2026-04-08 Dernière mise à jour le: 2026-06-12 Version: 1

Chapitre 10 — Mémoire de tâche à long horizon

Dixième billet de la tournée chapitre par chapitre de LLM Primer IV : Concevoir la cognition de l'IA avec MCP. Le chapitre où la question cesse d'être « combien rentre » pour devenir « quoi se rappeler et quoi oublier », et où les fenêtres de contexte à sept chiffres qui sortent aujourd'hui se révèlent repousser le mur d'une heure plutôt que de le faire disparaître.


Pourquoi ce chapitre existe

Un agent qui tourne trente secondes peut porter dans son prompt tout ce dont il a besoin. Un agent qui tourne trois heures ne le peut pas. Le travail qu'il fait dans la première heure ne tiendra pas à côté de celui qu'il fait dans la troisième, et la question de ce qu'il faut se rappeler et de ce qu'il faut oublier devient le problème d'ingénierie central. La fenêtre de contexte n'est plus un budget à gérer ; c'est une surface de travail qu'il faut continuellement rafraîchir contre un store plus profond. Ce chapitre porte sur l'architecture du souvenir — mémoire à court terme pour le raisonnement immédiat, mémoire à long terme pour la persistance entre sessions, et les techniques de compaction et d'externalisation qui les relient.

En une ligne : la mémoire à court terme n'est pas la mémoire du modèle mais celle de la boucle d'agent, matérialisée en texte et injectée à chaque appel — ce qui signifie que chaque décision sur ce que le modèle se rappelle est une décision que la boucle prend explicitement, dans le code, sans état caché à déboguer.

10.1 Mémoire à court terme : fenêtres, scratchpads, ReAct

La mémoire à court terme, c'est tout ce qui se trouve dans la fenêtre de contexte courante et qui est disponible sans recherche externe. La politique la plus simple est la fenêtre glissante : garder le prompt système et les descriptions d'outils en haut, garder les N derniers tours en bas, jeter tout entre les deux. Cela fonctionne tant que le contexte pertinent est récent, ce qui est vrai pour de courtes conversations et faux pour à peu près tout le reste. Le mode de défaillance est propre — une fois qu'un tour est jeté, il est perdu — et l'agent oubliera de manière visible les instructions de l'utilisateur au moment prévisible où la fenêtre se remplit pour la première fois.

La couche suivante est le scratchpad, une région structurée du contexte où le modèle écrit délibérément. Les scratchpads internes portent le raisonnement intermédiaire à l'intérieur de la boucle ; les scratchpads externes écrivent des notes via un appel d'outil dans un tampon stocké que les contextes futurs injectent. Le patron qui a donné aux scratchpads leur forme canonique est ReAct — Reason and Act — introduit par Yao et collègues en 2022. La boucle entrelace pensée, action, observation, jusqu'à ce que le modèle décide qu'il a la réponse. La structure externalise le raisonnement en artefacts textuels explicites auxquels le modèle peut se reporter, et donne à la boucle d'agent un échafaudage visible pour les opérations mémoire : les pensées peuvent être résumées, les actions dédupliquées, les observations compactées. Les agents construits sans ReAct ou une variante proche tendent à enchevêtrer raisonnement et action de façons qui rendent leur état opaque.

Un complément pratique est Reflexion, qui ajoute une étape de réflexion explicite où le modèle évalue ses actions récentes et écrit une critique dans le scratchpad pour la prochaine tentative. Les frameworks d'agents modernes mêlent les deux en une seule boucle configurable, avec la réflexion déclenchée par un signal d'échec plutôt que lancée à chaque cycle.

10.2 Mémoire à long terme : épisodique et sémantique

Quand la mémoire à court terme se termine, la mémoire à long terme commence. La distinction de sciences cognitives entre mémoire épisodique (événements spécifiques) et mémoire sémantique (faits généraux) s'est révélée utile pour les agents. La mémoire épisodique est le registre des interactions passées spécifiques ; la mémoire sémantique est la connaissance distillée qui a survécu — que cet utilisateur préfère le système métrique, que la commande de déploiement de ce projet est make ship, que cette API renvoie des erreurs qui ressemblent à des succès.

La mémoire épisodique est, dans la pratique actuelle, presque toujours une base de données vectorielle. Chaque interaction passée est embarquée, stockée avec des métadonnées, et récupérée au moment de la requête par similarité sémantique. Le patron est le RAG appliqué au passé propre de l'agent plutôt qu'à un corpus de documents, et l'ingénierie — découpage, choix d'embedding, évaluation de récupération — est largement identique à ce que couvre le Volume III.

La mémoire sémantique est moins standardisée. Les deux substrats dominants sont les stores clé-valeur structurés et les graphes de connaissances. Les stores clé-valeur sont simples, rapides, faciles à inspecter ; les graphes soutiennent des requêtes multi-hop comme « quelle est la commande de déploiement pour le projet sur lequel l'utilisateur travaille en ce moment » mais demandent de la maintenance et un langage de requête. La plupart des agents de production commencent par clé-valeur et passent à un graphe seulement quand les requêtes nécessitent vraiment des jointures. Beaucoup ne le font jamais.

La politique de mise à jour est l'endroit où la plupart des équipes se mettent en difficulté. Un fait extrait d'une seule conversation n'est pas nécessairement vrai en général. Une politique naïve qui promeut chaque assertion en mémoire sémantique produira un store corrompu qui se contredit. La discipline qui a émergé consiste à pondérer les assertions par contexte, à versionner les faits avec horodatages et provenance, et — pour les domaines à fort enjeu — à passer les mises à jour par une confirmation utilisateur explicite. Un patron émergé sous des noms comme MemGPT consiste à donner à l'agent des outils explicites de gestion de mémoire pour que le modèle lui-même décide ce qu'il sauvegarde, récupère et oublie. Le gain, c'est que le modèle sait souvent des choses sur quelles mémoires comptent qu'aucun extracteur à règles n'attraperait. Le coût, c'est que le modèle se trompe aussi, et qu'un store de mémoire conservé par le modèle a besoin de garde-fous contre une croissance emballée.

10.3 Survivre à la limite de contexte : compaction et notes structurées

Même avec mémoire épisodique et sémantique en place, la session courante de l'agent finit par toucher sa fenêtre. Le remède le plus commun est la compaction par résumé : quand le contexte approche soixante à quatre-vingts pour cent de la fenêtre, une étape en arrière-plan résume les tours plus anciens et les remplace. Les modes de défaillance sont la dérive de résumé (l'esprit général survit mais des faits spécifiques qui s'avèrent compter sont perdus) et le lissage récursif (chaque passe résume un résumé, et la perte cumulée est sévère). Les remèdes sont des prompts de résumé structurés qui préservent entités nommées, décisions et questions ouvertes, et résumer à partir des originaux quand c'est possible plutôt qu'à partir de résumés antérieurs.

L'effacement des résultats d'outils évacue le gros des retours d'outils après quelques tours intervenants, en les remplaçant par de brèves notes comme « table utilisateurs interrogée, 47 lignes retournées, utilisateur 12345 trouvé ». La prise de notes structurée oblige l'agent à maintenir un fichier de notes faisant autorité qui capture le but courant, les étapes terminées, les étapes restantes et les questions ouvertes — traité comme la source de vérité, pas comme une transcription. L'externalisation déplace les artefacts produits vers le système de fichiers ou la base, le contexte ne portant que des références. Le principe unificateur : la fenêtre de contexte est pour le travail actif, pas pour l'archivage. Les fenêtres plus grandes rendent le stockage externe plus important, pas moins, parce qu'elles permettent des sessions plus longues dans lesquelles l'architecture d'externalisation a plus de temps soit pour fonctionner, soit pour échouer.

À retenir : les agents à long horizon ne sont pas juste des agents à court horizon plus longs. Ce sont un problème d'ingénierie différent, avec des modes de défaillance différents — les patrons chercheur, ingénierie, opérations et agents en arrière-plan composent chacun les primitives différemment. Rendez l'état de mémoire inspectable sous forme lisible par l'humain, journalisez chaque lecture et écriture, et testez la reprise de session et la forte charge mémoire comme des cas routiniers, pas comme des cas limites.

Ce que prépare le Chapitre 10

Les Chapitres 9 et 10 ferment ensemble la Partie IV avec deux modèles mentaux complémentaires : le contexte comme budget fini à l'intérieur d'un seul appel, et la mémoire comme architecture pour un souvenir sélectif entre sessions. Ce dont aucun des deux chapitres n'a discuté, c'est la pression adversariale. Chaque écriture mémoire est un endroit qu'un attaquant peut empoisonner. Chaque appel d'outil est un endroit qu'un attaquant peut intercepter. Chaque mémoire récupérée est un endroit où un attaquant peut injecter des instructions que l'agent traitera comme ses propres pensées. Les architectures des deux derniers chapitres ont été conçues pour la justesse et l'efficacité, pas pour la survie sous attaque.


Prochaine étape — Chapitre 11 : Surfaces d'attaque et vulnérabilités du protocole. Confused Deputy, Token Passthrough, Session Hijacking, Capability Escalation, Unauthenticated Sampling, et la propagation implicite de confiance qui rend l'empoisonnement de contexte si dur à corriger.

Vous voulez le tableau complet ? Le livre parcourt les quatre patrons canoniques — chercheur, ingénierie, opérations, agents en arrière-plan — avec leurs modes de défaillance caractéristiques, la discipline de points de contrôle sur laquelle les agents de code de longue durée ont convergé, et l'architecture de suppression qui sépare un système de mémoire qui devient plus sage avec l'usage d'un système qui devient plus bruyant. LLM Primer IV sur Amazon →

SHO
SHO
CTO et Fondateur de RECEIPTROLLER. Axé sur les données, motivé par l'innovation, toujours curieux.