Conception d'un système de mémoire Agent : de la session à la mémoire à long terme

Vous avez passé la journée à discuter avec un Agent IA : architecture, choix techniques, évaluation des risques. Le lendemain, vous rouvrez la même conversation — il demande : « Sur quel sujet souhaitez-vous échanger ? »

Tout ce qui s’est dit hier — préférences, conclusions, suivi d’avancement — a disparu. Ce n’est pas un problème de capacité de l’Agent, mais d’architecture : le LLM est sans état par défaut ; chaque requête repart de zéro, sauf si vous construisez un système de mémoire. Beaucoup d’équipes le découvrent après la mise en ligne : « pourquoi me redemander ça », « on avait convenu hier » — puis elles rattrapent en urgence.

Cet article propose un plan complet pour concevoir un système de mémoire Agent : comment choisir les quatre types, monter le pipeline en cinq étapes, choisir un framework et maîtriser les coûts.

Chapitre 1 : pourquoi un Agent a besoin d’un système de mémoire

Les LLM ont une « mémoire de poisson rouge » par nature. Vous envoyez une requête, vous recevez une réponse — terminé. La requête suivante repart sur une page blanche. Ce n’est pas un défaut : c’est voulu — chaque inférence est indépendante pour garder des sorties prévisibles.

En contexte Agent, c’est un désastre.

Imaginez un Agent support : l’utilisateur dit « je veux changer l’adresse ». L’Agent répond « donnez la nouvelle adresse ». L’utilisateur : « celle de l’entrepôt, comme la dernière fois ». L’Agent est perdu : quelle dernière fois ? quel entrepôt ?

Pire encore, la « pourriture du contexte » (Context Rot) : vous empilez l’historique, le contexte s’allonge, le bruit augmente. Pour une question simple, l’Agent fouille des dizaines de tours. D’après le blog officiel Redis, le contexte plein peut pousser la latence p95 à 17,12 s et multiplier les tokens par 14.

L’écart de coût est frappant. J’ai vu une comparaison : ~1 M$/mois en contexte plein, ~100 k$/mois en mémoire sélective — un facteur 10.

Le dilemme : vous voulez que l’Agent se souvienne de tout, sans tout injecter dans la fenêtre de contexte. La réponse : un système de mémoire dédié.

Il couvre trois besoins :

Continuité inter-sessions : si l’utilisateur préfère les réponses en français aujourd’hui, l’Agent doit s’en souvenir demain, la semaine prochaine, le mois prochain.

Expérience personnalisée : habitudes, contexte métier et historique diffèrent par utilisateur ; la mémoire permet à l’Agent de « reconnaître » chacun.

Reprise après crash : si l’exécution s’interrompt, un redémarrage peut reprendre là où ça s’est arrêté, sans tout refaire.

Chapitre 2 : quatre types de mémoire — de la cognition à l’architecture

La mémoire n’est pas un seul stockage : elle a des niveaux et des rôles. Les sciences cognitives distinguent mémoire de travail, épisodique, sémantique et à long terme — l’architecture Agent peut s’en inspirer.

Mémoire de travail (Working Memory)

C’est « l’esprit » de la session en cours : ce que l’utilisateur vient de dire, l’avancement de la tâche, les résultats intermédiaires de raisonnement.

Stockage : la fenêtre de contexte. Durée de vie courte : fin de conversation, effacement ; la suivante repart de zéro.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

En pratique : Redis ou KV Store + Checkpointer pour des snapshots d’état. Le MemorySaver de LangGraph en est un exemple typique — après chaque nœud, snapshot en mémoire ou en base.

Mémoire épisodique (Episodic Memory)

Enregistre « ce qui s’est passé » : questions posées, réponses, décisions — un journal chronologique.

Contrairement au travail, elle persiste entre sessions : demain, on peut encore lire les événements d’hier.

Stockage : flux d’événements (Redis Streams) ou base temporelle. Optimisation clé : compression par résumé — l’événement brut est long ; un LLM produit une version courte, moins coûteuse à stocker et à récupérer.

Mémoire sémantique (Semantic Memory)

C’est le « savoir » : faits abstraits — « l’utilisateur préfère le français », « le siège est à Shanghai », « le produit A coûte 500 ».

Peu importe quand ni dans quelle conversation on l’a appris.

Stockage : base vectorielle (Pinecone, Weaviate, Milvus) + graphe de connaissances. Vecteurs indexés en HNSW ou IVF ; le graphe porte les relations (« utilisateur A préfère B », « société C est à D »).

Mémoire à long terme (Long-Term Memory)

C’est « qui est l’utilisateur » : profil, préférences, connaissances stables sur la durée — valables pour toutes les sessions.

Stockage : PostgreSQL, MongoDB ou offres cloud dédiées (AnalyticDB, PolarDB, etc.). Récupération : recherche sémantique + RAG, souvent avec filtre d’attributs (par ex. user_id).

Les quatre niveaux forment une pyramide : travail en bas, rapide mais éphémère ; long terme en haut, durable mais plus lent à interroger. L’Agent puise selon la tâche.

Chapitre 3 : pipeline en cinq étapes — de l’extraction à l’oubli

Stocker la conversation ne suffit pas. Il faut extraction, consolidation, stockage, récupération, oubli — chaque étape compte.

Étape 1 : extraction (Extraction)

Tout message ne mérite pas d’être mémorisé. « Bonjour », « merci », « un instant » — du bruit.

Objectif : repérer ce qui vaut la peine. Approche courante : classification LLM + filtres par règles. Le LLM juge la valeur long terme (« préfère le français » vs « a dit bonjour ») ; les règles écartent les motifs évidents (trop court, salutations seules).

# Pseudo-code — phase d'extraction
def extract_memories(conversation):
    candidates = []
    for message in conversation:
        # Classification LLM : vaut-il la peine d'être mémorisé ?
        classification = llm.classify(message, "memory_candidate")
        if classification == "worth_remembering":
            candidates.append(message)
    # Filtrage par règles : éliminer le bruit évident
    candidates = filter_noise(candidates)
    return candidates

Étape 2 : consolidation (Consolidation)

Les extraits peuvent se chevaucher. « L’utilisateur aime le français » peut apparaître trois fois — inutile de tripler.

Tâches : fusionner les doublons, mettre à jour l’ancien, former des triplets de graphe.

Exemple :

• Ancien : « préfère les réponses en français »
• Nouveau : « préfère un français concis »
• Fusionné : « préfère un français concis » (affiné)

# Pseudo-code — phase de consolidation
def consolidate_memories(new_memories, existing_memories):
    for new in new_memories:
        # Vérifier doublon ou similarité avec la mémoire existante
        similar = find_similar(new, existing_memories)
        if similar:
            # Fusionner ou mettre à jour
            merged = llm.merge(new, similar)
            update_memory(similar.id, merged)
        else:
            # Ajouter une nouvelle entrée
            add_memory(new)

Étape 3 : stockage (Storage)

Deux choix structurants : format et index.

Format selon le type : KV pour le travail, flux pour l’épisodique, vecteurs pour le sémantique, relationnel pour le long terme.

Index et performance : HNSW et IVF dominent.

• HNSW : jeux moyens (100 k–quelques millions), meilleur recall à latence égale, mais forte empreinte mémoire.
• IVF : très grands volumes (millions–milliards), mémoire plus efficace, précision un peu moindre.

D’après Redis, HNSW vise le recall ; IVF scale mieux en mémoire. Le choix dépend du volume et de l’exigence de précision.

Étape 4 : récupération (Retrieval)

Quand l’Agent a besoin de souvenirs, cette étape les remonte.

La seule recherche vectorielle peut manquer de précision. Mieux : récupération hybride — vecteurs + plein texte + filtres d’attributs.

Exemple : « quelle était l’adresse d’entrepôt évoquée la dernière fois ? »

1. Vecteurs : souvenirs proches sémantiquement (« adresse entrepôt », « logistique »)
2. Filtre : uniquement cet user_id
3. Tri temporel : les plus récents d’abord

# Pseudo-code — récupération hybride
def retrieve_memories(query, user_id):
    # Recherche vectorielle
    vector_results = vector_db.search(query, top_k=20)
    # Filtre d'attributs : utilisateur courant uniquement
    filtered = [m for m in vector_results if m.user_id == user_id]
    # Tri temporel : les plus récents en premier
    sorted_results = sort_by_time(filtered, descending=True)
    return sorted_results[:5]

Étape 5 : oubli (Forgetting)

L’oubli n’est pas négatif ici : sans lui, le stockage gonfle et le bruit noie l’utile.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Deux familles de stratégies :

Décroissance temporelle : l’importance baisse avec le temps ; une préférence d’il y a un mois peut être obsolète.

Éviction par importance : fréquence d’accès, retour utilisateur, nombre de validations — les entrées faibles sont purgées périodiquement.

Piège : figer une erreur ponctuelle. L’utilisateur dit une fausse info, l’Agent la grave comme fait. Mitigation : validation à la consolidation, ou marquage « en attente de confirmation » pour faible confiance.

Chapitre 4 : frameworks — Mem0 vs Zep vs LangMem vs LangChain

Des frameworks matures existent — inutile de tout réinventer. La question : lequel choisir ?

Arbre de décision

Avant de choisir, trois questions :

Q1 : Faut-il un graphe de connaissances ?
    → Oui → Mem0 Pro ou Zep (capacités matures)
    → Non → Q2

Q2 : Service managé acceptable ?
    → Oui → Mem0 (simple) ou MemoClaw (sans clé API)
    → Non → Q3

Q3 : Vous utilisez LangGraph ?
    → Oui → LangMem (intégration native)
    → Non → Implémentation maison (Checkpointer LangChain + base vectorielle)

Recommandations par scénario

Support client intelligent → Mem0

Préférences, commandes passées, réclamations — le graphe modélise bien « A a acheté B », « A a signalé C ». La version managée réduit l’ops ; la Pro ajoute le graphe.

Agent diagnostic médical → Zep

Symptômes, médicaments, examens dans le temps : Zep excelle sur les faits temporels (Temporal Facts), adaptés au raisonnement sur l’historique.

Agent outil interne → LangMem

Déjà sur LangGraph : LangMem s’intègre nativement, Checkpointer et stockage mémoire unifiés.

Prototype rapide → MemoClaw

Tester sans compte ni clé API : store / recall suffisent. Pour la production, un framework plus complet est souvent nécessaire.

Écosystème d’intégration Mem0

D’après le blog Mem0 début 2026, 21 frameworks/plateformes sont couverts — OpenAI, LangChain, LlamaIndex, CrewAI, AutoGen, etc. Sur une stack courante, un connecteur existe probablement déjà.

Chapitre 5 : production — coûts, performance, sécurité

Une démo qui tourne ≠ la production. Avant mise en ligne : latence, coût, sécurité.

Index : précision vs échelle

Goulot d’étranglement : l’index vectoriel.

FLAT : recherche exhaustive, précision maximale, lent — petits jeux (≤ dizaines de milliers) ou exigence de recall total.

HNSW : graphe hiérarchique, recall et vitesse élevés — 100 k à quelques millions ; mémoire lourde (ordre de quelques Go par million de vecteurs).

IVF : index inversé par buckets — millions à milliards, mémoire frugale, recall un peu plus bas (vecteurs hors bucket cible).

Règle simple : petit volume → FLAT ou HNSW ; grand volume → IVF. Haute exigence (santé) → HNSW même au prix de la vitesse.

Latence : des secondes aux millisecondes

Chaque étape s’additionne : récupération, raisonnement, génération. Le contexte plein gonfle l’entrée avant inférence — p95 jusqu’à ~17 s.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Piste : récupération avant inférence, et rapide. Redis unifie vecteurs, flux et KV — moins de latence réseau inter-services.

Autre piège : double appel LLM (récupérer → résumer les résultats → répondre). Mieux : injecter les souvenirs directement dans le contexte, un seul passage LLM.

Coûts : le secret du facteur 10

Trois leviers :

Mémoire sélective : ne pas tout historiser ; filtrer à l’extraction, borner le volume stocké.

Compression par résumé : milliers de tokens bruts → centaines en résumé ; LLM qui condense l’épisodique régulièrement.

Oubli intelligent : purge des entrées peu importantes ; décroissance + fréquence d’accès.

Selon Mem0, le passage contexte plein → sélectif peut ramener ~1 M$/mois à ~100 k$/mois — surtout tokens et stockage.

Sécurité et confidentialité : isolation

Données utilisateur : la conception doit être stricte.

Isolation : stockage et requêtes filtrés par user_id — jamais les souvenirs de B dans la session de A.

Défense empoisonnement : entrées malveillantes pour graver de faux faits — validation à la consolidation, « en attente de confirmation » avant écriture long terme.

Anonymisation : téléphone, pièce d’identité, etc. masqués avant persistance ; restauration soumise aux droits.

Cohérence : verrou distribué + réflexion

Multi-instances : A met à jour un souvenir, B peut lire l’ancienne version.

Verrou + version : verrou à l’écriture, nouvelle version publiée ; lecture = dernière version.

Réflexion périodique : LLM parcourt la mémoire, corrige contradictions et obsolescence — comme dans certaines offres AnalyticDB.

Conclusion

Un système de mémoire n’est pas un « bonus » : c’est ce qui distingue un Agent d’une simple API LLM. Sans mémoire, chaque conversation est une première rencontre — pas de compréhension durable ni de cohérence sur des tâches longues.

Ce n’est pas plug-and-play pour autant. Graphe de connaissances ? Service managé ? Stack existante ? Une fois clarifié, le choix de framework suit.

En cas de doute, commencez par LangMem ou Mem0 open source — investissement minimal, retour visible. Maîtrisez le travail, puis étendez vers l’épisodique et le long terme.