Comment faire d’un agent IA son propre agent
(monet.team-monet.com)Si vous travaillez tous les jours avec un agent IA de codage, vous connaissez ce sentiment.
Hier encore, on avait clairement défini ensemble une convention, et dès qu’on ouvre une nouvelle session, tout est effacé. Le fait que j’utilise toujours type plutôt que interface en TypeScript, que j’avais dit en revue de PR que ce pattern ne me plaisait pas, la cause racine de ce bug qu’on a enfin réussi à corriger la semaine dernière — il faut se comporter comme si c’était la première fois qu’on en parlait.
À force de répéter, on finit par se dire : « bon, je vais le faire moi-même ».
C’est pour résoudre ce problème que j’ai créé Monet. Le but : faire en sorte qu’un agent IA générique se comporte comme mon agent. Un système qui apprend mes conventions, retient mes préférences, et garde en tête l’historique du projet.
Comment ça fonctionne
Le principe est simple.
Écriture — l’agent décide par lui-même. Pas besoin de lui dire « retiens ça ». Il enregistre de lui-même les décisions prises pendant le travail, les patterns découverts et les problèmes rencontrés. Il filtre le bruit et ne garde que le signal utile.
Lecture — ce qui a été utile remonte en premier. Ce n’est pas une simple recherche par mots-clés. Les souvenirs réellement souvent consultés et utiles pour résoudre des problèmes sont priorisés. Les notes zombies que personne ne consulte reculent naturellement.
Croissance — plus ça s’accumule, plus il devient intelligent. Les premières tâches sont lentes. Il ne connaît ni la base de code, ni les conventions, ni les bugs récurrents. Mais à mesure que la mémoire s’enrichit, la tâche suivante devient plus rapide. Le pattern trouvé hier, la décision prise la semaine dernière, la cause racine de ce bug — plus besoin d’aller les rechercher. Au bout d’environ un mois, cet agent n’est plus un outil générique, mais il agit comme un ingénieur dédié qui connaît ce projet dans ses moindres détails.
Comment on en est arrivé là
Au début, j’empilais simplement des notes dans un fichier. L’agent écrivait dans un document Markdown ce qu’il apprenait en travaillant, puis je l’incluais au démarrage d’une nouvelle session. C’était simple, mais plus ça grossissait, plus le bruit augmentait.
Il y a donc 4 mois, j’ai créé un vrai système de mémoire. L’ancien Monet. Conçu sur la base de MCP pour que l’agent puisse lire et écrire, avec en tête l’idée d’un partage en équipe. Mais à force de se concentrer sur le partage en équipe, l’expérience en solo est devenue ambiguë. Ça fonctionnait, mais ça ne collait pas à mon workflow.
Alors j’ai tout refait. Il y a quelques semaines, j’ai mis de côté, provisoirement, l’objectif du partage en équipe et j’ai reconstruit Monet de zéro en me concentrant sur une seule question : « est-ce que je peux vraiment l’utiliser tous les jours ? » Au moment où j’écris ces lignes, 12 agents lisent et écrivent sur le nouveau Monet. Je n’ai pas encore de fonction de monitoring, donc je ne peux pas sortir de chiffres précis, mais il y a moins de recherche qu’avant et beaucoup plus de lecture/écriture. Autrement dit, les agents sélectionnent et accumulent d’eux-mêmes ce qui compte vraiment.
Honnêtement
Au stade du vibe coding, la mémoire n’a pas beaucoup d’importance. La plupart du temps, on crée de nouvelles fonctionnalités et les bugs restent simples. On dit à l’agent « corrige ça » et tout se règle dans la fenêtre de contexte.
Mais quand l’application devient de plus en plus complexe, c’est une autre histoire. Pour changer une seule ligne de code, il faut vérifier dix morceaux de logique liés, et l’agent rampe de fichier en fichier pour traquer les effets de bord. Les erreurs augmentent aussi. Même avec 1M de tokens, après trois compressions de contexte, on revient au point de départ.
Chez moi, j’utilise des agents pour créer de nouvelles choses intéressantes sur du code récent, et au travail, je me bats tous les jours avec du code vieux de plus de 20 ans. Au travail, la mémoire agentique est indispensable. Sans elle, le travail n’avance pas.
C’est pour ça que j’ai commencé à créer et utiliser moi-même une mémoire indexée basée sur les fichiers. C’est là qu’est né Monet. Ces derniers temps, au travail, je fais tourner les agents exprès en boucle — pour qu’ils collectent du contexte. La plupart des tickets se règlent dans les 20 % de contexte collectés. Et au-delà du temps gagné, le stress a diminué.
Surtout, alors qu’avant je me demandais péniblement « comment est-ce qu’on avait corrigé ce bug déjà ? », maintenant je demande simplement à Kiro (l’agent de codage de l’entreprise). La plupart du temps, il le sait.
Quand on a des dizaines d’agents et des millions de lignes de code, le contexte n’est plus un problème d’octets, mais un problème d’infrastructure. Et à ce moment-là, la mémoire n’est plus un simple nice-to-have : elle détermine si le travail est faisable ou non.
Si vous voulez essayer
- Site web : monet.team-monet.com
- GitHub : github.com/team-monet/with-monet — harnais d’installation (Apache-2.0)
- 100 % local : le code ne quitte jamais votre machine. Embeddings on-device, aucun réseau ni télémétrie. La mémoire tient dans un unique fichier SQLite dans
~/.monet— vous pouvez l’ouvrir directement, le sauvegarder et l’exporter. - Utilisation gratuite. Le moteur est un binaire compilé propriétaire, mais l’interface d’intégration repose sur le standard MCP. Intégration directe avec les agents compatibles MCP comme Claude Code, Cursor ou Codex.
J’aimerais particulièrement que les personnes suivantes l’essaient :
- les développeurs qui travaillent sérieusement tous les jours avec des agents IA
- celles et ceux qui ont déjà ressenti la fatigue de devoir répéter « il faut encore reparler de ce qu’on a dit hier… »
- celles et ceux qui se disent « la mémoire d’agent ? Pourquoi en aurait-on besoin ? » (vraiment — j’aimerais aussi entendre les avis contraires)
Tous les exemples et scénarios de ce texte sont tirés d’expériences réelles.
Aucun commentaire pour le moment.