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.
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 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.
C'est exactement le vecteur classique des supply chain compromises version outillage IA. Pas de malveillance nécessairement, mais le risque existe, et personne dans ces contenus ne le mentionne parce que ça casserait l'ambiance.
Le vrai modèle économique de la tendance
Ces vidéos et repos ont en commun de promouvoir quelque chose : un outil (Obsidian, souvent payant en version sync), un cours, un repo personnel à star, une newsletter. Le "workflow révolutionnaire" est le vecteur, pas le produit.
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.
Un CLAUDE.md de vingt lignes bien écrites battra n'importe quel système Obsidian surchargé. Parce que le contexte utile pour Claude, c'est du texte clair sur ton projet, pas une architecture de vault.
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é. La commande /memory te permet de lui demander de retenir quelque chose pour les prochaines sessions, sans aucun outil externe. Il gère ça tout seul dans des fichiers Markdown locaux. Si ton besoin c'est "que Claude se souvienne de mes préférences", c'est là que ça se passe, pas dans Obsidian.
Des fichiers petits et ciblés. 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. Mieux vaut plusieurs fichiers spécialisés (CONVENTIONS.md, ARCHITECTURE.md, TODO.md) et ne pointer que celui dont tu as besoin selon la tâche. Moins de tokens consommés, contexte plus pertinent.
Les hooks pour injecter du contexte au bon moment. Si tu veux vraiment automatiser l'injection de contexte, les hooks de Claude Code 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.
Bonus : 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.
La plupart des setups Obsidian ultra-configurés cherchent à résoudre un problème que les fonctionnalités natives règlent déjà. RTFM.