Comment connecter Claude Desktop à Obsidian — Un parcours à travers 4 serveurs MCP

Imaginez : vous avez plus de 400 notes dans Obsidian, accumulées au fil des années. Tout est éparpillé à la racine du vault, les concepts mélangés aux notes techniques, il y a des doublons (ideas.md et un dossier ideas/ avec 13 fichiers dedans), aucun système. Vous voulez mettre de l'ordre — construire une architecture de dossiers propre, ajouter des fichiers MOC, organiser les tags. Le faire à la main est fastidieux et lent. La pensée logique : connecter Claude à Obsidian via MCP, laisser l'IA faire le refactoring. Il s'avère que — c'est un chemin à travers un champ de mines. Voici ce que j'ai dû traverser pour arriver à une solution fonctionnelle.

Qu'est-ce que MCP et pourquoi ce n'est pas si simple

MCP (Model Context Protocol) est un protocole ouvert d'Anthropic qui permet à Claude de se connecter à des outils et des données externes. Le principe est simple : un serveur local tourne, expose des "outils" (tools), et Claude les appelle pendant la conversation.

Pour Obsidian, il existe théoriquement beaucoup de serveurs MCP. En pratique — chacun a ses propres problèmes.

Le problème principal de l'écosystème Obsidian : Obsidian est une application fermée sans MCP officiel. La communauté a comblé le vide, mais chaque implémentation suit son propre chemin, et aucune n'a de "bénédiction officielle".

Tentative 1 : MarkusPfundstein/mcp-obsidian

Le premier outil trouvé lors de la recherche. 3 400 étoiles sur GitHub, dans tous les tutoriels. Semble être un choix sûr.

Comment ça fonctionne : serveur Python basé sur le plugin Local REST API d'Obsidian. Le serveur communique avec le plugin via HTTPS, le plugin effectue les opérations via l'API d'Obsidian.

Ce qui a mal tourné

• Pas mis à jour depuis 17 mois
• 85 issues ouvertes
• Pas de move/rename — seulement read, write, append, delete
• Local REST API a un bug documenté de perte de données : le endpoint POST peut silencieusement écraser un fichier lors d'un append

Pas adapté au refactoring — nous avons besoin de déplacer des fichiers et de préserver les liens. On continue.

Tentative 2 : aaronsb/obsidian-mcp-plugin

Trouvé une option qui fonctionne comme un plugin natif Obsidian. Cela signifie un accès direct à l'API interne d'Obsidian — backlinks, Dataview, graphe de liens. Move via l'API native met à jour tous les wiki-links automatiquement, car Obsidian gère cela lui-même.

Difficultés d'installation

• Le plugin n'est pas dans le catalogue officiel d'Obsidian (PR en attente avec des erreurs de validation)
• Installation obligatoire via BRAT (Beta Reviewers Auto-update Tool)
• Claude Desktop n'accepte pas le Bearer token directement via l'UI — a forcé l'activation de HTTPS dans le plugin
• Le certificat self-signed pour localhost crée des problèmes de confiance

À travers tous ces contournements, j'ai finalement réussi à le connecter. Test basique — vault.move réécrit bien les [[wikilinks]], fonctionne comme prévu.

Ce qui a mal tourné en production

Quand j'ai commencé le refactoring massif (drag-and-drop de dizaines de dossiers dans Obsidian + opérations MCP simultanées), le serveur a figé pendant 4+ minutes. Pourquoi : le plugin tourne à l'intérieur d'Obsidian. Quand Obsidian réindexe des milliers de fichiers après un changement massif de structure, le plugin se bloque avec.

Conclusion : la dépendance à une instance Obsidian ouverte et son index est fatale pour les opérations en masse.

Tentative 3 : @bitbonsai/mcpvault

Logiquement — il faut un serveur qui ne dépend pas d'Obsidian. Travaille directement avec les fichiers sur le disque. @bitbonsai/mcpvault — recommandé dans de nombreux avis. Accès direct au système de fichiers, configuration simple (npx @bitbonsai/mcpvault@latest /path/to/vault), 14 outils. Obsidian n'a même pas besoin d'être ouvert.

Avant d'installer, j'ai vérifié un point critique — est-ce que les wiki-links se mettent à jour lors d'un move. J'ai trouvé un avis utilisateur :

Le connecteur filesystem ne sait pas qu'il est dans Obsidian — il voit un dossier de fichiers <code>.md</code> et c'est tout. Ne sait pas que les noms de fichiers portent un poids sémantique, que chaque <code>[[wikilink]]</code> cassera au moment d'un rename ou move. L'auto-update des liens ne fonctionne que quand le rename se fait depuis l'intérieur de l'app. Je l'ai appris après avoir demandé à Claude de nettoyer les noms de fichiers et suis revenu à un dashboard avec la moitié des liens cassés.

Confirmé dans la documentation même de mcpvault : PR #101 (wiki link resolution) est en review, pas mergé. Donc déplacer via mcpvault casserait la moitié du vault. Pas adapté.

Tentative 4 : VaultForge (Final)

blacksmithers/vaultforge — spécialement conçu pour les agents IA qui font du refactoring.

Architecturalement correct

• Direct filesystem — ne dépend pas d'Obsidian
• Moteur wikilink propre — implémente la logique de résolution [[wikilink]] qui met à jour toutes les formes (stem, chemin complet, alias, embed)
• Dry run par défaut sur toutes les opérations destructives — montre d'abord ce qui va changer, puis vous confirmez
• 27 outils contre 8–14 chez les concurrents : batch_rename, update_links, backlinks (impact analysis), prune_empty_dirs, frontmatter, smart_search (BM25), vault_themes (TF-IDF clustering)
• Licence MIT, TypeScript, zéro sous-dépendance
• Installation en 30 secondes via .mcpb (extension one-click pour Claude Desktop)

Test de sécurité sur fichiers isolés

Créé 4 fichiers test avec des liens croisés — liens stem, liens avec alias, liens avec chemin complet. Déplacement d'un fichier dans un sous-dossier :

delta.md → subfolder/delta-renamed.md

VaultForge a affiché un dry run : "1 fichier sera renommé, 3 liens seront mis à jour". Exécuté pour de vrai.

Vérifié après — les trois types de liens se sont mis à jour correctement. C'est exactement ce qui manquait à tous les outils précédents.

Comment installer VaultForge — Instructions finales

Si vous avez macOS et Claude Desktop :

Étape 1

Téléchargez le fichier .mcpb :

curl -fsSL https://github.com/blacksmithers/vaultforge/releases/latest/download/vaultforge.mcpb \
  -o /tmp/vaultforge.mcpb && open /tmp/vaultforge.mcpb

Étape 2

Claude Desktop ouvrira le dialogue d'installation d'extension. Entrez le chemin absolu vers votre vault — pas de backslashes, espaces normaux :

/Users/yourname/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVault

Étape 3

Cliquez sur Save. Claude Desktop ajoutera l'extension à la configuration automatiquement. Pas de redémarrage nécessaire — les extensions .mcpb sont détectées automatiquement.

Étape 4

Vérifiez : dans un nouveau chat, demandez : "What is the status of my Obsidian vault?" — devrait retourner quelque chose comme totalFiles: 416, totalDirs: 135, ...

Ce que j'ai appris sur l'écosystème MCP d'Obsidian

Premièrement, "le plus populaire" ne signifie pas "fonctionnel". MarkusPfundstein/mcp-obsidian a 3 400 étoiles et est la recommandation par défaut, mais il est obsolète et il lui manque des opérations clés.

Deuxièmement, un plugin natif a un coût caché. Le plugin aaronsb semblait idéal — graph, Dataview, move natif. Mais la dépendance à une instance Obsidian ouverte et son index le rend inadapté aux opérations massives sérieuses.

Troisièmement, filesystem direct sans link-engine est un piège. Mcpvault est rapide et simple, mais "juste déplacer des fichiers" détruit la structure du vault. Les liens portent une sémantique imposée que le filesystem ne connaît pas. Sans sa propre implémentation de logique wikilink, l'outil devient une mine.

Quatrièmement, testez sur des données isolées. Avant de confier un refactoring massif à un outil — créez un dossier test avec 4–5 fichiers avec des liens croisés et regardez ce qui se passe. 5 minutes de test économisent des heures de récupération depuis un backup.

Cinquièmement, gardez un backup git de votre vault. Le plus important de tout. Un seul git init à l'intérieur du vault et des commits périodiques — c'est l'assurance contre toute erreur d'un agent IA ou d'un outil. Si quelque chose casse — git reset --hard ramène tout.

Conclusion

Le parcours a pris plusieurs heures et trois tentatives échouées. L'architecture finale ressemble à ceci :

• VaultForge — l'outil de travail principal. Filesystem direct + moteur wikilink propre + 27 outils = refactoring stable à toute échelle.
• Git — versionnage du vault. Rollback gratuit pour toute erreur.

Maintenant je peux faire ce pour quoi tout a commencé : demander à Claude d'organiser 400 notes en une architecture PARA propre, fusionner les doublons, ajouter du frontmatter, construire des cartes MOC. Chaque opération est sûre, les liens sont préservés, le dry run montre ce qui se passera avant que quelque chose ne change.

Si vous aussi vous regardez votre Obsidian encombré et voulez un assistant IA — commencez directement avec VaultForge. Ne répétez pas mon parcours à travers des projets morts, des plugins beta et des serveurs filesystem sans logique de liens.