À retenir
- Le goulot d’étranglement n’est pas de donner plus d’information au modèle une fois. C’est de rendre l’information utile de nouveau accessible plus tard.
- La mémoire d’un agent fonctionne mieux sous forme de fichiers et de références externes que comme un seul prompt géant collé dans chaque session.
- Un OS de recherche pratique donne aux agents une structure qu’ils peuvent inspecter, interroger et mettre à jour sans reconstruire le contexte à partir de zéro.
La plupart des workflows d’agents ont encore le même problème agaçant.
Vous apprenez quelque chose d’utile à l’agent, ça fonctionne bien pendant une session, puis la fois suivante, vous repartez de zéro.
Les mêmes liens.
Les mêmes PDFs.
Les mêmes notes.
Les mêmes explications.
Le même « s’il vous plaît, souvenez-vous de mon style et de mes contraintes ».
Très productif. Très 2026. haha.
C’est le problème sur lequel Paul Iusztin et moi nous sommes concentrés dans notre conférence du Online Track de l’AI Engineer World’s Fair, qui a été sélectionnée comme keynote. Une super belle surprise, mais surtout, je pense que le sujet est l’une des choses les plus utiles que les ingénieurs IA doivent comprendre en ce moment.
Vous pouvez regarder la keynote complète ici :
L’idée principale est simple : le goulot d’étranglement n’est pas de donner plus d’information au modèle.
Le goulot d’étranglement, c’est de réutiliser cette information plus tard.
J’ai des notes dans Obsidian, des passages surlignés dans Readwise, des repos GitHub, des récapitulatifs de réunions, d’anciennes recherches pour des vidéos, des articles et des liens enregistrés au hasard que j’avais clairement prévu de revisiter. Paul a aussi des milliers de notes.
Mais quand je commence un nouveau projet, je ne veux pas coller tout mon second cerveau dans Claude Code, Cursor ou Codex. Ce serait coûteux, lent et, honnêtement, plutôt mauvais.
Le meilleur pattern consiste à garder la mémoire à l’extérieur du modèle.
Nous avons donc créé un OS de recherche IA basé sur de simples fichiers et références. Aucune base de données vectorielle nécessaire. Aucun graphe de connaissances à maintenir. Juste une structure que les agents peuvent inspecter, interroger et mettre à jour.
Il comporte trois couches.
Premièrement, la couche brute.
Chaque source reste intacte. Si l’agent ingère un article, un repo, une transcription, une note ou un passage surligné, la version originale est préservée. C’est important parce que les résumés perdent des détails. Lorsque la précision compte, l’agent peut toujours retourner à la source.
Deuxièmement, l’index.
C’est la carte. L’agent lit un fichier index.yaml qui lui indique ce qui existe, où ça se trouve, le sujet de chaque source et quelles notes dérivées y renvoient.
Au lieu de tout charger, l’agent commence par le catalogue, lit les résumés, puis ouvre seulement les fichiers dont il a besoin.
Troisièmement, le wiki.
C’est ici que la mémoire commence à devenir utile. Le système transforme les sources en concepts, comparaisons, entités, notes et questions ouvertes.
Par exemple, si vous ingérez quelques repos open source d’agents de code, il peut créer des notes sur les flux de permissions, le sandboxing, les registres d’outils, les sous-agents et les systèmes de mémoire, puis comparer les architectures entre les repos.
Et lorsque vous posez de nouvelles questions, le wiki peut grandir. De nouveaux concepts, de nouvelles comparaisons, de nouvelles notes.
C’est la partie qui m’intéresse le plus.
Un document de recherche normal est statique. Utile une fois, puis graduellement dépassé.
Un wiki basé sur des fichiers peut continuer à s’enrichir au fil de votre travail.
Bien sûr, les bases de données vectorielles et les systèmes RAG restent pertinents pour des produits en production. Nous les utilisons chez Towards AI, particulièrement pour notre tuteur IA. Mais pour un workflow de recherche personnel, je veux quelque chose que je peux inspecter à la main.
Je veux pouvoir ouvrir le dossier, lire les fichiers, corriger un mauvais résumé, retirer une source faible et comprendre pourquoi l’agent a répondu quelque chose.
C’est beaucoup plus difficile lorsque tout est caché derrière des embeddings et des appels à une base de données.
La leçon utile de la keynote est donc la suivante :
Ne faites pas en sorte que le modèle se souvienne de tout.
Faites en sorte que l’agent sache où chercher. (Habituellement dans ce qu’on appelle des skills, ou ici dans un « Wiki ».)
C’est aussi cette même idée que nous approfondirons pendant mon workshop en personne à l’AI Engineer World’s Fair de San Francisco le 29 juin, avec Omar et Samridhi de Towards AI.
Ce workshop porte sur la gestion du contexte et la mémoire pour les agents qui s’exécutent sur de longues périodes, à l’aide du tuteur IA open source que nous avons créé pour la Towards AI Academy.
Le tuteur doit répondre à partir du contenu de nos cours, de la leçon actuelle de l’étudiant, de son profil, de longues sessions de débogage ainsi que du code. Et il doit quand même être assez rapide pour être utilisé.
Chaque décision liée au contexte compte donc : quoi récupérer, quoi conserver, quoi retirer, quand compacter, quand la synthèse aide, quand la mise en cache rend la synthèse contre-productive et comment éviter que d’anciens outputs d’outils remplissent discrètement toute la fenêtre de contexte.
J’ai enregistré ma partie de ce workshop à l’avance pour les abonnés payants, et vous pouvez vous abonner ici : https://louisbouchard.substack.com/subscribe
La version courte : les agents n’ont pas besoin d’un contexte infini.
Ils ont besoin d’une meilleure mémoire, d’une meilleure récupération, d’une meilleure compression et de meilleurs systèmes autour d’eux.
C’est là que se trouve la vraie ingénierie.
En guise d’aperçu, voici le site d’expérimentation de ce prochain workshop : huggingface.co/spaces/towardsai-tutors/context-engineering-experiments
FAQ
Comment créer une mémoire réutilisable pour des agents IA?
Conservez les notes, les sources, les décisions et les références dans une structure externe que l’agent peut inspecter et mettre à jour d’une session à l’autre.
Pourquoi ne pas tout coller dans le contexte du modèle?
Ça devient coûteux, lent et désordonné. Une mémoire externe permet à l’agent de récupérer ce qui compte sans traîner toute l’archive dans chaque exécution.
Que faut-il éviter avec la mémoire d’un agent?
Évitez de traiter la mémoire comme un vague tas de texte. L’agent a besoin de fichiers clairs, de références et de règles sur ce qui doit être réutilisé.
Qu’est-ce qui devrait se trouver dans la mémoire réutilisable d’un agent?
Stockez des décisions concises, des faits vérifiés, des références aux sources, les préférences de l’utilisateur et des résultats durables dont le travail futur aura réellement besoin.
Comment un agent devrait-il récupérer une ancienne mémoire?
Il devrait chercher ou filtrer le stockage externe et charger seulement les entrées pertinentes pour l’objectif actuel.