XIAOJUSURVEY : ce que le dépôt didi/xiaoju-survey couvre réellement
XIAOJUSURVEY is an enterprises form builder and analytics platform that allows users to create questionnaires, exams, polls, quizzes, and analyze data online.
En bref
- De quoi s’agit-il ?
- Un système de questionnaires open source publié par Didi, empilant Vue3 et NestJS autour d'un protocole de méta-données maison. La promesse est large, la documentation l'est moins.
- À qui s’adresse-t-il ?
- XIAOJUSURVEY convient aux équipes qui acceptent la pile imposée Vue3 plus NestJS plus MongoDB et qui veulent un cycle complet création, diffusion, collecte et analyse sans assembler cinq outils. Il ne convient pas à qui veut brancher un backend existant en Java ou en Python, ni à qui a besoin de garanties de conformité documentées noir sur blanc.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 58 jours.
- En quel langage est-il écrit ?
- Principalement TypeScript, 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
Le problème visé : arrêter de recoller un éditeur, un moteur de règles et un tableau de bord
Monter une enquête sérieuse demande en général trois briques distinctes : un éditeur de formulaires, un moteur qui applique les règles d'affichage et de saut, et une couche d'analyse. Chacune a ses formats, ses exports, ses limites. XIAOJUSURVEY se présente comme une réponse intégrée à ce découpage. Le README annonce une couverture du cycle de vie complet, de la création à l'analyse en passant par la diffusion, avec gestion des utilisateurs, des espaces et des permissions. La cible affichée est double : équipes internes qui veulent un outil hébergé chez elles, et éditeurs qui veulent construire une offre verticale à partir du socle.
Le projet revendique un usage interne chez Didi et un passage à l'échelle sur des volumes importants. Ces chiffres viennent du README et ne sont pas vérifiables depuis le dépôt seul. Ce qui est vérifiable, c'est l'orientation : il ne s'agit pas d'une bibliothèque de rendu de formulaire à intégrer dans une application existante, mais d'une application complète avec un serveur, une base et deux interfaces. Ce choix ferme certaines portes et en ouvre d'autres.
Le Meta comme colonne vertébrale, et pourquoi cela complique l'adoption
L'élément structurant n'est pas l'interface, c'est le protocole. Le README décrit une séparation en deux familles : les accords de description métier (protocole de questionnaire, protocole de type de question) et les accords de description de matériaux (matériau de type de question, incluant le type et son configurateur). Autrement dit, une question n'est pas un composant React ou Vue isolé : c'est un objet de données conforme à un schéma, accompagné d'un configurateur qui sait l'éditer.
Cette conception a une conséquence pratique directe. Ajouter un type de question ne consiste pas à écrire un composant et à l'enregistrer dans un registre. Il faut produire un matériau conforme, avec sa partie rendu et sa partie configuration, et respecter le protocole pour que l'éditeur et le moteur de rendu restent cohérents. Le README insiste sur la « cohérence élevée » entre le moment où l'on construit et le moment où l'on affiche, ce qui est précisément le problème que ce découpage cherche à résoudre : sans schéma commun, l'aperçu dans l'éditeur finit par diverger du rendu réel.
Le coût est réel. Toute équipe qui veut un type de question très spécifique, une grille de notation particulière ou un format de réponse propriétaire devra passer par ce protocole. C'est un investissement initial plus lourd qu'un simple composant, en échange d'une intégration propre dans l'éditeur, l'aperçu, la logique conditionnelle et l'analyse. Si votre besoin se limite à un formulaire statique de dix champs, ce mécanisme est surdimensionné.
La pile imposée : Vue3, NestJS, MongoDB
Le README est explicite sur les choix techniques. Côté navigateur, Vue3 avec ElementPlus. Côté serveur, NestJS avec MongoDB. Un SDK multi-plateforme est mentionné, construit sur React Native. La génération de questionnaires par LLM est présentée comme une capacité d'enrichissement, avec une intégration à un modèle de langage en une étape selon la formulation du README.
Il faut mesurer ce que cela implique. Une équipe dont le socle est Java ou Python ne pourra pas réutiliser XIAOJUSURVEY comme simple service : le serveur est en TypeScript, et la logique de collecte, de permissions et d'analyse vit dedans. Adopter le projet revient à héberger et maintenir une application NestJS supplémentaire, avec sa base MongoDB. Le README mentionne des sujets d'entreprise comme l'intégration par Hook personnalisé pour pousser des données ou des messages vers d'autres systèmes, mais la nature exacte de ces points d'extension n'est pas détaillée dans le matériel fourni.
La mention de React Native pour le SDK interroge. Elle suggère qu'une partie du rendu a été pensée pour du natif, ce qui implique une seconde base de code à suivre en parallèle du rendu web. Le README ne dit pas si cette partie est publiée sur un registre de paquets, ni comment elle est versionnée. C'est un point à vérifier avant de compter dessus.
Démarrer en local : deux dossiers, deux commandes
Le README donne la séquence locale sans détour. Pour le serveur, on entre dans le dossier server, on lance npm install, puis npm run local. Pour l'interface, on entre dans web, on relance npm install, puis npm run serve. Les deux points d'entrée sont ensuite indiqués : http://localhost:8080/management pour l'interface d'administration, et http://localhost:8080/render/:surveyPath pour le rendu destiné aux répondants.
La prérequis de version est visible dans les badges du README : Node 18 ou supérieur. Rien dans le matériel fourni ne décrit la configuration MongoDB attendue en local, ni la présence d'un fichier d'environnement à renseigner. C'est une lacune documentaire à combler en lisant le manuel d'installation lié depuis le README, que je n'ai pas consulté.
Pour le déploiement, la voie proposée est Docker. Deux images sont annoncées : xiaojusurvey/xiaoju-survey:latest-slim, basée sur node:18-slim, décrite comme adaptée à la production avec un minimum de dépendances, et xiaojusurvey/xiaoju-survey:latest-full, basée sur node:18, qui embarque curl, vim et git pour le débogage. Le changement se fait en modifiant le tag de l'image dans docker-compose.yaml. Cette distinction est utile : embarquer git et vim dans une image de production n'a rien d'anodin en termes de surface d'attaque, et le README a raison de séparer les deux.
Ce que la documentation ne tranche pas
Le README renvoie massivement vers le site xiaojusurvey.didi.cn pour le fond : manuel produit, protocole Meta, spécifications d'interface, principes de conception, manuel de développement, guide de déploiement. Autrement dit, le dépôt GitHub sert de point d'entrée, pas de documentation. Pour un évaluateur, cela signifie que juger le projet sur le README seul est insuffisant et que le contenu réel des engagements se trouve ailleurs.
Plusieurs points restent flous dans le matériel fourni. La section sécurité annonce du chiffrement en transit, une détection de mots sensibles et une protection anti-fraude sur les votes. Aucun de ces mécanismes n'est décrit techniquement ici : on ne sait pas où s'applique le chiffrement, ni comment la liste de mots sensibles est alimentée, ni sur quel critère un vote est considéré comme suspect. Pour un usage en entreprise, ce sont exactement les questions à poser avant de s'engager.
Le volet intelligence artificielle est mentionné en une ligne, avec une intégration LLM présentée comme immédiate. Aucun détail sur le fournisseur, le format d'appel ou la gestion des clés n'apparaît dans le README. Traiter cette fonctionnalité comme acquise serait imprudent.
L'alternative naturelle : un moteur de formulaires générique plutôt qu'une application complète
La différence avec un projet comme SurveyJS ne porte pas sur le nombre de types de questions, mais sur la nature de la livraison. SurveyJS se présente comme une bibliothèque de rendu et d'édition de formulaires, avec un schéma JSON comme format pivot, à intégrer dans une application que vous possédez déjà. Vous gardez votre backend, votre authentification, votre base. XIAOJUSURVEY livre l'application entière : éditeur, serveur NestJS, MongoDB, gestion des utilisateurs et des espaces, analyse intégrée.
Le partage est clair. Avec une bibliothèque, vous contrôlez chaque couche et vous payez en intégration. Avec XIAOJUSURVEY, vous obtenez un produit fonctionnel en échange de l'acceptation d'une pile et d'un modèle de données. Le protocole Meta de XIAOJUSURVEY joue un rôle comparable au schéma JSON d'une bibliothèque, mais il est propre au projet et couvre aussi la partie configuration et analyse, ce qu'un simple schéma de rendu ne fait pas.
Un point mérite d'être noté : le README positionne explicitement le projet comme un socle pour construire une offre verticale, pas comme un composant. Si votre besoin est d'ajouter un éditeur d'enquête à une application existante en conservant votre backend, la bibliothèque générique sera presque toujours le bon choix. Si votre besoin est de disposer d'un outil complet auto-hébergé avec analyse incluse, l'arbitrage s'inverse.
Coût de maintenance et cadre de licence
La licence est Apache-2.0, ce qui autorise l'usage commercial, la modification et la redistribution, avec conservation des mentions de copyright et des brevets concédés. Le README ne signale aucune clause additionnelle, aucun fichier de licence séparé pour un composant, et aucune mention d'un modèle de licence commerciale parallèle. Je ne suis pas juriste et ce paragraphe ne constitue pas un avis juridique : pour un déploiement en entreprise, la vérification des dépendances tierces embarquées dans les images Docker reste nécessaire.
Sur la maintenance, les informations disponibles sont limitées. Le dépôt n'est pas archivé et le dernier push est daté du 20 juillet 2026. Aucune release taguée n'a été récupérée. C'est un point concret : sans release, le suivi de version repose sur les commits de la branche main, ce qui complique la mise à jour contrôlée et la reproduction d'un environnement. Le README mentionne un fichier MAJOR CHANGELOG hébergé dans une issue GitHub, ce qui est un emplacement inhabituel pour un journal de versions et le rend difficile à parcourir.
Le coût d'exploitation se compose de trois postes : maintenir une application Node 18 ou plus avec son MongoDB, suivre les évolutions du protocole Meta si vous avez écrit des matériaux de type de question personnalisés, et gérer la mise à jour des images Docker. Le second poste est le plus sous-estimé : un matériau conforme au protocole peut devoir être retouché lors d'un changement de schéma, et rien dans le matériel fourni n'indique qu'une politique de compatibilité soit documentée.
Conclusion éditoriale
XIAOJUSURVEY convient aux équipes qui acceptent la pile imposée Vue3 plus NestJS plus MongoDB et qui veulent un cycle complet création, diffusion, collecte et analyse sans assembler cinq outils. Il ne convient pas à qui veut brancher un backend existant en Java ou en Python, ni à qui a besoin de garanties de conformité documentées noir sur blanc. Avant de vous engager, vérifiez trois choses concrètes : le contenu réel du fichier docker-compose.yaml et le choix entre latest-slim et latest-full, la forme exacte du Meta tel que décrit dans la page de protocole, et la disponibilité d'une release taguée, puisque aucune n'apparaît dans les informations du dépôt.
Notes de la communauté