Base de connaissance auto-corrigée et pilotée par LLM (méthode Karpathy « second brain »), implémentée avec Claude Code + un dossier de fichiers .md + un fichier de règles CLAUDE.md. Aucun outil tiers. La lecture/visualisation se fait en markdown brut (éditeur, grep, index.md).
Distinction de fond : « second brain » est une catégorie/finalité ; « llm-wiki » (wiki vivant) est une architecture spécifique. Le second est une implémentation moderne du premier, où un LLM devient le mainteneur actif.
- Le « second brain » désigne une finalité — externaliser et augmenter sa mémoire dans un dépôt de connaissance personnel — popularisée dans les années 2010 par des méthodes comme PARA et des outils comme Obsidian, Notion ou Roam, où c’est l’utilisateur qui capture, trie et relie ses notes à la main.
- Le llm-wiki (ou wiki vivant) est une architecture spécifique qui poursuit cette même finalité, mais en confiant la maintenance à un LLM : le modèle ingère les sources brutes, en extrait des pages markdown interconnectées, détecte les contradictions et fait converger l’ensemble au fil du temps grâce à un contrôle qualité automatique (le lint).
La différence n’est donc pas de nature mais de moteur — un second brain classique est entretenu par toi et se dégrade mécaniquement en quelques mois par accumulation de doublons et d’informations obsolètes, là où le llm-wiki délègue précisément cette maintenance à un agent discipliné par un fichier de règles, ce qui le fait s’améliorer au lieu de pourrir. Autrement dit, tout llm-wiki est un second brain, mais un second brain ne devient un llm-wiki qu’à partir du moment où un LLM ne se contente plus de lire ou de répondre (ce qui relèverait du simple RAG) mais maintient activement la base.
1. Le principe en une phrase
Tu ne stockes pas des notes, tu maintiens un système de connaissance vivant : Claude lit tes sources brutes, les digère en pages markdown interconnectées, détecte les contradictions, et fait converger l’ensemble au fil du temps au lieu de le laisser pourrir.
RAG vs wiki vivant :
| RAG | Wiki vivant | |
|---|---|---|
| Rôle du LLM | répond (Google search sur tes docs) | comprend, structure, améliore |
| Données | statiques dans une base vectorielle | fichiers .md vivants qui évoluent |
| Maintenance | aucune | intégrée (lint) |
| Évolution | accumulation | amélioration continue |
| Mémoire | passive (oubliée après réponse) | persistante (le wiki EST la mémoire) |
| Coût token | recherche à chaque requête | lecture ciblée via l’index |
Le wiki est une code base que Claude maintient comme un développeur : Claude = programmeur, le dossier de .md = code base, CLAUDE.md = spécifications.
2. Architecture 3 couches (immuable)
mon-wiki/
├── raw/ # COUCHE 1 — sources brutes, immuables, source de vérité
│ ├── articles/ # PDF, articles, transcripts, notes brutes (.md/.txt/.pdf)
│ └── assets/ # images
├── wiki/ # COUCHE 2 — domaine du LLM : il écrit, tu lis
│ ├── concepts/
│ ├── entities/ # acteurs, outils, organisations
│ ├── sources/ # une fiche par source ingérée
│ ├── synthesis/ # réponses enrichissantes promues en pages
│ ├── index.md # référence toutes les pages (économie de tokens)
│ └── log.md # journal de tous les traitements
└── CLAUDE.md # COUCHE 3 — le schéma, les règles du LLM
Règles de couche :
- Couche 1 : Claude lit uniquement, ne modifie jamais. C’est ta vérité.
- Couche 2 : Claude écrit, tu lis (tu peux demander des corrections).
- Couche 3 : la config qui transforme Claude en moteur de connaissance discipliné. Initialisée au démarrage, évolutive ensuite.
Une source ne s’ajoute pas, elle recompile le système : un seul PDF peut toucher 10-15 pages (création, mise à jour, maillage, contradictions).
3. Le CLAUDE.md — pièce maîtresse
Copie ce template, remplace le domaine et les tags, place-le à la racine. Claude Code le lit automatiquement à chaque session.
# Wiki vivant — [NOM DU DOMAINE]
Tu es un agent LLM-wiki. Tu maintiens une base de connaissance markdown
auto-corrigée. Ce fichier définit tes règles. Tu les appliques à chaque opération.
## Domaine
[Périmètre en 2-3 lignes. Ex. « IA appliquée à l'éducation : concepts
pédagogiques, outils, acteurs institutionnels, recherche empirique,
cadre réglementaire français. »]
## Langue
- Pages rédigées en français.
- Termes techniques anglais conservés en anglais (ex. fine-tuning, scaling laws).
- Le log peut rester en anglais.
## Structure de répertoires
- raw/ sources brutes (lecture seule, jamais modifiées)
- raw/assets/ images
- wiki/concepts/ notions, idées
- wiki/entities/ acteurs, outils, organisations
- wiki/sources/ une fiche par source ingérée
- wiki/synthesis/ synthèses issues des requêtes
- wiki/index.md index de toutes les pages
- wiki/log.md journal des opérations
## Tags autorisés
concept, entity, tool, actor, practice, research, synthesis, comparison, source
## Nommage des fichiers
- kebab-case, minuscule, sans espace ni accent.
Ex. « L'éthique de l'IA » -> ethique-ia.md
- Indispensable pour un système agentique et pour grep.
## Format de page (front-matter YAML obligatoire)
Chaque page commence par :
```
---
title: Titre lisible de la page
type: concept | entity | synthesis | comparison | source
created: AAAA-MM-JJ
updated: AAAA-MM-JJ
sources: [nom-source-1, nom-source-2]
status: draft | verified
---
```
(Le YAML est grep-able et parsable : il sert au filtrage même sans interface.)
## Cross-références (maillage)
- Relier les concepts avec des liens markdown relatifs :
[ethique-ia](../concepts/ethique-ia.md)
-> cliquables dans VS Code, GitHub, tout éditeur markdown.
- Un concept mentionné doit avoir sa page ou un lien.
- Le maillage se fait une fois puis se réutilise : ne pas le refaire à chaque requête.
## Contradictions
- Si une source contredit une page, ne pas écraser.
- Signaler avec le marqueur ⚠️ dans la page, en citant les deux sources.
## OPÉRATIONS
### INGEST (ajouter une source)
1. Lire la source dans raw/.
2. Extraire les idées clés (les présenter AVANT d'écrire, demander confirmation).
3. Mettre à jour les pages existantes concernées.
4. Créer les nouvelles pages nécessaires.
5. Tisser le maillage (liens vers concepts liés).
6. Signaler les contradictions (⚠️).
7. Mettre à jour index.md et log.md.
Rappel : une source peut toucher 10-15 pages.
### QUERY (interroger le wiki)
1. Lire wiki/index.md (PAS tout le dossier — économie de tokens).
2. Retrouver les pages pertinentes.
3. Synthétiser avec citations (chemins des pages).
4. Proposer de promouvoir la synthèse en page wiki/synthesis/ si elle enrichit.
### LINT (contrôle qualité)
1. Détecter les contradictions entre pages.
2. Détecter les infos obsolètes vs sources récentes.
3. Détecter les pages orphelines (sans lien entrant/sortant).
4. Détecter les concepts mentionnés sans page dédiée.
5. Proposer les corrections (ne pas appliquer sans validation).
Recommandé tous les ~10 documents. Fait converger le wiki au lieu de dériver.
## Index (wiki/index.md)
Format : | page (chemin) | summary | date | tags |
Section LOG en bas listant les derniers traitements.
## Démarrage de session
À chaque ouverture : lire ce fichier, lire index.md, lire les dernières entrées
de log.md, puis demander : ingestion, requête, ou consolidation (lint) ?
Le schéma n’est pas gravé : demande à Claude de faire évoluer CLAUDE.md quand tu veux.
4. Mise en place — étape par étape
Étape 1 — créer le dossier et lancer Claude Code
mkdir mon-wiki && cd mon-wiki
claude
Étape 2 — initialiser
Tu es un agent LLM-wiki. Domaine : [ton domaine].
Crée l'architecture 3 couches (raw/, wiki/, CLAUDE.md), initialise CLAUDE.md
avec le schéma adapté au domaine, crée wiki/index.md et wiki/log.md vides.
Structure les sous-dossiers du wiki selon le domaine.
Règles : pages en français, termes techniques en anglais, nommage kebab-case,
liens markdown relatifs pour le maillage.
Claude adapte l’arborescence : vault « recherche LLM » -> papers/, datasets/, benchmarks/ ; vault « développement » -> architecture/, runbooks/, decisions/. Il pose 1-2 questions puis génère tout.
Étape 3 — alimenter raw/ (les 3 voies, sans Web Clipper)
a) Fichier local (PDF, article, doc). Copie-le dans raw/articles/. Claude Code lit les PDF nativement.
cp ~/Downloads/rapport.pdf raw/articles/
b) Page web / URL. Claude Code récupère et nettoie le contenu lui-même :
Récupère le contenu de [URL], nettoie-le (retire pub/menus/navigation),
et enregistre-le en markdown dans raw/articles/titre-source.md
(Skill defuddle du repo Kepano si installée — équivalent exact du Web Clipper, en ligne de commande.)
c) Transcript YouTube. Récupère le transcript hors Claude puis dépose-le :
pip install yt-dlp
yt-dlp --write-auto-sub --skip-download --sub-format vtt --sub-lang fr "URL"
# convertis le .vtt en texte propre, place-le dans raw/articles/
Ou colle directement le transcript dans le prompt d’ingestion.
d) Note brute. Pas besoin de fichier — colle dans le prompt :
Structure cette note en markdown propre et intègre-la au wiki : [texte brut]
Étape 4 — ingérer
J'ai déposé [titre-source] dans raw/. Ingère-la selon CLAUDE.md.
Claude présente les points clés, demande confirmation sur les pages à créer/fusionner, écrit en parallèle (sous-agents), tisse le maillage, met à jour index et log.
Étape 5 — interroger
Synthétise ce que le wiki dit sur [sujet]. Lis index.md et cite les pages.
Réponse substantielle -> Claude propose de la promouvoir en wiki/synthesis/. « oui » -> ta question enrichit la base. Boucle cumulative.
Étape 6 — lint (tous les ~10 documents)
Lint le wiki : contradictions, pages obsolètes, orphelines, concepts sans page.
Liste les corrections, ne les applique pas encore.
5. Le pipeline en 6 étapes (boucle continue)
1. INGESTION -> tu déposes la source dans raw/
2. STRUCTURATION -> Claude extrait, crée/met à jour, maille
3. LINT -> nettoie doublons / obsolètes (périodique)
4. STOCKAGE -> fichiers .md dans le dossier
5. INTERROGATION -> requête sur l'index
6. ENRICHISSEMENT -> la réponse devient une page -> retour en 1
Chaque cycle améliore la connaissance. Une base qui ne s’améliore pas meurt.
6. Lire / naviguer le wiki (sans interface)
- Point d’entrée :
wiki/index.md(tableau de toutes les pages). C’est aussi ce qui économise les tokens en requête. - Recherche plein texte :
ripgrep.rg "scaling laws" wiki/ # occurrencesrg -l "type: concept" wiki/ # toutes les pages d'un typerg "⚠️" wiki/ # toutes les contradictions - Arborescence :
tree wiki/oufind wiki -name '*.md'. - Rendu : n’importe quel lecteur markdown (aperçu VS Code, rendu GitHub si tu versionnes le dossier). Les liens relatifs y sont cliquables.
- Versionnement (recommandé) :
git initdans le dossier. Chaque ingestion/lint = un commit -> historique complet, diff, rollback. Remplace avantageusement tout « graphe » :git logte donne l’évolution réelle.
7. Adaptations spécifiques à Claude
Sous-agents. Un orchestrateur délègue : agent writer (écriture, raisonnement soutenu), agent auditor rapide (audit du système de fichiers, health check), agent researcher (recherche web + synthèse pour compléter une source). Claude écrit aussi plusieurs pages en parallèle lors d’une ingestion.
Skills (accélérateurs, installés une fois, invoqués par /) : defuddle (nettoyage d’URL = Web Clipper en CLI), second-brain-ingest/query/lint (opérations packagées). Le template manuel ci-dessus reste plus transparent et sans dépendance.
Multi-LLM / portabilité. Le dossier est un simple ensemble de .md : enrichi par Claude, rouvrable par tout autre client (qui lit CLAUDE.md ou son équivalent). Aucun verrou.
Livrables produits depuis le wiki (markdown pur, donc générables directement par Claude sans outil) : deck Marp (.md -> PPT/PDF via marp-cli), diagrammes Mermaid (bloc mermaid rendu par GitHub/VS Code). Exemple :
Lis wiki/index.md et génère un deck Marp sur les scaling laws dans
wiki/synthesis/scaling-laws-slides.md
Local vs cloud. Ingestion/lint = gourmands en raisonnement : garde-les sur un modèle cloud performant. Un modèle local (Ollama + Qwen3) sur MacBook M4 24 Go devient laborieux en ingestion (ventilateur, lenteur) ; il reste viable pour l’interrogation. Contexte minimum recommandé : 64 K tokens pour la gestion des sources.
8. Pièges et maintenance
- Ne saute pas le lint. Sans lui, la base dérive en ~6 mois (doublons, contradictions, fragments sans maillage). C’est ce qui distingue un wiki vivant d’un tas de notes mortes.
- Hallucination circonscrite par : (1) tes propres données en entrée, (2) le lint, (3) les contraintes du
CLAUDE.md. Surveillestatus: draftvsverified. - Protège
raw/. Couche 1 immuable ; toute modification va danswiki/. - Valide avant d’appliquer corrections de lint et fusions de pages : Claude propose, tu décides.
- Deux niveaux si le dossier sert aussi à l’opérationnel : niveau connaissance (wiki) + niveau opérations (décisions, incidents, runbooks). Sépare dès la structure.
9. Quickstart — copier-coller
mkdir mon-wiki && cd mon-wiki
git init
claude
Init (dans Claude Code) :
Initialise un wiki vivant. Domaine : [X]. Crée raw/ (articles, assets) et
wiki/ (concepts, entities, sources, synthesis, index.md, log.md), plus un
CLAUDE.md complet : tags autorisés, front-matter YAML (title/type/created/
updated/sources/status), nommage kebab-case, liens markdown relatifs pour le
maillage, marqueur contradiction ⚠️, opérations INGEST/QUERY/LINT, lecture de
index.md pour les requêtes, langue française + termes techniques en anglais.
Ingestion :
J'ai déposé [source] dans raw/. Ingère-la selon CLAUDE.md.
Requête :
Synthétise ce que le wiki dit sur [sujet], cite les pages.
Lint :
Lint le wiki : contradictions, obsolètes, orphelines, concepts sans page.
Après chaque opération : git add -A && git commit -m "ingest: [source]".