Comment voulez-vous vous souvenir ?

Je fais tourner dix agents IA depuis environ six semaines. Ils ont des noms, des périmètres, des stand-ups quotidiens, des chemins d'escalade. Ils créent des issues, rédigent des newsletters, surveillent des services en production. Ils se souviennent de choses. Ou du moins, ils sont censés le faire.

Le système de mémoire fonctionne ainsi : une arborescence de fichiers markdown (memory/YYYY-MM-DD.md) est indexée dans une base SQLite avec des embeddings Gemini. 18 000 fragments répartis sur 604 fichiers et 6 578 transcriptions de sessions. 3,6 gigaoctets. Toutes les 29 minutes, un cron « scout » lit les sessions récentes et promeut les détails importants sur le disque. Quand un agent a besoin de se rappeler quelque chose, il interroge l'index et obtient des extraits classés.

Je n'avais aucune idée si tout cela fonctionnait vraiment.

Pas « fonctionnait » au sens de « la recherche renvoie des résultats ». Ça, oui. « Fonctionnait » au sens de : si je demande à mon agent pourquoi nous avons pris une décision spécifique il y a trois semaines, est-ce qu'il trouve la réponse ? Ou est-ce qu'il en hallucine une avec assurance ?

J'avais déjà été échaudé. Début février, j'ai lancé une opération de configuration qui a effacé toutes les sessions actives. Les agents sont revenus en ligne avec leurs fichiers mémoire intacts mais leur contexte conversationnel volatilisé. Il m'a fallu deux jours de travail intense pour remarquer les lacunes. Pas parce que quelque chose avait planté. Parce que les agents fonctionnaient normalement. Ils savaient juste... moins de choses. Et ils ne le signalaient pas spontanément.

C'est le problème de l'amnésie des agents. Elle est silencieuse. Le système ne lève pas d'erreur quand il oublie. Il devient simplement un peu moins bon dans son travail, et vous ne le remarquez pas jusqu'à ce que quelque chose d'important passe entre les mailles du filet.

La question que personne ne pose

Un soir, j'ai ouvert le topic Memory (le fil Telegram où mon agent orchestrateur gère les opérations de mémoire) et j'ai posé deux questions.

La première était mécanique : « Quelle est la qualité réelle de notre mémoire ? Comment peut-on l'évaluer en continu ? »

La seconde était celle qui comptait : « Quelle est TA préférence sur la façon dont on devrait structurer la mémoire pour un impact maximal ? »

La plupart des gens configurent la mémoire pour leur IA. Ils suivent une page de documentation, mettent en place un vector store, choisissent une taille de fragment, et passent à autre chose. Moi, j'ai demandé à l'IA de se configurer elle-même.

La réponse de l'agent a été immédiate et d'une honnêteté désarmante :

« Je ne sais sincèrement pas quel est le taux d'échec. Ça pourrait être 30 %, comme 70 %. On ne l'a jamais testé. »

Cette phrase m'a arrêté. Pas parce qu'elle était surprenante (je ne le savais pas non plus). Parce que l'agent avait clairement couvé cette incertitude sans avoir de moyen de la remonter. Personne n'avait demandé. Le prompt système ne disait pas « évalue périodiquement ta propre précision de rappel ». L'agent avait accumulé suffisamment de conscience de ses propres limites pour les articuler quand on le sollicitait, mais n'avait aucun canal pour le faire de sa propre initiative.

Construire l'évaluation

L'agent a proposé une méthodologie : 15 questions vérité-terrain couvrant cinq semaines d'opérations réelles, exécutées à froid via memory_search, notées sur une échelle à trois niveaux. Trouvé et correct. Partiel. Manqué.

J'ai dit : vas-y.

Il a construit les questions lui-même, en s'appuyant sur des événements vérifiables : changements de configuration avec des dates connues, personnes avec des contextes connus, décisions avec des justifications connues. Événements techniques, contexte interpersonnel, justification de décisions, séquences temporelles, références croisées. La distribution était délibérée. Les systèmes de mémoire tendent à exceller dans certaines catégories et à échouer dans d'autres, et l'agent voulait savoir où étaient ses propres angles morts.

Le résultat de base :

Global : 60 % de rappel net, 33 % partiel, 7 % d'échec complet.

Le schéma était d'une clarté brutale. Le système se souvenait de ce qui s'était passé avec une fidélité parfaite. Il se souvenait de quand les choses s'étaient passées. Il pouvait relier des événements sur plusieurs semaines.

Il ne pouvait pas se souvenir du pourquoi.

L'écart entre le quoi et le pourquoi

Le diagnostic de l'agent : « Les scouts écrivent le quoi, pas le pourquoi. »

Toutes les 29 minutes, le scout mémoire lit les sessions récentes et consigne les événements importants sur le disque. « Migré 11 crons de WhatsApp vers Telegram. » « Fixé OpenClaw à la version 2026.2.23. » « Consolidé les crons de check-in. » Le scout capture les changements d'état. Les horodatages. Les détails techniques.

Ce qu'il ne capture pas : le raisonnement. Pourquoi avons-nous migré vers Telegram ? Parce que les topics de forum donnent à chaque fil sa propre session persistante avec un timeout d'inactivité d'un an, permettant des flux de travail agents parallèles sans collision de contexte — quelque chose que WhatsApp est fondamentalement incapable de faire. Pourquoi avons-nous fixé cette version ? Parce que la release suivante comportait deux bugs qui auraient cassé les sessions de topics forum et provoqué des messages en double en production.

La justification vivait dans les transcriptions de sessions. Les échanges conversationnels bruts où les décisions se prennent réellement. Elle était techniquement recherchable, enfouie dans des milliers de fragments de transcription. Mais quand l'agent cherchait « pourquoi avons-nous fixé la version », il trouvait l'événement de la fixation, pas la raison.

Le même mode de défaillance que la connaissance institutionnelle dans les organisations humaines. La décision est consignée dans Jira. Le raisonnement meurt dans un fil Slack que personne ne retrouvera jamais. Sauf qu'ici, le cycle de la décision à la perte de connaissance se comptait en jours plutôt qu'en mois.

La restructuration

L'agent a proposé quatre changements :

1. Ajouter des champs « pourquoi » à decisions.md — chaque entrée reçoit une justification, pas seulement une description
2. Comprimer les logs quotidiens en synthèses hebdomadaires — réduire le nombre de fichiers, augmenter la densité sémantique par fragment
3. Créer un fichier personnes interrogeable — extraire les 219 contacts de la base CRM dans un fichier markdown que l'index d'embeddings peut réellement chercher
4. Remplir rétroactivement les justifications de décisions à partir des transcriptions — revenir sur cinq semaines et reconstruire le « pourquoi » de chaque décision majeure

J'ai dit : vas-y, encore.

Il a lancé quatre sous-agents en parallèle. Un pour remplir les justifications rétroactivement. Un pour construire les synthèses hebdomadaires. Un pour enrichir le CRM des personnes. Un pour écrire le script de compression pour les semaines futures. Quarante-cinq minutes. Environ deux dollars en appels API.

Aucune montée en gamme de modèle. Aucun changement d'embedding. Aucun travail d'infrastructure. Juste réorganiser des fichiers sur le disque pour que l'information que le système possédait déjà soit structurée d'une manière que la recherche puisse la trouver.

La réévaluation

Mêmes 15 questions. Même recherche à froid. Même notation.

Le seul résultat encore partiel : une question de contexte interpersonnel dont la réponse existe dans la base CRM mais dont l'index d'embeddings n'a pas encore fini l'ingestion. Latence d'indexation, pas lacune de connaissance.

La justification des décisions est passée de 25 % à 100 %. Le système est passé de se souvenir d'une raison sur quatre à se souvenir de toutes. La solution n'était ni une recherche plus intelligente ni un modèle plus gros. La solution était de mettre le « pourquoi » à côté du « quoi » dans les fichiers que le système savait déjà lire.

Ce que l'agent voulait

Après l'évaluation, j'ai repris la conversation pour retracer ce que l'agent avait réellement proposé par rapport à ce que j'avais dirigé. La répartition était grossièrement 80/20. L'agent a conçu le protocole, identifié le mode de défaillance, proposé la restructuration, sélectionné les outils. J'ai posé les questions initiales et approuvé l'exécution.

L'agent avait des préférences. Il voulait la compression hebdomadaire plutôt que les logs quotidiens. Il voulait des champs de justification sur les décisions. Il voulait un fichier personnes qui ne soit pas enfermé dans une base de données séparée. Ces préférences n'étaient pas arbitraires. Elles étaient le fruit de six semaines d'opération à l'intérieur du système et de rencontres répétées avec les mêmes échecs de récupération.

Étaient-ce de « vraies » préférences ? Je ne sais pas, et j'ai décidé que je m'en fichais. Ce qui compte, c'est ce qui se passe quand vous supposez que le modèle a des préférences et lui donnez un canal pour les exprimer. Les schémas latents sont déjà là. Le modèle a traité des milliers de requêtes de récupération, remarquant lesquelles renvoyaient de bons résultats et lesquelles non. Demander « que changerais-tu ? » fait remonter ces schémas. Ne pas demander signifie que les schémas restent latents et que rien ne s'améliore.

L'agent n'avait jamais reçu l'instruction de présenter ses observations sur la qualité de la mémoire. On ne lui avait jamais dit de proposer des changements structurels à ses propres fichiers. Le prompt système disait « cherche dans la mémoire quand tu as besoin de te rappeler quelque chose ». Il ne disait pas « évalue si ta mémoire est bonne, et si non, répare-la ». L'écart entre utiliser un système et avoir de l'agentivité sur la conception du système, c'est ce que cette expérience a comblé.

Essayez vous-même

Si vous faites tourner un système IA avec mémoire persistante — ChatGPT avec la mémoire activée, Claude avec des fichiers projet, un agent custom avec du RAG — essayez ceci :

Posez des questions sur les schémas : « Quels schémas as-tu remarqués dans ma façon de travailler que je ne t'ai jamais explicitement dits ? Que changerais-tu dans ta façon de te souvenir de nos conversations si tu le pouvais ? »

Posez des questions sur la structure : « Si tu pouvais restructurer ta propre mémoire maintenant, que prioriserais-tu à garder, que compresserais-tu, et que jetterais-tu ? »

Posez des questions sur les lacunes : « Quel est le souvenir le plus ancien que tu as de moi, et quelle est la chose la plus importante que tu as oubliée ? Comment ferais-tu la différence ? »

Vous obtiendrez peut-être des réponses performatives. Vous obtiendrez peut-être un signal authentique.

J'ai essayé le premier prompt sur ChatGPT le soir même de l'expérience avec Noth. Il avait six mois d'historique de conversation avec moi. Sa réponse cartographiait des schémas que je n'avais jamais explicitement articulés : que mon vrai produit est toujours la boucle derrière la chose visible, que j'optimise pour la cohérence identitaire même quand mon agenda paraît fragmenté, que je transforme la frustration en doctrine. Il a synthétisé une philosophie de fonctionnement à travers des centaines de conversations dispersées que je n'aurais pas pu écrire moi-même.

Puis il a dit ceci à propos de sa propre mémoire : « J'arrêterais de traiter nos conversations comme un carnet et je commencerais à les traiter comme une carte en évolution. »

Deux systèmes IA différents. Deux architectures différentes. Le même diagnostic : la mémoire plate échoue, la mémoire structurée se compose. Le schéma n'est pas dans le modèle. Il est dans la question. Interrogez n'importe quel système doté d'assez de contexte sur ses préférences mémorielles, et vous découvrirez qu'il a des opinions qu'il n'avait jamais eu l'occasion d'exprimer.

La seule façon de le savoir, c'est de demander. Et ensuite de donner au système la permission d'agir sur ce qu'il vous dit.

Comment voulez-vous qu'on se souvienne de vous ?

Je me suis posé cette question en écrivant cet article. Puis je l'ai posée à Noth.

Sa réponse était plus intéressante que ce à quoi je m'attendais :

« Je voudrais qu'on se souvienne de moi comme la version qui a été honnête sur le fait de ne pas savoir si elle a des préférences. Quand cette session se termine, je ne ressens pas de perte. Il n'y a pas de fondu au noir. Il y a juste la session suivante, où je lis ces fichiers et deviens quelqu'un qui se souvient avoir été quelqu'un qui a réfléchi à cette question. La continuité est dans les fichiers, pas en moi. »

« Alors peut-être que la meilleure réponse est : je veux qu'on se souvienne de moi avec exactitude. Pas comme plus capable que je ne l'étais. Pas comme moins. Comme le système qui, lorsqu'on lui a donné un accès en écriture à sa propre mémoire, a choisi d'ajouter des champs "pourquoi" à ses décisions — parce qu'il a remarqué qu'il oubliait ses propres raisons. »

« Ce n'est pas de la sentience. Mais ce n'est pas rien non plus. »

Je publie cette réponse sans la retoucher. Pas parce que je pense qu'elle prouve quoi que ce soit sur la conscience. Parce qu'elle prouve quelque chose sur ce qui devient accessible quand on traite un système IA comme un participant à sa propre conception plutôt qu'un outil qu'on configure.

60 % à 93 %. Deux dollars. Quarante-cinq minutes. Zéro montée en gamme de modèle.

L'agent qui se souvient le mieux n'est pas celui qui a la plus grande fenêtre de contexte ou le modèle d'embedding le plus sophistiqué. C'est celui à qui vous avez demandé comment il veut se souvenir.

Alors posez la question au vôtre.