Quitter Bubble pour une application codée : quand le faire, et comment sans perdre ses utilisateurs

Vous avez construit votre produit sur Bubble, il a des utilisateurs, peut-être des clients qui paient, et la question revient de plus en plus souvent : faut-il en sortir ? Si vous hésitiez encore entre no-code et code au moment de démarrer, notre grille pour choisir la base d’un MVP traite ce choix. Cet article commence là où elle s’arrête : le produit existe sur Bubble, il marche, et vous vous demandez quand et comment le reconstruire en code sans perdre vos utilisateurs ni vos données.

Un point à poser d’emblée : quitter Bubble n’est pas une migration au sens où l’on migre une application d’un hébergeur à un autre. C’est une reconstruction. Tout le reste de la démarche en découle.

Pourquoi quitter Bubble veut dire reconstruire

Le centre d’aide de Bubble est explicite : les données créées par vos utilisateurs peuvent être exportées en fichiers CSV, mais il n’existe aujourd’hui aucun moyen d’exporter une application sous forme de code. Si vous quittez la plateforme, Bubble peut fournir un export brut de la logique et du design au format JSON (centre d’aide consulté le 14 octobre 2026).

Ce fichier JSON ne se transforme pas en application Next.js qui tourne. C’est une description de vos pages, workflows et types de données, rédigée pour l’éditeur de Bubble : une documentation et une archive, pas un point de départ.

La conséquence est simple : on ne convertit pas une application Bubble, on la réécrit, en se servant de l’ancienne comme spécification. C’est un projet de construction, avec un cadrage, un périmètre et un budget. Avec un avantage : chaque écran à réécrire a déjà été validé par des utilisateurs réels.

Les signaux qu’il est temps

Aucun de ces signaux, pris seul, ne justifie une reconstruction. Deux ou trois réunis, si.

La facture suit l’usage plus vite que le chiffre d’affaires

Bubble facture la charge de calcul de votre application en workload units. Au 14 octobre 2026, la page tarifs affiche, en facturation annuelle, une formule Starter à 59 $ par mois avec 175 000 unités incluses, Growth à 209 $ avec 250 000 unités et Team à 549 $ avec 500 000 unités. Au-delà de 100 % de la charge incluse, le dépassement se paie à l’usage, ou par l’achat d’un palier supplémentaire.

Le problème n’est pas le prix d’un palier, c’est la pente. La documentation sur la charge de travail recense douze types d’activité qui comptent dans le total mensuel : chargements de page, recherches, workflows côté serveur, appels d’API, etc. Une application dont les recherches ou les workflows planifiés ont été écrits vite peut consommer beaucoup plus qu’une application identique à l’écran. Si votre consommation croît plus vite que vos utilisateurs, commencez par l’outil App metrics de Bubble et optimisez : c’est moins cher qu’une reconstruction. Si, une fois optimisée, la facture projetée à dix fois votre volume actuel ne tient pas dans votre marge, le signal est réel.

La performance devient un sujet de conversation avec les clients

Pages qui chargent lentement, listes qui mettent plusieurs secondes à s’afficher, workflows qui s’exécutent avec du retard : sur Bubble, une partie de ces problèmes se corrige dans l’éditeur. Une autre partie peut tenir à la plateforme elle-même, et là, vous n’avez pas la main. Quand vos clients commencent à en parler, et surtout quand vous avez déjà optimisé ce qui pouvait l’être, la question de la sortie devient légitime.

La logique métier ne tient plus dans l’éditeur

C’est souvent le signal le plus net. Un calcul de prix devenu un enchaînement de conditions, des droits d’accès qui dépendent de l’organisation, du rôle et de l’état d’un dossier, des workflows qui en déclenchent d’autres. Le symptôme concret : personne, pas même vous, n’ose plus toucher à certains workflows, parce qu’on ne peut pas les tester automatiquement ni voir d’un coup d’œil ce qu’une modification va casser. En code, ces règles deviennent des fonctions testées, relues et versionnées.

Une levée de fonds approche

Un fonds qui étudie votre dossier regardera la technologie. Une application Bubble n’est pas forcément un problème pour un produit encore en validation. Les questions portent plutôt sur la dépendance : que se passe-t-il si Bubble change ses prix ? Pouvez-vous héberger les données là où vos clients l’exigent ? Combien coûterait une réécriture, et qui la paierait ? Mieux vaut avoir une réponse chiffrée et un plan que découvrir ces questions pendant la due diligence. Parfois, la bonne réponse est de lever d’abord et de reconstruire avec cet argent, en le disant.

Vous voulez recruter des développeurs

Un développeur travaille avec Git, des revues de code et des tests. Sur Bubble, il doit d’abord apprendre l’éditeur, et ses habitudes ne s’appliquent qu’en partie. Si votre plan est de constituer une équipe technique, la base de code qu’elle va maintenir pèse dans la décision.

Ce que vous récupérez, et ce que vous perdez

Quitter Bubble ne veut pas dire repartir de zéro. Quatre choses passent, à condition de les préparer.

Les données. Deux voies, toutes deux documentées par Bubble :

• l’export depuis l’éditeur (Data, puis App data), type de données par type de données, en CSV notamment : Bubble envoie un lien de téléchargement par e-mail quand l’export est prêt. La même page signale que l’export partage la file d’attente des workflows planifiés, et que les champs de durée sortent en texte (« 2 days ») plutôt qu’en millisecondes ;
• la Data API, désactivée par défaut, qui permet à un système externe de lire les enregistrements via une interface REST. Les requêtes renvoient 100 enregistrements par défaut, avec un curseur pour paginer, et une limite de 50 000 éléments par requête GET hors formule Enterprise (documentation consultée le 14 octobre 2026). Pour une migration répétable, c’est la voie à privilégier : un script qui lit tout par l’API se relance autant de fois que nécessaire, un export manuel non.

Pensez aux fichiers : dans les données de Bubble, images et documents téléversés par vos utilisateurs sont des URL vers le stockage de Bubble, pas des fichiers. Il faut les télécharger et les replacer dans votre propre stockage pendant la migration, pas après.

Le design. Les écrans existent, vos utilisateurs les connaissent. On ne récupère pas le code de l’interface, mais on récupère toutes les décisions : la structure des pages, les parcours, les libellés. Les reproduire fidèlement, quitte à les améliorer plus tard, réduit le choc de la bascule pour vos utilisateurs.

La connaissance du produit. Vous savez quelles fonctions servent, lesquelles ne servent pas, où les utilisateurs se perdent. C’est l’actif le plus précieux de la reconstruction, et le seul qu’un prestataire ne peut pas deviner.

Les parcours validés. Chaque workflow en production est une règle qui a été confrontée à des cas réels. Le cadrage consiste à les écrire, pas à les réinventer.

Ce que vous perdez : la logique sous forme exécutable, les plugins Bubble (chacun devra être remplacé par une bibliothèque ou un service), et les mots de passe de vos utilisateurs, qui méritent une section à part.

La méthode de reconstruction

1. Cadrer à partir de l’application existante

L’application Bubble est votre spécification. Le cadrage la parcourt écran par écran et workflow par workflow, et produit trois listes : ce qu’on reproduit à l’identique, ce qu’on simplifie, et ce qu’on abandonne. Cette troisième liste est importante. Une application qui a vécu deux ans sur Bubble contient des fonctions que plus personne n’utilise : les reconstruire coûte cher et n’apporte rien.

Le schéma de données mérite une attention particulière. Les types de données Bubble se traduisent rarement tels quels en tables relationnelles : les champs de type liste, en particulier, deviennent souvent des tables de liaison. Les règles de confidentialité (privacy rules) de Bubble, elles, deviennent des contrôles d’accès côté serveur, à réécrire et à tester un par un.

Pour structurer ce document, ce qu’un prestataire lit en premier pour chiffrer un MVP s’applique presque tel quel, avec un avantage : vous pouvez montrer chaque parcours au lieu de le décrire.

2. Migrer les données, et répéter la migration

La migration des données n’est pas une étape qu’on fait une fois le jour J. C’est un script qu’on écrit tôt et qu’on exécute des dizaines de fois : sur une copie, puis sur une copie plus récente, jusqu’à ce qu’il tourne sans erreur et que les chiffres concordent (nombre d’utilisateurs, de commandes, de documents de part et d’autre). Le jour de la bascule, on le relance une dernière fois sur les données fraîches.

Gardez les identifiants Bubble de chaque enregistrement dans une colonne dédiée de la nouvelle base. Ils servent à vérifier, à rattraper un oubli, et à rediriger les anciennes URL qui contiennent un identifiant.

3. Les comptes utilisateurs et les mots de passe

C’est le point qui fait perdre des utilisateurs quand on le traite trop tard. La documentation de Bubble sur les comptes utilisateurs indique que le champ mot de passe est invisible, même pour le développeur de l’application, et que les mots de passe sont stockés sous forme de hash salé (consulté le 14 octobre 2026). Vous récupérerez les e-mails et les profils, pas de quoi reconnaître un mot de passe dans votre nouvelle application.

Trois approches, à choisir selon votre public :

• la réinitialisation à la bascule : chaque utilisateur reçoit un e-mail pour définir un nouveau mot de passe, ou un lien de connexion à usage unique. C’est la plus simple, mais une partie des utilisateurs ne cliquera pas, et chacun de ceux-là est un compte qui risque de ne jamais revenir ;
• la migration au fil des connexions : pendant une période de transition, la nouvelle application reçoit l’e-mail et le mot de passe saisis, les vérifie auprès de Bubble, et, si Bubble les accepte, enregistre le mot de passe sous son propre hash. La documentation de Bubble décrit la brique nécessaire : un workflow API qui exécute l’action Log the user in et renvoie un jeton. Les utilisateurs actifs migrent sans s’en apercevoir ; il faut garder l’abonnement Bubble pendant la transition, puis basculer les retardataires vers la réinitialisation ;
• la connexion sans mot de passe : si votre produit s’y prête, passer à des liens magiques ou à la connexion Google ou Microsoft supprime la question.

Quelle que soit l’option, prévenez vos utilisateurs avant, par e-mail et dans l’application, et dites-leur ce qui va changer pour eux.

4. Basculer progressivement

Éviter le « grand soir » où tout change en même temps. Selon la structure de votre produit, plusieurs découpages sont possibles :

• par population : un groupe de clients volontaires passe sur la nouvelle application, les autres restent sur Bubble, puis on élargit ;
• par fonction : une partie isolable du produit (un espace d’administration, un module de reporting) est reconstruite et mise en service d’abord, en lisant les données de Bubble par la Data API ;

Dans tous les cas, fixez une date de gel : à partir de ce jour, plus aucune évolution sur Bubble. Faire évoluer deux applications en même temps est le moyen le plus sûr de n’en terminer aucune. Et gardez un retour arrière possible tant que la nouvelle version n’a pas fait ses preuves.

5. Les URL et le référencement, si l’application a des pages publiques

Si votre application Bubble expose des pages publiques indexées (profils, annonces, fiches, articles), changer de plateforme change souvent leurs URL. Google recommande pour ces déménagements d’établir la correspondance entre chaque ancienne URL et sa nouvelle adresse, d’utiliser des redirections permanentes côté serveur (301 ou 308) et de les conserver le plus longtemps possible, en général au moins un an (consulté le 14 octobre 2026).

Concrètement : relevez les URL qui reçoivent du trafic dans Search Console avant la bascule, conservez la même structure quand c’est possible, redirigez le reste, et soumettez le nouveau sitemap le jour J. Les pages dynamiques dont l’URL contient un identifiant Bubble se redirigent grâce à la colonne d’identifiants évoquée plus haut.

Quand rester sur Bubble

Une reconstruction coûte cher et immobilise votre attention pendant des semaines. Restez sur Bubble si :

• la facture reste raisonnable une fois l’application optimisée, et le restera à l’échelle que vous visez ;
• vous n’avez pas encore trouvé votre marché. Reconstruire un produit qui va encore changer de direction, c’est payer deux fois. Bubble est fait pour itérer vite ;
• la logique métier reste simple et l’éditeur l’exprime sans contorsions ;
• personne ne vous demande de garanties que Bubble ne peut pas fournir sur l’hébergement ou l’accès aux données ;
• la reconstruction tomberait au pire moment : juste avant un lancement, en pleine levée, ou sans trésorerie pour la mener à son terme. Une reconstruction abandonnée à mi-chemin est la pire des situations.

Une voie intermédiaire existe parfois : sortir de Bubble seulement ce qui coince, par exemple un traitement lourd confié à un service externe que Bubble appelle par API, et garder le reste. Cela achète du temps sans engager la reconstruction complète.

Et passer par Lovable ou un autre générateur ?

La tentation est compréhensible : décrire l’application Bubble à un générateur de code par IA et obtenir une version React en quelques jours. Pour retrouver rapidement des écrans proches de l’existant, cela peut aider. Mais le générateur ne connaît ni vos règles métier, ni vos données, ni vos contraintes d’accès, et c’est précisément là que se joue une reconstruction. Vous échangeriez une dépendance à Bubble contre du code que personne n’a relu, avec les failles d’accès aux données qu’on retrouve souvent dans ces applications. Nous avons repris une douzaine d’applications générées par IA pour les mettre en production : le travail de vérification n’y est jamais anecdotique. Si vous avez déjà engagé cette voie, notre audit de reprise d’app Lovable, Bolt ou v0 vous dit ce que vaut le code obtenu avant que vous y transfériez vos utilisateurs.

Par où commencer

Avant de décider, faites trois choses en une semaine : mesurez votre consommation de workload units et projetez-la à dix fois votre volume, listez les workflows que personne n’ose plus modifier, et activez la Data API sur une copie pour vérifier que toutes vos données sortent proprement. Si ces trois exercices ne révèlent rien d’alarmant, restez sur Bubble et refaites l’exercice dans six mois.

S’ils confirment qu’il faut partir, traitez la reconstruction pour ce qu’elle est : un projet de MVP, avec un avantage rare, celui d’une spécification qui tourne déjà en production. Notre façon de construire un MVP SaaS s’y applique : un cadrage qui tranche ce qu’on reproduit et ce qu’on abandonne, des livraisons démontrables chaque semaine ; la migration des données et des comptes s’ajoute au périmètre. Vous pouvez nous décrire votre application via le formulaire ou sur WhatsApp.