Optimiser une app Bubble : réduire les Workload Units et scaler

Un Workload Unit, c’est quoi au juste ?

Depuis avril 2023, Bubble facture l’usage de ses serveurs en Workload Units (WU) : une mesure du travail réellement effectué, comme un carburant. Le principe à retenir tient en une phrase. Seules les opérations côté serveur consomment des WU. Tout ce qui se passe dans le navigateur de l’utilisateur est gratuit.

Gratuit (dans le navigateur) : afficher ou masquer un élément, poser un état personnalisé, évaluer une condition côté client, naviguer dans une application single-page, faire un calcul front-end.

Payant (sur le serveur) : une recherche (Do a search for), une écriture (Make changes, Create, Delete), planifier ou lancer un workflow backend, un appel d’API externe, un envoi de fichier, un chargement de page.

Une nuance utile : une action gratuite le devient moins dès qu’on lui attache une condition qui, elle, interroge le serveur. Un afficher/masquer conditionné par une recherche paie cette recherche.

L’objectif n’est pas zéro WU. Les WU sont un carburant fait pour être dépensé ; le but est de les dépenser intelligemment.

D’où vient une facture qui explose ?

Presque toujours d’une poignée de patterns, pas d’un usage légitime. Dans une app Bubble, une règle des 20/80 s’observe presque toujours : 20 % des workflows et des recherches consomment 80 % des WU. Tout le travail consiste à trouver ces 20 %.

Les coupables reviennent sans cesse : des recherches non filtrées qui ramènent des listes entières, des workflows récursifs qui s’emballent, des données rechargées en boucle à chaque affichage. Nous les détaillons plus bas, une fois posée la seule chose à faire avant d’optimiser : mesurer.

Mesurer avant d’optimiser

On ne devine pas, on mesure. Deux outils, dans cet ordre.

App Metrics (Logs, onglet App Metrics, Workload) donne la vue d’ensemble sur 30 jours : un graphe par jour pour repérer les pics, un camembert par type d’activité (recherches, workflows, appels d’API, chargements de page), et le détail jusqu’au workflow. La méthode : repérer les jours de pic, identifier le type d’activité dominant, descendre dans le détail, isoler les 3 à 5 plus gros postes, puis les croiser avec leur fréquence. Un petit coût qui tourne 10 000 fois par jour pèse plus lourd qu’un gros qui tourne une fois par semaine.

Server Logs donne la précision chirurgicale : on déclenche un workflow, on lit le coût WU action par action, on corrige, on relance, on compare.

Deux réglages à vérifier tout de suite : les notifications de charge (à 50, 75 et 100 %) pour ne jamais être surpris, et la Protection contre la récursion infinie (Settings, API). Les applications créées avant juillet 2024 ne l’ont pas activée par défaut, et un seul workflow récursif mal configuré peut vider un quota mensuel en moins d’une heure.

Le cadre CVR : complexité, volume, répétition

Bubble propose un cadre d’optimisation en trois dimensions, à appliquer dans l’ordre d’impact.

Complexité. Existe-t-il un moyen fondamentalement moins cher d’obtenir le même résultat ? Une recherche serveur remplaçable par un filtre côté client sur des données déjà chargées ? Une condition évaluable dans le navigateur plutôt que par un aller-retour serveur ?

Volume. Renvoie-t-on plus de données que nécessaire ? Chaque caractère renvoyé par le serveur a un coût, minuscule mais qui s’accumule. On resserre les contraintes de recherche, on utilise :count ou :sum au lieu de charger une liste entière pour la compter, on ne charge pas les champs qu’on n’affiche pas.

Répétition. La tâche tourne-t-elle plus souvent que nécessaire ? C’est la dimension la plus rentable. Passer un « À chaque fois » en « Une seule fois » peut supprimer des milliers de WU par jour.

Les pièges les plus coûteux

Certains patterns méritent d’être nommés, parce qu’ils ne se voient pas dans l’éditeur.

L’opérateur :filtered avec contrainte avancée. Le plus dangereux. Quand le filtre interroge un autre type de données, Bubble peut lancer une requête par ligne de résultat : une recherche filtrée sur 500 produits déclenche jusqu’à 501 requêtes à chaque affichage. La parade : stocker la valeur filtrée comme un champ du type principal (dénormalisation), ou poser la contrainte directement dans la recherche initiale.

Les recherches imbriquées dans un Repeating Group. Un groupe de N lignes qui lance une recherche par ligne exécute N+1 requêtes à chaque chargement. La parade : pré-calculer et stocker la valeur (par exemple le nombre d’employés sur la fiche entreprise), ou charger la liste liée en une seule requête et faire la correspondance côté client.

Le workflow récursif emballé. Un backend qui se planifie lui-même sans condition d’arrêt fiable peut brûler tout un quota en quelques minutes. Protection contre la récursion infinie activée, condition d’arrêt en toute première étape, test sur un jeu de données limité avant la production.

Les Database Triggers silencieux. Un trigger se déclenche à chaque modification d’un enregistrement du type concerné, et vérifie sa condition à chaque fois, même quand elle répond « non ». Cette vérification coûte des WU. Sur un type écrit souvent (logs, sessions), la note grimpe vite. On consolide, et on se demande si la logique ne tiendrait pas dans le workflow qui provoque déjà la modification.

L’environnement de développement. Dev et Live partagent le même quota mensuel. Les imports CSV et les tests en masse dans la version de développement consomment des WU avant même le lancement.

Les chargements de page. Chaque chargement complet coûte, page et recherches comprises. Une architecture single-page (afficher ou masquer des groupes plutôt que naviguer vers une nouvelle page) est fondamentalement plus économe.

Optimiser, acheter plus de WU, ou changer de plan ?

Optimiser a un coût, lui aussi : du temps de développeur. La facture Bubble se compose de trois leviers indépendants : le plan, l’éventuel add-on de WU pré-achetées, et les dépassements. Le point durable à connaître : les WU pré-achetées via un add-on reviennent bien moins cher que les dépassements bruts. Les montants exacts évoluent, vérifiez la grille à jour sur bubble.io.

La règle de décision tient en trois cas. On optimise quand la surconsommation vient de mauvais patterns (recherches imbriquées, triggers emballés) et non d’un usage réel : le temps de développement est vite rentabilisé. On achète un add-on quand les dépassements sont réguliers mais que l’application est simplement en croissance, sans goulot d’optimisation. On change de plan quand on a besoin des fonctionnalités d’un palier supérieur, ou qu’on consomme durablement au-dessus du quota inclus.

Et on évite de sur-optimiser : un pic ponctuel (import de lancement, article de presse, migration de données) coûte souvent moins cher à absorber qu’à contourner. L’énergie d’optimisation va aux postes récurrents et fréquents.

Une app Bubble qui coûte trop cher ? Parlons-en.