DeepBI : une analyse de données pilotée par LLM, à installer soi-même

Le problème : écrire du SQL pour chaque question

Dans une équipe produit, la même scène se répète. Quelqu'un veut savoir combien de commandes ont été annulées le mois dernier, il ouvre un ticket, un analyste écrit la requête, la renvoie sous forme de capture d'écran, et la question suivante repart de zéro. DeepBI attaque ce cycle en plaçant un modèle de langage entre l'utilisateur et la base. Le README résume la promesse ainsi : « explore, query, visualize, and share data from any data source ». La formulation est large, mais le public visé est identifiable. Ce sont des équipes qui ont déjà des données dans MySQL, PostgreSQL, Doris ou StarRocks et qui veulent réduire le nombre d'allers-retours vers l'équipe data, pas des statisticiens qui ont besoin de modèles, de tests d'hypothèses ou de régression. Le projet se présente comme une plateforme d'analyse « AI-native », ce qui signifie concrètement que la conversation est l'interface principale et non un panneau de filtres à remplir.

Ce que la conversation produit réellement : requêtes persistantes et tableaux de bord

La fonction la plus intéressante du projet n'est pas la réponse ponctuelle, c'est la persistance. Le README distingue deux choses : l'analyse conversationnelle, qui renvoie un résultat arbitraire, et la génération conversationnelle de requêtes, qui produit des « persistent queries and visualizations ». Autrement dit, une question bien posée peut être enregistrée comme une visualisation réutilisable, et ces visualisations s'assemblent ensuite en tableaux de bord. C'est ce mécanisme qui sépare DeepBI d'un simple chat branché sur une base : sans persistance, chaque question repartirait du contexte de conversation, et rien ne serait partageable. Le dépôt ne détaille pas comment le schéma de la base est transmis au modèle, ni comment les jointures entre tables sont résolues, ni si un cache Redis intervient dans la génération. Ces éléments sont absents de la documentation fournie, et il faut le dire clairement : la mécanique interne de génération de requêtes n'est pas documentée publiquement dans le README.

Sources de données et portée de la couverture

La liste des bases supportées est explicite : MySQL, PostgreSQL, Doris, StarRocks, MongoDB, plus l'import de fichiers CSV et Excel. La portée est donc volontairement orientée entrepôt analytique et base relationnelle classique. Doris et StarRocks, tous deux des moteurs OLAP, indiquent une cible : des volumes qui ne tiennent pas dans une base transactionnelle. Il manque cependant des sources très courantes en entreprise, notamment les entrepôts cloud propriétaires et les API SaaS, et le README ne décrit aucune couche de connecteurs extensible. Si vos données vivent dans un système absent de cette liste, DeepBI n'est pas l'outil adapté, et le dépôt ne suggère pas de chemin d'extension documenté. La prise en charge de l'international se limite au chinois et à l'anglais, ce qui est cohérent avec l'origine du projet mais restreint pour une équipe francophone qui voudrait que les libellés générés soient en français.

Trois chemins d'installation, trois niveaux de friction

Le README propose trois méthodes. La plus simple est l'exécutable Windows : télécharger window_install_exe_EN.zip depuis la liste des tags, décompresser, double-cliquer sur le fichier .exe. La documentation indique que seuls Win10 et Win11 sont testés, et que Windows 10 doit être en version 22H2 ou supérieure pour installer WSL. La deuxième méthode passe par Docker, et c'est celle que le README détaille le plus : cloner le dépôt, entrer dans le répertoire, lancer ./Install.sh. Les ports par défaut sont 8338 et 8339, l'accès web se fait sur http://ip:8338. Les commandes d'exploitation sont docker-compose start, docker-compose stop et docker-compose ps, avec un sudo à ajouter en cas de PermissionError. La troisième méthode, Ubuntu, est la plus exigeante : elle demande Redis accessible en 127.0.0.1 sans mot de passe, PostgreSQL 16, et Python 3.8.x, avec un environnement virtuel recommandé. Le script s'exécute par . ubuntu_install.sh, et le README insiste sur le point : il faut le point et non sh, sinon l'environnement virtuel Python n'est pas activé. Cette nuance est le genre de détail qui fait échouer une installation.

Ce que le dépôt ne dit pas

La documentation est mince sur tout ce qui touche à l'exploitation. Aucune variable d'environnement n'est listée, aucun fichier de configuration n'est nommé, et la manière dont les identifiants des bases de données connectées sont stockés n'apparaît nulle part. Pour un service qui détient des accès en lecture à vos entrepôts, c'est une lacune qui compte. La gestion des clés d'API des fournisseurs de modèles n'est pas décrite non plus, alors que le fonctionnement du produit en dépend entièrement. Le README mentionne une exigence matérielle minimale d'un cœur et 2 Go de mémoire, avec une recommandation de 2 cœurs et 4 Go. Cette recommandation concerne le serveur DeepBI lui-même, pas l'inférence du modèle, qui se fait vraisemblablement via une API externe, sans que le dépôt le confirme. Les tests annoncés couvrent macOS 12.7 à 14.1.1, Ubuntu 20.04 et 22.04, et Windows 11 WSL 22.04. Rien n'est dit sur la montée en charge, le nombre d'utilisateurs simultanés, ou le comportement quand une requête générée est fausse.

Le point sensible : une requête générée peut être fausse sans le dire

C'est la limite structurelle de toute interface en langage naturel posée sur une base de données. Un modèle qui produit une jointure incorrecte renvoie un tableau de bord plausible, avec des chiffres faux, et rien dans le README n'indique un mécanisme de validation, de revue humaine ou de mise en garde affichée avant l'exécution. La fonction de rapports d'analyse automatisés est d'ailleurs marquée « to be developed » dans la liste des fonctionnalités : elle est annoncée, pas livrée. Sur un jeu de données dont les erreurs coûtent cher (finance, santé, conformité), faire écrire les requêtes par un modèle sans relecture est un pari. DeepBI reste un outil d'exploration, pas un système de reporting certifié. La question à se poser avant adoption n'est pas « est-ce que ça marche » mais « qui vérifie la requête avant que le chiffre parte en réunion ».

Face à Metabase ou Superset : deux philosophies opposées

Metabase et Apache Superset occupent la même place dans une stack data, mais par un chemin inverse. Ils demandent à l'utilisateur de construire une requête dans une interface graphique ou d'écrire du SQL, puis figent le résultat dans un tableau de bord. La sémantique est explicite : chaque champ est choisi, chaque filtre est visible, et le résultat est reproductible parce qu'il ne dépend d'aucun modèle. DeepBI déplace l'effort : l'utilisateur formule une intention, le système produit la requête. Le gain est réel pour les questions ad hoc, celles qu'on n'aurait jamais pris la peine de formaliser. Le coût l'est aussi : la reproductibilité dépend du modèle et du contexte fourni, et la lisibilité disparaît pour qui veut auditer la logique. Un choix pragmatique consiste à garder Metabase ou Superset pour les indicateurs qui doivent être stables et partagés, et à réserver DeepBI à l'exploration. Les deux ne s'excluent pas, mais ils ne répondent pas à la même contrainte.

Licence, maintenance et coût de mise à jour

Le projet est publié sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver l'avis de copyright et le texte de la licence. Le dépôt ne contient pas de mention d'une licence distincte pour le client web ou pour un composant tiers, mais le README ne fournit pas non plus d'inventaire des dépendances, et cette vérification reste à faire de votre côté, notamment si vous redistribuez le produit. Sur la maintenance, les faits disponibles sont limités : la dernière release listée est v2.0.4, datée du 8 octobre 2024, tandis que le dernier push sur la branche main est daté du 28 août 2026. Le décalage entre les deux suggère que le développement continue sans publication de version, mais rien dans le matériel fourni ne permet de confirmer ce que contient cet écart. Le coût de mise à jour n'est pas documenté : aucune procédure de migration de schéma, aucun numéro de version de base de données attendu au-delà de PostgreSQL 16, aucune note sur la compatibilité entre versions. Si vous déployez en production, prévoyez de lire les scripts Install.sh et ubuntu_install.sh avant de les exécuter, car ce sont eux qui portent l'essentiel de la configuration réelle.

Conclusion éditoriale

DeepBI convient aux équipes qui veulent interroger MySQL, PostgreSQL, Doris, StarRocks ou un CSV en langage naturel sans écrire de SQL, et qui acceptent d'héberger elles-mêmes le service. Il ne convient pas à qui cherche un produit managé, une API documentée ou une analyse statistique rigoureuse : la fonction de rapports automatisés est explicitement annoncée comme non développée. Avant de vous engager, vérifiez deux points précis dans le dépôt : le contenu réel de Install.sh et de ubuntu_install.sh, et la façon dont les identifiants de connexion aux bases sont stockés, puisque la documentation ne décrit ni l'un ni l'autre.

Sources officielles

1. DeepInsight-AI/DeepBI on GitHub
2. License: MIT
3. Project website
4. README
5. Releases