Je choisis rarement une seule mémoire LLM. Un agent fiable mélange contexte court, récupération externe et mémoire persistante selon le besoin. Le vrai sujet, c’est l’architecture : quoi garder, quoi oublier, quoi récupérer, et avec quelle latence acceptable.
C’est quoi la mémoire LLM ?
La mémoire LLM, c’est ce que le modèle sait déjà dans ses poids, plus ce qu’on lui donne au moment de répondre. LLM veut dire Large Language Model, un modèle de langage entraîné à prédire et générer du texte. Quand je parle de “poids”, je parle des milliards de paramètres internes ajustés pendant l’entraînement.
Il y a deux grandes familles à bien séparer. La première, c’est la connaissance paramétrique. Elle est figée dans le modèle après son entraînement, ou après un fine-tuning, c’est-à-dire un réentraînement ciblé sur des exemples spécifiques. Le modèle “sait” des choses, mais il ne sait pas forcément vos procédures internes, vos clients, vos tickets récents, vos règles métier du mois dernier.
La deuxième, c’est la mémoire injectée au runtime. Runtime veut juste dire “au moment où l’agent répond ou agit”. Là, on lui transmet ce dont il a besoin maintenant : l’historique de conversation, les instructions, les documents utiles, les décisions déjà prises, les préférences utilisateur, l’état d’un workflow.
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.
En production, le vrai levier est rarement de modifier le modèle lui-même. C’est souvent de mieux choisir ce qu’on lui donne au bon moment. Un agent IA fiable, ce n’est pas juste un gros modèle. C’est un modèle correctement alimenté.
Cette mémoire runtime sert à plusieurs choses très concrètes :
- Ancrer les réponses dans des faits vérifiables, plutôt que laisser le modèle improviser.
- Maintenir un état dans un workflow multi-étapes, par exemple une demande client qui passe par plusieurs contrôles.
- Éviter de repartir de zéro à chaque appel API, parce qu’un LLM n’a pas de mémoire magique entre deux requêtes.
- Garder une cohérence entre les actions, les décisions et les réponses envoyées.
Prenez un agent support. Il doit se souvenir que le client a déjà redémarré sa box, que le diagnostic pointe vers un problème DNS, que le contrat est premium, et que la prochaine action est d’ouvrir un ticket niveau 2. Si on ne lui donne pas ces infos, il risque de reposer les mêmes questions ou de proposer une action déjà faite.
Sur les projets d’automatisation IA que je vois passer, le problème vient souvent moins du modèle que de la donnée autour. Elle est mal préparée, trop longue, mal résumée, ou injectée en bloc “au cas où”. Et là, l’agent devient flou, lent, cher, parfois incohérent.
La bonne question n’est donc pas “Est-ce que mon modèle a une mémoire ?”. La bonne question, c’est “Quelle mémoire je lui donne, sous quelle forme, et à quel moment ?”. Les types de mémoire ne se remplacent pas tous. Ils se combinent.
Quels types de mémoire existent ?
Les principaux types de mémoire LLM sont la mémoire en contexte, la mémoire externe, la mémoire paramétrique et la mémoire épisodique. Je les vois comme des briques complémentaires, pas comme un classement théorique. Dans un agent IA fiable, chaque mémoire a son rôle, et le vrai sujet c’est de savoir quoi mettre où.
La mémoire en contexte, c’est tout ce que le modèle voit directement dans le prompt. L’historique de conversation, les consignes système, les données qu’on lui donne juste avant de répondre. Sa force est simple : c’est rapide, direct, précis. Le modèle voit les tokens, donc il peut s’appuyer dessus sans chercher ailleurs. Mais cette mémoire coûte cher en tokens, et elle a une limite physique : la fenêtre de contexte. Si on met trop d’informations, les éléments importants se noient. Si l’échange dure trop longtemps, les anciennes infos sortent du contexte ou deviennent moins fiables.
La mémoire externe, c’est ce qu’on stocke hors du modèle : documents, tickets support, CRM, bases métier, procédures internes. En pratique, on transforme souvent ces contenus en embeddings, c’est-à-dire en représentations numériques du sens, puis on les met dans une base vectorielle. L’agent cherche les passages utiles, parfois avec une recherche hybride qui mélange mots-clés et similarité sémantique, puis il injecte ces passages dans le prompt. C’est très pratique pour stocker large, garder un coût raisonnable et mettre à jour les données sans refaire un fine-tuning. Le risque, je l’ai vu chez plusieurs clients, c’est le mauvais chunking. Des morceaux trop longs, trop courts, ou mal découpés. Résultat : récupération bruyante, passages hors sujet, et hallucinations qui repartent de plus belle.
La mémoire paramétrique, c’est la connaissance contenue dans les poids du modèle. Elle donne une bonne culture générale, sans base externe, sans latence ajoutée. Mais elle peut être obsolète, figée, et rarement suffisante pour des données business qui changent toutes les semaines.
La mémoire épisodique, c’est la mémoire persistante entre sessions. Préférences utilisateur, décisions passées, contexte d’un projet, habitudes d’un processus. Elle apporte de la continuité. Mais si on garde tout, on crée vite une poubelle intelligente. Il faut résumer, consolider, oublier. Une bonne mémoire sait aussi supprimer.
| Type de mémoire | Usage principal | Avantage | Limite |
| Mémoire en contexte | Consignes, historique, données dans le prompt | Rapide et précise | Fenêtre limitée et coût en tokens |
| Mémoire externe | Documents, bases vectorielles, recherche de passages | Stockage large et mise à jour simple | Récupération parfois bruyante |
| Mémoire paramétrique | Connaissances internes du modèle | Aucune récupération externe | Peut être obsolète ou trop générale |
| Mémoire épisodique | Continuité entre sessions | Personnalisation et suivi | Accumulation si on ne résume pas |
Quels compromis faut il accepter ?
Il faut arbitrer entre pertinence, coût, latence, fraîcheur de la donnée et fiabilité. La meilleure mémoire LLM, ce n’est pas celle qui stocke tout. C’est celle qui donne au modèle juste assez d’information utile, au bon moment. C’est souvent là que les agents IA deviennent bons… ou franchement fatigants.
La mémoire en contexte, c’est la plus simple. On met les infos directement dans le prompt, donc le modèle les voit tout de suite. Quand le volume est faible, c’est fiable, lisible, facile à déboguer. Mais si on empile tout l’historique, ça coûte cher, ça ralentit, et le modèle finit par mélanger des détails importants avec du bruit.
La mémoire externe, souvent avec une base vectorielle, scale mieux. On stocke les documents dehors, puis on récupère seulement les passages utiles. Mais elle dépend énormément de la qualité de l’indexation. Le découpage des textes, les métadonnées, la stratégie de recherche, tout compte. Un mauvais chunk, c’est-à-dire un mauvais morceau de document, peut faire remonter une réponse presque bonne, donc dangereuse.
La mémoire paramétrique, celle qui est dans le modèle lui-même, est rapide. Pas besoin de rechercher ailleurs. Mais elle est difficile à mettre à jour. Si une règle métier change, le modèle ne le sait pas par magie.
La mémoire épisodique donne de la continuité. Elle permet à l’agent de se souvenir d’interactions passées, de préférences, de décisions. Mais il faut filtrer, résumer, supprimer. Sinon on fabrique une cave pleine de souvenirs contradictoires.
Dans mes missions, je préfère souvent démarrer petit. Une mémoire courte propre, une récupération externe bien chunkée, puis une mémoire épisodique seulement quand le cas d’usage le justifie. Ça évite beaucoup de fausse sophistication.
| Compromis | Symptôme | Correction possible |
| Pertinence vs volume | Le modèle répond à côté car trop d’anciennes infos restent dans le contexte | Hiérarchiser, résumer, garder seulement les éléments actifs |
| Qualité de récupération vs simplicité | Hallucinations quand la recherche remonte du bruit | Améliorer les chunks, les métadonnées et les filtres |
| Latence vs raisonnement | Réponses lentes car trop d’étapes sont ajoutées | Limiter les appels mémoire et mettre en cache les résultats utiles |
| Persistance vs cohérence | Réponses incohérentes à cause de souvenirs contradictoires | Ajouter des règles d’expiration, de validation et de priorité |
| Fraîcheur vs rapidité | Le modèle utilise une information dépassée | S’appuyer sur une source externe à jour plutôt que sur la mémoire interne |
Comment l’architecturer en production ?
En production, j’architecture la mémoire LLM comme un flux de données, pas comme une option qu’on colle à la fin du prompt. Sinon, ça devient vite un fourre-tout. On doit décider ce qui entre, ce qui est résumé, ce qui est indexé, ce qui est récupéré, ce qui est oublié, et ce qui est vraiment injecté au moment où le modèle répond.
Dans une architecture propre, l’utilisateur ou l’application métier génère des événements. Une question posée. Une décision prise. Un document consulté. Une préférence exprimée. Je ne garde pas tout. Je stocke les échanges utiles, je résume les conversations longues, et j’indexe les documents dans une mémoire externe, souvent une base vectorielle. Une base vectorielle, c’est simplement un moteur qui retrouve des contenus proches d’une question, même si les mots ne sont pas exactement les mêmes.
Le vrai sujet, c’est le tri. Je dois choisir la taille des chunks, donc les morceaux de texte envoyés à l’index. Trop petits, on perd le contexte. Trop grands, on noie le modèle. Je dois ajouter des métadonnées propres : source, date, client, produit, version, droits d’accès. Je dois aussi fixer des seuils de pertinence. Si le moteur récupère un passage trop faible, je préfère ne rien injecter plutôt que de polluer la réponse.
Des outils low code comme n8n sont très pratiques pour orchestrer tout ça. Low code, ça veut dire qu’on assemble des workflows visuels avec un peu de code quand c’est nécessaire. Je l’utilise souvent pour connecter une base métier, une API, un vector store, un modèle LLM et un système de logs. Ça permet de tester vite sans enfermer toute la logique dans du code dur dès le premier jour.
Un exemple simple : un agent interne répond sur une base documentaire. Il retient que Julie préfère des réponses courtes avec les liens sources. Il ne garde pas tout son historique brut. Il résume seulement les décisions importantes, comme “Le client X utilise la version Enterprise”. Quand Julie pose une question générale, il répond sans chercher dans tous les documents. Quand elle demande une procédure ou une règle précise, il récupère les passages pertinents, assemble le prompt, appelle le modèle, puis met à jour la mémoire si ça vaut le coup.
La latence doit être pensée dès le départ. Une récupération vectorielle, un résumé automatique et plusieurs appels LLM rendent l’agent plus intelligent. Mais ça peut aussi le rendre lent, cher, et pénible à utiliser.
Avant production, je valide ça :
- Fraîcheur des données.
- Qualité de récupération des passages.
- Coût tokens par requête.
- Temps de réponse réel.
- Stratégie d’oubli des données.
- Traçabilité des sources utilisées.
- Cohérence de la mémoire entre sessions.
Et si la vraie mémoire était surtout une bonne architecture ?
La mémoire LLM n’est pas un bloc magique à activer. C’est un ensemble de choix. Je garde le contexte quand il est court et utile. J’utilise une mémoire externe quand il faut récupérer de la donnée à jour. Je compte sur la mémoire paramétrique pour la compréhension générale. J’ajoute une mémoire épisodique quand la continuité entre sessions apporte vraiment quelque chose.
Le piège, c’est de tout stocker et de tout réinjecter. Un bon agent sait surtout filtrer. Si vous concevez cette mémoire proprement, vous gagnez des réponses plus cohérentes, moins chères, plus rapides et plus fiables pour votre business.
FAQ
- Qu’est-ce que la mémoire LLM ?
La mémoire LLM désigne à la fois ce que le modèle a appris dans ses poids et ce qu’on lui fournit au moment de répondre. En production, la partie la plus contrôlable est la mémoire runtime : contexte, documents récupérés, historique résumé, préférences et décisions passées. - Quelle est la différence entre mémoire en contexte et mémoire externe ?
La mémoire en contexte est directement placée dans le prompt. Elle est rapide et précise, mais limitée par la fenêtre de contexte. La mémoire externe stocke les informations ailleurs, souvent dans une base vectorielle, puis récupère seulement les morceaux utiles avant l’appel au modèle. - Pourquoi la mémoire externe peut provoquer des hallucinations ?
Elle peut provoquer des réponses faibles si la récupération ramène des passages hors sujet, incomplets ou mal découpés. Le modèle croit travailler avec du contexte fiable, mais le contexte est bruité. Le chunking, les métadonnées, les seuils de pertinence et la recherche hybride changent beaucoup le résultat. - Faut-il fine-tuner un modèle pour lui donner de la mémoire ?
Pas forcément. Le fine-tuning agit plutôt sur la mémoire paramétrique et le comportement du modèle. Pour des informations business qui changent souvent, une mémoire externe ou épisodique est généralement plus souple, plus simple à mettre à jour et plus contrôlable. - Comment éviter qu’un agent IA garde trop d’historique ?
Je mets en place des règles de résumé et d’oubli. L’agent ne doit pas conserver tout le brut. Il doit garder les décisions importantes, les préférences utiles et les éléments nécessaires à la continuité. Le reste peut être résumé, archivé ou supprimé selon le cas d’usage.
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. Avec mon agence webAnalyste et l’organisme Formations Analytics, j’accompagne des équipes qui veulent rendre leurs données vraiment exploitables, pas juste brancher un outil de plus. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer vos agents IA, vos workflows n8n ou vos architectures data, 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.