WeKnora : la plateforme RAG de Tencent qui ajoute un agent ReAct et un Wiki auto-maintenu
Open-source LLM knowledge platform: turn raw documents into a queryable RAG, an autonomous reasoning agent, and a self-maintaining Wiki.
En bref
- De quoi s’agit-il ?
- WeKnora transforme des documents bruts en base interrogeable, en agent capable d'enchaîner des outils et en wiki markdown. Le point délicat n'est pas la récupération, c'est la gouvernance des bacs à sable et des locataires.
- À qui s’adresse-t-il ?
- WeKnora convient aux équipes qui auto-hébergent déjà une infrastructure conteneurisée et qui ont besoin de cloisonner plusieurs espaces de travail, avec un catalogue de compétences et des bacs à sable persistants par locataire. Il ne convient pas à qui veut un index vectoriel minimal branché sur une bibliothèque de documents : la surface de configuration (fournisseurs LLM, backends de stockage, politiques réseau des bacs à sable, RBAC) dépasse largement le besoin.
- Puis-je l’utiliser commercialement ?
- À vérifier. La licence de ce dépôt n’entre pas dans les catégories que nous classons automatiquement : lisez son fichier LICENSE avant tout usage commercial.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement Go, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un problème de cloisonnement autant que de récupération
La récupération augmentée n'est plus un problème difficile à résoudre seul. Le problème que WeKnora attaque est ailleurs : une organisation dispose de documents dispersés, veut les interroger, mais doit aussi garantir que le service juridique ne lit pas les fichiers du service RH, et que chaque équipe peut brancher son propre modèle sans contaminer les autres. Le README décrit une matrice RBAC à quatre niveaux, une propriété par ressource et un journal d'audit par espace de travail. C'est cette couche, plus que le pipeline d'embedding, qui définit la cible.
Le public visé est donc une équipe plateforme interne, pas un développeur isolé. Le dépôt est écrit en Go, ce qui oriente le profil : compilation unique, déploiement binaire, peu de dépendances d'exécution côté serveur. Le README mentionne un backend de stockage multi-instance par espace de travail, ce qui suppose que quelqu'un assume la responsabilité de placer les données au bon endroit et de le documenter.
Troisième capacité revendiquée, le Wiki Mode : les agents distillent les documents bruts en une base markdown liée, avec graphe de connaissances interactif, édition manuelle, historique de révisions et retour arrière en un clic. C'est un choix éditorial fort. Une documentation générée puis modifiable à la main devient une source de vérité, avec les obligations de revue que cela implique.
Ce qui se passe entre le dépôt d'un fichier et la réponse
Le README décrit trois modes qui partagent la même ingestion. Les documents arrivent par téléversement ou par synchronisation depuis Feishu, GitLab, Tencent IMA, Notion, Yuque ou RSS. Le format est détecté, les fichiers Office passant par anydoc, un analyseur intégré au processus. Le texte est découpé en chunks, vectorisé, puis indexé.
La différence entre les trois modes tient à qui décide de la suite. En Q&A rapide, une requête déclenche une recherche sémantique, éventuellement un reranking, et le modèle répond. En mode agent, un agent ReAct orchestre lui-même la récupération, les appels d'outils MCP, la recherche web (Exa, Metaso selon les notes de version) et l'exécution de code dans un bac à sable, sur plusieurs étapes. En mode Wiki, la sortie n'est pas une réponse mais une page markdown persistée, avec snapshots et diff au niveau des lignes.
Deux mécanismes méritent l'attention. D'abord la compaction de contexte et les marqueurs de cache de prompt par fournisseur, mentionnés en v0.8.0 : sur une boucle ReAct longue, la fenêtre de contexte est le facteur limitant réel, pas la qualité du retrieval. Ensuite la mémoire longue durée inter-sessions, qui extrait profil, préférences, faits, tâches et centres d'intérêt, avec confirmation avant enregistrement et une fonction search_memory. Le fait que l'extraction demande une confirmation est un signe que l'équipe a rencontré le cas où un agent mémorise une information fausse et la ressert des mois plus tard.
Le catalogue de compétences et ses bacs à sable
C'est la partie la plus structurante de la v0.8.0. Un espace de travail dispose d'un catalogue de compétences installables depuis ClawHub, SkillHub, git ou une archive zip. Chaque compétence s'exécute dans un bac à sable avec des instantanés propres, une progression en direct, la consultation et l'édition de fichiers, et des variables d'environnement personnelles ou partagées au niveau de l'espace de travail.
Trois backends sont proposés : Docker, E2B et Cube, avec une politique réseau par locataire. Le README indique que le backend Local host-process a été supprimé et que Docker est désormais optionnel, ce qui signifie que l'exécution de code arbitraire n'est plus possible directement sur l'hôte. C'est une décision de sécurité cohérente avec le discours multi-locataire, et elle a un coût : il faut une couche d'orchestration de conteneurs disponible, avec les images correspondantes, la gestion des instantanés et la persistance de session entre deux appels d'outil.
La politique réseau par locataire est le détail qui compte. Un agent qui exécute du code et peut atteindre le réseau est une voie de sortie de données. Le fait que la politique soit paramétrable par espace de travail plutôt que globale montre que le modèle de menace est pris au sérieux. Le README ne détaille pas le format de cette politique dans l'extrait disponible, et c'est un point à vérifier dans la documentation produit avant de dimensionner le déploiement.
Mise en route : ce que la documentation donne
Le README renvoie à un site de documentation produit lancé en v0.7.2, construit avec VitePress, six sections et environ cinquante pages couvrant approximativement 360 points d'API et 150 variables d'environnement, avec un déploiement Docker/Nginx autonome, des données d'exemple pour le démarrage et une démo MCP locale. C'est là qu'il faut chercher les commandes d'installation : l'extrait de README fourni ne contient pas de bloc de démarrage, seulement des liens. Je ne peux donc pas citer de commande d'installation que je n'ai pas vue.
Deux éléments de configuration sont en revanche nommés explicitement. Le mode de chargement direct des fichiers passe par le paramètre de requête resource_urls=public ou par la variable d'environnement RESOURCE_URL_MODE. Il permet à une application tierce d'afficher images et fichiers sans second appel authentifié via un proxy. C'est pratique pour intégrer un widget, et cela veut dire que ces ressources deviennent accessibles à qui connaît l'URL. À traiter comme une décision de confidentialité, pas comme un réglage de performance.
Côté intégration, il existe un serveur MCP publié sur PyPI sous le nom tencent-weknora-mcp, une extension Chrome, une compétence ClawHub et un plugin officiel DeepSeek Harness publié sur npm sous @wxg-prc-cpg/dsh-weknora. Le README mentionne aussi des clés d'API à portée limitée avec un modèle de principal pour les intégrations programmatiques. Pour les fournisseurs de modèles, la liste annoncée couvre OpenAI, DeepSeek, Qwen, Zhipu, Hunyuan, Gemini, MiniMax, NVIDIA, LiteLLM et Ollama, soit plus de vingt intégrations.
Le cas où WeKnora est le mauvais outil
Si votre besoin se limite à indexer un dossier de PDF et à poser des questions en ligne de commande, WeKnora est surdimensionné. Le projet embarque une interface web, un système de révisions sur les chunks et sur les pages wiki, un tableau de bord de file de tâches avec gouvernance de pool de workers, une couche d'observabilité Langfuse, un RBAC à quatre niveaux et un catalogue de compétences. Chacun de ces composants est un composant à exploiter. Une alternative comme un index vectoriel local avec un script d'ingestion de quelques dizaines de lignes vous coûtera moins cher en maintenance et en surface d'attaque.
Le second cas défavorable est plus subtil. Le mode Wiki produit du markdown que des humains peuvent éditer, avec historique et retour arrière. Si votre organisation n'a pas de processus de revue sur la documentation interne, ce wiki va dériver : une page générée puis corrigée à la main cesse d'être reproductible depuis les sources, et la prochaine régénération écrase ou duplique le travail manuel. Le README décrit le retour arrière et le diff, pas la politique de réconciliation entre une page éditée et une source modifiée. C'est une lacune de conception à assumer.
Troisième réserve : l'exécution de code dans un bac à sable avec accès réseau, même avec une politique par locataire, reste une capacité à haut risque. La suppression du backend Local host-process montre que l'équipe en est consciente. Cela ne dispense pas de vérifier ce que la politique réseau autorise par défaut.
Comparer avec une approche par bibliothèque
La comparaison la plus utile n'est pas avec un autre produit complet, c'est avec une bibliothèque de pipeline comme LlamaIndex. Dans LlamaIndex, vous assemblez vous-même les briques : lecteurs de documents, découpeurs, index, moteurs de requête. Le contrôle est total, l'intégration se fait dans votre application, et il n'y a pas de service à héberger. En contrepartie, l'authentification, le cloisonnement par locataire, l'historique de révisions et l'interface d'administration sont à votre charge, ou n'existent pas.
WeKnora prend le chemin inverse. Le README présente une architecture modulaire où l'on remplace le LLM, la base vectorielle et le backend de stockage, mais cette modularité s'exerce à l'intérieur d'un cadre déjà décidé : espaces de travail, rôles, catalogue de compétences, bacs à sable. Vous gagnez les couches d'exploitation et vous héritez de leurs contraintes. Le choix se résume à ceci : préférez-vous écrire la plomberie multi-locataire, ou apprendre celle de quelqu'un d'autre et vivre avec ses limites ?
Un point de comparaison concret : le mode agent. Une bibliothèque vous donne une abstraction de boucle ReAct et vous laissez le soin de brancher les outils. WeKnora fournit un catalogue de compétences installables, des variables d'environnement par espace de travail et des instantanés par bac à sable. C'est plus rapide à mettre en service pour une équipe plateforme, et beaucoup plus difficile à déboguer quand une compétence échoue, puisque la chaîne traverse le catalogue, le bac à sable et la politique réseau.
Licence et coût de maintenance
Le badge du README affiche MIT et renvoie vers le fichier LICENSE du dépôt. L'API GitHub renvoie pourtant NOASSERTION, ce qui signifie que l'outil n'a pas su classer la licence automatiquement. Ce n'est pas nécessairement un problème, mais c'est une incohérence à lever avant de distribuer le logiciel dans un produit. Lisez le fichier LICENSE et le CHANGELOG pour repérer d'éventuelles mentions de composants tiers sous d'autres termes. Je ne donne pas d'avis juridique ici, seulement le constat que deux sources du même dépôt ne disent pas la même chose.
Le rythme de publication est soutenu : v0.8.0 le 3 septembre 2026, v0.7.2 le 7 août, v0.7.1 le 24 juillet. Sur un peu plus d'un mois, trois versions, dont une majeure qui supprime un backend d'exécution et en introduit deux autres. Ce rythme a une conséquence directe : une mise à jour mineure peut changer la façon dont les compétences s'exécutent. Si vous épinglez une version, vous vous coupez des correctifs de sécurité sur les bacs à sable. Si vous suivez la branche principale, vous absorbez des ruptures de configuration.
Le coût de maintenance réel se situe dans les dépendances externes, pas dans le code Go. Le README cite Langfuse pour l'observabilité, E2B et Cube comme backends de bac à sable, plus de vingt fournisseurs de modèles, et des sources de données dont la liste s'allonge. Chacune de ces intégrations est un point de rupture potentiel lors d'une montée de version. La documentation produit annonce environ 150 variables d'environnement : c'est le chiffre à garder en tête quand vous estimez le temps d'exploitation.
Conclusion éditoriale
WeKnora convient aux équipes qui auto-hébergent déjà une infrastructure conteneurisée et qui ont besoin de cloisonner plusieurs espaces de travail, avec un catalogue de compétences et des bacs à sable persistants par locataire. Il ne convient pas à qui veut un index vectoriel minimal branché sur une bibliothèque de documents : la surface de configuration (fournisseurs LLM, backends de stockage, politiques réseau des bacs à sable, RBAC) dépasse largement le besoin. Avant toute adoption, vérifiez trois points précis : la mention NOASSERTION renvoyée par l'API GitHub alors que le badge du README annonce MIT, la présence réelle de cgo et des dépendances système nécessaires à anydoc dans votre chaîne de build, et le fait que le backend Local host-process a été retiré en v0.8.0 au profit de Docker, E2B ou Cube, ce qui conditionne votre plan de déploiement.
Notes de la communauté