Ton IA se souvient de ce que tu as dit, et oublie ce qu’elle a fait.

2026-07-16 · 5 min de lecture · par Nabil BA-MOH

Nous avons ouvert un rapport de bug en amont. Quelques jours plus tard, nous avons posé une question simple à notre assistant : « est-ce qu’Anthropic a corrigé le bug que nous avons signalé ? » Sa mémoire (une recherche sémantique sur toutes les conversations que nous avions jamais eues avec lui) n’a pas pu retrouver le signalement. Une seule ligne gh issue list --author a répondu tout de suite. L’assistant avait fait le travail et ne se souvenait pas de l’avoir fait.

Cet échec n’est pas un hasard. Il est structurel, il touche la plupart des systèmes de mémoire IA construits en ce moment, et il a une solution propre. Voici les deux, tirés de nos propres logs, juillet 2026.

Pourquoi la mémoire l’a raté

Une mémoire basée sur les transcriptions indexe ce qui a été dit. Mais le fait durable de cette session (le numéro de l’issue, l’URL, le dépôt) n’a jamais été dit. Il est né dans un résultat d’outil : la sortie de la commande qui a créé l’issue. Les résultats d’outils défilent comme du bruit structuré ; personne ne les reformule en phrases. Donc le seul fait qui valait la peine d’être gardé n’est jamais entré dans le corpus où la mémoire cherche.

Généralise, et tu retrouves ce schéma partout : URL d’issues créées, numéros de PR, identifiants de documents publiés, identifiants de paiements. Les faits qu’on a le plus besoin de retrouver plus tard sont justement ceux qui n’apparaissent que dans la sortie des outils, la partie de la session où la mémoire par transcription est la plus mauvaise.

Les mots, on s’en souvient. Les actions, on les oublie. Et les faits les plus précieux de ton assistant naissent dans des actions.

La solution : journaliser les actions au moment où elles se produisent

La solution que nous avons livrée est volontairement ennuyeuse : déterministe, pas maligne. Un hook post-outil surveille les résultats d’outils à leur retour. Quand il reconnaît une action importante (une issue créée, une PR ouverte, une release publiée), il extrait l’identifiant du résultat d’outil et ajoute une ligne à une note de journal :

date · action · repo · url · title

Le journal est une note ordinaire, que le système de mémoire indexe comme n’importe quelle autre. Cette seule propriété change la garantie : les faits deviennent retrouvables par construction. Aucune discipline du modèle requise, pas besoin d’espérer que l’assistant pense à noter les choses, pas de résumé en prose qui pourrait oublier l’URL. Le hook se déclenche, la ligne s’écrit, le fait est trouvable.

Demande maintenant « est-ce qu’Anthropic a corrigé le bug que nous avons signalé ? » et la ligne du journal amène l’URL de l’issue directement dans le rappel. Et l’URL mène à la réponse à jour.

La doctrine derrière

Trois principes en découlent, et ils valent au-delà de notre stack :

Les systèmes externes restent la source de vérité. GitHub connaît l’état réel de l’issue ; Stripe connaît l’état réel du paiement. La mémoire ne doit jamais essayer d’en faire une copie : une copie est périmée dès qu’elle est faite.
La mémoire garde le pointeur qui y mène. La ligne du journal ne stocke pas le statut du bug. Elle stocke de quoi le retrouver : l’URL, la date, une ligne de contexte. Rappelle le pointeur, suis-le, obtiens la vérité actuelle.
Trier vaut mieux que tout capturer. Un fait trié d’une ligne vaut plus que mille lignes de transcription. Capturer plus ne fait pas une meilleure mémoire ; mieux choisir, si.

Si tu construis la mémoire d’un agent, la liste est courte : surveille les résultats d’outils, pas seulement les mots ; écris des pointeurs, pas des copies ; et rends l’écriture déterministe, parce que les faits qui comptent le plus sont ceux que personne ne pense à mentionner.

Pour nous, ce n’est pas un détail. Le journal d’actions est livré avec Klyr, qui donne à ton IA une mémoire persistante. Les conversations de ton assistant sont consultables, et ce qu’il a vraiment fait aussi : chaque issue, PR et document qu’il a touché, un pointeur par action, retrouvable des mois plus tard. Si tu préfères avoir ça plutôt que le construire, les offres individuelle et équipe sont sur la page d’accueil.

Côté mots de la mémoire, lis l’article sur le seuil d’auto-compaction : la compaction, c’est là où la mémoire par transcription va mourir.

FAQ

Pourquoi mon assistant IA ne se souvient-il pas de ce qu’il a fait, seulement de ce dont nous avons parlé ?

Parce qu’une mémoire basée sur les transcriptions indexe de la prose, et que les faits créés par des actions (URL d’issues, numéros de PR, identifiants de documents) n’apparaissent que dans des résultats d’outils que personne ne reformule en prose. Le fait naît en dehors du corpus où la mémoire cherche.

Qu’est-ce que le pattern du journal d’actions ?

Un hook post-outil déterministe qui reconnaît les actions importantes dans les résultats d’outils (issue créée, PR ouverte, release publiée), extrait l’identifiant et ajoute une ligne de pointeur (date, action, dépôt, URL, titre) à une note que le système de mémoire indexe. Les faits deviennent retrouvables par construction.

Pourquoi stocker des pointeurs plutôt que les faits eux-mêmes ?

Parce que les systèmes externes sont la source de vérité et que les copies se périment. Le journal stocke de quoi retrouver l’enregistrement à jour (l’URL et une ligne de contexte), donc le rappel t’envoie vers l’état actuel au lieu d’un instantané.

Capturer plus de conversation, est-ce une meilleure mémoire ?

Non. Trier vaut mieux que tout capturer : un fait trié d’une ligne vaut plus que mille lignes de transcription. Le but, c’est de choisir, pas d’accumuler.

Est-ce qu’il faut un modèle plus intelligent ?

Non, et c’est tout l’intérêt. Le journal est écrit par un hook déterministe, pas par le modèle qui déciderait de prendre des notes. Ça marche même quand le modèle ne pense jamais à mentionner ce qu’il a fait.