InfoForge : Wikipédia hors ligne en tant que 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 indiqué l’article Wikipédia dans lequel il avait trouvé cette information. Or, le modèle ne connaissait pas ce fait en soi ; 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’en donner la peine, alors que le modèle « sait déjà tout » ?

Parce qu’en réalité il ne sait rien, et que son mode d’échec est problématique. Un petit modèle interrogé sur une date, une propriété chimique ou un nom de lieu produira une réponse fluide, convaincante et plausible, sans la moindre indication quant à sa véracité. Il ne ment pas — il n’a simplement aucun mécanisme pour distinguer ce qu’il se rappelle de ce qu’il génère. Cela convient pour du texte littéraire, mais est catastrophique pour les faits.

La récupération d’informations corrige cela, mais les systèmes classiques supposent un API de recherche cloud : la requête part vers une entreprise qui la conserve dans ses registres ; l’utilité de votre assistant dépend alors de la disponibilité et des conditions d’utilisation de ce tiers. Or, chez moi, c’est mon stack IA qui répond aux questions de mes enfants — et ces deux aspects me préoccupent fortement.

Wikipédia résout ces deux problèmes simultanément : c’est le corpus de connaissances générales le plus dense existant, il est légalement et techniquement téléchargeable dans sa totalité, et il tient sur un disque dont le coût est inférieur à celui d’une soirée au restaurant. Le projet Kiwix s’occupe depuis des années de cette tâche ardue : packager des wikis entiers 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 d’orienter mon IA vers ce fichier plutôt que vers un navigateur.

Ce que l’on obtient 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 à construire la 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’a quitté le domicile, rien n’a été enregistré par un fournisseur quelconque, et le modèle a été structurellement empêché de répondre uniquement à partir de sa mémoire. Si la recherche n’avait rien donné, le programme aurait affiché un échec et renvoyé un code d’erreur non nul au lieu de combler le vide par une réponse.

Comment cela fonctionne

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

Extraction des mots-clés. La question n’est pas forcément la requête idéale. « Qui a écrit Kokoro et quand a-t-il été publié ? » est une formulation peu adaptée ; Kokoro l’est davantage. Une trentaine de lignes de code, qui suppriment les mots vides et conservent les expressions clés, suffisent largement — je n’ai jamais jugé utile de les modifier.

Recherche. La recherche en texte intégral de Kiwix repose sur un véritable index, pas sur un simple grep ; c’est ce qui permet d’obtenir des résultats si rapides. Sur 19,19 millions d’entrées, elle renvoie les titres pertinents en 3 à 30 millisecondes. Il n’y a aucune intégration d’embeddings, aucune base de données vectorielles ni aucun système de découpage à reconstruire lors des mises à jour du dump. Les éditeurs de Wikipédia se sont déjà chargés du découpage : ils appellent cela des articles.

Récupération et troncage. Les meilleures occurrences reviennent sous forme d’articles complets, chacun en environ 0,5 ms. Le troncage constitue la seule étape nécessitant un jugement humain : les premières sections contiennent la plupart des informations utiles ; on consomme donc le budget de tokens en partant du haut, tout en veillant à conserver suffisamment de texte pour que chaque article soit autonome, sans en accumuler au point d’écraser l’instruction suivante.

Le prompt ancré. Les articles extraits sont insérés dans le prompt avec une directive imposant de répondre uniquement à partir de ces sources et de citer les titres utilisés. C’est là tout le principe, mais il s’agit d’un simple prompt, pas d’une garantie absolue — d’où l’importance de la phase suivante.

Le modèle. Un modèle de raisonnement local (DeepSeek-R1 8B, installé sur le serveur GPU de la maison) produit la réponse finale. Une fois chauffé, l’ensemble du cycle ne prend qu’environ 8 secondes, dont 7,9 secondes sont consacrées au raisonnement proprement dit. La recherche est gratuite ; le raisonnement, lui, a un coût.

L’ancrage comme contrat de refus

Voici la décision architecturale que je défendrais le plus vivement — et elle n’est pas technique.

Un prompt indiquant « utilisez uniquement ces sources » est en réalité une requête. Les modèles s’y conforment la plupart du temps, mais y désobéissent discrètement parfois, surtout si les sources sont maigres et que le modèle possède dans sa mémoire des informations similaires. Si le seul rempart du système est cette instruction, alors « ancrage » n’est qu’un terme vague.

C’est pourquoi l’ancrage est appliqué en dehors du modèle. Lorsque la recherche ne renvoie rien d’utilisable, l’outil ne transmet pas la question brute au LLM comme solution de repli — il échoue, et ce, avec un code de sortie non nul, signal que tout programme appelant sait déjà interpréter. Les agents IA qui l’utilisent sont tenus de signaler un échec de recherche plutôt que de substituer une réponse tirée de leur propre mémoire. Le refus se propage ainsi ; il n’est pas estompé par une couche supérieure.

Le résultat est un assistant qui avouera franchement ne pas avoir trouvé d’information. Cela semble être un défaut sur une liste de fonctionnalités, 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 l’on doit contrôler chaque réponse, on n’a en réalité rien gagné.

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 également sur ce réseau, avant de revenir. Il n’y a aucun fournisseur susceptible d’enregistrer quoi que ce soit, aucune clé permettant de m’identifier, aucune clause contractuelle susceptible d’être modifiée dans les prochains trimestres. Mon enfant peut lui poser une question embarrassante ; la transaction est aussi privée que si l’on consultait un livre sur une étagère, car c’est exactement ce qu’elle est.

Personne n’a besoin de me faire confiance pour cela, et c’est là le point positif : il suffit de couper Internet pour constater que tout continue de fonctionner.

Les 90 % ingrats

Le pipeline lui-même a été créé en un week-end, sans difficultés majeures. Le vrai 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 doté d’un SELinux strict ; chacun de ces attributs m’a coûté une soirée entière :

• Mappage des utilisateurs sans privilèges. Le conteneur doit s’exécuter en tant que root dans son propre espace de noms, lequel est 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 ne parvient tout simplement pas à lire le fichier ciblé.
• Relabellisation SELinux. Un volume monté dans un conteneur sur un système SELinux exige l’option de montage adéquate pour être relabelisé ; sans cela, la lecture est bloquée par un mécanisme de sécurité qui ignore purement le conteneur. L’erreur se manifeste alors comme une absence de fichier, ce qui pousse à chercher à l’endroit totalement erroné.
• Chemins de fichiers explicites. La détection automatique du répertoire ZIM ne fonctionnait pas selon les indications de la documentation dans le contexte du conteneur ; indiquer le chemin manuellement a pris trente secondes, une fois que j’ai cessé de croire que le problème résidait ailleurs.

Trois options. Environ 90 % du temps consacré au projet. Voilà la réalité du self-hosting : ce sont ces aspects ingrats qui occupent la majeure partie du travail, et c’est précisément ce qu’on omet de mentionner dans les articles — d’où l’idée fausse selon laquelle certaines personnes seraient mauvaises en la matière, alors qu’elles font simplement leurs premiers pas, seules, face aux mêmes trois options.

Puis ça a cessé de fonctionner, sans que personne ne s’en aperçoive

Ça fonctionnait. C’était rapide. J’ai fait des tests, noté les chiffres, puis je suis 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’avait pas repris son activité, et rien ne m’en avait informé — car il n’y avait ni unité de service, ni surveillance, ni vérification d’état. Pire encore : le fichier décrivant cette fonctionnalité, qui aurait permis à mes agents IA de savoir que cet outil existait, n’avait jamais été installé — il était resté en mode brouillon. Pendant toute cette semaine, chaque agent a donc répondu en se fiant à sa mémoire, alors qu’il aurait pu consulter l’outil ; ils ignoraient même qu’une option manquait.

La leçon 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.

Pour y remédier, j’ai écrit une unité de service de 12 lignes ainsi qu’un fichier Markdown. L’unité de service assure la persistance du serveur après un redémarrage ; le fichier Markdown sert de description partagée entre les agents — c’est ainsi qu’ils découvrent ce qu’ils peuvent faire. Il précise l’existence de l’outil, comment l’appeler (via une commande shell ou simplement HTTP), et exige que toute réponse soit accompagnée de ses citations.

Le processus complet comptait 700 lignes ; seules treize lignes de code ont suffi à le rendre opérationnel. Je continue d’apprendre cette leçon, encore et encore.

Intégré au systè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 fonctionnalité partagée plutôt qu’un simple script que je devrais me rappeler. Lorsqu’un agent a besoin d’une information, il exécute la commande ou interroge l’endpoint, reçoit une réponse accompagnée de citations, puis transmet le tout. Ces citations sont cruciales : lorsqu’un agent me fournit des informations en citant un article, je peux le vérifier d’un seul clic. Or, cette vérification est ce qui transforme un assistant crédible en un outil réellement 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 emails et gère les conversations ; la couche de connaissances devient ainsi un élément supplémentaire dont l’utilisation ne nécessite aucun compte d’inscription.

Points à surveiller

• Espace disque requis avant le téléchargement. Environ 53 Go pour la version sans images, et presque le double si vous souhaitez les images. Vérifiez d’abord l’espace disponible ; un fichier ZIM partiellement téléchargé ne vous aidera guère.
• La date du fichier téléchargé compte. Le mien date de juin 2026. Wikipédia évolue sans cesse ; tout contenu plus récent n’existe pas aux yeux de ce système — ce qui est normal si vous le savez, mais peut s’avérer problématique 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, et non d’un défaut du modèle. Corrigez d’abord l’extraction des mots-clés avant de recourir à un modèle plus puissant.
• La troncature du contexte est un choix stratégique. Trop peu de contexte rend la réponse impossible ; trop en donner fait dériver le modèle de ses instructions. Ajustez ce paramètre en fonction de vos questions réelles, pas de celles générées artificiellement.
• Testez volontairement les cas d’échec. Posez une question pour laquelle Wikipédia ne possède aucun article ; vérifiez alors que vous obtenez un refus accompagné d’un code de sortie non nul, et non un long paragraphe. Si vous ne testez que les questions faciles, vous n’avez testé qu’une moitié du système.
• Créez l’unité de service dès le premier jour. Comme indiqué ci-dessus. 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 à s’exprimer uniquement à partir de ce contenu. Tout cela n’a demandé qu’un téléchargement et un week-end de travail. Le système est plus rapide qu’Internet, fonctionne en cas de panne réseau, ne risque pas d’être interrompu, et ne nécessite aucun modèle économique me concernant.

Prochaines étapes : ajouter davantage de fichiers ZIM dans le même rack — les collections médicales et techniques proposées par Kiwix, ainsi que quelques wikis personnels. La couche de recherche s’en moque d’ailleurs, du moment qu’il y a du contenu. Et bien sûr, j’ajouterai une vérification d’état : j’ai désormais payé le prix fort pour apprendre cette leçon.

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.