Comment mon agent IA travaille avec Obsidian sans décider à ma place

Pendant longtemps, j'ai accumulé des informations plus vite que je ne pouvais les exploiter.

Un article finissait dans mes favoris. Une idée dans Apple Notes. Une décision au milieu d'une Daily Note. Un onglet restait ouvert pendant trois semaines parce que je voulais « le lire plus tard ».

Le problème n'était pas la capture. J'étais même plutôt bon pour ça. Il commençait après : retrouver l'information, comprendre pourquoi je l'avais conservée et la relier à ce sur quoi je travaillais.

J'utilise Obsidian depuis plusieurs années. Mon organisation existait donc bien avant que j'y connecte un agent IA. C'est important, parce que l'agent n'a pas créé le système. Il est venu se greffer sur des habitudes, une structure et des règles déjà utilisées au quotidien.

Aujourd'hui, mon vault Obsidian vit dans un dépôt GitHub privé. Hermes, mon agent IA, tourne sur un VPS. Discord me sert d'interface pour lui parler. Le Mac peut être éteint : le serveur conserve une copie locale du dépôt, lit les notes et exécute les workflows prévus.

Sur le papier, l'architecture est simple.

Discord → Hermes sur un VPS → dépôt GitHub privé → Obsidian

La difficulté n'a jamais été de connecter les quatre briques. Le vrai travail a été de décider ce qui devait circuler entre elles, où l'agent pouvait écrire et à quel moment il devait s'arrêter.

Le vault reste la source de connaissance

Je n'utilise pas Discord comme une base de connaissances. Discord transporte une demande. Obsidian conserve ce qui mérite de l'être. Cette distinction évite de construire un deuxième système de notes dans un outil de messagerie.

Le vault contient des fichiers Markdown ordinaires. Je peux les lire dans Obsidian, les modifier dans VS Code, les versionner avec Git ou les exploiter avec un autre outil demain. Mes notes ne dépendent pas d'un format que seul un service sait ouvrir.

Le dépôt privé apporte trois choses utiles :

• une copie accessible au serveur ;
• un historique précis des modifications ;
• une manière simple de synchroniser le travail de l'agent avec mes appareils.

Sur mon Mac, le plugin Obsidian Git récupère et pousse régulièrement les changements. Sur mon téléphone, Obsidian Sync me donne accès au vault complet. Le VPS, lui, travaille directement sur sa copie du dépôt, puis pousse ses modifications une fois le résultat vérifié.

Git ne décide pas si une modification est autorisée. Il montre ce qui a changé et permet de revenir en arrière. C'est une couche de traçabilité et de réversibilité, pas un système de permissions.

L'organisation existait avant l'agent

À l'intérieur du vault, j'utilise une adaptation de PARA :

• les projets correspondent à des résultats avec une fin ;
• les casquettes regroupent les responsabilités que je maintiens dans le temps ;
• les ressources conservent les références qui pourront resservir ;
• les archives retirent de la vue active ce qui n'a plus de rôle aujourd'hui.

J'y ai ajouté une Inbox, un Journal, un Garden et des MOC. L'Inbox reçoit les captures qui n'ont pas encore été arbitrées. Le Journal conserve la chronologie de mes journées. Le Garden accueille les idées que j'ai reformulées et reliées avec mes propres mots. Les MOC servent de portes d'entrée vers plusieurs notes autour d'un même sujet.

Les dossiers répondent à une question opérationnelle : à quoi cette note sert-elle maintenant ? Les liens répondent à une autre question : avec quelles idées est-elle en relation ?

C'est aussi pour cela que les backlinks m'intéressent. Pas pour obtenir un joli graphe, mais pour retrouver les relations entre une décision, le projet qui l'a fait naître et les idées qu'elle a produites ensuite.

Hermes peut lire cette structure. Il ne doit pas pour autant décider seul de la place définitive d'une information.

Discord est la télécommande, pas le cerveau

J'ai séparé plusieurs usages dans Discord : capture rapide, recherche, contenu, maintenance du système et conversations générales.

Le bénéfice est surtout pratique. Je vois immédiatement dans quel contexte j'écris, et je peux associer des règles différentes aux workflows spécialisés. Un message envoyé dans un espace de capture ne déclenche pas le même traitement qu'une demande de modification du système.

Au départ, j'avais résumé ça par « un channel = un contexte ». La réalité technique est un peu plus précise : Hermes isole les conversations en sessions et peut leur injecter des consignes adaptées. Le nom du channel ne produit aucune magie à lui seul.

Discord correspond bien à ma manière de séparer visuellement les usages. Ce choix n'implique pas qu'un autre outil de messagerie soit incapable d'obtenir une isolation comparable.

Surtout, je n'y colle jamais de clé API, de mot de passe, de token ou de document client confidentiel. Discord transporte la demande, pas le secret.

Ce qui se passe quand je lui envoie un lien

Prenons le workflow le plus simple. Je découvre un article dans le train et je veux le conserver. Je l'envoie dans mon espace de capture avec quelques mots sur ce qui m'intéresse.

Hermes suit alors une procédure connue :

1. il ouvre la source originale ;
2. il en extrait le contenu utile ;
3. il prépare une synthèse courte ;
4. il crée une note dans l'Inbox avec l'URL, la date et le statut de capture ;
5. il vérifie le fichier créé ;
6. il commit et pousse la modification ;
7. il me confirme où la note a été déposée.

Quand Obsidian se synchronise, la capture apparaît sur mes autres appareils.

À ce stade, l'agent n'a pas décidé que l'article était vrai, important ou digne d'intégrer mon Garden. Il a seulement transformé un message volatil en une capture structurée et retrouvable. Lors de ma revue, je peux supprimer la note, la laisser comme ressource, l'associer à un projet ou en extraire une idée durable. Cette décision reste humaine.

C'est un détail qui change tout. Automatiser la capture me fait gagner du temps. Automatiser sans contrôle la transformation d'une capture en connaissance ferait entrer du bruit dans le système avec une apparence d'autorité.

Une capture, une hypothèse et une décision n'ont pas le même poids

Chaque note importante déclare ce qu'elle est. Une capture dit : « j'ai trouvé cette information ici ». Une hypothèse dit : « je pense que cette explication mérite d'être testée ». Une décision dit : « voici la règle que j'applique maintenant ».

Sans cette distinction, un agent peut ressortir une intuition ancienne avec l'assurance d'une décision récente. Le texte est présent dans le vault, donc il semble disponible et crédible. Mais sa présence ne dit rien de son statut.

C'est l'un des défauts des systèmes qui promettent une mémoire infinie. Stocker davantage ne suffit pas. Il faut aussi savoir d'où vient une information, quand elle a été produite, dans quel contexte et avec quel niveau de confiance.

J'essaie donc de séparer plusieurs couches :

• la session contient le travail en cours ;
• la mémoire persistante conserve quelques faits durables et préférences ;
• les skills décrivent des procédures réutilisables ;
• Obsidian contient la connaissance de travail ;
• la source originale sert à vérifier un état actuel.

Mon vault peut être bien organisé et contenir une information devenue fausse. Si je veux savoir si un post est publié, je vérifie X. Si je veux connaître l'état d'un dépôt, je vérifie Git. Si je veux confirmer une configuration, j'inspecte le système réellement appliqué.

Obsidian conserve le raisonnement. Il ne remplace pas la réalité extérieure.

L'espace d'écriture libre reste l'Inbox

La règle initiale de mon système tient en une phrase : Hermes peut capturer dans l'Inbox. Ailleurs, il propose ou attend une demande explicite.

Cette règle n'interdit pas toute modification hors de l'Inbox. Si je lui demande clairement de mettre à jour une note précise, il peut le faire, puis vérifier le diff, commit et pousser. La différence est que l'initiative et le périmètre viennent de moi.

Je ne veux pas qu'un processus planifié se réveille à cinq heures du matin, parcoure le vault et réorganise ce qu'il considère comme mal classé. Il pourrait réussir neuf fois et supprimer une nuance importante la dixième.

À l'inverse, la création d'une capture dans un dossier prévu est une action bornée : l'entrée est connue, la destination est connue, le format est connu et Git garde une trace.

Le bon niveau d'autonomie dépend donc moins de la capacité du modèle que du coût d'une erreur.

Ce que l'agent peut faire seul

Dans un workflow déjà validé, Hermes peut :

• lire une source publique et la résumer ;
• rechercher dans mes notes ;
• créer une capture dans l'Inbox ;
• préparer un briefing ou un brouillon ;
• appliquer une procédure connue sur des fichiers ciblés ;
• vérifier le résultat et laisser une trace dans Git.

Je n'ai pas besoin d'approuver manuellement chaque sous-étape. J'ai déjà approuvé le workflow, sa destination et ses limites.

C'est différent d'une autorisation générale d'utiliser tous les outils disponibles. Le fait que l'agent possède un terminal ne l'autorise pas à lancer n'importe quelle commande. Le fait qu'il puisse modifier un fichier ne l'autorise pas à réécrire tout le vault.

Une capacité technique répond à « est-ce possible ? ». Une permission répond à « est-ce autorisé ici ? ».

Ce qui reste sous validation humaine

Ma consigne globale est simple : l'agent ne publie rien, n'envoie rien, ne supprime rien et ne modifie rien d'important sans validation explicite.

Il peut analyser mes anciens contenus et préparer un article. Il ne décide pas que cet article est prêt à être publié. Il peut préparer un message destiné à quelqu'un. Il ne l'envoie pas. Il peut trouver une contradiction entre deux notes. Il ne choisit pas seul celle qui doit devenir la nouvelle référence. Il peut proposer une modification de configuration. Il ne l'applique pas simplement parce qu'elle semble logique.

Je conserve donc un point d'arrêt avant les actions qui :

• sortent du système vers l'extérieur ;
• modifient durablement une source de confiance ;
• exposent des informations sensibles ;
• produisent un coût difficile à annuler.

Les automatisations ne méritent pas toutes de rester actives

J'ai testé plusieurs tâches planifiées, notamment des briefs préparés et livrés dans Discord.

Le piège consiste à conserver une automatisation uniquement parce qu'elle fonctionne. Un résultat qui arrive chaque matin peut devenir une nouvelle pile à lire, puis un nouveau bruit à ignorer.

Mon brief planifié est aujourd'hui en pause. Ce n'est pas un échec du système. C'est la preuve qu'une automatisation doit continuer à justifier sa place.

Avant d'en maintenir une, je veux pouvoir répondre à quelques questions :

• qu'est-ce qui la déclenche ?
• quelles sources peut-elle consulter ?
• où dépose-t-elle son résultat ?
• que se passe-t-il si une source est inaccessible ?
• quelle décision reste humaine ?

« Ça tourne pendant que je dors » n'est pas un critère de qualité.

Ce que le système a réellement changé

Je capture plus facilement ce qui mérite une seconde lecture, mais surtout je sais où cette capture va arriver.

Je peux demander une recherche depuis mon téléphone et retrouver le résultat dans le même environnement que mes projets et mes notes. Une idée saisie rapidement ne dépend plus d'un onglet ouvert ou de ma mémoire du moment.

Le Journal conserve aussi le contexte de mes journées. Ma Daily Note se crée automatiquement et j'y ajoute quelques lignes lorsque je change de tâche : ce qui vient de se terminer, ce que j'ai décidé et ce qui vient ensuite. Je n'ai pas à reconstruire toute la journée le soir.

Une fois par semaine, je consacre environ vingt à trente minutes à la revue. Je vide l'Inbox, supprime le bruit, rapproche certaines captures, transforme les idées utiles et vérifie ce qui mérite encore une place active.

L'agent accélère la collecte et certaines transformations. La revue empêche cette vitesse de recréer le désordre qu'elle devait supprimer.

Le gain le plus important n'est donc pas « une IA qui écrit dans mes notes pendant que je travaille ». C'est un circuit plus fiable entre le moment où une information apparaît et celui où je décide de ce qu'elle devient.

Les limites que je garde volontairement

Ce système demande encore de l'entretien. Git peut signaler un conflit. Une extraction web peut échouer. Une note peut être correctement créée mais inutile. Une source peut avoir changé depuis sa capture. Un agent peut produire une synthèse propre qui rate le point important.

Je dois aussi résister à la tentation d'ajouter un workflow pour chaque friction rencontrée. Une automatisation apporte sa propre maintenance, ses cas limites et ses erreurs possibles.

Enfin, mon architecture correspond à ma manière de travailler. Elle n'est pas une recette universelle. Quelqu'un qui ne tient pas de Daily Notes, ne fait jamais de revue et n'utilise pas les liens entre ses idées obtiendra probablement un autre cimetière de notes, simplement alimenté plus vite.

L'agent amplifie le système sur lequel on le branche. S'il n'y a ni structure, ni règles, ni habitude d'arbitrage, il amplifie aussi le désordre.

Si je devais reconstruire le système depuis zéro

Je n'installerais pas l'agent en premier.

Je commencerais par une Inbox unique et une Daily Note. J'utiliserais le système assez longtemps pour voir où l'information se perd réellement. J'ajouterais ensuite une structure simple, une sauvegarde fiable et une revue hebdomadaire. Git viendrait après, pour rendre les changements visibles et récupérables.

L'agent arriverait seulement quand les tâches répétitives seraient devenues évidentes : extraire une source, créer une capture, retrouver un contexte, préparer une synthèse.

L'ordre compte :

1. une zone de capture ;
2. une habitude quotidienne ;
3. une structure compréhensible ;
4. une sauvegarde et un historique ;
5. une revue humaine ;
6. l'agent ;
7. les automatisations.

Commencer par l'agent pousse à inventer des usages. Commencer par le travail réel permet d'automatiser une friction déjà observée.

Ce système personnel est aussi mon laboratoire

Je construis aujourd'hui des systèmes IA pour des consultants, indépendants et petites équipes. Le contexte change, les outils aussi, mais les questions restent proches de celles rencontrées dans mon propre système. Où se trouve l'information ? Quelle tâche revient chaque semaine ? Quelles sources doivent être consultées ? Qu'est-ce que le système peut préparer ? À quel moment doit-il demander une validation ? Comment vérifier ce qu'il a fait et reprendre la main en cas d'erreur ?

Je ne cherche pas l'autonomie maximale. Je cherche le plus petit périmètre capable de retirer une friction réelle, sans retirer à l'humain les décisions qui comptent.

C'est moins spectaculaire qu'un agent à qui l'on donne accès à tout. C'est aussi beaucoup plus proche d'un système que l'on peut utiliser tous les jours.