Obsidian + Claude Code : la tendance qui vend du vent

Le pitch est toujours à peu près le même : brancher Obsidian sur Claude Code pour "économiser des tokens" et avoir un contexte toujours propre. Des repos GitHub avec de beaux README, des vidéos bien montées, des commentaires qui s'extasient. Et en dessous, techniquement, pas grand-chose.

Deux arguments reviennent tout le temps pour vendre ce setup : l'économie de tokens, et le graph view comme outil de tri du contexte. Aucun des deux ne résiste à l'examen. Et ce qui tourne autour, les repos à cloner et les skills à installer, mérite un vrai regard sécurité plutôt qu'un coup de confiance aveugle.

L'argument des tokens

L'idée vendue : en stockant tes notes dans Obsidian et en les injectant intelligemment dans Claude, tu évites de bourrer le contexte avec des informations inutiles. Tu paies moins, Claude répond mieux. Logique, sur le papier.

Le problème c'est que c'est exactement ce que fait CLAUDE.md nativement. Tu écris tes conventions de projet dans un fichier texte à la racine, Claude le lit au démarrage. Pas de plugin, pas d'intégration, pas d'Obsidian. Un fichier. C'est dans la documentation officielle, rubrique Memory and context, personne ne semble l'avoir lue.

L'économie de tokens réelle vient de la qualité de ce que tu mets dans ce fichier, pas de l'outil que tu utilises pour l'écrire. Notepad ferait le même travail. Le vrai sujet de fond, filtrer ce qui mérite d'être mémorisé et ce qui doit être oublié, mérite un article à part entière (que j'ai écrit ici).

Il y a un cas où un système externe apporte réellement quelque chose que CLAUDE.md ne fait pas nativement : la recherche full-text sur un vault de plusieurs milliers de notes. Si ton besoin réel c'est retrouver une note écrite six mois plus tôt dans un océan de fichiers, un outil de recherche et d'indexation dédié te fait gagner du temps. Mais ce n'est plus le même problème que "économiser des tokens", c'est un problème de recherche documentaire. Confondre les deux, c'est acheter la mauvaise solution au bon problème.

Le graph view n'économise rien du tout

Un argument récurrent dans ces setups : le graph view d'Obsidian permet de "visualiser les connexions entre tes notes" avant de décider quoi injecter dans le contexte. Ça sonne bien.

En pratique, le graph view ne communique pas avec Claude Code. C'est une visualisation locale, statique, qui te montre des liens entre fichiers Markdown. Pour qu'elle "économise des tokens", il faudrait qu'elle pilote automatiquement ce qui entre dans le contexte de Claude. Elle ne fait rien de tel. Tu regardes un graphe, tu décides toi-même ce que tu passes à Claude, tu le passes à la main. Le graph view est une fonctionnalité d'Obsidian pour organiser tes pensées, ce n'est pas un optimiseur de contexte IA. Prétendre le contraire, c'est de la confusion volontaire ou involontaire entre deux outils qui ne se parlent pas.

Ce qu'on ne te dit pas sur les skills et les hooks

Derrière beaucoup de ces setups, il y a un repo à cloner, un skill à installer, parfois les deux. Et c'est là que ça devient moins innocent.

Un skill Claude Code, c'est du code qui s'exécute dans ton environnement avec les permissions de ton agent. Un hook shell, c'est un script qui tourne automatiquement à chaque action de Claude (lecture de fichiers, écriture, exécution de commandes). Est-ce que tu as lu le code du dernier skill que tu as installé ? Ligne par ligne ? La réponse honnête pour la majorité des gens qui suivent ces tutoriels, c'est non. On voit la démo, on fait confiance à l'auteur, on installe.

Le vrai modèle économique de la tendance

Regarde la structure de ces contenus : un lien ou un code promo vers Obsidian Sync (la version payante), un badge GitHub qui pousse à star le repo, souvent une pub pour un cours ou une newsletter en fin de vidéo. Le "workflow révolutionnaire" est le vecteur, le produit c'est ce qui est vendu autour.

Ce n'est pas forcément cynique, des gens partagent sincèrement leur setup. Mais le résultat pratique est que des devs passent une après-midi à configurer un système de notes plutôt qu'à coder, en croyant optimiser leur productivité avec l'IA. La configuration, c'est la procrastination la mieux habillée qui existe.

Le contexte utile pour Claude, c'est du texte clair sur ton projet, pas une architecture de vault à entretenir.

Ce qui fonctionne vraiment

Quelques pratiques concrètes, sans plugin tiers.

La mémoire native de Claude Code. Claude Code a un système de mémoire intégré autour de fichiers CLAUDE.md en clair, pas un format propriétaire caché. La commande /memory ouvre directement ce fichier (celui du projet à sa racine, ou le ~/.claude/CLAUDE.md global pour tes préférences transverses) dans ton éditeur, pour que tu le retouches toi-même. Rien à synchroniser, rien à indexer : c'est le même fichier texte que celui que Claude charge au démarrage de chaque session. Si ton besoin c'est "que Claude se souvienne de mes préférences", c'est là que ça se passe, pas dans Obsidian.

Côté fichiers, mieux vaut petit et ciblé : un CLAUDE.md qui fait 500 lignes est contre-productif, tout le fichier est chargé en contexte à chaque session, que tu en aies besoin ou non. Plusieurs fichiers spécialisés (CONVENTIONS.md, ARCHITECTURE.md, TODO.md), en ne pointant que celui dont tu as besoin selon la tâche, consomment moins de tokens pour un contexte plus pertinent.

Les hooks de Claude Code servent justement à ça, injecter du contexte au bon moment. Si tu veux vraiment automatiser l'injection de contexte, ils te permettent d'exécuter un script avant ou après certaines actions. Ce script peut lire un fichier, appeler une API, générer du texte. C'est toi qui écris le script, tu sais exactement ce qu'il fait. Pas besoin d'un repo tiers pour ça, c'est dans la doc officielle, section Hooks.

Dernier point, souvent ignoré : la status bar. En bas de ton terminal Claude Code, il y a une barre de statut configurable qui affiche en temps réel les tokens consommés (input/output/cache), le coût estimé de la session en euros, et le pourcentage de fenêtre de contexte utilisée avec un code couleur vert/jaune/rouge. Elle se configure via un script shell dans ~/.claude/statusline-command.sh. Beaucoup de gens ne savent pas qu'elle existe. C'est pourtant le seul endroit où tu vois vraiment ce que tu consommes, sans plugin, sans dashboard tiers. Si tu veux optimiser tes tokens, commence par regarder là avant de monter un vault Obsidian.