Sur-mesureSaaSPropriété du codeMéthode
Quitter Bubble pour du code : quand et comment migrer
9 min de lecture
Quitter Bubble pour du code se justifie quand la plateforme bloque un enjeu concret : une facture qui suit l'activité au lieu du budget, des données hébergées aux États-Unis alors que vos clients les veulent en Europe, une équipe qui doit tester et versionner son code, ou une fonction impossible à construire dans l'éditeur. Sans l'un de ces signaux, rester sur Bubble est souvent le bon choix. Avec l'un d'eux, la méthode sûre consiste à garder l'application Bubble en ligne et à migrer module par module, données comprises.
Cet article s'appuie sur la documentation officielle de Bubble, consultée le 3 novembre 2026. Les offres de la plateforme évoluent : vérifiez-les sur bubble.io avant de décider.
Ce que Bubble fait bien, et pourquoi on y reste souvent
Bubble a permis à beaucoup de fondateurs de lancer un produit sans équipe technique : base de données, comptes utilisateurs, workflows, hébergement et sauvegardes sont fournis. La plateforme s'appuie sur Amazon Web Services et sur Cloudflare, et prend en charge une bonne part de l'exploitation que vous auriez à organiser vous-même avec du code.
C'est précisément ce qu'il faut garder en tête avant de partir : tout ce que Bubble fait en coulisse deviendra votre affaire. La documentation de Bubble le dit sans détour dans sa page consacrée à l'export d'une application : hébergement, base de données, authentification, stockage des fichiers, supervision et sauvegardes sont à mettre en place une fois l'application déplacée. Notre comparatif agence, freelance ou no-code rappelle dans quels cas le no-code reste la meilleure réponse.
Les quatre signaux qui justifient de migrer
| Signal | Ce qui se passe sur Bubble | Ce que le code change |
|---|---|---|
| Facture à l'usage | Chaque action consomme des unités de charge | Coût d'hébergement que vous dimensionnez |
| Hébergement des données | Serveurs partagés aux États-Unis, région au choix en Enterprise | Région choisie dès le départ |
| Propriété et réversibilité | Pas de code source exportable tel quel | Un dépôt de code que vous pouvez confier à une autre équipe |
| Méthode d'équipe | Éditeur visuel, logique dans les workflows | Tests automatiques, revue de code, versions |
1. La facture suit l'activité, pas votre budget
Bubble applique une tarification à l'usage mesurée en unités de charge (workload units, ou WU). Chaque formule inclut un quota mensuel ; au-delà, vous payez des dépassements ou ajoutez un palier, sur les formules Starter, Growth et Team. La documentation recense douze types d'activité qui consomment ces unités : recherches en base, workflows, appels d'API, chargement des pages, entre autres. Bubble prévient par e-mail à 75 % et à 100 % du quota mensuel.
Ce modèle n'est pas un défaut : il est juste pour une application peu sollicitée. Il devient un signal quand vos marges dépendent d'un coût par client prévisible, typiquement dans un SaaS dont vous fixez le prix, ou quand l'équipe passe plus de temps à optimiser sa consommation qu'à construire le produit.
2. Les données doivent être hébergées ailleurs
Selon la documentation de Bubble, l'environnement partagé est hébergé aux États-Unis et ce lieu ne peut pas être changé ; seule l'offre Enterprise permet de choisir la région AWS. Si un client grand compte, un appel d'offres public ou votre propre analyse RGPD exige un hébergement européen, la question se pose : passer en Enterprise, ou migrer.
3. Vous voulez un code que vous pouvez emporter
Bubble ne fournit pas de code source à télécharger. Sa page d'export décrit une autre démarche : un agent IA se connecte à l'application par le serveur MCP de Bubble, en version bêta, en lit les types de données, les pages, les workflows et les règles de confidentialité, puis la recrée en code dans le langage de votre choix. Bubble précise que cette reconstruction ne garantit pas une fidélité parfaite et fournit « un point de départ, pas une application terminée ». Les clés d'API ne sont pas lues par l'agent : elles se recopient à la main.
Si la capacité à changer de prestataire ou de plateforme compte pour vous, c'est un point à peser dès maintenant. Notre article sur la réversibilité détaille ce qu'il faut pouvoir récupérer en sortie.
4. L'équipe a besoin de méthodes de développeur
Quand plusieurs personnes modifient l'application, il faut des tests automatiques, une revue avant mise en production et un historique des versions lisible. Quand le produit grandit, la logique éparpillée dans des centaines de workflows visuels devient difficile à relire. C'est une forme de dette technique, et le code, bien tenu, la rend visible et remboursable.
Les mauvaises raisons de migrer
- « Le code, c'est plus sérieux. » Un code mal écrit est pire qu'une application Bubble bien construite. Ce qui compte, c'est la tenue dans la durée.
- « Ce sera moins cher. » Pas forcément. Bubble le rappelle : en code, les coûts se répartissent entre plusieurs fournisseurs (hébergement, base de données, envoi d'e-mails, supervision), auxquels s'ajoutent la maintenance et la reconstruction elle-même. Listez-les tous avant de comparer.
- « Il manque une fonction. » Vérifiez d'abord si un plugin, le connecteur d'API ou un élément HTML personnalisé suffit. Bubble le recommande lui-même avant tout départ.
Ce que vous récupérez, ce que vous reconstruisez
| Élément | Comment il sort de Bubble | Ce qu'il devient en code |
|---|---|---|
| Données | Export CSV, JSON ou NDJSON, ou Data API | Tables d'une base comme PostgreSQL |
| Types de données et option sets | Lus par l'agent ou relevés à la main | Schéma de base, tables de référence |
| Pages et workflows | Lus par l'agent, reconstruits | Écrans et logique serveur, testés |
| Règles de confidentialité | Lues par l'agent | Contrôle d'accès à réécrire et à vérifier |
| Comptes utilisateurs | À planifier | Authentification, reconnexion des utilisateurs |
| Clés d'API, secrets | Recopiés à la main | Coffre de secrets du nouvel hébergement |
| Sauvegardes, supervision | Fournies par Bubble | À mettre en place et à tester |
Deux points méritent une attention particulière.
Les identifiants. Gardez l'identifiant unique de chaque enregistrement Bubble comme colonne de la nouvelle base : c'est ce qui permet aux liens entre tables de rester justes après la reprise, et de rejouer l'import autant de fois que nécessaire.
Les règles d'accès. Les règles de confidentialité de Bubble protègent vos données sans que vous les voyiez à l'écran. Leur équivalent en code doit être réécrit, puis testé, utilisateur par utilisateur et rôle par rôle. C'est la partie où une reconstruction rapide, assistée par IA, se trompe le plus facilement : notre liste de contrôle de sécurité s'applique aussi ici.
Migrer module par module, sans coupure
Une migration réussie ne coupe pas le service. L'application Bubble reste en ligne pendant la reconstruction, et la bascule se prépare comme une mise en production ordinaire.
- Inventorier. Lister les types de données, les workflows, les intégrations (paiement, e-mails, API tierces) et les règles d'accès. Cet inventaire sert aussi de cahier des charges.
- Choisir l'ordre. Commencer par un module peu risqué ou très coûteux en unités de charge, par exemple un traitement de fond ou un export, plutôt que par l'inscription des utilisateurs.
- Construire la nouvelle base. Créer le schéma, écrire le script de reprise et le rejouer à blanc jusqu'à obtenir des comptes justes.
- Brancher les deux mondes. Pendant la transition, la Data API de Bubble permet au nouveau code de lire les enregistrements encore gérés par Bubble. Pensez à la sécuriser : elle obéit aux mêmes règles de confidentialité.
- Tester sur des données réelles. Recette avec quelques utilisateurs, sur une copie des données, avant toute bascule.
- Basculer, puis surveiller. Reprise finale, redirection du domaine, et l'application Bubble gardée en lecture seule quelques semaines, au cas où.
Pour un SaaS avec beaucoup de clients actifs, la bascule progressive, client par client, réduit encore le risque. Elle demande en revanche de faire cohabiter les deux systèmes plus longtemps, ce qui se décide au cas par cas.
Combien de temps et combien d'argent
Nous ne donnons pas de chiffre universel : il dépend du nombre de types de données, de workflows et d'intégrations, et surtout de l'état des données. Trois repères fiables, en revanche :
- La reconstruction n'est que la moitié du chantier. La reprise de données, les règles d'accès, l'hébergement et la recette en prennent autant.
- L'IA accélère l'écriture du code, y compris par l'agent que propose Bubble, mais pas les décisions ni la vérification. Comptez le temps de relecture.
- Le coût d'exploitation change de forme : un abonnement Bubble devient plusieurs lignes (hébergement, base, services tiers, maintenance). Comparez-les ligne à ligne avec l'abonnement actuel, sur au moins un an.
Si votre application a été construite avec un générateur par IA plutôt qu'avec Bubble, la démarche est très proche : elle est décrite dans mettre une application Lovable en production.
Par où commencer
Avant de décider, faites relire l'application : inventaire des workflows, consommation d'unités de charge des trois derniers mois, règles de confidentialité et volume de données. C'est ce relevé qui dit s'il faut optimiser sur Bubble, passer à une formule supérieure ou migrer, et dans quel ordre. Votre application Bubble est aussi un excellent cahier des charges : chez LPR Studio, nous partons de ce qu'elle montre pour présenter en visio, sous 5 jours ouvrés, un prototype gratuit de la version en code, avant tout engagement.