Discutons de votre projet
Un appel de 30 minutes pour cadrer votre cas d'usage IA.
Sans formulaire de qualification, sans engagement. On parle de votre contexte, on identifie ce qui peut bouger vite, on vous dit honnêtement où l'IA n'apportera rien.
AGE Services
Mis à jour le 6 août 2026 · 6 min de lecture
Le LLM wiki, une mémoire que l’agent cultive
Le LLM wiki est un pattern d’architecture publié par Andrej Karpathy (co-fondateur d’OpenAI, ex-directeur IA de Tesla) dans un gist daté d’avril 2026. Le principe : plutôt que de faire chercher l’IA dans des documents bruts à chaque question — comme le RAG — on lui fait lire les sources une seule fois, puis compiler une base de connaissances synthétisée : des fichiers Markdown interconnectés qu’elle maintient à jour au fil des nouvelles informations.
L’agent navigue ce graphe de fichiers (il suit des liens, comme un humain parcourt une encyclopédie) au lieu d’interroger une base vectorielle. Karpathy résume l’idée par une analogie : « Obsidian est l’IDE, le LLM est le programmeur, le wiki est la base de code. »
Trois traits distinctifs
Compilé
Lu une fois, synthétisé
L'agent lit les sources une seule fois et en compile des pages de synthèse, au lieu de tout re-parcourir à chaque question.
Relié
Un graphe Markdown
Des fichiers Markdown interconnectés par des liens [[wiki]] ; l'agent navigue, il ne fait pas de recherche vectorielle.
Sans infra
Zéro base vectorielle
Ni serveur ni pipeline d'embeddings : seulement des fichiers texte, versionnables et portables.
Ce choix du fichier texte a une conséquence peu commentée mais structurante : la mémoire n’appartient à aucun assistant. Exposée par un serveur MCP (Model Context Protocol), la même arborescence Markdown peut être lue et alimentée par plusieurs modèles différents en parallèle — et changer d’assistant ne fait rien perdre, puisque rien n’est stocké dans un format propriétaire.
Andrej Karpathy, à l’origine du pattern « LLM wiki », expose ici sa vision d’ensemble : le LLM comme nouveau « système d’exploitation » et la conception de logiciels pensés pour des agents — le cadre dans lequel s’inscrit l’idée du wiki (keynote Y Combinator, 2025).
Le principe en trois couches
L’architecture sépare nettement trois rôles, ce qui garantit la traçabilité (on ne mélange jamais la source et sa synthèse).
L'anatomie du système
raw/
Sources brutes (lecture seule)
Vos documents d'origine — PDF, notes, comptes rendus, contrats — jamais modifiés. L'agent les lit, ne les change pas.
wiki/
Le wiki (maintenu par l'IA)
Des pages Markdown organisées en entités et synthèses, chacune avec résumé, sources, date et liens.
CLAUDE.md
Le schéma (les règles)
Le document qui dit à l'agent comment structurer le wiki, ingérer une source, tisser les liens et journaliser.
L’anatomie d’une page
Chaque page du wiki suit une structure standardisée — c’est ce qui la rend lisible par l’agent comme par un humain, et auditable.
La structure type d'une page wiki
Titre en WikiLink. Le nom de l’entité ou du concept, cible des liens entrants.
Résumé en tête. Quelques lignes de synthèse : ce que l’agent lit en premier pour décider si la page est pertinente.
Sources & date. La traçabilité : de quels documents raw/ la page est issue, et quand elle a été mise à jour.
Contenu relié. Le corps de la page, parsemé de [[liens]] vers les pages connexes — ce sont eux qui forment le graphe.
Pages liées. Une section finale qui liste les connexions, pour la navigation de proche en proche.
Le cycle d’ingestion
Le wiki n’est pas figé : il grandit à mesure que de nouveaux documents arrivent. L’agent suit alors un cycle régulier.
Du document brut au graphe enrichi
1
Arrivée
Un document arrive dans raw/ (CR, contrat, note).
→
2
Analyse
L'agent le lit et en extrait entités et concepts.
→
3
Mise à jour
Il crée ou enrichit les pages concernées.
→
4
Liens
Il tisse les [[liens]] : le graphe s'étend.
→
5
Audit
Il corrige orphelines, liens brisés, contradictions.
Cette dernière étape — l’audit (ou lint) — est ce qui distingue une mémoire saine d’un fouillis : l’agent vérifie périodiquement la cohérence de l’ensemble, comme on relit et range une base documentaire.
LLM wiki ou RAG ?
Les deux approches donnent à un agent l’accès à une connaissance propriétaire, mais par des chemins opposés. Le tableau les situe.
Deux philosophies de la mémoire
LLM wiki ou RAG
Critère
LLM wiki
RAG
Accès à la connaissance
Navigation par index et liens
Recherche vectorielle (similarité)
Préparation
L'agent compile une fois, puis maintient
Pipeline d'ingestion + embeddings
Infrastructure
Fichiers Markdown, zéro serveur
Base vectorielle à exploiter et surveiller
Mémoire
Cumulative, s'enrichit dans le temps
Index ré-interrogé à chaque requête
Idéal pour
Connaissances textuelles stables
Gros corpus, données changeantes
Sur le plan du coût en tokens, l’argument du LLM wiki est que l’agent charge un index et quelques pages pertinentes, pas tout le corpus brut. Des analyses tierces avancent des économies pouvant atteindre 90 à 95 % sur certains cas — un ordre de grandeur non confirmé par un banc d’essai reproductible ni par Karpathy lui-même, à manier avec prudence.
Quand cette approche convient (ou pas)
Cartographie besoin → approche
Connaissances internes textuelles et stables
LLM wiki
Offres, processus, cas métier, décisions.
Réduire le coût en tokens d'agents récurrents
LLM wiki
L'agent charge les pages utiles, pas tout le corpus.
Données temps réel ou très volumineuses
RAG
Un pipeline vectoriel est plus adapté aux flux.
Recherche exacte fine dans un grand corpus
RAG (hybride)
Le wiki navigue, il ne fait pas de recherche fine.
Visualiser le graphe de connaissances
Obsidian
Le conteneur et la vue ; le wiki est le contenu.
En synthèse, le LLM wiki est une approche émergente mais cohérente pour donner à un agent une mémoire d’organisation persistante : l’IA compile les sources en un graphe Markdown qu’elle maintient et navigue, sans serveur ni base de données obligatoire. Sa force est la simplicité (des fichiers texte, une mémoire qui s’enrichit, un coût en tokens contenu) ; sa limite est son terrain — les connaissances textuelles stables, là où le RAG reste préférable pour les flux volumineux ou changeants. Les deux approches se combinent d’ailleurs bien : le wiki porte les arbitrages et les décisions lus en entier, un index vectoriel local peut compléter en couche de recherche sur le volume — l’index sert, il ne décide pas : les fichiers texte restent la vérité, et l’index se reconstruit depuis eux. Concrètement, il s’installe dans un vault Obsidian — Obsidian est le conteneur et l’interface, le LLM wiki le contenu et la méthode.
Vos questions
Questions fréquentes
Qu'est-ce que le « LLM wiki » et d'où vient l'idée ? +
C'est un pattern d'architecture publié par Andrej Karpathy (co-fondateur d'OpenAI) dans un gist daté d'avril 2026. Le principe : plutôt que de faire chercher l'IA dans des documents bruts à chaque question (comme le RAG), on lui fait lire les sources une seule fois pour qu'elle compile une base de connaissances synthétisée — des fichiers Markdown interconnectés qu'elle maintient à jour. Karpathy résume l'analogie ainsi : « Obsidian est l'IDE, le LLM est le programmeur, le wiki est la base de code. »
En quoi diffère-t-il du RAG ? +
Le RAG récupère des extraits par recherche vectorielle à chaque requête, sur des documents bruts. Le LLM wiki, lui, fait compiler les sources en pages de synthèse reliées par des liens, que l'agent navigue (comme un humain suit des liens dans une encyclopédie) plutôt que d'interroger une base vectorielle. Il n'y a donc ni base de données, ni pipeline d'embeddings à maintenir — seulement des fichiers texte.
Le LLM wiki fait-il vraiment économiser des tokens ? +
Probablement, mais avec prudence sur les chiffres. L'idée est que l'agent charge un index et quelques pages pertinentes plutôt que tout le corpus brut. Des analyses tierces avancent des économies pouvant atteindre 90 à 95 % sur certains cas — mais ces chiffres ne sont pas confirmés par un banc d'essai reproductible, ni par Karpathy lui-même. À considérer comme un ordre de grandeur, pas une garantie.
Quand cette approche est-elle pertinente, et quand l'est-elle moins ? +
Pertinente quand la base de connaissances est principalement textuelle et relativement stable (offres, processus, cas métier, décisions). Moins adaptée aux données temps réel ou très volumineuses en flux, pour lesquelles un RAG avec pipeline dédié répond mieux. L'approche s'installe dans un vault Obsidian et s'appuie sur un agent (type Claude Code) pour lire les sources et maintenir le wiki.