Écrit par Simon 
Quitter Bubble, c’est tout reconstruire. Ce n’est pas un défaut de Bubble, c’est son principe.
Bubble réunit au même endroit l’interface, la logique, la base de données et l’hébergement. C’est ce qui le rend si rapide au démarrage. C’est aussi ce qui rend la sortie si lourde : rien de ce que vous avez construit ne quitte la plateforme sous une forme réutilisable.
Ce que vous emportez a pourtant de la valeur. Une application qui tourne depuis des mois est une spécification que personne ne pourrait écrire. Des mois d’usage ont tranché ce qui sert : les écrans ouverts chaque jour, les règles qui pèsent, les cas particuliers remontés par les utilisateurs.
Ce guide dit quand partir, quand rester, que faire de la base. Puis comment migrer en dix étapes sans arrêter le service.
Ce qu’il faut retenir
- Bubble n’exporte aucun code, ni les mots de passe de vos utilisateurs. Seules les données sortent.
- La base part toujours. La seule question est le moment : avant, pendant ou après l’interface.
- On migre module par module, avec Bubble en repli, jamais en un grand soir.
Que peut-on récupérer d’une application Bubble ?
Les données, plus une description de l’application. En 2026, le support de Bubble répond toujours qu’aucun moyen d’exporter une application sous forme de code n’existe. Il propose à la place un fichier JSON de la logique et du design, qui ne s’exécute que dans Bubble. Le reste se reconstruit.
| Élément | Ce qui sort | Comment |
|---|---|---|
| Données | Oui | Onglet Data, type par type, en CSV, JSON ou NDJSON. Ou la Data API, 50 000 éléments au plus par requête |
| Fichiers | Oui, un par un | Servis depuis cdn.bubble.io. Aucun téléchargement groupé documenté |
| Utilisateurs | Les fiches, pas les mots de passe | Bubble ne garde que des empreintes et n’en propose pas l’export |
| Option sets | À retranscrire | Ils font partie de la définition de l’application, pas des tables |
| Workflows | Non | À réécrire, en s’appuyant sur le JSON comme référence |
| Règles de confidentialité | Non | À réécrire côté serveur, règle par règle |
| Interface | Non | À réécrire |
| Base Postgres | En lecture seule, Enterprise uniquement | Sur une instance dédiée, d’après le manuel de Bubble |
Le lot du 6 octobre 2026 n’y change rien. Le serveur MCP annoncé avec l’Agent 2 de Bubble laisse Claude Code ou Codex modifier une application. Il ne l’exporte pas. Un agent peut aider à lire une application Bubble pour en tirer la spécification, mais le code qu’il produira sera neuf.
Quels signes disent qu’il est temps de quitter Bubble ?
Ceux qui touchent au coût, à l’hébergement et à la maintenance. Depuis mai 2023, Bubble facture à l’unité de charge. Le dépassement coûte 0,30 $ les 1 000 unités hors palier, selon la FAQ tarifaire de Bubble. Une application qui grossit voit sa facture suivre son usage, pas son nombre de clients.
La facture devient imprévisible. Un workflow mal écrit, une recherche lancée à chaque chargement de page : le mois double. On peut optimiser. Il faut le faire avant de partir. Mais quand l’optimisation devient un poste permanent, le calcul change. Le prix d’entrée bouge aussi : d’après l’annonce de Bubble du 6 octobre 2026, le Starter web seul passe le 20 octobre à 39 $ par mois en facturation mensuelle, 32 $ en annuel.
Un client exige l’Europe. Le cluster partagé de Bubble est hébergé aux États-Unis, sur AWS. Les données en Europe demandent une instance dédiée, en offre Enterprise. Le sujet est développé dans notre article sur le no-code souverain.
L’application est devenue le produit. Vous la facturez, des clients en dépendent, des investisseurs posent la question de la propriété du code. Louer la fondation d’un produit devient alors un risque.
La logique ne se maintient plus. Des centaines de workflows, des déclenchements en cascade, des privacy rules que personne n’ose toucher. Aucun test automatisé ne protège un changement.
Il faut du mobile natif. L’éditeur mobile de Bubble, bâti sur React Native et lancé en bêta en juin 2025, l’est toujours d’après son manuel, seize mois plus tard.
Quand vaut-il mieux rester sur Bubble ?
Quand le produit cherche encore sa forme. Une migration de Bubble se compte en semaines de développement, en mois pour une application complexe. Pendant ce temps, l’application n’évolue presque plus. Si votre produit change chaque semaine, la réécriture figera une version déjà dépassée le jour de sa livraison.
Trois situations où l’on vous conseille de rester :
- Une seule brique coince. Un calcul lourd, un traitement de fichiers, une intégration capricieuse. Hébergez-la à côté et faites-la dialoguer par API. Notre article sur les limites de Bubble détaille cette sortie, la moins coûteuse des trois.
- La facture vient de quelques workflows. Un audit des unités de charge trouve souvent deux ou trois recherches répétées qui pèsent la moitié de la consommation. Corriger coûte quelques jours.
- Personne ne maintiendra le code. Une application codée sans équipe pour la faire évoluer devient, en deux ans, plus fragile que celle qu’elle remplace.
Un avertissement d’un praticien mérite d’être gardé en tête. George Collier, dont l’agence migre des applications Bubble vers Next.js et Supabase, observait en mai 2026 sur le forum de Bubble que la nouvelle application reproduit souvent la même dette technique que l’ancienne. Une réécriture qui recopie les workflows à l’identique déplace le problème.
Faut-il migrer le back-end, ou garder Bubble derrière ?
On migre toujours la base, mais pas forcément en premier. Bubble expose ses données par une Data API et ses workflows par une Workflow API, avec 15 000 à 35 000 requêtes par minute selon l’offre, d’après la page des limites de Bubble mise à jour en août 2026. Cela ouvre trois ordres possibles.
| Ordre | Comment | Quand le choisir |
|---|---|---|
| Le front d’abord | Le nouveau code lit et écrit dans Bubble par la Data API. La base part en dernier | Le cas courant : Bubble reste la source de vérité jusqu’à la bascule |
| La base d’abord | Les données passent dans Postgres. L’interface Bubble s’y branche par l’API Connector | Rarement : deux sources de vérité, deux modèles de droits. Et des unités de charge sur chaque appel |
| Module par module | Chaque module part avec ses données, dans une nouvelle base. Les entités partagées se synchronisent | Les applications où les modules se touchent peu : un espace client et un back-office, par exemple |
Garder Bubble comme back-end définitif, avec seulement l’interface en code, n’est presque jamais la bonne destination. Vous gardez la facture à l’usage, l’hébergement américain. Et une base que vous ne pouvez pas interroger en SQL. C’est un état de transition.
La règle qu’on applique : une seule source de vérité à chaque instant. Tant qu’un module n’a pas basculé, ses données vivent dans Bubble. Le nouveau code passe par l’API. Le jour où il bascule, ses données partent et Bubble ne les écrit plus. Une donnée modifiée des deux côtés à la fois est la panne la plus coûteuse d’une migration.
Quitter Bubble pour du code : que gagne-t-on, que perd-on ?
Vous gagnez la maîtrise du coût et de l’hébergement, vous payez la vitesse d’évolution. La facture d’hébergement devient fixe et lisible, sans unité de charge. Elle n’est plus le premier poste : c’est la maintenance qui le devient.
| Ce que vous gagnez | Ce que vous payez | |
|---|---|---|
| Coût | Une facture d’hébergement stable, sans unité de charge | Un budget de maintenance mensuel, en jours de développeur |
| Hébergement | La région de votre choix, Europe comprise | L’exploitation : sauvegardes, mises à jour, supervision |
| Évolution | Tests automatisés, revue de code, historique | Chaque changement passe par un développeur |
| Données | Une base Postgres que vous interrogez directement | Un schéma à concevoir, qui n’existait pas vraiment dans Bubble |
| Produit | Mobile natif, performance, toute bibliothèque du marché | Plus d’éditeur visuel pour ajuster un écran soi-même |
| Propriété | Le code et le dépôt sont à vous | Vous dépendez de l’équipe qui le connaît |
Le chiffrage complet, sur cinq ans, se fait poste par poste : notre article sur le coût d’un outil métier sur mesure donne la méthode.
Comment préparer la migration de Bubble vers du code ?
En quatre étapes, avant toute ligne de code. Le process complet en compte dix. Bubble continue de servir les utilisateurs du début à la fin. C’est dans la préparation que se cachent les mauvaises surprises : un champ liste, un option set, une privacy rule oubliée.
1. Faire l’inventaire de l’application
Listez les types de données et leurs champs, les option sets, les privacy rules, les workflows de page, les workflows d’API et les workflows planifiés. Ajoutez les plugins et chaque appel de l’API Connector. Notez ce qui sert vraiment : la migration est le moment de supprimer ce que personne n’ouvre.
Téléchargez le fichier JSON de l’application depuis l’onglet Settings. Il ne tournera nulle part ailleurs, mais il sert de référence quand on se demande ce que faisait un workflow.
2. Concevoir le modèle de données cible
Bubble ne vous a jamais demandé de schéma. Il faut en écrire un. Renommez les champs en noms compatibles SQL, transformez les option sets en tables de référence, éclatez les champs listes en tables de jointure. Gardez l’identifiant Bubble de chaque ligne dans une colonne : c’est ce qui rend les synchronisations rejouables.
3. Traduire les privacy rules en règles serveur
Dans Bubble, la sécurité vit dans les privacy rules. Dans le code, elle vit dans la base ou dans l’API : des règles par ligne dans Postgres, ou des contrôles dans chaque point d’API. Écrivez-les une par une, avec pour chaque rôle ce qu’il voit et ce qu’il modifie. C’est l’étape qu’on bâcle le plus souvent.
4. Choisir la stack
Un couple courant est Next.js et Supabase, parce que Supabase fournit d’office la base, l’authentification et le stockage de fichiers. Mais la bonne stack est celle que votre équipe sait maintenir. Choisissez un hébergement dont vous fixez la région.
Comment reconstruire une application Bubble sans coupure ?
Module par module, avec Bubble en repli. En mai 2026, sur le forum de Bubble, un utilisateur raconte sa propre migration. Il a réglé une trentaine d’écarts avant la bascule : règles, liaisons entre tables, valeurs par défaut. Puis il a gardé Bubble actif trente jours pour revenir en arrière. Les six étapes suivantes reprennent cette prudence.
5. Reconstruire module par module
On commence par le module qui justifie la migration. Le nouveau code lit et écrit dans Bubble par la Data API tant que la base n’a pas basculé. Activez-la type de donnée par type de donnée : elle est désactivée par défaut, comme les droits de création, de modification et de suppression.
6. Écrire un script de migration des données rejouable
Un script qui lit Bubble type par type et écrit dans la nouvelle base. Il doit pouvoir tourner dix fois de suite sans créer de doublons. On le rejoue à chaque répétition, puis une dernière fois à la bascule. Surveillez les champs de durée, que l’export de Bubble rend en texte.
7. Rapatrier les fichiers
Les fichiers sont servis depuis cdn.bubble.io. Les versions de développement et de production ont des stockages séparés. Téléchargez-les tous, déposez-les dans votre stockage, réécrivez les URL en base. Avant de supprimer l’application, jamais après.
8. Migrer les utilisateurs
Les mots de passe ne sortent pas. Deux voies. Une réinitialisation annoncée par e-mail, simple et un peu brutale. Ou une migration à la connexion : la première fois qu’un utilisateur se connecte au nouveau code, celui-ci vérifie son mot de passe auprès de Bubble par un workflow d’API, puis enregistre une nouvelle empreinte. Au bout d’un mois, on réinitialise les comptes restants.
9. Recetter la parité et faire la dernière synchronisation
Pour chaque rôle, jouez les scénarios qui comptent dans les deux applications, avec les mêmes données. Comparez les résultats. Puis prévoyez une courte fenêtre, un soir ou un week-end, pour la dernière synchronisation : Bubble passe en lecture seule, le script tourne une dernière fois. Le nouveau code devient la seule source.
10. Basculer, puis passer la main
Le domaine pointe vers le nouveau code. Gardez Bubble actif un mois, en lecture seule, pour comparer et revenir en arrière. Ensuite seulement, supprimez l’application. Laissez derrière vous une documentation, un environnement de test, un déploiement automatisé et une personne chez vous qui sait livrer.
Combien de temps et combien d’argent faut-il prévoir ?
Des semaines, pas des jours. Une application simple se compte en semaines de développement. Une application complexe, en mois.
Ce qui fait varier la note, c’est le nombre de workflows, de privacy rules et de types de données, pas le nombre d’utilisateurs. Le volume de données pèse peu : un script de migration se moque d’avoir mille ou un million de lignes à copier, tant qu’il est rejouable.
Chez Bienfait, on chiffre après l’inventaire, jamais sur une démonstration de l’application. Les workflows d’API et les privacy rules ne se voient pas à l’écran. Ce sont eux qui font la moitié du travail. Pour un premier ordre de grandeur, notre simulateur de coût de migration chiffre votre application poste par poste, barème affiché.
En bref
Bubble se quitte en reconstruisant tout. Mais pas en repartant de zéro.
L’application qui tourne est votre spécification, ses données sont votre socle, ses utilisateurs sont votre recette. La base part toujours. La seule vraie décision est l’ordre : on garde une seule source de vérité à chaque instant.
Chez Bienfait, on commence par l’audit des unités de charge et des briques qui coincent. Et on vous dit franchement quand une brique déportée suffit.
Et si votre application est un portail posé sur Airtable plutôt qu’un produit complet, le chantier n’a rien à voir : c’est l’objet de notre guide pour migrer de Softr vers du code.
Les sources
- Bubble, Can I export my data from the Bubble platform, support, 8 décembre 2023. Consulté le 2026-10-12. Article
- Bubble, Exporting data, manuel. Consulté le 2026-10-12. Page
- Bubble, Data API requests, manuel. Consulté le 2026-10-12. Page
- Bubble, Bubble hard limits, support, 4 août 2026. Consulté le 2026-10-12. Article
- Bubble, Dedicated instance, manuel. Consulté le 2026-10-12. Page
- Bubble, How Bubble hosting works, manuel. Consulté le 2026-10-12. Page
- Bubble, GDPR, support, 3 août 2026. Consulté le 2026-10-12. Article
- Bubble, Files, support. Consulté le 2026-10-12. Article
- Bubble, Pricing FAQ, manuel. Consulté le 2026-10-12. Page
- Bubble, Bubble’s pricing plans in 2023, blog, 6 avril 2023 (entrée en vigueur le 1er mai 2023). Consulté le 2026-10-12. Article
- Bubble, Native mobile beta, blog, 9 juin 2025. Consulté le 2026-10-12. Article
- Forum Bubble, Migrating users off Bubble to another custom platform, 2025. Consulté le 2026-10-12. Discussion
- Bubble, Agent 2, blog, 6 octobre 2026. Consulté le 2026-10-12. Article
- Bubble, Native mobile apps, manuel (éditeur en bêta). Consulté le 2026-10-12. Page
- Forum Bubble, Loss of major EU clients due to US hosting, novembre 2025. Consulté le 2026-10-12. Discussion
- Forum Bubble, George Collier (Not Quite Unicorns), Migrating your Bubble app to Next.js + Supabase, and how it can go wrong, 10 mai 2026, contenu d’agence. Consulté le 2026-10-12. Discussion
- Knowcode, Case study: practical advice on how to migrate from a Bubble.io database to Supabase, 5 novembre 2024. Consulté le 2026-10-12. Article
Questions fréquentes
Peut-on exporter le code d'une application Bubble ?
Non. Le support de Bubble l'écrit sans détour : il n'existe aucun moyen d'exporter une application sous forme de code. On peut télécharger sa définition en JSON, mais ce fichier ne tourne que dans Bubble. On repart donc d'une page blanche, avec l'application existante comme spécification.
Comment récupérer les données d'une application Bubble ?
Par l'export de l'onglet Data, type de donnée par type de donnée, en CSV, JSON ou NDJSON. Ou par la Data API, qui renvoie jusqu'à 50 000 éléments par requête. Aucun accès direct à la base Postgres n'est proposé, sauf en lecture seule sur une instance dédiée, réservée à l'offre Enterprise.
Que deviennent les mots de passe en quittant Bubble ?
Oui, ou presque. Bubble n'exporte ni les mots de passe ni leurs empreintes. Deux solutions : une réinitialisation annoncée par e-mail, ou une vérification du mot de passe contre Bubble à la première connexion, par un workflow d'API, avant d'enregistrer une nouvelle empreinte.
Combien coûte une migration de Bubble vers du code ?
Il dépend du nombre de workflows, de règles de confidentialité et de types de données, bien plus que du nombre d'utilisateurs. Une application simple se compte en semaines de développement. Une application complexe, en mois. Notre simulateur de coût de migration en donne l'ordre de grandeur pour la vôtre, poste par poste.
Peut-on garder Bubble comme back-end et coder seulement le front ?
Techniquement oui, par la Data API et la Workflow API. En pratique, c'est un état de transition, pas une destination : vous gardez la facture en unités de charge, l'hébergement américain et une base que vous ne pouvez pas interroger directement. On s'en sert pendant la migration, pas après.
Bubble peut-il héberger les données en Europe ?
Seulement sur une instance dédiée, en offre Enterprise. Le cluster partagé de Bubble est hébergé aux États-Unis. Un membre de l'équipe de Bubble indiquait en novembre 2025 qu'aucune option européenne n'était prévue à court terme sur ce cluster.
