Pourquoi ton agent « ne se souvient de rien » alors que toute la documentation est chargée
C'est la plainte numéro un de la deuxième semaine : tu lui as chargé le manuel entier, les politiques, l'historique des tickets, et l'agent continue de demander des choses que tu lui as déjà dites hier. La conclusion immédiate — « il lui manque de la mémoire » — est correcte et ne sert à rien, parce que mémoire est le mot avec lequel le marché désigne trois choses différentes, qui se rangent à des endroits différents, coûtent des choses différentes et cassent de manières différentes.
La confusion la plus chère du secteur, c'est celle-ci : mémoire et RAG ne sont pas la même chose. Le RAG, c'est que l'agent sache chercher dans ta documentation. La mémoire, c'est que l'agent sache qui tu es la prochaine fois que tu lui parles. Tu peux avoir un RAG impeccable — il récupère le paragraphe exact du manuel en 200 millisecondes — et un agent qui ne se souvient toujours pas que ce client s'est déjà plaint deux fois de la même commande. Ce sont des problèmes différents avec des solutions différentes, et monter le second avec l'outil du premier, c'est exactement pour ça que la moitié des projets s'enlisent ici.
Les trois choses que tu mets dans le même sac
Avant d'acheter quoi que ce soit, sépare. Un agent en production a normalement besoin des trois, mais elles se contractent, se paient et s'auditent séparément.
1. Le contexte de la conversation en cours (mémoire à court terme)
C'est ce que le modèle a sous les yeux en ce moment : ce que tu as dit dans ce fil. Ce n'est pas une base de données, c'est la fenêtre de contexte — l'espace de travail du modèle — et elle se vide quand la conversation se termine. C'est gratuit au sens où il n'y a rien à construire, et hors de prix au sens où ça se paie au token à chaque tour : plus le fil est long, plus chaque message suivant coûte cher. Quand quelqu'un te dit que son agent « se souvient de tout à l'intérieur de la conversation », il te décrit le comportement par défaut, pas une capacité qu'il aurait construite.
Le symptôme qu'il te manque ça : l'agent se contredit lui-même dans le même fil, ou il perd le fil dans les conversations longues. Ça se règle avec de la gestion de contexte (résumer les tours anciens), pas avec une base vectorielle.
2. La connaissance consultable (ça, c'est bien du RAG)
Tes documents, indexés de façon que l'agent puisse trouver le fragment pertinent et répondre avec lui sous les yeux. Manuels, politiques, contrats, procédures, catalogue, tickets résolus. C'est de la connaissance de l'organisation, la même pour tout le monde, et son problème n'est pas de se souvenir : c'est de trouver et d'être à jour. Ça vit dans un index — vectoriel, lexical ou les deux — et son coût principal n'est pas le stockage, c'est l'entretien : un index qui contient encore la procédure abrogée concurrence en silence celle qui est en vigueur.
Le symptôme qu'il te manque ça : l'agent répond avec aplomb des choses qui ne sont écrites nulle part, ou il cite le mauvais document. Ça se règle avec de la récupération, pas avec de la mémoire. Comment ça se monte et comment ça s'évalue, c'est dans entraîner un agent IA ; le garder vivant est un travail continu qui a son propre nom, maintenir à jour la connaissance de l'IA.
3. Les faits qu'il doit retenir d'une session à l'autre (mémoire à long terme)
Voilà la couche que presque personne ne construit, et c'est celle qui te manquait. Ce n'est pas de la documentation : ce sont des faits précis sur une personne, un compte ou un dossier, appris pendant le travail et qui doivent survivre à la fin de la conversation. « Ce client facture au nom d'une autre société. » « Ce fournisseur n'accepte pas les bons de livraison par mail. » « Cet utilisateur a déjà refusé cette proposition en mars, et il a dit pourquoi. »
Elle se distingue des deux autres par trois propriétés : elle est spécifique à une entité (elle ne vaut pas pour tout le monde), elle s'écrit toute seule pendant l'opération (personne ne charge un document avec ça dedans), et elle périme (une préférence change, une donnée cesse d'être vraie). C'est cette troisième propriété qui fait de la mémoire à long terme un problème de gouvernance et pas seulement d'ingénierie, et c'est le sujet de la seconde moitié de ce guide.
Où vit chacune et ce qu'elle coûte
| Couche | Où elle vit | Qui l'écrit | Ce qui la casse | Coût dominant |
|---|---|---|---|---|
| Contexte de la conversation | La fenêtre de contexte du modèle | La conversation elle-même | Fils longs : ça déborde ou ça devient cher | Tokens par tour |
| Connaissance consultable (RAG) | Index sur tes documents | Toi, au moment de publier le document | Contenu obsolète et doublons non marqués | Entretien de l'index |
| Mémoire à long terme | Entrepôt dédié, hors du modèle | L'agent, pendant l'opération | Faits périmés que personne ne retire | Gouvernance : revue et effacement |
Regarde bien la colonne de droite, parce que c'est celle qui n'apparaît jamais dans le budget. Les deux premières couches ont un coût qui se voit sur une facture. La troisième a un coût qui se voit en réunion : quelqu'un doit décider ce qu'on retient, pendant combien de temps et qui peut l'effacer. Si ce quelqu'un n'existe pas, la mémoire à long terme n'est pas une capacité : c'est un passif qui grossit tout seul.
Le test de trente secondes pour savoir laquelle te manque
Prends le cas concret qui t'a fait penser qu'il te manquait de la mémoire et pose-lui trois questions. La réponse te dit quoi acheter, et t'évite de payer une base vectorielle pour réparer un résumé de conversation.
- La donnée qui te manque est-elle écrite dans un de tes documents ? Si oui, ce n'est pas de la mémoire : c'est de la récupération. Ton problème est dans l'index ou dans le document, pas dans l'agent.
- La donnée vaut-elle pour tous tes clients ou seulement pour celui-là ? Si elle vaut pour tous, c'est de la connaissance. Si elle est de ce client et de personne d'autre, c'est de la mémoire à long terme.
- La donnée cesserait-elle d'être vraie d'ici un an ? Si la réponse est oui, tu as besoin de la couche d'oubli avant d'avoir besoin de celle du souvenir. Stocker sans plan de péremption, c'est accumuler des erreurs futures avec une date d'activation.
Oublier est plus difficile que retenir
C'est la partie que presque personne n'écrit, et celle qui coûte le plus cher. Construire de la mémoire est un problème résolu : tu stockes le fait, tu le récupères au bon moment. Le retirer, en revanche, n'est pas une opération : c'en est plusieurs, et il suffit qu'une seule échoue pour que la donnée reste vivante.
Le meilleur exemple public de l'embrouillamini vient de la documentation d'OpenAI pour ChatGPT elle-même. Son centre d'aide dit littéralement que, pour effacer complètement quelque chose que ChatGPT pourrait savoir de toi, il faut supprimer « chaque source où cela apparaît, y compris les conversations passées, les conversations archivées, les fichiers, le résumé de mémoire », et déconnecter les applications connectées susceptibles de contenir cette information. Et il ajoute deux avertissements qui valent leur pesant d'or pour quiconque conçoit ça dans son entreprise : supprimer une conversation ne supprime pas les mémoires qui en sont sorties, et si tu désactives la mémoire puis la réactives, le système peut recréer des mémoires à partir des conversations encore présentes dans ton historique. Source : Memory FAQ, OpenAI Help Center, consulté le 10 septembre 2026.
Ce n'est pas un défaut d'OpenAI : c'est la forme du problème. Dès qu'un fait est copié à plus d'un endroit — l'entrepôt de mémoire, l'index, le journal de la conversation, le système de destination où l'agent a écrit — l'effacement cesse d'être un bouton et devient une procédure avec une liste d'endroits. Si personne n'a écrit cette liste, tu ne peux promettre d'effacer quoi que ce soit.
Ce qui t'oblige à pouvoir effacer (et ce que personne ne te dit)
Trois ancrages, et il vaut mieux ne pas les mélanger. Le premier : le droit à l'effacement du RGPD s'exerce sur les données personnelles que tu traites, et la mémoire d'un agent en contient par construction — noms, préférences, incidents, décisions. Le deuxième : le Comité européen de la protection des données, dans son avis 28/2024 (17 décembre 2024), place la barre haut pour considérer comme anonyme un modèle entraîné sur des données personnelles et rappelle que, face à un traitement illicite, les autorités peuvent ordonner des mesures correctrices allant jusqu'à l'effacement du jeu de données. Cet avis parle du modèle ; ton entrepôt de mémoire est un cas bien plus simple et bien plus clairement identifiable, donc ce qui là-bas est discutable, ici ne l'est pas.
Le troisième est le plus opérationnel et il vient de chez toi. En juillet 2026, la CNIL et le Conseil de l'IA et du Numérique ont publié une note exploratoire sur l'IA agentique et la protection des données qui met la mémoire persistante au centre du problème : elle décrit comment la multiplication des espaces de mémoire disperse les données entre environnements de stockage et rend plus complexe de déterminer ce qui est effectivement conservé, quelles opérations peuvent l'affecter et pendant combien de temps ; elle prend l'exemple de l'utilisateur qui supprime un fichier sensible et n'a aucun moyen de s'assurer qu'il a bien disparu de toute la mémoire du système ; et elle recommande, parmi les mesures à intégrer dès la conception, le cloisonnement de la mémoire des agents pour éviter l'accumulation de données. Cloisonner, ça veut dire que la mémoire d'un client ne fuit pas dans la conversation d'un autre, et qu'elle peut se désigner et se retirer par morceaux. C'est la différence entre un entrepôt étiqueté et un tiroir en vrac. Source : IA agentique et données personnelles, CNIL et CIANum, 20 juillet 2026.
Ce qu'aucun des trois ne te dit : combien de temps ton agent doit se souvenir que ce client préfère qu'on l'appelle l'après-midi. Ça n'est écrit dans aucun texte. C'est une politique à toi, et si tu ne l'écris pas, la politique par défaut est « pour toujours », qui est la pire de toutes.
La fiche d'une page : ce qu'il retient, où et jusqu'à quand
Tout ce qui précède tient dans un tableau qu'on revoit chaque trimestre. Il n'en faut pas plus, et sans lui il n'y a aucune conversation possible avec ton délégué à la protection des données.
| Ce qui est retenu | Couche | Péremption | Où il faut l'effacer | Qui peut effacer |
|---|---|---|---|---|
| Préférence de contact du client | Mémoire long terme | 24 mois sans activité | Entrepôt + copie dans le CRM | Responsable du compte |
| Incident ouvert et son historique | Mémoire long terme | Clôture + rétention légale | Entrepôt + ticket + journal | Responsable du support |
| Procédure interne en vigueur | RAG | À la publication de la nouvelle version | Index (réindexer) | Propriétaire du document |
| Résumé du fil en cours | Contexte | Fin de la conversation | Ne persiste pas | — |
- Une ligne par type de donnée, pas par système. Si une ligne dit « données du client », elle est mal écrite : découpe-la jusqu'à ce que chaque ligne ait une péremption différente.
- La péremption, en unités. « Quand ça ne servira plus » n'est pas une péremption. « 24 mois sans activité », si, parce qu'un script peut l'appliquer.
- La colonne du où effacer est celle qui compte. C'est la liste d'endroits dont on parlait : si elle n'a qu'une seule entrée, elle est probablement incomplète.
- Un nom qui peut effacer. Une personne avec un vrai bouton, testé au moins une fois. Une procédure d'effacement que personne n'a jamais exécutée n'est pas une procédure.
- Revue trimestrielle avec le tableau sous les yeux. Ce qui s'accumule sans être revu cesse d'être de la mémoire et devient du sédiment.
Nous montons la couche de mémoire avec ce tableau écrit avant la première ligne de code : ça fait partie de l'infrastructure d'IA sur laquelle tournent les employés IA que nous mettons au travail, dans la logique générale de créer un agent IA qui tient en production. On ne vend pas de mémoire infinie. On facture le fait que ton agent retienne ce qu'il doit, pendant le temps qu'il doit, et que le jour où il faudra l'effacer, ça s'efface pour de bon.