Le wiki agentique de Karpathy : signal à tester avant d'industrialiser votre mémoire IA

Notes de terrain : 15 juin 2026

En veille mémoire IA, un fil revient cette semaine : avant d'acheter une plateforme « mémoire d'entreprise », est-ce qu'un wiki maintenu par agent réduit vraiment le lissage statistique, ou est-ce qu'on cristallise de nouvelles erreurs ? Le pattern popularisé par Karpathy et documenté par plusieurs retours terrain alimente ce signal.

Pour une squad produit de cinq à huit personnes (Notion + repo docs), on cible un pilote de trente jours : curieux sur le signal, discipliné sur la mesure, pas de scale avant preuve.

Ce qu'on a lu : compilation, pas retrieval à chaque fois

Andrej Karpathy a popularisé un pattern où l'agent ne se contente pas d'indexer des PDF pour un RAG. Il compile : à l'ingestion, il lit une source, met à jour des pages markdown, croise les entités, signale les contradictions. L'analogie retenue par Gamgee : traiter la gestion de connaissance comme une compilation de code, pas comme un interpréteur relancé à chaque question.

L'architecture décrite tient en trois couches :

1. Raw : sources immuables (transcripts, exports, PDF).
2. Wiki : pages markdown que l'agent crée et met à jour.
3. Schema : fichier de règles (AGENTS.md, conventions, workflows).

Trois opérations tournent en boucle : Ingest, Query, Lint (santé du wiki, liens cassés, claims obsolètes). L'Agentic AI Foundation résume bien la promesse : l'intelligence se déplace vers le moment de l'écriture, pas vers chaque requête runtime.

Promesse documentée (pas encore exécutée en pilote chez nous) : à petite échelle, Atlan cite jusqu'à 95 % de tokens en moins vs chargement naïf de tous les documents. Pour une squad qui paie à l'usage, c'est tentant.

Limite documentée : le même comparatif place le mur vers 50 000–100 000 tokens d'index, soit environ 100–200 articles. Au-delà, il faut une couche retrieval. Le gist LLM Wiki v2 parle d'un index plat qui casse vers 200–500 documents sans BM25/vecteurs. Pour une PME, ce n'est pas théorique : un wiki Notion + repo Git peut atteindre ce seuil plus vite qu'on ne le croit.

Tension : le RAG lisse à la requête, le wiki cristallise à l'ingestion

Le discours marché oppose souvent RAG (mauvais) et wiki agentique (bon). Les sources consultées nuancent ce tableau.

• RAG : stateless. Chaque question relit des chunks, moyenne des passages proches, risque de documentation drift si les sources ne suivent pas le produit.
• Wiki agentique : les erreurs d'ingestion restent. Une hallucination de lien ou une synthèse trop lisse peut se propager aux pages dépendantes. Le gist v2 insiste : l'auto-ingest sans gate humain peut corrompre la base « silencieusement » quand le modèle invente des dépendances.

On retient donc un trade-off net :

On n'a pas de réponse tranchée pour une squad québécoise. On a une hypothèse à tester : sur un périmètre restreint (un module produit, un runbook ops), le wiki agentique réduit-il les réponses « trop lisses » par rapport à un RAG sur le même corpus ?

Signal terrain : le wiki comme discipline, pas seulement comme archive

Un retour DEV Community nous a arrêtés. Le wiki n'a pas seulement stocké des faits : injecté via CLAUDE.md, il est devenu un correctif de comportement (« lire le fichier avant d'éditer », règles de session). Le problème visé n'était pas la mémoire longue, mais la discipline de l'agent.

Pour une squad de 5–8 personnes, c'est peut-être le premier gain réaliste : pas une « mémoire d'entreprise » complète, mais un socle de règles et d'échecs passés versionné dans Git, revu en PR humaine.

Protocole pilote 30 jours

On emprunte la structure des playbooks SMB documentés en veille, sans copier leurs métriques marketing.

Semaine 1 : Cadrage (20 % du trafic doc)

• Choisir un seul périmètre : ex. runbook déploiement ou module API interne.
• Baseline : 10 questions types que l'équipe pose déjà à Notion/Copilot.
• Métrique unique : taux de réponses avec source citée correcte (audit humain, pas auto-éval LLM).

Inspiré de PathOpt : démarrer petit, documenter le temps passé à corriger les sorties.

Semaine 2 : Wiki minimal + gate écriture

• Dossier wiki/ + index.md + AGENTS.md dans le repo existant.
• Gate humain obligatoire avant tout commit agent sur le wiki (leçon gist v2).
• Pas d'auto-ingest sur tout Notion : seulement les pages taguées pilot-wiki.

Semaine 3 : Comparaison RAG vs wiki

• Même 10 questions sur (A) RAG Notion/vectoriel existant si présent, (B) wiki agentique.
• Noter : contradictions, omissions d'échecs, « réponses trop propres ».

Semaine 4 : Décision scale / pause / pivot

• Critères empruntés à Promarkia : une métrique north star, pas dix.
• Cibles indicatives (à calibrer) : révision humaine < 30 % des pages générées ; 0 contradiction non résolue dans le lint.

Si le pilote échoue sur la qualité, on n'a pas « raté l'IA ». On a peut-être évité d'acheter une plateforme mémoire prématurément.

Ce qu'on surveille (validité : juin 2026)

1. Références open source : dépôt kenhuangus/llm-wiki et évolutions du gist v2.
2. Documentation drift sur notre propre pilote : est-ce que le wiki suit le code après deux sprints ?
3. Discours vendor « RAG is dead » : Epsilla et similaires poussent des graphes sémantiques payants. On sépare le pattern utile du upsell.
4. Concurrence multi-agents : écritures simultanées sur markdown sans DB transactionnelle restent un angle mort pour squads > 1 agent actif.

Hypothèse contestable : pour une PME, le wiki agentique sert d'abord de couche discipline + mémoire courte, pas de remplacement d'un RAG sur tout l'historique Notion.

Ce qu'on n'a pas testé en production : un déploiement complet chez un client Inyulface. Cet article documente la lecture du signal et un protocole, pas un bilan terrain chiffré.