Un système de second cerveau peut être construit localement, sans base de données vectorielle, sans Obsidian, sans code, en utilisant un LLM comme libraire actif plutôt que comme assistant ponctuel. L’idée centrale, attribuée à Andrej Karpathy, repose sur un constat simple : un LLM peut maintenir un index et lire sélectivement un corpus de plusieurs centaines de milliers de mots sans infrastructure spécialisée. Ce que les outils de type Obsidian délèguent à l’utilisateur — organiser, relier, baliser — est ici délégué à l’IA. L’utilisateur capture. L’IA structure.
Le système fonctionne dans Claude Cowork, un environnement de bureau qui pointe vers un dossier local. Il est entièrement composé de dossiers et de fichiers Markdown, ne coûte presque rien en stockage, et s’améliore à chaque utilisation.
Ce que le système suppose avant de démarrer
L’architecture repose sur trois dossiers et un fichier de pilotage à la racine.
- Raw est le dossier de capture brute. Articles, transcriptions, notes de réunion, screenshots, PDFs : tout entre ici sans organisation préalable. Le tri n’est pas le rôle de l’utilisateur.
- Wiki est le dossier que l’IA construit et maintient. L’utilisateur ne l’édite jamais manuellement. Claude y crée des fichiers thématiques, un index, des connexions entre concepts.
- Outputs reçoit les réponses aux questions posées au système. Ces réponses, une fois sauvegardées, enrichissent la base et améliorent les réponses futures.
- Le fichier CLAUDE.md à la racine est le schéma de pilotage. Il indique à Claude comment lire la base, quand agir, comment nommer les fichiers, selon quelle logique construire le wiki. C’est le seul fichier que l’utilisateur rédige en collaboration avec l’IA lors de l’initialisation.
Il peut contenir : le périmètre thématique de la base, les règles d’ingestion, le format attendu pour les articles du wiki, les critères du contrôle qualité mensuel, et les instructions de style rédactionnel.
Une base de connaissance peut en contenir d’autres. Un dossier parent peut accueillir plusieurs sous-bases thématiques indépendantes, chacune avec son propre CLAUDE.md, toutes pilotées par un CLAUDE.md de niveau supérieur qui décrit la structure globale.
Pourquoi un fichier CLAUDE.md, pas une instruction dans le chat
La distinction entre une instruction donnée dans le chat et un fichier CLAUDE.md à la racine est fonctionnelle, pas stylistique. Le fichier est chargé automatiquement à chaque session pointant vers ce dossier. Il rend le comportement de Claude reproductible, cohérent entre les sessions, et indépendant de la mémoire conversationnelle.
Ce fichier doit couvrir au minimum : le périmètre thématique, les règles de nommage des fichiers wiki, la logique de l’index, le format du changelog (qui sert aussi de mémoire système), et les instructions pour le contrôle qualité périodique. Il peut aussi intégrer un guide de style anti-IA pour que les articles du wiki ne sonnent pas comme des sorties de modèle.
Un fichier de mémoire séparé, qui enregistre la date du dernier traitement, permet à Claude de distinguer les fichiers déjà ingérés des nouveaux arrivants dans Raw. Sans ce fichier, chaque session repart de zéro et risque de dupliquer le travail.
Construire le wiki : le travail du libraire
Une fois Raw alimenté, une seule instruction déclenche la construction du wiki :
Lis tout ce qui se trouve dans Raw et compile un wiki dans le dossier wiki en suivant les règles de ton CLAUDE.md. Crée d’abord l’index, puis un fichier par grand thème, et relie les sujets connexes.
Claude produit alors un index qui rend la base immédiatement interrogeable, des articles thématiques synthétisant les idées extraites de Raw, et des connexions entre concepts que l’utilisateur n’aurait pas nécessairement établies lui-même.
Ce travail est coûteux en crédits et peut nécessiter d’être découpé en sessions. Sur un plan Max, la construction initiale d’une base de taille modeste consomme environ 40 à 50 % d’une session.
Poser des questions et faire croître la base
Le mécanisme de croissance repose sur une boucle simple : chaque réponse générée par Claude à partir du wiki est sauvegardée dans Outputs, et ces outputs sont ensuite réintégrés dans la base. Une bonne réponse devient une entrée qui enrichit les réponses suivantes.
Pour que cela fonctionne, le CLAUDE.md doit contenir une règle explicite : toute réponse à une question génère automatiquement un fichier dans Outputs. Sans cette règle, les réponses restent dans le chat et disparaissent à la fermeture de la session.
Une question utile à poser après chaque session de consultation :
Quels sont les trois plus grands manques dans ma compréhension de ce sujet d’après ce qui est dans le wiki ?
Cette question ne cherche pas une réponse dans la base — elle audite la base elle-même et révèle ses lacunes.
Le contrôle qualité mensuel
Un LLM peut écrire quelque chose d’inexact, le sauvegarder dans le wiki, et les réponses suivantes construire sur cette erreur sans signal d’alerte. Le contrôle mensuel est le mécanisme de correction.
L’audit couvre sept points :
- contradictions entre articles
- liens brisés et références orphelines
- affirmations non sourcées
- fichiers Raw non encore traités
- articles obsolètes (plus de 90 jours sans mise à jour sur un sujet évolutif)
- lacunes thématiques identifiées par rapport au périmètre déclaré
- et nouveaux articles candidats suggérés par les connexions détectées.
L’audit peut être déclenché manuellement ou automatisé via une tâche planifiée dans Cowork. Il produit un rapport dans Outputs, avec un menu d’actions que l’utilisateur peut valider ou déclencher directement. La phase 1 est un rapport. La phase 2 est une exécution sur validation.
Ce contrôle est intentionnellement mensuel, pas hebdomadaire. La fréquence est calibrée pour équilibrer la qualité de la base avec la consommation de crédits.
Alimenter Raw sans friction
Plusieurs méthodes coexistent selon le contexte :
- Coller directement dans le chat et demander à Claude d’écrire le fichier Markdown correspondant dans Raw. Simple, mais consomme des crédits.
- Créer manuellement des fichiers Markdown via un éditeur léger (Xcode sur Mac, par exemple) : File > New from template > Markdown. Le fichier est nommé, collé, déposé dans Raw. Méthode sans coût en crédits.
L’extension Obsidian Web Clipper convertit n’importe quelle page web en fichier Markdown propre en un clic, gratuitement. Elle ne nécessite pas d’utiliser Obsidian comme système central — elle sert uniquement de convertisseur.
Les PDFs peuvent être déposés dans Raw mais posent des difficultés de lecture plus importantes pour le LLM. Les fichiers texte et Markdown sont préférables.
Les images (JPEG, PNG) peuvent également être ingérées, mais leur traitement dépend des capacités multimodales du modèle utilisé.
Ce que la base devient avec le temps
Jour 1 : la base contient ce qui a été déposé manuellement sur quelques heures. Utile, mais pas distinctif.
Jour 100 : chaque réunion transcrite, chaque article annoté, chaque réponse sauvegardée a été indexé, relié, synthétisé et amélioré par plusieurs cycles d’audit. La base reflète une perspective, des sources et un jugement que personne d’autre ne possède, parce que personne d’autre n’a lu exactement ce que vous avez lu ni posé exactement les mêmes questions.
C’est ce qui distingue ce système d’une bibliothèque passive : il apprend de son utilisation. Chaque question améliore la prochaine réponse. Chaque audit renforce la cohérence. La valeur est cumulative et non transférable.
Erreurs de conception à éviter
Ne pas rédiger de CLAUDE.md précis dès le départ. Un fichier vague produit un wiki inconsistant. Le temps passé à définir le périmètre, les règles de nommage et les instructions de style est récupéré dès la première session de consultation.
Éditer le wiki manuellement. Le wiki est la sortie du libraire. L’éditer manuellement crée des incohérences invisibles que le prochain cycle d’audit devra corriger — ou pire, construire dessus.
Ne pas sauvegarder les réponses dans Outputs. C’est la boucle d’amélioration. Sans elle, le système stagne au niveau de ce qui a été initialement déposé dans Raw.
Déclencher le contrôle qualité trop fréquemment. L’audit complet consomme des ressources significatives. Mensuel est le rythme correct pour une base active. Décaler les audits de bases multiples sur des jours différents évite de saturer les crédits disponibles en une seule journée.
Négliger le fichier de mémoire. Sans trace de ce qui a déjà été traité, chaque session risque de réingérer des fichiers Raw déjà présents dans le wiki, produisant des doublons et des contradictions.
Ce que cela change concrètement
- La rupture avec les systèmes antérieurs (Obsidian, Notion) n’est pas technique — elle est organisationnelle. Ces outils demandent à l’utilisateur d’être le libraire : organiser, taguer, relier, maintenir. La plupart des bases abandonnées l’ont été parce que cette charge de maintenance a fini par dépasser la valeur extraite.
- Ici, la maintenance est délégée. L’utilisateur capture et questionne. Claude organise, relie, audite et améliore. Le résultat, après quelques mois d’utilisation régulière, est un actif cognitif impossible à répliquer : non pas une collection d’articles, mais une base de connaissance qui reflète une perspective singulière, structurée par un outil qui a appris à la servir.