Wiki LLM : comment en construire un et le garder exact

Un wiki LLM est une base de connaissances personnelle qu’un agent IA écrit pour vous. Vous rassemblez des sources brutes (articles, publications, transcriptions, notes) dans un dossier. L’agent les lit et entretient par-dessus un ensemble de pages markdown reliées entre elles : une page par concept, personne ou source, plus un index. Quand vous ajoutez une source, l’agent met à jour chaque page concernée. Quand vous posez une question, il répond à partir du wiki et peut ranger la réponse comme nouvelle page.

L’idée vient d’Andrej Karpathy. Le 2 avril 2026, il a publié sur X un message sur les « LLM Knowledge Bases », et deux jours plus tard une version plus longue sous forme de « fichier d’idée » sur GitHub, écrite pour être collée telle quelle dans un agent comme Claude Code ou Codex. Il l’oppose au RAG, où un modèle récupère des morceaux de vos fichiers à chaque question sans que rien ne s’accumule. Dans un wiki LLM, la connaissance est « compilée une fois puis tenue à jour » : les renvois et les contradictions sont donc déjà traités avant que vous ne posiez la question.

Obsidian est l’IDE ; le LLM est le programmeur ; le wiki est la base de code.

Cette phrase du gist résume l’installation que la plupart des gens reproduisent : l’agent ouvert dans un terminal d’un côté, un éditeur markdown de l’autre, et un dossier de fichiers entre les deux. Le modèle n’exige pourtant aucun éditeur en particulier. N’importe quel dossier et n’importe quel agent capable de lire et d’écrire des fichiers font l’affaire.

Ce qu’un éditeur ne vous dit pas, c’est quelles pages l’agent a modifiées, ni si quelqu’un les a vérifiées. Knowtarium est une base de connaissances chiffrée de bout en bout conçue pour cette installation. Votre wiki vit dans un espace de travail sous forme de pages markdown simples, votre agent le lit et l’écrit via MCP, et chaque page qu’il modifie est signée, montre qui l’a modifiée et peut être annulée. Vous pouvez commencer gratuitement. La suite de ce guide décrit l’installation en fichiers bruts, avec au passage des notes sur la façon dont Knowtarium s’en charge.

Karpathy décrit le modèle du wiki LLM en trois couches :

• Les sources brutes. Vos documents choisis. Ils sont immuables : l’agent les lit et ne les modifie jamais. C’est votre source de vérité.
• Le wiki. Un répertoire de pages markdown que l’agent écrit : résumés, pages d’entités, pages de concepts, comparaisons, une vue d’ensemble. « Vous le lisez ; le LLM l’écrit. »
• Le schéma. Un fichier comme CLAUDE.md pour Claude Code ou AGENTS.md pour Codex, qui dit à l’agent comment le wiki est organisé et quels processus suivre. Vous l’affinez avec l’agent au fil du temps.

Et trois choses que vous demandez à l’agent :

Deux fichiers le rendent navigable. index.md liste chaque page avec un lien et un résumé d’une ligne, et l’agent le lit en premier à chaque question. Karpathy note que cela marche « étonnamment bien » à échelle moyenne (une centaine de sources et quelques centaines de pages) sans aucune recherche par embeddings. Au-delà, le gist suggère de donner à l’agent un outil de recherche locale sur les fichiers markdown. log.md est la chronologie des ingestions, des questions et des passes de lint.

Le gist est volontairement abstrait et laisse les détails à vous et à votre agent. Voici une version concrète qui fonctionne avec Claude Code, Codex ou Cursor. Comptez environ une demi-heure, passée surtout sur le schéma.

1. Créez les dossiers

Séparez les sources et le wiki, pour qu’il soit toujours clair quel texte vient du monde et lequel vient de l’agent.

customer-wiki/
  CLAUDE.md            # le schéma (ou AGENTS.md pour Codex)
  raw/                 # vos sources : l’agent les lit, ne les modifie jamais
    2026-09-12-interview-northwind.md
    2026-09-14-support-tickets.md
    assets/            # images téléchargées à côté des articles enregistrés
  wiki/                # les pages de l’agent
    index.md           # une ligne par page, lu en premier à chaque question
    log.md             # ce qui s’est passé, et quand
    overview.md
    concepts/
    entities/
    sources/           # une page de résumé par source brute
    answers/           # les bonnes réponses, rangées dans le wiki

Dans Knowtarium

Importez customer-wiki/ dans un espace de travail Knowtarium et ses dossiers suivent. Le graphe montre ce qui est périmé (avec la relecture activée, il peut colorer les pages par niveau de confiance), et les liens vers des pages que l’agent n’a pas encore écrites apparaissent en fantômes : une liste de choses à faire pour la prochaine ingestion.

(s’ouvre en grand dans un nouvel onglet) (s’ouvre en grand dans un nouvel onglet)

2. Mettez-le sous git

Lancez git init avant la première ingestion. Karpathy rappelle que le wiki « n’est qu’un dépôt git de fichiers markdown », et git est aussi le moyen le moins cher de voir ce que l’agent a changé. Nous y revenons plus bas.

3. Écrivez le fichier de schéma

C’est le fichier le plus important de l’installation. Commencez court, et ajoutez une règle chaque fois que l’agent fait quelque chose que vous ne vouliez pas. Les recommandations d’Anthropic pour CLAUDE.md s’appliquent ici : restez sous les 200 lignes environ et rendez chaque instruction assez concrète pour pouvoir la vérifier. Si vous utilisez plusieurs agents, écrivez-le une fois sous le nom AGENTS.md et ajoutez un CLAUDE.md qui contient @AGENTS.md, pour que Claude Code charge les mêmes règles.

# Schéma du wiki
 
Tu tiens le wiki dans wiki/. Les sources de raw/ sont en lecture seule.
 
## Pages
- Un concept, une entité ou une source par fichier. Noms de fichiers en kebab-case.
- Chaque page commence par un frontmatter : type, title, description, sources.
- Relie les pages liées par des liens markdown standard.
- Chaque affirmation cite sa source par une note de bas de page nommée d’après l’id de la source.
- Si tu ne peux pas le citer, ne l’écris pas. Signale les questions ouvertes comme telles.
 
## Ingest (quand j’ajoute un fichier à raw/)
1. Lis la source. Donne-moi les 3 à 5 points clés avant d’écrire.
2. Écris wiki/sources/<name>.md avec un résumé et l’id de la source.
3. Mets à jour les pages de concepts et d’entités concernées. Signale les contradictions
   avec les pages existantes au lieu de les écraser en silence.
4. Mets à jour wiki/index.md et ajoute une entrée à wiki/log.md.
5. Liste tous les fichiers que tu as modifiés.
 
## Query
- Lis d’abord wiki/index.md, puis n’ouvre que les pages dont tu as besoin.
- Réponds avec des citations. Propose de ranger les bonnes réponses dans wiki/answers/.
 
## Lint (quand je le demande)
- Signale les contradictions, les affirmations périmées, les pages orphelines, les pages manquantes
  et les affirmations sans source. Propose des corrections ; ne les applique pas encore.

Deux de ces règles comptent plus qu’il n’y paraît : « chaque affirmation cite sa source » et « liste tous les fichiers que tu as modifiés ». Elles ne coûtent rien maintenant et rendent la relecture possible plus tard.

4. Ajoutez une source et ingérez-la

Enregistrez un article en markdown dans raw/ et demandez à l’agent de l’ingérer. Karpathy préfère ingérer une source à la fois et rester impliqué : lire le résumé, vérifier les mises à jour, dire à l’agent sur quoi insister. Faites-le au moins pour les dix premières sources. C’est ainsi que vous découvrez ce qui manque à votre schéma.

Dans Knowtarium

Chaque page que l’ingestion écrit ou modifie est signalée dans la barre latérale jusqu’à ce que vous l’ouvriez, avec sous son titre une ligne qui indique quel agent l’a modifiée et quand, un lien vers les changements et un Undo. Lisez-y le résumé et les mises à jour, et annulez ce que vous ne voulez pas. Si vous préférez approuver d’abord, activez la relecture (« Ask me first ») pour le dossier wiki/, et chaque changement vous attend sous forme de diff.

(s’ouvre en grand dans un nouvel onglet) (s’ouvre en grand dans un nouvel onglet)

5. Posez des questions et gardez les bonnes réponses

Posez des questions qui croisent les sources, pas seulement sur une seule. Quand une réponse vaut la peine d’être gardée, demandez à l’agent de la ranger dans wiki/answers/ et de la lier depuis les pages dont elle s’inspire.

# ingérer une source
> Ingère raw/2026-09-14-support-tickets.md. Montre-moi d’abord les points clés.
 
# poser une question, puis garder la réponse
> En t’appuyant uniquement sur le wiki, où les nouveaux clients bloquent-ils ? Cite les pages.
> Range ça dans wiki/answers/onboarding-blockers.md et ajoute un lien.
 
# bilan de santé
> Passe le wiki au lint. Ne change rien pour l’instant, donne-moi une liste.

6. Passez le lint à intervalles réguliers

Une fois par semaine, ou toutes les dix ingestions, demandez une passe de lint. Demandez d’abord un rapport et approuvez les corrections à part, pour qu’un bilan de santé ne puisse pas réécrire en douce la moitié du wiki. Un préfixe constant dans le journal permet de voir facilement ce qui s’est passé récemment :

## [2026-09-14] ingest | Tickets de support, août
## [2026-09-15] query | Où les nouveaux clients bloquent-ils ?
## [2026-09-20] lint | 2 contradictions, 4 pages orphelines

$ grep "^## \[" wiki/log.md | tail -5

Le modèle du wiki LLM rend l’entretien presque gratuit. C’est tout l’intérêt, et c’est aussi le risque. L’agent peut toucher 15 pages en une passe, et dans la plupart des installations personne ne lit ces 15 changements. Karpathy lui-même reste impliqué quand il ingère, et pour les wikis d’équipe il évoque « éventuellement des humains dans la boucle qui relisent les mises à jour ». La plupart des tutoriels sautent cette partie. Voici ce qui s’accumule quand on la saute :

• La dérive par rapport à la source. Le résumé d’un résumé perd une nuance. « Dans certains benchmarks » devient « systématiquement », et trois pages plus loin, c’est un fait.
• Des synthèses sans source. L’agent relie deux idées dans une phrase qui se lit bien et ne cite rien. Impossible de la distinguer d’une affirmation sourcée.
• Des contradictions tranchées en silence. Une nouvelle source contredit une ancienne page, et l’agent choisit un gagnant au lieu de le signaler.
• Des pages périmées qui ont l’air fraîches. Une page écrite en mai se lit pareil en décembre. Rien n’indique qu’il est temps de la vérifier.
• Vos propres modifications se désynchronisent. Vous corrigez un chiffre sur une page. Les cinq pages qui le répètent ont toujours l’ancien.
• Le lint corrige sa propre copie. Le lint, c’est le même genre de modèle qui lit les mêmes pages. Il repère les contradictions entre pages, pas les erreurs sur lesquelles toutes les pages s’accordent.

Rien de tout cela ne fait du modèle une mauvaise idée. Cela veut dire qu’un wiki LLM a besoin de la même chose que toute base de code écrite par un seul auteur : un deuxième regard, et une trace de qui a écrit quoi.

Quatre habitudes comblent l’essentiel du trou. Vous pouvez les adopter une par une, en fichiers bruts, sans nouvel outil.

1. Notez la provenance dans le frontmatter

Chaque page devrait dire qui l’a écrite, quand et à partir de quelles sources, et chaque affirmation devrait renvoyer à l’une de ces sources. Les notes de bas de page nommées d’après l’id d’une source ([^northwind-call]) résistent quand l’agent réordonne la liste, contrairement aux notes numérotées. Voici une page qui utilise les noms de champs de l’Open Knowledge Format, pour que d’autres outils puissent aussi les lire :

---
type: Concept
title: Abandons à l’étape d’import
description: Pourquoi les nouveaux clients bloquent quand ils importent leurs données.
generated: { by: claude-code/2.1, at: 2026-09-20T09:12:00Z }
verified:
  - { by: human:sam, at: 2026-09-20T18:40:00Z }
stale_after: 2027-03-20T00:00:00Z
sources:
  - id: northwind-call
    resource: /raw/2026-09-12-interview-northwind.md
    title: Entretien client, Northwind Traders
---
 
Northwind est resté bloqué une semaine sur l’import CSV.[^northwind-call]

generated indique qui a écrit le texte actuel. verified indique qui l’a vérifié, et le préfixe human: désigne une personne. Ajoutez une ligne à votre schéma : « signe dans generated chaque page que tu modifies, ne t’ajoute jamais à verified ». Notre guide pour faire citer leurs sources aux agents va plus loin.

2. Relisez chaque changement d’agent avant de vous y fier

Traitez une ingestion comme une pull request. Faites un commit avant de commencer, laissez l’agent travailler, puis lisez le diff et acceptez-le ou rejetez-le. Git fait cela très bien :

$ git status --short          # quelles pages ont changé$ git diff --stat             # dans quelle mesure$ git diff wiki/concepts/     # lire les modifications elles-mêmes$ git add -p                  # accepter bloc par bloc$ git commit -m "ingest: support tickets"$ git restore wiki/entities/  # jeter ce que vous n’avez pas accepté

Ne lisez pas chaque page. Lisez les lignes qui ont changé, et vérifiez chaque nouvelle affirmation par rapport à la note de bas de page qu’elle cite. Quand vous approuvez une page, ajoutez-vous à verified avec la date. La méthode complète se trouve dans comment relire les modifications des agents.

3. Faites vérifier vos modifications par l’agent

La relecture devrait marcher dans les deux sens. Quand vous modifiez une page à la main, demandez à l’agent de trouver chaque page qui pointe vers elle, cite la même source ou répète l’ancienne valeur, et de proposer des corrections pour ces pages. Vous relisez ensuite ces corrections comme n’importe quel changement d’agent. C’est ainsi que votre correction atteint les cinq autres pages.

4. Donnez une date d’expiration aux pages

Ajoutez stale_after avec une date absolue : courte pour les prix, les versions et les rôles des gens, longue pour les définitions. Une passe de lint peut alors lister les pages qui ont dépassé leur date au lieu de deviner. La péremption devient une comparaison de dates, pas une affaire de jugement.

L’Open Knowledge Format est une spécification ouverte publiée par Google Cloud pour la connaissance écrite par des agents. La version 0.2 a ajouté des signaux de confiance exactement pour le cas ci-dessus : des corpus écrits en continu par des agents et lus par d’autres agents. Un paquet OKF a la même forme qu’un wiki LLM (un dossier de fichiers markdown avec un frontmatter YAML), et il réserve les deux mêmes noms de fichiers, index.md et log.md.

Les lecteurs déduisent un niveau de confiance de verified : aucune entrée signifie unverified, seulement des agents ou des processus signifie machine-confirmed, et au moins une personne signifie human-reviewed. Une page ne peut jamais se déclarer elle-même digne de confiance. Deux petites différences avec le gist : le gist n’impose pas de syntaxe de lien, alors qu’OKF utilise des liens markdown standard ; et le log.md d’OKF liste les entrées les plus récentes en premier, sous de simples titres de date YYYY-MM-DD. Chaque champ est facultatif : vous pouvez donc démarrer un wiki LLM en OKF et ajouter les champs de confiance au fur et à mesure.

Git est la base : il vous montre ce qui a changé, si vous faites un commit avant chaque session et lisez le diff après. Knowtarium est l’installation que nous recommandons quand le wiki grandit, parce qu’il garde l’historique, l’annulation et l’état de confiance à côté des pages plutôt que dans votre terminal. Voici comment les deux se comparent.

Si vous ingérez quelques sources par semaine et lisez chaque diff, git seul peut suffire. Knowtarium est une application web : vos pages sont chiffrées sur votre appareil avant de nous parvenir, nous ne pouvons donc pas les lire, et il n’appelle aucune IA lui-même. L’agent que vous connectez voit ce qu’il lit. Si votre wiki vit déjà dans un coffre Obsidian, importez-le dans un espace de travail et il est converti en OKF sans toucher à ce que vous avez écrit ; le guide de migration détaille la démarche, et la page de comparaison explique en quoi les deux applications diffèrent.