En 2026, connecter un agent de code à un coffre Obsidian n’est plus une idée exotique. C’est probablement la configuration de gestion des connaissances la plus sous-estimée qui existe actuellement. Et pourtant, presque tous ceux qui le font restent à la première étape : pointer Claude Code vers un dossier et le laisser lire et écrire du Markdown. Ça fonctionne. Mais ce n’est que le début, et pour comprendre pourquoi l’étape suivante, MCP, est importante, il faut d’abord comprendre ce que nous avons déjà et là où ça coince.
Ce qui est déjà possible sans MCP
Lorsque Claude Code pointe directement vers un coffre, il fonctionne comme n’importe quel agent ayant accès au système de fichiers : il lit la structure des dossiers, applique grep et glob pour localiser le contenu pertinent, et écrit ou modifie des fichiers Markdown en respectant les conventions que vous lui avez données (YAML frontmatter, wikilinks, une hiérarchie de dossiers par type de contenu). Pas de plugin, pas de base de données, pas d’API : juste du texte brut et un agent qui sait le lire et l’écrire avec discernement.
Le résultat, lorsque le système est bien conçu, est plus puissant qu’il n’y paraît. Pour référence réelle, non hypothétique : un coffre que je suis de près est passé, exactement avec cette méthode, de 78 sources brutes (articles, documents, documentation) à 180 pages wiki interconnectées (83 d’entre elles sont des pages de concepts, le reste des outils, des personnes, des comparaisons et des résumés de sources), le tout avec des références croisées que l’agent lui-même met à jour à chaque nouvelle entrée. Sans que personne n’écrive une seule page à la main.
Le plafond de l’accès direct aux fichiers
Mais ce modèle a une limite structurelle, pas seulement une limitation de performance. Claude Code doit savoir à l’avance comment votre coffre est organisé : quel dossier est immuable, quelle est la convention de frontmatter, où se trouvent les concepts par rapport aux outils. Chaque nouveau coffre est, en pratique, une intégration différente qui doit être expliquée depuis le début dans le prompt système.
De plus, l’agent ne peut pas demander à un coffre « quelles sont tes capacités ? ». Il peut seulement lire ce qui existe déjà et exécuter des opérations génériques sur les fichiers (lire, écrire, chercher par texte). Il n’y a aucun moyen de lui exposer une opération dérivée (donne-moi le graphe de backlinks de cette note, exécute cette requête Dataview, dis-moi quelles pages sont orphelines) sans que l’agent lui-même reconstruise cette logique à chaque fois, gaspillant du contexte et de la marge d’erreur en cours de route.
Ce que MCP résout, en profondeur
MCP (Model Context Protocol) est le standard ouvert qu’Anthropic a lancé en novembre 2024 pour résoudre exactement ce problème : l’intégration entre les modèles d’IA et les systèmes externes. Avant MCP, si N assistants IA devaient se connecter à M outils ou sources de données différents, il fallait N×M intégrations sur mesure : lorsqu’une application voulait supporter Notion, elle le construisait de zéro ; quand une autre voulait la même chose, elle le reconstruisait de zéro. MCP transforme ce N×M en N+M : des clients génériques sont construits (un par application) et des serveurs génériques (un par système), et n’importe quel client peut parler à n’importe quel serveur sans intégration sur mesure.
L’analogie correcte est l’USB-C : avant, chaque périphérique avait son propre connecteur ; avec l’USB-C, l’appareil n’a besoin que de parler le protocole, sans se soucier de savoir s’il est connecté à un Mac ou à un PC.
L’architecture comporte trois couches. L’hôte est l’application orientée utilisateur (Claude Code, Claude Desktop, ou un agent personnalisé) qui interprète ce qui est demandé et décide si elle a besoin de données ou d’outils externes. Le client vit à l’intérieur de l’hôte et gère une connexion 1:1 avec chaque serveur, traduisant les requêtes abstraites en messages MCP concrets et gérant le cycle de vie de la session. Le serveur connecte le protocole à un système réel, dans ce cas un coffre Obsidian, traduisant les requêtes MCP en opérations natives.
Deux propriétés font de cela plus qu’une couche d’abstraction cosmétique. La première est la découverte dynamique des capacités : lors de la connexion, le client demande au serveur ce qu’il est capable de faire, et le serveur répond en temps réel. Si le serveur ajoute une nouvelle fonction demain, le client n’a pas besoin d’être reprogrammé pour l’utiliser. La seconde est le découplage entre l’intelligence et les données : celui qui construit le serveur MCP pour Obsidian n’a pas besoin de savoir quel modèle l’utilisera, et celui qui construit l’agent n’a pas besoin de reconstruire son intégration à chaque changement de modèle.
Un serveur MCP expose trois types de primitives. Les ressources sont des données que le modèle peut lire mais pas modifier : le contenu d’une note, les résultats de recherche, le graphe de backlinks. Les outils sont des actions que le modèle peut invoquer activement : créer une note, mettre à jour un tag, exécuter une requête structurée. Les prompts sont des modèles d’instructions réutilisables et paramétrables, par exemple « résume cette source et génère la page wiki correspondante » en tant qu’opération nommée, et non comme du texte libre à réécrire à chaque fois.
Appliqué à Obsidian, spécifiquement
Des serveurs MCP spécialement conçus pour Obsidian existent déjà dans son écosystème open source, généralement soutenus par le plugin REST API local d’Obsidian, qui exposent des opérations telles que la recherche sémantique dans le coffre, la création et l’édition de notes, la gestion des tags et des métadonnées, ou la lecture du graphe de liens, sans que l’agent ait besoin de connaître la structure exacte des dossiers à l’avance.
Ce qui change en pratique est subtil mais important : sans MCP, Claude Code gère votre coffre avec des règles que vous lui avez expliquées une par une. Avec MCP, votre coffre devient un outil que Claude Code peut opérer exactement comme il opérerait une API ou une base de données, découvrant ses capacités au moment de la connexion, sans les mémoriser à l’avance. Et cette même connexion fonctionne pour n’importe quel autre client MCP, pas seulement Claude Code : le même serveur pourrait alimenter un agent différent, dans une autre application, sans toucher à une ligne de code du côté d’Obsidian.
Cadre pratique : trois niveaux de maturité
Pour situer où se trouve votre propre configuration, voici le cadre que j’utilise :
Niveau 0 : copier-coller manuel du contexte. Chaque conversation commence de zéro ; l’utilisateur colle des fragments pertinents de ses notes dans le chat. Cela fonctionne pour des tâches spécifiques, mais ne passe pas à l’échelle.
Niveau 1 : agent avec accès direct aux fichiers. C’est là que se trouvent la plupart des configurations Claude Code + Obsidian aujourd’hui, y compris l’exemple de l’article avec 78→180 pages. L’agent lit et écrit le coffre directement, en suivant les conventions expliquées dans un fichier d’instructions. C’est déjà nettement plus puissant que le niveau 0, et pour un seul coffre géré par un seul agent, cela peut suffire pendant longtemps.
Niveau 2 : agent connecté via MCP. Le coffre est exposé comme un serveur avec des capacités dynamiquement découvrables, réutilisables entre différents modèles et applications. Cela devient pertinent dès que plus d’un agent, plus d’un coffre, ou le besoin d’exposer des opérations qui vont au-delà de la lecture et de l’écriture fichier par fichier entrent en jeu.
Il n’est pas nécessaire de passer directement au niveau 2 pour profiter d’un coffre géré par l’IA. Le niveau 1 est déjà un véritable saut par rapport à l’absence de système. Mais comprendre ce que MCP résout, c’est comprendre où cela va : de « mon IA peut lire mes notes » à « mes connaissances sont un système que n’importe quelle IA peut opérer. »
À quel niveau se trouve votre propre configuration en ce moment ? Dites-le-moi dans les commentaires. Si l’intérêt est suffisant, le prochain article sera un guide étape par étape pour configurer votre premier serveur MCP pour Obsidian.
Et si cela vous a été utile, suivez-moi @chesny
Ceci n’est que le premier article d’une série sur les agents qui cessent de lire les systèmes et commencent à les opérer.
