Client local-first ou cloud : quel modèle pour gérer ses bases en 2026

En 2026, deux familles d'outils cohabitent pour interagir avec une base de données. D'un côté, les clients desktop installés sur le poste du développeur : DBeaver, DataGrip, TablePlus, Beekeeper Studio, QoreDB. De l'autre, les surfaces SaaS hébergées : Retool, Mode, Hex, Metabase Cloud, PopSQL. Les deux familles se ressemblent en apparence, puisqu'elles affichent toutes des tables et exécutent toutes des requêtes, mais elles ne résolvent pas le même problème.

Le choix entre local-first et cloud n'est pas une préférence esthétique. Il a des conséquences concrètes sur la latence, sur la souveraineté des credentials, sur la façon dont l'outil s'insère dans une infrastructure existante et sur ce qui devient facile ou difficile au quotidien. Cet article décrit chaque modèle dans ses détails techniques et indique dans quels contextes l'un ou l'autre est le bon choix.

Ce que recouvre techniquement un client local-first

Un client local-first est un binaire natif qui tourne sur la machine de l'utilisateur. Les credentials de connexion sont stockés en local, généralement dans le keychain de l'OS ou dans un vault chiffré applicatif. Quand l'utilisateur lance une requête, la connexion sort directement du poste vers la base, sans passer par un service intermédiaire. L'état applicatif (onglets ouverts, historique, requêtes sauvegardées, snippets) vit aussi sur le disque local.

Cette définition implique quelques propriétés concrètes. Le compte utilisateur chez l'éditeur du client est optionnel, voire inexistant : DBeaver et DataGrip fonctionnent sans inscription, QoreDB aussi. L'éditeur du logiciel n'a pas de backend qui voit les requêtes ou les résultats. Si la base est dans un VPC privé accessible via VPN, le client fonctionne dès que le VPN est actif, sans configuration supplémentaire. L'outil est utilisable hors-ligne pour tout ce qui ne nécessite pas la base (lecture de l'historique, édition d'un snippet, navigation dans un export).

Ce que vise un outil cloud orienté base de données

Un outil cloud comme Retool, Mode ou Hex est une application web hébergée par le fournisseur. L'utilisateur s'y connecte avec un compte, configure une source de données en y entrant les credentials de sa base, puis travaille dans une interface accessible depuis n'importe quel navigateur. Le service stocke les credentials côté serveur, dans un vault qui appartient au fournisseur. Quand une requête est exécutée, c'est le backend du service qui ouvre la connexion à la base, exécute le SQL et renvoie les résultats au navigateur de l'utilisateur.

Ce modèle est conçu pour le partage. L'URL d'un dashboard ou d'un notebook peut être envoyée à un collègue, qui l'ouvrira sans installer quoi que ce soit. Les droits d'accès sont centralisés. Les workflows automatisés (rapports planifiés, alertes, intégrations) sont gérés par la plateforme. L'outil cloud est typiquement utilisé pour des cas où plusieurs personnes consomment les mêmes données, parfois sans avoir les droits ou les compétences techniques pour les requêter elles-mêmes.

Latence et chemin réseau

Sur un client local-first, la requête fait un seul aller-retour : poste utilisateur vers base, puis base vers poste. La latence perçue dépend uniquement de la qualité du lien entre le développeur et sa base. Sur un Postgres hébergé dans la même région que le poste, on parle de quelques millisecondes pour les requêtes simples, ce qui rend l'exploration interactive très confortable.

Sur un client cloud, la requête fait deux hops : navigateur vers service SaaS, puis service SaaS vers base. La latence cumule deux trajets réseau, ce qui devient sensible quand l'utilisateur, le SaaS et la base ne sont pas dans la même région. Pour des dashboards qui rafraîchissent toutes les heures, c'est sans importance. Pour de l'exploration ou du debug, où on enchaîne dix requêtes courtes en deux minutes, la différence se sent.

Souveraineté des credentials et trajet des données

Dans un modèle local-first, les credentials de la base ne quittent jamais la machine de l'utilisateur. C'est l'utilisateur, et lui seul, qui détient le mot de passe ou le certificat de connexion. Aucun tiers ne peut techniquement les utiliser. Les résultats des requêtes ne transitent pas non plus par un service externe : ils vont de la base à la mémoire du poste, point.

Dans un modèle cloud, l'éditeur du SaaS a techniquement accès aux credentials qu'il stocke (chiffrés au repos, mais déchiffrés à l'exécution) et aux requêtes qu'il exécute. C'est une réalité opérationnelle assumée par les fournisseurs sérieux, qui publient des audits, des certifications SOC 2 et des modèles de menaces détaillés. La question n'est pas de savoir si le fournisseur est honnête, c'est de savoir si l'organisation peut accepter cette surface d'attaque supplémentaire. Pour une équipe qui manipule des données soumises à RGPD, à HIPAA ou à des contraintes de souveraineté, le calcul n'est pas neutre.

Accès aux bases en VPC privé

Une part importante des bases en production en 2026 vit dans un VPC privé, sans IP publique, accessible uniquement depuis un bastion ou via VPN d'entreprise. Un client local-first s'adapte naturellement : si le poste est sur le VPN, il joint la base, sinon il ne la joint pas. Pas de configuration côté infra à faire pour l'outil lui-même. QoreDB supporte en plus le tunnel SSH natif, ce qui permet d'atteindre une base derrière un bastion sans monter le tunnel à la main.

Un outil cloud doit, lui, atteindre la base depuis ses propres serveurs. Cela suppose soit d'ouvrir un trou dans le firewall et de mettre les IPs du fournisseur en allowlist, soit d'installer un connecteur (Retool propose un agent on-premise, Hex un workspace connector) qui maintient un tunnel reverse depuis le réseau de l'entreprise vers le SaaS. Le second cas fonctionne mais ajoute une dépendance à un composant tiers qu'il faut déployer, monitorer et garder à jour.

Là où le modèle cloud est le bon choix

Le cloud devient pertinent dès que la valeur principale est le partage. Un dashboard que dix personnes ouvrent chaque matin, une requête sauvegardée que le support consulte à la demande, un notebook d'analyse partagé entre data analysts et product managers : tout cela est mieux servi par Mode, Hex ou Metabase que par un client desktop. Le navigateur, l'URL partageable et l'authentification centralisée sont les vrais atouts de ces produits.

Retool occupe une case un peu différente : c'est moins un client de BDD qu'un constructeur d'applications internes, où la base de données est une source de données parmi d'autres. L'usage typique est de bâtir une interface admin que le support ou les ops utilisent quotidiennement. À l'inverse, un client desktop n'est pas adapté à ce besoin : on n'installe pas DBeaver à toute l'équipe support.

Là où le modèle local-first reste le bon choix

Pour le travail quotidien d'un développeur produit ou backend, le local-first reste le meilleur format. Exploration d'un schéma, debug d'une requête lente, vérification d'une migration, écriture d'un script SQL complexe : ces tâches sont individuelles, interactives, sensibles à la latence, et touchent souvent à des bases sensibles. Un client local couvre ce besoin sans demander à l'organisation d'ajouter un service tiers à son périmètre.

Le local-first est aussi le format naturel pour les équipes tech qui veulent contrôler où vivent les credentials. Stocker les mots de passe de production uniquement dans des keychains OS individuels, plutôt que dans un vault SaaS partagé, simplifie le modèle de menaces. Si un développeur quitte l'entreprise, il suffit de tourner ses droits dans la base et de récupérer son poste : il n'y a pas de credentials persistés ailleurs.

Pour les bases en environnement régulé (santé, finance, secteur public), le local-first évite de devoir auditer un fournisseur SaaS supplémentaire. L'outil tourne sur un poste déjà conforme, utilise les credentials déjà gérés, et n'ajoute pas de nouvelle juridiction au passage des données.

Choisir selon l'usage réel

En pratique, le choix se fait par cas d'usage, pas par dogme. Une équipe de cinq développeurs qui manipule PostgreSQL et MongoDB au quotidien sera servie par un client local-first comme DataGrip, DBeaver ou QoreDB. Une équipe data qui produit des dashboards consommés par trente personnes sera servie par Mode, Hex ou Metabase. Une startup qui veut une interface admin pour son support utilisera Retool. Un développeur solo qui veut juste écrire des requêtes voudra un client local rapide qui s'ouvre en deux secondes.

Beaucoup d'organisations utilisent les deux en parallèle, et c'est le cas le plus sain. Les développeurs travaillent dans leur client local-first pour le code et le debug. Les dashboards et les outils internes vivent dans une plateforme cloud dédiée à ce besoin. Chercher un seul outil qui couvre les deux usages mène généralement à un compromis qui ne satisfait personne.

Le choix structurant de QoreDB

QoreDB est explicitement positionné dans la famille local-first. Le runtime est Tauri 2, le backend est en Rust, les drivers (PostgreSQL, MySQL, MongoDB, SQLite, SQL Server, CockroachDB) sont natifs et tournent dans le binaire du poste. Les credentials sont stockés dans un vault chiffré par Argon2, en local. Aucun compte chez QoreDB n'est requis pour utiliser l'application : pas de backend qui voit les requêtes, pas de télémétrie obligatoire. La fédération inter-bases, quand elle est utilisée, repose sur DuckDB embarqué dans le binaire et exécute le join sur le poste.

Ce choix vient d'une conviction sur le public cible : QoreDB s'adresse au développeur produit, à la petite équipe tech, au backend qui touche à PostgreSQL ou MongoDB plusieurs fois par jour. Pour ce profil, la latence, la souveraineté des credentials et l'accès à des bases en VPC privé pèsent plus que le partage de dashboards. Le format desktop est aligné avec ce besoin. Pour les usages de partage et de BI, d'autres familles d'outils existent et font mieux le job : c'est sain d'avoir deux familles plutôt qu'un compromis.

Local-first et cloud ne sont pas en concurrence frontale, ce sont deux réponses à deux problèmes différents. Le premier optimise pour le travail individuel sur des bases sensibles, avec une latence minimale et une souveraineté maximale. Le second optimise pour le partage à grande échelle, l'automatisation et l'accessibilité depuis un navigateur. Choisir le bon modèle en 2026, c'est avant tout savoir lequel des deux problèmes on cherche à résoudre.