Bubble construit des applications métier, des marketplaces et des SaaS complets, sans écrire de code.
Ce n’est pas pour autant un outil universel.
Il bute sur cinq points précis. Trois se contournent, deux non — et ce sont ces deux-là qu’il faut regarder en face avant de démarrer, pas après. Les connaître ne disqualifie pas l’outil : ça vous dit pour quels projets le choisir.
La prise en main : combien de temps avant de livrer ?
C’est la première limite, et la plus immédiate.
La prise en main de Bubble est nettement plus difficile que celle de Glide ou de Stacker. L’interface ne se laisse pas deviner : il faut parfois chercher longtemps où poser une information, et par où se déclenchent les workflows — cette suite logique en back-end qui joue le rôle des routes en développement classique.
Plusieurs logiques internes ressemblent d’ailleurs au développement traditionnel. Passer l’identifiant d’une entité à une page ou à un composant pour en afficher dynamiquement le contenu, par exemple, est un réflexe de développeur qu’aucune interface visuelle ne rend évident.
Le paradoxe de l’outil tient là : Bubble fait nativement une quantité de choses sans que vous ayez rien à régler, et en demande d’autres très manuellement, qui exigent de bien le connaître.
Comptez plusieurs semaines avant de livrer quelque chose de solide. Rien d’insurmontable — mais si votre besoin est une application simple à sortir en dix jours, l’outil n’est pas le bon.
Peut-on faire des calculs complexes dans Bubble ?
Non, et c’est la limite technique la plus nette.
Bubble couvre sans difficulté toutes les opérations standard d’une application métier ou d’un SaaS : créer, lire, modifier, supprimer, filtrer, trier, conditionner. Il bloque dès qu’il s’agit d’un vrai algorithme — un calcul d’optimisation, un moteur de scoring, une simulation qui doit sortir un résultat standardisé.
Le contournement est connu et il fonctionne : hébergez la logique mathématique chez vous, exposez-la en API, et faites-la dialoguer avec Bubble. L’application reste dans Bubble, le calcul vit ailleurs.
Ce contournement a un coût qu’il faut assumer. Vous réintroduisez une brique à développer et à maintenir, donc quelqu’un capable de le faire. Si votre projet repose entièrement sur cet algorithme, la question à poser n’est plus « comment le brancher à Bubble », mais « pourquoi Bubble ».
Jusqu’où va le design dans Bubble ?
Vous ferez de beaux produits avec Bubble, bien agencés et au goût du jour. Il y a de fortes chances que vos besoins tiennent dans les standards de ce qui se fait aujourd’hui sur le web.
La limite apparaît sur les interfaces graphiques très poussées : jeux vidéo, diagrammes de données interactifs, cartes manipulables.
Ce n’est apparemment pas une question de charge que feraient peser ces animations. C’est plutôt un positionnement : Bubble n’a pas fait du design avancé sa priorité, et l’outil reflète ce choix.
En pratique, la question à se poser est simple. Votre interface est-elle un moyen de manipuler des données, ou est-elle le produit lui-même ? Dans le premier cas, Bubble suffit largement. Dans le second, regardez ailleurs — ou prévoyez d’intégrer des composants externes, avec la maintenance que ça implique.
La sur-itération : la limite qui vient de vous
Celle-ci n’est pas dans l’outil. Elle est dans l’usage qu’on en fait, et elle abîme plus de projets que les quatre autres réunies.
Bubble donne une vitesse grisante. On construit un écran en une heure, on ajoute un workflow, on en ajoute un deuxième, on modifie le modèle de données pour caser une idée arrivée en cours de route.
Trois mois plus tard, personne ne sait plus quel workflow fait quoi, ni à quel moment il se déclenche. Le modèle de données a été tordu tellement de fois qu’il faut le reconstruire. Et la reconstruction casse des écrans dont on avait oublié qu’ils en dépendaient.
Deux réflexes évitent ça, et ils ne coûtent rien.
Nommez vos workflows en décrivant ce qu’ils font, pas ce qu’ils sont. Et figez votre modèle de données avant de construire les écrans : c’est la partie la plus coûteuse à changer une fois le projet lancé, exactement comme dans un projet de développement classique.
Les trois limites structurelles : code, hébergement, export
Les trois suivantes ne se contournent pas. Elles se décident avant de commencer.
Aucun code personnalisé autre que le JavaScript. Bubble n’accepte pas d’autre langage. Sur la plupart des projets, ça ne se voit jamais. Sur certains, ça ferme des portes d’un coup.
Aucun hébergement chez vous. Tout tourne sur l’infrastructure de Bubble, adossée à AWS. Vous ne choisissez ni le serveur, ni la région, ni les conditions. Le sujet devient bloquant dès qu’un client vous impose une clause d’hébergement, ou quand la souveraineté des données entre au contrat.
Aucun export du code. C’est la plus lourde des trois. Si vous décidez un jour de passer sur du développement maison, vous ne repartez pas de ce que vous avez construit : ni le front, ni la logique, ni les workflows ne sortent de la plateforme. Vous repartez d’une page blanche, avec pour seul acquis une application testée qui sert de spécification. C’est déjà beaucoup, et c’est moins que ce que beaucoup imaginent.
Ce point rejoint une question plus large que le seul Bubble : celle du verrouillage fournisseur, qui se pose pour tout outil dont vous ne détenez pas le code.
Bubble face aux autres outils
Les limites de Bubble se comprennent mieux en regardant ce que font les outils voisins, parce qu’aucun ne couvre le même terrain.
Glide et Stacker se prennent en main en quelques heures et affichent proprement des données qui existent déjà. Ils ne portent pas de logique métier complexe. Si votre besoin est de donner une vue à des utilisateurs sur une base existante, Bubble est surdimensionné.
Softr joue le même rôle, avec une authentification et une gestion de groupes d’utilisateurs très rapides à mettre en place. Là encore, la logique reste mince.
WeWeb se rapproche davantage : il se branche sur n’importe quelle API, accepte du code, et laisse exporter le front. C’est la réponse directe aux deux limites structurelles de Bubble — l’hébergement et la propriété du code — au prix d’un back-end à gérer séparément.
Bubble garde un avantage net sur un point : il est complet. Base de données, logique, interface et hébergement dans un seul outil, sans assemblage. Pour une équipe qui n’a personne pour tenir plusieurs briques, ce n’est pas un détail.
Que faire quand on atteint une limite ?
Atteindre une limite n’oblige pas à tout refaire. Trois sorties existent, du moins coûteux au plus lourd.
Déporter la brique qui coince. C’est la réponse au problème des calculs, et elle vaut au-delà : hébergez ailleurs ce que Bubble ne sait pas faire, et faites-le dialoguer par API. L’application reste où elle est, la complexité vit à côté. Vous ajoutez une brique à maintenir, ce qui n’est pas neutre, mais vous ne repartez pas de zéro.
Découper l’application. Beaucoup de projets qui « atteignent les limites de Bubble » ont en réalité fusionné deux outils différents : un espace client et un back-office métier, par exemple. Séparez-les, et chacun retombe dans le domaine de compétence d’un outil. Un portail client sur une plateforme, l’outil interne sur une autre.
Recoder, en partant du modèle validé. C’est la sortie la plus coûteuse, et la seule qui règle l’hébergement et la propriété du code. Elle est aussi beaucoup moins risquée qu’un développement parti d’une page blanche : vous savez exactement ce que fait l’application, quels écrans servent, quelles règles comptent, parce que des gens s’en servent depuis des mois. L’application Bubble devient la spécification.
Le mauvais réflexe, c’est de forcer. Empiler les contournements dans l’outil pour éviter d’admettre qu’on est sorti de son domaine produit une application que plus personne ne comprend, et qui coûte plus cher à maintenir qu’une réécriture.
Le bon moment pour se poser la question arrive avant la crise : quand vous passez plus de temps à contourner l’outil qu’à construire avec.
Alors, quand choisir Bubble ?
Quand quatre conditions sont réunies.
Votre projet demande une vraie logique métier — plusieurs types d’utilisateurs, des droits différenciés, des états qui s’enchaînent — et pas seulement un affichage de données. Vous avez, ou vous acceptez de prendre, le temps d’apprendre l’outil. Vos besoins de design tiennent dans les standards du web. Et l’hébergement chez un tiers américain ne pose de problème ni à vous, ni à vos clients.
Si l’une de ces quatre conditions manque, un autre outil ira mieux. Ce n’est pas un échec du no-code.
Comme le dit un product builder qu’on a interviewé : c’est facile d’être déçu du no-code, mais parfois ce n’est pas le no-code le problème — c’est qu’il ne fallait juste pas l’utiliser là.
Avant de démarrer votre projet Bubble : laquelle de ces cinq limites toucherez-vous en premier ?
Bubble bute sur cinq points : la prise en main, les calculs lourds, le design très poussé, l'hébergement et l'export du code. Les trois premiers se contournent par une API ou un découpage de l'application. Les deux derniers se décident avant de commencer, jamais après.
Questions fréquentes
Quelles sont les limites de Bubble ?
Cinq. Une prise en main longue. L'impossibilité de faire tourner un algorithme de calcul lourd. Un plafond sur les interfaces graphiques très poussées. Aucun hébergement hors de leur infrastructure. Aucun export du code. Les trois premières se contournent, les deux dernières non.
Peut-on faire des calculs complexes dans Bubble ?
Pas directement. Bubble couvre les opérations standard d'une application métier, mais bloque dès qu'il faut un vrai algorithme. Le contournement consiste à héberger la logique de calcul chez vous et à la faire dialoguer avec Bubble par API.
Peut-on exporter le code d'une application Bubble ?
Non. Si vous décidez plus tard de passer sur du développement classique, vous repartez de zéro : Bubble ne restitue ni le front, ni la logique. C'est la limite la plus structurante à connaître avant de démarrer un projet destiné à durer.
Peut-on héberger une application Bubble sur ses propres serveurs ?
Non. Tout est hébergé sur l'infrastructure de Bubble, qui s'appuie sur AWS. C'est un point à trancher tôt quand vos clients imposent des clauses d'hébergement ou de souveraineté des données.
Bubble est-il difficile à prendre en main ?
Plus difficile que Glide ou Stacker. L'interface demande du temps, et plusieurs logiques ressemblent au développement classique : passer l'identifiant d'une entité à une page pour en afficher le contenu, par exemple. Comptez plusieurs semaines avant de livrer quelque chose de solide.
