Bubble et Xano : quand et comment séparer le frontend du backend

Le moment où on commence à chercher "Bubble Xano" ressemble souvent à ça : l'app tourne, les premiers utilisateurs arrivent, et les pages mettent deux fois plus de temps à charger qu'il y a six mois. Les workflows s'enchaînent. La base de données grossit. Et quelque chose dans l'infrastructure commence à grincer.

L'idée derrière l'architecture Bubble + Xano est simple : vous gardez Bubble pour ce qu'il fait bien - construire des interfaces rapidement - et vous déplacez les données et la logique métier vers Xano, un backend conçu pour tenir la charge. Les deux communiquent via API REST.

Ça règle un problème précis. Ça en crée quelques autres. Voici comment évaluer si c'est la bonne décision pour votre projet.

Pourquoi le backend de Bubble finit par coincer

Bubble est un outil complet : interface, logique, base de données dans le même environnement. C'est ce qui le rend si rapide à prendre en main. C'est aussi ce qui crée des frictions quand l'app grandit.

Quelques contraintes concrètes. Les listes de données dans Bubble sont plafonnées à 10 000 enregistrements par requête. La taille maximale par enregistrement est de 20 MB. Les workflows - conditions, modifications de données, recherches - consomment des "workflow units" limitées sur l'infrastructure partagée des plans standard. Et Bubble ne donne pas accès au SQL brut : vous travaillez avec son propre système de requêtes, qui ne supporte pas les jointures complexes ni les index personnalisés.

Pour une app avec quelques centaines d'utilisateurs et un modèle de données simple, ces limites ne posent pas de problème. Pour un SaaS multi-tenants avec plusieurs milliers d'utilisateurs actifs et des règles métier imbriquées, le backend Bubble devient le goulot. Les pages ralentissent. Les workflows s'exécutent en série. Et les options d'optimisation dans Bubble lui-même sont vite épuisées.

C'est là que Xano entre dans l'équation.

Ce que Xano apporte comme backend

Xano n'est pas un constructeur d'interface. C'est un backend autonome : base PostgreSQL, éditeur d'endpoints REST, logique métier visuelle. Il fait ce que Bubble fait moins bien côté données, sans toucher à ce que Bubble fait bien côté interface.

Trois composants forment l'essentiel de Xano.

L'API Builder permet de créer des endpoints REST visuellement : méthode HTTP, paramètres d'entrée, authentification, rate limiting. Chaque endpoint devient une fonction que Bubble (ou n'importe quel autre frontend) appelle. Xano génère automatiquement la documentation Swagger correspondante.

Le Visual Logic Builder est là où Xano se distingue. L'éditeur de logique supporte les conditions, les boucles, les variables, les transformations de données et les appels à des APIs externes. Vous pouvez construire une règle comme "envoyer un email uniquement si un client a passé plus de 3 commandes ce mois, que son dernier achat date de moins de 7 jours, et que le total dépasse 500 euros" - sans écrire une ligne de code.

L'infrastructure est basée sur PostgreSQL avec auto-scaling sur les plans payants. Contrairement à la base Bubble, vous définissez vos tables, vos relations, vos index. La structure relationnelle permet de construire des schémas complexes qui tiennent dans le temps, sans les limitations de schéma schemaless type Firebase.

Côté tarifs, Xano propose un plan gratuit (Build) suffisant pour prototyper, un plan Starter à 29 dollars par mois pour les projets early-stage, et un plan Pro à 249 dollars par mois avec infrastructure dédiée et auto-scaling pour la production à fort trafic. Xano annonce plus de 100 000 applications déployées sur sa plateforme, traitant plus de 300 millions d'appels API par mois.

Connecter Bubble à Xano : le setup en pratique

La connexion entre les deux outils passe par l'API Connector de Bubble, un plugin natif disponible sur tous les plans. Voici les étapes dans l'ordre.

Dans Xano, vous créez d'abord vos tables et vos endpoints. Xano génère une documentation Swagger pour chaque groupe d'APIs - cette documentation liste tous vos endpoints avec leurs paramètres d'entrée et de sortie. Vous la téléchargez ou vous copiez l'URL de la spec.

Dans Bubble, vous activez l'API Connector et vous ajoutez une nouvelle API. Vous entrez l'URL de base de votre instance Xano (qui ressemble à https://xxx.xano.io/api:groupe), puis vous configurez l'authentification. Xano utilise des tokens JWT : Bubble doit d'abord appeler l'endpoint de login Xano pour obtenir un token, puis inclure ce token dans les headers de chaque requête suivante.

Pour chaque endpoint Xano (GET /users, POST /orders, etc.), vous créez un appel dans l'API Connector : méthode HTTP, paramètres, valeurs de retour. Bubble analyse la réponse JSON et vous permet de mapper les champs aux types de données Bubble.

Une fois les appels configurés, vous les utilisez dans vos workflows Bubble exactement comme des actions natives : déclencher sur un clic, récupérer des données pour alimenter un repeating group, etc. Du point de vue de l'interface Bubble, la source des données est transparente.

Le setup initial prend quelques heures pour une équipe qui connaît les deux outils. La courbe d'apprentissage principale est du côté Xano : comprendre les concepts de tables relationnelles, de relations entre tables, et de logique d'endpoint est nécessaire avant de pouvoir construire quelque chose d'utile.

Ce que cette architecture permet

Au-delà des performances, le découplage Bubble + Xano ouvre quelques possibilités que l'architecture Bubble seule ne permet pas facilement.

Plusieurs frontends sur le même backend. Si vous voulez une application web Bubble et une application mobile FlutterFlow pour les mêmes données, Xano devient le point central. Les deux frontends appellent les mêmes endpoints. La logique métier n'est pas dupliquée.

Des intégrations IA directement dans le backend. Xano permet d'appeler des APIs externes depuis sa logique d'endpoint. Un endpoint peut recevoir des données utilisateur, les envoyer à un LLM (OpenAI, Mistral, Anthropic), traiter la réponse et la stocker - sans que Bubble soit impliqué dans ce traitement. Si vous construisez des agents IA pour votre entreprise, c'est une architecture plus propre qu'un traitement LLM dans les workflows Bubble.

Des automatisations n8n déclenchées depuis Xano. Xano peut envoyer des webhooks vers n8n ou Make au moment d'événements précis (nouvelle commande, seuil atteint, etc.). À l'inverse, n8n peut appeler des endpoints Xano pour écrire des données. Ça permet de séparer clairement la logique applicative (Xano) de la logique d'automatisation (n8n).

Quand cette architecture est de trop

Ajouter Xano à un projet Bubble a un coût réel - en temps, en argent, et en complexité. Dans plusieurs cas, ça ne vaut pas la peine.

Pour un MVP en phase de validation, deux outils sont deux fois plus de friction. Si vous n'avez pas encore prouvé que votre idée a des utilisateurs, le backend Bubble est suffisant. Vous avez le temps de migrer vers Xano quand les limites de Bubble deviennent un problème réel, pas hypothétique.

Si votre app a besoin de temps réel - un chat, une collaboration en direct, une map qui se met à jour à la seconde - Xano n'est pas la bonne réponse. Xano est conçu pour des APIs REST classiques (requête/réponse). Firebase Realtime ou Supabase Realtime sont mieux placés pour ces cas.

Si votre budget est serré, deux abonnements (Bubble + Xano Starter minimum) s'additionnent. Pour une app qui n'a pas encore de revenus, réfléchissez à si les limitations de Bubble sont un problème aujourd'hui ou dans 18 mois.

Enfin, si personne dans l'équipe ne comprend les concepts d'APIs REST et de bases relationnelles, Xano va créer plus de problèmes qu'il n'en résout. Ce n'est pas du code, mais ce n'est pas non plus un outil pour quelqu'un qui ne sait pas ce qu'est un endpoint ou une clé étrangère.

Un mot sur le lock-in

L'architecture Bubble + Xano réduit le lock-in sur chaque outil individuellement. Si vous décidez de migrer le frontend vers React ou WeWeb, votre backend Xano reste intact. Si vous migrez le backend vers du code custom, votre frontend Bubble continue de fonctionner pendant la transition.

Mais chaque outil crée son propre lock-in. La logique métier dans Xano est dans l'interface de Xano, pas dans des fichiers versionables dans Git. Si vous changez d'avis sur Xano, la migration n'est pas triviale. Pour les projets où la portabilité totale est un critère important, Supabase offre plus de flexibilité - mais demande des compétences techniques plus élevées.

Questions fréquentes

Peut-on utiliser Xano avec FlutterFlow en plus de Bubble ?

Oui, c'est même l'un des cas d'usage classiques. Xano expose des endpoints REST que n'importe quel client peut appeler. Vous pouvez avoir une web app Bubble et une app mobile FlutterFlow qui utilisent exactement les mêmes endpoints Xano. La logique métier est centralisée dans le backend, les deux frontends en bénéficient.

Bubble peut-il recevoir des webhooks de Xano ?

Bubble peut recevoir des webhooks via son API Workflow. Vous pouvez configurer Xano pour envoyer un webhook vers votre app Bubble quand un événement se produit côté Xano - par exemple, notifier le frontend qu'une tâche longue s'est terminée. C'est un pattern valide pour simuler du temps réel sans WebSockets.

L'authentification se gère comment entre les deux outils ?

Xano gère son propre système d'authentification avec JWT. L'utilisateur se connecte via Bubble, qui appelle l'endpoint de login Xano et reçoit un token. Bubble stocke ce token (dans l'état utilisateur ou en cookie) et l'inclut dans les headers de chaque requête suivante vers Xano. Xano vérifie le token et identifie l'utilisateur. C'est une implémentation standard, bien documentée des deux côtés.

Xano héberge-t-il les données en France ou en Europe ?

Sur les plans standard, Xano héberge aux États-Unis. Des options d'hébergement en Europe et dans d'autres régions sont disponibles sur les plans Enterprise. Si vous traitez des données personnelles soumises au RGPD, vérifiez les options d'hébergement EU disponibles et le contrat de sous-traitance de données avant de vous engager. C'est un point à clarifier dès la phase de choix d'architecture, pas après le déploiement.