Wanwu : une plateforme d'agents multi-tenant pour équipes FDE, vue depuis son dépôt

Le problème visé : livrer un projet IA chez le client, pas prototyper

Le README ne présente pas Wanwu comme un framework destiné aux développeurs qui veulent écrire un agent en quelques lignes. Il le présente comme une plateforme destinée aux Forward Deployed Engineers, ces ingénieurs qui installent et adaptent une solution directement dans les systèmes du client. Le vocabulaire employé est celui de la livraison : combler le dernier kilomètre entre la construction et la mise en production. Les cinq capacités mises en avant (RAG, ontologie, workflow, GUI, agent généraliste) correspondent à cinq obstacles classiques d'un déploiement en entreprise : des documents dispersés, des données structurées que le modèle ne lit pas, des processus métier à respecter, des applications anciennes sans API, et un besoin d'interaction en langage naturel. Le public visé n'est donc pas une équipe produit qui construit sa propre stack, mais une équipe d'intégration qui doit rendre quelque chose de fonctionnel sur le site du client, avec des contraintes de conformité et de permissions. C'est une distinction importante : elle explique pourquoi la plateforme est multi-tenant et pourquoi elle propose une interface visuelle avant de proposer une bibliothèque.

RAG et GraphRAG : ce que la documentation détaille, et ce qu'elle ne chiffre pas

Le module RAG est celui qui reçoit le plus de détails dans le README. Il annonce la prise en charge de 12 formats de fichiers, le crawling d'URL, l'OCR, un déploiement privé du modèle MinerU, une recherche multimodale, un découpage en cascade ou adaptatif, un classement intelligent et la citation des sources. S'y ajoute UniAI-GraphRAG, présenté comme un composant intégré avec modélisation d'ontologie de domaine, destiné aux résumés multi-documents et au raisonnement à plusieurs sauts. Le README affirme un score F1 de premier plan dans le secteur, sans fournir de jeu de données, de protocole ni de référence comparative. Cette affirmation n'est pas vérifiable à partir du dépôt seul, et il faut la traiter comme une revendication marketing tant qu'aucun banc d'essai n'est publié. Un point concret mérite l'attention : la compatibilité avec des bases de connaissances créées dans Dify, importées par API pour être utilisées dans les agents, le chat et les workflows. C'est un choix pragmatique. Il reconnaît qu'une entreprise a souvent déjà des bases Dify en place et évite d'imposer une migration complète avant de pouvoir évaluer Wanwu. Cela crée aussi une dépendance de fait à un format externe, dont le dépôt ne précise pas la stabilité dans le temps.

Workflow, ontologie et agent GUI : trois réponses à trois contraintes différentes

Le module Workflow propose une orchestration visuelle en low-code avec des branches conditionnelles, des appels d'API, des LLM, des bases de connaissances, du code et du MCP. Le README mentionne un débogage de bout en bout et une analyse de performance, sans décrire le format de définition des workflows ni la façon dont ils sont versionnés. C'est une lacune pour une équipe qui veut mettre ces graphes sous Git. Le module Ontology s'attaque aux données structurées : il construit automatiquement un réseau de connaissances métier à partir des données et documents de l'entreprise, pour passer du questions-réponses à l'analyse métier. La documentation reste ici très générale : aucune indication sur les sources de données supportées, sur la façon dont le graphe est interrogé, ni sur la charge de maintenance quand le schéma source change. Le module GUI est le plus singulier. Il permet à l'IA d'opérer des interfaces applicatives sans API sous-jacente, avec un conteneur Docker isolé par bot pour exécuter les opérations d'interface. Le client GUI n'est pas dans le dépôt : il est distribué via un lien Baidu Pan, avec un mot de passe. Pour un projet Apache-2.0, ce détail compte, car il signifie qu'une partie de la chaîne de livraison échappe au dépôt public et à son processus de publication.

Mise en route : ce que le README donne, et ce qu'il faut aller chercher soi-même

Le README structure sa prise en main autour de trois méthodes de déploiement plutôt que d'une séquence de commandes. La première est l'usage direct de la plateforme via son interface visuelle, sans code, pour créer agents, workflows et systèmes de questions-réponses. La deuxième est l'intégration par API RESTful, décrite comme un BaaS destiné à être embarqué dans un OA, un CRM ou un ERP, avec un contrôle fin des permissions. La troisième est la combinaison d'un Skill et du client dédié UniClaw, pour les scénarios à privilèges élevés comme le contrôle d'un PC local ou l'envoi de messages DingTalk. Le badge du dépôt indique Go supérieur ou égal à 1.24.0, ce qui fixe une contrainte de version pour la compilation. En revanche, le README nettoyé fourni ici ne contient ni commande docker compose, ni nom de fichier de configuration, ni clé de configuration, ni variable d'environnement. Toute personne qui veut auto-héberger la plateforme devra donc lire le dépôt lui-même pour trouver le fichier compose, les valeurs par défaut et l'ordre de démarrage des services. Je ne peux pas décrire cette procédure sans l'inventer. C'est la principale zone d'ombre du projet pour un lecteur qui arrive par la page GitHub.

Multi-tenant, permissions et le coût réel d'exploitation

La plateforme est décrite comme multi-tenant et destinée aux scénarios d'entreprise. Le README mentionne un contrôle fin des permissions pour l'intégration API, mais ne détaille pas le modèle d'isolation : les tenants partagent-ils une base de données, les index vectoriels sont-ils séparés, comment les quotas par tenant sont-ils appliqués. Ces questions déterminent pourtant si la plateforme convient à un hébergement mutualisé entre plusieurs clients ou si elle doit être déployée une instance par client. Le rythme de publication donne un autre indice sur le coût de suivi : trois versions entre juillet et septembre 2026, avec v0.6.4 le 4 septembre 2026. Un rythme de versions mineures aussi rapproché suggère une phase de stabilisation encore active. Pour une équipe qui exploite la plateforme en production, cela implique de prévoir un cycle de mise à jour régulier et de vérifier à chaque fois les migrations de schéma, que le README ne décrit pas. La licence Apache-2.0 est permissive : elle autorise l'usage commercial, la modification et la redistribution, avec conservation des mentions de copyright et du texte de licence, et elle inclut une clause de brevets. Elle n'impose aucune obligation de publier vos modifications. Ce n'est pas un avis juridique : si vous redistribuez la plateforme modifiée, faites valider la notice et les fichiers de licence par votre service compétent, et vérifiez séparément le régime du client GUI, distribué hors dépôt.

Quand Wanwu n'est pas le bon outil

Wanwu est une plateforme, pas une bibliothèque. Si votre besoin est d'appeler un modèle et d'enchaîner quelques outils dans un service que vous contrôlez entièrement, l'adopter revient à hériter d'une interface visuelle, d'un modèle multi-tenant et d'un ensemble de services à maintenir dont vous n'utiliserez qu'une fraction. Le coût d'exploitation se paie en surface de composants, pas en lignes de code écrites. Le module GUI illustre une autre limite : il fonctionne par vision et clics sur des interfaces, avec des conteneurs Docker isolés par bot. Cette approche est puissante pour les systèmes sans API, mais elle reste fragile face aux changements d'interface, et le README ne décrit ni la gestion des échecs de clic, ni les mécanismes de reprise. Enfin, la documentation actuelle ne permet pas de juger le module Ontology sur pièce : trop peu de détails sur les connecteurs et sur la construction du graphe pour évaluer sa charge de maintenance. Une équipe dont le besoin principal est l'analyse de données structurées devrait demander une démonstration ciblée avant de s'engager.

Face à Dify : deux approches de la même case

Le README mentionne Dify explicitement, mais pas comme concurrent : comme source de bases de connaissances importables par API. La différence d'approche est réelle. Dify se présente comme une plateforme de construction d'applications LLM, avec une communauté large et un déploiement documenté. Wanwu se positionne en amont de la livraison, avec un discours centré sur l'ingénieur FDE, les privilèges élevés et l'opération d'interfaces sans API. La compatibilité annoncée signifie qu'un import depuis Dify est possible, pas que les deux plateformes sont interchangeables : les agents, workflows et permissions ne sont pas transférables. Si vous avez déjà des bases Dify en production, Wanwu peut les consommer sans migration, ce qui réduit le coût d'un essai. Si votre besoin est un écosystème d'applications LLM avec un grand nombre d'intégrations tierces, l'argument de Wanwu porte surtout sur les modules GUI et ontologie, qu'il faut évaluer séparément.

Conclusion éditoriale

Wanwu vise les équipes FDE qui livrent chez le client et doivent couvrir RAG, workflow et opérations GUI dans un seul déploiement. À éviter si vous cherchez un framework minimal à intégrer dans votre propre code : la valeur annoncée tient à la plateforme complète, pas à une bibliothèque. Avant tout essai, vérifiez la procédure de démarrage réelle du dépôt (docker compose, variables d'environnement, schéma de base) et le sort des composants non couverts par Apache-2.0, notamment le client GUI distribué hors dépôt.

Sources officielles

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. UnicomAI/wanwu on GitHub