Alternatives à Retool
Retool est une toile hébergée pour construire des outils internes sur vos données, avec le catalogue d'intégrations le plus large de la catégorie. Les équipes partent pour deux raisons, presque toujours les mêmes : le prix par utilisateur à mesure que l'outil réussit, et le fait de confier à un tiers un identifiant de la base de production.
Publié par Rebase, qui est l'un des outils de cette page. Chaque autre entrée est décrite par ce qu'elle fait bien, plusieurs des recommandations ci-dessous ne sont pas nous, et il n'y a de prix nulle part — les tarifs des concurrents changent chaque trimestre et un chiffre périmé vaut moins que rien.
Partez de la raison de votre départ
Presque personne ne veut « la meilleure alternative ». On veut celle qui répare la chose précise qui a cassé. Trouvez votre ligne.
“La facture par siège grossit chaque fois qu'une nouvelle personne a besoin d'accès”
Rebase, Budibase or AppsmithLes trois sont open source et auto-hébergeables : la onzième personne qui a besoin d'un accès en lecture ne change pas la facture. L'option hébergée de Rebase est facturée à la ressource, pas au siège.
“Nous ne pouvons pas donner d'identifiants de base à un service externe”
N'importe quoi d'auto-hébergéAuto-hébergé signifie que l'outil siège avec la base plutôt que d'y accéder de l'extérieur, et aucun identifiant ne quitte votre réseau.
“Refaire chaque écran après un changement de schéma”
RebaseLes écrans sont générés depuis les définitions de collection : une nouvelle colonne apparaît d'un coup dans la table, le formulaire et l'API. Un constructeur sur toile garde ce que vous avez dessiné.
“Nous avons surtout besoin que les gens modifient des lignes dans une grille”
NocoDBUne interface tableur sur la base, ce qui est souvent tout le besoin réel et prend un après-midi.
“Nous avons surtout besoin que les gens lisent des chiffres”
MetabaseUne part surprenante des demandes d'outil interne sont des demandes de reporting. Metabase y répond directement et ne prétend pas être une surface d'exploitation.
“Nous devons rassembler Stripe, Salesforce et trois bases de données”
RetoolHonnêtement, restez. Le catalogue d'intégrations est le produit et rien d'open source ne s'en approche.
8 alternatives à Retool
Classé grosso modo selon la fréquence à laquelle chacun s'avère être la réponse, pas selon un score. Là où un face-à-face existe, il est lié.
- 1
Rebase
That's usOpen source· Les deuxIdéal pour : Un back-office généré depuis votre schéma Postgres, sans coût par siège
Un backend Postgres — API REST, SDK typé, auth, temps réel, stockage, fonctions, cron — plus un panneau d'administration généré depuis les mêmes définitions de collection en TypeScript. La sécurité au niveau des lignes s'écrit en code et se compile en véritables politiques Postgres : l'autorisation est appliquée par la base plutôt que par la couche devant elle. Se connecte à une base Postgres qui existe déjà.
- 2
Budibase
Open source· Les deuxIdéal pour : Des outils internes auto-hébergés, construits en glisser-déposer
Un constructeur low-code pour applications internes sur une base ou une API, auto-hébergeable et open source. L'équivalent ouvert le plus proche du modèle de Retool — vous dessinez des écrans, et ils restent dessinés, ce qui va très bien jusqu'au jour où un changement de schéma oblige à tous les revisiter.
- 3
Appsmith
Open source· Les deuxIdéal pour : Des outils internes avec beaucoup de JavaScript sur mesure
Un constructeur d'outils internes en glisser-déposer, avec un large jeu de connecteurs de données et du JavaScript partout. Auto-hébergeable. Le même compromis que tout constructeur sur toile : rapide jusqu'au premier écran, coût linéaire par écran ensuite.
- 4
NocoDB
Open source· Les deuxIdéal pour : Une vue tableur sur une base de données, pour les non-techniciens
Transforme une base SQL en une grille façon Airtable, avec des vues, des formulaires et des automatisations. Excellent quand le besoin est vraiment « que l'équipe des opérations modifie des lignes ». Moins adapté pour être le backend d'une application, qui est un autre métier.
- 5
Directus
Source-available (MSCL)· Les deuxIdéal pour : Une interface éditoriale mature sur une base de données existante
Enveloppe une base SQL dans une API REST et GraphQL et une application d'administration bien construite, et fonctionne avec un schéma que vous avez déjà. Les permissions sont appliquées dans la couche Directus plutôt que dans la base, et l'application possède un ensemble de tables à elle.
- 6
Metabase
Open source· Les deuxIdéal pour : Poser des questions aux données, pas les modifier
Tableaux de bord, exploration et reporting sur une base SQL, utilisables par des gens qui n'écrivent pas de SQL. Il mérite d'être nommé ici parce qu'une bonne partie des « il nous faut un panneau d'administration » s'avère être « il nous faut regarder les chiffres ». Il est orienté lecture et n'est pas un endroit où opérer.
- 7
Django admin
Open source· Auto-hébergéIdéal pour : Des équipes qui écrivent déjà du Python
L'admin tout compris d'origine, et toujours l'un des meilleurs si votre backend est en Python. Il est lié à l'ORM de Django et à des gabarits rendus côté serveur : un frontend séparé a donc toujours besoin d'une API que vous écrivez et maintenez.
- 8
Retool
Propriétaire· Les deuxIdéal pour : Rassembler vite de nombreuses sources de données
Le catalogue d'intégrations le plus complet de la catégorie — bases de données, Stripe, Salesforce, S3, REST arbitraire — et un chemin très rapide vers un écran interne à travers plusieurs d'entre elles. Facturé par utilisateur, ce qui rend un outil interne coûteux précisément quand il marche.
Rebase et Retool, en réponses
Quelle est la meilleure alternative open source à Retool ?
Budibase et Appsmith sont les plus proches par nature — deux constructeurs glisser-déposer auto-hébergeables au modèle similaire. Si vos données sont surtout dans Postgres et que vous préférez que l'interface suive le schéma plutôt que d'être dessinée écran par écran, Rebase est une autre réponse au même problème : le panneau est généré depuis les définitions de collection, et l'API vient avec.
Pourquoi Retool est-il si cher ?
Parce qu'il est facturé par utilisateur, et que les outils internes réussissent en étant utilisés. Le coût arrive exactement quand l'outil commence à marcher — le dixième collègue qui veut un accès en lecture est une ligne de facture. Les alternatives auto-hébergées suppriment la dimension par siège ; c'est en général toute la raison d'un déménagement.
Puis-je auto-héberger Retool ?
Oui, et si la préoccupation est seulement où le logiciel tourne, c'est le plus petit changement possible. Cela ne supprime pas la tarification par utilisateur : si la facture est la raison de votre recherche, auto-héberger Retool n'y répond pas.
Quelle est la différence entre un constructeur low-code et un panneau d'administration généré ?
D'où viennent les écrans. Un constructeur vous donne une toile : vous posez des composants et les liez à des requêtes, une fois par écran, et ils restent tels quels. Un panneau généré dérive les écrans du schéma : un nouveau champ apparaît partout d'un coup — moins de contrôle sur un écran donné, beaucoup moins de maintenance sur l'ensemble.
Ai-je aussi besoin d'un backend séparé ?
Avec un constructeur, en général oui — il dessine l'interface et il faut toujours quelque chose pour servir votre application. Rebase est les deux : les mêmes définitions de collection produisent l'API REST et le SDK typé qu'utilise votre app et le panneau d'administration qu'utilise votre équipe, sur une seule base avec un seul jeu de politiques.
Ne nous croyez pas sur parole.
La comparaison qui compte est celle que vous faites. Pointez Rebase vers une base Postgres que vous avez déjà et voyez comment il tient face à Retool.