Le no-code peut-il vraiment passer à l'échelle ?
Oui, mais jusqu'à un certain seuil : un projet no-code tient la charge de plusieurs dizaines de milliers d'utilisateurs actifs à condition de découpler le backend (Supabase, Xano) de l'interface (Bubble, WeWeb) et de surveiller la consommation réelle — au-delà, une architecture mixte ou un passage au code sur mesure devient nécessaire pour la partie la plus sollicitée.
Un projet no-code passe à l'échelle jusqu'à plusieurs dizaines de milliers d'utilisateurs actifs si le backend est découplé de l'interface ; au-delà, c'est presque toujours la partie la plus sollicitée qu'il faut faire évoluer, pas tout le projet.
Qu'entend-on par « passer à l'échelle » ?
« Passer à l'échelle » recouvre en réalité trois questions distinctes, souvent confondues dans une seule inquiétude : « est-ce que mon outil no-code va tenir ? »
Le nombre d'utilisateurs actifs simultanés et la fréquence de leurs actions sur l'application.
Le nombre de lignes en base et la complexité des requêtes exécutées à chaque affichage.
Le nombre de personnes qui modifient le même projet en parallèle, sans se gêner ni créer de conflits.
Ces trois dimensions ne grandissent pas au même rythme ni avec les mêmes conséquences : un projet peut très bien gérer un fort trafic avec une base de données simple, et inversement.
Quelles sont les limites réelles de Bubble, WeWeb et FlutterFlow ?
Les trois outils que nous recommandons le plus souvent (notre comparatif Bubble, WeWeb ou FlutterFlow détaille leurs usages respectifs) ne scalent pas de la même façon, car ils ne reposent pas sur la même architecture.
| Outil | Backend | Facteur limitant | Signal d'alerte |
|---|---|---|---|
| Bubble | Intégré, propriétaire | Workload Units (WU) consommées par requête, workflow et appel API | Facture WU qui grimpe plus vite que le nombre d'utilisateurs |
| WeWeb | Au choix (Supabase, Xano, API) | Capacité du backend choisi, pas de WeWeb lui-même | Lenteur côté base de données, pas côté interface |
| FlutterFlow | Firebase ou Supabase | Capacité du backend choisi, le code Flutter généré étant déjà performant | Mêmes signaux que l'outil backend sélectionné |
Bubble a remplacé son ancien système de capacité fixe par des Workload Units (WU), qui mesurent la consommation réelle (requêtes base de données, exécution de workflows, appels API) plutôt qu'un simple nombre d'utilisateurs ; le détail des plans et des quotas est précisé sur bubble.io/pricing. WeWeb et FlutterFlow, eux, délèguent cette question au backend choisi : c'est Supabase ou Firebase qui absorbe la charge, pas l'outil d'interface.
Comment repousser ces limites sans tout recoder ?
- 1. Découpler la base de données dès le départChoisir Supabase ou un backend externe plutôt que la base propriétaire d'un outil tout-en-un, pour pouvoir la faire évoluer indépendamment de l'interface.
- 2. Limiter les workflows qui tournent à chaque affichageDéplacer les calculs lourds vers des tâches planifiées ou des fonctions serveur plutôt que de les exécuter à chaque chargement de page.
- 3. Mettre en cache ce qui change peuÉviter de recalculer ou de recharger une donnée stable (catalogue, paramètres) à chaque requête utilisateur.
- 4. Surveiller la consommation avant la saturationSuivre les WU chez Bubble ou les métriques de la base chez Supabase chaque mois, pour anticiper une migration plutôt que la subir.
L'erreur la plus fréquente à éviter
Un projet qui fonctionne bien avec 500 utilisateurs ne donne aucune garantie à 50 000 : la croissance du trafic et du volume de données n'est presque jamais linéaire, surtout sur les requêtes qui joignent plusieurs tables.
Ce que nous observons chez les projets que nous accompagnons
Voici un exemple représentatif de notre méthode, sans donnée client ni promesse de résultat garantie.
La facture WU grimpe toujours avant le ressenti utilisateur
Chez Amari Agency, nous demandons systématiquement à nos clients Bubble de consulter leur consommation de Workload Units avant de nous signaler un ralentissement : dans la plupart des cas, la hausse de consommation apparaît plusieurs semaines avant qu'un utilisateur ne remarque une lenteur, ce qui laisse le temps d'agir plutôt que de réagir en urgence.
Quels contenus lire ensuite ?
Ces ressources complètent cette réflexion sans cibler la même requête :
Questions fréquentes sur le passage à l'échelle en no-code
Combien d'utilisateurs un projet Bubble peut-il supporter ?
Il n'y a pas de plafond fixe : la limite dépend des Workload Units consommées par les requêtes et workflows, pas d'un nombre d'utilisateurs en soi ; deux projets avec autant d'utilisateurs peuvent consommer très différemment selon leur logique.
WeWeb est-il plus scalable que Bubble ?
WeWeb délègue la question à son backend choisi (Supabase, Xano) : la scalabilité dépend donc de ce backend, pas de WeWeb lui-même, ce qui donne plus de flexibilité mais demande aussi plus d'assemblage.
Faut-il migrer vers du code dès les premiers signes de ralentissement ?
Pas nécessairement : un découplage de la base, une mise en cache ou une optimisation des workflows suffisent souvent avant d'envisager une migration complète, voir notre guide sur les limites du no-code.
Les Workload Units limitent-elles vraiment la croissance d'un projet ?
Elles limitent le budget avant de limiter techniquement le projet : un pic de consommation se traduit d'abord par une facture plus élevée, ce qui laisse le temps d'optimiser avant un blocage réel.