Migrer de Bubble vers du code : comment on a basculé Tala en une nuit

Migrer de Bubble vers du code, c'est reconstruire l'application ailleurs, puisque Bubble n'exporte pas son code, puis y transférer les données exportées en CSV ou lues par l'API, avant de basculer les utilisateurs. Si cette bascule a été répétée sur un export à blanc, elle tient en une nuit ; le gros du travail se fait avant, dans la traduction du modèle de données et dans un script de migration qu'on peut rejouer sans rien casser.

Nous en parlons parce qu'on l'a fait chez nous. Tala, notre produit d'agents vocaux IA, a démarré sur Bubble avec ses comptes clients, ses organisations, ses assistants vocaux, ses historiques d'appels, ses numéros de téléphone et ses abonnements Stripe. Des clients payaient chaque mois. Nous avons reconstruit l'application en code pendant que la version Bubble continuait de les servir, puis nous avons tout basculé en une nuit. Nous racontons ici la méthode, le piège qui a failli gâcher la matinée de nos clients, et la façon de décider si votre app doit suivre le même chemin.

Un point a changé la donne depuis deux ans : avec des agents de code comme Claude Code, reconstruire une application de cette taille coûte nettement moins cher qu'avant. Le débat porte donc moins sur le budget que sur ce qu'on garde, l'ordre des chantiers et la manière de basculer sans casser les clients.

Peut-on exporter le code d'une application Bubble ?

Non, aucune option ne permet d'exporter le code d'une application Bubble. Le manuel officiel le dit sans détour : une app Bubble ne tourne que sur la plateforme Bubble, il n'existe aucun moyen de l'exporter sous forme de code, et si vous partez, vous devrez reconstruire la logique de l'application, Bubble disant seulement pouvoir aider à exporter le design (page « Application and data ownership » du manuel Bubble). Bubble précise que vous possédez vos données et le design de votre app, mais que l'éditeur garde la propriété du code qui la fait tourner.

Ce qui sort, ce sont les données. Depuis l'onglet Data, chaque type de données s'exporte en CSV, en JSON ou en NDJSON, et Bubble envoie un e-mail avec le lien de téléchargement quand le fichier est prêt (manuel Bubble, « Exporting data »). L'export depuis l'éditeur est réservé aux plans payants, et pour de gros volumes le manuel recommande plutôt de lire la base par script via l'API (manuel Bubble, « The database editor »). Les pages, les workflows, les règles de confidentialité et les conditions affichées à l'écran ne sortent pas : ils se réécrivent.

Si la portabilité du code compte pour votre prochain projet, nous avons comparé les outils no-code qui exportent réellement leur code ; Bubble n'en fait pas partie, et ce choix d'architecture est assumé par l'éditeur.

Quand faut-il quitter Bubble, et quand vaut-il mieux rester ?

Il faut quitter Bubble quand l'outil freine le produit qui fait vivre l'entreprise, et rester tant qu'il vous laisse avancer plus vite qu'une équipe de développeurs. Le premier signal est souvent la facture. Au 14 octobre 2026, la page tarifs de Bubble affiche, pour une application web seule, le plan Starter à 29 $ par mois (facturation annuelle) avec 175 000 unités de charge par mois, Growth à 119 $ avec 250 000 unités et Team à 349 $ avec 500 000 unités (les formules web et mobile coûtent plus cher, voir aussi le tableau des plans du manuel). Au-delà du quota, sans palier supplémentaire acheté, le dépassement coûte 0,30 $ par tranche de 1 000 unités selon la FAQ tarifaire du manuel.

Ces unités de charge (workload units) mesurent tout ce que le serveur fait pour votre app : chaque écriture en base compte pour 0,5 unité, chaque action de workflow côté serveur pour 0,6 (barème officiel des activités). La facture suit donc l'usage et devient difficile à prévoir dès qu'un traitement de fond s'emballe. Nous avons détaillé ce calcul dans ce que coûte vraiment une application Bubble.

Pour Tala, ce que nous avons gagné en quittant Bubble montre bien ce qui manquait : des tests automatisés, un historique Git de chaque modification, plusieurs environnements, des déploiements sans coupure, et surtout des agents de code IA qui travaillent directement dans le dépôt. Bubble rendait tout cela difficile. Le jour où votre feuille de route bute sur ce genre de besoin, la migration devient rationnelle.

Rester est souvent le bon choix. Si votre app n'a pas encore de clients payants, ne migrez pas : vous reconstruiriez une hypothèse qui changera encore le mois prochain. Gardez Bubble, stabilisez le produit, et si la consommation d'unités vous inquiète, faites relire vos workflows par une agence Bubble avant d'envisager un chantier de reconstruction. Même chose pour une petite app interne que votre responsable ops modifie lui-même chaque semaine. Et si votre contrainte est l'emplacement des données, le plan Enterprise propose le choix du lieu d'hébergement, sur devis (page tarifs Bubble). Quand on hésite, le plus utile reste un audit de votre application et de ce que l'IA peut y reprendre, qui chiffre ce qui se reconstruit vite et ce qui demandera du temps.

Peut-on garder Bubble en back-end et refaire seulement le front ?

Oui, c'est techniquement possible grâce à la Data API de Bubble, mais nous le déconseillons comme destination finale. La documentation de la Data API explique qu'elle expose une interface REST pour lire, créer, modifier et supprimer les enregistrements de votre base. Elle est désactivée par défaut, s'active dans Settings puis API, et vous choisissez type par type ce qui est exposé.

Le problème vient de ce qui reste en place. Chaque appel entrant vers la Data API ou la Workflow API consomme 0,01 unité de charge, plus un coût par octet échangé, d'après le barème des activités. Votre nouveau front interroge Bubble à chaque écran, donc vous payez toujours à l'usage, et la logique métier reste dans des workflows qu'on ne teste ni ne versionne comme du code. Pour comprendre un bug, il faut lire deux systèmes.

Ce montage a deux usages honnêtes. D'abord comme passerelle pendant la reconstruction, pour lire les données en direct et comparer les deux versions. Ensuite quand le front Bubble convient encore et que seul le back-end souffre ; on peut alors faire l'inverse et brancher Bubble sur un back-end Xano, ce qui déplace la logique lourde hors de l'outil tout en gardant l'interface.

Pour Tala, on a reconstruit front et back ensemble, sur un socle open source de plateforme d'agents vocaux : backend Python (FastAPI), PostgreSQL, front React et Next.js, Stripe conservé pour les paiements. Garder un morceau de Bubble nous aurait obligés à maintenir deux mondes, puis à migrer une seconde fois. Notre avis est tranché : si vous partez pour de bon, partez d'un bloc, et servez-vous de la Data API uniquement comme d'un outil de transition.

Comment migrer les données d'une app Bubble sans recopier ses défauts ?

On exporte chaque type de données depuis Bubble, puis un script les transforme vers le nouveau modèle et les insère en gardant la trace de chaque ancien identifiant. Le mot important est « transforme ». Un modèle de données Bubble a été dessiné avec les contraintes de Bubble ; le recopier tel quel dans une base PostgreSQL, c'est importer ces contraintes dans un système qui n'en a plus besoin.

Chez Tala, nous avons exporté en CSV, table par table, les organisations, les utilisateurs, les abonnements, les assistants, les historiques d'appels et les numéros. Un « assistant » Bubble se résumait à un message d'accueil et un prompt. Dans la nouvelle version, chaque assistant est devenu un workflow à nœuds (début, accueil, agent, fin). Migrer revenait à traduire chaque assistant dans cette forme, donc à comprendre ce que l'ancien faisait vraiment.

Le script doit pouvoir tourner dix fois sans créer de doublon. Le nôtre avait les propriétés suivantes :

• un mode de validation seule (« --dry-run ») qui lit tout et n'écrit rien ;
• une option pour ne traiter que quelques organisations (« --limit N ») ;
• une reprise à une étape donnée (« --start-from ») quand une étape plante au milieu ;
• un cache de correspondance entre l'identifiant Bubble et le nouvel identifiant, qui rend le script rejouable sans doublon ;
• un second script de vérification qui recompte organisations, utilisateurs, agents et historiques, et contrôle les métadonnées Stripe.

Les clients payants ont gardé leur abonnement Stripe. Nous avons mis à jour les métadonnées des clients et des abonnements pour qu'elles pointent vers les nouveaux identifiants d'organisation, puis réaligné le jour de facturation de chaque client sur son ancre de facturation Stripe, pour que le quota mensuel se remette à zéro le même jour que la facture.

Prévoyez aussi les surprises de format. Le manuel signale qu'un champ de durée stocké en millisecondes sort de l'export sous forme de texte descriptif, par exemple « 2 days » pour 172 800 000 millisecondes (« Exporting data », section Known issue). L'export passe aussi par la file d'attente des workflows planifiés et peut prendre du retard, un détail qui compte le soir de la bascule. Enfin, l'ancienne plateforme fixait des réglages sans le dire : chez nous, la transcription vocale basculait en anglais tant que la langue n'était pas explicitement réglée sur le français. Listez ces paramètres implicites avant de partir.

Que deviennent les mots de passe des utilisateurs Bubble ?

Les mots de passe ne suivent pas la migration. Le manuel Bubble indique qu'ils sont stockés sous forme de hachage salé et que ce champ reste invisible, y compris pour le développeur de l'app (manuel Bubble, « User accounts »). Le hachage est une transformation à sens unique : personne ne peut retrouver le mot de passe d'origine, et rien d'utilisable par un autre système ne sort à l'export. C'est une bonne pratique de sécurité, et il faut la prévoir dès le début du projet.

Concrètement, vous recréez les comptes dans le nouveau service d'authentification à partir des e-mails exportés, puis chaque utilisateur définit un nouveau mot de passe à sa première connexion, par un lien de réinitialisation ou un lien de connexion envoyé par e-mail. Vos clients doivent le savoir avant le jour J. Un message court envoyé quelques jours avant évite une vague de tickets au support.

Pour Tala, nous avons recréé les utilisateurs dans le nouveau service de connexion avec leur adresse e-mail déjà marquée comme vérifiée et sans mot de passe : à la première connexion, chacun passait par « mot de passe oublié ». Nous avons aussi coupé tout envoi d'e-mail automatique pendant la nuit de bascule. Un service d'authentification peut envoyer un message de bienvenue à chaque compte créé ; imaginez vos clients payants recevant « Bienvenue ! » à une heure du matin pour un service qu'ils utilisent depuis des mois. Vérifiez cette configuration avant de lancer le script, pas après.

Pensez enfin aux favoris de vos utilisateurs : gardez le même domaine et redirigez les anciennes adresses de pages vers les nouvelles.

Comment se passe la nuit de bascule d'une app Bubble vers du code ?

La nuit de bascule rejoue pour de vrai ce qu'on a déjà fait l'après-midi sur un export à blanc : export final, script, vérification, rebranchements, recette, ouverture. Si elle vous paraît risquée, c'est qu'elle n'a pas été répétée.

Chez Tala, la reconstruction a pris plusieurs mois pendant lesquels Bubble continuait de servir les clients. Le jour J, nous avons fait un premier export complet l'après-midi et fait tourner le script en validation seule. Ce passage à blanc sert à voir les erreurs l'après-midi plutôt qu'à minuit. Le soir, export final, puis lancement réel du script dans la nuit. Ensuite, mise à jour des métadonnées Stripe, rebranchement des numéros de téléphone des clients côté opérateur vers la nouvelle application, et passage du script de vérification.

Tout était vert. Puis nous nous sommes connectés avec un vrai compte client migré, et ce client ne voyait aucun de ses agents. Le script avait rattaché les organisations à l'identifiant d'invitation hérité de Bubble au lieu de l'identifiant d'équipe du nouveau service de connexion. Les données étaient bien là, mais personne n'y avait accès. Avec un compte administrateur, qui voit tout, nous n'aurions rien remarqué. Un script dédié a corrigé le rattachement dans la nuit, avant l'arrivée des premiers clients.

La leçon vaut pour toute migration Bubble : recettez avec un compte client réel migré, jamais avec votre compte admin. Choisissez deux ou trois clients représentatifs et parcourez leurs écrans clés avant d'annoncer quoi que ce soit. Gardez aussi l'application Bubble intacte et accessible en lecture tant que la vérification n'est pas terminée. Si quelque chose casse, vous devez pouvoir revenir en arrière sans perdre une donnée.

Quand le site marketing de Tala a quitté Webflow, les redirections ont demandé le même soin ; nous le détaillons dans l'article sur la migration de Webflow vers Astro.

Combien de temps prend une migration de Bubble vers du code, et combien coûte-t-elle ?

Le délai et le budget d'une migration Bubble dépendent de trois facteurs que vous pouvez estimer vous-même. Le périmètre fonctionnel d'abord : nombre d'écrans, de workflows, de rôles utilisateurs, et part de logique qui tourne côté serveur. Les données ensuite : combien de types, combien de relations entre eux, et quel historique vous devez absolument conserver. Les intégrations enfin : paiement, téléphonie, envoi d'e-mails, outils tiers branchés par API. Chaque intégration est un point à rebrancher la nuit de la bascule.

Un quatrième facteur pèse souvent plus que prévu : le nombre de clients actifs qui doivent traverser la migration sans friction. Une app interne de vingt utilisateurs supporte une matinée de flottement, un SaaS avec des abonnements mensuels ne la supporte pas.

Ce qui a le plus changé, c'est le coût de la reconstruction elle-même. Avec des agents de code comme Claude Code qui travaillent dans le dépôt, écrire les écrans, les tests et les scripts de migration va beaucoup plus vite qu'il y a deux ans. Dominique explique dans sa vidéo pourquoi le code va désormais plus vite que le no-code avec l'IA, et le guide pour utiliser Claude Code au quotidien montre comment on s'y prend. L'IA ne décide pas à votre place du nouveau modèle de données, et elle ne remplace pas la recette avec un compte client. Elle raccourcit la partie la plus longue, ce qui rend la migration accessible à des produits qui n'auraient jamais pu se l'offrir.

Chez Noxcod, on ne chiffre pas sans avoir vu l'application : deux apps Bubble d'apparence identique cachent parfois des volumes de logique très différents. Si vous préparez une migration Bubble vers du code sur mesure, l'échange commence par la liste de vos types de données, de vos workflows serveur et de vos intégrations. Et si la conclusion est de reconstruire, cela devient un projet de développement sur mesure classique, avec une bascule préparée comme on l'a fait pour Tala.

Questions fréquentes

Combien de temps faut-il pour migrer une application Bubble vers du code ?

La bascule elle-même tient en une nuit si elle a été répétée sur un export à blanc. La reconstruction prend plus longtemps et dépend du nombre d'écrans, de workflows serveur, de types de données et d'intégrations. Pour Tala, elle s'est étalée sur plusieurs mois en partant d'un socle open source, pendant que Bubble servait les clients. Les agents de code IA raccourcissent nettement cette phase, sans supprimer le travail sur le modèle de données.

Faut-il arrêter de développer sur Bubble pendant la reconstruction ?

Gelez les nouvelles fonctionnalités, pas les corrections. Chaque champ ajouté dans Bubble pendant la reconstruction devra être reporté dans le nouveau modèle et dans le script de migration. Le plus simple est de figer le schéma de données Bubble dès que le script est écrit, de ne corriger que les bugs bloquants, et de reporter toute nouveauté sur la version en code. Sinon, vous migrez une cible qui bouge.

Mes clients verront-ils une coupure pendant la migration ?

Ils peuvent ne rien voir si la bascule se fait la nuit et que vous avez répété le processus l'après-midi même. Ce qu'ils verront presque toujours, c'est la demande de nouveau mot de passe, puisque Bubble ne laisse pas sortir les mots de passe. Prévenez-les avant, coupez les e-mails automatiques pendant la nuit, et vérifiez leurs écrans avec un vrai compte client avant l'heure d'ouverture.

Quelle alternative à Bubble pour une application qui grossit ?

Tout dépend de ce qui coince. Si seul le back-end souffre, déplacer la logique lourde vers un back-end comme Xano en gardant le front Bubble peut suffire. Si vous avez besoin de tests, de versionnage, de plusieurs environnements et d'agents IA dans le code, une stack classique (base PostgreSQL, API, front React) devient plus simple à faire évoluer. Partez de votre feuille de route des douze prochains mois pour trancher.

Peut-on revenir sur Bubble si la migration se passe mal ?

Oui, à condition de l'avoir prévu. Ne supprimez rien côté Bubble la nuit de la bascule : gardez l'application et sa base intactes, mettez simplement l'ancienne version hors ligne pour les clients. Tant que la vérification et la recette ne sont pas terminées, un retour arrière reste possible en remettant les accès et les intégrations sur Bubble. Après quelques jours d'usage réel sur la nouvelle version, la source de vérité a changé de camp.