Ce qui change, en bref

Bubble, l'un des acteurs majeurs de l'univers Nocode, a annoncé récemment un changement majeur dans sa politique de pricing. La nouvelle unité de pricing, appelée Workload Unit (WU), remplace l'ancienne unité de pricing, la Capacity Unit (CU). 

Cette décision est prise dans le but de pouvoir discriminer ses prix en fonction de la valeur (supposée) que retirent d’une application ses utilisateurs (donc son propriétaire) en utilisant pour proxy le volume d’actions réalisées par ladite application. Jusqu’à présent les prix étaient fonction de la capacité de serveur demandée par l’application pour fonctionner à une performance acceptable, ce qui était moins directement le reflet de la valeur retirée de l’application.

La structure du pricing reste similaire (plan fonction des fonctionnalités souhaitées et packages en fonction de l’utilisation) mais permet désormais de ne plus avoir de limitation (théorique) de performance.

Globalement le coût d’une application Bubble augmentera de façon significative en pourcentage mais dans la plupart des cas de façon soutenable en valeur absolue. Il conviendra d’évaluer au cas par cas.

Le nouveau modèle de prix sera effectif à partir du 1er mai pour les nouvelles applications, et 18 mois plus tard pour les applications déjà sur un plan payant, ou au changement de plan si cela intervient avant les 18 mois.

Retour sur les différentes annonces, et comment cela a bouleversé la Nocode sphère :

Première annonce (6 avril) :

• Le nouveau modèle de prix est annoncé par Emmanuel (co-CEO).
• Le nombre de WU consommées par une application apparaît dans les logs des applications .
• Les utilisateurs indiquent que la consommation en WU, telle que calculée, induirait un prix multiplié par un facteur 3 à 10 pour certaines applications.

Deuxième annonce (7 avril 2023) :

• Plus de détails sont fournis par Tatiana (VP of Marketing), notamment l’ajout dans la documentation de ce qui contribue aux WU.
• Annonce d’un webinaire le 20/04 au sujet de l’optimisation vis-à-vis des WUs.

Troisième annonce (12 avril 2023) :

• Josh (co-CEO de Bubble) annonce une révision de sa formule de calcul des WU consommées par une application, et dévoile plus de détails sur sa formule au travers d’une table de correspondance de WU en fonction du type de workload.
• Un calculateur est mis à disposition pour estimer ce que sera le prix d’une application pour une consommation donnée de WUs.

Il faut attendre que les premières données de consommation des applications soient collectées sur la base de la nouvelle formule afin d’évaluer l’impact de la révision. Au bout de quelques jours, la réduction du nombre de WU est bien confirmée dans les logs. Nous constatons réellement une diminution de l’ordre de -90% sur nos applications les plus consommatrices en WU.

Notre analyse

Les atouts de Bubble restent relativement inchangés. D’un point de vue fonctionnalités, on note plutôt une amélioration à plan équivalent (les noms ont changé pour éviter la confusion entre plans actuels et futurs plans) : le plan Free donne notamment accès à l’API connector (ce qui n'était pas le cas du plan Free actuel), et le plan Growth (équivalent du plan Professional actuel) inclut désormais 10 branches (contre 3 seulement pour le plan Professional actuel). D’un point de vue coût, les niveaux de prix des plans (qui sont liés aux fonctionnalités) restent relativement semblables, le prix Team (équivalent du plan Production actuel) baissant même un peu par rapport au plan Production actuel.

Bubble cherche à optimiser son pricing pour capter la création de valeur plutôt que purement prendre une marge sur le coût de production de son service. D’une part la réalité économique du marché doit d’une façon ou d’une autre rattraper l’entreprise (leur réserve de liquidités n’est cependant à priori pas en cause), et d’autre part c’est une façon de pérenniser la situation financière tout en restant fidèle à son crédo : rendre la création de logiciel accessible au plus grand nombre. 

Ce nouveau modèle de pricing permet en effet de faire payer plus ceux qui le peuvent, c’est-à-dire ceux qui monétisent ou retirent de la valeur de leurs applications, afin d’absorber les coûts de ceux qui sont en phase de lancement.

Les projets sans modèle économique mais nécessitant un passage à l’échelle se retrouveront cependant substantiellement plus chers à financer avec ce nouveau pricing qu’avec l’actuel. On pourra regretter aussi que le nouveau modèle de pricing ne prenne pas/plus directement en compte la sobriété énergétique, ce qui était à priori davantage le cas de l’ancien modèle, basé sur la capacité de serveurs utilisée.

Le développement avec Bubble va devenir plus technique, ce qui va tendre à encore plus professionnaliser sa pratique. En effet, avec une formule de calcul des WUs basée sur un grand nombre de critères, c’est probablement l’un des outils avec le pricing le plus compliqué de l’univers Nocode.

Les actions que nous prenons chez Alegria pour nos clients actuels et futurs que nous avons orientés ou orienterons vers le choix de Bubble.

Dans l’immédiat, nous allons sécuriser le pricing actuel des applications de nos clients pour les 18 prochains mois, car il sera toujours possible de basculer sur le nouveau modèle à tout moment si celui-ci s’avérait plus avantageux.

Nous allons proposer au cours des 18 prochains mois du refactoring à nos clients existants pour les optimisations dont le ROI fait sens.

Nous allons systématiquement mettre en perspective les coûts de WU par rapport aux coûts de développement et d’optimisation qui pourraient davantage influer sur le coût total de possession, afin de ne pas perdre de vue l’objectif global du client.

Nous allons également adapter notre méthodologie et nos formations à cette nouvelle grille de pricing. Nous optimisions pour la performance (et notamment la performance perçue par les utilisateurs), nous optimiserons désormais également pour la consommation (de WUs).

Quand nous orientons nos clients vers Bubble c’est que c’est la solution qui fait le plus de sens pour leur projet (nous travaillons aussi avec des architectures alternatives telles que Xano + WeWeb, FlutterFlow + Firebase, etc.), non seulement d’un point de vue technique mais aussi d’un point de vue du coût total de possession, de l’objectif, de time to market, des contraintes de marché, des ressources, et du degré d’autonomie.

‍