Un agent de code, c'est une IA à qui on délègue des tâches : lire, écrire, modifier du code, parfois sur plusieurs étapes. Plus on lui confie de responsabilités, plus son amnésie devient coûteuse. Un agent qui ne se souvient de rien refait les mêmes erreurs, ignore tes décisions et travaille à côté de tes conventions. La pièce qui lui manque, c'est une mémoire. Un RAG local la lui fournit.
Un agent sans mémoire répète ses erreurs
Le problème de base est le même que pour un assistant de chat : un agent raisonne sur une fenêtre de contexte, vidée entre les sessions. Mais l'enjeu est plus lourd, parce que l'agent agit.
Sans mémoire, un agent va :
- reproposer une approche que tu avais explicitement écartée, faute de connaître la décision ;
- enfreindre tes conventions parce qu'il ne les a jamais vues ;
- refaire un essai qui a déjà échoué, parce que l'échec n'est consigné nulle part qu'il puisse consulter.
Chaque session repart d'une page blanche, comme on l'explique dans pourquoi ton IA oublie tout. Pour un agent, ça se traduit en travail à refaire.
Le RAG comme couche mémoire
La solution n'est pas de rendre l'agent « plus malin », mais de lui donner accès à ce qu'il faut savoir, au bon moment. C'est précisément ce qu'est un RAG : retrieve avant de generate. Retrouver, puis produire.
Concrètement, le RAG s'intercale avant l'action de l'agent :
- l'agent a une tâche ou une question ;
- le système retrouve, dans ta connaissance, les passages pertinents (décision liée, convention applicable, note d'échec passé) ;
- l'agent reçoit ce contexte sourcé et agit en s'appuyant dessus.
Cette couche de retrieval devient, de fait, la mémoire de l'agent. Elle est externe (elle survit aux sessions), interrogeable (l'agent n'y lit que le pertinent) et sourcée (chaque décision s'appuie sur une origine vérifiable). C'est la même logique que dans mémoire long terme vs fenêtre de contexte, appliquée à un agent qui agit.
Pourquoi le local, pour un agent
Un agent de code lit ton code et tes décisions internes. Lui brancher une mémoire cloud reviendrait à exposer cette connaissance à un tiers. Un RAG local garde tout sur ta machine : le retrieval tourne via Ollama et une base vectorielle locale, rien ne sort. Pour du code propriétaire, c'est une condition, pas une option. Le comparatif complet est dans RAG local vs RAG cloud.
Les trois étages qui servent le bon souvenir
Tout l'enjeu d'une mémoire d'agent, c'est de servir le bon passage, pas le morceau vaguement proche. Un mauvais souvenir oriente mal l'agent. Smart Brain empile pour ça trois étages :
- Recherche hybride. BM25 attrape les termes exacts (un nom de fonction, un identifiant), les embeddings Qwen3 attrapent le sens. Les deux signaux fusionnent. Détail dans le retrieval hybride.
- Graphe. Les liens entre tes notes font remonter le contexte voisin d'une décision, pas seulement la décision isolée.
- Reranking. Un cross-encoder re-note les candidats et place le passage le plus juste en tête. Détail dans le reranking cross-encoder.
Le résultat est mesuré : Hit@1 de 0,909, Hit@5 de 0,98. Une mémoire d'agent fiable se juge à sa précision, pas à sa taille. Les chiffres sont sur la page technique.
Mémoire d'un agent vs mémoire d'un humain
Une nuance utile : la mémoire d'un agent n'est pas un cerveau qui « comprend ». C'est un index qui retrouve. Elle ne remplace pas ton jugement ; elle remet sous les yeux de l'agent ce que tu as déjà décidé, pour qu'il ne le contredise pas par ignorance.
C'est aussi pour ça qu'Artefact Neural ne s'arrête pas au retrieval : six agents (estimation, retrieval sourcé, exécution, audit, jugement, capitalisation) s'appuient sur cette mémoire pour exécuter et se vérifier entre eux. Le détail est sur la page technique.
En résumé
Un agent de code devient utile quand il cesse de répéter ce qui a déjà été tranché. Le RAG local est la couche qui lui donne cette mémoire : retrouver avant d'agir, en local, sourcé. Pour le moteur en détail, vois le silo RAG local ; pour le brancher sur ton assistant, donner une mémoire à Claude Code.