SQLBot : le Text-to-SQL qui s'installe en une commande Docker, sous licence FIT2CLOUD

Le problème : écrire du SQL pour des gens qui ne l'écrivent pas

Un analyste métier qui veut savoir combien de commandes ont été annulées le mois dernier dépend aujourd'hui de quelqu'un d'autre. Soit il attend qu'un data analyst écrive la requête, soit il apprend le schéma de la base. SQLBot attaque ce point précis : l'utilisateur pose sa question en langage naturel, l'outil produit du SQL, l'exécute et renvoie un résultat tabulaire ou un graphique. Le README résume la promesse par « 对话式数据分析 » (analyse de données conversationnelle).

La cible est donc l'entreprise qui a déjà une base relationnelle exploitable et un LLM accessible par API, et qui veut donner un accès en lecture à des non-techniciens sans ouvrir un client SQL. Ce n'est pas un outil pour développeur qui veut générer du SQL dans son propre code : c'est une application complète, avec interface web, comptes utilisateurs et espaces de travail.

Ce que fait réellement le RAG dans la chaîne

Le README ne détaille pas l'architecture interne, mais il nomme les briques qui composent le mécanisme. Le schéma de la section « 工作原理 » (principe de fonctionnement) montre une chaîne qui part de la question utilisateur, passe par le modèle, et revient avec du SQL et une visualisation. Les éléments que l'outil ajoute autour du modèle sont identifiables dans le texte : une base de connaissances de type RAG, des invites personnalisables, un glossaire de termes métier et une bibliothèque d'exemples SQL servant à calibrer la génération.

C'est là que se joue la différence avec un simple appel à un LLM. Un modèle seul ne connaît ni vos noms de tables, ni vos abréviations internes, ni la convention qui distingue un statut annulé d'un statut remboursé. SQLBot injecte ces éléments dans le contexte avant la génération. La conséquence pratique est contre-intuitive : la qualité des réponses dépend moins du modèle choisi que de la propreté du glossaire et des exemples SQL que vous alimentez. Le README parle d'un effet qui « 越问越准 » (s'améliore à mesure qu'on l'interroge), ce qui suppose une boucle d'exploitation : quelqu'un doit traiter les questions mal comprises et enrichir la base. Sans cette personne, l'outil plafonne au niveau de son contexte initial.

Déploiement : une commande, cinq volumes, deux ports

L'installation documentée tient en une commande Docker, avec PostgreSQL embarqué. Le conteneur expose 8000 et 8001, et monte cinq volumes : ./data/sqlbot/excel, ./data/sqlbot/file, ./data/sqlbot/images, ./data/sqlbot/logs et ./data/postgresql. L'option --privileged=true est présente dans l'exemple du README, ce qui accorde au conteneur des capacités étendues sur l'hôte. Sur une machine dédiée à l'outil, c'est un choix de confort. Sur un serveur qui héberge autre chose, c'est le premier point à retirer ou à restreindre, le README ne justifiant pas cette option.

L'accès se fait ensuite sur http://<IP>:8000/ avec le couple admin / SQLBot@123456. Ces identifiants sont publics et documentés : les changer fait partie des premières minutes d'exploitation, pas des bonnes pratiques à planifier. Pour un environnement isolé, le projet renvoie vers un paquet d'installation hors ligne hébergé sur community.fit2cloud.com, et vers le magasin d'applications 1Panel comme voie de déploiement alternative. Le choix du fournisseur de modèle se fait dans l'interface : la documentation liste une compatibilité OpenAI pour Alibaba Bailian, Qianfan, DeepSeek, Hunyuan, iFlytek Spark, Gemini, Kimi, Tencent Cloud, Volcano Engine et MiniMax, OpenAI en natif, et une entrée « OpenAI compatible » personnalisée. Tout fournisseur qui expose une API compatible OpenAI a donc une porte d'entrée, mais le README ne précise pas quelles fonctions avancées (appels d'outils, sorties structurées) sont réellement utilisées par la chaîne de génération.

Isolation par espace de travail : la vraie fonctionnalité d'administration

Le README met en avant une isolation des ressources au niveau de l'espace de travail et une configuration fine des permissions de données. C'est le point qui distingue un outil déployable en entreprise d'un prototype. Une base de données d'entreprise contient rarement un seul public : les ventes ne doivent pas interroger les tables de paie, et une filiale ne doit pas voir les marges du groupe. Si cet isolement se fait au niveau de l'espace de travail, alors un même déploiement peut servir plusieurs populations avec des périmètres de tables distincts.

La formulation reste cependant générale. Le README ne décrit ni le modèle de rôles, ni la granularité exacte (table, colonne, ligne), ni la manière dont les permissions sont appliquées au moment de l'exécution du SQL généré. C'est la zone la plus floue de la documentation, et c'est précisément celle qu'un responsable sécurité voudra vérifier en premier. Un mécanisme d'isolation mal compris donne une fausse impression de cloisonnement, ce qui est plus dangereux que pas d'isolation du tout.

Quand SQLBot n'est pas le bon outil

Le cas défavorable le plus net est celui de la base dont le schéma n'est pas documenté. La chaîne repose sur du contexte : glossaire, exemples SQL, descriptions. Sur une base de trente tables aux noms cryptiques et sans commentaires, l'outil produira des requêtes plausibles et fausses. Une jointure oubliée ne lève pas d'erreur, elle renvoie un chiffre. Le README ne mentionne aucun mécanisme de validation sémantique du résultat, et on ne peut pas affirmer depuis ce matériel qu'il en existe un.

Deuxième cas : l'intégration dans un service existant. SQLBot est une application, pas une bibliothèque. Le README cite des modes d'intégration (Web embarqué, fenêtre modale, appel MCP) et des cibles comme n8n, Dify, MaxKB et DataEase. Si votre besoin est d'appeler une fonction depuis votre backend, ces modes supposent de toute façon un déploiement SQLBot à côté. Troisième cas : les requêtes à enjeu financier ou réglementaire, où un SQL faux coûte plus cher qu'un SQL absent. L'outil n'annonce pas de garde-fou de ce type.

Ce qui change par rapport à un cadre Text-to-SQL générique

La comparaison utile n'est pas avec un autre produit, mais avec l'approche par cadre applicatif : une bibliothèque comme LangChain ou un pipeline maison qui envoie le schéma au modèle et exécute la requête retournée. Dans cette approche, vous contrôlez chaque étape, vous branchez votre propre système d'authentification, et vous n'ajoutez aucune dépendance lourde. En contrepartie, vous écrivez vous-même la gestion des espaces, la persistance des conversations, la bibliothèque d'exemples et l'interface.

SQLBot prend le chemin inverse : il fige ces choix et les livre déjà faits. Vous récupérez une application complète avec comptes, espaces, permissions, intégrations et paquet hors ligne, au prix d'une stack à héberger (le conteneur embarque PostgreSQL) et d'une licence qui n'est pas une licence open source standard. La différence n'est donc pas une question de qualité de génération, mais de répartition du travail : à vous de construire, ou à vous d'exploiter.

Licence FIT2CLOUD : GPLv3 avec deux clauses qui comptent

Le dépôt est marqué NOASSERTION par l'outil d'analyse, et le README renvoie vers un fichier LICENSE nommé FIT2CLOUD Open Source License. Le texte précise que cette licence est essentiellement GPLv3, avec des restrictions supplémentaires. Deux clauses sont énoncées : interdiction de remplacer ou modifier le logo et les mentions de copyright de SQLBot, et obligation pour les œuvres dérivées de respecter les obligations d'ouverture de GPLv3.

La première clause est celle qui surprend dans un contexte commercial. Un déploiement en marque blanche, où l'on souhaite retirer les références à SQLBot de l'interface, se heurte directement à cette interdiction. La seconde signifie qu'une modification du code, si elle est distribuée, doit être publiée sous GPLv3. Une utilisation strictement interne, sans distribution, n'est pas traitée par le README : c'est une question à poser à un juriste, pas à trancher ici. Je ne donne pas d'avis juridique, et le fichier LICENSE complet n'est pas dans le matériel fourni.

Versionnage et coût de maintenance

Trois versions sont listées : v1.9.0 en juin 2026, v1.10.0 en juillet, v1.10.1 en août. Le rythme est mensuel, ce qui implique des mises à jour régulières si vous suivez les correctifs. La branche par défaut est main et le dépôt n'est pas archivé.

Le coût réel ne se situe pas dans la mise à jour du conteneur, mais dans deux postes que le README rend visibles sans les chiffrer. Le premier est le coût par requête du fournisseur de modèle : chaque question consomme des jetons, et le contexte injecté (schéma, glossaire, exemples) pèse sur ce volume. Le second est le travail d'exploitation de la base de connaissances. Le README décrit une amélioration progressive liée aux données d'interaction ; cela suppose une personne qui consulte les questions mal servies, corrige les exemples SQL et met à jour le glossaire. Sans ce rôle attribué, la qualité ne progresse pas d'elle-même. La persistance repose sur le volume ./data/postgresql : c'est lui qui porte l'historique et la configuration, et c'est lui qu'il faut sauvegarder.

Conclusion éditoriale

SQLBot convient aux équipes qui veulent une couche de question-réponse SQL posée au-dessus d'un entrepôt existant, avec un LLM accessible par API compatible OpenAI et un déploiement Docker maîtrisé. Il ne convient pas à qui cherche une bibliothèque à intégrer dans un service existant, ni à qui refuse les contraintes de la licence FIT2CLOUD. Avant de l'adopter, vérifiez trois points dans cet ordre : la compatibilité exacte de votre fournisseur avec le mode OpenAI, la politique de rétention de vos schémas et de vos exemples SQL, et la clause de conservation du logo et des mentions de copyright.

Sources officielles

1. dataease/SQLBot on GitHub
2. Issues
3. Project website
4. README
5. Releases