FrameworksAgents.com Logo

Mémoire long terme pour agents IA : guide

Guidecalendar_todayPublié le 17 avril 2026schedule11 min de lecturelong term memory agent iapersistance mémoire agent

Donnez une mémoire long terme à vos agents IA : persistance, épisodique, sémantique et procédurale. Guide complet avec solutions et code Python.

Mémoire long terme pour agents IA

TL;DR : un agent fiable ne stocke pas tout dans la fenêtre de contexte. Il combine en général une mémoire épisodique pour l'historique, une mémoire sémantique pour les faits retrouvés par similarité, une mémoire procédurale pour les préférences et règles de travail, et une couche de gouvernance pour l'oubli, le TTL et la suppression RGPD.

Introduction

Un agent IA sans mémoire long terme recommence à zéro à chaque session. Il oublie les préférences utilisateur, les décisions passées et les informations déjà validées. C'est acceptable pour un chatbot simple, beaucoup moins pour un assistant, un agent support ou un orchestrateur multi-étapes. Si vous voulez un agent qui gagne en continuité plutôt qu'en simple contexte temporaire, il faut sortir de la seule fenêtre de contexte du LLM et mettre en place une mémoire persistante. Cet article explique les grands types de mémoire long terme, les architectures utiles en pratique et les choix techniques à faire pour construire un agent qui se souvient sans devenir incontrôlable.

Dans cette logique, il est utile de distinguer la mémoire générale d'un agent de la mémoire long terme persistée. Si vous voulez le cadrage complet sur les catégories de mémoire, commencez aussi par Mémoire des agents IA.

Résumé rapide

TypeCe qu'elle stockeSupport courantQuand l'utiliser
Épisodiqueévénements, conversations, actions passéesSQLite, PostgreSQL, logs structuréscontinuité entre sessions, audit
Sémantiquefaits, préférences, documents, résumésChroma, Qdrant, Pineconerappel par similarité, RAG
Procéduralerègles, habitudes, style de réponseJSON, KV store, prompt systempersonnalisation comportementale
Contextuelle persistéeétat projet, décisions, contraintesSQL, YAML, fichiers d'étatsuivi opérationnel, exécution longue

Les 4 types de mémoire long terme pour les agents

Quand on parle de mémoire long terme pour un agent, on mélange souvent plusieurs besoins très différents. En pratique, il faut séparer au moins quatre couches.

1. La mémoire épisodique

La mémoire épisodique enregistre les événements passés : conversations, tâches exécutées, erreurs rencontrées, résultats d'actions. C'est la mémoire du vécu de l'agent.

Exemples :

  • un utilisateur a demandé un export CSV hier
  • l'agent a déjà tenté une API qui a renvoyé une erreur 429
  • une tâche a été validée après trois itérations

Cette mémoire sert surtout à donner de la continuité entre les sessions et à éviter de répéter les mêmes actions inutilement.

2. La mémoire sémantique

La mémoire sémantique stocke des faits persistants : connaissances, profils, documents, préférences, concepts appris. C'est la partie la plus proche d'un système RAG.

Exemples :

  • le client préfère recevoir un résumé court
  • tel produit a telle politique tarifaire
  • ce document interne contient les règles de validation

C'est souvent ici qu'une mémoire vectorielle pour agents IA devient utile, car on veut récupérer une information pertinente par similarité de sens, pas seulement par clé exacte.

3. La mémoire procédurale

La mémoire procédurale encode comment l'agent agit. Elle peut prendre la forme de préférences comportementales, de règles d'exécution ou de patterns appris.

Exemples :

  • toujours proposer 2 ou 3 options quand il existe un vrai trade-off
  • ne jamais exécuter une action externe sans confirmation
  • résumer les logs avant de relancer un outil

Dans un agent moderne, cette mémoire est souvent hybride : une partie dans le prompt système, une partie dans des fichiers de configuration, une partie dans des règles dérivées de l'expérience.

4. La mémoire contextuelle persistée

Cette catégorie sert à conserver le contexte durable de travail : état de projet, décisions, jalons, contraintes, historique de collaboration.

Exemples :

  • tel projet utilise PostgreSQL et non SQLite
  • la branche de déploiement est main
  • le ton attendu par l'utilisateur est concis et factuel

Elle n'est ni purement épisodique, ni purement sémantique. C'est une mémoire de continuité opérationnelle.

Mémoire épisodique : stocker l'historique des conversations

La mémoire épisodique est souvent la première à implémenter, parce qu'elle résout un problème immédiat : l'agent oublie ce qui s'est passé avant.

Option 1 : stockage SQL

Une base SQL convient très bien si vous voulez garder un historique structuré, filtrable et auditable.

import sqlite3
from datetime import datetime

conn = sqlite3.connect("agent_memory.db")
conn.execute("""
CREATE TABLE IF NOT EXISTS episodes (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    user_id TEXT,
    session_id TEXT,
    role TEXT,
    content TEXT,
    created_at TEXT
)
""")


def save_episode(user_id: str, session_id: str, role: str, content: str):
    conn.execute(
        "INSERT INTO episodes (user_id, session_id, role, content, created_at) VALUES (?, ?, ?, ?, ?)",
        (user_id, session_id, role, content, datetime.utcnow().isoformat())
    )
    conn.commit()


def load_recent_episodes(user_id: str, limit: int = 10):
    rows = conn.execute(
        "SELECT role, content FROM episodes WHERE user_id = ? ORDER BY id DESC LIMIT ?",
        (user_id, limit)
    ).fetchall()
    return list(reversed(rows))

Avantages :

  • simple à requêter
  • facile à purger
  • très bon pour l'audit et le RGPD

Limites :

  • peu efficace pour retrouver un souvenir par similarité sémantique
  • nécessite une logique de résumé si l'historique grossit trop

Option 2 : stockage vectoriel des épisodes

Si vous voulez retrouver les conversations passées par proximité de sens, une base vectorielle est plus adaptée.

from chromadb import Client
from uuid import uuid4

client = Client()
collection = client.get_or_create_collection("episodes")


def save_episode_embedding(text: str, metadata: dict):
    collection.add(
        ids=[str(uuid4())],
        documents=[text],
        metadatas=[metadata]
    )


def recall_similar_episodes(query: str, n_results: int = 3):
    results = collection.query(query_texts=[query], n_results=n_results)
    return results["documents"][0]

Cette approche est intéressante quand l'agent doit se rappeler qu'une situation ressemble à une autre, même si les mots exacts diffèrent.

Recommandation pratique

Pour la mémoire épisodique, une architecture hybride marche souvent mieux :

  • SQLite ou PostgreSQL pour l'historique brut
  • base vectorielle pour les résumés d'épisodes importants

Vous gardez ainsi la traçabilité tout en permettant une récupération intelligente.

Mémoire sémantique : connaissances et faits persistants

La mémoire sémantique répond à une autre question : comment l'agent conserve-t-il des faits utiles entre les sessions ?

C'est ici que les embeddings, la recherche sémantique et le RAG deviennent centraux. L'agent ne doit pas injecter tout son passé dans le prompt. Il doit récupérer uniquement ce qui est pertinent pour la tâche en cours.

Architecture typique

  1. Transformer un fait ou un document en embedding
  2. Le stocker dans une base vectorielle avec des métadonnées
  3. Formuler une requête de rappel au moment opportun
  4. Réinjecter les souvenirs les plus pertinents dans le prompt

Exemple simple :

from openai import OpenAI
from chromadb import Client
from uuid import uuid4

openai_client = OpenAI()
vector_db = Client().get_or_create_collection("semantic_memory")


def remember_fact(text: str, metadata: dict):
    vector_db.add(
        ids=[str(uuid4())],
        documents=[text],
        metadatas=[metadata]
    )


def retrieve_facts(query: str, top_k: int = 5):
    results = vector_db.query(query_texts=[query], n_results=top_k)
    return results["documents"][0]

Quels outils utiliser ?

Les options les plus fréquentes :

  • Chroma pour prototypage local rapide
  • Qdrant pour self-hosting plus robuste
  • Pinecone pour une solution managée orientée production

Ce qu'il faut stocker

À garder dans la mémoire sémantique :

  • préférences utilisateur stables
  • faits métier réutilisables
  • résumés de documents
  • décisions déjà prises
  • contexte projet durable

À éviter :

  • bruit conversationnel sans valeur future
  • informations périmées non datées
  • données sensibles sans stratégie de suppression

Mémoire procédurale : préférences et comportements appris

La mémoire procédurale est souvent sous-estimée. Pourtant, c'est elle qui transforme un agent techniquement compétent en agent réellement utile.

Un agent n'a pas seulement besoin de savoir des choses. Il doit aussi apprendre comment travailler avec un utilisateur, une équipe ou un environnement donné.

Exemple de stockage structuré

import json
from pathlib import Path

PREFERENCES_FILE = Path("agent_preferences.json")


def load_preferences():
    if not PREFERENCES_FILE.exists():
        return {}
    return json.loads(PREFERENCES_FILE.read_text())


def save_preference(key: str, value):
    prefs = load_preferences()
    prefs[key] = value
    PREFERENCES_FILE.write_text(json.dumps(prefs, ensure_ascii=False, indent=2))

Exemples de préférences utiles :

  • longueur de réponse attendue
  • ton préféré
  • format de livrable
  • niveau de détail technique
  • règles métier récurrentes

Réinjection dans le prompt

La mémoire procédurale n'est utile que si elle influence effectivement le comportement.

def build_system_prompt(base_prompt: str, preferences: dict) -> str:
    lines = [base_prompt]
    if preferences.get("tone"):
        lines.append(f"Ton préféré : {preferences['tone']}")
    if preferences.get("response_style"):
        lines.append(f"Style de réponse : {preferences['response_style']}")
    if preferences.get("decision_rules"):
        lines.append(f"Règles : {preferences['decision_rules']}")
    return "\n".join(lines)

La bonne pratique consiste à ne pas injecter toutes les préférences à chaque appel, mais seulement celles qui influencent la tâche en cours.

Architectures combinées : comment articuler plusieurs types de mémoire

Une mémoire long terme utile n'est presque jamais monolithique. Le meilleur design est généralement composé de plusieurs couches.

Architecture recommandée

Couche 1, mémoire épisodique

  • stockage relationnel des conversations et événements
  • utile pour audit, replay, historique brut

Couche 2, mémoire sémantique

  • stockage vectoriel des faits et résumés importants
  • utile pour rappel par pertinence

Couche 3, mémoire procédurale

  • stockage structuré des préférences et règles de comportement
  • utile pour personnalisation et cohérence

Pipeline simple de rappel

  1. L'utilisateur envoie une requête
  2. L'agent identifie le besoin de rappel
  3. Il interroge la mémoire sémantique
  4. Il charge les préférences procédurales pertinentes
  5. Il récupère si besoin quelques épisodes récents
  6. Il compose un contexte réduit, pertinent et frais

Pourquoi l'hybride gagne

Un seul système fait rarement tout bien.

  • SQL est excellent pour le filtrage exact
  • la base vectorielle est meilleure pour la similarité
  • le JSON ou key-value est plus simple pour les préférences

Vouloir tout faire avec une seule base finit souvent par créer un système fragile ou inutilement complexe.

Bonnes pratiques : TTL, oubli sélectif, privacy, compression

La vraie difficulté n'est pas seulement de mémoriser. C'est de mémoriser sans polluer l'agent.

1. Mettre des timestamps partout

Chaque souvenir doit être daté. Sans ça, impossible de gérer la fraîcheur et l'obsolescence.

2. Prévoir un TTL

Certaines mémoires expirent naturellement :

  • une préférence temporaire
  • un état de tâche
  • un contexte de ticket clos

Exemple simplifié :

from datetime import datetime, timedelta


def is_expired(created_at: datetime, ttl_days: int) -> bool:
    return datetime.utcnow() > created_at + timedelta(days=ttl_days)

3. Implémenter l'oubli sélectif

Toutes les informations ne méritent pas la même durée de vie. Un bon système distingue :

  • ce qu'il faut conserver longtemps
  • ce qu'il faut compresser
  • ce qu'il faut supprimer rapidement

Exemples :

  • préférences utilisateur stables, longue conservation
  • messages transactionnels, conservation courte
  • erreurs techniques répétitives, conservation résumée

4. Compresser la mémoire

Au lieu de garder 50 interactions similaires, vous pouvez les résumer en un souvenir stable.

Exemple :

  • au lieu de stocker 20 messages montrant que l'utilisateur préfère des réponses courtes
  • stocker un fait procédural : response_style = concise

5. Gérer la privacy et le RGPD

La mémoire long terme touche vite à des données personnelles. Il faut donc prévoir :

  • une suppression par utilisateur
  • une suppression par catégorie de données
  • une traçabilité minimale
  • une stratégie d'anonymisation si besoin

Exemple SQL de suppression :

def delete_user_memory(user_id: str):
    conn.execute("DELETE FROM episodes WHERE user_id = ?", (user_id,))
    conn.commit()

Si vous utilisez une base vectorielle, la suppression doit aussi exister côté embeddings. C'est un point à vérifier très tôt, pas à la fin.

Que faut-il implémenter en premier ?

Si vous partez de zéro, n'essayez pas de construire le système parfait dès le départ.

Ordre recommandé :

  1. historique SQL minimal
  2. préférences structurées
  3. recherche sémantique sur les faits importants
  4. compression et TTL
  5. politiques de suppression et d'audit

C'est plus simple, plus testable et plus robuste qu'une grosse architecture vectorielle dès le jour 1.

Questions fréquentes

Une base vectorielle suffit-elle pour toute la mémoire long terme ?

Non. Une base vectorielle est excellente pour retrouver des souvenirs par similarité sémantique, mais elle n'est pas idéale pour les préférences structurées, les états exacts ou l'audit. En pratique, les agents robustes utilisent une architecture hybride.

Quelle différence entre mémoire long terme et RAG ?

Le RAG est un mécanisme de récupération d'information. La mémoire long terme est plus large : elle inclut aussi les préférences utilisateur, les états persistés, l'historique d'exécution et les règles comportementales.

Faut-il mémoriser toutes les conversations ?

Non plus. Il vaut mieux sélectionner, résumer et dater. Une mémoire trop volumineuse dégrade la qualité du rappel et augmente les coûts d'inférence.

Conclusion

La mémoire long terme d'un agent IA n'est pas une seule brique technique, mais un assemblage de mémoires épisodiques, sémantiques, procédurales et contextuelles. Le bon design dépend moins du modèle que de ce que l'agent doit réellement retenir, oublier et réutiliser. En pratique, une architecture hybride est souvent le meilleur choix : SQL pour le vécu, vectoriel pour le rappel sémantique, stockage structuré pour les préférences.

Prêt à implémenter ? Commencez par la mémoire vectorielle pour agents IA pour poser les fondations de votre système de mémoire long terme.

Restez informé sur les agents IA

Nouveaux tutoriels, comparatifs et guides pratiques directement dans votre boîte mail.

homeAccueilcodeFrameworkssmart_toyAgentsmenu_bookTutorielsTwitter