Toutes les analyses
Playbook

Le second cerveau IA qui s'entretient tout seul : la méthode Karpathy.

·14 min de lecture

Tout le monde a accès aux mêmes LLMs. Le modèle n'est plus un edge ; le seul qui reste, c'est le contexte qu'on lui donne : lectures, décisions, clients, veille de plusieurs années. Un modèle « custom-trained » sur un cerveau singulier, sans une ligne de fine-tuning. Les notes éparpillées dans Notion, Google Docs ou Apple Notes ne servent à rien : l'IA ne sait pas les lire.

La méthode qui change ça a été formalisée par Andrej Karpathy au printemps 2026 : laisser un agent LLM construire et entretenir un wiki personnel en plain-text markdown. Trois couches, trois opérations, zéro infrastructure.

Le système qui manquait pour transformer un patrimoine de données souveraines en AI brain opérationnel, et faire de cet actif le seul avantage compétitif que l'arrivée de l'IA n'aplatit pas.

1. Pourquoi tous les seconds cerveaux meurent (et la discipline n'a rien à voir)

Combien d'applications de prise de notes finissent à l'abandon en quelques mois ?

Notion installé un week-end, abandonné trois mois plus tard parce qu'on n'y retrouve plus rien. Apple Notes devenu cimetière de bouts de phrases sans contexte. Une trentaine de Google Docs intitulés « brouillon », « notes », « sans titre 47 », éparpillés dans le Drive, jamais ré-ouverts. Un dossier À lire sur le bureau qui pèse douze gigas.

Le réflexe est toujours le même : je manque de discipline.

C'est faux. Et c'est important de l'établir, parce que tant que cette croyance tient, on continue à payer la prochaine app en espérant qu'elle sauve la mise. Aucune ne le fera. Le problème n'est pas dans l'outil, et il n'est pas dans la personne qui l'utilise.

Le vrai blocage, c'est le bookkeeping : la maintenance silencieuse d'un système de connaissance. Mettre à jour les liens entre les pages, garder les résumés à jour, noter quand une nouvelle source contredit une ancienne croyance, ranger la nouvelle note au bon endroit, recroiser les concepts. Personne ne décroche d'un système de notes parce que lire ou réfléchir est trop dur. On décroche parce que tenir la base à jour est un job invisible qui grandit plus vite que la valeur qu'on en retire. Andrej Karpathy l'a formulé proprement il y a quelques semaines :

« Humans abandon wikis because the maintenance burden grows faster than the value. »

Traduction : les humains abandonnent leurs wikis parce que le coût d'entretien grandit plus vite que la valeur qu'ils en tirent.

Le problème n'est pas un défaut de lecture ni de méthode. C'est la maintenance qui finit par avoir raison de tous les seconds cerveaux successifs.

En 2026, ce frein vient de tomber. Les LLMs ne s'ennuient pas. Ils peuvent toucher quinze fichiers d'un coup sans oublier un cross-référencement, relire toute une base à chaque ingestion pour repérer ce qui change, ce qui se contredit, ce qui se renforce. Ils n'ont pas de mauvaise humeur le dimanche soir. Le coût d'entretien tombe quasiment à zéro.

2. Ce que Karpathy a révélé en avril 2026

Petite mise en contexte sur la source, parce qu'elle compte. Andrej Karpathy est l'ancien directeur de l'IA chez Tesla, membre fondateur d'OpenAI, et l'une des voix les plus suivies sur l'usage pratique des LLMs. Ses explications ont une particularité : elles cristallisent des patterns plusieurs mois avant qu'ils soient produits ou packagés par les outils du marché. Quand il décrit ce qu'il fait avec ses propres outils, ça vaut la peine d'écouter.

Le 2 avril 2026, il poste sur X. Ce qui suit n'est pas un papier de recherche, c'est une note tactique qui mérite trois lectures pour bien capter ce qu'il décrit :

« Something I'm finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge (stored as markdown and images). »

Trois jours plus tard, il publie un gist détaillé qui formalise le pattern. Le chiffre qu'il pose discrètement au milieu du texte est celui qui change la conversation : il maintient un de ces wikis à environ 100 articles et 400 000 mots, sans RAG, sans embedding pipeline, sans infrastructure custom. Juste des fichiers markdown dans un dossier, et un agent LLM qui les entretient.

Pour quiconque a déjà touché à du retrieval-augmented generation en entreprise, cette ligne est une gifle. L'industrie bricole des stacks vectoriels, tune des chunk sizes, benchmarke des rerankers. Et un type respecté de la communauté ML dit en passant : à mon échelle, rien de tout ça n'est nécessaire, un wiki en markdown suffit.

La métaphore qu'il utilise est celle qui rend le pattern intelligible d'un coup :

« Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase. »

Obsidian, c'est l'IDE. Le LLM, c'est le programmeur. Le wiki, c'est le code source.

L'humain lit, navigue, pose des questions, valide. Le LLM écrit, refactore, range, lie. Le wiki (l'ensemble des connaissances) devient un objet maintenu par l'utilisateur, mais édité par la machine. C'est exactement la division du travail qui manquait jusqu'ici pour ne pas craquer au bout de trois mois.

Et tout est en markdown plain text. C'est-à-dire : lisible par n'importe quelle IA, n'importe quel outil, dans n'importe quel système, pour les trente prochaines années au moins. Pas de format propriétaire. Pas de vendor lock-in. Pas de couche d'abstraction qui trahira l'utilisateur quand l'app d'aujourd'hui changera de propriétaire ou de pricing.

C'est cette propriété qui sépare un vrai second cerveau de Notion, Apple Notes, Google Docs. Ce sont des silos visuels conçus pour les yeux humains. Ils ne sont pas conçus pour qu'une IA les lise, les relie, les maintienne. En 2026, c'est une erreur d'architecture fatale.

3. L'architecture, sans bullshit

Voici le pattern. Il tient en trois couches et trois opérations.

Couche 1 : Raw. Le dossier des sources brutes : articles capturés via Obsidian Web Clipper, transcripts YouTube/podcast, screenshots, notes vocales, papers. Tout ce qui rentre passe par là. Immuable. L'IA lit ce dossier, elle n'y écrit jamais. C'est l'équivalent des archives.

Couche 2 : Wiki. Les pages que l'IA génère et maintient à partir du raw : pages de concepts, pages d'entités (les personnes, les boîtes, les outils dont il est question), pages d'idées atomiques (les claims tenus ou explorés). Plus deux fichiers spéciaux : un index.md qui catalogue le wiki, et un log.md qui journalise chronologiquement chaque ingestion, chaque question, chaque passe de maintenance. Cette couche appartient entièrement à l'IA. On y navigue, on y lit, mais on n'éditera quasi jamais une page à la main.

Couche 3 : Schema. Un seul fichier. Il s'appelle CLAUDE.md (ou AGENTS.md, selon l'agent utilisé). Il décrit comment l'IA doit ranger : la nomenclature des fichiers, les conventions de wikilinks, les YAML front-matter à inclure, les règles de citation, ce qu'elle n'a pas le droit de faire (par exemple, ne jamais ré-éditer un fichier raw). C'est ce qui transforme un chatbot générique en bibliothécaire discipliné. Sans ce fichier, un LLM improvise à chaque session ; avec, on a un système.

Et trois opérations qui font tourner tout ça :

  • /ingest : une source est déposée dans raw/. L'agent la lit, résume en deux phrases ce qu'il en tire, et propose les pages à créer ou à mettre à jour. L'humain valide. L'agent écrit cinq à quinze fichiers d'un coup, en croisant avec tout l'existant. Une seule source touche dix pages du wiki. C'est là que se passe la magie du compounding.
  • /query : une question est posée. L'agent lit l'index, descend sur trois à cinq pages pertinentes, répond avec des citations wikilink. Pas de hallucination généraliste : la réponse vient de la base de l'utilisateur.
  • /lint : audit santé périodique. L'agent sort une liste de pages orphelines (sans lien entrant), de wikilinks cassés, de contradictions entre pages, de pages trop vieilles dans des domaines actifs. L'humain pilote les fixes, l'agent exécute.

Setup en une commande. Coller littéralement ceci dans Claude Code, dans un dossier vide :

Help me set up a LLM wiki that fits my needs and workflows
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

L'agent va lire le gist Karpathy, poser quelques questions sur le cas concret (domaines à suivre, sources ingérées, fréquence, langue), et générer un premier CLAUDE.md + la structure de dossiers raw/, concepts/, entities/, ideas/, index.md, log.md. Dix minutes plus tard, le second cerveau est fonctionnel. Une première source dans raw/, un /ingest, et la mécanique est en route.

Ce qu'il faut : Obsidian (gratuit), Claude Code, un dossier git pour versionner, et le fichier de schéma. Zéro infra. Pas de base vectorielle, pas de chunking, pas de reranker, pas de stack à maintenir. Toute la complexité passe dans un fichier markdown lisible par un humain.

Dans notre cabinet d'implémentation IA, nous installons ce pattern chez des PMEs francophones avant même d'évoquer un RAG ou des embeddings. Dans 80 % des cas, c'est tout ce qu'il leur faut pour résoudre leur "problème de documentation interne". Pour qu'on regarde un cas concret, écrivez-nous.

4. La bascule quotidienne : consommer devient entraîner

Voilà l'effet de bord qui change tout, et qui ne se révèle qu'à l'usage, après les premières semaines d'ingestion régulière.

Avant. Une vidéo YouTube de 45 minutes sur un sujet intéressant. Deux ou trois choses apprises. Trois jours plus tard, 80 % oublié. Trois semaines plus tard, peut-être une phrase floue qui reste. Le temps de consommation s'évapore. Consommation passive.

Aujourd'hui, le geste tient en quatre temps :

  1. Une consommation : vidéo, podcast, article long-form, peu importe.
  2. Capture via Obsidian Web Clipper, en un clic. Cinq secondes.
  3. Dépôt dans raw/. Sans réfléchir au rangement. Le nom du fichier suit la convention du schéma, c'est tout.
  4. Lancement de /ingest. L'agent prend le relais : il lit, identifie les concepts qui s'enrichissent (ou ceux qu'il faut créer), met à jour les pages d'entités (personnes citées, outils mentionnés), pose une ou deux nouvelles ideas/ si la source défend un claim singulier, et montre les modifications pour validation.

Ce qui change, ce n'est pas le temps passé : c'est ce qui en reste. Chaque vidéo devient un bloc de contexte permanent dans l'IA. Trois mois plus tard, à une question complexe, l'IA ne répond plus avec sa culture générale (la même que celle du concurrent qui utilise la même API). Elle répond avec la culture de l'utilisateur : ses lectures, ses décisions passées, ses clients, son angle, ses opinions remises à jour à chaque ingestion.

L'effet vertueux est immédiat. Plus on consomme, plus l'IA devient utile. La veille arrête d'être une to-do list qui culpabilise, elle devient un actif qui compound. On filtre mieux ce qu'on laisse entrer, aussi, parce qu'on sait que ce qui rentre va rester, vraiment.

Et il y a un compounding inverse, plus subtil, qui ne se remarque qu'au bout d'un mois ou deux : l'IA recroise spontanément une vidéo ingérée aujourd'hui avec un article déposé trois mois plus tôt et complètement oublié depuis. Elle sort la connexion dans une réponse de query. La réaction est mécanique : « ah oui, je m'en souvenais plus ». Ces connexions-là, personne ne les ferait à la main.

La punchline tient en une ligne : avant, on consommait et on oubliait. Maintenant, on consomme et l'IA devient meilleure. Même geste, ROI complètement différent.

5. Pourquoi ça bat le RAG à l'échelle d'une PME

Maintenant le sujet B2B, parce que c'est là que la majorité des projets IA d'entreprise se plantent.

Quand une PME francophone arrive avec « on aimerait pouvoir interroger nos docs internes avec une IA », la réaction par défaut du marché aujourd'hui c'est : il vous faut un RAG. Vector database, embeddings, chunking, reranker, pipeline d'ingestion, mise à jour incrémentale. Un devis qui pique et un stack à maintenir derrière. Encore plus dès qu'il faut poser ça sur AWS avec un MLOps propre.

Sauf qu'à l'échelle réelle de la plupart des PMEs (quelques centaines de documents internes, quelques dizaines à quelques centaines de milliers de mots utiles), un wiki maintenu par IA bat un RAG sur trois dimensions :

  • Coût. Pas de stack vectoriel à payer, pas de tuning d'embeddings, pas de pipeline d'orchestration. Le coût marginal d'une ingestion, c'est quelques tokens de contexte.
  • Lisibilité. Quand un dirigeant veut comprendre pourquoi l'IA a répondu telle chose, il ouvre le wiki et lit les pages citées. Pas de boîte noire vectorielle. C'est traçable, débuggable, contestable.
  • Maintenance. L'agent qui ingère met à jour la base au passage. Pas de cron job qui ré-indexe, pas de drift entre l'index et la source. Le wiki est toujours à jour parce que c'est le passage obligé de toute nouvelle source.

Karpathy le rappelle : il fait tourner ça à 100 articles et 400 000 mots. C'est exactement l'échelle de la doc d'un service métier, d'une équipe produit, d'un département juridique dans une boîte moyenne. La plupart des projets que les clients décrivent comme « notre RAG interne » tombent largement en-dessous de ces seuils.

Ce que cette approche résout dans une entreprise n'est pas ce que les dirigeants formulent au départ. Le pitch standard du marché, « l'IA résume vos documents », loupe la vraie douleur. La vraie douleur, c'est que tous les systèmes de connaissance internes déjà tentés sont morts pour la même raison : personne ne tient la maintenance dans la durée.

C'est ce paramètre que la méthode inverse :

Le job de maintenance qui a tué tous les wikis internes déjà essayés passe à un agent qui ne s'épuise pas.

Une fois la friction de maintenance retirée, la base interne reste peuplée, à jour, interrogeable. Pas parce qu'on a "ajouté de l'IA" par-dessus, mais parce qu'on a retiré la cause qui faisait abandonner les équipes au bout de six mois.

Honnêteté sur les limites. Au-delà d'environ mille documents bien volumineux, l'index commence à dégrader et la lecture index + drill devient lente : Karpathy lui-même bascule vers des outils CLI de recherche à ce stade-là. Si le corpus est très hétérogène (PDFs scannés, tableaux denses, documents multimodaux), le préprocessing reste utile. S'il faut des permissions row-level multi-tenants, un dossier markdown plat ne suffit pas. Mais 80 % des cas B2B SMB francophones tombent avant ces seuils. Et les cas qui les dépassent peuvent commencer par un wiki en attendant, sans dette technique.

Pour une PME à qui on a vendu (ou s'apprête à vendre) un projet RAG conséquent, trente minutes avant de signer valent le coup. Souvent c'est un wiki maintenu par IA qui résout le vrai problème, pour une fraction du budget et avec un time-to-value de quelques jours au lieu de plusieurs semaines ou mois. Parlons-en.

6. Comment en construire un, concrètement

Ce qu'on peut y mettre :

  • De la documentation d'entreprise : info équipes, fiches clients, deals en cours, contrats, processus internes, systèmes et stacks techniques, comptes-rendus de réunions, debriefs commerciaux, retours d'incidents.
  • De la veille pro : articles, podcasts, papers, threads, vidéos sur un domaine donné. Le cas perso le plus immédiat.
  • Des projets en cours : pitchs, idées produit, R&D, tests utilisateurs, retours d'expérience.
  • De la vie perso : tout sujet sur lequel on prend des décisions répétées dans le temps.
  • Des projets ponctuels : une étude de marché, une due diligence, le suivi d'une formation, l'écriture d'un livre.

Ce qu'il faut, vraiment :

  • Obsidian (gratuit).
  • Claude Code.
  • Un dossier git pour versionner.
  • Un fichier CLAUDE.md ou AGENTS.md qui décrit le schéma.
  • Un dossier raw/.

C'est tout. La commande de setup, à recoller dans un dossier vide :

Help me set up a LLM wiki that fits my needs and workflows
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Conseil opérationnel, parce que c'est l'erreur que font 80 % des gens qui démarrent : ne pas chercher à tout ranger d'avance. Ne pas dessiner l'arbre des concepts sur un tableau blanc avant de commencer. Déposer cinq à dix sources dans raw/ : des choses déjà consommées récemment, pas une "to-read list" idéale. Lancer /ingest sur chacune. Laisser l'agent proposer une structure. Le schéma émerge des sources réelles, pas l'inverse. Le wiki est un objet organique qui se cristallise à mesure que le raw se nourrit. Pré-figurer toute l'architecture, c'est retomber dans le piège Notion : un week-end à ranger des dossiers vides, et l'abandon trois mois plus tard.

Le geste est petit. On dépose, on valide les modifications, on lit. On pose une question quand on en a besoin. Le reste se fait tout seul.

7. La techno manquait. Elle est là.

Aujourd'hui, il y a un agent LLM qui ne s'ennuie pas, qui édite quinze fichiers d'un coup sans oublier un cross-référencement, et qui coûte quelques centimes par session. La méthode tient dans un fichier. Le setup tient dans une commande. Le format tient dans du plain text relisible dans trente ans.

En 2026, un second cerveau ne sert à rien si l'IA ne peut pas le lire. Et inversement : l'IA reste générique tant qu'elle n'a pas accès à un contexte propriétaire. Le wiki est ce qui réconcilie les deux.

Pour les dirigeants qui veulent ce pattern adapté à la réalité de leur boîte (un vrai remplacement de tâche manuelle, pas un gadget IA de plus), un échange de 30 min suffit pour cadrer le cas. Écrivez-nous.

Pour le tuto pas-à-pas du setup perso (Obsidian + Claude Code + le premier CLAUDE.md + le premier ingest), écrivez-nous. On peut faire la première session ensemble.