LLM Wiki : comprendre la nouvelle architecture de connaissance en IA

Une LLM Wiki compile vos sources dans une base de connaissances pérenne et interliée lors de l’ingestion, puis répond à partir de cette base plutôt que de réinterroger des extraits bruts à chaque fois. Ainsi, le savoir s’accumule à mesure que vous ajoutez des sources, au lieu d’être reconstruit à partir de zéro à chaque question.

Je vous explique d’où vient l’idée de la LLM Wiki, en quoi elle se compare au Retrieval-Augmented Generation (RAG), et si elle change vraiment la façon dont les systèmes d’IA gèrent la connaissance.

Aux origines du concept de LLM Wiki

L’idée de LLM Wiki a pris forme en 2026, présentée par Andrej Karpathy et reprise par quelques projets open source qui l’ont transformée en quelque chose d’opérationnel.

L’idée est simple. En 2026, les systèmes d’IA passent une grande partie de leur temps à relire les mêmes documents. Vous téléversez un PDF, le modèle récupère des extraits, répond à une question, puis passe à autre chose. La semaine suivante, vous ajoutez un autre PDF sur le même sujet et le modèle refait exactement la même chose. Rien ne persiste.

Le plus grand changement, c’est que la recherche et la compilation sont deux métiers différents.

Par exemple :

• Systèmes orientés recherche élarguent des fragments pertinents au moment de la requête et les transmettent au modèle comme contexte. Le modèle travaille avec ce que l’outil de recherche a ramené.
• Systèmes orientés compilation lisent chaque source une fois à l’ingestion, extraient l’essentiel et l’écrivent dans une base de connaissances structurée. Le modèle répond ensuite à partir de cette base.

Une LLM Wiki appartient à la seconde catégorie. Quand vous ajoutez une nouvelle source, le modèle la lit, met à jour les pages existantes, en crée de nouvelles si besoin et signale les contradictions avec ce qui est déjà consigné. La base de connaissances grandit à chaque source ajoutée, et le modèle dispose à chaque fois d’un meilleur socle pour répondre.

C’est la première rupture concrète avec le paradigme « recherche d’abord » qui domine depuis que RAG est devenu la norme. RAG traite chaque requête comme une recherche à neuf dans les documents bruts. Une LLM Wiki considère l’ingestion comme le moment où le travail s’effectue, et la requête comme une lecture à partir d’une base déjà mise en forme.

Qu’est-ce qu’une LLM Wiki ?

Une LLM Wiki est une base de connaissances persistante, tenue par l’IA, qui synthétise en continu l’information issue des documents sources en pages structurées et interconnectées.

Trois éléments la distinguent d’un simple dossier de fichiers ou d’un magasin vectoriel.

• Persistante : les pages sont créées une fois puis mises à jour à l’arrivée de nouvelles sources. Rien n’a à être rédérivé au moment de la question, car la synthèse est déjà écrite.
• Mise à jour continue : chaque source ingérée déclenche des éditions à travers tout le wiki : nouvelles pages pour de nouvelles entités, révisions des résumés existants, notes lorsque des données récentes contredisent d’anciennes affirmations.
• Double audience : les pages sont lisibles par des humains et suffisamment structurées pour que des agents d’IA raisonnent dessus. Markdown, liens croisés et mise en page cohérente remplissent ces deux fonctions.

Le mouvement clé, c’est que le wiki devient la couche de connaissance principale. Les documents originaux restent en stockage brut comme piste d’audit, mais personne ne les interroge directement. Les systèmes de chat, agents et assistants de recherche lisent le wiki, car c’est là que se trouve la version compilée et référencée du savoir.

L’architecture d’une LLM Wiki

L’architecture ressemble à un pipeline en trois étapes : les sources arrivent, le modèle les compile en pages de wiki, et les applications d’IA lisent ces pages. 

Architecture LLM Wiki

Voici le détail de chaque étape.

Documents sources

Tout contenu textuel peut être ingéré. Par exemple :

• Documentation et PDFs
• Notes personnelles et transcriptions de réunions
• Dépôts de code
• Contenu web capturé depuis des articles ou aspiré depuis des sites

Les sources brutes sont placées en stockage immuable. Une fois ingérées, le modèle les lit mais ne les modifie jamais, ce qui offre une piste d’audit claire reliant chaque affirmation du wiki à sa source.

Compilation des connaissances

Le wiki se crée à cette étape. Lorsqu’une nouvelle source arrive, le modèle exécute un ensemble d’opérations :

• Extraction des concepts : entités, thématiques, définitions et affirmations sont extraites du texte source.
• Mise à jour des pages existantes : si une entité ou un concept disposent déjà d’une page, le modèle la révise avec les nouvelles informations et signale les contradictions.
• Création de nouvelles pages : tout ce qui n’entre pas dans une page existante obtient la sienne.
• Liaison des sujets connexes : des références croisées sont ajoutées dans les deux sens pour que les pages restent reliées au fur et à mesure que le wiki grandit.

Une seule source ingérée peut « mettre à jour » 10 à 15 pages lors de ce passage. C’est l’objectif : le travail de connexion du nouveau matériau au savoir existant se fait une fois, à l’ingestion, et non à chaque requête comme avec RAG.

Applications d’IA

Le wiki est conçu pour être lu par différents types de consommateurs. Par exemple :

• Systèmes de chat qui répondent à partir du savoir compilé, plutôt que des documents bruts.
• Assistants de recherche qui suivent les références croisées pour se faire une idée d’un sujet.
• Agents logiciels qui utilisent le wiki comme mémoire durable sur des tâches de longue durée.
• Systèmes de connaissance d’entreprise qui exposent le wiki à des outils internes, à des tableaux de bord, ou à des serveurs MCP.

Le wiki est au centre. Les sources arrivent d’un côté, les applications le lisent de l’autre, et la couche de compilation maintient la cohérence des deux extrémités.

LLM Wiki vs RAG traditionnel

La différence principale entre un RAG traditionnel et une LLM Wiki tient au moment où le travail s’effectue.

RAG traditionnel

RAG récupère des extraits de documents au moment de la requête. Vous posez une question, une recherche par embeddings extrait les k meilleurs extraits d’un magasin vectoriel, et ces extraits sont ajoutés au contexte du modèle avec votre question. Le modèle génère une réponse à partir de ce contexte temporaire puis oublie tout une fois la réponse livrée.

Le contexte est jetable. 

Les extraits qui ont servi à répondre à votre dernière question disparaissent du contexte dès que le modèle termine sa réponse. Si vous posez demain une question liée, l’outil de recherche relance une requête, récupère à nouveau des extraits, et le modèle re-synthétise. Rien ne s’accumule entre les requêtes.

LLM Wiki

Une LLM Wiki compile l’information lors de l’ingestion. Quand vous ajoutez une source, le modèle la lit une fois, consigne l’essentiel dans des pages structurées, met à jour les références croisées et stocke le résultat en markdown durable. La phase de requête consiste alors à lire la base compilée, plutôt que à re-synthétiser à partir d’extraits bruts.

La connaissance est persistante, et elle évolue. 

Chaque nouvelle source déclenche des éditions dans tout le wiki : contradictions signalées, résumés anciens révisés, connexions entre sujets qui se densifient avec le temps.

Arbitrages

Aucune approche n’est universellement supérieure. Elles optimisent des objectifs différents.

Voici quelques points à garder en tête :

• Fraîcheur : avantage à RAG, qui lit directement les documents sources au moment de la requête. Si vous mettez à jour les documents sous-jacents, la prochaine requête verra le changement immédiatement. Une LLM Wiki doit ré-ingérer les sources pour mettre à jour ses pages : il y a donc un décalage entre la vérité brute et la connaissance compilée.
• Précision : une LLM Wiki l’emporte lorsque les questions exigent une synthèse multi-sources, car cette synthèse est déjà faite et relue. RAG peut manquer des liens si les fragments pertinents dépassent ce que la fenêtre de contexte peut contenir : il ne voit jamais l’ensemble en une seule passe.
• Maintenance : RAG demande très peu de maintenance une fois le magasin vectoriel en place, car l’indexation est mécanique. Une LLM Wiki requiert un entretien actif : passes de « lint » pour détecter les affirmations périmées, vérifications de contradictions, revues périodiques pour élaguer les pages orphelines. En contrepartie, un wiki entretenu s’enrichit avec le temps, tandis qu’un index RAG reste plat.
• Scalabilité : RAG monte en charge de manière prévisible avec le nombre de documents, car la recherche est un problème d’indexation. Une LLM Wiki monte en charge selon la capacité du modèle à garder la connaissance compilée cohérente en grossissant. Au-delà d’une certaine taille, les wikis ont besoin de fichiers d’index, d’outils de recherche, ou de couches d’embeddings pour rester navigables.

Voici un récapitulatif côte à côte :

LLM Wiki versus RAG

Dans la pratique, RAG et les LLM Wikis sont aussi complémentaires. Certaines implémentations exécutent RAG sur le wiki lui-même dès qu’il dépasse ce qu’un fichier d’index peut gérer.

Pourquoi les agents d’IA bénéficient d’une LLM Wiki

Les agents d’IA souffrent encore plus que les systèmes de chat du problème de l’absence de mémoire. Une conversation isolée peut tolérer des ré-« retrievals », mais des agents qui tournent des heures ou des jours redécouvrent les mêmes faits sur des dizaines de tâches. Une LLM Wiki leur offre un endroit où stocker ce qu’ils apprennent pour ne pas avoir à le réapprendre.

Voici quelques domaines où une connaissance persistante montre le plus de potentiel :

• Développement logiciel : un agent de code qui travaille des semaines sur une base de code accumule de la connaissance sur les modules, conventions, bogues passés et décisions de conception. Sans wiki, ce contexte est reconstruit à chaque session. Avec un wiki, l’agent lit les pages compilées et reprend là où la session précédente s’est arrêtée.
• Recherche de longue haleine : un agent qui suit un sujet à travers des centaines d’articles ne peut pas tout garder en contexte. Un wiki lui offre un lieu pour classer des résumés et retrouver la vue d’ensemble évolutive sans relire tout le corpus.
• Assistants d’entreprise : déployés en interne, ils reçoivent les mêmes questions de différents employés au quotidien. Un wiki leur permet de répondre à partir d’un savoir interne compilé au lieu de fouiller les mêmes pages à chaque demande.
• Mémoire organisationnelle : les équipes perdent du contexte quand des personnes partent ou qu’une réunion se termine. Une LLM Wiki alimentée par des transcriptions, tickets et documents conserve ce contexte relié.

Bien mise en œuvre, une LLM Wiki se fera sentir sur trois plans :

1. Moins de recherches répétitives : un agent qui lit une page compilée n’a pas besoin de relancer la même recherche web ou la même requête vectorielle que la veille.
2. Contexte plus riche : les pages du wiki contiennent déjà des synthèses ; l’agent démarre chaque tâche avec une base plus dense et mieux connectée que des extraits bruts ne pourraient lui offrir.
3. Apprentissage cumulatif : chaque session enrichit le wiki, et la suivante bénéficie de ce que la précédente a découvert. C’est ainsi qu’un agent s’améliore vraiment avec le temps, au lieu de repartir de zéro à chaque invite.

Construire une LLM Wiki

Le flux de travail d’un wiki est une boucle. Les sources entrent, les pages s’écrivent et se réécrivent, et l’ensemble se raffine à mesure que le corpus grandit.

Boucle de construction d’une LLM Wiki

• Ingérer les documents. Première étape : amener les sources en stockage brut. Les documents sont lus une fois et conservés immuables pour que chaque affirmation en aval renvoie à une source précise. L’ingestion peut être un fichier unique, un lot, ou un flux depuis un dossier surveillé par le modèle.
• Identifier entités et concepts. Pour chaque nouvelle source, le modèle extrait l’essentiel : entités nommées, concepts clés, affirmations, définitions, relations. C’est le moment où le texte non structuré devient classable par le wiki. Cette passe d’extraction vérifie aussi le wiki existant pour distinguer ce qui est déjà couvert de ce qui est nouveau.
• Générer ou mettre à jour les pages. Les nouvelles entités obtiennent de nouvelles pages. Les pages existantes sont révisées avec l’information nouvelle. Si la source contredit une affirmation existante, le modèle la signale sur la page au lieu d’écraser le contenu. Une seule source ingérée modifie souvent 10 à 15 pages car les sources abordent plusieurs sujets.
• Entretenir les liens. Des références croisées bidirectionnelles sont ajoutées pour que les pages restent connectées. Si une nouvelle page sur RAG mentionne les bases de données vectorielles, et qu’une page vector databases existe déjà, les deux pages sont liées.
• Raffiner en continu la connaissance. Des passes de « lint » périodiques détectent les problèmes qui s’accumulent : contradictions entre pages, affirmations périmées remplacées par des sources récentes, pages orphelines sans liens entrants, concepts importants cités en passant mais sans page dédiée. Cette étape garde le wiki en bonne santé en montant en charge.

Les détails dépendent de votre stack, mais la forme générale reste la même : ingérer, extraire, écrire, lier, raffiner — et boucler.

Fonctionnalités communes des systèmes LLM Wiki

La plupart des implémentations de LLM Wiki partagent le même ensemble de fonctionnalités. Les déclinaisons diffèrent, mais les briques de base sont communes.

Compilation automatique du savoir

Le wiki s’écrit tout seul. Quand une source est ingérée, le modèle en extrait l’essentiel et le classe dans des pages sans intervention humaine. La maintenance manuelle tue les wikis traditionnels : on se lasse de mettre à jour les références croisées et les résumés. Les modèles, eux, ne se lassent pas : c’est la fonctionnalité qui rend l’ensemble viable.

Pages liées

Chaque page renvoie à des pages connexes via des références croisées. Lorsqu’une page sur les transformers mentionne les attention mechanisms, les deux pages se lient réciproquement. Le résultat est un graphe navigable où l’on découvre des connexions insoupçonnées en suivant les références.

Attribution des sources

Chaque affirmation de chaque page renvoie à une source précise. Les documents bruts demeurent immuables pour vérifier à tout moment l’origine de l’information. C’est crucial pour deux raisons : fournir une piste d’audit pour contrôler la justesse, et permettre au modèle de retirer proprement des affirmations quand une source est supprimée.

Graphes de connaissances

La structure liée du wiki forme en soi un graphe de connaissances. Les nœuds sont les pages, les arêtes sont les liens, et la forme du graphe révèle la vraie nature du corpus. Des pages « hub » apparaissent naturellement autour des concepts importants, des pages orphelines signalent des lacunes, et des amas denses montrent les zones les mieux maîtrisées.

Mémoire persistante

Le wiki est disponible entre les sessions. Le contexte d’un chat disparaît à la fin de la conversation, mais les pages du wiki restent sur disque en markdown. C’est ce qui transforme un modèle de chat en un système capable de porter le savoir d’un jour à l’autre, d’un projet à l’autre, et entre exécutions d’agents.

Mises à jour continues

Les nouvelles sources entraînent des révisions des pages existantes, pas de simples ajouts. Si un article publié le mois dernier contredit ce qui était écrit il y a six mois, le wiki le signale et met à jour les pages concernées. La base se rapproche de la véracité avec le temps, au lieu d’accumuler des énoncés périmés.

Ces fonctionnalités ne sont pas indépendantes. Un wiki sans attribution des sources n’est pas digne de confiance. De même, un wiki sans mises à jour s’évente, et un wiki sans pages liées n’est qu’un dossier de résumés. La valeur naît de leur combinaison.

Cas d’usage concrets des LLM Wikis

Le schéma décrit jusqu’ici est général ; voici maintenant des applications réelles où une LLM Wiki peut être utile, voire plus utile que RAG.

Littérature scientifique

Quiconque suit un sujet à travers des dizaines ou des centaines d’articles fait face au même problème : les publications s’empilent plus vite qu’elles ne sont lues. Une LLM Wiki lit chaque article à son arrivée, en extrait les affirmations, les classe sous les concepts pertinents, et signale les contradictions avec ce qui a déjà été lu. Le résultat est une synthèse vivante, alignée sur l’état de l’art, au lieu d’un dossier de PDFs que vous ne lirez jamais.

Documentation d’ingénierie

Les bases de code cumulent une dette documentaire qui grandit souvent à chaque sprint. Typiquement, des décisions de conception se prennent dans des fils Slack, et des notes d’architecture vivent dans le Notion de quelqu’un. Le code est la seule source garantie à jour. Un wiki alimenté par le code, les commentaires, les pull requests et la doc interne peut compiler une vision du système connectée au code. Les ingénieurs peuvent questionner le wiki plutôt que la personne qui a écrit le module il y a trois ans.

Bases de connaissances d’entreprise

Les entreprises accumulent du savoir dans des tickets, transcriptions de réunions, spécifications produits et wikis internes. Une LLM Wiki peut ingérer l’ensemble et compiler une unique couche de connaissance qui reste à jour. Les employés l’interrogent une fois au lieu de fouiller quatre outils différents.

Gestion personnelle des connaissances

Les apps de prise de notes ont résolu le stockage, pas la synthèse. Vous avez toujours des centaines de notes, d’articles et de surlignages, que vous ne revisiterez pas. Un wiki alimenté par votre coffre-fort Obsidian, par exemple, peut transformer ce tas de notes en un corps de connaissance compilé, interrogeable.

Mémoire pour agents d’IA

Des agents qui tournent des heures ou des jours ont besoin d’un endroit pour stocker leurs apprentissages. Le wiki leur offre une mémoire durable réutilisable entre sessions : ce qui a marché, ce qui n’a pas marché, quels fichiers ont déjà été lus, quelles pistes ont été explorées. C’est particulièrement utile pour des agents construits au dessus de Claude Code ou d’outils similaires, où l’on travaille sur la même base de code au fil de nombreuses sessions et où le contexte des exécutions précédentes rend la session courante efficace.

Implémentations actuelles de LLM Wiki

En 2026, l’écosystème LLM Wiki en est à ses débuts. La plupart sont open source et portés par des individus ou de petites équipes. On est loin de la maturité actuelle de RAG.

Le gist initial de Karpathy est le point de départ de nombreux implémenteurs. Il décrit le schéma avec suffisamment de détail pour que quiconque disposant d’un agent LLM puisse construire sa variante en collant le document dans Claude Code ou un outil similaire. La plupart des wikis actuels naissent comme projets personnels bâtis sur une idée partagée.

Les initiatives open source sont le terrain d’expérimentation. Des projets comme llm-wiki.net publient leur code sous licences permissives pour permettre forks, extensions ou adaptations aux différents flux de travail. L’avantage : vous voyez exactement ce que fait le wiki et vous le modifiez si vos besoins ne collent pas au défaut.

Les approches « local-first » tournent entièrement sur votre machine. Les sources sont sauvegardées sur disque, le wiki est un dossier de fichiers markdown, et le modèle lit/écrit via un agent local. Obsidian est l’interface la plus courante, conçue pour le markdown et les liens. Vous gardez un contrôle maximal : les sources ne quittent pas votre machine et vous pouvez inspecter chaque page écrite par le modèle.

Les versions hébergées commencent à apparaître mais restent rares. Le schéma s’accorde moins bien au modèle SaaS que RAG, car le wiki est censé vous appartenir : vos sources, vos pages, vos choix de classement. Les versions hébergées conviennent surtout aux wikis d’équipe, où la valeur du savoir partagé l’emporte sur le coût d’héberger les sources sur l’infrastructure d’autrui.

Mais en juillet 2026, rien n’est achevé. On en est encore au défrichage, et la plupart des projets actuels sont des prototypes.

Atouts et limites

Le schéma LLM Wiki a ses forces et ses coûts. Il faut connaître les deux avant de se lancer.

Atouts

• Connaissance persistante : le wiki reste disponible au-delà de toute session. Ce que le modèle a élucidé le mois dernier est encore sur la page aujourd’hui, et le nouveau travail s’appuie dessus au lieu de repartir à neuf.
• Synthèse réutilisable : le travail de liaison des sources a lieu une fois, à l’ingestion. Chaque requête ultérieure lit le résultat compilé au lieu de re-synthétiser le texte brut. On économise du calcul et on obtient de meilleures réponses, car le modèle a déjà fait le travail de fond.
• Moins de récupérations répétées : un wiki qui a déjà une page sur un sujet n’a pas besoin de fouiller le corpus brut à chaque occurrence. Essentiel pour des agents de longue durée, qui évitent ainsi de relancer les mêmes recherches.
• Organisation structurée : des pages et des liens qu’on peut parcourir et sur lesquels on peut raisonner, bien plus qu’un dossier de PDFs.

Limites

• Maintien à jour : le wiki doit être ré-ingéré lorsque les sources changent. Si un document évolue et que vous ne relancez pas l’ingestion, le wiki continue de référencer l’ancienne version. RAG n’a pas ce problème, puisqu’il lit les sources en direct au moment de la requête.
• Vérification délicate : chaque affirmation d’une page a été écrite par un modèle. L’attribution aide, mais il faut encore faire confiance à la fidélité du résumé par le modèle.
• Maintenance : les vérifications de contradictions et la ré-ingestion ont un coût. Un wiki non entretenu se périme, et la maintenance consomme du temps et du calcul, même si le modèle fait l’essentiel.
• Dérive potentielle du savoir : chaque ingestion peut introduire de petits biais ou erreurs. Sur des centaines d’ingestions, ils peuvent se cumuler : une page initialement juste peut finir subtilement inexacte après de nombreuses révisions.

Idées reçues courantes sur les LLM Wikis

Bien que la LLM Wiki soit un concept nouveau, des idées fausses circulent déjà. Voici ce qu’elles manquent.

Une LLM Wiki remplace RAG

Non. Les deux répondent à des problématiques différentes. RAG sert à des recherches rapides sur un corpus changeant souvent. Une LLM Wiki sert à constituer un corpus de connaissances dans la durée. Beaucoup de systèmes réels combinent les deux : RAG pour la fraîcheur des sources brutes, un wiki pour la synthèse compilée par-dessus.

Ce n’est qu’une autre base vectorielle

Les bases vectorielles indexent du texte pour la recherche. Une LLM Wiki écrit un texte que le modèle a lu, compris et réorganisé. Une base vectorielle vous renvoie les extraits que vous y avez placés. Un wiki vous renvoie des pages qui n’existaient pas avant l’ingestion. La sortie est radicalement différente.

La base de connaissances n’a jamais besoin d’être mise à jour

Faux. Les sources changent, de nouvelles arrivent, et le modèle commet des erreurs à corriger. Un wiki non entretenu se périme comme toute documentation. La différence, c’est que le modèle prend en charge l’essentiel de la maintenance, pas qu’elle disparaisse.

Cela ne profite qu’aux agents d’IA

Les agents sont le cas le plus clair, car ils tournent longtemps et bénéficient d’une mémoire durable, mais les humains en tirent aussi de la valeur. Pensez à un chercheur qui suit un sujet ou à un ingénieur sur une base de code. Ou à toute personne qui construit un capital de connaissance personnel et bénéficie de cette synthèse cumulative. 

Les LLM Wikis deviendront-ils une nouvelle architecture d’IA ?

Il est trop tôt pour le dire, mais la trajectoire probable est claire : la connaissance persistante ne remplacera pas les systèmes « recherche d’abord », elle cohabitera avec eux : RAG pour les consultations en direct, les wikis pour le contexte compilé et de longue durée. Les grandes questions ouvertes portent sur la validation et le passage à l’échelle — personne n’a encore totalement résolu la détection des erreurs de modèle écrites dans les pages, ni éprouvé le schéma sur des wikis très vastes. MCP semble naturellement adapté pour exposer des wikis aux agents, mais l’adoption en entreprise sera plus tardive du fait des exigences accrues en matière de confiance.

Le schéma n’est pas encore établi. Sa progression dépendra de la résolution des enjeux de maintenance et de validation. D’autres questions trouvent réponse dans la FAQ ci-dessous.

Conclusion

La LLM Wiki est l’une des idées les plus intéressantes émergées en 2026, car elle change ce que fait un système d’IA lorsque vous lui fournissez une source. Plutôt que de relire les mêmes documents à chaque requête, le modèle les lit une fois et les classe dans une base de connaissances qui s’améliore avec le temps.

Le concept en est encore à ses débuts et les implémentations actuelles sont préliminaires, mais l’idée est prometteuse et s’inscrit dans une tendance plus large. Les systèmes d’IA passent d’un contexte jetable à une connaissance persistante, et les LLM Wikis figurent parmi les premières tentatives sérieuses de ce que cela signifie concrètement.

Si vous souhaitez suivre les nouveautés sans vous y perdre, inscrivez-vous à notre parcours AI Fundamentals. Vous apprendrez le jargon et saurez utiliser l’IA efficacement au travail.