Vault knowledge base + agent IA : 7 décisions de conception pour durer#

Une base de connaissance Markdown ne sert pas seulement à stocker des notes. Elle doit rester lisible pour un humain, exploitable par un agent IA et compatible avec une recherche sémantique. Elle doit aussi tenir plusieurs années sans finir par se contredire. Plusieurs guides publiés en 2026 promettent cet équilibre. Sur le terrain, tous les choix ne se valent pas.

Je retiens ici sept décisions de conception. Chacune s’écarte d’un pattern devenu courant en 2026, et chacune a un coût. Mon but n’est pas de proposer une recette universelle, mais de rendre ces arbitrages lisibles.

Le contexte 2026#

L’écosystème 2026 autour des bases de connaissance pilotées par IA repose sur trois éléments récurrents.

Le premier est un gist communautaire publié au printemps, qui décrit un pattern de wiki maintenu par LLM. Les sources brutes restent intactes, et l’agent produit des notes compilées à partir de ces sources. Le schéma a ensuite circulé dans plusieurs billets et dépôts.

Le deuxième est une série de guides sur l’association entre Obsidian, un agent et un serveur Model Context Protocol (MCP). Cette pile est souvent présentée comme la voie normale pour exposer un vault local à un assistant en langage naturel.

Le troisième est plus discret, mais plus utile pour trier le bruit. Deux études de l’ETH Zurich publiées début 2026 ont mesuré l’effet de fichiers de contexte d’agent comme AGENTS.md ou CLAUDE.md. Leurs résultats, tels qu’ils sont rapportés, nuancent certaines promesses de confort et d’efficacité lues dans les billets les plus enthousiastes.

Le décalage entre ces guides et ce que j’observe réellement sur la durée justifie les sept décisions suivantes.

Les sept décisions#

1. Pas de cascade de mises à jour automatiques#

Le pattern courant met à jour plusieurs notes à la fois quand une source change. Sur le papier, cela donne l’impression d’un système qui se corrige tout seul.

Je préfère une autre règle. Une ingestion crée ou met à jour une seule note. Les effets sur les notes voisines sont signalés en fin de session, puis relus à la main à intervalle régulier.

La cascade automatique propage aussi les erreurs. L’agent décide ce qui est matériellement affecté par une nouvelle source, puis corrige parfois le mauvais fichier sans que personne ne le voie tout de suite. Au bout de quelques mois, la base s’écarte de ce que disent réellement les sources.

Les études de l’ETH Zurich sur les fichiers de contexte d’agent rapportent un surcoût d’environ 20 % dans certains cas, sans gain net sur le résultat. Je retiens surtout l’effet pratique. Une base qui dérive en silence vaut moins qu’une base qui oblige à relire les points touchés. La première rassure trop vite. La seconde reste vérifiable.

Le coût assumé est une revue hebdomadaire d’environ trente minutes pour un vault actif de plusieurs centaines de notes. Ce n’est pas gratuit, mais le budget reste lisible.

2. Pas de serveur MCP par défaut#

Plusieurs guides recommandent d’ajouter un serveur MCP pour exposer le vault à Claude Desktop ou à Cursor. Dans un usage en ligne de commande mono-utilisateur, cette couche ajoute surtout une étape de plus.

L’agent, par exemple OpenCode ou Claude Code, peut lire le filesystem directement. Il n’a pas besoin d’un intermédiaire supplémentaire pour ouvrir un fichier déjà accessible localement.

Un guide largement diffusé cite un benchmark où la recherche en CLI consommerait autour de cent tokens, contre plusieurs millions via MCP pour le même usage. Je prends ce chiffre comme un repère cité, pas comme une vérité générale. Il montre au moins que le coût grimpe vite quand on ajoute une couche qui apporte peu dans ce contexte.

Si le vault doit un jour être exposé à un agent distant ou à plusieurs utilisateurs, un serveur MCP pourra entrer en scène. Pour le moment, je m’en passe.

3. Taxonomie figée plutôt que topics émergents#

Le pattern courant laisse les catégories émerger au fil des ingestions. Si une nouvelle source ne rentre dans aucun topic existant, j’en crée un. Le système paraît souple, mais il bouge sans garde-fou.

Je fais l’inverse. Une liste fermée de domaines vit dans un fichier versionné, par exemple domains.txt. Toute note doit porter un champ domain: dont la valeur figure dans cette liste. Un hook de validation refuse l’écriture si le domaine n’existe pas.

Le point technique est le suivant. Dans un vault qui mélange plusieurs domaines, technique, commercial, personnel, veille, la pollution sémantique entre domaines devient vite la première source de bruit dans une pipeline vectorielle. Les dossiers n’y changent pas grand-chose, parce qu’une pipeline d’embeddings lit du texte, pas l’arborescence du disque. Une métadonnée structurée, en revanche, peut servir de filtre à la requête.

Le coût assumé est léger. La taxonomie évolue lentement, avec quelques ajouts ou fusions par trimestre. C’est moins souple qu’une catégorie créée au fil de l’eau, mais beaucoup plus stable.

4. Pas d’index global maintenu à la main#

Un index global unique semble pratique au début. Dans les faits, il grossit vite, devient pénible à relire, et demande une discipline de mise à jour que peu de vaults gardent longtemps.

Je préfère plusieurs Maps of Content, ou MOC, dans un dossier dédié. Chaque MOC couvre un domaine de premier niveau, comme la téléphonie, l’infrastructure ou le commercial. Il n’y a pas de fichier central qui prétend tout résumer.

Le choix répond à un problème de taille et de maintenance. Un index unique sur plusieurs centaines de notes finit par ressembler à une table des matières plus lourde que le corpus lui-même. Les MOC locales restent plus proches du contexte de travail. Elles sont plus faciles à lire, à corriger et à faire évoluer.

Le coût assumé est l’absence de vue d’ensemble immédiate. Si je veux savoir combien de notes sur SIP existent, un grep ou un find répond en quelques secondes. Ce n’est pas élégant. C’est utile.

5. Aucune écriture durable sans validation humaine#

Le pattern courant laisse l’agent écrire directement dans la base durable. La promotion d’une source brute vers une note synthétique, ou la mise à jour d’un article existant, se fait alors sans étape intermédiaire.

Je garde une validation humaine avant toute écriture durable. L’agent propose un chemin cible, une note brouillon ou une action sur la source. L’humain vérifie avant que la note soit écrite sur le disque.

Le pire cas n’est pas une base incomplète. C’est une base fausse. Une erreur de quelques pour cent sur les notes durables suffit à entamer la confiance dans l’ensemble. Je ne consulte plus la base de la même manière si je dois vérifier chaque réponse à la main.

Le coût est modeste. Relire et valider une note prend souvent moins d’une minute. Sur une année, la discipline pèse peu. En retour, elle évite que le vault gagne en volume pendant qu’il perd en fiabilité.

6. Liens essentiels dans le frontmatter#

Les guides Obsidian s’appuient souvent sur les wikilinks placés dans le corps des notes pour reconstituer le graphe de relations. Pour une pipeline vectorielle, parser tout le Markdown à chaque passage n’est pas idéal.

J’ajoute une couche plus explicite. Les liens essentiels, en général trois à cinq, sont dupliqués dans le frontmatter sous une clé related:. Les wikilinks restent dans le corps pour la lecture humaine et le graphe natif d’Obsidian.

Le bénéfice est double. D’abord, le frontmatter se parse sans effort. Ensuite, la liste related: oblige à choisir les liens centraux plutôt qu’à accumuler des références au fil du texte. Le résultat est moins décoratif, mais plus exploitable.

Le coût est une duplication assumée. Elle ajoute une contrainte d’édition, mais elle évite de reconstruire le graphe en lisant tout le corps de la note.

7. L’application des règles de confidentialité côté serveur RAG uniquement#

Quand je parle de confidentialité, la tentation est de filtrer les notes directement dans l’agent local. En pratique, cela donne une impression de contrôle plus qu’un contrôle réel.

Je place l’application des règles de confidentialité uniquement côté serveur de retrieval-augmented generation (RAG). L’agent local ignore les marqueurs de confidentialité présents dans les notes. L’application des règles vit dans le serveur qui sert les utilisateurs via une API authentifiée, par exemple avec authentification unique (SSO) et JSON Web Token (JWT).

Le raisonnement est direct. Un agent local tourne sous l’identité de l’utilisateur, sur un filesystem auquel cet utilisateur a déjà accès. Un cat suffit pour lire un fichier. Filtrer à ce niveau ne protège donc pas grand-chose. La couche utile est celle où l’utilisateur ne voit pas directement les fichiers, donc le serveur RAG.

Le coût assumé découle de cette logique. Si un document ne doit pas être lu en clair, il ne doit pas rester dans le vault. Il faut alors le sortir du périmètre, le chiffrer à part, ou le placer dans un espace protégé que l’agent ne touche pas.

Une philosophie commune#

Ces sept décisions reposent sur trois principes.

Le premier est la sobriété de conception. Un fichier texte vaut souvent mieux qu’un automate de plus, un commit Git vaut souvent mieux qu’un job de cron, et un script shell suffit parfois là où une pile plus lourde ajouterait surtout de la complexité et des risques de panne.

Le deuxième est la méfiance envers les patterns en vogue. Un gist qui circule bien ou un benchmark qui impressionne ne suffisent pas à valider un choix. Ce qui compte, c’est le comportement sur la durée, avec un corpus réel et des contraintes réelles.

Le troisième est la visibilité des arbitrages. Chaque décision a un coût. Je préfère le rendre explicite dès le départ plutôt que le découvrir plus tard sous forme de dette cachée.

Ce que je ne sais pas encore#

Je garde encore quelques points à vérifier à l’usage.

• Sur cinq ans, la taxonomie figée restera-t-elle stable, ou faudra-t-il la refondre plus souvent que prévu ?
• La validation humaine de chaque promotion restera-t-elle tenable au-delà du cadre personnel ?
• L’application côté serveur RAG résistera-t-elle à des tentatives de prompt injection plus travaillées que celles que je teste d’habitude ?
• Le champ related: sera-t-il rempli avec régularité, ou finira-t-il par rester vide par lassitude ?

Ces points restent des hypothèses de travail. Un bilan après douze mois dira ce qu’ils valent en pratique.

Trois points#

1. Les patterns 2026 autour des bases de connaissance pilotées par LLM sont utiles, mais ils ne se transposent pas tous aussi bien à un vault réel.

2. Les sept décisions retenues ici visent la stabilité, la lisibilité et la vérifiabilité. Elles ne cherchent pas à maximiser l’automatisation.

3. La logique commune tient dans la sobriété de conception, le scepticisme envers les modes techniques et la mise à plat des coûts.

Pour aller plus loin#

• LLM Wiki, gist communautaire de référence (avril 2026) - gist.github.com/karpathy/442a6bf555914893e9891c11519de94f - décrit un pattern raw + wiki compilée par LLM.
• Obsidian skills pour agents, référentiel kepano - github.com/kepano/obsidian-skills - regroupe des skills officiels pour Claude Code, OpenCode et Cursor.
• Obsidian + Claude AI Knowledge Management Setup 2026 - buildmvpfast.com - détaille trois voies d’intégration.
• Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? (ETH Zurich, 2026) - arxiv.org/abs/2602.11988 - étudie l’impact des fichiers de contexte d’agent.
• On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents (ETH Zurich, 2026) - arxiv.org/abs/2601.20404 - complète l’analyse sur l’efficacité.
• Position publique du créateur d’Obsidian sur l’intérêt d’un serveur MCP local - x.com/kepano - reprise dans plusieurs threads de la communauté.

Le flux RSS du blog permet de suivre la suite.