Pendant deux ans, la réponse par défaut à « comment je donne ma connaissance à un LLM ? » était RAG. Construire une base de données vectorielle. Découper vos documents en chunks. Les embeder. Lancer une recherche du plus proche voisin au moment de la requête. Recoudre les résultats dans le prompt.

Ça marchait. À peu près. Quiconque a vraiment livré un système RAG connaît les modes d’échec : des chunks qui perdent le contexte, des embeddings qui récupèrent le mauvais passage, des classements opaques, pas de provenance, des cas limites bizarres quand l’utilisateur pose une question pour laquelle l’index n’était pas calibré.

En avril 2026, Andrej Karpathy a posté un workflow qui ne fait presque rien de tout ça et fonctionne mieux pour la connaissance personnelle. Il l’appelle LLM Knowledge Bases. L’architecture est juste un dossier de fichiers markdown, un LLM avec accès au système de fichiers, et une habitude. VentureBeat l’a décrit comme « une bibliothèque markdown évolutive maintenue par l’IA » — une description qui capture ce qui est vraiment nouveau.

Le pattern post-RAG est là. Cet article explique ce que c’est, pourquoi ça marche, et comment Save Vault le rend accessible sans aucune configuration développeur.

Ce que RAG essayait de résoudre

Le problème d’origine : les LLM ont une fenêtre de contexte fixe, votre base de connaissances est plus grande que la fenêtre, donc vous avez besoin d’un moyen de récupérer le bon slice pour chaque question.

En 2023, les vecteurs étaient la réponse évidente. Tout embeder, chercher par similarité, injecter les top-k chunks. Ça se combinait bien avec les petites fenêtres de contexte de GPT-3.5 et Claude 1. Tout le pattern « startup IA » était « RAG sur X ».

Trois choses ont changé.

Les fenêtres de contexte ont explosé. Claude a livré 1M tokens de contexte cette année. Gemini et GPT-5 sont similaires. Un million de tokens c’est environ 750 000 mots — assez pour tenir un petit wiki entier en mémoire.
Le filesystem MCP a été livré. Les LLM peuvent maintenant ouvrir des fichiers sur disque directement. Ils n’ont pas besoin de chunks pré-indexés. Ils peuvent naviguer, lire, et relire comme un humain.
Les LLM sont devenus meilleurs en lecture. Claude Opus 4 peut ingérer des centaines de fichiers en une session et raisonner de façon cohérente à travers eux. Le goulot d’étranglement est passé de « qualité de récupération » à « ce dont l’humain a vraiment besoin ».

Une fois ces trois choses vraies, RAG a commencé à ressembler à un contournement pour des limitations qui n’existent plus.

À quoi ressemble le pattern wiki Markdown

Le setup de Karpathy, simplifié :

Dossier brut. Chaque page web qu’il veut garder est sauvegardée comme fichier .md dans un répertoire raw/. Il utilise Obsidian Web Clipper pour ça.
Passe de compilation. Périodiquement, un agent LLM (Claude Code dans son cas) lit tout dans raw/, génère des pages de concepts, écrit des résumés, et crée des backlinks. Ça produit un wiki structuré au-dessus du matériel brut.
Boucle de requête. Quand il a une question, il demande au LLM. Il cherche dans le wiki, ouvre les fichiers pertinents, et répond en utilisant les contenus.
Passe de lint. Occasionnellement le LLM scanne le wiki pour les incohérences, les données manquantes, ou les nouvelles connexions qui valent la peine d’être notées.

Son wiki de recherche actuel fait ~100 articles et ~400K mots. Il lui pose des questions complexes et obtient des réponses sourcées.

Pas de base de données vectorielle. Pas de modèle d’embedding. Pas de stratégie de chunking. Pas de classement de récupération. Juste des fichiers markdown, une structure de dossiers, et un LLM qui peut les lire.

Pourquoi ça fonctionne mieux que RAG (pour ça)

Le pattern wiki a des avantages structurels que RAG ne peut pas égaler sans devenir lui-même un wiki.

La provenance est gratuite. Chaque réponse cite un fichier. Vous pouvez l’ouvrir, le lire, le modifier, le supprimer. Pas de « l’embedding l’a dit ».

L’édition est triviale. Un fichier markdown est du texte. Ouvrez-le dans n’importe quel éditeur. Corrigez une faute. Ajoutez une note. Supprimez une section. La prochaine requête reflète immédiatement le changement. Pas d’étape de re-embedding.

La structure se compose. Quand le LLM compile le wiki, il construit des backlinks et des pages de concepts. Le wiki devient meilleur plus vous sauvegardez, parce que le LLM a plus de contexte pour connecter les nouvelles entrées. Un index vectoriel ne fait que grossir.

La portabilité est totale. Un dossier de fichiers .md fonctionne dans Obsidian, VS Code, GitHub, Logseq, vim, ou cat. Une base de données vectorielle est une boîte noire que vous devez avoir un runtime spécifique pour lire.

Vous pouvez le lire vous-même. Ça semble évident, mais c’est le plus grand avantage. Vous voudrez parfois savoir ce qui est dans votre base de connaissances. Avec RAG, c’est une requête de reporting. Avec markdown, c’est ls.

Le compromis honnête : RAG gagne encore quand vous avez des millions de documents, un accès multi-tenant, ou des contraintes de latence strictes (pensez aux chatbots de support client sur un corpus de millions d’articles d’aide). Pour la connaissance personnelle — votre lecture, votre recherche, votre domaine — le pattern wiki est maintenant strictement meilleur.

La pièce manquante : l’ingestion

Le pattern de Karpathy a une hypothèse silencieuse : qu’obtenir du markdown propre dans le dossier raw/ est facile. Pour les développeurs qui utilisent déjà Obsidian Web Clipper, c’est à peu près vrai. Pour tout le monde d’autre, c’est l’étape où le workflow meurt.

Web Clipper peut se débattre avec les pages sous paywall, les sites JavaScript-lourds, le contenu vidéo, les threads X, et tout ce qui est dynamique. Les gens sauvegardent du HTML confus, abandonnent, et concluent que « la chose wiki n’est pas pour eux ».

L’extension Save existe spécifiquement pour corriger cette étape. Elle utilise Gemini pour extraire du contenu propre de pages arbitraires, incluant :

Les articles derrière des paywalls auxquels vous avez accès
Les vidéos YouTube (transcription complète + résumé IA)
Les threads X/Twitter
Les reels Instagram et captions TikTok (transcrits)
Les discussions Reddit
La documentation avec les blocs de code intacts
Les SPA dynamiques sur lesquelles les clippers traditionnels s’étouffent

Un clic. Du markdown propre de l’autre côté. À déposer dans le dossier.

L’autre pièce manquante : la config MCP

Le pattern de Karpathy suppose aussi que vous pouvez configurer un serveur MCP. Pour les utilisateurs de Claude Code, c’est un cd d’une ligne. Pour ceux qui utilisent Claude Desktop, ça signifie éditer un fichier de config JSON et redémarrer l’app — et avoir le bon chemin, et se souvenir de le refaire quand vous déplacez des dossiers.

Save Vault collapse les deux pièces manquantes en une seule app :

L’extension Save alimente du markdown propre dans Save Vault automatiquement
Save Vault écrit dans ~/Documents/Save Vault/ organisé en bases de connaissances (sous-dossiers)
Un serveur MCP intégré expose list_knowledge_bases, list_files, read_file, et search à Claude
Le toggle « Connect to Claude » dans la menu bar câble le serveur MCP dans les configs Claude Desktop et Claude Code, sans édition JSON

Le résultat est le pattern Karpathy avec les aspérités polies. Sauvegarder une page → elle arrive dans votre vault → Claude peut répondre à des questions à son sujet. Pas de base de données vectorielle, pas de chunking, pas d’embeddings.

Ce que ça ressemble en pratique

Imaginez que vous faites des recherches sur un concurrent.

Jour 1. Vous sauvegardez leur page de tarification, trois articles de blog, et un thread Hacker News sur leur seed round. Cinq fichiers dans votre KB Competitors.

Jour 5. Vous demandez à Claude : « Quels changements de prix cette entreprise a-t-elle faits au cours de l’année passée, et comment les clients ont-ils réagi ? » Claude cherche dans votre KB Competitors, lit les fichiers pertinents, cite la page de tarification, fait remonter le sentiment du thread HN, et répond — tout sourcé.

Jour 30. Vous avez 40 fichiers entre Competitors, Customers, et AI Research. Vous demandez à Claude de compiler chaque KB en un wiki. Il écrit des pages de concepts, les lie, signale les contradictions. Vous avez maintenant trois wikis vivants que vous pouvez interroger comme des moteurs de recherche, mais mieux — parce qu’ils ne contiennent que ce que vous avez curatés.

Jour 90. Vos wikis sont plus grands que n’importe quel rapport d’analyste que vous achèteriez, plus récents que n’importe quel deck de consultant, et entièrement les vôtres. Chaque affirmation est sourcée à un fichier que vous avez sauvegardé.

C’est à quoi ressemble vraiment une base de connaissances personnelle une fois que la friction est partie. RAG était censé livrer ça et ne l’a pas fait. Le pattern Karpathy le fait — une fois que les pièces d’ingestion et MCP sont câblées pour vous.

Essayez-le

Installez l’extension Chrome Save
Installez Save Vault depuis savemarkdown.co
Basculez Connect to Claude dans la menu bar
Sauvegardez 10 choses que vous vouliez lire
Ouvrez Claude et posez une question qui les relie

C’est le workflow post-RAG. Il remplace déjà les bases de données vectorielles pour la connaissance personnelle. Il ne reste plus qu’à commencer à construire la vôtre.

Save Vault est gratuit. L’extension Save est gratuite pour 3 sauvegardes par mois, 3,99 $/mois illimité. savemarkdown.co.