En avril 2026, Andrej Karpathy a rédigé un GitHub Gist. Il y décrit une méthode. Il l’appelle le LLM Wiki.
Quatre équipes ont construit la même chose par la suite. Cognition a bâti DeepWiki. Factory a bâti AutoWiki. LangChain a publié OpenWiki. Garry Tan a publié GBrain.
La méthode est identique dans les quatre systèmes. Un LLM lit vos documents sources une seule fois. Il écrit les informations dans des pages markdown. Il maintient les pages à jour lorsque les sources changent. L’agent lit ces pages. L’agent ne relit pas les documents sources pour chaque question.
On appelle ces systèmes des wikis pour agents. Cet article vous explique ce qu’ils sont. Il vous dit ce que chaque équipe a construit. Il vous montre les limites de la méthode. Il vous révèle aussi une différence importante que beaucoup négligent.
L’idée : compiler à l’ingestion, pas à la requête
La méthode habituelle pour donner à un modèle un grand ensemble de documents est la recherche (retrieval). Vous placez les documents dans une base de données. Vous les découpez en morceaux. Vous créez des embeddings pour ces morceaux. Pour chaque question, le système trouve les morceaux pertinents.
Cette méthode fonctionne. Elle a aussi un problème. Le système ne conserve pas les résultats. Il reconstruit chaque réponse à partir des morceaux bruts. La dixième réponse n’est pas meilleure que la première. Vous payez le coût du travail dix fois.
Un wiki pour agent déplace ce coût. Le modèle effectue le travail une fois, lorsqu’il lit la source. Il écrit les résultats dans des pages. Les pages perdurent.
Le modèle réalise ces étapes quand une nouvelle source arrive. Il lit la source. Il modifie les pages concernées. Il corrige les résumés. Il signale les informations en contradiction avec les pages.
Les deux méthodes sont correctes. Elles diffèrent sur deux points. La première différence est le moment où vous payez le coût. La seconde différence est ce qui reste après la question.
Chaque système possède les trois mêmes couches.
La couche 1 est constituée des documents sources. Ce sont vos articles, vos papiers et vos dépôts. Le modèle les lit. Le modèle ne les modifie pas.
La couche 2 est le wiki. Le wiki est en markdown. Le modèle écrit l’intégralité du wiki. Le wiki contient des résumés, des pages pour chaque sujet, et des liens entre les pages.
La couche 3 est le fichier de schéma. Ce fichier indique au modèle la structure du wiki. Il lui dit aussi quelles tâches effectuer. Le fichier habituel est CLAUDE.md ou AGENTS.md. Ce fichier fait du modèle un mainteneur correct du wiki.
Le système effectue trois opérations.
Ingestion : le modèle lit une nouvelle source. Puis il écrit les données dans chaque page concernée.
Requête : vous posez une question au wiki. Vous pouvez écrire une bonne réponse dans le wiki comme une nouvelle page.
Lint : le modèle examine le wiki. Il trouve les informations en contradiction. Il trouve les informations trop anciennes. Il trouve les pages sans lien.
Pourquoi ça marche :
Les wikis humains deviennent obsolètes avec le temps. La cause est spécifique. La partie difficile n’est pas de lire les sources. La partie difficile n’est pas d’avoir les idées. La partie difficile est la maintenance.
La maintenance comprend ces tâches : vous devez corriger les liens entre les pages. Vous devez garder les résumés exacts. Vous devez comparer chaque nouveau document avec les pages existantes.
Ce travail ne s’arrête pas. Ce travail n’apporte aucune récompense. Une équipe débordée arrête ce travail en premier. Ensuite le wiki devient inexact. Ensuite les gens ne l’utilisent plus.
Un modèle effectue ce travail sans problème. Le modèle ne s’ennuie pas. Le modèle n’oublie pas un lien. Le modèle peut modifier quinze fichiers en une seule opération.
L’idée est ancienne. Vannevar Bush a décrit le Memex en 1945. Le Memex est un stockage personnel de documents avec des liens entre eux. Bush n’avait pas de réponse pour la maintenance. Le modèle est la réponse.
D’où vient le nom
Lisez le gist de Karpathy directement. Il est plus précis que les résumés qu’on en fait.
Il écrit ceci à propos de la méthode habituelle : « le LLM redécouvre la connaissance à partir de zéro à chaque question. Il n’y a pas d’accumulation. »
Sa méthode consiste à compiler l’information, et non à la retrouver. Ainsi « la connaissance est compilée une fois puis maintenue à jour, pas redérivée à chaque requête. » Le résultat est « un artefact persistant et cumulatif. »
Vous n’écrivez pas le wiki. Il écrit : « Vous n’écrivez jamais (ou rarement) le wiki vous-même, le LLM écrit et maintient tout. » Il utilise l’agent et Obsidian ensemble. Il écrit : « Obsidian est l’IDE ; le LLM est le programmeur ; le wiki est la base de code. »
Le gist donne une limite de taille. De nombreux résumés n’incluent pas cette limite. La méthode sans embeddings « fonctionne étonnamment bien à échelle modérée (~100 sources, ~centaines de pages) et évite le besoin d’une infrastructure RAG basée sur les embeddings. »
Pour plus de sources, le gist vous conseille d’ajouter une recherche. Il donne qmd comme exemple. Le gist décrit qmd comme « un moteur de recherche local pour fichiers markdown avec recherche hybride BM25/vectorielle et réordonnancement par LLM. »
Ainsi la règle porte sur la taille. La règle ne porte pas sur le remplacement. N’utilisez pas d’infrastructure de recherche quand l’ensemble de sources est petit. Ajoutez de la recherche quand l’ensemble devient grand.
Ce que les laboratoires ont réellement construit
C’est là que le modèle cesse d’être une idée pour devenir de l’ingénierie, et les différences entre les implémentations sont la partie utile.
Cognition : DeepWiki, le wiki comme service public
Cognition a appliqué la méthode aux dépôts publics sur GitHub. Remplacez github.com par deepwiki.com dans l’URL d’un dépôt public. Vous obtenez alors un wiki pour cette base de code. Le wiki contient un résumé d’architecture, un index des fichiers, un graphe de dépendances et une recherche. Le wiki a des liens vers la source (Cognition).
Plus de 50 000 des plus grands dépôts publics ont un wiki. La liste inclut MCP et LangChain.
Le deuxième point est plus important. Le wiki n’est pas le produit. Le wiki est une infrastructure de recherche pour l’agent. Devin utilise le wiki pour trouver le code pertinent dans une base de code. DeepWiki est donc la couche compilée sous la recherche de code dans Devin (Devin Docs).
Factory : AutoWiki, la documentation comme artefact de build
Factory a appliqué la méthode à l’intégration continue. Factory écrit que la documentation doit être un artefact de build, et non un projet séparé. La documentation vient de la source. Elle a la structure de la base de code. Elle change quand le dépôt change (Factory).
La méthode pour créer le wiki comporte deux passes. La passe 1 est un scan structurel. Elle lit le fichier README, les manifests de paquets, la configuration CI et les points d’entrée. La passe 2 est un scan sémantique. Elle lit les routes, les points de terminaison API, les classes de service, les schémas de base de données et les feature flags.
Factory divise le travail entre des agents spécialisés. Chaque agent reçoit une partie du dépôt. Chaque agent reçoit assez de contexte pour écrire une bonne page. Cette méthode évite un problème connu : un seul agent écrit une mauvaise documentation pour un grand dépôt.
Factory maintient le wiki à jour avec de l’infrastructure, et non avec de la discipline. La commande /wiki reconstruit le wiki. La commande /install-wiki écrit un workflow CI. Ce workflow reconstruit le wiki à chaque push sur la branche par défaut. Pour GitHub, le wiki va dans l’onglet wiki du dépôt (Factory Docs).
LangChain : OpenWiki, et le passage du code à tout
LangChain a publié OpenWiki en logiciel open source. OpenWiki est un outil en ligne de commande. Il écrit et maintient la documentation d’un agent pour une base de code. LangChain a ensuite publié OpenWiki Brains, qui a deux modes. Code Brain est le premier mode, pour un dépôt. Personal Brain est le second mode, pour vos propres sources (LangChain).
Personal Brain est le changement important. Il lit les données de Gmail, Notion, dépôts git, X, Hacker News et la recherche web. Il écrit toutes ces données dans un seul wiki local en markdown. L’agent lit ce wiki. La méthode est passée de la documentation d’un dépôt à la documentation de votre travail.
Chaque équipe a pris la même décision concernant la sortie. La sortie n’est pas un texte à lire par un humain. La sortie est un markdown structuré pour le contexte LLM. Il contient des titres, des liens entre pages et des résumés. La structure permet à un agent de trouver rapidement l’information pertinente. Le lecteur du wiki est un modèle.
GBrain : la version open source à l’échelle personnelle
GBrain applique la méthode à un stockage de connaissances personnel, et non à une base de code. GBrain utilise le markdown dans un dépôt git. Il a un fichier de schéma. Il crée automatiquement un graphe de liens entre les sujets.
GBrain montre que la méthode nécessite très peu d’infrastructure. Pas de base de données vectorielle. Pas de service. Rien que des fichiers. Un modèle maintient les fichiers. Un humain peut les lire.
La matrice technique
Les quatre systèmes ont la même structure. Ils utilisent le markdown dans git. Ils utilisent un fichier de schéma. Ils compilent à l’ingestion. Ils reconstruisent le wiki quand les sources changent. Ils écrivent les pages pour qu’un agent les lise. Quatre équipes ont résolu quatre problèmes différents et ont construit la même structure. Cet accord est une bonne preuve que la structure est correcte.
Les systèmes diffèrent dans la maintenance. Factory fait la maintenance dans la CI. Les trois autres systèmes font la maintenance quand une personne exécute une commande. Leurs wikis sont donc aussi exacts que la dernière commande.
Où ça s’arrête
Limite 1 : la taille. Karpathy donne cette limite. La méthode sans embeddings est correcte pour environ 100 sources. Pour plus de pages, vous devez ajouter un moteur de recherche. Le gist vous conseille d’utiliser ensemble la recherche BM25 et la recherche vectorielle.
Limite 2 : la précision. Le modèle compile l’information à l’ingestion. Un résumé précoce peut supprimer un détail de la source. Chaque réponse ultérieure contient cette erreur. La recherche dans les morceaux bruts n’a pas ce problème. Vous échangez le coût du travail répété contre le risque de perte de données.
Limite 3 : les informations obsolètes. Une page n’est aussi exacte que la dernière mise à jour. C’est la raison pour laquelle la méthode Factory est importante. Un wiki inexact est pire que pas de wiki. L’information inexacte a le format d’une information correcte.
Limite 4 : le coût. Vous payez des tokens pour créer des pages. Vous pouvez créer des pages que personne ne lit. Vous payez aussi des tokens pour linter des pages qui n’ont pas changé.
Un wiki n’est pas une mémoire
Il y a une différence que vous devez connaître. Les mots dans ce domaine ne sont pas encore précis.
Beaucoup de gens appellent ces systèmes de la mémoire. LangChain appelle OpenWiki une couche mémoire wiki pour les agents IA. D’autres disent qu’un wiki donne de la mémoire à un agent. Le mot mémoire a ici deux significations différentes.
La première signification est la connaissance d’un ensemble de documents. Un wiki fait cela. Il compile les données de vos documents, de votre dépôt ou de votre Gmail. Il vous dit ce que contiennent les documents.
La seconde signification est la mémoire d’un utilisateur. Ce sont des données différentes. Cela inclut les préférences d’une personne. Cela inclut les décisions d’une personne. Cela inclut les méthodes qu’une équipe a rejetées. Cela inclut le résultat quand un agent a essayé une méthode dans une autre application.
La mémoire d’un utilisateur a une structure différente. Elle est liée à une personne, et non à un ensemble de documents. Elle provient de l’interaction, et non de l’ingestion. Elle doit aussi effectuer ces tâches pour chaque utilisateur : corriger les informations contradictoires, supprimer les informations trop anciennes, conserver la source de chaque élément, et supprimer les données sur demande.
Un wiki fait correctement la première tâche. Un wiki ne fait pas la seconde tâche. Votre wiki Gmail dit à l’agent ce qu’il y a dans votre Gmail. Il ne dit pas à l’agent que vous avez changé une décision lors d’une conversation mardi. Il ne dit pas à l’agent qu’une méthode a déjà échoué pour vous.
Une couche mémoire fait la seconde tâche. Mem0 en est un exemple. Elle conserve chaque mémoire avec un user_id. La mémoire se déplace ainsi avec la personne entre les sessions, les applications et les agents. Elle modifie un fait en place quand le fait change. Elle n’ajoute pas un nouvel enregistrement à chaque fois.
Les deux systèmes ne sont pas alternatifs. Utilisez les deux. L’erreur n’est pas d’utiliser un wiki. L’erreur est de penser qu’un wiki vous donne la mémoire d’un utilisateur.
Résumé
L’idée des wikis pour agents est correcte. Compilez la connaissance une fois. Puis maintenez-la à jour. Ne la reconstruisez pas pour chaque question. La maintenance a bloqué les wikis humains, et un modèle fait la maintenance sans coût supplémentaire. Quatre équipes ont construit la même structure en quelques mois. C’est une preuve solide.
Faites ces trois choses. Compilez vos documents en pages quand l’ensemble de documents est stable et que vous le lisez fréquemment. Ajoutez de la recherche quand l’ensemble devient grand, comme le dit le gist. Gardez la différence entre la connaissance d’un ensemble de documents et la mémoire d’un utilisateur. Un wiki vous donne la première. Un wiki ne vous donne pas la seconde.
In Context #17
Ce blog fait partie d’In Context, une série de blogs de @mem0ai couvrant la mémoire des agents IA et l’ingénierie de contexte.
Mem0 est une couche mémoire intelligente et open source conçue pour les LLM et les agents IA afin de fournir des interactions à long terme, personnalisées et contextuelles entre les sessions.
- Obtenez votre clé API gratuite ici : app.mem0.ai
- ou auto-hébergez mem0 depuis notre dépôt GitHub open source
Références
- Andrej Karpathy, LLM Wiki (GitHub Gist, avril 2026)
- qmd : recherche hybride locale BM25/vectorielle pour markdown
- Cognition, DeepWiki : documentation IA pour tout dépôt
- Devin Docs, DeepWiki
- Factory, Présentation d’AutoWiki
- Documentation Factory, Vue d’ensemble d’AutoWiki
- langchain-ai/openwiki (GitHub)
- LangChain, Wiki Memory
- garrytan/gbrain (GitHub)
- Vannevar Bush, As We May Think (The Atlantic, 1945)
- Mem0
