Lorsque vous choisissez une stack technique pour votre application web, vous ne choisissez pas seulement une expérience de développement. Vous choisissez un modèle de facturation. Pendant des années, le développement visuel était régi par des plans d’hébergement simples. Vous payiez un forfait mensuel pour un palier, et vous aviez une allocation fixe de capacité serveur.
Cela a changé quand Bubble a introduit les Workload Units (WUs). Au lieu de facturer l’espace visuel ou les limites de taille de base de données, ils ont commencé à facturer chaque action individuelle exécutée par votre base de données, votre système logique et vos chargements de page. À peu près au même moment, la montée du « vibe coding » et des builders IA a introduit un modèle de facturation différent : la tarification API basée sur les tokens.
Si vous hésitez entre un builder visuel comme Bubble et une stack native IA, vous devez comprendre comment ces systèmes évoluent. Une application qui coûte cinquante dollars par mois pendant votre phase de test peut facilement grimper à des centaines ou des milliers de dollars une fois que de vrais utilisateurs commencent à interagir avec elle. Analysons l’évolution des coûts des bases de données, des déclencheurs logiques et des crédits selon les deux modèles.
Comment fonctionnent réellement les Workload Units de Bubble
Pour comprendre l’économie de Bubble, il faut regarder la Workload Unit. Une WU est une mesure créée par Bubble pour quantifier la puissance de calcul utilisée par votre app. Chaque fois que votre application effectue une action sur le serveur, Bubble effectue un calcul et déduit des WUs de votre forfait mensuel.
Avec le forfait Starter d’entrée de gamme ($69 par mois), vous disposez de 175 000 WUs. Avec le forfait Growth ($249 par mois), vous avez 250 000 WUs. Ces chiffres semblent élevés jusqu’à ce que vous voyiez à quelle vitesse ils disparaissent.
Les WUs sont consommées par :
- Opérations de base de données : Lecture, écriture, modification ou suppression d’enregistrements.
- Déclencheurs de workflow : Exécution d’actions personnalisées, de conditions ou de workflows backend.
- Requêtes API Connector : Envoi de données à des services externes ou réception de webhooks.
- Surcharge de page : Chargement de composants visuels et exécution des workflows initiaux de la page.
Le problème de ce modèle n’est pas le prix en soi, mais la volatilité. Parce que le langage de programmation visuel de Bubble est compilé sur leurs serveurs, vous n’avez aucun contrôle direct sur l’efficacité de l’exécution de ce code. Une seule requête de recherche non optimisée peut scanner l’intégralité de votre base de données, consommant des milliers de WUs en quelques secondes.
La mécanique des API IA et de la tarification par tokens
De l’autre côté de l’équation économique se trouve la tarification basée sur les tokens. Si vous construisez une application avec des générateurs de code IA comme Lovable ou Bolt, ou si vous écrivez du code personnalisé qui interface avec des LLM bruts, votre facturation est déterminée par les tokens d’entrée et de sortie.
Les tokens sont les unités de texte de base traitées par une IA. Mille tokens correspondent environ à 750 mots. Le modèle de tarification ici est linéaire et centré sur le développeur :
- Coûts de développement : Vous payez des tokens lorsque vous demandez à l’IA d’écrire ou de modifier le code de votre application. Une fois le code écrit, il s’exécute sur une infrastructure cloud standard (comme Vercel, Supabase ou Netlify), qui est généralement gratuite ou forfaitaire pour un trafic modéré.
- Coûts IA d’exécution : Si votre app utilise des fonctionnalités IA - comme une interface de chat ou un résumé automatique de documents - vous payez le fournisseur du modèle (tel qu’Anthropic ou OpenAI) pour chaque interaction utilisateur.
Cela signifie que vos coûts d’hébergement restent bas et prévisibles, tandis que vos coûts de développement sont variables. Cependant, si votre application tourne dans une boucle automatisée, ou si vous entrez dans une boucle de débogage de régression pendant le développement, votre consommation de tokens peut augmenter considérablement.
Comparaison des modèles économiques
Voyons comment ces composants de tarification se comparent pour des tâches opérationnelles courantes.
| Tâche opérationnelle | Bubble Workload Units (WUs) | Tarification API AI / Tokens |
|---|---|---|
| Requêtes de base de données | Consomme des WUs par enregistrement récupéré. Les grandes tables ou les recherches imbriquées entraînent une consommation élevée. | Payé via l’hôte de la base de données (tarif forfaitaire ou basé sur le stockage, généralement peu coûteux). |
| Logique métier | Les workflows et les déclencheurs visuels consomment des WUs pour chaque étape. Les planificateurs ajoutent une consommation continue. | Exécuté via des fonctions serverless (très abordable, souvent gratuit pour des millions d’exécutions). |
| Intégrations externes | L’API Connector consomme des WUs proportionnellement à la taille de la charge utile. | Frais d’appel API standards (frais de transit réseau négligeables). |
| Fonctionnalités AI | Consomme des WUs pour l’API Connector plus les frais de tokens du fournisseur AI direct. | Facturation linéaire basée sur le nombre exact de tokens d’entrée et de sortie. |
| Maintenance de l’app | Coût d’abonnement forfaitaire pour l’accès à l’éditeur, sans frais pour les mises à jour visuelles. | Coûts variables en crédits ou tokens pour demander à l’AI des corrections de bugs et des changements. |
Mise à l’échelle de la base de données : le vrai moteur des coûts
Les bases de données sont la source la plus courante de surprises de facturation. Dans Bubble, l’optimisation de la structure des données est obligatoire. Si vous créez un type de donnée appelé “Project” et que vous le liez à une liste de “Tasks”, une recherche de projets chargera les tâches associées. Le serveur de Bubble gère ce mappage relationnel visuellement, ce qui consomme des WUs pour chaque enregistrement chargé. Si vous avez 5 000 tâches et que vous les interrogez sans contraintes strictes, vous verrez votre solde de WUs chuter rapidement.
À l’inverse, si votre application utilise une base de données dédiée comme PostgreSQL ou Supabase, la mise à l’échelle repose sur les ressources de calcul ou la taille du stockage des données. Une requête qui parcourt 10 000 enregistrements ne prend que quelques millisecondes de temps CPU. Les hôtes de bases de données standards vous facturent l’espace de stockage (par exemple 10 $ par mois pour plusieurs gigaoctets) plutôt que de compter chaque lecture ou écriture individuelle.
Déclencheurs de logique et workflows : coûts prévisibles vs variables
L’exécution des déclencheurs de logique met en évidence l’écart d’efficacité entre les plateformes visuelles propriétaires et l’infrastructure serverless standard.
Dans Bubble, chaque workflow logique s’exécute sur le cluster de serveurs de Bubble. Si vous configurez un workflow qui se lance au clic d’un bouton, évalue trois conditions, met à jour un enregistrement et envoie un e-mail, chaque étape coûte des WUs. Si vous lancez un workflow backend pour traiter des données en masse, il exécutera des boucles qui consomment des milliers de WUs. Les créateurs se plaignent souvent que la logique métier normale coûte trop cher à faire tourner en production.
Avec une app générée par AI, votre logique backend est généralement compilée en code JavaScript ou Python léger. Ce code s’exécute sur des plateformes serverless où vous bénéficiez de millions de millisecondes d’exécution gratuites chaque mois. Vous ne payez pas pour cliquer sur un bouton ou évaluer une condition “si”. Vous ne payez que si vous effectuez des appels directs à un modèle AI externe pendant l’exécution, et cela évolue de manière linéaire.
L’alternative hybride avec Softr
Si vous voulez créer une application métier fonctionnelle sans rester bloqué dans les calculs de WUs ou des boucles de prompting constantes, une plateforme hybride comme Softr offre une solution pratique.
Softr fonctionne sur un modèle d’abonnement prévisible. Vous payez un tarif mensuel forfaitaire selon le plan choisi (Starter, Basic, Professional ou Business). Ce plan vous donne des limites fixes sur le nombre d’utilisateurs de l’app et d’enregistrements en base de données, plutôt que de vous facturer chaque requête de recherche ou vue de page.
Softr gère la mise à l’échelle des bases de données et les déclencheurs de logique via une structure hybride :
- Bases de données relationnelles natives : Softr inclut une base de données conçue pour les opérations métier. Vous pouvez importer des enregistrements, établir des relations et lancer des requêtes sans craindre de pénalités basées sur l’utilisation.
- AI Co-Builder : Vous pouvez utiliser l’AI Co-Builder pour générer rapidement des pages, des bases de données et des workflows. Bien que cela utilise une allocation mensuelle de crédits, c’est totalement optionnel. Vous pouvez construire, modifier et maintenir toute votre application visuellement dans le studio sans utiliser de crédits.
- Vibe Coding isolé : Si vous avez besoin de composants personnalisés, vous pouvez utiliser le bloc Vibe Coding pour générer des éléments spécifiques sans régénérer tout le code source de l’application.
Cette approche vous offre la rapidité de la génération par AI avec la prévisibilité des coûts d’un hébergement forfaitaire. Vous ne recevrez pas de factures surprises parce qu’un utilisateur a chargé un tableau de bord ou déclenché un workflow logique basique.
Conseils pratiques pour les créateurs
Lorsque vous décidez comment allouer votre budget, gardez ces directives à l’esprit :
- Choisissez des options forfaitaires pour les outils internes à fort trafic : si votre équipe charge constamment des tableaux et met à jour des enregistrements, une plateforme forfaitaire comme Softr vous protégera des pics de WUs.
- Optimisez vos requêtes de base de données dès le début : si vous devez construire sur Bubble, utilisez des contraintes sur toutes les recherches pour éviter de charger des champs ou des relations inutiles.
- Isolez vos fonctionnalités AI : si vous intégrez des appels LLM, configurez des limites de débit et mettez les réponses en cache pour éviter de payer pour des prompts identiques.
En adaptant l’architecture de votre application au bon modèle économique, vous pouvez créer des outils qui restent abordables à mesure que votre entreprise grandit.