Agent memory strategies : short-term vs long-term, vector stores et patterns

Introduction

Un agent IA sans mémoire est un poisson rouge dans un bocal. Il tourne en boucle, réinvente la roue à chaque interaction, et ne retient rien de ce qui s'est passé il y a cinq minutes.

Si vous avez déjà utilisé un chatbot qui "oublie" tout dès que la conversation se réinitialise, vous avez touché du doigt le problème central de l'IA agentique.

La mémoire d'un agent transforme un modèle de langue brut — capable uniquement de prédire le prochain token — en un système capable de :

• Maintenir un objectif sur la durée
• S'adapter à un utilisateur spécifique
• Capitaliser sur des interactions passées

Ce guide couvre l'ensemble des stratégies : short-term memory, working memory, long-term memory (vector stores), et l'hybrid architecture qui combine les deux.

Résumé rapide

Stratégie	Stockage	Capacité	Latence	Use case
Short-term (context window)	RAM / GPU	4K–200K tokens	Immédiate	Session active
Working memory	RAM	Faible (features)	Très basse	Calcul intermédiaire
Long-term (vector store)	Disque / cloud	Illimitée	10–100 ms	Persistance cross-session
Hybrid (short + long)	Les deux	Maximale	Mixte	Agents autonomes

Qu'est-ce que la mémoire d'un agent IA ?

Un agent IA fonctionne avec plusieurs couches de mémoire, chacune répondant à un besoin différent.

Short-term memory (context window)

La short-term memory correspond à la context window du modèle sous-jacent — l'espace temporaire où transitent toutes les informations de la session active. C'est là que le modèle "voit" l'historique de la conversation, les documents chargés, et les résultats d'outils intermédiaires.

Dès que la fenêtre se remplit ou que la session se ferme, ces informations disparaissent.

Working memory

La working memory désigne les structures actives que l'agent manipule pendant son raisonnement : faits en cours, sous-buts partiels, résultats d'étapes précédentes. Là où la context window est un espace passif (le modèle y lit), la working memory est un espace de manipulation actif.

Certains frameworks implémentent cela comme un espace mémoire séparé.

Long-term memory (vector stores)

La long-term memory résout le problème de persistance au-delà des sessions. Elle stocke les informations grâce à des vector embeddings — des représentations numériques compressées de texte, consultables par recherche sémantique.

Un agent peut ainsi "se souvenir" d'une interaction vieille de trois mois et retrouver le contexte pertinent en temps réel.

L'enjeu en 2026 : ne pas choisir l'une de ces approches, mais les faire travailler ensemble dans une hybrid memory architecture cohérente.

Short-term memory : gérer la context window

Comment fonctionne une context window

La context window stocke tout ce qui est passé en entrée du modèle : prompt système, historique de conversation, documents, résultats d'appels API.

Sa taille varie selon le modèle :

Modèle	Context window	Limite pratique
GPT-4o	128K tokens	~100K tokens utiles
Claude 3.7 Sonnet	200K tokens	~180K tokens utiles
Gemini 2.0 Flash	1M tokens	Variable selon cache
Llama 3 70B	8K–128K (config)	Dépend du déploiement

Rappel : un token ≈ 0,75 mots en français. Une conversation de 5 000 mots consomme ~6 700 tokens de contexte.

Trois techniques de gestion du contexte

1. Summarization

Condense périodiquement l'historique en version compressée. L'agent détecte quand le contexte atteint ~70 % de sa capacité et substitue un résumé à l'historique brut.

# Pattern summarization basique
def summarize_if_needed(messages, model):
    total_tokens = estimate_tokens(messages)
    if total_tokens > CONTEXT_LIMIT * 0.7:
        summary = model.invoke(
            "Résume cette conversation en 200 mots maximum : "
            + str(messages[-10:])
        )
        return [messages[0], {"role": "system", "content": f"Résumé : {summary}"}] + messages[-3:]
    return messages

2. Windowing

Découpe la conversation en segments chevauchants. Ne conserve que les N derniers échanges + un résumé des plus anciens. Plus précis que la summarization pure, mais plus complexe.

3. Message pruning

Supprime activement les turns les moins pertinents — bruit, confirmations, salutations — pour préserver les informations à forte valeur.

Bon à savoir

• Les prompts système consomment de la place. Un prompt de 3 000 tokens réduit d'autant l'espace disponible pour la conversation.
• Les résultats d'outils sont souvent verbeux (JSON de 2 000 tokens pour une simple recherche). Passez-les toujours dans un step de "compression" avant réinjection.
• Les embeddings de documents ne restent pas dans la fenêtre : ils sont calculés une fois et stockés dans le vector store.

Long-term memory : vector stores et persistance

Pourquoi la context window ne suffit pas

Un agent de veille qui vous accompagne depuis six mois ne peut pas stocker six mois d'interactions dans une context window. Même un modèle avec 1M de tokens atteint ses limites si l'historique croît indéfiniment.

La long-term memory pour agents IA répond à ce problème en externalisant le stockage dans une base de données dédiée, interrogable par recherche sémantique.

Comment fonctionne un vector store

1. Embedding : chaque fragment de mémoire est transformé en vecteur numérique (384 à 3072 floats selon le modèle).
2. Indexation : les vecteurs sont indexés dans une base spécialisée (Pinecone, Chroma, Qdrant, Weaviate…).
3. Retrieval : l'agent calcule un embedding de la query actuelle, interroge le store, et récupère les chunks les plus similaires.
4. Injection : les chunks récupérés sont injectés dans la context window comme contexte complémentaire.

# Pattern retrieval memory basique
def retrieve_relevant_memories(query, vector_store, top_k=5):
    query_embedding = embedding_model.encode(query)
    results = vector_store.query(
        vector=query_embedding,
        n_results=top_k,
        filter={"session_id": current_session}
    )
    return [doc['text'] for doc in results['documents']]

# Usage dans un agent loop
context = retrieve_relevant_memories(user_message, vector_store)
full_prompt = system_prompt + context + user_message
response = llm.invoke(full_prompt)

Choisir un vector store en 2026

Solution	Type	Prix	Quand l'utiliser
Pinecone	Cloud géré	Payant	Production, scaling automate
Chroma	Local / self-hosted	Gratuit	Expérimentation, petits volumes
Qdrant	Cloud / self-hosted	Freemium	Bon équilibre, performant
Weaviate	Cloud / self-hosted	Freemium	Multimodal (texte + images)
pgvector	PostgreSQL	Gratuit (infra)	Stack déjà PostgreSQL

Pour un agent personnel sur VPS : Chroma (local) ou Qdrant (Docker). Pour production à fort volume : Pinecone ou Qdrant cloud.

Stratégie d'indexation

La qualité du retrieval dépend directement de la qualité de l'indexation. Deux écueils majeurs :

• Chunking trop grossier : un document de 10 000 mots indexé en un seul chunk donne un embedding moyen qui ne capture rien.
• Chunking trop fin : des chunks de 50 mots éclatent la sémantique et génèrent du bruit au retrieval.

En pratique : chunk size de 500 mots, overlap de 50 mots, métadonnées riches (date, source, type d'interaction) pour permettre un filtrage fin.

Hybrid memory architecture : combiner short et long-term

Le principe

L'architecture idéale combine les deux approches : la short-term memory gère ce qui se passe maintenant, la long-term memory stocke ce qui s'est passé avant.

L'agent décide dynamiquement quand store, quand retrieve, et comment fusionner les deux flux.

┌─────────────────────────────────────────────┐
│              AGENT (orchestrateur)           │
│                                              │
│  1. Réception user message                   │
│  2. Retrieval → long-term memory             │
│  3. Fusion avec short-term (session)         │
│  4. Raisonnement / tool calling              │
│  5. Résultats → long-term (si pertinent)    │
│  6. Update short-term                       │
└─────────────────────────────────────────────┘
         │                      │
         ▼                      ▼
  ┌──────────────┐     ┌──────────────────┐
  │ Context window│     │  Vector store     │
  │ (short-term)  │     │  (long-term)      │
  │ ~128K tokens  │     │  Illimité         │
  └──────────────┘     └──────────────────┘

Le retrieval deciding problem

La question la plus complexe n'est pas technique mais décisionnelle : quand l'agent doit-il主动 aller chercher dans sa long-term memory ?

Trois stratégies :

1. RAG classique : retrieval à chaque tour sur une query reconstruite. Simple, prévisible, mais génère des appels inutiles.

2. Retrieval conditionnel : l'agent évalue lui-même (via un prompt ou une heuristique) si le message actuel nécessite un retrieval. Plus intelligent, mais l'agent peut se tromper.

3. Memory indexing proactif : indexer systématiquement chaque interaction après completion, retrieve uniquement sur demande explicite ou mismatch detection.

Pour la plupart des agents : le pattern 2 avec guardrails offre le meilleur rapport simplicité / efficacité.

Stockage sélectif

Stocker chaque échange est un gaspillage. Filtrez :

• Store : décisions importantes, préférences utilisateur, faits vérifiés, erreurs corrigées
• Ne storez pas : confirmations triviales, salutations, erreurs déjà rectifiées, bruit

Heuristique : si l'information pourrait être utile dans une session future, stockez-la. Si elle n'a de valeur que dans le moment présent, laissez-la en short-term.

La mémoire dans les frameworks

OpenClaw — skills et vector memory

OpenClaw implémente la mémoire à travers son système de skills et de vector memory intégré. Les skills sont des unités de compétence réutilisables qui stockent leur état. Le vector store est accessible nativement via des skills dédiés.

L'approche est orientée configuration plutôt que code : la mémoire se configure via des skills dans SKILL.md, et l'agent y accède comme à n'importe quel autre outil.

CrewAI — memory tier system

CrewAI implémente un système de mémoire à trois niveaux :

• Contextual Memory : conserve le fil conducteur d'une mission multi-agent
• Agent Memory : mémoire propre à chaque agent (expériences, préférences)
• Collaborative Memory : mémoire partagée entre agents d'une même crew

CrewAI est particulièrement adapté aux workflows multi-agents où plusieurs agents doivent partager un contexte commun tout en ayant leur propre mémoire individuelle.

LangChain — flexibilité maximale, complexité proportionnelle

LangChain propose le système le plus flexible. ConversationalMemory, BufferMemory, VectorStore-backed Memory, SummaryMemory — chaque type de mémoire a son abstraction.

C'est l'outil le plus puissant pour un engineer qui sait exactement ce qu'il veut construire. La courbe d'apprentissage est rebutante pour un usage rapide.

Comparatif

Critère	OpenClaw	CrewAI	LangChain
Facilité de setup	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐
Flexibilité	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Multi-agent memory	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
Vector store intégré	Oui (skill)	Partiel	Oui
Courbe d'apprentissage	Faible	Moyenne	Élevée

Exemple concret : agent de veille IA avec hybrid memory

Contexte : un agent de veille qui, chaque matin, envoie un résumé des actualités IA pertinentes en tenant compte de vos centres d'intérêt évolutifs.

Étape 1 — Setup initial

from openclaw import Agent
from openclaw.skills import VectorMemory, WebSearch

agent = Agent(
    name="VeilleIA",
    skills=[VectorMemory(), WebSearch()],
    system_prompt="Tu es un agent de veille IA. Chaque matin, tu cherches les actualités"
                   "les plus pertinentes selon les préférences de l'utilisateur stockées"
                   "en mémoire vectorielle, puis tu génères un résumé structuré."
)

Étape 2 — Indexation initiale des préférences

Au premier lancement, l'utilisateur définit ses centres d'intérêt, indexés dans le vector store avec le tag user_preferences.

preferences = "L'utilisateur s'intéresse aux agents IA open-source, aux vector stores,
               à l'automatisation business et aux outils de productivité."
memory.store(preferences, metadata={"type": "user_preferences", "priority": "high"})

Étape 3 — Boucle quotidienne

# Retrieval : préférences et derniers contextes
prefs = memory.retrieve("préférences utilisateur veille", top_k=3)
recent = memory.retrieve("résultats veille précédents", top_k=5)

# Recherche avec contexte enrichi
query = f"Actualités IA {prefs} — exclure sujets déjà couverts : {recent}"
results = websearch.search(query, count=10)

# Résumé et stockage pour la prochaine itération
summary = agent.invoke(f"Résume ces actualités de façon actionnable : {results}")
memory.store(f"Veille du {today} : {summary[:200]}",
             metadata={"type": "veille_summary", "date": today})

Résultat : après une semaine, l'agent "sait" que vous avez déjà lu tel article, évite les doublons, affine ses recherches selon ce qui vous a semblé pertinent.

Bonnes pratiques

Erreur n°1 : surcharger la context window. Plus de contexte ne signifie pas une meilleure réponse. Chaque information non pertinente dilue le signal. Filtrez avant d'injecter.

Erreur n°2 : tout stocker dans le vector store. Un agent qui indexe chaque message génère une base bruitée. Retrieval lent et imprécis. Stockez sélectivement.

Erreur n°3 : ignorer la latence de retrieval. Un vector store sur un serveur distant ajoute 50–200 ms par appel. Dans une agent loop avec 3–5 tours, ça multiplie le temps de réponse. Gardez le vector store proche de l'agent (même datacenter, ou local).

Erreur n°4 : ne pas versionner les souvenirs. Les préférences utilisateur évoluent. Un vector store qui ne supporte pas la mise à jour de chunks devient obsolète. Privilégiez les stores qui supportent l'upsert (Qdrant, Pinecone, Weaviate).

Optimisation : implémentez un relevance filter avant d'injecter les chunks récupérés. Un chunk peut être similaire à la query sans être pertinent pour la tâche actuelle. Filtrez sur les métadonnées (type, date, score de similarité).

Questions fréquentes

Quelle différence entre short-term memory et working memory ?

La short-term memory correspond à la context window du modèle — un espace passif de taille fixe où transitent les informations de la session en cours.

La working memory désigne les structures actives que l'agent manipule pendant son raisonnement : faits en cours de traitement, sous-buts partiels, résultats intermédiaires.

En pratique, la working memory est souvent implémentée comme une sous-partie de la short-term, mais le concept est utile pour distinguer "en transit" de "stocké temporairement".

Comment choisir entre Chroma, Qdrant et Pinecone ?

• Prototype / agent personnel : Chroma (local, zéro coût, suffisant jusqu'à ~100K documents)
• Production scaling modéré : Qdrant (performant, bon free tier, facile à déployer en Docker)
• Production enterprise haute disponibilité : Pinecone (managé, solide, payant)

La différence se joue sur la latence de retrieval et la facilité d'upsert — Qdrant et Pinecone sont en avance sur ces deux critères.

Comment savoir si ma hybrid memory fonctionne ?

Trois métriques à surveiller :

• Memory recall rate : l'agent retrouve-t-il l'information quand il en a besoin ?
• Context utilization : quelle fraction de la fenêtre de contexte est utilisée efficacement ?
• Retrieval latency : combien de temps prend chaque query au vector store ?

Testez régulièrement avec un ensemble de questions annotées dont vous connaissez la réponse stockée en long-term memory.

Peut-on utiliser un agent sans long-term memory ?

Oui, pour des sessions isolées et des tâches bornées. Un agent qui répond à une question unique, lance un script, ou effectue une tâche en moins de 5 minutes n'a pas besoin de persistance.

La long-term memory devient nécessaire dès que l'agent doit maintenir un état au-delà d'une session ou accumuler de l'expérience utilisateur. Pour un agent de productivité quotidienne, c'est quasi systématique.

Quelle stack pour un développeur solo ?

OpenClaw avec son skill vector memory intégré. Setup fonctionnel en quelques minutes, sans infrastructure séparée. Montez en puissance vers Qdrant ou Chroma uniquement quand le besoin dépasse ce que le skill natif offre.

---

Vous voulez aller plus loin ? Consultez le guide sur l'architecture d'un agent IA pour comprendre où la mémoire s'intègre dans le cycle de vie complet d'un agent. Pour le stockage à grande échelle, voir le guide des vector stores pour agents IA.

Cet article fait partie du cluster Tutoriels de FrameworksAgents.com — votre ressource francophone pour maîtriser les agents IA et leurs implémentations concrètes.