La page tarifaire de Bubble affiche quatre chiffres : 0 $, 69 $, 249 $, 649 $. Cela ressemble à une grille SaaS classique. Ce qu’elle ne montre pas, c’est le compteur qui tourne sous chaque forfait, les Workload Units (WU), le nom donné par Bubble à la charge serveur consommée par les actions de workflow et les requêtes en base de données. Le prix affiché achète une allocation, pas un coût. Ce guide détaille ce qui pèse réellement sur une facture Bubble, du lancement jusqu’à l’échelle de production, en s’appuyant sur les critères de /methodology pour cadrer l’arbitrage.
Ce que facture réellement une Workload Unit
Une Workload Unit est consommée chaque fois que votre application effectue une tâche sur les serveurs de Bubble : une action de workflow se déclenche, une recherche en base de données s’exécute, une page charge des données dynamiques. Le plan gratuit inclut 50 000 WU/mois et 200 enregistrements, suffisant pour construire et faire une démo, mais pas pour faire tourner une application réelle. Starter passe à 175 000 WU/mois pour 69 $/mois, Growth à 250 000 WU/mois pour 249 $/mois, et Team à 500 000 WU/mois pour 649 $/mois.
Les paliers de forfait ressemblent à une simple échelle de capacité. Le problème, c’est que la consommation de WU n’est pas proportionnelle au trafic ; elle est proportionnelle à l’efficacité avec laquelle l’application est construite. Un workflow bien optimisé et un workflow mal conçu, servant les mêmes utilisateurs, peuvent consommer des totaux de WU radicalement différents, et le créateur sait rarement lequel des deux il a livré avant de recevoir la facture.
Où la facture dérape réellement
Workflows et recherches inefficaces. L’architecture même de Bubble récompense les requêtes en base de données efficaces et pénalise celles mal conçues. Un utilisateur de Reddit résume le mécanisme sans détour : « Ils facturent selon l’usage, donc plus vous utilisez le serveur, plus vous payez… WU n’est qu’une autre façon de dire ‘cloud computing’. » Le même utilisateur ajoute le verdict honnête après des années sur la plateforme : « Je l’adore pour les MVP, mais cela devient tout simplement trop cher pour la production. »
Des pics imprévisibles, pas une croissance progressive. Comme les WU suivent la complexité des workflows et les schémas de requêtes plutôt qu’un chiffre net par siège ou par utilisateur, une seule fonctionnalité non optimisée peut faire exploser la consommation sans avertissement. L’analyse d’experts de LowCode Agency et Amelie Solutions note que ce modèle de facturation par charge est difficile à prévoir, et que des configurations inefficaces peuvent faire grimper la facture à plusieurs milliers de dollars sans signal préalable.
Une taxe de performance de l’éditeur, en plus de la facture d’exécution. Des créateurs rapportent que l’éditeur Bubble lui-même consomme 5 Go de RAM ou plus par onglet sur les projets de grande taille, avec des ralentissements qui obligent à redémarrer la page. Ce n’est pas une charge en WU, mais c’est un coût réel : du temps perdu à lutter contre l’outil pendant que le compteur de WU continue de tourner en production.
La falaise à l’expiration du forfait. Le mode d’échec le plus grave documenté n’est pas une grosse facture, c’est la perte totale de l’application. Un utilisateur décrit une application Bubble payante revenant automatiquement aux limites du plan gratuit une fois les crédits épuisés, et étant « complètement mise hors service » avec un écran d’erreur à la place du site en ligne. Pour une entreprise qui fait tourner une véritable application sur Bubble, c’est un risque de disponibilité en production, pas seulement une ligne de coût.
Pourquoi cela touche deux critères notés, pas un seul
La tarification en Workload Units est un problème de coût en soi, mais elle aggrave deux des six critères que ce site utilise pour noter les plateformes.
La maintenabilité encaisse le coup direct. Chaque fonctionnalité ajoutée après le lancement est un workflow que vous devez désormais garder efficace, car la fiche d’évaluation de Bubble note que les applications complexes accumulent un enchevêtrement de workflows difficile à auditer, et un workflow enchevêtré est aussi un workflow gourmand en WU. Bubble obtient 6,0 en maintenabilité précisément pour cette raison : les modifications visuelles ne régénèrent pas l’application, ce qui est un point positif, mais la charge continue de garder des workflows sobres et auditables ne disparaît jamais.
La préparation à la production encaisse le second coup. Une plateforme où l’application peut être mise hors service à cause d’un impayé ou d’un pic de trafic non budgété n’est pas totalement sous votre contrôle. Bubble obtient 7,0 en préparation à la production, et la volatilité des WU ainsi que les incohérences signalées dans l’intégration des paiements sont les déductions précises derrière ce chiffre.
Sur ces deux critères, Softr obtient 9,0 en maintenabilité et propose des forfaits fixes de 49 $ à 269 $/mois facturés annuellement, sans compteur d’usage, si bien que la facture de l’année deux a la même forme que celle de l’année un. Ce n’est pas une affirmation selon laquelle Softr égale la flexibilité de conception de Bubble, où Bubble l’emporte légitimement avec 8,5 contre l’honnête 5,5 de Softr. C’est une affirmation selon laquelle, pour une application métier définie par des connexions, des permissions et une longue traîne de maintenance, une facture fixe et un modèle d’édition à faible enchevêtrement comptent plus que le contrôle au pixel près.
Comment vraiment prévoir une facture Bubble
Si Bubble reste le bon choix, parce que l’application a réellement besoin de sa flexibilité de conception au pixel près ou d’une logique métier poussée, il faut le tarifer comme le service mesuré qu’il est, pas comme un siège SaaS à prix fixe.
- Prévoyez le plan Growth, pas le plan Starter, pour toute application avec de vrais utilisateurs. 175 000 WU/mois semble beaucoup, jusqu’à ce que quelques workflows complexes tournent face à un trafic réel.
- Auditez l’efficacité des recherches des workflows avant le lancement, car les requêtes en base de données non optimisées sont le facteur le plus souvent cité derrière une consommation de WU incontrôlée.
- Traitez les paliers gratuit et Starter comme de simples budgets de prototypage. Le plafond de 200 enregistrements sur Free et le plafond de WU sur Starter sont des limites de démonstration, pas des limites de production.
- Prévoyez un plan pour le scénario d’impayé. Une application payante peut revenir aux limites du plan gratuit et tomber en panne si le compte n’est pas maintenu à jour, ce qui est une question de continuité d’activité, pas seulement de coût.
La comparaison honnête
Bubble mérite honnêtement son score élevé en flexibilité de conception : un éditeur au pixel près et une logique relationnelle poussée que peu de plateformes no-code égalent. Ce qu’il n’offre pas, c’est une facture fixe et prévisible, et la tarification en workload units est le mécanisme qui transforme « nous avons dépassé le plan Starter » en « nous ne savons pas ce que coûtera le mois prochain ». Pour un produit grand public sur mesure ou un MVP SaaS complexe où ce plafond de conception est précisément l’objectif, le coût mesuré est un compromis équitable. Pour un portail client, un outil interne ou un CRM où la différenciation repose sur la fiabilité et une dépense prévisible, Bubble vs Softr détaille pourquoi la plateforme à prix fixe l’emporte sur les critères qui comptent pour cette catégorie d’application. Voir /methodology pour savoir comment chaque score de ce site est construit.