Chat2DB : client SQL local avec clé de chiffrement à sauvegarder

Le problème : un client par moteur, et une IA qui sort du poste

Une équipe qui touche à MySQL, PostgreSQL, ClickHouse et Redis finit souvent avec un outil par moteur. Chat2DB vise à remplacer cette collection par une seule application : un espace SQL avec édition, complétion, formatage, exécution, requêtes sauvegardées et historique, plus la navigation dans les métadonnées, la gestion des tables et objets en DDL/DML, l'édition de données sur place, l'import/export et des tableaux de bord. Le public annoncé est explicite : développeurs, DBA, analystes et équipes data. Le second problème est moins visible. Les assistants SQL hébergés imposent d'envoyer le schéma, parfois les données, à un service tiers. Ici, le README parle d'un assistant IA que vous connectez à votre propre modèle, ce qui change la question de la confidentialité en une question d'exploitation : c'est vous qui fournissez et payez le modèle.

Ce qui se passe entre l'interface et votre moteur

L'architecture repose sur JDBC. Le README annonce plus de 40 moteurs pris en charge, dont MySQL, PostgreSQL, Oracle, SQL Server, ClickHouse, MongoDB, Redis, SQLite, MariaDB, TiDB, Hive, DB2, Snowflake, BigQuery, Elasticsearch, Trino, TimescaleDB, Greenplum, YugabyteDB, CrateDB, QuestDB, Apache IoTDB, Firebird, HSQLDB et Apache Derby. Le point intéressant est la couche d'extension : selon le README, de nouvelles bases JDBC peuvent être ajoutées par configuration seule, sans modification de code. Concrètement, l'interface parle au serveur Chat2DB, qui parle au pilote JDBC, qui parle à la base. Le mode de déploiement conditionne le reste : desktop, web, Docker ou CLI, cette dernière étant un projet séparé, Chat2DB-CLI, avec support MCP. Cette séparation compte, car elle signifie que l'intégration MCP ne passe pas par l'application graphique. Le README donne aussi une contrainte de ressources pour Docker : au moins 2 cœurs CPU et 4 Gio de RAM.

Démarrer en Docker sans perdre la clé

Le README décrit deux chemins. Le premier est l'installateur de bureau, téléchargé depuis les releases, sans configuration supplémentaire. Le second est Docker. L'ordre compte : la clé d'abord, le conteneur ensuite. Depuis un clone du dépôt, on exécute ./script/security/init-community-encryption-key.sh, puis on lance le conteneur avec les paramètres indiqués, notamment --publish 127.0.0.1:10825:10825, le volume de données et la variable CHAT2DB_COMMUNITY_ENCRYPTION_KEY_FILE pointant vers /run/secrets/chat2db-community-encryption.key. L'interface répond ensuite sur http://localhost:10825. Une variante Compose existe avec docker/docker-compose.yml. Deux avertissements du README méritent d'être lus avant de copier les commandes : l'exemple docker run stocke les données dans $HOME/.chat2db-community-docker tandis que la définition Compose utilise le volume nommé chat2db-community-data, et ces deux emplacements ne partagent pas leurs données. Par ailleurs, la version 5.3.0 utilise le répertoire /root/.chat2db-community et ne migre pas automatiquement les données des images antérieures basées sur /root/.chat2db.

La clé AES-256-GCM, seule vraie dépendance d'exploitation

Chat2DB chiffre les mots de passe de sources de données et les clés d'API des modèles avec AES-256-GCM, au moyen d'une clé par installation. Le README insiste : sauvegardez ce fichier séparément et conservez-le à travers les mises à niveau et les reconstructions de conteneur, car le remplacer ou le perdre rend illisibles les mots de passe et les clés d'API déjà stockés. Le démarrage web ou headless échoue sans clé valide ; seul le mode Desktop en crée une automatiquement. La référence de configuration donne les détails utiles : la clé doit être du Base64 valide décodant exactement 32 octets, l'initialiseur produit la forme standard de 44 caractères se terminant par =. Les mots de passe de sources et les clés d'API utilisent la même clé avec des valeurs AAD distinctes, donc un chiffré produit pour un usage ne peut pas être déchiffré pour l'autre. Pour un chemin personnalisé, le script accepte un argument et le démarrage Java doit recevoir la propriété correspondante, par exemple -Dchat2db.community.encryption-key-file=/secure/path/chat2db-community.key. Cette clé est le vrai coût caché du produit : elle transforme une mise à jour de conteneur en opération à préparer.

Mono-utilisateur, et c'est une décision de conception

Le README est direct : Chat2DB Community est une application mono-utilisateur, locale d'abord, sans comptes utilisateurs ni frontières d'autorisation entre utilisateurs. Il demande de garder le service HTTP lié à 127.0.0.1 ou ::1 et de ne pas l'exposer à d'autres utilisateurs ou à des réseaux non fiables. Ce n'est pas une limite qu'on contourne avec un reverse proxy : l'absence de modèle d'autorisation signifie que toute personne atteignant le port 10825 accède aux sources configurées. Le même paragraphe signale que les pilotes JDBC personnalisés sont du code Java exécutable, à installer uniquement depuis des sources de confiance, et que les fichiers de configuration importés, les archives, les fichiers SQL, le contenu des bases et les réponses de l'IA restent des données non fiables. Autrement dit, l'IA n'est pas traitée comme une source d'instruction fiable, ce qui est la bonne posture, mais cela veut dire aussi que la revue des requêtes générées reste votre travail.

Face à un client SQL classique, la différence est la couche modèle

Un client SQL de bureau traditionnel sait se connecter, exécuter, afficher un plan et exporter. Chat2DB en fait autant, avec en plus des tableaux de bord, des diagrammes ER et l'import/export, ce qui le rapproche d'un outil de BI léger. La différence réelle tient à l'assistant : génération, explication et optimisation de requêtes en langage naturel, branché sur le modèle que vous fournissez. Cette approche s'oppose à celle d'un assistant intégré à un service cloud, où vous n'avez ni le choix du modèle ni la maîtrise du trajet des données. Elle s'oppose aussi à l'usage d'un plugin d'éditeur : ici, l'IA voit le contexte de la source connectée et de son schéma, pas seulement le fichier ouvert. Le revers est qu'il n'existe pas de moteur IA intégré. Si vous n'avez pas de modèle accessible, l'assistant ne sert à rien, et le produit redevient un client SQL parmi d'autres.

Mises à niveau et licence : ce que le dépôt permet de dire

Le rythme de publication est soutenu : v5.3.3, v5.3.4 et v5.3.5 sont datées du 6 août, du 20 août et du 2 septembre 2026, et le dernier push sur main est du 9 septembre 2026. La procédure de mise à jour décrite dans le README est manuelle : tirer la nouvelle image, supprimer l'ancien conteneur, relancer la commande de démarrage, en conservant ~/.config/chat2db-community/encryption.key. Il n'y a pas de mécanisme de migration automatique mentionné entre les images antérieures et la 5.3.0. Sur la licence, le dépôt renvoie NOASSERTION : GitHub n'identifie pas de licence reconnue, et rien dans le matériel fourni ne permet de dire quels droits s'appliquent à la redistribution ou à l'usage commercial. Ce n'est pas un détail à traiter après l'adoption. Si vous comptez intégrer Chat2DB dans un produit ou le déployer dans une entreprise, la première vérification est le fichier de licence du dépôt, pas la page de téléchargement.

Conclusion éditoriale

Chat2DB Community convient à un développeur, un DBA ou un analyste qui travaille seul sur son poste et veut un client SQL unique pour plusieurs moteurs, avec un assistant IA branché sur son propre modèle. Il ne convient pas à une équipe qui attend des comptes utilisateurs ou une séparation des droits : le README précise que l'application est mono-utilisateur, sans frontière d'autorisation entre utilisateurs, et demande de garder le service lié à 127.0.0.1 ou ::1. Avant d'adopter, vérifiez trois points : que votre SGBD figure dans la liste des 40+ moteurs ou qu'il est ajoutable par configuration JDBC, que vous avez bien exécuté ./script/security/init-community-encryption-key.sh et sauvegardé ~/.config/chat2db-community/encryption.key, et que l'emplacement de données choisi (volume nommé chat2db-community-data ou $HOME/.chat2db-community-docker) est celui que vous sauvegarderez.

Sources officielles

1. Issues
2. OtterMind/Chat2DB on GitHub
3. Project website
4. README
5. Releases