Comment Obsidian, un agent Claude Code et deux routines cloud programmées maintiennent, sans intervention manuelle sur le contenu, ma base de connaissances qui s’enrichit chaque jour ?
Le problème que je voulais éviter
Un chatbot branché sur mes notes, qui va chercher un passage pertinent à chaque question c’est le réflexe RAG. Ça marche, mais ça ne construit rien : la mille et unième question repart de zéro, comme la première.
Ce que je voulais, c’est l’inverse : un système qui accumule seul des entrées. Chaque source que je lis, chaque flux que je surveille, chaque question que je pose à Claude devrait laisser une trace structurée, reliée au reste de mon contenu, consultable directement et, sans repasser par le modèle qui l’a écrite.
Le modèle vient d’un texte d’Andrej Karpathy, repris ensuite sous le nom de LLM wiki : au lieu d’interroger un moteur de recherche vectorielle à la volée, on confie à un agent IA le rôle de bibliothécaire. Il lit mes sources, en extrait la substance, écrit le résultat dans des pages Markdown normales (et universelles), et relie ces pages entre elles. Moi je choisis les sources et je pose les questions; lui synthétise, classe, et signale les contradictions plutôt que de les écraser silencieusement (ou d’en créer des doublons).
Règle importante du contrat:
« Ne jamais écraser silencieusement une affirmation contredite. Si une nouvelle source contredit une page existante, documenter les deux versions avec leurs sources et dates, et le signaler explicitement. »
Cela permet de garder une ouverture d’esprit enrichie de contradictions.
Trois couches, une seule règle absolue
Le coffre Obsidian est organisé en trois couches, et une seule règle en régit l’articulation : les sources brutes ne sont jamais modifiées par l’agent.
Vous voyez ci-dessous que les dossiers Clippings/ et Sources/ ne seront jamais modifiés par Claude.
Ce sont des dossiers immuables.
A noter: j’ai installé le plugin Chrome Obsidian web clipper pour sauvegarder les pages web dans les dossier Clippings/ de mon coffre fort Obsidian.
Structure de mon coffre Obsidian:
├── Clippings/ ← sources brutes (web, articles) — IMMUABLE, ne jamais modifier
├── Sources/ ← sources brutes structurées (livres, images, couvertures) — IMMUABLE
├── Wiki/ ← couche compilée, entièrement gérée par toi
│ ├── hot.md ← cache de contexte récent (~500 mots), premier fichier du Wiki/ lu à chaque session
│ ├── index.md ← catalogue de tout le wiki
│ ├── log.md ← journal chronologique (append-only)
│ ├── Entités/ ← personnes, organisations, lieux, outils
│ ├── Concepts/ ← idées, thèmes, méthodes, comparaisons de fond
│ ├── Résumés/ ← une page de compilation par source ingérée (1 page = 1 source)
│ └── Synthèses/ ← réponses de requêtes qui valent la peine d’être conservées, comparaisons transversales
└── CLAUDE.md ← ce fichier, le contrat que tu suis
Dossiers immuables:
Clippings/ et Sources/
Articles web clippés, PDF, fiches de livres/films/jeux, flux RSS bruts, digests de veille: la matière première de mon wiki, jamais éditée par l’agent.
Lecture seule, ne seront jamais réécrits par l’agent.
Dossiers et fichiers compilé:
Wiki/
Entités, Concepts, Résumés, Synthèses (voir arborescence ci-dessus): entièrement écrit et maintenu par l’agent, plus quatre fichiers de pilotage : hot.md, index.md, log.md, graph.canvas.
Le tout obéit à un simple fichier markdown, CLAUDE.md à la racine du coffre, un contrat écrit une fois, relu par l’agent au début de chaque session, qui fixe les conventions de nommage, le frontmatter YAML standard, le format des dates et heures (JJ-MM-AAAA et HH:mm sans exception) et les wikilinks [[Nom de la page]] pour tout relier.
Les quatre fichiers qui pilotagent mon Wiki
Cache de contexte: ~500 mots maximum. Remplacé entièrement à chaque fin de session: ce n’est pas un historique mais une mémoire de travail pour l’agent. Je peux donc en reprendre certaines actions qui se seraient mal passées. C’est le premier fichier lu au début d’une session, il évite de rejouer toute la conversation précédente et ainsi limiter la cosommation de tokens de Claude.
Journal chronologique: log.md en « append-only ». Chaque session y ajoute une entrée horodatée (ingestion, requête ou maintenance) résumant ce qui a été fait, jamais réécrit, seulement complété par l’agent IA.
Catalogue: toutes les pages du wiki, classées par catégorie (et par ordre chronologique, la plus ancienne entrée en haut du wiki). Consulté avant toute création de page pour éviter les doublons: enrichir une page proche plutôt qu’en dupliquer une, ceci afin de ne pas surcharger le wiki de pages sensiblements identiques et d’en affiner le contenu.
Carte visuelle curatée: au format ouvert JSON Canvas, ouvrable dans Obsidian. Ce n’est pas une réplique de la vue Graph native (qui montre déjà tous les liensentre les entrées du wiki), c’est une sélection des pages les plus centrales, régénérée entièrement à chaque session et mise en page sous forme de carte mentale (ce que l’on nomme un canvas).
Les outils qui font tourner la mécanique
Assemblage de plusieurs couches de logiciels et d’outils (locaux et dans le cloud) qui me permettent à chaque niveau de corriger/modifier chacune des entrées si je le désire. Fléxibilité.
Obsidian
L’application de prise de notes elle-même : un coffre de fichiers Markdown locaux, sans base de données propriétaire, les fichiers .MD peuvent êtres lus sur n’importe quel système autre système, aucun fichier n’est propriétaire à Obsidian, et c’est la force de cette application. Si demain Obsidian ferme ses portes je ne perds aucun contenu.
Principe fondateur: « file over app » je garde le contrôle sur mes fichiers, quelle que soit l’app qui les affiche.
Claude Code
L’agent de codage en ligne de commande d’Anthropic (modèle Claude Sonnet 5). C’est lui qui lit CLAUDE.md, lui qui exécute les workflows d’ingestion/requête/maintenance, lui qui écrit directement dans Wiki/.
Si Claude à un doute, il me demanderra ce qu’il doit faire et comment il devra agir sur mon Wiki.
Git & GitHub
Le dépôt mon-coffre-obsidian est la colonne vertébrale de toute l’automatisation : c’est l’état partagé entre mon PC (et mon iPhone) et les agents qui tournent dans le cloud, sans accès direct à ma machine. Mes routines Claude n’interagissent en direct qu’avec mon dépôt GitHub, jamais en direct sur ma machine locale.
Routines cloud planifiées
Une fonctionnalité de Claude Code : programmer un agent pour s’exécuter à heure fixe, indépendamment de mon ordinateur, avec accès au dépôt GitHub pour committer ses résultats.
J’ai deux routines:
- 1- Recherche automatique d’articles nouvellement publiés sur internet en rapport direct avec des sujets déffinis par moi-même (à 09h00 chaque matin),
- 2- Recheche de nouvelles entrées sur une liste de flux RSS que j’ai constitué (à 09h20 chaque matin).
PowerShell
Scripts écrits à la volée par l’agent pour parser des flux RSS/Atom trop volumineux pour une lecture directe (certains fichiers dépassent 1 Mo): extraction XML générique, gestion RSS 2.0/RDF/Atom.
Ainsi, mon agent agent sait lire n’importe quel flux de données pour en saisir l’essence.
Poppler (pdftotext)
Installé à la demande (Claude Code m’a demandé si je l’autorisais à l’installer) pour extraire le texte de gros fichiers PDF (Par exemple: le DSM-5 qui fait 1275 pages) dépassant la limite de lecture directe de l’agent.
Recherche & récupération web
Utilisées par les routines et par moi pour aller chercher le contenu réel d’un article derrière son flux RSS, et contourner au cas par cas les blocages anti-bot (nature.com, wired.com, arstechnica.com…).
Markdown + YAML + JSON Canvas
Les formats eux-mêmes : texte brut, portable, lisible sans outil propriétaire, la condition pour que tout ce système reste inspectable et versionnable dans Git.
Comment je l’ai construit, étape par étape ?
Dans l’esprit du journal Wiki lui-même, chaque entrée datée, typée, et brève. Voici la séquence réelle de mise en place:
Étape 1 · Fondation
Choisir Obsidian et désigner le coffre
Un dossier local de fichiers Markdown, sans plugin communautaire n’est requis. Décision de principe : rien dans Wiki/ ne serait jamais tapé à la main, uniquement écrit par l’agent, basé sur des sources que je lui fournis.
Étape 2 · Contrat
Écrire CLAUDE.md
Le document fondateur : rôle de l’agent (« bibliothécaire », pas simple assistant de recherche), architecture en trois couches, conventions de nommage en français naturel, frontmatter YAML standard, règles strictes (jamais halluciner, toujours vérifier l’index avant de créer une page, jamais éditer Clippings/ ou Sources/ ni mes dossiers contenants des documents personnels).
Étape 3 · Squelette
Créer l’ossature du Wiki/
index.md, log.md, hot.md, un graph.canvas vide ({}), et les quatre dossiers Entités/, Concepts/, Résumés/, Synthèses/. Rien dedans encore, seulement la structure que le contrat décrit.
Étape 4 · Ingestion
Premier lot de sources
Le texte de Karpathy lui-même, discuté ligne par ligne avec l’agent avant qu’il n’écrive quoi que ce soit.
Première page Résumé, premier Concept, première Entité créés (le format se stabilise en le faisant, pas en le théorisant à l’avance).
Étape 5 · Versionnement
Initialiser Git et créer le dépôt GitHub
git init, création du dépôt Nikalo71/mon-coffre-obsidian, remote add origin, premier commit et push.
Important: À partir de là, le coffre a un état partageable, condition nécessaire à tout ce qui suit. J’ai passé mon dépôt GitHub en « non partagé » une fois le processus terminé et après avoir retiré le contenu de mon wiki pour n’y laisser que son squelette.
Étape 6 · Automatisation 1
Programmer la routine « Veille matinale »
Une routine cloud planifiée à 9h (Europe/Paris) : chaque matin, un agent cherche une dizaine d’actualités IA générative / vibe coding / second cerveau, rédige un digest daté, et le committe dans Sources/Routines/AAAAMMJJveilleiavibecoding.md avant de pousser sur main.
Étape 7 · Automatisation 2
Programmer la routine « Veille RSS »
Une seconde routine, 20 minutes plus tard (9h20), distincte de la première : elle applique directement la procédure de rafraîchissement décrite dans CLAUDE.md à tous les flux Sources/RSS/*.md — identifie les articles plus récents que la dernière mise à jour de chaque page Résumé correspondante, en récupère le contenu réel, et le pousse également sur main.
Étape 8 · Boucle quotidienne
Pull, puis ingestion
Les deux routines poussent directement sur origin/main; le coffre local ne les voit qu’après un git pull.
Les digests qu’elles produisent restent des sources comme les autres : c’est une session « ingest » avec Claude Code, qui décide ensuite ce qui mérite d’entrer dans Wiki/.
Étape 9 · Maintenance
Vérifications périodiques
Sessions dédiées : cohérence entre index.md et les fichiers réels, pages orphelines sans lien entrant, doublons, contradictions non résolues, hot.md devenu trop long. Le wiki ne grossit pas seulement, il s’auto-corrige.
Le circuit complet, en une journée:
Une fois les étapes 6 à 9 en place, voici ce qui se passe chaque matin :
- 9h00: Veille matinale – routine sur le cloud
- 9h20: Veille RSS – routine sur le cloud
- GitHub · main – automatique, alimenté par les routines
git pull(local) – commande terminal VS Code non necessaire chaque jour- Session « ingest » – lancé par moi-même dans le termial VS Code
- Claude Code trie, compile, relie.
Les deux routines ne se coordonnent pas entre elles, elles tournent en parallèle, sur le même dépôt. Ce n’est pas anodin : la première fois qu’elles ont produit un digest à la même heure, elles avaient sélectionné des actualités largement différentes. Plutôt que de fusionner silencieusement les deux fichiers, le contrat impose de documenter les deux comme des sources distinctes: l’anomalie devient deux notes dans le wiki, pas une correction invisible.
Ce que ça donne, avec ses limites:
- 288 pages dans Wiki
- 32 flux RSS suivis
- 2 routines cloud quotidiennes
- ~500 mots max dans hot.md
Ce que le système fait bien : il ne repart jamais de zéro. Une contradiction entre deux flux sur un même modèle d’IA est documentée avec ses deux sources plutôt que tranchée arbitrairement; une page proche existante est enrichie plutôt que dupliquée; une source mal étiquetée à l’origine (un flux « Google research blog » qui s’est révélé être un site satirique allemand, des filtres RSS annoncés mais non fonctionnels côté serveur) est signalée comme fait sur la source, pas corrigée en douce.
Ce qu’il ne fait pas:
Mes bibliothèques de: livres, films et jeux cataloguées (des bases dans le logiciel Obsidian) restent des fiches éditeur non lues/non vues.
Le wiki documente honnêtement qu’elles n’ont pas encore de substance à compiler, plutôt que d’inventer un contenu qui n’existe pas.
Incident réel, corrigé en session:
index.md s’est retrouvé un jour dupliqué en deux passes quasi identiques:
558 lignes au lieu de 320, probablement un mauvais collage lors d’une édition antérieure. Détecté simplement en relisant le fichier avant une ingestion, reconstruit à partir de la version la plus complète de chaque section.
Rien n’a distingué cet incident d’un bug logiciel classique : il a fallu le remarquer et non pas l’anticiper.