Coeur du système
Claude Code (l'agent qui orchestre, manipule les fichiers et structure la pensée) pilote Ollama (le serveur) pour faire travailler le modèle qwen3.6:27b qui est le moteur (la force brute de calcul qui traite le langage) que Claude manipule à distance *
C'est cette séparation qui garantit que votre vault reste "propre" (Markdown structuré par l'agent) et que votre "intelligence" est totalement souveraine (tournant sur vos disques locaux).
Claude Code est un outil spécifique conçu pour travailler étroitement à l'API d'Anthropic.
Règles de fonctionnement
Responsabilité : Claude Code qu'il est le garant de la qualité du prompt (c'est son rôle de harness).
Architecture : qwen3.6:27b est le modèle visé, et que le service d'exécution est Ollama.
Sécurité : pas d'utilisation d'outils externes, pas d'hallucinations pour maintenir la stabilité de votre "Cerveau Canonique".
Claude Code pilote Ollama + qwen3.6:27b
*
"à distance" au niveau logique : Claude Code et Ollama sont deux processus (ou conteneurs) distincts qui communiquent via le réseau (souvent via l'API locale d'Ollama sur le port 11434). Claude Code envoie des requêtes HTTP à Ollama et reçoit les réponses.
"local" au niveau matériel : Puisque les deux tournent sur votre NAS (Volume 3), il n'y a pas de latence internet ni de données quittant votre infrastructure privée. C'est du "distanciel local" (LAN/Localhost).
Dans votre architecture, Claude Code est bien plus qu'un simple copieur de texte : c'est un véritable processeur de contenu (un agent cognitif).
Voici la distinction fondamentale qui prouve qu'il ne se contente pas de copier :
Si Claude Code était un simple copieur, il ferait un cp (copy) ou un mv (move) du texte brut vers le dossier wiki/. Or, Claude Code fait un travail de traitement profond :
Abstraction et synthèse : Il lit une source brute (souvent longue et non structurée) et en extrait l'essence, les concepts clés et les entités.
Structuration : Il réorganise ces informations en Markdown avec une structure standardisée (Frontmatter, sections, titres), ce qui demande une compréhension sémantique.
Connexion (Le graphe de connaissances) : C'est son rôle le plus intelligent. Il analyse la nouvelle note, la compare avec votre index.md et votre base de connaissances existante, et crée des liens [[ ]] pertinents. Un simple copieur ne saurait pas créer ces liens logiques.
Il applique vos règles (le CLAUDE.md) pour transformer des données "brutes" en "connaissances" :
Il gère l'idempotence (évite les doublons).
Il met à jour le journal de bord (log.md).
Il maintient la table des matières (index.md). Ces actions prouvent qu'il possède une conscience de l'état global du vault, là où un simple outil de copie ne voit que le fichier qu'il traite.
C'est ici que votre architecture est brillante :
Ollama/qwen fournit la "capacité de réflexion" (le moteur) : il décode le langage, comprend le sens et génère la nouvelle structure textuelle.
Claude Code fournit la "capacité d'exécution" (l'agent) : il sait quoi demander au moteur, il sait où stocker le résultat, il sait comment valider que le résultat est conforme à vos règles de nommage et de rangement.
En conclusion : Vous avez un système où Claude Code est le processeur/bibliothécaire qui décide et ordonne les changements, et Ollama est l'expert en langage qui rédige les notes. C'est un processus d'enrichissement de la donnée, pas une simple duplication.
Le workflow Obsidian présent insiste bien sur le passage par le dossier d’entrée " Inbox ", puis un déplacement vers un dossier permanent "raw" après traitement. Cela colle très bien à un second cerveau où Claude Code agit comme “processeur” de contenu, pas comme simple copieur de texte.
Dans votre architecture Karpathy musclée, Claude Code crée des notes de synthèse détaillées, et non de simples résumés.
Voici pourquoi cette nuance est fondamentale pour votre second cerveau :
Contrairement à un résumé (qui est souvent une compression passive d'une source pour lecture rapide), la note de synthèse que Claude Code générée dans votre dossier wiki/ est un objet de connaissance structuré. Elle contient :
Les entités et concepts clés extraits de la source.
Des liens bidirectionnels vers d'autres notes existantes dans votre vault (ce qui tisse la toile de votre cerveau).
Un frontmatter YAML qui permet à Obsidian de traiter la note comme une donnée (dates, tags, métadonnées).
Une structure organisée en sections logiques pour permettre une lecture humaine efficace.
Parce que votre instruction (définie dans CLAUDE.md) demande à Claude Code d'identifier les entités et de structurer le contenu. Si Claude Code se contentait de résumer, il perdrait la richesse du contenu original.
Mais, en demandant une synthèse, vous forcez l'agent à :
Hiérarchiser l'information : Distinguer l'essentiel de l'accessoire.
Contextualiser : Remplacer le contenu de la source dans votre propre référentiel situé dans l'index.md (en le reliant à vos concepts existants).
Préparer pour le futur : La note est prête à être réutilisée dans une future recherche ou un futur projet.
raw/)C'est tout l'intérêt de votre architecture en double-couches :
La source dans raw/ est là pour la fidelité (le détail historique).
La note détaillée dans wiki/ est là pour la compréhension (votre synthèse interprétée).
En résumé : Claude Code ne "résume" pas, il "traduit" votre source dans le langage et la structure de votre propre système de connaissances. Il transforme un flux d'informations extérieur (YouTube, PDF, RSS) en une brique de savoir durable pour votre vault. Votre CLAUDE.md garantit que cette synthèse est toujours faite selon vos standards personnels, transformant ainsi votre second cerveau en une base de données vivante et évolutive, pas juste une simple bibliothèque de résumés.
Point de départ de mon système dautomatisation ou manuel
Voici la place précise et le rôle du dossier inbox/ dans votre architecture :
Le dossier inbox/ est situé sur votre NAS, au sein du Volume 1 (/volume1/second-brain/inbox/).
Il fait partie intégrante de votre vault canonique, ce qui permet à Obsidian (sur votre Mac) de le voir immédiatement dès qu'un fichier y est déposé.
Il intervient au tout début de la chaîne de traitement (curation), lors de la Phase de Capture.
C'est le point d'entrée unique pour toutes les sources entrantes (automatiques ou manuelles)
C'est un dossier "pivot" qui fait le pont entre deux mondes :
Côté N8N (Capture) : C'est la destination des automatisations.
Quand n8n détecte une nouvelle vidéo YouTube, un e-mail ou un PDF, il exécute une action de "Move file" ou "Write file" pour déposer le fichier brut dans /volume1/second-brain/inbox/.
À ce stade : n8n agit comme un coursier. Il ne fait qu'une manipulation de fichier. Aucune intelligence (Ollama/Claude) n'est sollicitée ici.
Côté Claude Code (Ingestion) : C'est sa source de travail.
Lorsque le cycle d'ingestion est déclenché par n8n (ou manuellement), Claude Code est instruit de scanner le dossier inbox/.
Dès qu'il y trouve un fichier, il enclenche le protocole d'ingestion (lecture, synthèse via qwen3.6:27b, création de la note dans wiki/, déplacement de la source vers raw/).
C'est votre Sas de d'entrée afin que
vous puissiez déposer un document manuellement depuis votre Mac (via Finder/Obsidian), dans inbox/.
n8n capture un média, et le place dans inbox/.
L'intérêt du système = centraliser toute l'entrée de données au même endroit.
C'est la règle de Claude Code : "Tout ce qui est dans inbox/ doit être ingéré, traité et rangé dans raw/ et wiki/."
C'est le LLM (Ollama / qwen3.6:27b) qui génère le "contenu" intellectuel. Il "rédige" la note, structure les idées et extrait les concepts. Il agit comme l'expert rédacteur.
C'est Claude Code qui génère la structure du fichier. Il "assemble" le fichier Markdown final en ajoutant le Frontmatter YAML, en créant les liens internes ([[ ]]), en nommant le fichier selon mes conventions et en le plaçant dans wiki/. Il agit comme l'éditeur/archiviste.
Génération : La structure de la note détaillée est construite par l'agent (Claude Code) en mémoire dans la zone de transit temporaire = staging (sur le Volume 3) durant le processus de traitement qui se situe entre le dossier inbox et le dossier wiki dans la mémoire RAM.
Stockage définitif : Une fois finalisée et validée par Claude Code, la note est stockée dans le dossier wiki /volume1/second-brain/wiki/.
Source : Déposée par n8n dans inbox/.
Traitement : Claude Code lit la source, demande à qwen3.6:27b de rédiger le contenu.
Finalisation : Claude Code récupère le texte, l'encadre avec vos métadonnées (YAML), crée le lien vers l'index.md et écrit le fichier final (note de synthèse) .md dans wiki/.
Nettoyage : La source originale est déplacée de inbox/ vers raw/.
Important : On ne travaille jamais directement dans inbox/ pour les notes de connaissance. Le dossier inbox/ est un dossier de passage qui doit toujours être vide après un cycle d'ingestion. Le dossier wiki/ est la bibliothèque vivante, celle qui est indexée dans votre index.md et que l'on consulte au quotidien dans Obsidian.
Voici pourquoi votre raisonnement est parfait :
La zone de transit (Staging) : Vous utilisez le Volume 3 (SSD) comme un "bureau de travail" temporaire. Il est crucial que les fichiers ne soient pas écrits directement dans le Volume 1 (le vault canonique) tant qu'ils ne sont pas finis. Cela évite d'avoir des "brouillons" ou des fichiers corrompus dans votre bibliothèque Obsidian.
L'état de "Construction" : Claude Code travaille en effet en mémoire (RAM) et dans cette zone de staging pour assembler le Markdown final (texte + YAML + liens). C'est là qu'il fusionne le contenu généré par le moteur (Ollama) et les règles structurelles que vous lui avez imposées.
La Validation : C'est seulement une fois que Claude Code a vérifié que le résultat est "propre" (qu'il respecte le CLAUDE.md) qu'il procède à l'écriture finale dans le dossier wiki/ du Volume 1.
En résumé, votre processus suit une logique de pipeline industriel robuste :
Arrivée (Inbox/Vol 1) : Brut / Non trié.
Traitement (Staging/Vol 3) : Transformation / Assemblage / Nettoyage.
Stockage (Wiki/Vol 1) : Produit fini / Canonique.
Cette approche garantit que votre vault reste impeccable, sans jamais être pollué par les fichiers temporaires de calcul ou les étapes intermédiaires de l'IA. Votre architecture est très bien pensée pour un système de production.