InfoForge : Wikipédia hors ligne comme source RAG pour mes agents IA locaux

J’ai demandé à un modèle local de 8B qui avait écrit Kokoro et quand il avait été publié. Il a répondu « Natsume Sōseki, 1914 », puis il a fait ce qui m’intéressait vraiment : il a indiqué l’article Wikipedia dans lequel il avait trouvé cette information. Le modèle ne connaissait pas ce fait ; il l’a recherché dans une copie de Wikipédia de 52,69 Go stockée sur mon ordinateur, sans aucune interaction avec Internet.

Pourquoi s’embêter, alors que le modèle « sait déjà tout » ?

Parce qu’en réalité il ne sait rien, et son mode d’échec est problématique. Un petit modèle interrogé sur une date, une propriété chimique ou un nom de lieu donnera une réponse fluide, convaincante et plausible, sans la moindre indication quant à sa véracité. Il ne ment pas ; il n’a tout simplement aucun mécanisme pour distinguer la mémorisation de la génération. Cela convient pour de la prose, mais est désastreux pour les faits.

La recherche externe résout le problème, mais la plupart des solutions reposent sur une API cloud : votre question part chez un tiers qui la consigne, et l’utilité de votre assistant dépend désormais de la disponibilité et des conditions d’utilisation de ce tiers. Or, dans mon foyer où les modèles d’IA répondent aux questions de mes enfants, ces deux aspects me dérangent fortement.

Wikipédia résout simultanément ces deux problèmes : c’est le corpus de connaissances générales le plus dense qui existe, il est légalement et techniquement téléchargeable en intégralité, et il tient sur un disque dont le coût est inférieur à celui d’une soirée au restaurant. Le projet Kiwix s’en charge depuis des années : il conditionne l’ensemble des wikis dans le format ZIM compressé et indexé, destiné à un usage hors ligne dans les écoles, sur les navires ou dans les zones dépourvues de connexion. Je me contente simplement d’orienter un modèle vers ce contenu plutôt que vers un navigateur.

Ce que vous obtenez en fin de compte

Une question en entrée, une réponse en sortie, ainsi qu’un bloc de citations indiquant précisément quels articles Wikipédia ont servi à la formulation de cette réponse. Par exemple :

$ infoforge "Qui a écrit Kokoro et quand a-t-il été publié ?"

Kokoro a été écrit par Natsume Sōseki et publié en 1914.

Sources :
  - Kokoro

Rien de spectaculaire à première vue. L’essentiel est ce qui ne se produit pas : aucune requête réseau n’est envoyée, rien n’est consigné auprès d’un fournisseur, et le modèle est structurellement empêché de répondre en se basant uniquement sur sa mémoire. En cas d’absence de résultats, le programme affiche un échec et renvoie un code d’erreur non nul, plutôt que de combler le vide par une réponse inventée.

Comment ça fonctionne

Cinq étapes, toutes très simples — c’est d’ailleurs la recommandation.

Extraction des mots-clés. La question brute n’est pas une requête efficace. « Qui a écrit Kokoro et quand a-t-il été publié ? » est un mauvais terme de recherche ; Kokoro est bien meilleur. Une trentaine de lignes de code suffisent à supprimer les mots vides et conserver les expressions pertinentes ; je ne l’ai jamais remplacée.

Recherche. La recherche en texte intégral de Kiwix est un véritable index, pas un simple grep — c’est ce qui permet d’obtenir des résultats aussi rapides. Sur 19,19 millions d’entrées, les titres correspondants sont renvoyés en 3 à 30 millisecondes. Il n’y a ici aucune intégration d’embeddings, aucune base de données vectorielle ni aucun système de découpage à reconstruire lors des mises à jour. Les éditeurs de Wikipédia se sont déjà chargés du découpage : ils appellent ces fragments des « articles ».

Récupération et troncage. Les meilleurs résultats reviennent sous forme d’articles complets, chaque récupération prenant environ 0,5 ms. Le troncage est la seule étape nécessitant un jugement : les premières sections contiennent la plupart des informations pertinentes ; on extrait donc le texte du début de chaque article jusqu’à atteindre le budget de tokens imparti, sans en prendre trop afin que l’instruction suivante ne soit pas écrasée.

Le prompt ancré. Les articles obtenus sont intégrés au prompt avec la consigne stricte de ne répondre qu’à partir de ces sources et de citer leurs titres. C’est là toute la clé du système ; il s’agit d’un simple prompt, pas d’une garantie absolue — raison pour laquelle une étape supplémentaire est prévue.

Le modèle. Un modèle de raisonnement local (DeepSeek-R1 8B, exécuté sur le serveur GPU domestique) rédige la réponse. Une fois chauffé, l’ensemble du processus prend environ 8 secondes, dont 7,9 secondes sont consacrées au modèle lui-même. La recherche est gratuite ; la réflexion ne l’est pas.

L’ancrage comme contrat de refus

C’est le choix architectural que je défendrais le plus : il n’est d’ailleurs pas technique du tout.

Un prompt indiquant « utilisez uniquement ces sources » est une demande polie. Les modèles s’y conforment la plupart du temps, mais l’ignorent parfois discrètement, surtout lorsque les sources sont rares et que le modèle possède dans sa mémoire des informations similaires. Si la seule protection repose sur cette phrase, alors « ancrage » n’est qu’un concept vague.

C’est pourquoi l’ancrage est appliqué en dehors du modèle lui-même. Lorsque la recherche ne renvoie aucun résultat exploitable, l’outil ne transmet pas la question brute au LLM comme solution de repli — il échoue, et ce, en renvoyant un code d’erreur non nul, signal que tous les programmes appelants savent déjà interpréter. Les agents IA qui s’en servent sont tenus de signaler l’échec plutôt que de fournir une réponse imaginaire. Le refus se propage ainsi ; il ne se voile pas au niveau supérieur.

On obtient ainsi un assistant qui avoue franchement ne pas avoir trouvé d’information. Cela semble être un défaut sur papier, mais c’est tout le contraire. Un modèle qui dit « Je n’ai rien trouvé » vaut infiniment plus qu’un modèle plus grand qui invente des réponses, car le premier sert de base fiable tandis que le second exige une vérification factuelle systématique — et si chaque réponse doit être vérifiée, on n’a finalement gagné aucun temps.

La confidentialité est une architecture, pas une politique

Tous les grands assistants disposent d’une page dédiée à la confidentialité. Ici, il n’y a qu’une topologie : la question part du terminal, atteint un index de recherche sur le même réseau local, puis un modèle situé également sur ce réseau, avant de revenir vers l’utilisateur. Aucun fournisseur ne peut enregistrer cette requête, aucune clé ne permet d’identifier quiconque, aucun contrat d’utilisation ne risque d’être modifié à l’avenir. Mon enfant peut lui poser une question embarrassante sans crainte : l’opération est aussi privée que si on consultait un livre sur une étagère, car c’est précisément ce qui se passe.

Personne n’a besoin de me faire confiance pour cela — et c’est là le plus beau : on peut vérifier en débranchant simplement Internet et constater que tout continue de fonctionner.

Les 90 % peu glamour

La mise en place du pipeline n’a demandé qu’un week-end agréable. Le véritable défi résidait dans trois simples options de conteneur.

Le serveur Wikipédia tourne dans un conteneur sans privilèges sur un poste Linux immuable doté de SELinux en mode strict ; chacun de ces critères a nécessité une soirée entière de travail :

• Mappage des utilisateurs sans privilèges. Le conteneur doit fonctionner en tant que root dans son propre espace, tout en étant associé à mon utilisateur non privilégié en dehors. Une erreur ici fait que le serveur démarre, se déclare opérationnel, mais ne sert rien — le processus est simplement incapable de lire le fichier auquel il est censé accéder.
• Relabellisation SELinux. Sur un système SELinux, un volume monté dans un conteneur doit être configuré avec une option spécifique pour être relabelisé ; sans cela, le noyau bloque toute lecture en vertu d’une politique qui ignore purement et simplement l’existence du conteneur. L’erreur se manifeste alors comme une absence de fichier, ce qui conduit à chercher au mauvais endroit.
• Chemins de fichiers explicites. La détection automatique du répertoire ZIM ne se comportait pas comme indiqué dans la documentation depuis l’intérieur du conteneur. Il a suffi de nommer le fichier explicitement ; cela n’a pris que trente secondes, une fois que j’ai compris que le problème ne résidait pas ailleurs.

Trois options seulement. Elles ont englouti environ 90 % du temps total investi. Voilà la réalité de la plupart des projets d’auto-hébergement : cette partie ingrate est rarement décrite dans les tutoriels — ce qui conduit les gens à croire qu’ils sont mauvais en la matière, alors qu’ils font simplement leurs premiers pas, seuls, face aux mêmes trois options.

Puis ça a disparu, sans que personne ne le remarque

Ça fonctionnait. C’était rapide. J’ai effectué des tests, noté les chiffres, et j’ai passé à autre chose.

Une semaine plus tard, j’ai voulu l’utiliser… mais il avait disparu. À un moment donné, la machine s’était redémarrée ; le conteneur n’était pas revenu en ligne, et rien ne m’avait prévenu — car il n’y avait ni unité de service, ni surveillance, ni vérification d’état. Pire encore : le fichier de compétences qui aurait informé mes agents IA de l’existence de cet outil était resté en brouillon, sans jamais être installé. Pendant toute cette semaine, chaque agent a donc répondu en se basant sur sa mémoire, alors qu’il aurait pu consulter l’outil ; il ignorait même qu’une option manquait.

La leçon à retenir est simple :

Une fonctionnalité que rien ne lance automatiquement et dont personne n’a connaissance est indiscernable d’une fonctionnalité que vous n’avez jamais créée.

La solution a consisté en une unité de service de 12 lignes et un fichier Markdown. L’unité de service permet au serveur de survivre à un redémarrage ; le fichier Markdown constitue une compétence partagée dans l’écosystème d’agents — c’est ainsi que mes agents découvrent ce qu’ils peuvent faire. Ce fichier indique l’existence de l’outil, la manière de l’utiliser (une commande shell ou un simple appel HTTP), et exige que toute réponse inclue ses références.

Le pipeline initial comptait 700 lignes — c’était une belle histoire. Mais ce sont ces treize lignes de code basique qui ont rendu le tout opérationnel. Je réapprends cette leçon sans cesse.

Intégré à l’écosystème d’agents

Je gère une petite flotte d’agents IA locaux pour les tâches domestiques et professionnelles ; InfoForge est désormais une capacité partagée, et non plus un simple script dont je devais me souvenir. Un agent ayant besoin d’une information exécute la commande ou appelle l’endpoint, reçoit une réponse accompagnée de références, puis transmet le tout. Ces références sont cruciales : lorsqu’un agent me communique quelque chose en citant un article, je peux vérifier cela d’un simple clic. Cette vérification est ce qui transforme un assistant potentiellement fiable en un outil véritablement utilisable.

InfoForge s’intègre également à tout le reste du système. Le même serveur GPU traite les requêtes InfoForge, rédige des e-mails et participe aux échanges de chat ; la couche de connaissances est désormais un élément supplémentaire dont on n’a pas besoin de créer de compte.

Points à surveiller

• Espace disque requis avant le téléchargement. Environ 53 Go pour la version sans images, presque le double si vous souhaitez inclure des illustrations. Vérifiez d’abord l’espace disponible ; un fichier ZIM partiellement téléchargé est un moyen lent de s’en rendre compte.
• La date du dump est importante. Le mien date de juin 2026. Wikipédia continue d’évoluer ; tout contenu plus récent n’est pas reconnu par le système, ce qui est normal si vous le savez… mais peut vite devenir une source d’erreurs sinon.
• La qualité des recherches dépend de l’extraction des mots-clés. Presque toutes les mauvaises réponses proviennent d’une requête mal formulée, pas d’un modèle insuffisant. Améliorez d’abord l’extraction des termes clés avant de songer à utiliser un modèle plus puissant.
• La troncature du contexte est un paramètre crucial. Trop peu de contexte empêche d’obtenir la bonne réponse ; trop en donner fait dériver le modèle des instructions initiales. Réglez ce paramètre en fonction de questions réelles, pas uniquement synthétiques.
• Testez volontairement les cas d’échec. Posez une question sur laquelle Wikipédia n’a effectivement aucun article, et vérifiez que le système refuse de répondre en renvoyant un code d’erreur non nul — pas un long paragraphe. Si vous ne testez que les cas simples, vous ne testez qu’une moitié du système.
• Créez l’unité de service dès le premier jour. Comme expliqué plus haut. Demandez-moi comment je le sais.

Où cela me mène

Ma maison dispose désormais d’une encyclopédie hors ligne dotée d’un index de recherche, ainsi que d’une IA autorisée uniquement à s’exprimer en se basant sur ce contenu. Tout cela n’a coûté qu’un téléchargement et un week-end de travail. Le système est plus rapide qu’Internet, fonctionne même en cas de panne réseau, ne risque pas d’être supprimé, et ne nécessite aucun modèle économique me concernant.

Prochaines étapes : ajouter d’autres collections ZIM dans le même rack — les ensembles médicaux et techniques proposés par Kiwix, ainsi que quelques wikis personnels — car la couche de recherche s’adapte à n’importe quel corpus. Et bien sûr, mettre en place une vérification d’état… car j’ai désormais appris cette leçon à mes dépens.

Téléchargements

• Download InfoForge project source (zip) 80 KB

Gratuit pour un usage personnel. Si ça vous fait gagner un après-midi, le bouton café n'est pas loin.