The LLM Wiki : Comment construire une base de connaissances IA qui n'oublie jamais

📋 Vue d'ensemble

• Type : Conférence / Tutoriel (avec une démo de création en direct)
• Sujet principal : Comment construire un "LLM Wiki" persistant et auto-organisé — un concept proposé par Andrej Karpathy — en utilisant Obsidian et un agent de codage IA, pour pallier les limites du classique Q&A sur documents (RAG).
• Intervenants : Jamie (hôte de la chaîne YouTube "Teachers Tech").

🎯 Objectif principal & Contexte

• La vidéo aborde une frustration spécifique et très répandue : les outils d'IA comme ChatGPT et NotebookLM traitent chaque question comme un nouveau départ, sans jamais accumuler ni capitaliser sur le travail précédent.
• L'objectif est à la fois éducatif et pratique : expliquer pourquoi l'approche standard est défaillante, introduire le concept alternatif de Karpathy, puis guider les spectateurs étape par étape dans la construction de leur propre LLM Wiki fonctionnel (démontré via l'exemple de la planification d'un voyage au Japon).
• Public cible : utilisateurs non techniques. Jamie le dit explicitement : "Si vous savez créer un dossier sur votre ordinateur, vous pouvez le faire."

---

🧠 Concepts clés & Étapes

Concepts fondamentaux

Figure 1 — Le RAG se réinitialise à chaque requête ; le LLM Wiki accumule et consolide les connaissances avec l'ajout de chaque nouvelle source.

1. Le problème du RAG (Retrieval Augmented Generation)

• RAG = vous téléversez des fichiers, posez une question, l'IA cherche, extrait les fragments pertinents et génère une réponse.
• La faille : "Posez une question similaire le lendemain et l'IA refait tout ce travail à partir de zéro. Rien n'a été sauvegardé, rien ne s'est accumulé. Chaque nouvelle question repart de zéro."
• Analogie proposée : un chercheur qui lirait des articles pendant des semaines — mais avec le RAG, "à chaque fois que vous posez une question à l'IA, c'est comme si elle n'avait jamais lu aucun de ces articles."
• Le goulot d'étranglement : aucune mémoire, aucune accumulation, aucun effet cumulatif.

2. Le LLM Wiki (La solution de Karpathy)

• Au lieu de fouiller les documents bruts à chaque fois, l'IA lit vos documents une seule fois et construit un Wiki structuré et persistant composé de fichiers markdown interconnectés.
• Quand vous ajoutez une nouvelle source, l'IA : la lit, extrait les idées clés, les intègre, met à jour les pages existantes, crée de nouvelles pages, fait le lien entre les idées connexes et signale les contradictions.
• Au fil du temps, le Wiki "ne cesse de croître et de s'enrichir" — la synthèse et les connexions sont pré-établies avant même que vous ne posiez la question.
• L'approche de Karpathy : "Voyez Obsidian comme l'IDE, le LLM comme le programmeur, et le Wiki comme la base de code (code base)." Vous rédigez rarement le Wiki vous-même — vous vous concentrez sur ce qui y entre et sur les questions à poser.

3. Le système à trois couches

• Couche 1 — Sources brutes (Raw Sources) : Documents originaux (PDF, articles, notes). En lecture seule — l'IA les lit mais ne les modifie jamais. C'est votre "source de vérité".
• Couche 2 — Le Wiki : Un dossier de fichiers markdown créés/maintenus par l'IA (page d'index, pages de concepts, pages d'entités, résumés, comparaisons — le tout interconnecté).
• Couche 3 — Le Schéma : Un document de règles indiquant à l'IA comment structurer le Wiki, traiter les nouvelles sources et tout formater. Dans Claude Code, il s'agit du fichier claude.md.

Distinctions importantes

• RAG vs. LLM Wiki : Le RAG refouille les fichiers bruts à chaque fois (éphémère) ; le Wiki construit une base de connaissances persistante à effet cumulatif (permanente, cumulative).
• Obsidian vs. n'importe quel éditeur de texte : Obsidian est choisi pour sa vue graphique (connexions visuelles), mais le système est fondamentalement un simple dossier de fichiers markdown — VS Code ou tout autre éditeur fait parfaitement l'affaire.
• L'IA est le moteur, pas Obsidian : Obsidian seul ne fait rien ; il vous faut un agent de codage (Claude Code, Codex, Cursor) pour lire/écrire les fichiers.

Figure 2 — L'architecture à trois couches : les sources brutes restent intactes, le Wiki se développe automatiquement, et le schéma remonte toutes les règles que l'IA doit suivre.

---

🛠️ Guide de construction étape par étape

Prérequis

1. Obsidian — application gratuite de prise de notes en markdown (sur obsidian.md), utilisée comme interface de visualisation.
2. Un agent de codage IA — Jamie utilise Claude Code ; alternatives : OpenAI Codex, Cursor, ou d'autres outils similaires capables de lire/écrire des fichiers locaux.

Le processus de création

1. [00:04:40] Ouvrir Obsidian → créer un nouveau Vault / Coffre (un "mot chic pour dire dossier") → nommé LLM Wiki, sauvegardé dans Documents.
2. [00:05:10] Créer trois dossiers à l'intérieur :
   • raw — l'IA lit à partir d'ici, sans jamais éditer.
   • wiki — là où l'IA construit et maintient les pages.
   • templates — optionnel (nécessaire uniquement pour le formatage manuel des notes ; non utilisé ici puisque Claude génère tout).
3. [00:06:10] Créer le fichier de schéma claude.md à la racine (root) du vault. Claude Code le lit automatiquement à l'ouverture du projet. (Jamie fournit un template de base dans la description).
4. [00:06:40] Personnaliser le claude.md. Les cinq composants :
   • Purpose (Objectif) : La seule ligne que vous DEVEZ personnaliser (démo = "planifier un voyage au Japon").
   • Folder structure (Structure des dossiers) : Où se trouvent les sources brutes et la sortie du Wiki.
   • Ingest workflow (Workflow d'ingestion) : lire le document → extraire les concepts → créer/mettre à jour les pages du Wiki → mettre à jour l'index → loguer les modifications.
   • Page formatting rules (Règles de formatage des pages) : un résumé en haut de chaque page, chaque affirmation cite sa source, les pages pointent vers des concepts connexes.
   • Question-answering behavior (Comportement pour les sessions Q&A) : consulter le Wiki en premier, citer les sources, signaler les incertitudes.
5. [00:08:10] Installer l'extension Chrome gratuite Obsidian Web Clipper — elle convertit les articles web en fichiers markdown.
6. [00:08:40] Ajouter la première source : un article de blog de voyage sur Tokyo → enregistré en markdown → glissé-déposé dans le dossier raw. (Note : Les PDF et fichiers texte peuvent être déposés directement — Claude lit les PDF nativement).
7. [00:09:40] Pointer Claude Code vers le bon répertoire (l'emplacement du vault), puis ouvrir Claude.
8. [00:10:20] Commande : "Je viens d'ajouter une nouvelle source au dossier raw. Merci de la lire et de mettre à jour le wiki." → Claude lit, résume, et propose la création de pages Wiki (ex : pages sur les quartiers). Vous pouvez revoir le périmètre avant d'approuver. L'opération a pris ~3 minutes.
9. [00:10:39] Vérifier dans Obsidian : des pages structurées et interconnectées apparaissent. La vue graphique (graph view) montre visuellement les connexions qui se forment à partir d'un seul document.
10. [00:11:21] Ajouter une deuxième source (un guide gastronomique sur le Japon) → même commande d'ingestion → Claude met à jour les pages de quartiers existantes ET en crée de nouvelles. La vue graphique s'enrichit de nœuds et de connexions.
11. [00:12:18] Poser une question croisée entre plusieurs sources : "Dans quel quartier devrais-je loger si je veux être proche de la meilleure nourriture tout en restant à proximité des grands temples ?" → Claude répond en puisant dans les pages du Wiki (quartiers, nourriture, temples) et cite des pages spécifiques du Wiki, pas les articles bruts.
12. [00:13:19] Linter le Wiki : Commande "Merci de linter le wiki." → Claude vérifie la présence de contradictions, d'affirmations obsolètes, de pages orphelines (aucun lien entrant) et de concepts mentionnés mais manquants, puis renvoie un bilan de santé.

Figure 3 — L'avantage de l'effet cumulatif : chaque source ingérée enrichit l'ensemble du Wiki, alors que l'utilisation traditionnelle de l'IA sous forme de chat ne produit aucun capital intellectuel durable.

---

🧭 Analyse stratégique & Changements de paradigme

• Connexions invisibles : La vidéo requalifie discrètement l'IA, transformant un "outil de recherche" en un "travailleur du savoir / documentaliste". Ce changement de perception — traiter l'IA comme un programmeur qui maintient une base de code — implique que votre production intellectuelle devient un actif versionné et auditable plutôt qu'un historique de chat éphémère. C'est une relation fondamentalement différente avec l'IA.

• L'enjeu principal : L'effet cumulatif est la véritable valeur ici. L'utilisation classique de l'IA s'apparente à un tapis de course — l'effort ne capitalise pas. Le LLM Wiki transforme chaque heure de lecture/ingestion en un actif permanent qui s'auto-améliore et gagne de la valeur avec le temps. Pour les travailleurs de la connaissance, les étudiants et les chercheurs, cela convertit un effort dispersé en un véritable capital durable.

Figure 4 — Connaître les limites : le LLM Wiki excelle en tant qu'outil de gestion des connaissances personnelles mais nécessite une sélection rigoureuse, un agent IA et un linting périodique pour rester fonctionnel.

• Changement de donne (Game Changer) : Le modèle persistance + synthèse au point d'ingestion. En effectuant le "vrai travail" de connexion des idées au moment où une source est ajoutée (plutôt qu'au moment de la requête), le système anticipe l'effort de synthèse. La transition la plus précieuse est la suivante : arrêtez de demander à l'IA de réfléchir à partir de zéro, et chargez-la plutôt de maintenir une structure vivante qui matérialise déjà cette réflexion. La fonctionnalité bonus la plus sous-estimée : le signalement des contradictions — le Wiki ne se contente pas de stocker, il réconcilie activement les informations contradictoires entre les différentes sources, ce qu'un système RAG ne peut pas faire.

• Confidentialité et propriété des données : Tout reste localisé dans des fichiers texte markdown simples (plain-text) qui vous appartiennent — un avantage stratégique en termes de respect de la vie privée et de portabilité, que Jamie met explicitement en avant comme argument face aux solutions cloud.

---

⚖️ Limites et mises en garde honnêtes (à partir de [00:15:14])

Limite	Détail
L'échelle (Scale)	Fonctionne mieux à l'échelle personnelle (~100 articles selon Karpathy). Des dizaines de milliers de pages nécessiteraient une infrastructure plus lourde que de simples fichiers markdown.
Garbage in, garbage out	La qualité du Wiki dépend entièrement de la fiabilité des sources ; vous devez filtrer rigoureusement ce qui y entre.
Agent de codage indispensable	Obsidian seul ne fait rien — il vous faut impérativement Claude Code, Codex, ou un équivalent.
L'IA peut faire des erreurs	Elle peut mal catégoriser ou rater des connexions ; d'où la fonctionnalité de linter et l'importance d'une relecture humaine (surtout au début).

📊 Décomposition détaillée

• [00:00:00] Accroche : le problème "invisible" sur la façon dont la plupart des gens utilisent l'IA — chaque question repart de zéro.
• [00:00:30] Introduction d'Andrej Karpathy (co-fondateur d'OpenAI, ancien directeur IA de Tesla) et de son concept concept de "LLM Wiki".
• [00:01:10] Jamie se présente, parle de Teachers Tech ; plongée dans le fonctionnement du RAG et de son absence de mémoire.
• [00:02:10] Explication de la solution Wiki — lire les documents une fois, construire une base de connaissances persistante et interconnectée.
• [00:02:40] Analogie de Karpathy : IDE / programmeur / base de code (code base).
• [00:03:10] Présentation de l'architecture à trois couches (Brut / Wiki / Schéma).
• [00:04:10] Les prérequis globaux — Obsidian + un agent de codage IA (Claude Code recommandé).
• [00:04:40]–[00:05:40] Création du vault et des trois dossiers fondamentaux.
• [00:06:10]–[00:07:40] Explication du fichier de schéma claude.md et de ses cinq composantes ; la ligne "Purpose" (objectif) est la seule ayant besoin d'être personnalisée.
• [00:08:10] Installation du Web Clipper d'Obsidian.
• [00:08:40]–[00:09:10] Ingestion de la première source (blog de voyage couvrant Tokyo).
• [00:09:40]–[00:10:39] Lancement de la première commande d'ingestion ; vérification des pages générées et de la vue graphique.
• [00:11:21]–[00:11:54] Ingestion d'une deuxième source (guide gastronomique) ; Claude met à jour les pages existantes + l'arborescence (graph) s'élargit.
• [00:12:18]–[00:12:43] Question croisée (plusieurs sources concernées) suivie d'une réponse sourcée depuis le Wiki.
• [00:13:19]–[00:14:02] Le concept de "linter le wiki" et démonstration du rapport (pages orphelines, liens brisés, trous dans l'ingestion de données).
• [00:14:02]–[00:15:14] Cas d'usage pratiques : étudiants/chercheurs, enseignants, entreprises, passionnés de lecture.
• [00:15:14]–[00:16:21] Limites du système exposées en toute transparence, adossées à un fort soutien pour la méthode.
• [00:16:21] Conclusion : les liens pour les schémas/templates se trouvent dans la description ; mention de son guide pour débutants sur Claude Code.

🔑 Points à retenir

1. Les systèmes Q&A par IA traditionnels (RAG) n'ont aucune mémoire — l'effort n'a jamais d'effet cumulatif ; chaque requête redémarre à zéro.
2. Le LLM Wiki renverse cette logique : l'IA lit les sources une seule fois et maintient une base de connaissances en markdown, persistante et interconnectée, qui s'étoffe avec chaque ajout.
3. Trois couches d'organisation simples — les sources brutes (Raw) en lecture seule, le Wiki que l'IA prend en charge, et un Schéma (claude.md) définissant les règles comportementales.
4. La fonction "lint" garantit la santé du Wiki en détectant les contradictions, les pages orphelines, les liens brisés et les concepts manquants.
5. C'est gratuit, configuré en local, et ne demande pas de compétences techniques — vous êtes propriétaire de vos données sous la forme de fichiers texte (plain-text), et ce workflow est pertinent dans tous les domaines où s'accumule du savoir.

❓ Questions en suspens / Suivi

• Comment le système passe-t-il à l'échelle au-delà de ~100 articles ? Jamie indique que le modèle a ses limites mais ne précise pas l'infrastructure requise pour l'améliorer.
• À quelle fréquence devrait-on effectuer le linting ? Le terme "Périodiquement" utilisé est assez vague — aucune cadence concrète n'est identifiée.
• Comment gérer les conflits de version ou faire un roll back suite à une mauvaise ingestion ? Le fait de laisser une IA apporter des modifications de masse aux pages (durant les lints) s'accompagne d'un risque qui n'est pas adressé ici.
• Quel est exactement le contenu interne du template claude.md ? Résumé à voix haute uniquement — les détails complets se trouvent sur un lien externe (dans la description de la vidéo).
• Le coût / l'utilisation des tokens (token) concernant la lecture intégrale et réécriture du Wiki lors des digestions d'informations et des processus de linting n'a pas été abordé.
• Multi-utilisateur / Mode collaboratif : Le cas d'usage en entreprise a été évoqué, mais le moyen de synchroniser un tel système collaboratif en équipe n'est pas expliqué.