Agent IA et plugin Obsidian : ce qui marche vraiment
Connecter un agent IA à Obsidian, ce n’est pas juste installer trois plugins et espérer que ça marche.
Un vault Obsidian, c’est ta mémoire externe : notes, projets, décisions, connaissances accumulées. Un agent IA peut lire dedans, comprendre le contexte, et produire quelque chose d’utile. Mais Obsidian n’a pas été conçu comme une base de données ouverte. Ses fichiers sont en Markdown, ses liens en wikilinks, et son écosystème de plugins évolue vite.
Résultat : toutes les solutions ne se valent pas. Certaines lisent mais n’écrivent pas. D’autres écrivent mais cassent les liens. D’autres encore promettent une recherche sémantique mais s’arrêtent aux dix premiers fichiers.
Ton IA manque peut-être surtout de contexte.
Fais le point sur ton organisation, ta mémoire IA et les règles qui doivent guider tes agents. En quelques minutes, tu obtiens un diagnostic clair pour repartir sur une base propre.
Gratuit, sans engagement.
Voici ce qui marche vraiment, sans le bruit.
Le minimum viable pour connecter un agent IA
Tu n’as pas besoin de huit plugins. Tu as besoin de trois choses : lire le vault, écrire dedans, et ne pas tout casser.
La combinaison qui tient la route : Local REST API pour lire, Templater pour écrire, Git pour versionner. Le reste est optionnel. Et parfois contre-productif.
Lire le vault sans le casser
Pour qu’un agent IA travaille avec ton vault, il doit d’abord pouvoir le lire. Trois approches existent. Une seule est vraiment indispensable.
| Plugin | Ce qu’il fait | Pour qui |
|---|---|---|
| Local REST API | Expose le vault en lecture seule via un serveur local. Liste les fichiers, lit le Markdown, récupère les métadonnées. | Tout le monde. C’est le point de départ. |
| Obsidian Git | Versionne le vault et permet à un agent de cloner le dépôt pour lire les fichiers en batch. | Ceux qui acceptent un léger délai et veulent un historique. |
| Dataview | Requêtes sur le vault comme une base de données. Extrait des listes selon tags, frontmatter, liens. | Ceux qui ont déjà un vault bien tagué et structuré. |
Local REST API est le plus direct. Il crée un serveur local, tout reste sur ta machine, et n’importe quel agent capable d’appeler une API REST peut s’en servir. Pas de cloud, pas de dépendance externe. La limite : lecture seule, pas de recherche sémantique.
Obsidian Git est utile si tu veux un accès batch plutôt que temps réel. L’agent clone le dépôt, lit les fichiers, analyse l’historique. L’avantage : pas de limite de taille, pas de serveur à maintenir. L’inconvénient : pas d’accès instantané, et des conflits de merge possibles si vous modifiez la même note en parallèle.
Dataview est puissant si ton vault est déjà bien structuré. Tu peux demander « toutes les notes avec le tag décision créées ce mois-ci » et l’agent récupère la liste. Mais si ton vault n’est pas propre, Dataview ne te sauvera pas.
Écrire dans le vault sans tout faire sauter
L’écriture, c’est là où ça se complique. Un agent qui écrit dans ton vault peut créer une note utile. Il peut aussi corrompre un fichier, écraser une décision, ou générer du bruit que tu mettras des semaines à nettoyer.
Deux plugins sortent du lot pour l’écriture contrôlée.
Templater permet de générer des notes à partir de templates et d’exécuter du JavaScript pour modifier des fichiers. Un agent peut créer une nouvelle note avec un template prédéfini, mettre à jour le frontmatter, ou insérer du contenu généré à un endroit précis. C’est puissant, mais ça demande de comprendre l’API de Templater et de bien écrire les scripts.
QuickAdd est plus simple : des macros pour ajouter rapidement du contenu. L’agent peut ajouter une tâche, créer une note, insérer un bloc de texte. Pas besoin de JavaScript. La limite : actions prédéfinies uniquement, pas de modification en profondeur.
Advanced Obsidian URI existe aussi, mais je le mentionne pour dire de ne pas l’utiliser pour ça. Les URLs sont accessibles à tout processus sur ta machine, et il n’y a pas de lecture du vault. Trop limité, trop exposé.
La recherche sémantique, est-ce que ça vaut le coup
La recherche classique d’Obsidian (Ctrl+O) trouve des mots-clés. La recherche sémantique comprend le sens des notes. C’est séduisant sur le papier.
Obsidian Text Generator utilise des modèles d’embeddings locaux pour trouver des notes similaires et répondre à des questions en contexte. Avantage : tout en local, pas de cloud. Inconvénient : générer des embeddings pour 10 000 notes peut prendre des heures, et les modèles locaux sont moins précis que les modèles cloud.
Obsidian Search Assistant ajoute une couche d’IA à la recherche native. Il reformule les requêtes en langage naturel. Avantage : léger et rapide. Inconvénient : dépendance au cloud, pas de véritable compréhension sémantique.
Mon avis : commence sans. La recherche sémantique est utile quand tu as des milliers de notes et que tu ne sais plus où se trouve l’information. Mais si ton vault est bien structuré avec des liens clairs, la recherche native suffit largement. Ajoute la recherche sémantique seulement quand tu te retrouves bloqué.
Les trois pièges qui cassent tout
J’ai vu trois patterns revenir, et ils font tous mal.
Premier piège : les permissions. Un serveur local expose ton vault à tout processus sur ta machine. Les solutions cloud comme Obsidian Sync ne donnent pas accès au système de fichiers. La solution : utilise un vault local synchronisé avec Git, et fais travailler l’agent sur une copie.
Deuxième piège : les formats. Les wikilinks ne sont pas du Markdown standard. Le frontmatter YAML n’est pas toujours bien interprété par les outils externes. Certains plugins ajoutent des syntaxes propriétaires. La solution : standardise tes templates et documente les formats de ton vault.
Troisième piège : les boucles. Un agent qui modifie une note pendant que tu travailles dessus, ça crée des écrasements. Pire : un agent qui modifie une note qui déclenche une action qui modifie la note à nouveau. La solution : travaille en asynchrone sur une copie, ou utilise un fichier .lock pour indiquer qu’une note est en cours de modification.
Le workflow qui tient avec Hermes
Voici la combinaison que j’utilise et qui ne casse pas.
- Installe Local REST API pour donner à Hermes un accès en lecture à ton vault.
- Installe Templater pour permettre à Hermes de générer des notes via des templates.
- Synchronise ton vault avec Git pour versionner chaque changement.
- Fais travailler Hermes sur une copie locale, pousse les modifications, et synchronise avec Obsidian.
Les avantages : pas de conflit, pas de risque de corruption (Git permet de revenir en arrière), et flexibilité pour utiliser d’autres outils en parallèle. La contrepartie : un délai entre la modification et la synchronisation, et la nécessité de gérer Git.
Si tu veux comprendre pourquoi Obsidian est un bon socle au départ, lis pourquoi Obsidian fonctionne bien comme second cerveau. Si tu veux la méthode complète pour brancher Hermes à ton système, intégrer Hermes Agents à ton second cerveau te donne le pas à pas. Et si tu n’as pas encore posé le cadre global, commence par comprendre ce qu’est un second cerveau.
En pratique : installe Local REST API et Templater. Synchronise avec Git. Donne à ton agent un accès en lecture via l’API REST, et laisse-le écrire via Templater sur une copie. C’est simple, ça marche, et tu gardes le contrôle.
