Des alternatives à Retool qui ne téléversent pas ta base de données sur le serveur de quelqu'un d'autre

J'ai utilisé Retool. J'aime Retool. Si tu as besoin d'un outil interne prêt pour mardi et que ton équipe maîtrise déjà JavaScript, Retool t'y amènera plus vite que presque n'importe quoi d'autre sur le marché. Il a mérité sa place de valeur par défaut dans la catégorie. La bibliothèque de composants est franchement bonne, le constructeur par glisser-déposer est rapide, et la possibilité d'écrire du JavaScript partout signifie que tu n'es jamais coincé par une abstraction no-code qui lâche au pire moment.

Mais il y a un truc que la plupart des reviews de Retool ne mentionnent pas ouvertement, et c'est justement celui qui finit par compter le plus pour un certain type d'équipe : quand tes utilisateurs lancent une requête dans une application Retool, cette requête ne va pas directement de leur navigateur vers ta base de données. Elle passe de leur navigateur aux serveurs de Retool, puis des serveurs de Retool vers ta base de données, puis à nouveau par les serveurs de Retool, puis revient à leur navigateur. Retool se trouve au milieu de chaque interaction avec la base de données. Chaque ligne que tes utilisateurs lisent, chaque requête qu'ils lancent, chaque filtre qu'ils appliquent — tout ça transite par une infrastructure appartenant à un tiers et gérée par lui.

Pour beaucoup d'équipes, c'est très bien. Franchement, très bien. Si ta base de données est un réplica en lecture de données analytiques non sensibles, ou si tu construis des outils internes pour une équipe qui fait déjà confiance aux vendeurs SaaS pour tout, le flux de données par les serveurs de Retool n'est pas un problème. Retool est une entreprise bien gérée, avec une posture de sécurité sérieuse, une conformité SOC 2 et des clients entreprise qui l'ont audité en profondeur.

Mais pour les équipes avec des bases de données en production, des exigences de conformité (HIPAA, ta propre SOC 2, des contraintes de résidence des données GDPR), des environnements isolés (air-gapped), ou simplement une forte préférence institutionnelle pour ne pas faire transiter le trafic de base de données par un tiers — c'est un problème. Et c'est un problème que la plupart des articles sur les « alternatives à Retool » abordent de biais. Ils parlent d'open-source. Ils parlent d'auto-hébergement. Ils parlent de coût. Ils disent rarement la chose elle-même : tes requêtes passent par le serveur de quelqu'un d'autre, et voici comment arrêter ça.

C'est de ça que parle cet article.

Le problème du flux de données

Laisse-moi le dessiner en texte, parce que l'architecture compte plus que le marketing.

Retool Cloud (le défaut, ce que la plupart des équipes utilisent) :

[User's Browser] --> [Retool Cloud Servers] --> [Your Database]
                        ^                         |
                        |                         |
                        +------ responses --------+

Chaque requête que tes utilisateurs lancent fait un aller-retour par l'infrastructure de Retool. Tes identifiants de base de données sont stockés sur les serveurs de Retool (chiffrés, oui — mais stockés là-bas). Le SQL que tes utilisateurs écrivent, les paramètres qu'ils passent, les résultats qui reviennent — tout transite par le réseau de Retool. Si Retool a une panne, tes outils internes tombent. Si Retool a un pic de latence, tes outils semblent lents. Si ton équipe conformité demande « où passe notre trafic de base de données », la réponse honnête est « par les serveurs de Retool, en us-east-1 ou là où ils tournent ».

Retool auto-hébergé (offre Enterprise uniquement) :

[User's Browser] --> [Your Retool Instance] --> [Your Database]
                        ^
                        |
                   You run this on your own infra

C'est mieux, du point de vue du flux de données. Ton trafic de base de données reste sur ton réseau. Mais Retool auto-hébergé est une fonctionnalité Enterprise, ce qui veut dire que tu paies le tarif Enterprise (parlez à nos commerciaux, ce qui veut dire « ça va être cher »), et tu es maintenant responsable de faire tourner une instance Retool basée sur Docker sur ton infrastructure. Tu as échangé un problème de flux de données tiers contre un problème de maintenance de serveur et une grosse facture.

Local-first (ce que je défendrai à la fin) :

[User's Desktop App] --> [Your Database]
       ^
       |
   No intermediate server at all

Pas de serveur au milieu. Pas de compte cloud. Pas de conteneur Docker à maintenir en vie. L'application tourne sur ta machine et parle directement à ta base de données, comme le feraient psql ou une interface graphique de base de données.

La préoccupation ici n'est pas que la confidentialité, soyons clairs. Il y a trois vrais problèmes avec le flux de données cloud :

Confidentialité et conformité. Ton trafic de base de données transite par un tiers. Pour certains jeux de données et certaines juridictions, ce n'est tout simplement pas autorisé. Pour d'autres, c'est autorisé mais exige une évaluation des risques vendeur, un accord de traitement des données et des audits réguliers — une friction que tu peux éliminer entièrement en ne le faisant pas.
Latence. Chaque requête fait un saut réseau supplémentaire. Si ta base de données est en eu-west et que les serveurs de Retool sont en us-east, les requêtes de tes utilisateurs traversent l'Atlantique deux fois. Ce n'est pas une latence théorique — elle se manifeste à chaque chargement de table, à chaque filtre, à chaque recherche.
Dépendance de disponibilité. Si Retool est en panne, tes outils internes sont en panne, même si ta base de données est parfaitement saine et que ta propre infrastructure va bien. Tu as couplé la disponibilité de tes outils à un vendeur que tu ne contrôles pas. J'ai vécu des incidents où la base de données était debout, les serveurs d'application étaient debout, mais l'outil d'administration interne était tombé parce que le vendeur SaaS avait une panne régionale. C'est un mode d'échec frustrant parce que rien de ton côté n'est réellement cassé.
Enfermement vendeur. Les applications Retool sont construites dans le constructeur de Retool et stockées au format Retool. Migrer hors de Retool veut dire reconstruire tes outils dans autre chose. C'est vrai pour tout outil de cette catégorie dans une certaine mesure, mais la dépendance cloud le rend plus aigu — tu ne peux même pas continuer à faire tourner tes outils existants pendant la migration, parce que le runtime est hébergé.

Ce que Retool fait bien

Avant de passer aux alternatives, je veux être juste avec Retool, parce que le balayer d'un revers serait malhonnête. Retool est populaire pour de vraies raisons, et si la préoccupation du flux de données ne s'applique pas à toi, ces raisons restent valables.

Le constructeur d'applications est rapide. Je le dis dans deux sens. C'est rapide pour construire — tu peux avoir une interface CRUD fonctionnelle sur une table en quelques minutes, et un outil multi-étapes plus complexe en un après-midi. Et les applications résultantes sont raisonnablement rapides à l'usage, flux de données cloud mis à part. Le canevas glisser-déposer, le panneau de propriétés, la façon dont les composants s'emboîtent — c'est un logiciel soigné. J'ai utilisé des constructeurs plus lourds, et Retool n'en fait pas partie.

La bibliothèque de composants est franchement bonne. Tables, graphiques, formulaires, modales, onglets, conteneurs, cartes — tout est là, tout fonctionne, et tout est suffisamment personnalisable pour construire de vraies applications plutôt que de simples dashboards. Le composant table en particulier est l'un des meilleurs que j'ai utilisés. Il gère de gros jeux de données, le tri, le filtrage et l'édition en ligne sans s'effondrer.

Du JavaScript partout. C'est la fonctionnalité tueuse de Retool, à mon avis. Partout où tu peux mettre une valeur, tu peux mettre une expression JavaScript. Partout où tu as besoin de logique, tu peux écrire une fonction JavaScript. Tu n'es pas limité par ce que l'abstraction no-code supporte — tu peux descendre dans du vrai code quand tu en as besoin, et le code s'exécute dans un contexte où il a accès à tes requêtes, tes composants et l'état de ton application. Pour les développeurs, c'est la différence entre un outil qui passe à l'échelle et un outil qui casse au cas limite.

Génération d'applications par IA. Retool a beaucoup investi dans l'IA, et ça se voit. Tu peux décrire une application en langage naturel et obtenir une première ébauche raisonnable. Tu peux demander à l'IA de modifier des composants, d'écrire des requêtes, de générer du JavaScript. Ce n'est pas parfait — les applications générées nécessitent encore une revue et des ajustements humains — mais ça réduit significativement le temps entre l'idée et l'outil fonctionnel. C'est un domaine où les ressources de Retool (c'est une entreprise bien financée) se traduisent par un véritable avantage produit.

L'écosystème. Retool existe depuis assez longtemps pour qu'il y ait une bibliothèque de modèles, de composants communautaires, d'intégrations et de tutoriels. Si tu veux construire quelque chose, quelqu'un a probablement construit quelque chose de similaire et en a écrit. Ça compte pour les équipes qui adoptent un nouvel outil.

Donc : Retool est bon. Si l'architecture du flux de données te convient, il n'y a pas de raison de changer. Cet article s'adresse aux équipes pour qui ce n'est pas le cas.

5 alternatives qui gardent tes données plus près

Voici cinq alternatives, organisées à peu près par proximité de tes données. Les quatre premières sont des outils open-source auto-hébergés — ils tournent sur ton infrastructure, donc ton trafic de base de données reste sur ton réseau, mais tu maintiens un serveur. La cinquième est une catégorie complètement différente : une application de bureau local-first sans serveur.

1. Appsmith (auto-hébergé, open-source)

Appsmith est probablement le concurrent open-source le plus direct de Retool, et il a les GitHub stars pour le prouver — environ 39,6K au moment où j'écris. Il est sous licence Apache 2.0, l'une des licences open-source les plus permissives (tu peux l'utiliser commercialement, la modifier et la distribuer sans obligations copyleft). L'architecture est simple : tu auto-hèrges une instance Appsmith sur ta propre infrastructure — une VM, un conteneur Docker, un cluster Kubernetes — et tes utilisateurs y accèdent via un navigateur, comme avec Retool. La différence, c'est que l'instance Appsmith est à toi. Tes identifiants de base de données vivent sur ton serveur. Tes requêtes vont de ton serveur vers ta base de données. Rien ne transite par le réseau de quelqu'un d'autre.

L'expérience du constructeur est similaire à celle de Retool : un canevas glisser-déposer, une bibliothèque de composants, du JavaScript pour la logique personnalisée, un éditeur de requêtes qui se connecte à tes bases de données et API. Si tu as utilisé Retool, Appsmith te semblera familier. La bibliothèque de composants n'est pas tout à fait aussi soignée que celle de Retool, et l'écosystème de modèles et de contenu communautaire est plus petit, mais la fonctionnalité de base — construire des outils internes sur tes données — est solide.

Le compromis, c'est la maintenance du serveur. Tu fais tourner une instance Appsmith, ce qui veut dire que tu gères les mises à jour, les sauvegardes, les certificats SSL, le contrôle d'accès et la disponibilité. Pour une équipe avec des capacités DevOps, c'est un coût connu. Pour une petite équipe ou un développeur solo, c'est une vraie charge. Appsmith propose aussi une version cloud, mais si tu lis cet article, la version cloud ne t'intéresse probablement pas — elle pose le même problème de flux de données que Retool cloud.

Appsmith est le bon choix si : tu veux une expérience type Retool, tu as l'infrastructure pour l'auto-héberger, et tu veux une licence Apache 2.0 qui te permet de modifier et distribuer librement.

2. ToolJet (auto-hébergé, open-source)

ToolJet est l'autre grande alternative open-source à Retool, avec environ 35K GitHub stars. Il est sous licence AGPL v3, une distinction importante par rapport à l'Apache 2.0 d'Appsmith. L'AGPL est une licence copyleft forte — si tu modifies ToolJet et que tu le rends accessible via un réseau (ce qui est exactement ce que tu fais quand tu héberges une plateforme d'outils internes), tu es obligé de rendre le code source de tes modifications disponible à tes utilisateurs. Pour la plupart des cas d'usage interne, c'est très bien — tes utilisateurs sont tes propres employés, et partager le code source avec eux n'est pas un problème. Mais si tu construis un ToolJet modifié exposé à des utilisateurs externes, ou si ton équipe juridique est prudente sur les licences copyleft, ça vaut la peine de comprendre les implications de l'AGPL avant de s'engager.

Fonctionnellement, ToolJet est similaire à Appsmith : auto-hébergé, basé sur navigateur, constructeur glisser-déposer, JavaScript pour la logique personnalisée, se connecte à tes bases de données et API directement depuis ton instance. La bibliothèque de composants est comparable. L'expérience du constructeur est comparable. À l'aveugle, la plupart des développeurs auraient du mal à faire la différence entre Appsmith et ToolJet rien qu'avec le constructeur — les vraies différences sont dans la licence, la communauté et les intégrations spécifiques que chacun gère mieux.

Le compromis est le même qu'Appsmith : tu maintiens un serveur. Et la licence AGPL est à prendre en compte si ton équipe juridique a des opinions sur le copyleft.

ToolJet est le bon choix si : tu veux une expérience type Retool, l'AGPL ne te dérange pas, et tu préfères l'ensemble de composants ou la communauté de ToolJet. Honnêtement, entre Appsmith et ToolJet, le choix se résume souvent à la préférence de licence et à celui dont la documentation te semble la plus claire.

3. Budibase (auto-hébergé, open-source)

Budibase tourne autour de 23,6K GitHub stars et prend un angle légèrement différent d'Appsmith et ToolJet. Là où Appsmith et ToolJet sont explicitement du « Retool mais en open-source », Budibase penche plutôt vers le bout constructeur d'applications low-code CRUD du spectre. Il est bon pour construire des formulaires, des tables et des interfaces CRUD sur tes données — le pain et le beurre des outils internes — et il intègre une couche de base de données pour quand tu veux créer une nouvelle source de données plutôt que de te connecter à une existante.

Cette base de données intégrée mérite qu'on en parle. Budibase peut se connecter à des bases de données externes (PostgreSQL, MySQL, MongoDB, etc.), mais il est aussi livré avec sa propre base de données interne pour les applications qui ont besoin de leur propre stockage. C'est utile si tu construis un outil qui doit suivre son propre état — workflows d'approbation, soumissions de formulaires, logs d'audit — à côté des données qu'il lit dans ta base principale. C'est aussi une source potentielle de confusion : tu as maintenant des données à deux endroits (la base interne de Budibase et ta base externe), et tu dois être clair sur laquelle est laquelle.

Budibase propose un palier gratuit auto-hébergé et des plans cloud payants. La version auto-hébergée garde tes données sur ton infrastructure, ce qui est le point pertinent pour cet article. Le compromis, encore une fois, c'est la maintenance du serveur — plus la complexité supplémentaire de la couche de base de données interne si tu choisis de l'utiliser.

Budibase est le bon choix si : tes outils internes sont principalement des applications CRUD (formulaires, tables, gestion d'enregistrements), tu veux peut-être une base de données intégrée pour l'état spécifique à l'application, et tu préfères un constructeur un peu plus opinaitré que l'approche canevas vierge d'Appsmith ou ToolJet.

4. Windmill (auto-hébergé, open-source)

Windmill est l'exception dans cette liste, et je veux être clair sur pourquoi il y est. Windmill n'est pas principalement un constructeur d'outils internes — c'est une plateforme de workflows et d'automatisation de scripts qui inclut aussi un constructeur d'interface. Environ 16,2K GitHub stars, et un modèle mental fondamentalement différent des autres.

Dans Windmill, tu écris des scripts (en Python, JavaScript, Go, Bash, et autres), et Windmill les transforme en étapes réutilisables que tu peux enchaîner en workflows. Les workflows peuvent être déclenchés par des plannings, des webhooks ou des interactions UI. Le constructeur d'interface te permet de créer des frontends qui appellent ces scripts et workflows — tu peux donc construire des outils internes, mais les outils sont des frontends sur des scripts, pas des frontends sur des requêtes directes à la base de données.

C'est une différence importante. Si tes outils internes consistent principalement à « lancer cette requête et afficher les résultats dans une table », Windmill est surdimensionné — tu écrirais des scripts pour encapsuler des requêtes qu'Appsmith ou ToolJet te laisseraient lancer directement. Mais si tes outils internes impliquent de la vraie logique — traitement de données multi-étapes, appels à des API externes, transformation de données entre systèmes, exécution de tâches planifiées — l'approche script-first de Windmill est franchement meilleure que de bricoler de la logique sur un outil piloté par requêtes.

Le compromis, c'est une courbe d'apprentissage plus raide. Windmill s'attend à ce que tu écrives du code. Pas des snippets JavaScript dans un panneau de propriétés — de vrais scripts dans de vrais fichiers, versionnés et déployés. Pour une équipe de développement, c'est une fonctionnalité, pas un bug : la logique de tes outils internes est du vrai code que tu peux tester, revuer et maintenir comme n'importe quel autre code. Pour un non-développeur ou une équipe cherchant une expérience no-code, c'est un obstacle.

Windmill est le bon choix si : tes outils internes sont lourds en scripts, tu veux que la logique de tes outils soit du vrai code versionné, et tu as besoin d'automatisation de workflows à côté de tes interfaces. C'est le mauvais choix si tu veux juste un constructeur CRUD rapide.

5. BaseVolt (local-first, application de bureau)

Je vais être direct sur mon parti pris ici : je suis impliqué dans BaseVolt, donc prends cette section avec le scepticisme approprié et va vérifier par toi-même. Mais je l'inclus parce que c'est la seule option de cette liste qui adopte une approche architecturale fondamentalement différente, et cette approche est tout l'enjeu de cet article.

BaseVolt est une application de bureau local-first. Pas une application web que tu auto-héberges. Pas un conteneur Docker. Une application native que tu installes sur ton Mac ou ta machine Windows, comme tu installerais une interface graphique de base de données comme TablePlus ou DBeaver. Quand tu connectes BaseVolt à ta base de données, la connexion est directe — de ta machine, vers ta base de données, par le chemin réseau que tu utiliserais pour n'importe quel autre client de base de données. Il n'y a pas de serveur intermédiaire. Pas de compte cloud. Pas de Docker. Pas d'infrastructure à maintenir.

Le compromis est évident et je veux le dire d'emblée : c'est une application de bureau, pas une interface web partagée. Si tu as besoin d'un outil que toute ton équipe accède via un navigateur, BaseVolt n'est pas le bon choix. C'est pour la personne ou le petit groupe qui administre une base de données directement — la même personne qui aurait sinon TablePlus ouvert dans une fenêtre, une application Retool dans une autre, et un terminal avec psql dans une troisième. BaseVolt remplace la partie panneau d'administration de cette configuration, pas la partie application web partagée.

Ce que BaseVolt t'apporte : un panneau d'administration pour SQLite, PostgreSQL, MySQL et Cloudflare D1, avec des vues grid, gallery, kanban et dashboard sur tes données. Un serveur MCP intégré pour connecter un assistant IA (Claude, Cursor, ce que tu utilises) afin de t'aider à gérer ton schéma — générer des migrations, explorer des tables, écrire des requêtes. Une synchronisation entre appareils si tu la veux (palier Pro), pour que tes vues et connexions enregistrées te suivent d'une machine à l'autre. Un support hors ligne, parce que tout tourne localement et que tes données sont tes données.

Le palier gratuit supporte jusqu'à 2 sources de données, ce qui suffit pour l'essayer sérieusement sur une vraie base de données. Pro est à $99/an et ajoute la synchronisation entre appareils et des sources de données illimitées. Pas de mur d'inscription, pas de carte de crédit pour commencer — tu télécharges l'application et tu te connectes à une base de données.

BaseVolt est le bon choix si : tu es la personne qui administre une base de données, tu veux une connexion directe sans serveur au milieu, et tu n'as pas besoin d'une interface web partagée pour une équipe plus large. C'est le mauvais choix si tu construis des outils pour des utilisateurs non techniques qui y accéderaient via un navigateur.

Tableau comparatif

|| | Retool (Cloud) | Retool (Self-Hosted) | Appsmith | ToolJet | Budibase | BaseVolt | ||---|---|---|---|---|---|---| || Déploiement | SaaS, hébergé par Retool | Auto-hébergé (Docker), offre Enterprise | Auto-hébergé (Docker/K8s) | Auto-hébergé (Docker/K8s) | Auto-hébergé (Docker) | Application de bureau (macOS, Windows) | || Flux de données | Navigateur → Retool cloud → ta base | Navigateur → ton instance → ta base | Navigateur → ton instance → ta base | Navigateur → ton instance → ta base | Navigateur → ton instance → ta base | Application de bureau → ta base (direct) | || Temps d'installation | Minutes (inscription, connexion base) | Heures à jours (Docker, infra, achat Enterprise) | Heures (déploiement Docker, config) | Heures (déploiement Docker, config) | Heures (déploiement Docker, config) | Minutes (téléchargement, connexion base) | || Constructeur d'app vs. panneau d'admin | Constructeur d'app complet | Constructeur d'app complet | Constructeur d'app complet | Constructeur d'app complet | Constructeur d'app low-code, axé CRUD | Panneau d'administration avec vues (grid, gallery, kanban, dashboard) | || IA | Génération d'app par IA, écriture de requêtes par IA | Génération d'app par IA, écriture de requêtes par IA | Construction assistée par IA | Construction assistée par IA | Construction assistée par IA | Serveur MCP intégré pour la gestion de schéma assistée par IA | || Coût | Palier gratuit, puis $10+/utilisateur/mois | Tarification Enterprise (parlez à nos commerciaux) | Auto-hébergé gratuit, cloud payant | Auto-hébergé gratuit, cloud payant | Auto-hébergé gratuit, cloud payant | Gratuit (2 sources), Pro $99/an | || Serveur à maintenir | Non (Retool le maintient) | Oui | Oui | Oui | Oui | Non | || Idéal pour | Équipes à l'aise avec le flux cloud et voulant le constructeur le plus soigné | Grandes équipes avec budget Enterprise et exigences strictes de résidence des données | Équipes voulant un Retool open-source avec licence permissive | Équipes voulant un Retool open-source, à l'aise avec l'AGPL | Équipes construisant des apps CRUD, nécessitant peut-être une base interne | Administrateurs individuels ou petites équipes voulant une connexion directe sans serveur |

Le spectre : Cloud → Auto-hébergé → Local-first

Je pense que la façon la plus claire de cadrer ce choix est un spectre de proximité de tes données.

Cloud (Retool Cloud, Appsmith Cloud, ToolJet Cloud, Budibase Cloud) : Tes données sont le plus loin de toi. Elles transitent par les serveurs d'un vendeur. Tu as l'installation la plus facile, le moins de maintenance et l'expérience la plus soignée — mais tu échanges la proximité des données contre de la commodité. C'est le bon bout du spectre pour les équipes où le flux de données n'est pas une préoccupation.

Auto-hébergé (Retool auto-hébergé, Appsmith, ToolJet, Budibase, Windmill) : Tes données sont plus proches. Elles restent sur ton réseau, transitant par une infrastructure que tu contrôles. Tu prends la maintenance du serveur comme coût — mises à jour, sauvegardes, disponibilité, contrôle d'accès. C'est le milieu du spectre, et c'est là qu'atterrissent la plupart des équipes avec des préoccupations de données. Tu as l'expérience application web (accès partagé via un navigateur) sans le flux de données tiers.

Local-first (BaseVolt) : Tes données sont au plus près. Il n'y a pas de serveur du tout — l'application parle directement à ta base de données depuis ta machine. Tu renonces à l'interface web partagée, et en échange tu élimines entièrement le serveur. Pas de maintenance, pas de Docker, pas de compte cloud, pas d'infrastructure intermédiaire d'aucune sorte. C'est le bout le plus lointain du spectre, et c'est le bon bout pour les administrateurs individuels et les petites équipes qui n'ont pas besoin de l'interface web partagée.

La plupart des articles sur les alternatives à Retool présentent ça comme un binaire : cloud contre auto-hébergé. Je pense qu'il est plus utile de le voir comme un spectre, parce que la vraie question n'est pas « cloud ou auto-hébergé » — c'est « à quelle distance dois-tu garder tes données, et qu'es-tu prêt à sacrifier pour ça ? » Le cloud sacrifie la proximité des données pour la commodité. L'auto-hébergé sacrifie la commodité (maintenance du serveur) pour la proximité des données. Le local-first sacrifie l'interface web partagée pour une proximité maximale des données et zéro maintenance.

Il n'y a pas de réponse universellement juste. Il y a la bonne réponse pour ta situation spécifique, qui dépend de ce que sont tes données, de qui doit y accéder, de tes contraintes de conformité et de la quantité d'infrastructure que tu es prêt à faire tourner.

Quand chaque approche gagne

Faisons ça concret, parce que les cadres abstraits ne sont utiles que jusqu'à ce que tu doives prendre une vraie décision.

Utilise Retool Cloud si : Tes données ne sont pas assez sensibles pour s'inquiéter du flux tiers, tu veux l'expérience constructeur la plus soignée, tu veux la génération d'app par IA, et tu préfères payer par utilisateur plutôt que maintenir une infrastructure. C'est la plupart des équipes, honnêtement. Retool est le défaut pour une raison, et si la préoccupation du flux de données ne s'applique pas à toi, pas besoin de trop réfléchir.

Utilise Retool auto-hébergé si : Tu as spécifiquement besoin de Retool (le constructeur, l'écosystème, le soin), tu as un budget Enterprise, et tu as une exigence de conformité qui impose l'auto-hébergement. C'est un cas étroit — les grandes entreprises avec des standards d'outillage spécifiques et le budget qui va avec.

Utilise Appsmith si : Tu veux un constructeur type Retool, tu veux de l'open-source avec une licence permissive (Apache 2.0), et tu as l'infrastructure pour l'auto-héberger. Appsmith est le choix open-source le plus sûr si tu doutes de la licence — Apache 2.0 est bien comprise et crée rarement de friction juridique.

Utilise ToolJet si : Tu veux un constructeur type Retool, l'AGPL v3 ne te dérange pas (ou ton équipe juridique l'a validée), et tu préfères l'approche spécifique de ToolJet. Entre Appsmith et ToolJet, la licence est souvent le facteur décisif. Si l'AGPL n'est pas un problème pour ton cas d'usage, choisis celui dont le constructeur te plaît le plus après un essai.

Utilise Budibase si : Tes outils internes sont principalement des applications CRUD — formulaires, tables, gestion d'enregistrements — et tu veux peut-être une base de données intégrée pour l'état spécifique à l'application. Budibase est plus opinaitré qu'Appsmith ou ToolJet, ce qui est une fonctionnalité si tes outils correspondent à son modèle et une limite sinon.

Utilise Windmill si : Tes outils internes impliquent de la vraie logique — workflows multi-étapes, exécution de scripts, orchestration d'API, tâches planifiées — et tu veux que cette logique soit du code versionné plutôt que des snippets JavaScript dans un constructeur. Windmill est la seule option ici qui traite les scripts comme des citoyens de première classe, et si tes outils sont lourds en scripts, c'est le bon choix même si ce n'est pas un remplacement pur de Retool.

Utilise BaseVolt si : Tu es la personne qui administre directement une base de données, tu veux une connexion directe sans serveur au milieu, et tu n'as pas besoin d'une interface web partagée pour une équipe plus large. BaseVolt remplace la partie outil d'administration de ton workflow — celle où tu aurais sinon une interface graphique de base de données ouverte à côté d'une application Retool — par une seule application local-first qui se connecte directement. Ce n'est pas un remplacement de Retool pour les équipes qui construisent des outils web partagés. C'est un remplacement de Retool pour l'administrateur individuel qui n'avait jamais besoin d'un outil web partagé en premier lieu.

En résumé

Retool est bon. Les alternatives open-source (Appsmith, ToolJet, Budibase, Windmill) sont bonnes. Elles méritent toutes ton attention si la préoccupation du flux de données est ce qui te pousse loin de Retool Cloud, et elles résolvent toutes le problème de la même façon : en mettant un serveur sur ton infrastructure plutôt que sur celle du vendeur. C'est une solution légitime, et pour les équipes qui ont besoin d'une interface web partagée, c'est la bonne.

Mais si tu es un administrateur individuel ou une petite équipe, et que tu maintiens une instance Appsmith auto-hébergée uniquement pour que tes requêtes de base de données ne passent pas par un tiers, ça vaut la peine de te demander si tu as vraiment besoin du serveur. Beaucoup d'outils internes, c'est une personne ou un petit groupe qui travaille directement avec une base de données. Pour ce cas, une application de bureau local-first qui se connecte directement à ta base de données — pas de serveur, pas de Docker, pas de compte cloud, pas de maintenance — est une architecture plus simple qui résout le même problème avec moins de pièces en mouvement.

C'est le vide que BaseVolt comble. Ce n'est pas pour tout le monde, et j'ai essayé d'être honnête sur là où ça ne colle pas. Mais si tu es le genre de personne qui préfère installer une application plutôt que déployer un conteneur, et que tu veux que ta connexion à la base de données soit aussi directe que celle de ton interface graphique de base de données, ça vaut le coup d'y regarder.

Essayez-le sur basevolt.app — pas d'inscription, pas de carte de crédit. Connecte-le à une base de données et regarde si le modèle de connexion directe te convient. La démo est sur demo.basevolt.app si tu veux d'abord regarder.

Si tu as des questions, des retours, ou que tu veux débattre de savoir si Appsmith auto-hébergé est réellement meilleur pour ton cas (c'est possible), retrouvez-moi sur X.