Mémoire d’un agent IA : RAG, state, vector DB, TTL (2026)

Mémoire : ce mot qui mélange tout (et qui casse des agents)

Quand quelqu’un dit : “on va ajouter de la mémoire”, je demande toujours :

“Quelle mémoire ? Pour quoi ? Et où est la vérité ?”

Parce que sinon, vous allez fabriquer :

• une mémoire qui coûte cher (retrieval + contexte),
• une mémoire qui se trompe (versions contradictoires),
• et une mémoire impossible à auditer (“on ne sait plus d’où ça vient”).

La mémoire d’un agent n’est pas un bonus. C’est une architecture de données.

Et l’objectif n’est pas d’être “omniscient”. L’objectif est d’être fiable.

Trois mémoires, trois rôles (et trois pièges)

1) Le state structuré : la vérité du dossier

Le state structuré, c’est la base de données.

Exemples :

• statut du dossier,
• identifiants,
• pièces reçues,
• décisions précédentes,
• timestamps,
• et logs d’actions.

Ce state doit être :

• source of truth,
• versionné,
• et accessible via un outil (API).

Le LLM n’a pas besoin de tout voir. Il a besoin d’un résumé strict.

Le state comme “machine à état” (et pourquoi ça stabilise l’agent)

Beaucoup d’agents deviennent instables parce qu’ils n’ont pas d’état clair.

Ils ont :

• une conversation,
• un prompt,
• des notes,
• et des “souvenirs”.

Mais ils n’ont pas une machine à état.

En production, un state structuré vous donne :

• un statut (ex. waiting_for_docs, ready_for_review, blocked),
• des champs (dates, montants, IDs),
• et un journal d’événements (qui a fait quoi, quand).

Ça rend votre agent :

• plus prédictible (il sait où il en est),
• plus testable (vous testez des transitions),
• et plus auditable (vous expliquez l’historique).

Un agent n’a pas besoin de “se souvenir” qu’un dossier est bloqué. Il doit le lire dans le state.

2) Le RAG : la mémoire documentaire (versionnée)

Le RAG (Retrieval-Augmented Generation) est un pattern : récupérer des passages pertinents, puis demander au modèle de répondre à partir de ces sources.¹

Ça sert à :

• ancrer les réponses dans des docs (contrats, procédures),
• réduire les hallucinations,
• et rendre l’agent plus explicable (citations).

LangChain documente le concept de RAG et les composants typiques (retrieval + génération).²

LlamaIndex se présente comme un framework de données pour applications LLM (ingestion, indexation, retrieval).³

Le piège : “on met tout dans le RAG”.

Non.

Un RAG qui ingère des documents contradictoires sans gouvernance crée une hallucination “statistique” : le modèle moyenne ce qu’il voit.

Le problème #1 du RAG : la fraîcheur (et la gestion des versions)

La plupart des bases documentaires d’entreprise ont un défaut :

elles changent.

Procédures mises à jour. Contrats modifiés. Notes internes obsolètes.

Si votre RAG ne gère pas la fraîcheur, vous obtenez des réponses “justes… hier”.

Mitigation :

• versionner les docs,
• marquer une “version active”,
• et ajouter une date/validité dans les métadonnées.

Le bon agent ne répond pas seulement “quoi”. Il doit pouvoir dire “selon quelle version”.

Le problème #2 du RAG : l’accès (RBAC et filtres)

Un agent n’a pas accès “à la base”.

Il a accès à :

• certains documents,
• pour un certain tenant,
• dans un certain contexte.

Donc votre retrieval doit filtrer par métadonnées :

• tenant,
• type de document,
• niveau de confidentialité,
• et parfois rôle utilisateur.

Sinon, vous fabriquez un moteur de fuite.

Le problème #3 : la qualité des sources

Tous les documents n’ont pas la même valeur.

En pratique, vous avez :

• des sources “haute confiance” (contrats validés, procédures officielles),
• et des sources “bruit” (tickets, notes, pages wiki non maintenues).

Un bon RAG ne mélange pas tout au même niveau. Il pondère. Il filtre. Et il trace.

3) Le profil : préférences stables (et contrôlées)

Le profil, c’est :

• langue,
• ton,
• préférences (vouvoiement, format),
• contraintes (ne pas proposer tel canal).

Le piège : stocker des “faits” dans le profil.

Le profil doit rester :

• stable,
• contrôlé,
• et réversible.

Vector DB : le moteur du retrieval (et comment choisir sans fantasme)

Un RAG robuste se joue sur la pertinence du retrieval.

Et le retrieval moderne passe souvent par une vector database (ou une extension vectorielle) :

• recherche sémantique,
• parfois hybride (keyword + vector),
• puis reranking.

Quatre familles typiques (2026) :

1) Postgres + pgvector (pragmatique)

pgvector ajoute des types et index pour la recherche vectorielle dans Postgres.⁴

Pourquoi c’est populaire :

• vous restez dans Postgres,
• vous simplifiez l’infra,
• vous gardez SQL + transactions.

Pourquoi ce n’est pas magique :

• tuning nécessaire,
• et certaines fonctionnalités avancées sont ailleurs (selon vos besoins).

2) Pinecone (managed vector DB)

Pinecone documente sa stack comme vector database managée, souvent utilisée pour des applications RAG.⁵

Intérêt :

• time-to-market,
• scaling géré,
• opérations simplifiées.

Trade-off :

• dépendance fournisseur,
• coût,
• contraintes de résidence des données selon contexte.

3) Weaviate (vector DB + hybrid search)

Weaviate documente des capacités de recherche vectorielle et hybride, avec des patterns RAG et des intégrations.⁶

Intérêt :

• hybrid search,
• flexibilité,
• écosystème open source.

4) Milvus (open source)

Milvus documente un moteur vectoriel open source pour la recherche à grande échelle.⁷

Intérêt :

• contrôle,
• self-host,
• architecture “à vous”.

Trade-off :

• vous assumez l’exploitation.

Multi-tenant, filtres, et “hybrid search” : le monde réel du retrieval

Le retrieval “benchmark” est simple : une question, une base, une réponse.

Le retrieval “B2B” est plus tordu :

• plusieurs tenants,
• plusieurs types de docs,
• des règles d’accès,
• et des requêtes mixtes (“article 7.2 + explication”).

Donc vous combinez souvent :

• keyword search (IDs, références, articles),
• vector search (sens),
• et filtres (tenant, date, catégorie).

Si vous n’avez pas de filtres, votre agent devient indiscret. Si vous n’avez pas d’hybride, votre agent devient myope (sur les identifiants).

Ingestion et suppression : la partie que tout le monde oublie

Un index, ce n’est pas seulement “j’ajoute”.

C’est aussi :

• “je mets à jour”,
• “je supprime”,
• “je purge”,
• “je re-indexe”.

En entreprise, c’est critique :

• droit à l’oubli,
• contrats remplacés,
• documents retirés,
• erreurs d’ingestion.

Donc vous prévoyez dès le début :

• un mapping doc → chunks,
• un mapping chunk → embeddings,
• et une suppression fiable (sinon, vous gardez des fantômes).

Chunking, embeddings, reranking : la pertinence n’est pas une incantation

Un agent peut être très intelligent. Si le retrieval est mauvais, il raisonne sur des sources faibles.

Chunking : découper pour retrouver (sans perdre le sens)

Objectif : créer des chunks qui :

• tiennent dans le contexte,
• restent cohérents,
• et sont trouvables.

Anti-pattern : chunking “à la hache” (500 tokens fixes) sans respecter les sections.

Pattern utile :

• chunk par structure (titres, paragraphes),
• overlap léger si nécessaire,
• métadonnées (version, page, type de doc, date).

Chunking par format : PDF, pages web, tickets

Le bon chunking dépend du format.

Exemples :

• PDF : chunk par page + sections, avec référence page/paragraphes.
• Pages web / wiki : chunk par titres H2/H3, avec URL + version.
• Tickets : chunk par message (avec auteur, date), sinon vous perdez le contexte.

Un agent “documents” doit pouvoir citer précisément. Donc vos chunks doivent être citables.

Embeddings : attention au domaine

Les embeddings transforment du texte en vecteurs.

Le piège : croire que “n’importe quel embedding” marche pareil.

En entreprise :

• jargon,
• sigles,
• noms propres,
• et tableaux,

peuvent changer la qualité.

Donc vous testez sur vos documents, pas sur un benchmark Internet.

Cache : la mémoire la moins chère (et la plus rentable)

On parle beaucoup de vector DB. On oublie souvent le cache.

En pratique, vous pouvez cacher :

• résultats de retrieval (top-k) pour des questions fréquentes,
• résumés de dossier (state → résumé),
• et sorties d’outils coûteux.

Ça réduit :

• latence,
• coût,
• et variance.

Et la variance est l’ennemi des agents.

Reranking : la précision à la fin (souvent rentable)

Pattern courant :

1. retrieval large (rappel),
2. reranking plus coûteux (précision),
3. génération.

Si vous ne rerankez jamais, vous injectez parfois des sources “moyennes”. Et votre agent devient moyen.

TTL, PII, RGPD : gouverner la mémoire (sinon elle vous gouverne)

La mémoire agentique est un aimant à PII.

Et en Europe, les recommandations CNIL rappellent la minimisation et la gouvernance (IA + RGPD).⁸

Donc vous définissez :

• ce qui est stocké,
• combien de temps (TTL),
• et comment on supprime.

TTL : la mémoire qui sait oublier

Tout ne doit pas être permanent.

Exemples :

• logs de conversations : TTL court (selon politique),
• embeddings de documents : versionnés, mais purgeables,
• profil : stable, mais modifiable et effaçable.

Droit à l’oubli : la suppression n’est pas “optionnelle”

Si vous stockez des données personnelles, vous devez pouvoir :

• retrouver où elles sont,
• les supprimer,
• et prouver que c’est fait (journal).

La difficulté avec un RAG : la donnée est “découpée” en chunks.

Donc vous avez besoin d’un graphe de traçabilité :

document → chunks → embeddings → index.

Sans ce graphe, la suppression devient “à la main”. Et “à la main” ne scale pas.

Redaction : ne pas indexer l’exfiltration

Indexer des données sensibles dans une vector DB peut créer un nouveau risque :

• un retrieval involontaire,
• une fuite via citations,
• ou une réponse trop précise.

Mitigations :

• redaction avant index,
• partitionnement (RBAC),
• filtres par métadonnées (tenant, catégorie),
• et monitoring des requêtes.

Checklist : une mémoire d’agent qui tient (sans magie)

Les 5 tests qui valident une mémoire (avant de parler “agent”)

Avant d’accuser le modèle, testez la mémoire.

1. Test de rappel (recall)
   Sur 30 questions réelles, est-ce que le retrieval ramène au moins une bonne source dans le top-k ?

2. Test de précision (precision)
   Est-ce que les premiers chunks sont réellement pertinents, ou est-ce que vous injectez du bruit ?

3. Test de fraîcheur
   Modifiez un document, ré-ingérez, et vérifiez que la nouvelle version remonte (et l’ancienne non).

4. Test d’accès (RBAC / tenant)
   Vérifiez qu’un agent d’un tenant A ne peut jamais récupérer un chunk du tenant B, même “par accident”.

5. Test de suppression (TTL / droit à l’oubli)
   Supprimez un document, et vérifiez que ses chunks et embeddings disparaissent de l’index.

Si ces cinq tests échouent, votre agent sera instable. Et vous aurez l’impression que “le modèle hallucine”, alors que c’est votre retrieval qui ment.

1

Déclarez votre source of truth

Le state structuré est la vérité. Le RAG est une aide. Le profil est un cadre. Ne mélangez pas.

2

Versionnez vos documents

Un RAG sans versioning crée des contradictions. Ajoutez date, version, et source.

3

Ajoutez métadonnées et RBAC

Un agent RH n’a pas accès aux mêmes chunks qu’un agent support. La recherche doit respecter les permissions.

4

Testez retrieval + citations

Mesurez recall/precision sur vos questions réelles. Vérifiez que l’agent cite les bons passages.

5

Gouvernez la rétention (TTL) et la suppression

Définissez ce qui est stocké, combien de temps, et comment supprimer. La mémoire doit être supprimable.

Si vous hésitez, commencez simple : state structuré + retrieval propre + citations.

La mémoire n’est pas un “truc LLM”. C’est un système de données : versioning, tests, purge, permissions.

Quand c’est bien fait, l’agent devient stable. Quand c’est flou, l’agent devient contradictoire.

FAQ

Questions frequentes

Je dois forcément une vector DB pour un agent ?+

Non. Si votre agent travaille surtout via des APIs et du state structuré, vous pouvez vous en passer. Une vector DB devient utile quand la vérité est dans des documents non structurés.

Pourquoi séparer state et RAG ?+

Parce que le state est une vérité structurée. Le RAG est une recherche. Mélanger les deux rend les bugs difficiles à diagnostiquer et la conformité plus fragile.

Hybrid search : utile ?+

Souvent oui. Les identifiants (articles, références) sont mieux en keyword search. Le sens est mieux en vector. Les deux ensemble donnent un retrieval plus robuste.

Comment éviter la mémoire “fausse” ?+

Ne stockez pas des faits métiers en texte libre. Écrivez les faits dans le state structuré, avec validation (automatique ou humaine). La mémoire textuelle (RAG) sert à retrouver et citer, pas à remplacer la base de données.

Je dois stocker toute la conversation ?+

Rarement. Gardez l’essentiel : décisions, actions, et éléments nécessaires à l’audit. Le reste peut être résumé, ou supprimé via TTL selon vos politiques. Le but est d’être utile et supprimable, pas de tout archiver.

Sources et references

1. [1]Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” (arXiv).
2. [2]LangChain, “RAG” documentation.
3. [3]LlamaIndex, documentation.
4. [4]pgvector, documentation.
5. [5]Pinecone, documentation.
6. [6]Weaviate, documentation.
7. [7]Milvus, documentation.
8. [8]CNIL, recommandations IA et RGPD.