Cette ligne dans le Wiki Gist de Karpathy que 99% des développeurs ont ratée — Et pourquoi c'est tout l'enjeu

On a tous compris l'intérêt d'un second cerveau depuis longtemps. Condenser ses cours, ses livres, ses PDFs, ses notes dans un endroit où on peut effectivement les retrouver. Le concept traîne depuis dix ans, il est digéré, plein de gens ont essayé. Le problème n'a jamais été l'idée. Le problème, c'est la maintenance. Tu nourris ton système pendant trois mois, tu te retrouves avec cent cinquante fichiers, tu t'y perds, tu passes plus de temps à réorganiser qu'à ajouter. Six mois plus tard, le cerveau moisit dans un coin de ton disque et tu n'y touches plus jamais.

Karpathy a posté un gist il y a deux semaines qui résout exactement ça. Il ajoute une couche d'auto-organisation par-dessus : le système classe ses propres pages, fusionne les redondances, maintient sa propre cohérence. Tout le monde s'est mis à le construire cette semaine. Trois dossiers, un CLAUDE.md, Obsidian par-dessus. Des tutos partout.

Sauf qu'un truc a échappé à 99% des builders. Et c'est dommage, parce que c'est tout l'intérêt. Sans ça, tu as un dossier qui se range tout seul. Avec ça, tu as un cerveau qui apprend de chaque question que tu lui poses, lit ce que tes outils lui écrivent, et finit par construire les outils dont il a besoin.

TLDR : L'architecture, c'est la moitié visible. Une phrase enterrée dans le gist active une boucle de rétroaction qui fait que la base devient plus dense à chaque utilisation. Puis il y a un troisième canal que personne n'a formalisé : ton infrastructure qui alimente la base directement, et la base qui fait remonter quels nouveaux outils construire, ou même qui les construit elle-même. J'ai activé les deux sur mon repo la semaine dernière. Voici ce qui a vraiment changé.

La Base de Connaissances Que J'Avais Déjà (Et Que Je N'Exploitais Jamais À Fond)

Je ne suis pas parti de zéro il y a six mois. Comme la plupart des devs qui font ça depuis un moment, j'avais déjà des repos éparpillés sur mon disque où j'avais organisé connaissances, compétences, processus, outils, docs. Un dossier par domaine. Fichiers markdown soigneusement structurés. Notes SEO ici, patterns de code review là, snippets que je réutilisais sans arrêt, décisions d'architecture que je ne voulais pas oublier. Recettes Docker compose que j'avais fini par réécrire au moins trois fois parce que je ne retrouvais jamais la version précédente. Diagrammes d'infra. Checklists de déploiement. Post-mortems d'incidents que j'avais écrits pour moi et jamais relus. J'utilisais ces repos tous les jours, je les chargeais dans Claude Code comme contexte quand j'en avais besoin, je posais des questions dessus, je copiais-collais des règles dans de nouveaux projets.

Ça marchait. C'était utile. Et si tu lis ça, il y a de bonnes chances que tu aies la même chose quelque part. Le repo de trucs que tu as ingérés, nettoyés, committés. Celui qui te fait du bien le dimanche soir après avoir ajouté un nouveau fichier.

Le grand changement qu'a apporté Claude, par rapport aux dix années précédentes à faire ça, c'est que j'ai arrêté de me demander "où j'ai foutu ce truc déjà." Pendant une décennie, le goulot d'étranglement de toute base de connaissances personnelle était le même : tu avais l'info quelque part, tu te souvenais vaguement l'avoir notée, mais la trouver voulait dire grep, Spotlight, ouvrir trois dossiers, relire la moitié d'un fichier pour vérifier si c'était le bon. Maintenant je demande juste à Claude. Le repo est en contexte, la question obtient une réponse, terminé. Ça seul, c'était un énorme déblocage. Ça rendait le repo vraiment utilisable pour la première fois.

Mais je le sous-exploitais encore. Méchamment. Mon repo était une bibliothèque très bien organisée que je devais parcourir moi-même à chaque fois que je voulais tirer un livre de l'étagère (sauf que maintenant Claude la parcourait pour moi au lieu de moi). Mieux, plus rapide, mais toujours à sens unique. Je demandais, il répondait, la conversation se terminait. Le repo n'apprenait rien de tout ça. Le lendemain je posais une question liée, Claude parcourait la même étagère encore une fois, me donnait une réponse légèrement différente, et cette deuxième réponse s'évaporait aussi.

Je pense que c'est pour ça que le gist de Karpathy a autant résonné quand il l'a lâché. Ce n'était pas l'architecture. Plein d'entre nous avaient déjà quelque chose de similaire. Le gist donnait un nom à un sentiment vague avec lequel la plupart d'entre nous traînions depuis des mois : ce truc que j'ai construit est utile, mais il ne fait clairement pas ce qu'il pourrait faire. La pièce manquante était la couche d'auto-organisation. Un second cerveau qui classe ses propres pages, fusionne ses propres redondances, maintient sa propre cohérence pendant que tu dors. C'est ça que Karpathy nous a mis sous le nez.

Et c'est ça que tout le monde s'est mis à construire cette semaine.

Karpathy A Posté L'Architecture. Tout Le Monde A Copié La Mauvaise Moitié.

Le gist s'appelle llm-wiki. Deux dossiers qui comptent. raw/ pour le matériau source, filtré et structuré mais complet. Un cours SEO complet distillé en 900 lignes. Un livre de code condensé en 600. Un playbook ops réduit de trois confs à 700 lignes de ce qui s'applique vraiment à ta stack. Personne ne lit ça en prod. C'est l'archive, l'endroit où tu retournes quand le wiki dit quelque chose qui sonne faux et que tu veux vérifier la source.

wiki/ c'est la version opérationnelle. Un fichier par domaine. Fusionne tous les raw de ce domaine en règles actionnables. 150 à 200 lignes max. C'est ce que les agents chargent avant de produire quoi que ce soit. Une fraction de la taille du raw, et ça se maintient tout seul. Ajoute un nouveau cours sur le même domaine, le wiki absorbe les nouvelles règles sans grossir. Les contradictions se résolvent, les patterns obsolètes disparaissent.

Par-dessus ça, un CLAUDE.md à la racine qui dit au modèle comment naviguer le tout, et Obsidian comme frontend pour que tu puisses le parcourir comme un humain normal.

L'architecture est propre. C'est aussi la partie évidente. Bien sûr qu'on sépare raw de synthétisé. Bien sûr qu'on donne des règles de navigation au modèle. Bien sûr qu'Obsidian est un bon viewer.

Puis les tutos ont débarqué. Chaque YouTubeur tech avec sa ring light a reposté des variations du même diagramme cette semaine. Trois dossiers. CLAUDE.md. Obsidian. Construis-le comme Karpathy. Poste une screenshot. Passe à autre chose.

J'ai fait partie de cette vague pendant deux jours. Reconstruit la structure par-dessus mon repo existant. Ingéré plus de sources. Posé des questions. Le setup était mieux que ce que j'avais, plus rapide, plus dense. Mais la base restait là, ne grandissant que quand je l'alimentais manuellement avec de nouveaux trucs. La couche d'auto-organisation faisait son boulot sur ce que je mettais dedans. Elle ne faisait rien avec ce que je faisais avec la base après.

C'est là que je suis retourné au gist et que je l'ai lu plus lentement. Pas la section architecture. La section query. La partie qui dit ce qui se passe après que le modèle répond.

La Phrase Qui Transforme Une Archive Statique En Base Vivante

La phrase, du propre post de Karpathy sur le workflow :

"Often, I end up filing the outputs back into the wiki to enhance it for further queries. So my own explorations and queries always add up in the knowledge base."

Lis-la deux fois. Elle décrit un comportement, pas une architecture.

Ce qu'elle dit, clairement : quand tu poses une question et que le modèle te donne une réponse utile, cette réponse retourne dans le wiki comme nouvelle page. La requête suivante, sur le même sujet ou adjacent, part d'une base qui contient déjà la réponse précédente. La base grandit de ton usage, pas seulement de ton ingestion.

Sans cette boucle, ton repo est un RAG avec des dossiers plus jolis. Tu ingères, tu requêtes, la réponse clignote sur ton écran et meurt dans l'historique de chat. Demain tu poses une question similaire, le modèle récupère des mêmes pages sources, synthétise la même réponse from scratch. Tu paies pour la synthèse à chaque fois (ma forme préférée de gaspillage récurrent, franchement).

Avec la boucle, la base a un état. Le job du modèle passe de "synthétiser depuis les sources raw" à "trouver la page où c'est déjà répondu, l'affiner si besoin." Plus rapide, moins cher, plus dense avec le temps.

Un paragraphe dans le gist. Toute la raison de construire ça.

Ce Qu'Un Container Mort A Appris À Ma Base De Connaissances

Mon repo ne contient pas que des cours et des livres. Il contient aussi la documentation vivante de mes propres services : configs, notes de déploiement, incidents passés, décisions d'architecture que j'ai prises à 2h du mat et notées avant d'oublier pourquoi. Même pattern que le reste, raw/ avec l'historique complet, wiki/ avec les règles opérationnelles. C'est là que les choses ont commencé à devenir intéressantes.

Ma sync de catalogue distributeur s'est arrêtée. Le container était up, le process était vivant, mais il n'avait pas tiré de nouveau feed en 34 heures. Je l'ai remarqué parce que le nombre de produits côté partenaire a dérivé de ce qui était sur ma boutique. Les clients ont commencé à commander des trucs qui n'étaient plus en stock upstream.

J'ai ouvert Claude Code et demandé : "quel est l'état de la sync distributeur, quand a-t-elle tourné avec succès pour la dernière fois, et quelle est la cause la plus probable du silence ?" Le modèle a parcouru le wiki, tiré la page de service pertinente, vérifié les entrées de log récentes que j'avais ingérées, et répondu : probablement une fuite mémoire dans le parser, le container consomme de la RAM mais ne crash pas parce que le seuil de l'OOM killer est trop haut. Recommandé un restart et un cap mémoire.

Réponse Claude Code classique. Utile. Spécifique. Aurait crevé dans l'historique de chat.

Sauf que la boucle était activée. La réponse a été classée dans le wiki comme nouvelle page sous services/distributor-sync/incidents/2026-03-29-silent-failure.md. La page avait le symptôme, le diagnostic, la résolution, et un flag notant que ce service avait maintenant échoué silencieusement une fois. Coût total : une requête, une page classée.

Une semaine plus tard, j'ai posé une question sans rapport sur le webhook de l'API partenaire. Le modèle a répondu, puis a ajouté la version polie de "au fait, tu devrais regarder ça" : "note que ta sync distributeur a eu un échec silencieux il y a 6 jours, tu n'as actuellement aucun monitoring sur son heartbeat, tu devrais en ajouter un avant que ça se reproduise." Il a fait remonter ça tout seul parce que le wiki avait la page d'incident, et que le modèle l'avait lue en cherchant du contexte sur les services adjacents.

Une semaine plus tôt, cette info aurait disparu. La session de chat où je l'avais diagnostiquée aurait été fermée. La prochaine fois que la sync serait morte silencieusement, j'aurais redécouvert la même cause racine from scratch.

Le wiki n'avait pas juste retenu. Il avait connecté.

Le Troisième Canal : Quand Tes Outils Alimentent La Base, Et Que La Base Construit Ses Propres Outils

Voici le truc qui m'a embêté avec l'incident ci-dessus. J'ai appris que le container avait échoué silencieusement par accident, parce que les clients ont commencé à se plaindre. Claude n'a classé la page qu'après que j'aie demandé. Si je n'avais pas demandé, l'incident n'aurait jamais existé dans la base.

Et si le container lui-même classait la page ?

La boucle de Karpathy est pilotée par l'humain. Tu demandes, le modèle répond, la réponse est classée. Deux canaux alimentent la base : les documents que tu ingères manuellement, et les requêtes que tu lances. Il y a un troisième canal. Il n'est pas dans le gist.

Ton infrastructure produit déjà du signal en continu. Les cron jobs réussissent ou échouent. Les containers redémarrent. Les services timeout. Les callbacks webhook retournent des codes non-200. La plupart de ce signal va dans des logs que personne ne lit, ou dans des systèmes d'alerting qui tirent une fois et oublient. Rien n'atterrit quelque part où le modèle peut l'utiliser.

Ce que j'ai construit par-dessus le pattern de Karpathy, c'est une couche fine qui laisse l'infra elle-même classer des pages. Un CLI que n'importe quel service peut appeler pour ajouter une observation directement dans la base. La sync catalogue écrit une page quand elle réussit, avec le nombre de lignes. Le handler webhook écrit une page quand il voit un payload malformé. Un cron écrit une page quand il skip parce que le run précédent tournait encore. Pages courtes. Timestampées. Elles atterrissent dans un dossier signals/ que le modèle connaît.

La raison pour laquelle ça marche, c'est la même raison pour laquelle les CLIs font de meilleurs canaux de signal que les wrappers MCP pour toute tâche d'agent : un curl one-liner depuis un script Bash écrit dans le wiki, pas de négociation de protocole, pas de danse de schéma. Le container n'a pas besoin de savoir ce qu'est un LLM. Il ajoute juste un fichier markdown à un dossier.

Et puis le truc de second ordre a commencé à arriver.

Une fois assez de signal accumulé, le modèle a commencé à lire le dossier signals/ pendant les requêtes et à pointer les trous. Pas "ton container a échoué" (cette partie était attendue). Des trucs comme : "tu as trois services qui écrivent des pages de succès mais pas de pages d'échec pour le webhook handler, ce qui veut dire que je ne peux pas dire s'il marche ou s'il est juste silencieux. Tu devrais ajouter un émetteur d'échec dans ce handler." Ou : "ton cron job pour la sync distributeur écrit quand il tourne, mais rien n'écrit quand il skip un cycle. Tu as besoin d'un émetteur de skip."

Puis il a arrêté de demander. Il a commencé à construire.

Un exemple concret de la semaine dernière, et même pas un exemple d'infra. Je me demandais s'il fallait acheter 32 ou 48 GB de RAM sur mon prochain MacBook. Question classique, réponse classique du mec à l'Apple Store : "tu seras très bien avec 24, fais-moi confiance." Je ne lui faisais pas confiance. J'ai demandé à Claude Code à la place, avec mon repo en contexte : "comment je sais ce dont j'ai vraiment besoin ?" Le modèle ne m'a pas donné une fourchette. Il a proposé de construire un CLI de monitoring (un script pour sampler les métriques RAM toutes les 5 minutes dans un CSV, un deuxième script pour calculer le résumé et recommander une taille basée sur le pic observé plus une marge de 30%). Écrit les deux scripts. Les a lancés. Trois jours de données plus tard, le verdict était dans mon wiki : RAM utilisée bloquée à 22-23 GB sur une machine 24 GB, 77 MB libres au point bas, compressor qui turbine à 4,5 GB. Recommandation : 32 minimum, 48 si je voulais la paix.

Pas une estimation. Pas du marketing. Des vrais chiffres de mon vrai usage, collectés par des outils que la base a construits pour elle-même parce qu'elle savait qu'elle n'avait pas encore la réponse.

La base n'apprenait plus seulement. Elle comblait ses propres angles morts.

Tu ingères. Tu requêtes. Tes outils écrivent. Et puis la base construit le prochain outil toute seule.

Trois Pièges Avant D'Activer La Boucle

Trois pièges dans lesquels je suis tombé les deux premières semaines. Prends ces décisions avant d'appuyer sur l'interrupteur, ou ta base se transforme en poubelle rapidement.

Ce qui est classé en retour. J'ai commencé par classer chaque réponse. Après quatre jours la base avait quarante-sept variations de "oui cette commande docker est correcte" et je ne trouvais plus rien d'utile. La règle maintenant : classer seulement si la réponse révèle quelque chose que la base ne savait pas déjà, documente un incident, ou rend une décision explicite. L'échafaudage conversationnel meurt dans l'historique de chat où il a sa place.

Qui décide de la qualité. Les modèles qui s'auto-jugent sont trop généreux avec eux-mêmes, j'ai découvert ça vite quand Claude a classé une page déclarant un endpoint d'API déprécié comme "best practice actuelle." La review humaine complète ne scale pas au-delà de cent pages. J'ai atterri sur un terrain d'entente : le modèle classe dans pending/, un cron quotidien promeut tout ce que je n'ai pas supprimé dans les 24 heures. Le silence veut dire approbation. La flemme est la porte.

Comment tu empêches les erreurs de se composer. Celle-là je l'ai apprise des commentaires du gist, pas de Karpathy. Si le modèle classe une mauvaise réponse, cette mauvaise réponse devient un "fait" dans la base. La requête suivante la lit, la traite comme vérité de base, produit une deuxième mauvaise réponse qui dépend de la première. Trois semaines plus tard, ta base te gaslighte. Le fix est le même genre de contrat que j'ai décrit dans mon framework de contrats de prompts : chaque page classée déclare ses sources, un niveau de confiance, une date de re-validation. Pas de sources, expiration rapide. Haute confiance avec sources vérifiées, longue vie. La base s'auto-élague.

Cloue ces trois trucs. Le reste tourne tout seul.

30 Jours Plus Tard : Deux Bases, Deux Systèmes Différents

Dans 30 jours, plein de devs auront construit exactement le même setup. Trois dossiers, un CLAUDE.md, Obsidian par-dessus. Identiques jusqu'aux noms de dossiers.

La moitié d'entre eux aura une archive morte qu'il faut nourrir à la main pour qu'elle reste pertinente (qui sera franchement oubliée dans le mois, soyons réalistes). L'autre moitié aura une base qui apprend de chaque question, lit ce que l'infra lui écrit, et construit les outils dont elle a besoin quand elle remarque un trou. Même architecture. Une boucle et un canal de différence.

C'est ça à quoi ressemble une vraie base de connaissances personnelle. Pas un dossier. Un système qui devient plus dense à chaque utilisation, et plus affûté à chaque fois qu'il tombe sur quelque chose qu'il ne connaît pas.

Karpathy a écrit la ligne. Personne ne l'a lue.

Sources

• Gist llm-wiki d'Andrej Karpathy sur GitHub

(*) L'image de couverture a été générée par une IA qui, pour être honnête, classe ses propres pages depuis avant qu'on en fasse un hobby.