No-code rate limiting API quotas : maîtriser Bubble et Firebase

Une facture Firebase à 3 800 € reçue un lundi matin après un pic de trafic non anticipé : c'est le genre de mauvaise surprise qui a poussé de nombreuses startups no-code à revoir leur architecture. Le rate limiting et la gestion des quotas API ne sont plus des sujets réservés aux ingénieurs backend. Sur Bubble, Firebase, Xano ou Supabase, chaque requête compte — littéralement — et un défaut de contrôle peut transformer un succès marketing en catastrophe financière.

Chez Fabrica Digitalis, agence no-code basée à Annecy, nous accompagnons des porteurs de projets qui découvrent trop tard le coût réel d'une application qui scale mal. Voici comment anticiper.

Pourquoi le rate limiting est vital sur les plateformes no-code

Les plateformes no-code facturent presque toutes à l'usage : workload units chez Bubble, invocations et lectures Firestore chez Firebase, requêtes API chez Xano. Contrairement à un serveur dédié où l'on paie une capacité fixe, ici chaque action utilisateur coûte de l'argent. Sans garde-fou, trois scénarios peuvent faire exploser vos coûts :

• Un bot qui scrape vos pages publiques et déclenche des milliers de requêtes/minute
• Un utilisateur légitime qui, par erreur d'UX, spam un bouton envoyant un webhook
• Un workflow récursif mal calibré (une boucle qui appelle une API à chaque itération)

Le rate limiting consiste à fixer un plafond au nombre de requêtes qu'un utilisateur, une IP ou un endpoint peut consommer sur une fenêtre de temps donnée. C'est votre première ligne de défense budgétaire.

Bubble : optimiser les Workload Units sans casser l'UX

Depuis le passage au pricing Workload Units en 2023, Bubble facture chaque opération selon sa complexité. Un simple Do a search for mal indexé peut consommer 10 à 50 fois plus qu'une requête optimisée.

Les leviers concrets côté Bubble

1. Limiter les workflows côté client : ajoutez une condition When button clicked AND custom state 'loading' is no pour bloquer les double-clics. C'est basique mais 80 % des apps que nous auditons ne le font pas.
2. Paginer systématiquement les Repeating Groups : afficher 500 items d'un coup peut coûter des dizaines de WU par visite. Passez à 20 items avec chargement à la demande.
3. Utiliser les Backend Workflows avec parcimonie : chaque Schedule API workflow on a list peut générer des centaines d'exécutions. Privilégiez le batching.
4. Mettre en cache les données rarement modifiées via des custom states ou une base externe (Xano, Supabase) moins chère à interroger.

Pour les endpoints API exposés publiquement, Bubble propose des API tokens par utilisateur : révoquez ceux qui explosent leur quota, et logguez chaque appel dans une base pour repérer les anomalies. Nos études de cas montrent des réductions de 40 à 70 % de la facture WU après un audit ciblé.

Firebase : dompter Firestore et Cloud Functions

Firebase est redoutable : chaque lecture Firestore, chaque invocation Cloud Function, chaque Mo de bande passante est compté. Une app mal conçue peut facilement franchir les 500 € mensuels sur un trafic modeste.

Les règles Firestore comme rate limiter

Les Security Rules Firebase permettent de refuser une écriture si l'utilisateur a déjà effectué X opérations dans les N dernières secondes. On stocke un compteur par UID et on incrémente à chaque action. Simple, gratuit, efficace.

Budget alerts et App Check

Deux réflexes indispensables :

• Activer Budget Alerts dans Google Cloud : vous recevez un mail dès que vous atteignez 50 %, 90 % puis 100 % du budget mensuel fixé.
• Activer Firebase App Check : bloque les requêtes qui ne proviennent pas de votre app légitime. C'est LA parade contre les scrapers et abus d'API keys exposées.

Optimiser les Cloud Functions

Chaque invocation compte, mais aussi le temps d'exécution et la mémoire allouée. Trois bonnes pratiques : réduire la mémoire au minimum viable (souvent 128 Mo suffisent), utiliser les callable functions plutôt que HTTP quand possible, et regrouper les traitements batch via Pub/Sub plutôt que déclencher une fonction par événement.

L'approche architecturale : mutualiser et cacher

Au-delà des réglages ponctuels, la vraie économie vient de l'architecture. Chez Fabrica Digitalis, nous appliquons systématiquement trois principes sur les projets clients :

• Séparer la lecture publique de la lecture authentifiée : les pages vitrines n'ont pas besoin de Firestore, un simple JSON statique régénéré toutes les heures suffit
• Denormaliser intelligemment : mieux vaut dupliquer un champ que faire 3 requêtes jointes
• Utiliser un CDN (Cloudflare, Bunny) devant les endpoints publics pour absorber les pics sans toucher au backend

Ces choix se prennent idéalement dès la conception. Un projet démarré sans réflexion sur les quotas se refactore rarement à moindre coût — d'où l'importance d'un cadrage sérieux dès le départ, comme nous le pratiquons dans nos prestations d'accompagnement no-code.

Monitoring : ce qu'il faut absolument tracker

On ne pilote pas ce qu'on ne mesure pas. Voici le tableau de bord minimal à mettre en place dès le lancement :

• Nombre de requêtes API par jour (par endpoint)
• Coût cumulé du mois en cours vs prévisionnel
• Top 10 des utilisateurs par volume de requêtes
• Taux d'erreur 429 (Too Many Requests) — s'il grimpe, votre limite est peut-être trop stricte

Bubble Logs, Firebase Console et Google Cloud Monitoring offrent tout cela nativement. Encore faut-il prendre le temps de configurer les alertes.

Autour d'Annecy : un accompagnement pragmatique

À Annecy et sur toute la région Auvergne-Rhône-Alpes, nous rencontrons régulièrement des startups qui découvrent après 6 mois d'exploitation que leur produit n'est pas viable économiquement à cause d'une architecture no-code mal calibrée. Un projet comme Allo Burger ou MyCom illustre bien ce que produit une réflexion coûts en amont : des apps qui scalent sans que la facture ne suive la même courbe.

Que vous soyez à Annecy, à Genève ou dans l'une de nos zones desservies, la méthode reste la même : audit, priorisation, correctifs mesurés. Pour les projets déjà en production, une prestation de maintenance mensuelle inclut le monitoring des quotas et l'optimisation continue.

En résumé : cinq règles pour dormir tranquille

1. Fixez des budgets alerts avant de lancer, pas après le premier incident
2. Activez systématiquement App Check (Firebase) ou les tokens API (Bubble)
3. Paginez tout, cachez ce qui peut l'être
4. Monitorez les endpoints les plus consommateurs chaque semaine
5. Refactorez dès qu'un endpoint dépasse 20 % de votre budget total

Vous suspectez que votre app no-code consomme trop ? Nous proposons des audits techniques flash pour identifier les gisements d'économie et sécuriser vos quotas. Découvrez nos offres d'accompagnement ou parlons-en directement.