← Resources
By Marcus Okafor
— Platform Engineer, Apps
·
· GUIDE
Alternative à Retool auto-hébergée : outils internes sans frais par siège
Les constructeurs d'outils internes low-code sont une couche d'interface sur des données hébergées ailleurs, facturée par siège de constructeur et par siège de spectateur. Ce guide explique le piège du tarif par siège, le plafond de personnalisation et pourquoi un constructeur orienté code avec backend inclus change l'économie du modèle.
Comment fonctionnent réellement les constructeurs d'outils internes low-code
Des outils comme Retool, Appsmith, ToolJet et Budibase reposent sur un canvas visuel en glisser-déposer : vous assemblez des composants prêts à l'emploi — tableaux, formulaires, boutons, graphiques — et les reliez aux données via des requêtes. En réalité, ce sont des couches d'interface sur des données hébergées ailleurs. Elles se connectent à vos Postgres, MySQL, Snowflake, API REST ou feuilles de calcul existants plutôt que de stocker quoi que ce soit elles-mêmes.
Cette architecture a une conséquence souvent sous-estimée : vous devez tout de même fournir et exploiter votre propre backend. La base de données, l'authentification, les secrets, la planification et toute logique côté serveur sont à votre charge, à héberger et à maintenir séparément. Le constructeur vous donne les écrans, pas le moteur d'exécution qui les sous-tend.
Le piège du tarif par siège (et la surprise du siège spectateur)
La tarification de Retool est par siège, avec une distinction constructeur/spectateur. Sur le plan Business, un Constructeur coûte 50 $/utilisateur/mois (annuel) et un utilisateur interne coûte 15 $/utilisateur/mois ; le plan Team est à 10 $ par constructeur et 5 $ par utilisateur interne, et le plan gratuit est limité à cinq utilisateurs. La surprise pour la plupart des équipes, c'est que les spectateurs sont eux aussi payants : les personnes qui se contentent d'utiliser un outil sont facturées par siège au-delà du quota gratuit, si bien que le coût croît avec la taille de l'audience, pas seulement avec le nombre de développeurs. En plus des sièges, Retool empile des composants facturés à l'usage : exécutions de workflows mesurées, crédits IA non reportables et heures d'agent facturées séparément.
L'effet net : un outil que vous voulez voir adopté par tous devient plus cher précisément parce que tout le monde l'utilise.
Le plafond du glisser-déposer
Les constructeurs visuels sont rapides, jusqu'au moment où ils ne le sont plus. Le low-code finit inévitablement par atteindre un plafond de personnalisation, et la solution habituelle est une « trappe de sortie » : un bloc de code personnalisé. Le problème, c'est que cette trappe est souvent bridée : certains constructeurs ne prennent en charge que le JavaScript côté client, sans exécution côté serveur ; le style se limite au CSS inline ; et l'interface de workflow en organigramme devient illisible à mesure que la logique s'étoffe.
Le plafond apparaît à des points prévisibles : transformations de données ou algorithmes sur mesure, intégrations nécessitant un serveur hébergé et interfaces au-delà des composants prêts à l'emploi. Et comme la logique applicative vit dans le format propriétaire de l'éditeur, la plupart des constructeurs ne peuvent pas exporter un code source propre et lisible par des humains : le travail réalisé dans le canvas est donc difficile à emporter avec soi.
L'option open source et auto-hébergement
Une catégorie open source existe précisément pour échapper au coût par siège et à l'enfermement propriétaire. Appsmith est le plus important (des dizaines de milliers d'étoiles GitHub) ; ToolJet, Budibase, Lowcoder et NocoDB complètent le panorama. L'auto-hébergement change l'économie du modèle : Budibase, par exemple, autorise 20 utilisateurs sur son niveau gratuit auto-hébergé contre cinq pour Retool, avec SSO et intégration inclus.
Mais l'auto-hébergement n'est pas exempt de contraintes : il vous faut le savoir-faire technique pour déployer, maintenir et faire évoluer la solution, les niveaux payants verrouillent toujours les fonctionnalités premium, et la plupart de ces outils conservent la même architecture en glisser-déposer : vous héritez donc à la fois du plafond et de la contrainte d'apporter votre propre base de données, simplement sans la facture par siège.
IA native ou IA greffée après coup
La fracture 2025–2026 sur ce marché oppose les plateformes conçues autour de l'IA à celles qui greffent des fonctionnalités IA sur une architecture low-code déjà existante. Retool a ajouté des agents IA et des workflows IA ; Budibase a ajouté des workflows connectés à des LLM et un générateur de cron par IA. Dans chaque cas, l'IA est un nœud greffé doté de son propre pool de crédits, posé à côté d'un canvas conçu avant que l'IA ne compte. Cela suffit pour des cas simples du type « résumer ce champ », mais ce n'est pas la même chose qu'une application où appeler un modèle est une primitive de première classe dans le code.
La place d'osFoundry dans ce paysage
osFoundry inverse le modèle low-code. Il construit des applications internes sous forme de code réel et appropriable, avec le backend complet inclus — Postgres par application, secrets, KV, cron, fonctions serverless et un sous-domaine —, si bien qu'il n'y a aucune contrainte d'apporter sa propre base de données ni de plafond à contourner, car le code est lui-même la trappe de sortie. C'est de l'IA native plutôt que de l'IA greffée après coup : invokeAI est un appel de première classe dans le code applicatif, pas un pool de crédits distinct. Et la tarification est basée sur l'usage, pas sur le siège, si bien qu'ajouter des spectateurs ou des constructeurs ne multiplie pas une facture par tête — c'est exactement le piège de coût du modèle par siège. Vous échangez un canvas en glisser-déposer contre du vrai code et, en retour, vous obtenez le backend, l'IA et les données réunis en un seul endroit que vous pouvez exporter.
Frequently asked questions
- Quelle est la meilleure alternative auto-hébergée à Retool ?
- Parmi les constructeurs en glisser-déposer, Appsmith est la plus grande option open source, suivi de près par ToolJet, Budibase et Lowcoder — tous auto-hébergeables. Si vous voulez éviter complètement le plafond du glisser-déposer, une plateforme orientée code qui construit de vraies applications avec backend inclus (base de données, secrets, cron, fonctions) constitue un modèle différent qui supprime la contrainte d'apporter votre propre base de données. Choisissez selon que vous préférez un canvas visuel ou du vrai code.
- Pourquoi Retool est-il si cher ?
- Parce qu'il facture par siège, et les spectateurs comptent aussi. Sur le plan Business, un constructeur coûte 50 $/utilisateur/mois et un utilisateur interne 15 $/utilisateur/mois, auxquels s'ajoutent des exécutions de workflows mesurées, des crédits IA et des heures d'agent. Le coût croît avec le nombre de personnes qui utilisent vos outils, pas seulement avec celles qui les construisent : le succès les rend donc plus chers.
- Les constructeurs d'outils internes open source nécessitent-ils leur propre base de données ?
- La plupart, oui. Les constructeurs en glisser-déposer sont une couche d'interface qui se connecte à des données hébergées ailleurs, vous provisionnez et exploitez donc séparément votre propre base de données, authentification, secrets et planification. Une plateforme qui inclut une base de données par application, des secrets et un cron supprime entièrement cette charge opérationnelle.
- Les constructeurs d'outils low-code peuvent-ils exporter du vrai code source ?
- Généralement pas proprement. La logique applicative vit dans le format propriétaire du constructeur, et rares sont ceux qui peuvent exporter un code source lisible par des humains, ce qui rend la migration pénible. Si éviter l'enfermement propriétaire compte, privilégiez une plateforme où ce que vous construisez est du vrai code accompagné d'une base de données standard que vous pouvez emporter.
- Que se passe-t-il lorsque vous atteignez les limites d'un constructeur en glisser-déposer ?
- Vous basculez vers une trappe de sortie — un bloc de code personnalisé — souvent limité au JavaScript côté client, au CSS inline et à une interface de workflow qui devient ingérable à mesure que la logique s'étoffe. Le plafond apparaît typiquement lors de transformations de données sur mesure, d'intégrations nécessitant un serveur hébergé et d'interfaces au-delà des composants standard. Une plateforme orientée code n'atteint jamais ce plafond, car elle démarre avec du code.
- Appsmith, ToolJet ou Budibase est-il vraiment gratuit en auto-hébergement ?
- Le cœur open source est gratuit, et l'auto-hébergement relève les limites d'utilisateurs gratuits (Budibase autorise 20 utilisateurs contre 5 pour Retool). Mais vous prenez en charge vous-même le déploiement, la maintenance et la mise à l'échelle, et les niveaux payants verrouillent toujours les fonctionnalités premium et la tarification par créateur. « Gratuit » désigne la licence, pas le coût total d'exploitation.
- Quelle est la différence entre un constructeur IA-natif et un qui a greffé l'IA après coup ?
- Un constructeur à IA greffée après coup ajoute un nœud IA et un pool de crédits à côté d'un canvas conçu avant que l'IA ne compte — suffisant pour des tâches simples au niveau d'un champ. Une plateforme IA-native traite l'appel à un modèle comme une primitive de première classe dans le code applicatif : l'IA est donc tissée dans la logique de l'outil plutôt que reléguée dans un bloc distinct.
Sources