llm-wiki-agent : un wiki markdown que l'agent tient à jour à votre place

Le problème : des sources qu'on ne relit jamais

Le README part d'un constat simple. La plupart des outils de connaissance personnelle vous font chercher dans vos propres notes. Ici, l'agent lit ce que vous avez collecté et rédige un wiki structuré, avec références croisées et contradictions signalées. La cible est donc assez précise : des personnes qui accumulent des PDF, articles, transcriptions ou chapitres, et qui veulent une synthèse interliée sans écrire les fiches elles-mêmes. Les cas d'usage listés couvrent la recherche longue durée, la lecture chapitre par chapitre, le journal personnel, les comptes rendus de réunion et la veille concurrentielle. Le point commun est le volume : le mécanisme n'a d'intérêt qu'à partir du moment où plusieurs sources traitent des mêmes entités. Une seule source produit une page de résumé, ce que n'importe quel éditeur de texte fait déjà.

Le mécanisme : un dossier raw/, un dossier wiki/, un graphe

L'architecture tient en deux arborescences décrites dans le README. D'un côté raw/, où vous déposez les documents. De l'autre wiki/, qui contient index.md (catalogue mis à jour à chaque ingestion), log.md (journal en ajout seul de chaque opération), overview.md (synthèse vivante révisée à chaque ingestion), puis sources/, entities/, concepts/ et syntheses/. Les pages d'entités et de concepts sont créées automatiquement quand une personne, une entreprise, un projet ou une idée apparaît dans une source. Les réponses aux requêtes sont archivées comme pages dans syntheses/. Le dossier graph/ contient graph.json, présenté comme des données de nœuds et d'arêtes avec un cache SHA256, et graph.html, une visualisation vis.js à ouvrir dans un navigateur. Le README indique que graph.html dessine chaque page comme un nœud, chaque [[wikilink]] comme une arête, et ajoute en pointillés des relations implicites inférées par le modèle. Une détection de communautés regroupe les sujets proches. Rien dans le matériel fourni ne décrit le format exact des entrées de log.md ni la structure interne de graph.json, donc je ne peux pas en dire plus sur ce point.

Installation : quatre agents, aucune clé API

Le dépôt s'installe par un clone, sans étape Python. Les commandes du README sont git clone https://github.com/SamurAIGPT/llm-wiki-agent.git, puis cd llm-wiki-agent. Ensuite, on ouvre le dossier dans l'agent : claude lit CLAUDE.md et .claude/commands/, codex et opencode lisent AGENTS.md, gemini lit GEMINI.md. C'est cette lecture de fichier de configuration qui remplace la clé API : l'agent est déjà authentifié de son côté. Les déclencheurs sont soit des commandes courtes (ingest raw/papers/my-paper.md, query: what are the main themes?, lint, build graph), soit du langage naturel. Claude Code expose en plus /wiki-ingest, /wiki-query, /wiki-lint et /wiki-graph via .claude/commands/. Le README précise que ces slash commands sont spécifiques à Claude Code et que les autres agents utilisent les déclencheurs en langage naturel, qui fonctionnent identiquement. Pour les formats binaires (PDF, DOCX, PPTX, XLSX, HTML, TXT, CSV, JSON, XML, RST, EPUB), la conversion passe par markitdown au moment de l'ingestion, sans étape séparée. C'est aussi la dépendance externe la plus visible du projet.

Ce que lint et query produisent réellement

Les exemples du README sont plus concrets que la moyenne. Après trois ingestions de papiers, lint est censé signaler des manques, par exemple l'absence de sources sur mixture-of-experts avec une suggestion de papier. Sur un corpus d'entreprise, il signale qu'un projet mentionné dans cinq pages n'a pas de page dédiée, ou qu'une feuille de route contredit un entretien client sur la priorité d'une fonctionnalité. Ces sorties sont des exemples documentés, pas des garanties : leur qualité dépend entièrement du modèle qui pilote l'agent et du contenu réel des sources. Le signalement de contradictions se fait à l'ingestion, selon le README, et non au moment de la requête. C'est un choix de conception défendable : la contradiction est détectée quand la nouvelle source entre, avec le contexte des deux textes encore disponibles. En contrepartie, une contradiction qui n'apparaît qu'à la troisième source ne sera vue qu'à cette troisième ingestion.

Les limites que le README ne masque pas

Le projet n'a aucune release publiée et l'historique de publication se limite au dépôt lui-même. Il n'existe pas de version taguée à épingler, donc une adoption implique de suivre la branche main. Autre point : tout repose sur un agent tiers. Si le comportement de Claude Code, Codex, OpenCode ou Gemini CLI change dans la façon de lire les fichiers de configuration ou d'exécuter des commandes, le skill casse sans qu'aucun code du dépôt n'ait bougé. La conversion markitdown ajoute une dépendance non triviale pour les PDF et les formats bureautiques ; le README ne décrit ni le comportement en cas d'échec de conversion, ni la façon de reprendre une ingestion interrompue. Enfin, le wiki est du markdown : il n'y a pas de recherche sémantique sur embeddings, pas d'index vectoriel, pas de serveur. Le README mentionne le mot rag dans les topics, mais le mécanisme décrit est un wiki markdown avec un graphe de liens, pas un pipeline de récupération vectorielle. Si vous cherchez ce dernier point, cet outil n'est pas le bon.

Face à Obsidian seul

Obsidian est nommé dans les topics du dépôt, ce qui invite à la comparaison. La différence porte sur qui écrit. Dans Obsidian, vous créez les notes, les liens et les fiches d'entités ; le graphe se contente d'afficher ce que vous avez saisi. Ici, la création des pages entities/ et concepts/ est déléguée à l'agent à partir des sources brutes, et overview.md est révisé à chaque ingestion. Le prix à payer est le déterminisme : deux ingestions du même document peuvent produire des pages différentes en formulation, là où une note Obsidian reste identique jusqu'à ce que vous la modifiiez. Autre écart : Obsidian est une application avec une interface, des greffons et une recherche locale. llm-wiki-agent est un ensemble de fichiers markdown plus un graphe HTML statique. Pour un usage hors ligne strict ou sur un appareil sans agent de codage installé, Obsidian reste l'option la plus simple.

Coût de maintenance et licence

Le coût de maintenance se répartit entre trois postes. Le premier est la consommation de l'agent : chaque ingestion, chaque requête et chaque lint passe par le modèle, donc le volume de sources se traduit directement en appels. Le deuxième est la dépendance markitdown, à mettre à jour avec le reste de l'environnement. Le troisième est le suivi de main, faute de versions taguées. Côté licence, le dépôt est publié sous MIT, ce qui autorise la modification et la redistribution avec conservation de l'avis de licence. Cela concerne le code du dépôt. Les documents que vous ingérez et le wiki produit restent sous vos propres conditions, et les sorties générées par un agent peuvent soulever des questions distinctes selon le fournisseur utilisé. Ce n'est pas un avis juridique, seulement une lecture de l'identifiant de licence indiqué dans le README.

Un wiki qui vit dans votre arborescence

L'intérêt réel du projet tient à un détail d'implémentation : tout reste sur disque, en markdown, dans un dossier que vous pouvez versionner avec git. index.md sert de catalogue, log.md d'historique en ajout seul, et les pages sont reliées par des [[wikilink]] que graph.html relit. Cela signifie que vous pouvez inspecter, corriger ou supprimer une page produite par l'agent sans passer par une API. C'est aussi ce qui rend le projet fragile : rien ne garantit la cohérence du wiki si vous éditez à la main entre deux ingestions, et le README ne décrit pas de mécanisme de fusion entre une page éditée manuellement et une page régénérée. Pour un corpus stable et un agent configuré, le compromis est clair : vous échangez du contrôle éditorial contre du temps de rédaction.

Conclusion éditoriale

llm-wiki-agent convient à qui accumule déjà des documents et utilise Claude Code, Codex, OpenCode ou Gemini CLI, et accepte un wiki au format markdown versionnable. À éviter si vous cherchez une application graphique, une recherche sémantique sur vecteurs, ou si vous ne pouvez pas installer markitdown pour les formats binaires. Avant d'adopter, vérifiez trois choses : le contenu réel de CLAUDE.md et des fichiers .claude/commands/, le comportement de wiki/log.md après quelques ingestions, et le rendu de graph/graph.html sur votre propre corpus.

Sources officielles

1. Issues
2. License: MIT
3. README
4. SamurAIGPT/llm-wiki-agent on GitHub