Je brainstorm beaucoup avec Claude. Sur desktop via Claude Code pour le dev, sur Claude.ai web quand je réfléchis à un problème, sur mobile quand une idée me vient. Le problème : dès que je quittais Claude Code sur mon PC, je perdais l'accès à mes notes. Mon vault Obsidian, mes specs, mes décisions d'architecture, tout restait coincé sur ma machine.
Quand j'ai scanné l'écosystème des serveurs MCP Obsidian, j'ai trouvé une dizaine de projets. Tous en stdio, tous locaux. Certains proposaient des tunnels Tailscale ou du Docker + reverse proxy, mais aucun n'offrait du remote natif avec OAuth.
Alors j'ai construit Vaulken. Un serveur MCP remote qui donne à Claude l'accès à mes fichiers depuis n'importe où. Si tu veux comprendre pourquoi le remote est important et comment fonctionne Streamable HTTP sous le capot, j'en parle dans l'article sur le MCP remote.
Le produit est en alpha sur vaulken.dev. D'ailleurs, cet article a été écrit avec Claude qui accédait à mes notes via Vaulken.
Le principe
Tes fichiers vivent dans un bucket S3-compatible. Si tu utilises Obsidian, le plugin Remotely Save synchronise ton vault vers le bucket. Sinon, n'importe quel contenu texte dans un bucket fonctionne.
Vaulken se branche sur ce bucket et expose son contenu via MCP. Claude s'y connecte via une URL HTTPS avec authentification OAuth (détails techniques dans l'article auth, à venir). Pas de tunnel, pas de serveur à maintenir, pas de token à copier-coller.
1Obsidian ──sync──▶ Bucket S3 ◀────── Vaulken MCP ◀────── Claude.ai
2(Remotely Save) (Scaleway, (Streamable HTTP, (web, mobile,
3 AWS, R2...) OAuth 2.1) desktop)BYOB : ton bucket, tes règles
Vaulken fonctionne en mode BYOB (Bring Your Own Bucket) : tu connectes ton propre stockage S3-compatible (AWS, Scaleway, Cloudflare R2, MinIO...). Tes données restent chez toi. Vaulken ne stocke pas tes fichiers, il les lit et les écrit dans ton bucket.
Une fois le vault configuré, tu crées des access configs depuis le dashboard. Chaque access config est un point d'entrée MCP avec ses propres contraintes : path prefix, permissions (lecture seule ou lecture-écriture), et une description injectée dans les instructions MCP pour guider l'agent.
1Vault "notes" (ton bucket S3)
2├── Access "Principal" → / read-write
3├── Access "Claude mobile" → / read-only
4├── Access "Projets" → /projects/ read-write
5└── Access "Blog" → /blog/ read-writeChaque access config génère une URL MCP unique que tu colles dans Claude.ai, Claude Code ou Cursor. L'URL porte le vault, le path prefix et les permissions. Rien à configurer côté client.
Tu peux donner à Claude un accès read-only depuis ton téléphone (pas de risque d'écraser un fichier), et un accès read-write limité à /projects/ depuis Claude Code. Même vault, URLs différentes.
16 tools conçus pour les LLM
Les principes de design des tools sont détaillés dans l'article MCP remote. Voici comment Vaulken les applique :
| Catégorie | Tools | Rôle |
|---|---|---|
| Lecture | read_file, read_section, get_outline, get_metadata | Lire un fichier entier, une section par heading, la structure, ou les métadonnées |
| Écriture | write_file, append_file, patch_file, replace_in_file, replace_section | Écriture complète, ajout, patch multi-éditions, remplacement ciblé |
| Organisation | list_files, move_file, delete_file, update_frontmatter | Navigation, déplacement, suppression, gestion YAML |
| Recherche | search_text, search_semantic, get_related | Full-text, recherche par concept (embeddings), fichiers similaires |
read_section évite de charger un fichier entier quand tu ne veux qu'un chapitre. get_outline renvoie la structure en quelques lignes. patch_file applique plusieurs modifications en un seul appel sans renvoyer tout le contenu.
La recherche sémantique fait une vraie différence : les fichiers sont indexés via des embeddings, et Claude peut chercher par concept. Quand je demande "retrouve mes notes sur l'architecture de la base de données", il trouve les fichiers pertinents même sans correspondance exacte de mots-clés.
Ce que ça change au quotidien
Continuité entre plateformes. Je commence un brainstorm sur Claude.ai web, je continue sur mobile dans le train, je repasse en Claude Code pour implémenter. Claude accède aux mêmes notes partout. Plus de rupture de contexte quand je change de device.
Capture d'idées sur mobile. Avant, les idées en dehors du bureau finissaient dans les mémos vocaux et je les oubliais. Maintenant, je dicte à Claude et il range la note dans Obsidian avec le bon nom, les bons tags, dans le bon dossier.
Recherche dans les archives. "Retrouve ce qu'on avait décidé sur la stratégie de pricing en février." Claude cherche par concept, lit les fichiers, fait une synthèse. Le genre de requête qui prendrait 15 minutes de navigation manuelle.
Écriture avec contexte. Quand Claude rédige un article technique, il accède à ma documentation, mes specs, mes analyses. Il ne part pas de zéro, il travaille avec mon contexte réel.
Setup
- Crée un compte sur vaulken.dev et configure ton vault (bucket S3 + credentials)
- Ajoute l'URL MCP dans Claude.ai → Settings → Connectors
- Le flow OAuth se lance automatiquement : login, consent, autorisation
- Claude accède à tes fichiers
La documentation détaille le setup complet.
Pas juste Obsidian
Vaulken n'est pas un outil Obsidian. C'est un serveur MCP pour S3. Obsidian est le go-to-market parce que la communauté est large et le problème mobile bien identifié. Mais le serveur fonctionne avec n'importe quel contenu texte dans un bucket.
Autres cas d'usage :
- Agent-to-agent : un agent écrit des résultats dans S3, un autre les lit via Vaulken. Le bucket sert de mémoire partagée entre agents.
- Pipeline → LLM : un script dépose des fichiers (rapports, extractions) dans S3, tu interroges le contenu via Claude + Vaulken.
- Wiki/docs : des fichiers markdown dans un bucket, accessibles via Claude pour du Q&A.
Le type de workspace (plain, obsidian) ajoute des hints contextuels pour l'agent (frontmatter YAML, liens [[wiki]]), mais les tools fonctionnent sur tout contenu texte.
La suite
Vaulken est en alpha sur vaulken.dev. Deux chantiers arrivent : l'amélioration de la recherche sémantique, et une meilleure gestion du BYOB pour simplifier le setup S3.
Pour les choix techniques (pourquoi Streamable HTTP, comment fonctionne un serveur MCP remote), voir l'article MCP remote. Pour l'authentification OAuth 2.1 avec DCR et PKCE, le prochain article de la série couvrira ça en détail.