Je la gère en séparant ce que l’agent traite maintenant, ce qu’il doit savoir durablement, et ce qu’il a déjà vécu. Sinon, il oublie, mélange tout, ou coûte trop cher. La fenêtre de contexte aide, mais elle ne remplace pas une vraie mémoire.
Pourquoi un agent IA oublie tout ?
Un agent IA oublie tout pour une raison simple : un LLM est sans état par défaut. Ça veut dire que chaque appel repart à froid si on ne lui redonne pas le contexte utile. Ce n’est pas un bug. C’est le fonctionnement normal d’un modèle de langage appelé via API : il reçoit une entrée, il produit une sortie, puis il ne garde pas de trace durable de l’échange.
J’aime bien le formuler comme ça : le modèle ne “se souvient” pas, il “relit” ce qu’on lui donne au moment de répondre. Si une information n’est pas dans le prompt, dans l’historique transmis, dans une base mémoire, ou récupérée via un outil, elle n’existe pas pour lui. Même si l’utilisateur l’a donnée deux minutes avant.
En production, ça devient vite un vrai sujet. Dans un workflow multi-étapes, l’agent doit souvent garder en tête plusieurs choses à la fois :
Intégrez l’IA Générative (GenAI) dans votre activité
Nos formations IA Générative (GenAI) et prompt engineering sont conçues pour les équipes qui veulent apprendre à exploiter les IA comme un pro. Vous y apprenez à structurer des prompts efficaces, à exploiter les meilleurs outils (assistants IA type ChatGPT, générateurs d’images, audio et vidéo) et à les appliquer à vos vrais cas métiers : analyser vos données (GA4, BigQuery, CRM…), produire des contenus clairs et crédibles, prototyper plus vite et automatiser les tâches répétitives. Des ateliers 100 % pratiques, pensés pour les entreprises, pour gagner du temps, sécuriser vos usages et livrer des analyses et supports de décision de niveau pro.
- Une consigne métier donnée au départ.
- Un choix utilisateur, comme “je préfère être livré le matin”.
- Une action déjà exécutée, par exemple “le ticket a déjà été créé”.
- Un résultat d’outil, comme une réponse CRM, ERP ou base SQL.
- Un statut de tâche, comme “validation en attente du manager”.
Sans mémoire persistante, l’agent peut faire n’importe quoi. Il peut répéter une action déjà faite, ignorer une préférence, perdre une contrainte importante, ou redemander une information déjà donnée. Et là, l’utilisateur perd confiance très vite. Pas parce que le modèle est “nul”, mais parce que l’architecture autour ne lui donne pas ce dont il a besoin.
Chez les clients, je vois toujours le même moment de bascule. Le chatbot démo marche bien, il répond proprement, tout le monde est content. Puis on lui demande d’exécuter un vrai process business, avec des étapes, des validations, des exceptions, des données qui changent. Et là, la mémoire devient le problème numéro un.
Le point clé, c’est que la mémoire n’est pas juste un historique de conversation. C’est une brique d’architecture. Elle sert à stocker, retrouver, filtrer et réinjecter le bon contexte au bon moment. Beaucoup d’équipes pensent régler ça avec une grande fenêtre de contexte. En pratique, ça aide parfois, mais ça ne suffit pas.
Pourquoi le contexte ne suffit pas ?
Une grande fenêtre de contexte aide, clairement. Mais elle ne crée pas une mémoire fiable. Elle permet seulement de donner plus de texte au modèle au moment de l’appel. C’est pratique, mais ce n’est pas la même chose qu’une mémoire propre, persistante, triée, et réutilisable.
La première limite, c’est que le rappel peut se dégrader avant même d’atteindre la capacité maximale. On parle souvent de l’effet lost in the middle, observé dans des travaux de recherche sur les longs contextes. L’idée est simple : une information placée au milieu d’un très long prompt peut être moins bien récupérée qu’une information au début ou à la fin. Ce n’est pas une loi magique qui arrive à chaque fois, mais en production c’est un vrai risque. J’ai déjà vu des agents “oublier” une contrainte importante noyée dans un historique énorme, alors qu’elle était bien présente dans le prompt.
La deuxième limite, c’est que la fenêtre de contexte ne sait pas naturellement prioriser ce qui compte. Si on renvoie tout l’historique, on mélange les infos utiles avec du bruit : politesses, essais ratés, détails obsolètes, digressions, corrections temporaires. Le modèle reçoit tout au même endroit, et il peut accorder trop d’attention à un détail qui n’a aucune valeur métier. C’est un peu comme demander à quelqu’un de relire tout un fil Slack de trois mois pour répondre à une question simple.
La troisième limite, c’est que le contexte n’existe pas entre les sessions. Quand la session se termine, rien ne persiste si l’application n’a pas prévu un stockage externe. Certains produits grand public ont déjà ajouté une mémoire entre sessions, oui. Mais si vous construisez votre propre agent, c’est à vous de décider ce qu’on stocke, comment on le récupère, et comment on le présente au modèle au bon moment.
Il y a aussi le coût. Renvoyer tout l’historique consomme des tokens, donc ça ralentit les appels et ça augmente la facture. Et souvent, on paie pour envoyer du texte qui ne sert à rien. La bonne approche, ce n’est pas de tout mettre dans le prompt. C’est de récupérer seulement ce qui est utile, quand c’est utile.
| Problème | Ce que ça provoque | Meilleure approche |
| Long contexte difficile à exploiter | Information importante moins bien récupérée | Récupérer les éléments pertinents au moment de l’appel |
| Historique envoyé en bloc | Bruit, contradictions, détails sans valeur métier | Trier, résumer et prioriser avant d’injecter dans le prompt |
| Pas de mémoire entre sessions | L’agent repart de zéro à chaque fois | Stocker une mémoire externe contrôlée par l’application |
Quelles mémoires faut-il distinguer ?
Je distingue la mémoire de travail, la mémoire sémantique et la mémoire épisodique, parce qu’elles ne servent pas le même besoin. C’est l’approche CoALA que je trouve la plus saine ici : on classe les mémoires selon ce qu’elles représentent, pas selon l’endroit où elles sont stockées.
Je vois souvent l’erreur inverse en production. On commence par dire “il nous faut une base vectorielle” ou “on va mettre ça dans PostgreSQL”. Mauvais départ. On choisit d’abord le type de mémoire dont l’agent a besoin pour le cas business, puis on choisit l’implémentation technique. Une base vectorielle, une table SQL, un cache Redis ou un stockage objet, ce sont juste des moyens. Pas la décision de fond.
La mémoire de travail, c’est ce que l’agent garde en tête maintenant. Elle vit dans le contexte immédiat : le prompt courant, les derniers tours vraiment utiles, l’état de la tâche, les résultats récents d’un outil. Elle disparaît à la fin de la session, ou presque. Exemple simple : l’agent prépare une réponse à un client, il garde en tête la demande en cours, le ton attendu, les contraintes immédiates et la dernière information récupérée dans un outil.
La mémoire sémantique, c’est la connaissance persistante. Documentation produit, règles internes, politiques RH, FAQ, connaissances métier, procédures support. En production, c’est souvent le plus gros volume. En général, on découpe ces contenus en morceaux, on les transforme en embeddings, c’est-à-dire en représentations numériques du sens, puis on les stocke dans une base vectorielle pour les retrouver par similarité.
La mémoire épisodique, elle garde ce qui s’est passé. Date, contenu de l’échange, actions réalisées par l’agent, résultats obtenus. L’index temporel est clé, parce que l’ordre change le sens. Une préférence exprimée hier, une action faite ce matin, puis un ticket fermé ensuite, ce n’est pas interchangeable. J’ai vu des agents “bien mémorisés” donner de mauvaises réponses juste parce qu’ils retrouvaient les bons événements dans le mauvais ordre.
| Type de mémoire | Contenu | Durée de vie | Usage typique |
| Mémoire de travail | Prompt courant, derniers échanges utiles, état de la tâche, résultats récents | Très courte, souvent limitée à la session | Répondre correctement à la demande en cours |
| Mémoire sémantique | Documentation, règles, FAQ, politiques, connaissances métier | Longue, mise à jour selon les sources | Retrouver une connaissance fiable au bon moment |
| Mémoire épisodique | Historique des échanges, actions, dates, résultats | Variable, selon le besoin métier et la conformité | Comprendre ce qui s’est déjà passé et dans quel ordre |
Comment l’implémenter proprement ?
J’implémente la mémoire d’un agent IA en séparant stockage, récupération et injection dans le prompt. L’agent ne doit pas tout relire, il doit recevoir le bon souvenir au bon moment.
Je garde une architecture simple. La mémoire de travail reste dans le prompt et dans l’état courant du workflow. C’est ce que l’agent utilise tout de suite pour répondre, décider, appeler un outil, suivre une tâche en cours.
La mémoire sémantique, elle, part dans un système de recherche adapté. Souvent, j’utilise des embeddings, c’est-à-dire des représentations numériques du sens d’un texte, avec une base vectorielle pour retrouver les passages proches de la demande. Si l’utilisateur parle d’un contrat, l’agent doit retrouver les clauses utiles, pas tout l’historique de conversation.
La mémoire épisodique se stocke différemment. Je mets un horodatage, des métadonnées et un index temporel. Le but, c’est de reconstruire ce qui s’est passé dans le bon ordre. Qui a validé quoi. Quelle action a été lancée. Quelle erreur est apparue. Chez un client, c’est souvent là que la différence se voit entre un agent “sympa en démo” et un agent utilisable en production.
Le point le plus important, c’est de décider quoi mémoriser. Tout stocker crée du bruit, coûte cher et rend l’agent moins fiable. Je garde les préférences utilisateur utiles, les décisions validées, les étapes terminées, les documents de référence, les actions réalisées et les erreurs importantes. J’évite le bavardage sans valeur, les doublons et les informations temporaires déjà périmées.
Le cycle est assez clair. L’utilisateur parle. L’orchestrateur récupère les souvenirs pertinents. Le modèle raisonne avec ce contexte injecté. L’agent agit. Puis le système écrit éventuellement un nouveau souvenir. Le mot important, c’est “éventuellement”. L’écriture ne doit pas être automatique pour tout. Je filtre, je résume, je structure.
Exemple de structure simple : { « memory_type »: « semantic », « user_id »: « user_123 », « content »: « L’utilisateur préfère recevoir les rapports le lundi matin. », « timestamp »: « 2026-07-09T10:15:00Z », « source »: « conversation », « importance »: 0.8, « expires_at »: null }. Ce n’est pas un standard universel, juste une base claire pour éviter de mélanger toutes les mémoires.
| Bonne pratique | Pourquoi je le fais |
| Séparer les types de mémoire | Pour éviter de traiter une préférence utilisateur comme un événement métier. |
| Récupérer peu mais mieux | Pour injecter du contexte utile sans noyer le modèle. |
| Horodater l’épisodique | Pour reconstruire les faits dans le bon ordre. |
| Résumer avant stockage | Pour réduire le bruit et garder seulement l’information exploitable. |
| Tester la qualité du rappel | Pour vérifier que l’agent retrouve vraiment les bons souvenirs. |
| Surveiller les coûts tokens | Parce que chaque souvenir injecté finit dans la facture et dans la latence. |
La vraie question c’est ce que votre agent doit retenir
La mémoire d’un agent IA ne se résume pas à une grande fenêtre de contexte. Un LLM repart à froid par défaut, donc si je veux un agent utile en production, je dois organiser ce qu’il garde, ce qu’il oublie et ce qu’il récupère. La mémoire de travail sert l’instant présent. La mémoire sémantique porte les connaissances durables. La mémoire épisodique raconte ce qui s’est passé dans le temps. Une fois ces rôles séparés, l’implémentation devient beaucoup plus saine. Vous gagnez un agent plus fiable, moins coûteux, et surtout capable de suivre un vrai workflow business.
FAQ
- Pourquoi un LLM n’a pas de mémoire par défaut ?
Un LLM appelé via API est généralement sans état. Il reçoit un prompt, produit une réponse, puis ne garde pas de trace durable. Si l’application veut qu’il se souvienne, elle doit stocker les informations ailleurs et les réinjecter quand c’est utile. - Une grande fenêtre de contexte peut-elle remplacer la mémoire d’un agent IA ?
Non. Elle permet d’envoyer plus de texte au modèle, mais elle ne garantit pas un rappel fiable, ne priorise pas les informations importantes et ne persiste pas entre les sessions. En production, elle doit être complétée par une vraie stratégie de mémoire. - Quelle est la différence entre mémoire sémantique et mémoire épisodique ?
La mémoire sémantique stocke des connaissances durables, comme une documentation produit, une FAQ ou des règles métier. La mémoire épisodique stocke ce qui s’est passé dans le temps : échanges, actions de l’agent, décisions, résultats, avec un horodatage. - Pourquoi utiliser une base vectorielle pour la mémoire sémantique ?
Une base vectorielle permet de retrouver des contenus proches du sens de la demande, pas seulement des mots exacts. C’est utile pour récupérer les bons passages d’une documentation ou d’une base de connaissances avant de les donner au modèle. - Faut-il tout mémoriser dans un agent IA ?
Non, c’est même une mauvaise idée. Tout mémoriser crée du bruit, augmente les coûts et peut dégrader les réponses. Je préfère stocker peu, mais mieux : les faits utiles, les décisions, les préférences importantes, les actions réalisées et les éléments qui servent vraiment le workflow.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent passer des prototypes IA aux vrais systèmes exploitables, avec des données propres, des workflows robustes et des agents qui tiennent la route. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez structurer vos agents IA ou vos automatisations, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.