Sortir de Bubble ou FlutterFlow sans perdre ses utilisateurs

Réponse courte

Pour migrer de Bubble ou FlutterFlow vers React Native sans désorganiser une base active, commence par auditer les comptes, les données, les paiements et les accès aux stores. Construis la nouvelle application en parallèle, teste l'import sur une copie, puis bascule par cohortes avec un retour arrière possible. Une migration avec abonnements récurrents relève plutôt d'un budget de 25 000 à 70 000 € HT selon le brief et demande plusieurs mois de préparation et d'exécution. Le prix final dépend surtout de la qualité des exports, des intégrations et du mode de publication de l'app existante. Inyka ne chiffre pas ce type de reprise au forfait avant un audit.

Ce qu'on migre vraiment

« Sortir du no-code » donne l'impression qu'il suffit de remplacer des écrans. Le travail porte aussi sur les identités, l'historique, les règles métier, les fichiers et les droits d'accès. Une personne qui retrouve une jolie interface mais perd son abonnement considère que la migration a échoué.

La distinction entre Bubble et FlutterFlow compte. Bubble indique que les données peuvent être exportées, mais que la logique de l'application doit être reconstruite. FlutterFlow propose un export du code Flutter. Passer de FlutterFlow à React Native reste une réécriture du client mobile, même si le code exporté aide à comprendre certains parcours. Il ne faut pas vendre ces deux situations comme un même « export de code ».

Avant le devis, je demanderais une démonstration de chaque parcours actif et une liste des intégrations. Quels écrans sont encore utilisés ? Quelles automatisations envoient un email, prélèvent un paiement ou modifient un statut ? Ce relevé évite de reproduire une fonction oubliée, ou de payer pour une fonction que plus personne n'ouvre. Pour décider quand quitter le no-code, lis aussi notre comparaison no-code et React Native.

Auditer les accès avant de dessiner la nouvelle app

La première livraison utile est un inventaire, pas une maquette. Il doit lister les tables et leurs relations, les comptes utilisateurs, les médias, les automatisations, les services tiers et les détenteurs des comptes de publication. Pour chaque élément, note qui peut exporter, qui peut modifier et qui peut rétablir l'ancien fonctionnement.

Prends un exemple banal : un utilisateur possède trois réservations, une photo de profil et un abonnement Stripe. Si l'export contient son email mais pas l'identifiant qui relie ses réservations au paiement, importer quatre lignes ne reconstitue pas son compte. Il faut définir une clé de correspondance stable et vérifier les relations après import.

L'audit doit aussi montrer où se trouve le contrat de paiement : Stripe direct, achat intégré Apple ou Google, RevenueCat, ou plusieurs systèmes à la fois. Cette réponse change la méthode et le prix. Enfin, vérifie à qui appartiennent le code et les comptes techniques. Sans accès au compte store ou à la base source, le calendrier n'a aucune valeur.

Construire en parallèle, sans déplacer les utilisateurs trop tôt

Inyka reconstruit le client mobile en React Native et Expo avec un backend adapté au projet, souvent Supabase. La nouvelle app tourne d'abord sur des données de test, puis sur une copie contrôlée des données réelles. La version actuelle continue de servir les utilisateurs pendant cette phase. On évite ainsi de faire dépendre leur activité d'un chantier encore incomplet.

Le périmètre ne doit pas être une photographie automatique de l'existant. Une fonction rarement utilisée peut sortir de la première version, mais seulement après avoir vérifié son rôle réel : faible trafic ne veut pas dire faible importance. Une page de récupération de compte, par exemple, est peu ouverte jusqu'au jour où elle devient nécessaire. Les parcours à préserver en priorité sont connexion, action principale, paiement et assistance.

Prévois une grille de comparaison écran par écran, mais teste surtout les actions complètes. Un utilisateur doit pouvoir se connecter, retrouver ses informations, terminer une action et recevoir le bon statut. La méthode de cadrage d'une app mobile aide à fixer ces critères avant de produire le premier build.

Migrer les données avec une répétition générale

Une migration sérieuse commence par une exportation d'essai. On transforme les identifiants, on importe dans une base de test et on compare les comptes, les relations et les fichiers. Les erreurs doivent être listées par catégorie : email absent, date invalide, référence cassée, média introuvable. Corriger à la main quelques profils pendant la répétition ne règle pas le problème pour toute la base.

Le jour de la bascule, une fenêtre de gel ou une synchronisation des changements récents peut être nécessaire. Cela dépend du rythme auquel les données bougent. Si les utilisateurs créent des commandes toute la journée, un export pris la veille laisse un trou. Il faut alors rejouer les modifications intervenues entre le dernier import de test et l'ouverture de la nouvelle version.

Documente aussi le retour arrière. Si les comptes ne se chargent plus ou si les paiements apparaissent en double, qui arrête le déploiement et quel système redevient la référence ? Un plan de secours utilisable vaut plus qu'une promesse de « migration sans perte ». Le contrôle final se fait sur des parcours réels, avec un petit groupe d'utilisateurs et leur accord, avant l'ouverture générale.

Abonnements : conserver l'accès, pas seulement les identifiants

Avec Stripe, récupérer un identifiant de client ne suffit pas. Il faut relier le bon compte applicatif à la bonne souscription, vérifier les statuts en cours et les événements de facturation, puis tester renouvellement, échec de paiement et annulation. Le système de paiement peut continuer à débiter pendant que l'app change. C'est précisément pourquoi l'état des droits doit être contrôlé des deux côtés.

Pour les achats intégrés, l'identité de l'application sur les stores compte. Publier une mise à jour sous la fiche existante et créer une nouvelle fiche ne produisent pas le même résultat. Apple documente le transfert d'une app et les précautions pour ses abonnements renouvelables. Google décrit également le transfert des abonnements avec une app. Une nouvelle application distincte exige une stratégie de reconnaissance des droits, des tests et parfois une démarche utilisateur.

La règle est simple : aucune bascule des abonnés avant un test de bout en bout sur chaque canal de paiement utilisé. Si la situation est mixte ou que l'ancien prestataire contrôle le compte développeur, l'audit doit le signaler avant tout prix fixe.

Choisir une bascule que l'on peut surveiller

Il existe deux chemins principaux. Une mise à jour de l'application existante garde sa fiche store si les comptes et identifiants le permettent. Une nouvelle application demande aux utilisateurs de l'installer et crée davantage de friction. Dans les deux cas, le backend et les paiements doivent rester cohérents pendant la transition.

Une petite cohorte interne ouvre le bal, suivie d'utilisateurs volontaires, puis du reste de la base. On suit les connexions réussies, les données manquantes, les paiements, les demandes au support et les désinstallations. Aucun seuil universel de « 60 % migrés » ne justifie à lui seul l'arrêt de l'ancienne version : il faut regarder qui manque encore, surtout parmi les abonnés actifs.

La communication doit répondre à une question concrète : « Qu'est-ce que je dois faire ? » Un message avant la sortie annonce la date et les changements visibles. Le jour du lancement, donne un lien store, la procédure de connexion et un contact de support. Un rappel ciblé ne part qu'aux comptes qui n'ont pas terminé le passage. Évite de promettre que rien ne changera si une reconnexion ou un nouveau téléchargement est nécessaire.

Budget : ce que le chiffre recouvre

Le brief situe une migration simple autour de 25 000 € HT et un cas avec paiements récurrents et intégrations vers 50 000 à 70 000 € HT. Ce sont des ordres de grandeur de cadrage, pas un tarif Inyka applicable sans lecture du système. L'offre Scale commence à 24 000 € HT pour une app complexe, mais une reprise active ajoute des inconnues que la création d'un produit neuf n'a pas.

Poste	Ce qu'il faut vérifier
Audit	Exports, accès, parcours, dépendances et scénario de publication
Nouvelle app	Fonctionnalités conservées, backend, tests et builds
Données	Import d'essai, corrections, fichiers et contrôle après bascule
Abonnements	Correspondance des comptes, droits et événements de paiement
Transition	Cohortes, assistance, suivi et retour arrière

Un devis qui ne nomme que les écrans manque une grande partie du chantier. Pour comparer les lignes, pars de notre guide du prix d'une application mobile et demande une ligne distincte pour chaque risque de migration.

Les pièges qui cassent une migration pourtant bien préparée

Exporter une seule fois, trop tôt. Une base continue de changer pendant la reconstruction. Un export correct le lundi ne contient pas les commandes du mardi. Fixe une heure de référence, puis prévois un gel ou un import des changements intervenus depuis cette heure.

Confondre compte et adresse email. Deux comptes peuvent partager une adresse familiale ; une personne peut aussi avoir changé d'email depuis son achat. La correspondance entre ancien et nouveau système doit s'appuyer sur des identifiants stables et traiter les exceptions dans un journal.

Tester des données sans tester les droits. Les lignes sont présentes, mais l'app refuse l'accès à un abonné ou révèle un fichier à la mauvaise personne. Pour chaque profil de test, vérifie les données visibles, les actions autorisées et les événements de paiement.

Éteindre l'ancien support le jour de sortie. Les utilisateurs qui rencontrent un problème cherchent le canal qu'ils connaissent. Maintiens une adresse et un responsable capables de comprendre les deux versions jusqu'à la fin de la transition.

Annoncer une date avant l'accord des stores. Le build peut être prêt sans être encore disponible. Prépare les messages avec une fenêtre de publication, puis envoie le lien définitif seulement après vérification des fiches iOS et Android.

Ce qu'Inyka refuse sur une sortie no-code

Un forfait de reprise signé avant l'inventaire des données, comptes, paiements et droits de publication. L'audit doit réduire les inconnues qui changent le prix.
Une promesse de « zéro perte utilisateur ». On peut organiser les contrôles et le support, pas décider à la place de chaque personne si elle continue à utiliser le produit.
Un basculement des abonnements sur la base d'une simple liste d'emails. Les droits et les événements de renouvellement doivent être vérifiés sur le canal qui facture.
Une nouvelle app qui ajoute des fonctions pendant que le parcours principal reste instable. La migration est déjà un changement pour l'utilisateur ; la roadmap produit reprend après la continuité d'usage.

Checklist avant d'ouvrir la nouvelle version

La personne qui valide la mise en ligne doit pouvoir répondre oui, avec une preuve, à chacun de ces points :

Le propriétaire détient le dépôt, la base et les comptes développeur nécessaires.
Un export récent des tables et des fichiers peut être relu et restauré.
Les comptes de test couvrent abonnés actifs, paiements échoués et comptes gratuits.
Chaque identifiant importé pointe vers le bon historique et les bons médias.
Connexion, récupération de compte et suppression de compte fonctionnent.
Un achat, un renouvellement et une annulation donnent le bon droit d'accès.
Les anciennes et nouvelles versions indiquent la même source de vérité pendant la transition.
Les personnes du support disposent de la procédure de diagnostic et d'escalade.
Le message de lancement contient le bon lien store et les étapes de connexion.
Une personne nommée peut arrêter le déploiement et appliquer le retour arrière.

Cette liste n'exige pas que tous les utilisateurs aient déjà migré. Elle fixe les conditions minimales pour ouvrir la porte sans confondre vitesse de sortie et continuité du service.

FAQ

Que deviennent les photos et documents envoyés par les utilisateurs ? Ils doivent figurer dans l'inventaire, être copiés avec leurs droits d'accès et rester reliés aux bons comptes. Un export des seules tables ne suffit pas si les fichiers sont hébergés séparément.

Faut-il prévenir les utilisateurs d'une nouvelle politique de données ? Vérifie ce qui change dans l'hébergement, les prestataires et les informations collectées. Les textes et messages envoyés aux utilisateurs doivent refléter le fonctionnement réel de la nouvelle version.

Faut-il changer de mot de passe après la migration ? Cela dépend de la méthode d'authentification et des données récupérables. Si les secrets de connexion ne sont pas transférables en sécurité, prévois une réinitialisation guidée plutôt qu'une tentative de copie fragile.

Peut-on garder les avis de l'App Store ? Une mise à jour de la fiche existante les conserve. Apple indique qu'un transfert officiel d'app entre comptes conserve aussi notes et avis ; une nouvelle fiche constitue un autre produit.

Quand fermer l'ancienne version ? Après vérification des droits des abonnés, des données et des parcours essentiels, puis après une période d'assistance définie au cadrage. Le nombre d'installations de la nouvelle app ne suffit pas.

Que faire d'un compte sans adresse email valide ? Prévois une procédure d'identification alternative et un traitement par le support. Ne fusionne pas deux comptes sur la seule base d'un nom affiché.

Peut-on tester avec de vrais utilisateurs avant la sortie ? Oui, avec un groupe volontaire et une version de test adaptée à chaque store. Leurs retours doivent porter sur des tâches complètes, pas seulement sur l'apparence des écrans.

Qui répond si un abonnement est facturé mais non reconnu ? Nomme un responsable du support et donne-lui un chemin pour vérifier le paiement puis rétablir le droit. Ce cas doit être répété avant l'ouverture générale.

Cadrer la sortie avant de chiffrer

Si ton produit a déjà des utilisateurs, commence par faire inventorier ce qui doit survivre à la bascule. Cadrer la sortie de ton no-code avec Inyka sert à décider du périmètre, du mode de publication et des tests nécessaires avant de signer un devis de migration.

Réserver un appel découverte de 30 minutes pour présenter les accès, les abonnements et la base à préserver.