Un agent d’IA qui ne se souvient pas de vous est fondamentalement limité. Chaque conversation repart de zéro. Vous devez vous présenter de nouveau, réexpliquer vos préférences et repréciser le travail en cours. Les frictions s’accumulent et la confiance diminue.
C’est le problème de la mémoire. Les fenêtres de contexte prennent en charge la conversation en cours. La mémoire à long terme — d’une session, d’un jour et d’un mois à l’autre — nécessite sa propre architecture. Et c’est plus difficile qu’il n’y paraît.
Cet article présente ce qu’est réellement la mémoire des agents en production : les couches, les choix de stockage, les modèles de récupération et les compromis qui distinguent une mémoire utile d’une mémoire qui hallucine.
Ce que signifie “mémoire”
Une vision simpliste serait la suivante : mémoire = “le modèle se souvient d’éléments d’une conversation à l’autre”. La réalité est plus nuancée. Les sciences cognitives distinguent plusieurs types de mémoire, et la mémoire des agents d’IA bénéficie d’une distinction similaire :
Mémoire de travail. La conversation en cours. Conservée dans la fenêtre de contexte. Perdue à la fin de la conversation (sauf si elle est enregistrée de manière persistante).
Mémoire épisodique. Des événements passés spécifiques. “Mardi dernier, nous avons discuté de X.” “Il y a trois mois, vous avez décidé Y.”
Mémoire sémantique. Des faits généraux. “Votre nom est Alice.” “Vous préférez les réponses concises.” “Votre entreprise est à Tallinn.”
Mémoire procédurale. La manière de procéder. “Lorsque l’utilisateur demande une réunion, utilisez ce modèle.” “Lorsque le client appartient au niveau X, suivez le processus Y.”
Les différents types de mémoire servent des fonctions différentes. Un système complet de mémoire d’agent couvre tous ces aspects.
Ce que la mémoire doit accomplir
Avant l’architecture, les objectifs :
Continuité. L’agent reprend là où il s’était arrêté. Vous n’avez pas à vous présenter de nouveau à chaque session.
Personnalisation. L’agent applique vos préférences sans qu’il soit nécessaire de les lui rappeler. Il écrit dans votre style, utilise vos outils et fait référence à votre équipe.
Préservation du contexte. Les décisions prises lors de conversations antérieures éclairent les conversations actuelles. L’agent doit se souvenir que “nous avons décidé X le mois dernier”.
Accumulation de compétences. L’agent apprend vos habitudes et les applique. Après 10 conversations consacrées à la programmation en Python, il doit utiliser Python par défaut.
Confidentialité et oubli. Ce qui est mémorisé, ce qui ne l’est pas et ce qui est supprimé. Ces choix sont essentiels à la confiance des utilisateurs comme à la conformité juridique.
Ces objectifs sont parfois contradictoires. La continuité incite à tout mémoriser ; la confidentialité, à ne rien mémoriser. L’architecture permet d’arbitrer ces compromis.
L’architecture
Une architecture typique en couches :
┌─────────────────────────────────────┐
│ Working memory (in-context) │ Current conversation
├─────────────────────────────────────┤
│ Session memory (recent) │ Last N conversations
├─────────────────────────────────────┤
│ Episodic memory (long-term) │ Specific past events
├─────────────────────────────────────┤
│ Semantic memory (facts) │ Stable user facts
├─────────────────────────────────────┤
│ Procedural memory (preferences) │ How to behave for this user
└─────────────────────────────────────┘
Chaque couche a son propre stockage, sa propre récupération et sa propre logique de dégradation.
Examinons chaque couche.
Couche 1 : Mémoire de travail
Cette couche a déjà été abordée dans l’article sur l’ingénierie du contexte. Il s’agit de la conversation en cours, présente dans le contexte. Pour les conversations à plusieurs tours, on utilise un contexte hiérarchisé qui conserve les échanges récents tels quels et résume les plus anciens.
Le transfert vers la mémoire à long terme s’effectue à la fin de la session. Les informations clés de la conversation sont extraites et stockées.
Couche 2 : Mémoire de session
Les sessions récentes — par exemple, les 10 dernières conversations — sont conservées de manière synthétique. Elles sont accessibles à l’agent lors de la session suivante.
Implémentation : un résumé par session, stocké avec un horodatage et un sujet. Lorsque l’utilisateur revient, l’agent dispose d’un aperçu rapide des événements récents.
{
"session_id": "abc-123",
"user_id": "alice",
"started": "2026-05-14T10:30:00Z",
"ended": "2026-05-14T10:45:00Z",
"topic": "Drafting proposal for Acme Corp",
"summary": "Drafted v1 of the Acme proposal. Decided to lead with the cost-savings angle. Alice will review and send Friday.",
"facts_learned": ["Acme is a current customer", "Alice's deadline is Friday"],
"open_items": ["Alice to review v1 by Thursday"]
}
Au début d’une nouvelle session, les 3 à 5 résumés les plus récents peuvent être chargés automatiquement. L’agent dispose ainsi du contexte des événements récents.
C’est la forme de mémoire intersession la plus accessible. Elle est facile à mettre en œuvre et immédiatement utile.
Couche 3 : Mémoire épisodique
Il s’agit d’événements passés précis qu’il est utile de conserver à long terme : décisions, jalons et conversations importantes.
Ces éléments sont extraits des sessions lorsqu’ils sont remarquables et stockés avec des métadonnées détaillées.
{
"event_id": "ev-456",
"user_id": "alice",
"date": "2026-04-22",
"type": "decision",
"description": "Alice decided to migrate from Postgres to ClickHouse for the analytics workload, citing query performance.",
"context_summary": "After 3 weeks of evaluation including performance tests and cost analysis.",
"related_topics": ["infrastructure", "analytics", "database"],
"importance": "high"
}
Récupération : lorsque cela est pertinent pour la conversation en cours, l’agent récupère les épisodes associés. Il peut utiliser la recherche sémantique (vectoriser la requête actuelle et trouver les épisodes correspondants), la mise en correspondance des sujets ou des requêtes temporelles (“que s’est-il passé le mois dernier ?”).
La difficulté consiste à déterminer ce qui constitue un “épisode digne d’être mémorisé”. Toutes les conversations ne le sont pas. Un modèle consiste à faire extraire par un LLM les événements notables à la fin de chaque session. Les décisions, les engagements et les jalons sont stockés ; les échanges informels ne le sont pas.
Couche 4 : Mémoire sémantique
Des faits stables sur l’utilisateur qui doivent toujours être disponibles. “Alice est la PDG d’Acme. Son style de communication préféré est concis. Elle travaille dans le fuseau horaire de Tallinn.”
Ces faits sont moins nombreux que les épisodes, mais plus souvent récupérés. Ils constituent le “modèle de l’utilisateur” de l’agent.
Implémentation : un profil structuré.
{
"user_id": "alice",
"profile": {
"name": "Alice Tamm",
"role": "CEO at Acme Corp",
"location": "Tallinn, Estonia",
"timezone": "Europe/Tallinn",
"preferred_language": "English",
"communication_style": "concise, direct, no preamble",
"expertise_areas": ["product strategy", "go-to-market"],
"tools_used": ["Notion", "Slack", "Linear"]
}
}
Les mises à jour interviennent lorsque l’agent apprend de nouveaux faits. Après une session, un LLM identifie et propose les nouveaux faits stables ; ils sont soit fusionnés automatiquement, soit placés dans une file d’attente pour examen.
Point important : les faits sémantiques doivent être fiables et stables. Une remarque en passant dans une conversation (“Je pourrais essayer Python”) ne doit pas devenir un fait sémantique (“Alice préfère Python”). Le seuil de validation est plus élevé.
Une approche basée sur la confiance :
- Entendu une fois : fait candidat, pas encore stocké.
- Entendu deux fois ou déclaré explicitement : stocké avec un niveau de confiance moyen.
- Confirmé explicitement ou mentionné fréquemment : stocké avec un niveau de confiance élevé.
Cela empêche l’agent d‘“apprendre” des faits erronés à partir de commentaires passagers.
Couche 5 : Mémoire procédurale
Il s’agit de la manière dont l’agent doit se comporter pour cet utilisateur : processus, modèles et préférences applicables à des actions précises.
Exemples :
{
"user_id": "alice",
"procedural": {
"email_signature": "...",
"meeting_preferences": "always offer 3 time slots, never schedule before 9am",
"code_style": "Python, type hints required, dataclasses over dicts",
"tone_for_clients": "warm, direct, with explicit next steps",
"approval_process": "all customer-facing communications need Alice's review before sending"
}
}
Ce sont les modèles que l’agent suit lorsqu’une tâche correspondante se présente.
Les mises à jour interviennent explicitement (“Alice, veuillez toujours procéder ainsi pour X”) ou par reconnaissance de schémas récurrents (après 5 demandes similaires traitées de la même manière, le schéma est ajouté).
Choix de stockage
Où la mémoire est-elle stockée ?
Base de données SQL. Fiable, interrogeable et bien maîtrisée. Chaque type de mémoire correspond à une table. Des jointures servent à la récupération. Ce choix convient aux schémas d’accès structurés.
Base de données vectorielle. Pour la récupération sémantique des épisodes (“trouver des souvenirs liés à ce sujet”). Les épisodes sont vectorisés, puis récupérés par similarité.
Combinaison. Souvent la meilleure solution : SQL pour les requêtes structurées et une base vectorielle pour la recherche sémantique. Les éléments de mémoire résident dans les deux, avec des identifiants cohérents.
Outils de mémoire spécialisés. Mem0, Letta (anciennement MemGPT), Zep. Ces outils sont conçus comme des couches de mémoire pour les agents. Ils méritent d’être envisagés si vous recherchez une abstraction de plus haut niveau.
Pour la plupart des équipes, une approche simple combinant SQL et recherche vectorielle suffit. Les outils spécialisés sont utiles, mais ajoutent une dépendance.
Modèles de récupération
Comment l’agent intègre-t-il la mémoire au contexte ?
Modèle 1 : Chargement automatique au début de la session
Lorsqu’une nouvelle session commence, charger automatiquement :
- Le profil sémantique de l’utilisateur.
- Les N derniers résumés de session.
- Tous les engagements ou suivis en cours.
C’est le contexte de référence dont dispose l’agent lorsque l’utilisateur se présente.
Modèle 2 : Récupération guidée par la requête
Lorsque le message de l’utilisateur évoque des sujets passés, récupérer les épisodes pertinents.
Exemple : l’utilisateur demande “quelle était la conclusion de notre discussion sur la base de données ?” L’agent recherche les épisodes associés à “base de données” et récupère celui qui convient.
Implémentation : vectoriser le message de l’utilisateur, trouver les épisodes similaires et les inclure dans le contexte.
Modèle 3 : Outils de mémoire explicites
L’agent a des outils pour interroger la mémoire :
search_episodes(query): trouver des événements passés précis.get_user_profile(): récupérer le profil sémantique.list_open_items(): obtenir les éléments en attente.
L’agent décide quand appeler ces outils en fonction de la conversation.
Modèle 4 : Enrichissement de mémoire en arrière-plan
Un processus en arrière-plan examine périodiquement la mémoire et :
- Regroupe les épisodes associés en thèmes.
- Met à jour le niveau de confiance des faits.
- Dégrade les souvenirs anciens qui n’ont pas été consultés.
C’est la “maintenance de la mémoire” : elle permet de préserver l’utilité du référentiel de mémoire au fil du temps.
Écriture de la mémoire
Quand la mémoire est-elle écrite ?
Extraction à la fin de la session
C’est l’approche la plus fiable. Lorsqu’une session se termine :
- Un LLM analyse la conversation.
- Extrait :
- Résumé de session.
- Événements notables (pour la mémoire épisodique).
- Nouveaux faits (pour la mémoire sémantique).
- Signaux de préférence (pour la mémoire procédurale).
- Met à jour les données et les stocke.
Ce traitement par lots préserve la rapidité de l’expérience en session (aucune écriture en mémoire pendant la conversation).
Prompt d’extraction :
Analyze this conversation. Output JSON with:
1. summary: 2-3 sentence summary of what happened.
2. notable_events: array of significant events worth remembering (decisions made, milestones, important context).
3. new_facts: array of stable facts learned about the user (only include if you have high confidence).
4. preference_signals: array of preferences observed (only if expressed clearly or repeated).
5. open_items: array of unresolved items the user might want to revisit.
Be conservative. Only include items with high confidence. Better to miss something than to hallucinate.
Mises à jour en temps réel des faits importants
Pour certains faits, il serait inapproprié d’attendre la fin de la session. Si l’utilisateur dit “en fait, je m’appelle Alex, pas Alice”, la correction doit être appliquée immédiatement.
Un modèle consiste à faire détecter en temps réel par l’agent les corrections explicites ou les nouveaux faits importants, puis à mettre à jour la mémoire au fil de la conversation.
Cela nécessite une conception soigneuse — le LLM pourrait “apprendre” des faits erronés. Certaines équipes exigent une confirmation utilisateur avant d’appliquer les mises à jour en temps réel.
Mises à jour initiées par l’utilisateur
L’utilisateur peut demander explicitement à l’agent de mémoriser certains éléments :
- “Veuillez vous souvenir que je préfère X.”
- “Oubliez ce que j’ai dit sur Y.”
- “Faites toujours Z.”
Ces demandes doivent être prises en compte immédiatement. Elles constituent les signaux offrant le niveau de confiance le plus élevé.
L’agent peut proposer un outil dédié :
remember(content: string, type: "fact" | "preference" | "procedure")
forget(content: string)
list_what_you_remember()
Donner ce contrôle à l’utilisateur renforce la confiance.
Oubli et dégradation
Une mémoire qui croît indéfiniment finit par devenir du bruit. La dégradation est essentielle.
Dégradation basée sur le temps
Les souvenirs anciens ont moins de chances d’être récupérés. Implémentation :
- Calculer le score de récupération selon
relevance * recency_decay. - Les souvenirs anciens disparaissent de fait, sauf s’ils sont explicitement mentionnés.
Rétention basée sur l’importance
Les épisodes importants sont conservés plus longtemps ; les épisodes anodins se dégradent plus rapidement.
- Attribuer un niveau d’importance aux épisodes lors de leur écriture.
- Événements critiques : conservation indéfinie.
- Événements courants : dégradation sur plusieurs mois.
Oubli initié par l’utilisateur
L’utilisateur peut demander la suppression de souvenirs spécifiques.
- Faits spécifiques.
- Périodes spécifiques.
- Sujets spécifiques.
Implémentation : une opération de suppression qui supprime (ou marque comme supprimée) les éléments pertinents.
Suppression imposée par la conformité
Les exigences légales (droit à l’oubli du RGPD, lois sur la conservation des données) imposent parfois la suppression.
- Suppression du compte utilisateur → toutes les mémoires supprimées.
- Demande de suppression de données → suppression de souvenirs précis.
- Limites de conservation → suppression automatique après N mois.
Ces mécanismes doivent être intégrés dès le départ. Les ajouter a posteriori est difficile.
Considérations de confidentialité
La mémoire est sensible. L’agent en sait beaucoup sur l’utilisateur. Plusieurs points sont à prendre en compte :
Chiffrement au repos
Les données de mémoire sont chiffrées. C’est une pratique courante.
Contrôles d’accès
Qui peut consulter la mémoire d’un utilisateur ? L’utilisateur seulement, le système seulement, le personnel d’assistance sous certaines conditions ? Définissez-le clairement et auditez les accès.
Traitement des données à caractère personnel
Les informations permettant d’identifier une personne (noms réels, adresses, informations financières) doivent être étiquetées et traitées avec précaution. Elles nécessitent des contrôles d’accès et des procédures de suppression spécifiques.
Visibilité pour l’utilisateur
Les utilisateurs doivent pouvoir consulter ce que l’agent mémorise à leur sujet. C’est à la fois éthique et bénéfique pour l’expérience utilisateur. Proposez un “tableau de bord de la mémoire”.
What the agent remembers about you:
Profile:
- Name: Alice Tamm
- Role: CEO at Acme Corp
- Communication style: concise, direct
Recent sessions:
- 2026-05-14: Drafted proposal for Acme
- 2026-05-12: Reviewed Q1 results
- ...
Preferences:
- Prefers concise responses
- Uses Notion, Slack, Linear
[Edit] [Delete specific items] [Delete all]
Cette transparence renforce la confiance. Une mémoire cachée est inquiétante.
Partage entre contextes
Si l’utilisateur dispose de plusieurs “modes” (agent professionnel, agent personnel), il peut souhaiter que les souvenirs restent séparés. Ne les partagez pas automatiquement entre les modes sans demande explicite.
Modes de défaillance courants
Quelques cas fréquents :
Défaillance 1 : Souvenirs hallucinés
L’agent affirme se souvenir de choses qui n’ont pas eu lieu. “La semaine dernière, nous avons convenu de X” — mais X n’a jamais été discuté.
Cause : le LLM “comble les vides” avec des souvenirs plausibles lors de l’extraction ou de la récupération.
Solution : ancrer les opérations de mémoire dans des données de conversation réelles. Le LLM effectue l’extraction ; la vérification s’appuie sur la transcription réelle. Les faits hallucinés doivent être signalés.
Défaillance 2 : Faits erronés appris
L’agent affirme avec confiance des faits erronés. “Vous avez dit préférer Python” alors que vous avez dit être contraint d’utiliser Python au travail.
Cause : mauvaise interprétation lors de l’extraction.
Solution : appliquer des seuils de confiance. N’apprendre qu’à partir de déclarations explicites, répétées ou confirmées. L’utilisateur doit pouvoir apporter des corrections.
Défaillance 3 : Fuites de données confidentielles
Des souvenirs d’un utilisateur apparaissent dans la conversation d’un autre. Catastrophique.
Cause : défauts dans la logique de cloisonnement par utilisateur.
Solution : imposer le cloisonnement par utilisateur dans les couches de stockage et de récupération. Auditer le système. Ne jamais compter sur le LLM pour effectuer le filtrage.
Défaillance 4 : Gonflement de la mémoire
Après un an, la mémoire est en mégaoctets par utilisateur. La récupération ralentit. Les coûts augmentent.
Cause : absence de dégradation ou de nettoyage.
Solution : appliquer une dégradation forte. La plupart des souvenirs deviennent inaccessibles (faible priorité de récupération) après plusieurs mois. Effectuer une compaction périodique.
Défaillance 5 : Faits obsolètes
L’utilisateur a changé de rôle il y a six mois. L’agent fait toujours référence au rôle ancien.
Cause : les faits ne sont pas mis à jour lorsqu’ils sont supplantés.
Solution : détecter les contradictions. Lorsqu’un nouveau fait contredit un ancien, le nouveau l’emporte (après confirmation en cas d’incertitude).
Défaillance 6 : Consolidation déroutante
La consolidation de mémoire en arrière-plan réécrit parfois les souvenirs de manière à perdre des informations.
Cause : résumé trop agressif qui ne préserve pas les faits essentiels.
Solution : la consolidation doit préserver explicitement les faits. Tester la consolidation sur des transcriptions de mémoire réelles.
Exemple concret : assistant personnel avec mémoire
Cas concret : un assistant personnel basé sur l’IA destiné aux particuliers.
Couches de mémoire :
- Travail : conversation actuelle.
- Session : les 7 dernières sessions sous forme de résumés.
- Épisodique : 100 événements notables les plus récents, avec recherche sémantique.
- Sémantique : profil utilisateur (nom, rôle, préférences, outils).
- Procédurale : processus explicites configurés par l’utilisateur.
Stockage :
- SQL (PostgreSQL) : profil structuré, sessions, épisodes, procédures.
- Base de données vectorielle (pgvector) : recherche sémantique épisodique.
Opérations :
- Début de session : charger automatiquement le profil sémantique + les 3 dernières sessions + les éléments en attente.
- Milieu de session : récupération épisodique déclenchée par la pertinence du sujet.
- Fin de session : extraction basée sur le LLM ; l’utilisateur peut vérifier ce qui a été appris.
- Arrière-plan : consolidation hebdomadaire (regrouper les épisodes associés, dégrader les souvenirs obsolètes).
Contrôles utilisateur :
- Tableau de bord de la mémoire indiquant les éléments mémorisés.
- Modification ou suppression d’éléments individuels.
- Bouton “oublier la dernière heure”.
- Suppression complète du compte (efface tout).
Résultats :
- Continuité : les utilisateurs indiquent que l’agent “semble persister” d’une session à l’autre.
- Personnalisation : le style des réponses correspond aux préférences de l’utilisateur sans qu’il soit nécessaire de les préciser de nouveau.
- Confidentialité : les contrôles explicites donnent confiance aux utilisateurs.
- Coût : la mémoire représente environ 5 à 15 % de l’utilisation des jetons par session. Le jeu en vaut la chandelle.
Défaillances traitées :
- Les souvenirs hallucinés sont détectés grâce à la vérification lors de l’extraction.
- Les faits erronés sont détectés par les seuils de confiance.
- La confidentialité est assurée à chaque point de stockage et de récupération.
- Le gonflement est maîtrisé par la dégradation et la consolidation.
C’est un système de mémoire adapté à la production. Il n’est pas trivial, mais reste tout à fait réalisable pour une équipe dédiée.
Outils spécialisés
Quelques précisions sur les offres de mémoire en tant que service :
Mem0. Open source et bien conçu. Prend en charge nombre des approches présentées ci-dessus. À envisager si vous ne souhaitez pas tout construire à partir de zéro.
Letta (MemGPT). Paradigme différent — le LLM lui-même gère la mémoire via des appels d’outils. Puissant mais plus complexe.
Zep. Couche de mémoire hébergée. Intégration facile.
Cognee. Plus récent ; mémoire fondée sur un graphe de connaissances.
Ces outils font gagner du temps de développement. Ils ajoutent aussi une dépendance et limitent les possibilités de personnalisation. Pour les systèmes de production matures, il est souvent judicieux de construire sa propre mémoire ; pour les prototypes ou les petites équipes, l’utilisation d’un outil est raisonnable.
Le point clé
La mémoire à long terme est ce qui fait que les agents semblent intelligents et continus plutôt qu’amnésiques. C’est aussi l’une des choses les plus difficiles à bien faire.
L’architecture est en couches :
- Mémoire de travail (en contexte).
- Mémoire de session (sessions récentes).
- Mémoire épisodique (événements spécifiques).
- Mémoire sémantique (faits stables).
- Mémoire procédurale (préférences et processus).
Chaque couche possède sa propre logique de stockage, de récupération et de dégradation. Chacune contribue à rendre l’agent utile au fil du temps.
Les modèles importants :
- Extraction prudente (ne pas halluciner de faits).
- Apprentissage basé sur la confiance (ne pas apprendre à partir de commentaires passagers).
- Oubli actif (dégradation et nettoyage).
- Contrôle par l’utilisateur (transparence et possibilité de modification).
- Respect de la confidentialité (à chaque couche).
Bien conçue, la mémoire transforme l’IA, qui passe d‘“un nouvel inconnu à chaque conversation” à “un partenaire utile qui s’inscrit dans la continuité”. C’est la différence entre l’IA comme outil et l’IA comme collègue.
Pour les agents destinés à vous accompagner pendant des jours, des semaines ou des mois, la mémoire n’est pas facultative. Elle est fondamentale. Construisez-la de manière réfléchie, avec les couches et la rigueur nécessaires.
