DB-GPT : l'assistant de données agentique qui écrit son propre SQL
open-source agentic AI data assistant for the next generation of AI + Data products.
En bref
- De quoi s’agit-il ?
- DB-GPT est un assistant de données open source sous licence MIT qui connecte bases, fichiers CSV/Excel et bases de connaissances, puis laisse un agent écrire le SQL et le code d'analyse. Le point à trancher : à qui profite réellement l'exécution en bac à sable, et à quel prix.
- À qui s’adresse-t-il ?
- Adoptez DB-GPT si vous voulez un assistant SQL et code auto-hébergé qui relie plusieurs sources et exécute des skills réutilisables dans un environnement isolé. Écartez-le si vous cherchez un simple client SQL ou un entrepôt managé : ici tout passe par un agent, et l'isolation du bac à sable est votre seule barrière.
- Puis-je l’utiliser commercialement ?
- Oui. MIT 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. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement Python, 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 : la question métier qui finit en ticket SQL
Une question simple sur un chiffre d'affaires par région mobilise aujourd'hui trois personnes : celle qui la pose, celle qui connaît le schéma, et celle qui sait écrire la requête. DB-GPT vise cet intervalle. Le README le présente comme un assistant qui connecte vos données, écrit le SQL et le code, exécute des skills en environnement isolé, et transforme l'analyse en rapports et en actions. La cible n'est donc pas le data engineer qui tape déjà ses jointures, mais l'équipe qui veut qu'une question en langage naturel aboutisse à une requête exécutée, puis à un graphique ou un rapport HTML. Le projet est en Python, publié sous licence MIT, avec une documentation sur docs.dbgpt.cn. La dernière version listée est la v0.8.2, datée du 26 août 2026, et le dépôt n'est pas archivé.
Ce que l'agent fait entre la question et le résultat
Le README décrit une boucle en quatre temps. D'abord l'exploration : fichiers, bases et bases de connaissances sont réunis dans un même espace de travail. Ensuite la planification : le modèle découpe la tâche, écrit le SQL et le code, puis exécute étape par étape. Vient l'étape des skills, ces paquets réutilisables qui encapsulent une méthode d'analyse ou un workflow métier. Enfin la restitution : graphiques, tableaux de bord, rapports HTML et synthèses. Deux briques techniques sont nommées explicitement : AWEL pour l'orchestration des workflows et RAG pour la partie documentaire. Le point d'architecture qui compte, c'est que l'exécution de code et d'outils se fait dans un environnement isolé. Autrement dit, le modèle ne se contente pas de proposer une requête : il la lance. Cette conception déplace le risque, elle ne le supprime pas. Un agent qui exécute du code sur vos données doit être traité comme un composant à privilèges, pas comme un champ de saisie.
Installation : une ligne, un profil, une clé
La mise en route passe par un script d'installation en une ligne, annoncé pour macOS et Linux. La commande de base est : curl -fsSL https://raw.githubusercontent.com/eosphoros-ai/DB-GPT/main/scripts/install/install.sh | bash. Le README donne aussi la variante avec profil et clé : curl -fsSL https://raw.githubusercontent.com/eosphoros-ai/DB-GPT/main/scripts/install/install.sh | OPENAI_API_KEY=sk-xxx bash -s -- --profile openai. Deux autres profils sont documentés, Kimi 2.5 via Moonshot avec MOONSHOT_API_KEY et --profile kimi, et MiniMax via une API compatible OpenAI avec MINIMAX_API_KEY et --profile minimax. Le script clone le dépôt dans ~/.dbgpt/DB-GPT, et le README indique qu'un checkout local existant peut être réutilisé au lieu de recloner. Ce mécanisme de profils est la vraie interface de configuration : c'est lui qui détermine le fournisseur de modèle, donc la qualité du SQL produit et la localisation des données envoyées. Le README ne détaille pas, dans l'extrait fourni, la structure des fichiers de configuration ni les variables au-delà des clés d'API.
Le bac à sable n'est pas un détail d'implémentation
Le README insiste sur l'exécution isolée, et c'est justifié. Un agent qui génère du Python pour nettoyer un jeu de données a accès, par construction, à tout ce que le processus peut atteindre. La documentation parle d'environnements isolés pour un travail plus sûr et plus fiable, sans préciser dans l'extrait disponible la technologie d'isolation employée ni les ressources allouées. C'est une lacune réelle : avant de laisser un agent écrire et exécuter du code sur des données clients, il faut savoir si l'isolation repose sur un conteneur, un sous-processus ou autre chose. Autre limite, plus structurelle : DB-GPT est un cadre d'orchestration. Sa valeur dépend du modèle branché derrière le profil. Un modèle faible produira des requêtes plausibles et fausses, et le bac à sable ne détectera pas une jointure erronée. C'est le mode de défaillance le plus probable en production, et il est silencieux.
Face à un client SQL classique ou à un notebook
L'alternative la plus directe pour un analyste reste le notebook : Jupyter, du Python, un pilote de base de données, et un assistant de complétion dans l'éditeur. La différence n'est pas la puissance de calcul, c'est la répartition de la décision. Dans un notebook, l'humain choisit chaque étape et voit chaque cellule avant de l'exécuter. Dans DB-GPT, l'agent planifie et enchaîne les étapes, avec un bac à sable comme garde-fou. Le notebook gagne sur l'auditabilité immédiate et sur le coût, puisque aucune infrastructure d'agent n'est nécessaire. DB-GPT gagne sur la répétabilité : un skill encapsule une méthode d'analyse une fois, et l'équipe la rejoue sans réécrire le raisonnement. Ce n'est pas un remplacement d'outil, c'est un changement de granularité : on versionne des workflows au lieu de cellules. Si votre besoin se limite à interroger une base avec une bonne autocomplétion, la seconde option est plus simple et moins risquée.
Maintenance, licence et coût de mise à jour
Le rythme de publication est soutenu : v0.8.0 en mars 2026, v0.8.1 en juin, v0.8.2 en août, avec un dernier push sur main en septembre 2026. Trois versions mineures en six mois, sur un projet qui intègre des fournisseurs de modèles multiples : cela implique de suivre les notes de version à chaque montée, en particulier quand un profil change de nom ou d'API. La licence MIT est permissive et n'impose pas de publier vos modifications, ce qui convient à un usage interne. Elle ne règle en revanche aucune question de conformité sur les données envoyées au fournisseur de modèle choisi via le profil d'installation, ni sur les skills tiers que vous importez. Le README montre une capture d'écran d'import de skill depuis GitHub : chaque skill importé est du code que votre agent exécutera. Ce point relève de votre politique interne, pas de la licence.
Conclusion éditoriale
Adoptez DB-GPT si vous voulez un assistant SQL et code auto-hébergé qui relie plusieurs sources et exécute des skills réutilisables dans un environnement isolé. Écartez-le si vous cherchez un simple client SQL ou un entrepôt managé : ici tout passe par un agent, et l'isolation du bac à sable est votre seule barrière. Avant de déployer, vérifiez deux choses concrètes : le profil choisi par scripts/install/install.sh et le contenu des skills que vous importez.
Notes de la communauté