Open source ou propriétaire : quel client de base de données privilégier

Choisir un client de base de données, c'est aussi choisir un modèle de licence. La décision se prend rarement à ce niveau, mais elle conditionne tout le reste : qui peut lire le code, qui peut le forker, qui paie, qui décide de la roadmap, et ce qui se passe le jour où l'éditeur disparaît. Trois grands modèles coexistent aujourd'hui : open source pur, propriétaire fermé, et open core. Chacun répond à un cas d'usage différent.

Cet article compare les trois approches sur les critères qui comptent dans la durée : auditabilité du code, pérennité du projet, qualité du support, et coût total sur plusieurs années. L'objectif n'est pas de désigner un gagnant, mais de donner les clés pour trancher en connaissance de cause.

Le modèle open source pur

Les références historiques sont DBeaver Community Edition (Apache 2.0), pgAdmin (PostgreSQL License), phpMyAdmin (GPL-2.0) ou MongoDB Compass (SSPL). Tout le code est public, modifiable, redistribuable selon les termes de la licence. Personne ne peut couper l'accès, augmenter les prix unilatéralement ou retirer une fonctionnalité du jour au lendemain sans qu'un fork soit possible.

L'avantage le plus concret est l'auditabilité. Une équipe sécurité peut lire le code, vérifier comment les credentials sont stockés, comprendre ce qui sort sur le réseau, et auditer les dépendances. Pour un client de base de données qui manipule des secrets de production, cette transparence n'est pas un détail.

Le second avantage est la pérennité. Tant qu'il existe une communauté active, le projet survit à son éditeur d'origine. pgAdmin tourne depuis plus de vingt ans. DBeaver Community a essaimé en plusieurs forks. Le code ne meurt pas avec une startup.

Le coût direct est nul. Le coût indirect, lui, se paie en temps : il faut accepter que les priorités de la roadmap soient pilotées par les mainteneurs (et leurs sponsors), que le support se fasse via GitHub ou Stack Overflow, et que l'UX progresse au rythme des contributions. Les éditeurs open source pur qui financent leur travail vendent souvent du service autour : formations, support entreprise, hosting managé.

Le modèle propriétaire fermé

Côté propriétaire, les références sont DataGrip (JetBrains), TablePlus, Navicat, Studio 3T ou SQL Server Management Studio. Le code est fermé, l'éditeur contrôle la totalité de la chaîne : roadmap, prix, distribution, support. Le client paie une licence (perpétuelle, annuelle ou abonnement) et reçoit en échange un produit poli et un canal de support direct.

Ce modèle a deux forces réelles. La première est l'UX : quand une équipe entière vit du produit, le polish s'accumule. DataGrip et TablePlus sont reconnus pour leur qualité d'interface, leur cohérence et leur rapidité d'itération. La seconde est le support : un ticket trouve une réponse, parfois un correctif, dans une fenêtre prévisible.

Les contreparties sont structurelles. L'auditabilité dépend uniquement de ce que l'éditeur veut bien documenter. Le coût croît avec l'équipe : 250 dollars par poste et par an pour DataGrip, 89 dollars pour TablePlus en perpétuel mais avec mises à jour limitées. Sur cinq ans et vingt postes, l'addition se chiffre en dizaines de milliers d'euros. Et si l'éditeur ferme, est racheté ou pivote, il n'existe pas de plan B : le code n'est pas récupérable.

Le risque le plus sous-estimé est celui du verrou de format. Un fichier de connexions DataGrip ou Navicat n'est pas trivial à exporter vers un autre client. Plus l'organisation accumule de configurations, de requêtes sauvegardées et de scripts dans l'outil, plus le coût de sortie augmente.

Le modèle open core

L'open core est plus récent et plus nuancé. Le cœur du produit est publié sous licence ouverte (Apache 2.0, MIT), certaines fonctionnalités avancées sont sous licence commerciale ou source-available (souvent BUSL ou Elastic License). C'est le modèle de Beekeeper Studio (Community en MIT, Ultimate Edition payante), DBeaver Pro (Community libre, Pro propriétaire), et celui de QoreDB (Core en Apache 2.0, modules Premium en BUSL 1.1).

L'idée est de combiner les deux logiques. Le socle ouvert garantit l'auditabilité du chemin critique : connexion, exécution de requêtes, stockage des credentials, drivers de bases. Une équipe sécurité peut lire ce qu'elle a besoin de lire. Les modules avancés (fédération inter-bases, time travel, contrats de données, AI assistant chez QoreDB) financent le développement et restent inspectables sans être librement redistribuables.

Le point de vigilance est la frontière entre Core et Premium. Une frontière claire, stable et documentée rassure : on sait ce qu'on installe gratuitement et ce qu'on paiera plus tard. Une frontière floue ou mouvante est un signal négatif. Chez QoreDB, le périmètre Premium est listé explicitement dans le fichier CLAUDE.md du dépôt et chaque fichier porte son header SPDX : Apache-2.0 ou BUSL-1.1. C'est un choix éditorial assumé : pas de surprise, pas de bait-and-switch.

Quatre critères pour trancher

Auditabilité. Si une politique de sécurité impose la lecture du code qui manipule les credentials et les requêtes, le propriétaire fermé est exclu d'office. L'open source pur répond à 100 %. L'open core répond pour son périmètre Core, qui inclut généralement les fonctions sensibles. Pour QoreDB, c'est le cas : vault, drivers, exécution de requêtes, validation SQL sont tous dans le Core Apache 2.0.

Pérennité. Trois questions à se poser : qui maintient le code, depuis combien de temps, et que se passe-t-il si l'éditeur disparaît ? Un projet open source actif depuis dix ans avec plusieurs mainteneurs est plus solide qu'une startup propriétaire d'un an. Un open core dont le Core peut continuer à vivre en fork est un filet de sécurité réel.

Support. L'open source pur a un support communautaire, gratuit mais aléatoire. Le propriétaire a un support contractuel, payant et garanti. L'open core combine généralement les deux : support communautaire sur la partie Core, support contractuel via la licence Premium. Si la criticité est forte et le temps de réponse encadré, un SLA s'achète.

Prix long terme. L'open source pur est gratuit en licence, payant en temps interne. Le propriétaire est prévisible année après année mais grossit avec l'équipe. L'open core démarre gratuit et passe en payant uniquement si les modules Premium sont nécessaires : un développeur qui n'utilise que les fonctions Core ne paie rien, une équipe qui veut la fédération multi-bases ou l'assistant IA paie pour ces modules. Le calcul se fait sur trois à cinq ans, pas sur l'année en cours.

Quel modèle pour quel contexte

Un développeur solo qui touche surtout à PostgreSQL et SQLite trouvera son compte dans pgAdmin ou DBeaver Community : zéro coût, code lisible, communauté large. Une équipe backend qui multiplie les moteurs (PostgreSQL, MongoDB, Redis, SQL Server) et qui valorise la rapidité d'itération préférera souvent DataGrip ou TablePlus : le coût est compensé par le gain de temps quotidien.

Une organisation qui a besoin à la fois d'auditabilité du chemin critique et de fonctionnalités avancées (fédération, diff visuel, contrats de données) se tournera vers un modèle open core : Beekeeper Ultimate, DBeaver Pro ou QoreDB. La règle pratique est de vérifier d'abord que la frontière Core/Premium est claire, que la licence du Core est OSI-approved, et que les fonctions sécurité-critiques sont bien dans le Core. Dans le cas de QoreDB, vault Argon2, drivers natifs, protections production et exécution de requêtes sont tous en Apache 2.0 : seules les fonctions à forte valeur métier passent en BUSL.

Un contexte régulé (banque, santé, secteur public) ajoute une couche : la licence doit être compatible avec la politique interne, les redistributions internes doivent être autorisées, et la chaîne de fourniture doit pouvoir être vérifiée. Apache 2.0 et MIT passent partout. Les licences source-available (BUSL, Elastic, SSPL) demandent une lecture attentive du texte, mais autorisent généralement l'usage interne sans frottement.

Le choix de QoreDB

QoreDB a été conçu en open core dès le premier commit. Le Core (Apache 2.0) couvre tout ce dont un développeur a besoin pour utiliser le produit quotidiennement : connexion aux cinq drivers (PostgreSQL, MySQL, MongoDB, SQLite, SQL Server), éditeur SQL, data grid, vault chiffré, exports CSV/JSON/SQL/HTML, protections production, tunnels SSH. Les modules Premium (BUSL 1.1) regroupent les fonctions qui financent le projet : fédération inter-bases via DuckDB, time travel, contrats de données, assistant IA, diff visuel, exports Parquet et XLSX, ER diagram avancé.

Le choix de la BUSL plutôt qu'une licence purement propriétaire est délibéré. Le code Premium reste lisible, auditable, modifiable pour un usage non concurrentiel. Au bout de la période de change (typiquement 4 ans), chaque version Premium bascule en Apache 2.0. C'est un compromis qui protège le modèle économique sans fermer le code, et qui rend toute migration possible si l'éditeur disparaît.

En synthèse

Le choix entre open source pur, propriétaire et open core ne se fait pas sur le seul critère du prix initial. Il se fait sur l'équilibre entre auditabilité, pérennité, support et coût étalé dans le temps. L'open source pur maximise la liberté et minimise le coût direct, au prix d'un support communautaire. Le propriétaire maximise le polish et le support, au prix d'une dépendance complète à l'éditeur. L'open core cherche un point médian : code ouvert sur le chemin critique, modèle économique viable sur la valeur ajoutée. Aucun n'est universellement meilleur. Le bon modèle est celui qui répond à votre contrainte la plus forte, qu'elle soit budgétaire, sécuritaire ou organisationnelle.