Tu ouvres ton éditeur, tu lances une session avec ton assistant, et avant de pouvoir lui demander quoi que ce soit d'utile, tu reposes le décor : l'architecture, la décision de la semaine dernière, la convention que l'équipe suit. Le développeur passe une part réelle de sa journée à recontextualiser une IA qui oublie tout. C'est exactement le problème qu'une mémoire IA résout, et le cas d'usage où elle change le plus de choses.
Le dev passe sa journée à recontextualiser son IA
Un assistant de code raisonne sur sa fenêtre de contexte, vidée à chaque session. Il ne retient ni ton repo, ni tes choix d'une fois sur l'autre. On l'explique dans pourquoi ton IA oublie tout.
Pour un dev, ça se traduit par un rituel coûteux : recoller le contexte au début de chaque session, et recommencer demain. Ce copier-coller permanent ne scale pas : tu y perds du temps, tu oublies toujours une décision, et ton assistant répond à côté.
Ce que ton assistant ignore de ton repo
Erreur fréquente : croire que « connaître le repo » se limite au code source. Le code, ton assistant le lit souvent à l'écran. Ce qui lui manque, c'est tout ce qui n'est pas dans les fichiers :
- les décisions d'architecture et leur justification ;
- les conventions de l'équipe, le nommage, les patterns maison ;
- les options écartées et pourquoi ;
- les essais passés qui ont échoué.
Cette connaissance vit dans tes notes et tes décisions, pas dans tes fonctions. Sans elle, ton assistant te propose l'approche que tu avais écartée et enfreint des conventions qu'il n'a jamais vues. On développe ce point dans l'IA qui connaît ton code.
Une mémoire qui connaît tes décisions, pas juste tes fichiers
La solution n'est pas un assistant plus malin, mais un assistant qui peut consulter ce que tu sais déjà. C'est le rôle d'une mémoire externe : ta connaissance vit à un endroit stable, et l'assistant retrouve le passage pertinent pour chaque question, sourcé.
Le mécanisme, c'est un RAG local. Appliqué à un agent qui agit, il devient sa mémoire de travail : on le détaille dans un RAG local comme mémoire d'un agent de code.
Comment ça marche : vault, Smart Brain, Claude Code
Avec Artefact Neural, le montage est concret :
- ta connaissance vit dans un vault Obsidian : décisions, conventions, notes de projet, ADR ;
- Smart Brain indexe ce vault en local (Ollama plus base vectorielle ChromaDB) et fournit le retrieval : recherche hybride BM25 plus embeddings Qwen3, graphe des liens, reranking cross-encoder ;
- via MCP Obsidian, ce vault devient une source que Claude Code interroge directement dans ton éditeur. On détaille ce pont dans donner une mémoire persistante à Claude Code.
La qualité du retrieval est mesurée, pas promise : Hit@1 de 0,909, Hit@5 de 0,98, sur un vault d'environ 23 500 chunks. Les chiffres sont sur la page technique.
Ce que ça change au quotidien
Concrètement, une fois cette mémoire branchée :
- tu demandes « pourquoi on a choisi cette approche pour l'auth » et l'assistant retrouve ta note de décision, datée, au lieu de spéculer ;
- il respecte ta convention de nommage parce qu'elle est dans ton vault et qu'il peut la consulter ;
- il ne repropose pas l'option que tu avais documentée comme écartée ;
- tu arrêtes de recoller ton architecture à chaque session.
Tu ne paies plus l'impôt de la recontextualisation. Ton contexte devient celui de ton assistant.
Pour qui c'est, honnêtement
Soyons clairs sur le profil. Artefact Neural est un système que tu héberges, pas un service géré : tu l'installes et tu l'exécutes sur ta machine. Il s'adresse à des développeurs à l'aise avec un flux technique (Claude Code dans l'éditeur, un vault de notes). Ce n'est pas un produit grand public en deux clics, et c'est assumé : la contrepartie, c'est que ta connaissance ne sort jamais de chez toi et qu'il n'y a aucune facturation au token.
Brancher Smart Brain sur ton repo
Si tu veux donner cette mémoire à ton assistant sur ton propre projet, la documentation couvre l'installation locale, la page technique détaille le moteur, et les offres incluent Smart Brain à partir du tier Studio.
Ton assistant n'a pas besoin d'avoir appris ton repo. Il a besoin de pouvoir le consulter.