Construire un LLM Wiki
Un dossier de fichiers Markdown qui devient ton second cerveau, maintenu et enrichi automatiquement par Claude Code. Pas de RAG, pas de base vectorielle, pas d'embeddings. Juste des fichiers et un agent.
L'idée en deux phrases
La plupart des systèmes (NotebookLM, ChatGPT file uploads, RAG classique) re-cherchent dans tes sources brutes à chaque question. Rien ne s'accumule. Ici c'est l'inverse : entre toi et tes sources, il y a un wiki Markdown que l'agent maintient au fil de l'eau — il intègre chaque nouvelle source, met à jour les pages existantes, signale les contradictions, tisse les liens.
Le wiki est persistant et compose. Les références croisées sont déjà là. Les contradictions sont déjà notées. La synthèse reflète déjà tout ce que tu as lu. Toi tu cures les sources et tu poses les bonnes questions, l'agent fait tout le boulot d'écriture, classement et bookkeeping.
L'architecture en trois couches
mon-wiki/ ├── CLAUDE.md # schéma : conventions, workflows, règles ├── raw/ # sources immuables (articles, PDF, transcripts) │ └── article-001.md └── wiki/ # couche écrite/maintenue par l'agent ├── index.md # catalogue de toutes les pages ├── log.md # journal append-only des opérations ├── entities/ # personnes, entreprises, outils ├── concepts/ # sujets, idées, théories ├── sources/ # pages-résumés des sources ingérées └── analysis/ # synthèses transverses, comparaisons
- Raw — tu poses, tu ne touches plus. L'agent lit mais ne modifie jamais.
- Wiki — l'agent en est seul propriétaire. Tu lis, l'agent écrit.
- Schéma (CLAUDE.md) — la config qui transforme l'agent en mainteneur de wiki discipliné plutôt qu'en chatbot générique. Tu le fais évoluer avec lui au fil du temps.
Le tuto en 6 étapes
Installer Obsidian
Obsidian est un éditeur de Markdown gratuit qui affiche ton vault sous forme de graphe interactif. Optionnel techniquement (Claude Code marche sans), mais c'est ce qui rend le wiki visuel.
- Va sur obsidian.md
- Télécharge la version pour ton OS, installe, lance
Créer un nouveau vault
Au premier lancement : "Create new vault" → nom (ex. mon-wiki)
→ choisis un emplacement (Bureau, Documents, ou un repo Git pour avoir l'historique gratis).
À ce stade, dossier vide. Tout le reste est créé par Claude Code.
Lancer Claude Code dans le dossier
Ouvre un terminal, navigue dans le dossier du vault, lance Claude Code :
cd ~/Desktop/mon-wiki
claude
Sur Windows : PowerShell ou Terminal Windows. Sur Mac/Linux : iTerm/Terminal classique. Si tu utilises VS Code/Cursor/Antigravity, tu peux aussi ouvrir le dossier dans l'éditeur et lancer Claude Code depuis le terminal intégré.
Coller le prompt dans Claude Code
C'est l'étape clé. Le bloc ci-dessous contient l'instruction d'implémentation en français, suivie du texte intégral du pattern original (en anglais, pour ne rien perdre des nuances). Clique sur "Copier", colle dans Claude Code, envoie.
Tu es maintenant mon agent LLM Wiki. Implémente le pattern décrit ci-dessous comme mon second cerveau complet, dans le dossier courant.
Ce que je veux que tu fasses, dans l'ordre :
1. Crée la structure de base : CLAUDE.md à la racine, dossiers raw/ et wiki/, fichiers wiki/index.md et wiki/log.md, plus les sous-dossiers logiques (entities/, concepts/, sources/, analysis/) à l'intérieur de wiki/.
2. Rédige un CLAUDE.md complet qui spécifie : la structure du vault, les conventions de nommage, le format des pages wiki (frontmatter YAML avec tags/dates/source-count), les règles de cross-référencement (liens [[…]] internes), et les workflows pour les trois opérations principales : Ingest, Query, Lint.
3. Pose-moi quelques questions de calibrage : à quoi sert ce wiki (recherche, veille, second cerveau perso, business…), niveau de granularité souhaité, langues des sources, ce que je veux que tu mettes en avant.
4. Une fois la structure créée, dis-moi clairement quoi faire ensuite : où déposer ma première source, quelle commande te donner pour l'ingérer.
Important :
- Tu écris dans wiki/, jamais dans raw/.
- Une ingestion typique touche 10 à 15 pages : tu crées les pages neuves ET tu mets à jour les pages existantes pertinentes.
- Tu mets à jour index.md à chaque ingest.
- Tu ajoutes une entrée dans log.md avec le format ## [YYYY-MM-DD] {operation} | {titre} pour qu'on puisse parser avec grep plus tard.
- Quand je te pose une question, lis index.md d'abord, puis drill dans les pages pertinentes, puis synthétise une réponse avec citations vers les pages du wiki.
- Les bonnes réponses peuvent elles-mêmes être filed back dans wiki/analysis/ pour ne pas se perdre.
================================================================
PATTERN ORIGINAL (à respecter dans son esprit)
================================================================
# LLM Wiki
A pattern for building personal knowledge bases using LLMs.
## The core idea
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up.
The idea here is different. Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources. When you add a new source, the LLM doesn't just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing wiki — updating entity pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis. The knowledge is compiled once and then kept current, not re-derived on every query.
This is the key difference: the wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read.
You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work — summarizing, cross-referencing, filing, bookkeeping. In practice: LLM agent on one side, Obsidian on the other. The LLM makes edits, you browse the results in real time. Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.
## Architecture (three layers)
1. Raw sources — your curated collection of source documents. Articles, papers, images, data files. Immutable. The LLM reads from them but never modifies them.
2. The wiki — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely.
3. The schema — CLAUDE.md (or AGENTS.md). Tells the LLM how the wiki is structured, what conventions to follow, what workflows to use when ingesting / answering / maintaining. Co-evolves with you over time.
## Operations
Ingest. Drop a new source into raw/, tell the LLM to process it. Typical flow: LLM reads the source, discusses key takeaways, writes a summary page in wiki/, updates index, updates relevant entity and concept pages, appends an entry to the log. A single source might touch 10-15 wiki pages.
Query. Ask questions against the wiki. The LLM searches relevant pages, reads them, synthesizes an answer with citations. Answers can take different forms (markdown page, comparison table, Marp slide deck, chart). Good answers should be filed back into the wiki as new analysis pages so explorations compound.
Lint. Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search.
## Indexing and logging
index.md is content-oriented. A catalog of everything in the wiki — each page listed with a link, a one-line summary, optionally metadata (date, source count). Organized by category. Updated on every ingest. The LLM reads the index first when answering a query, then drills into the pages.
log.md is chronological. Append-only. Format: ## [2026-04-02] ingest | Article Title — parseable with grep "^## \[" log.md | tail -5.
## Why this works
The tedious part of maintaining a knowledge base is not the reading or thinking — it's the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The wiki stays maintained because the cost of maintenance is near zero.
The human's job: curate sources, direct the analysis, ask good questions, think about what it all means. The LLM's job: everything else.
================================================================
Maintenant, vas-y. Crée la structure, rédige le CLAUDE.md, pose-moi tes questions de calibrage.
Une fois envoyé, Claude crée la structure complète : CLAUDE.md, dossiers
raw/ et wiki/, fichiers index.md et
log.md, sous-dossiers thématiques. Il enchaîne ensuite avec 2 à 4 questions de
calibrage (à quoi sert le wiki, granularité, langues, axes prioritaires). Réponds
franchement — c'est ce qui détermine la qualité du wiki.
Installer Obsidian Web Clipper (optionnel)
Pour ingérer un article web sans copier-coller à la main, l'extension Chrome Obsidian Web Clipper aspire la page en Markdown propre directement dans le vault.
- Installe l'extension depuis le Chrome Web Store
- Options de l'extension →
Location→ changeclippings/enraw/ - Sur n'importe quelle page : icône extension → "Add to Obsidian" → l'article atterrit en
MD dans
raw/
Bonus si tu veux que les images soient stockées en local : Settings → Files and links →
Attachment folder path = raw/assets/. Puis Settings → Hotkeys →
cherche "Download attachments for current file" → bind à Ctrl+Shift+D. Tu
cliperas, puis hotkey, et toutes les images seront sur ton disque.
Ingérer ta première source
Une fois un fichier dans raw/, tu retournes dans Claude Code :
Je viens d'ajouter "[nom-du-fichier].md" dans raw/.
Ingère-le dans le wiki.
Claude lit la source, identifie concepts/entités/idées, crée les pages neuves, met à jour les
pages existantes pertinentes, tisse les liens, met à jour index.md et ajoute
une entrée dans log.md. Une ingestion peut toucher 10 à 15
pages et prendre 5 à 15 minutes selon la taille du document.
C'est lent mais c'est le boulot de bookkeeping qui aurait pris des heures à la main.
Côté Obsidian, ouvre la Graph view (Ctrl/Cmd + G) : tu vois les
nœuds apparaître et se connecter en temps réel. Plus tu ingères, plus les hubs émergent.
Les trois opérations à connaître
Ingest — ajouter une source
J'ai ajouté X dans raw/. Ingère-le.
Tu peux ingérer une source à la fois (recommandé pour rester impliqué et corriger au passage) ou batch-ingérer (plus rapide, moins contrôlé).
Query — interroger le wiki
D'après mon wiki, quelles sont les techniques d'agents
qui reviennent le plus souvent ? Compare-les en tableau,
avec citations vers les pages sources.
L'agent lit index.md, drill dans les pages pertinentes, synthétise. Et le truc important
: file la réponse dans wiki/analysis/ pour qu'elle ne disparaisse pas
dans l'historique de chat.
Lint — audit régulier
Lance un audit santé du wiki. Identifie : contradictions
entre pages, claims devenus obsolètes, pages orphelines
sans backlinks, concepts mentionnés sans page dédiée,
liens manquants, trous à combler par recherche web.
À faire toutes les semaines ou tous les 10-15 ingests. C'est ce qui empêche le wiki de partir en cacahuète quand il grossit.
LLM Wiki vs RAG classique
La question légitime : "ça remplace pas un RAG sérieux, si ?". Réponse honnête : non, pas dans tous les cas.
| Critère | LLM Wiki | RAG classique |
|---|---|---|
| Recherche | Lecture d'index + suivi de liens | Similarité vectorielle |
| Infrastructure | Juste des fichiers Markdown | Embedding model + vector DB + chunking |
| Coût | ~Gratuit (juste les tokens) | Compute + stockage en continu |
| Maintenance | Lint périodique | Re-embedding à chaque changement |
| Capture des relations | Liens explicites, sémantiques | Similarité de surface |
| Lisibilité humaine | 100 % lisible et éditable | Opaque (vecteurs) |
| Versioning | Git natif (c'est juste des .md) | Snapshots de DB |
| Scalabilité | ~Quelques centaines de docs max | Millions de documents |
TL;DR
Récap exécutif
- Un dossier Markdown maintenu par un agent. C'est tout.
- Setup en 6 étapes : Obsidian → vault → terminal → prompt → Web Clipper → ingestion.
- Trois opérations : Ingest (ajouter), Query (interroger), Lint (auditer).
- Tu cures les sources, l'agent fait le bookkeeping. Division du travail honnête.
- Limite réelle : ne scale pas à des millions de docs. Pour ta veille perso, largement suffisant.
- Avantage rare : tout est en clair, versionnable Git, exportable, branchable à n'importe quel autre agent.