Accueil › Glossaire › Short-Term Memory

Short-Term Memory (Mémoire à Court Terme)

La short-term memory (STM) d’un agent IA est la mémoire de travail qui contient les informations du contexte immédiat : l’historique de la conversation en cours, les résultats des outils récemment appelés, les raisonnements intermédiaires et l’état de progression de la tâche. Elle correspond directement à la fenêtre de contexte du LLM.

C’est la forme de mémoire la plus fondamentale et la plus universelle. Chaque chatbot, chaque agent, chaque application LLM utilise une short-term memory : l’historique des messages que vous voyez dans votre conversation. Quand vous dites « comme je l’ai mentionné plus tôt », c’est la STM qui permet au modèle de comprendre votre référence.

Mais la STM est aussi la mémoire la plus fragile. Elle est volatile (effacée à la fin de la session), limitée en taille (par la fenêtre de contexte du LLM), et sujette au « context drift » (le modèle perd progressivement le fil des instructions initiales quand la conversation s’allonge). Comprendre et gérer correctement la STM est une compétence essentielle pour tout développeur d’agents IA.

Comment fonctionne la STM

Les LLM sont fondamentalement stateless : chaque appel API est indépendant, sans aucune mémoire des appels précédents. L’illusion de mémoire dans les chatbots est créée par l’application, qui renvoie l’historique complet de la conversation à chaque nouveau message.

Concrètement, quand vous envoyez un message dans ChatGPT ou Claude, votre application envoie au LLM l’ensemble des messages précédents + votre nouveau message. Le modèle reçoit tout le contexte à chaque tour, « se souvient » de la conversation uniquement parce qu’on la lui rappelle intégralement. C’est pourquoi la mémoire à court terme est parfois appelée « in-context memory » : elle vit dans le contexte du prompt.

Les composants de la STM

La STM d’un agent contient plusieurs types d’informations :

L’historique des messages : la séquence de messages utilisateur et assistant de la conversation en cours. C’est la forme la plus basique de STM.

Le system prompt : les instructions initiales qui définissent le comportement de l’agent (rôle, ton, règles, outils disponibles). Ce system prompt consomme des tokens de contexte et reste en mémoire tout au long de la conversation.

Les résultats d’outils : dans un agent ReAct ou Think-Act-Observe, les observations (résultats de recherche, sortie de code, réponses d’API) s’accumulent dans le contexte.

Le scratchpad de raisonnement : les traces de pensée (Thoughts) de l’agent, les plans intermédiaires et les notes de progression. C’est la « mémoire de travail » au sens strict, où l’agent « réfléchit à voix haute ».

L’état custom : dans LangGraph, vous pouvez étendre l’état de l’agent avec des champs supplémentaires (user_id, préférences, variables de session) qui persistent au sein du thread.

Le défi : la fenêtre de contexte déborde

Le problème central de la STM est la finitude. Même avec 1M tokens (Claude Opus 4.6), une conversation suffisamment longue finira par dépasser la fenêtre. Et bien avant d’atteindre la limite technique, les performances se dégradent : les LLM peinent à exploiter efficacement les informations situées au milieu d’un long contexte (le problème « lost in the middle »).

Pour un agent qui effectue une boucle Think-Act-Observe avec 15 itérations, chacune ajoutant 500 à 2 000 tokens (pensée + action + observation), le contexte peut grossir de 7 500 à 30 000 tokens sur une seule tâche. Ajoutez le system prompt (~1 000 tokens), les définitions d’outils (~2 000 tokens) et l’historique de conversation, et le budget de contexte se consomme rapidement.

Les stratégies de gestion de la STM sont donc essentielles pour tout agent de production.

Stratégies de gestion de la STM

Troncation (Window Buffer)

La méthode la plus simple : conserver uniquement les N derniers messages et supprimer les plus anciens. C’est l’approche « fenêtre glissante ». Rapide à implémenter, mais brutale : les informations anciennes (y compris le contexte important de début de conversation) sont perdues définitivement.

LangChain implémente cette stratégie via le paramètre de troncation configurable : suppression des premiers messages, des derniers messages, ou d’un nombre spécifique de messages.

Résumé (Summarization)

Une stratégie plus sophistiquée : utiliser un LLM pour résumer les messages anciens en un texte compact qui capture les informations essentielles. Ce résumé remplace les messages originaux dans le contexte, libérant de l’espace tout en conservant le sens.

LangChain propose ConversationSummaryBufferMemory : un hybrid qui garde les messages récents en intégralité et résume progressivement les messages plus anciens quand le budget de tokens est dépassé. C’est le meilleur compromis entre fidélité (messages récents) et compression (messages anciens).

Compaction (Claude)

Claude Opus 4.6 intègre un mécanisme de compaction automatique : quand le contexte approche de la limite, le système résume automatiquement les parties anciennes de la conversation. Cette compaction est transparente pour l’utilisateur et préserve les informations essentielles tout en libérant du contexte pour les interactions suivantes.

Externalisation dans des fichiers

L’approche de Claude Code et LangChain Deep Agents : plutôt que garder tous les résultats intermédiaires dans le contexte, l’agent les écrit dans des fichiers et les relit sélectivement quand il en a besoin. C’est le principe de « Dynamic Context Discovery » : la STM du LLM ne contient que ce qui est immédiatement nécessaire, le reste est stocké en fichiers accessibles à la demande.

C’est analogue au swap mémoire dans un système d’exploitation : les données peu utilisées sont déplacées sur disque pour libérer la RAM. Letta (ex-MemGPT) formalise cette analogie : le contexte du LLM est la « RAM », le stockage externe est le « disque », et l’agent pagine les informations entre les deux.

Filtrage intelligent

Les approches les plus avancées (AgeMem, janvier 2026) utilisent le LLM lui-même pour décider quelles informations garder en STM et lesquelles archiver en mémoire à long terme. L’opération FILTER sélectionne les messages pertinents pour la tâche en cours, l’opération SUMMARY compresse les messages non filtrés. Le tout est entraîné par reinforcement learning pour optimiser la gestion du contexte.

STM vs LTM : deux mémoires complémentaires

En production, les deux mémoires interagissent : la LTM récupère des informations pertinentes et les injecte dans la STM du contexte courant. La STM accumule des expériences qui sont périodiquement consolidées en LTM. C’est le même flux que chez l’humain : la mémoire de travail traite l’information immédiate, et les éléments importants sont transférés en mémoire à long terme pendant le « repos » (entre les sessions).

Implémentation pratique

Avec LangChain / LangGraph

LangGraph gère la STM via des checkpointers qui persistent l’état du thread. Chaque thread représente une conversation, et l’état (incluant l’historique des messages) est sauvegardé après chaque étape. MongoDB, PostgreSQL et le stockage en mémoire sont supportés comme backends de checkpointing.

Pour gérer la croissance du contexte, LangGraph offre des stratégies de troncation configurables et des résumeurs intégrés. L’état peut être étendu avec des champs custom (user_id, variables de session) qui persistent tout au long du thread.

Avec LlamaIndex

LlamaIndex propose un composant Memory modulaire avec un chat message store (STM basique), un StaticMemoryBlock pour les informations de contexte fixes, un FactExtractionMemoryBlock qui extrait automatiquement des faits des conversations, et un VectorMemoryBlock qui archive les messages anciens dans un vector store quand la STM atteint sa limite de tokens.

Avec OpenAI Agents SDK

Le OpenAI Agents SDK introduit le concept de « sessions » pour le context engineering. Les sessions gèrent automatiquement la STM avec des stratégies de compression configurables. Le résumeur utilise un LLM dédié pour compresser les messages anciens, avec des garde-fous contre les hallucinations dans les résumés et un tracking des jalons importants de la conversation.

Défis de la STM

Context drift

Le context drift est la dégradation progressive de l’adhérence de l’agent à ses instructions initiales. Plus la conversation s’allonge, plus les instructions du system prompt sont « noyées » dans l’historique des messages. L’agent peut commencer à dévier de son rôle, oublier des contraintes, ou ignorer des consignes.

Les contre-mesures : rappeler périodiquement les instructions clés dans la conversation, utiliser la summarization pour compresser l’historique tout en gardant le system prompt intact, et monitorer la conformité des réponses aux instructions initiales.

Lost in the middle

Les recherches montrent que les LLM exploitent mieux les informations au début et à la fin du contexte qu’au milieu. Dans une conversation de 50 messages, les informations mentionnées au message 15 sont plus susceptibles d’être ignorées que celles des messages 1-5 ou 45-50. La summarization atténue ce problème en condensant les messages intermédiaires.

Coût croissant

Chaque message ajouté au contexte augmente le nombre de tokens d’input facturés. Une conversation de 20 tours avec un historique complet consomme progressivement plus de tokens : le message 20 inclut les 19 messages précédents en contexte. La troncation et la summarization ne sont pas juste des optimisations techniques : elles sont des optimisations financières essentielles.

STM dans les systèmes multi-agents

Dans un système multi-agent, la STM pose un défi supplémentaire : comment partager le contexte entre agents ? Une shared memory (mémoire partagée) peut être utilisée pour la coordination. MongoDB propose une intégration de shared memory pour les systèmes multi-agents dans LangGraph, où les agents accèdent à un espace de contexte commun.

Bonnes pratiques

Mesurez votre consommation de contexte. Utilisez tiktoken (OpenAI) ou l’API de comptage de tokens de votre fournisseur pour monitorer combien de tokens votre STM consomme à chaque tour. Identifiez les sources de bloat : les résultats d’outils verbeux, les traces de raisonnement longues, ou les messages système redondants.

Adoptez la summarization hybride. Le pattern le plus efficace : gardez les 5 à 10 derniers messages en intégralité (messages récents = haute fidélité) et résumez tout ce qui précède en un paragraphe compact. C’est le fonctionnement de ConversationSummaryBufferMemory dans LangChain.

Externalisez les résultats d’outils volumineux. Un résultat de recherche web de 5 000 tokens n’a pas besoin de rester intégralement dans le contexte. Extrayez les informations pertinentes (quelques phrases) et archivez le reste dans un fichier ou une base vectorielle accessible si nécessaire.

Protégez le system prompt. Le system prompt est l’ancre de la STM : c’est lui qui définit le comportement de l’agent. Ne le laissez jamais être « poussé hors du contexte » par un historique trop long. Certains frameworks le placent en position protégée (toujours en tête du contexte, jamais tronqué).

Testez la dégradation. Simulez des conversations de 30, 50, 100 tours et mesurez si l’agent maintient ses instructions et sa qualité de réponse. La dégradation est souvent graduelle et ne se révèle qu’en test de stress.