Mémoire d’agent : un mot, plusieurs mécanismes
Publié le · mis à jour le
Un appel d’API sans état part de rien : il ignore votre identité, l’activité de votre entreprise et vos décisions du mois dernier. Certains produits de conversation ajoutent déjà l’historique, des résumés ou une mémoire ; nommez donc le produit et son mode de configuration avant d’en parler. Cette absence de continuité n’est pas un défaut du modèle, c’est un choix d’architecture. Le sujet a beaucoup occupé l’année 2026, et le mot mémoire recouvre désormais quatre mécanismes dont aucun ne remplace les autres. Les distinguer vient avant le choix d’un outil.
Les quatre mémoires que le mot recouvre
Le wiki compilé
Des connaissances du domaine, lisibles par un humain, versionnées dans un dépôt Git. Sa première qualité n’est pas technique : un collaborateur qui a les droits d’accès ouvre le wiki, le corrige et le relit avant un audit. C’est souvent la couche la plus simple à expliquer, pour autant que les autorisations Git et les approbations soient elles-mêmes tenues, journaux compris.
L’outil de mémoire
Anthropic propose un outil de mémoire par lequel le modèle demande à lire et à écrire. Le stockage, lui, reste chez vous : /memories est une convention que votre application relie à son propre stockage. C’est votre code qui exécute les opérations et qui les autorise, ce qui fait à la fois l’avantage et la charge.
L’édition de contexte et la compaction
Beaucoup confondent les deux. L’édition de contexte supprime ou réduit certains résultats d’outils, selon les règles que vous fixez. La compaction résume l’état de la conversation quand la plateforme est réglée pour le faire. Toutes deux gèrent la fenêtre de travail ; aucune ne fournit à elle seule une mémoire durable d’une session à l’autre.
Les mémoires gérées
Certaines plateformes proposent des mémoires partagées entre sessions et entre agents, avec des espaces de noms, des versions et des règles de contrôle. Ces fonctions n’ont rien d’universel. Vérifiez qui peut écrire, comment l’historique est conservé, si les versions se réécrivent, et quelles traces relient un changement à une identité et à une source.
Les mots exacts de Karpathy
Le 3 avril 2026, Andrej Karpathy a publié un gist d’environ 1 500 mots décrivant un modèle qu’il appelle le LLM Wiki. Trois couches : des sources brutes immuables, un wiki de fichiers Markdown dont le modèle a entièrement la charge, un schéma qui dit comment le wiki est rangé. Trois opérations : importer les sources, chercher, et vérifier que l’ensemble tient debout.
Dans ce schéma, le modèle fabrique le wiki à partir des sources et l’entretient, pendant que les personnes choisissent les sources, la structure et les questions. Pour un usage en entreprise, j’ajouterais une étape : le modèle propose les changements, un responsable les valide. Laisser tourner le compilateur ne doit pas effacer l’autorité éditoriale.
L’identité n’est pas la mémoire
La confusion la plus coûteuse ne porte pas sur le type de mémoire, mais sur ce que vous y rangez. Le fichier d’identité dit qui est l’agent, ce qu’il fait, ce qu’il ne fera jamais. Il change rarement, et seulement quand un humain le décide. La mémoire, elle, est faite pour bouger. Tant que les deux restent séparés, un fait ponctuel ne peut pas réécrire le mandat de l’agent. Fusionnés, une note mal enregistrée un mardi redéfinit sa mission pour six mois, sans que rien ne signale le changement.
Le contenu à ne jamais écrire dans une mémoire
Une mémoire persistante se liste, puis se récupère au fil des sessions suivantes ; vous n’avez pas à l’injecter en bloc. Chaque élément rappelé influence l’agent. D’où trois exclusions simples :
- aucun mot de passe, jeton ni clé d’accès ; passez par un coffre à secrets
- aucune donnée personnelle dont la tâche n’a pas besoin
- rien de ce que le dépôt de code ou le système métier documente déjà
La deuxième ligne porte le poids juridique : une mémoire qui garde un dossier d’habitant ou le salaire d’un collaborateur traite des données personnelles, avec la finalité, la durée de conservation et le droit d’accès qui vont avec. Pour une commune, le régime est cantonal, un sujet développé ici.
La mémoire d’agent ajoute un risque : un document ou un message peut chercher à s’y glisser sous forme d’instruction. Chaque nouvel élément arrive donc avec une source, un auteur, une date, un niveau de confiance et un état d’approbation. Et un contenu venu d’une source non fiable ne touche jamais à l’identité, aux autorisations ni aux règles de sécurité de l’agent.
Faire vivre une mémoire
Je m’en tiens à trois règles d’exploitation, qui portent sur le rythme plutôt que sur les outils :
- une seule collecte : tout passe par un dossier d’entrée unique ; le modèle propose un emplacement, un responsable approuve selon le risque
- traitement planifié : l’import et la vérification tournent à heures fixes ; une mémoire dont l’entretien dépend d’une décision humaine quotidienne ne sera pas entretenue
- chaque nouvelle page cite l’ancienne : un graphe dont les fichiers grossissent pendant que les liens restent plats décrit un entrepôt, pas une mémoire
La moitié difficile du travail consiste à oublier. Une mémoire sans date de révision accumule des notes périmées, et le nombre de fichiers qui monte lui donne l’air d’être en bonne santé. Quand un fait change, n’écrasez pas l’ancien : écrivez le nouveau et marquez le précédent comme remplacé, pour qu’une croyance fausse reste traçable jusqu’à sa source. Les données personnelles doivent en outre rester corrigibles et supprimables dans les index, les caches et les sauvegardes qui en gardent une copie. Et quand deux sources se contredisent, c’est un responsable qui tranche.
Le coût
L’argument commercial le plus courant est le nombre de tokens économisés, ces fragments de texte facturés par le modèle : un document compilé une fois coûte moins cher à servir que le même document relu à chaque question. C’est vrai, avec une réserve qui commande tout le calcul : le cache de préfixe fonctionne par correspondance exacte, si bien qu’une mémoire réécrite à chaque tour coûte plus cher qu’une mémoire stable, à contenu égal. Les autres leviers sur la facture d’IA sont présentés dans un autre article.
Cinq contrôles avant la mise en service
- Qui écrit dans cette mémoire ?
- Comment tranchez-vous entre deux pages contradictoires ?
- Quelles données personnelles y entrent, et pour combien de temps ?
- Qui peut lire quoi ?
- Comment en sortez-vous ?
La cinquième question explique le schéma de Karpathy, qui ne dépend d’aucune technologie : vous lisez un texte brut versionné sans logiciel particulier, vous le corrigez directement, et il survit à un changement de fournisseur.
Ajoutez cinq contrôles : l’origine de chaque information, la validation des mises à jour à fort impact, la protection contre une instruction malveillante cachée dans un document et gardée en mémoire, une date d’expiration ou de révision, et une procédure testée pour corriger ou supprimer l’information dans toutes ses copies.
Le cycle de vie
Une mémoire saine traverse des états visibles : proposé → validé → disponible pour les rôles autorisés → révisé ou expiré → corrigé ou supprimé. La traçabilité, la classification et la règle d’accès suivent l’élément d’un bout à l’autre. Un stockage qui sait seulement lire et écrire n’est pas prêt pour l’entreprise.
La provenance de cette grille
Ces quatre mécanismes forment une classification utile, non une terminologie partagée par tous les fournisseurs. Vérifiez le stockage, les versions, l’accès et la suppression dans la plateforme que vous utilisez vraiment.
J’ai revu les quatre mécanismes le 14 août 2026.