FlutterFlow : quand passer au code Flutter, et comment reprendre votre projet

Une application FlutterFlow gagne à passer au code Flutter lorsque ses évolutions s'écrivent davantage en code que dans l'éditeur visuel : une logique métier qui s'étoffe, des développeurs qui rejoignent le projet, des règles d'accès aux données plus fines. Comme FlutterFlow génère déjà du Flutter, ce passage ne fait pas repartir de zéro : les écrans, le projet Firebase, les données et les comptes de vos utilisateurs sont conservés. Highway Studio est une agence Flutter et Firebase qui reprend les projets FlutterFlow : nous partons de votre application telle qu'elle fonctionne, nous fixons le prix et la date avant de commencer, et nous vous remettons un code source organisé, que tout développeur Flutter peut reprendre.

Agence FlutterFlow ou agence Flutter : laquelle choisir ?

Tout dépend de ce que votre application doit devenir dans les mois qui viennent. Une agence FlutterFlow continue de construire dans l'éditeur visuel ; une agence Flutter travaille dans le code que FlutterFlow génère, ou le reconstruit.

Highway Studio est une agence Flutter : nous développons en Flutter, la technologie de Google pour les applications multiplateformes, avec Firebase côté serveur, et nous reprenons les applications nées sur FlutterFlow. Voir notre expertise Flutter et Firebase.

Que vaut le code généré par FlutterFlow ?

C'est un véritable projet Flutter, que l'on peut compiler et faire évoluer hors de FlutterFlow. D'après la documentation de FlutterFlow, consultée le 8 novembre 2026, l'export contient le fichier de configuration du projet (pubspec.yaml), les ressources de l'application, et tout le code Dart dans le dossier lib/. Son organisation reflète celle de l'éditeur :

• Un dossier par page et par composant, chacun avec un fichier d'interface et un fichier de modèle.
• Un état global unique, la classe FFAppState, qui rassemble les données partagées par toute l'application.
• Un dossier flutter_flow/, produit par FlutterFlow, qui contient les utilitaires dont le code généré a besoin : navigation, animations, fonctions communes.
• Un dossier custom_code/ pour les actions et les widgets écrits par les développeurs.
• Un dossier backend/ pour les appels aux API, à Firebase ou à Supabase.

Cette organisation est cohérente pour un code que l'éditeur régénère à chaque modification. Elle l'est moins pour un code que des développeurs feront évoluer directement pendant des années : la logique métier s'y répartit entre les actions attachées aux écrans, l'état global et le code personnalisé, sans règle qui désigne la place de la suivante. C'est ce point, davantage que la qualité du code lui-même, qui décide d'un passage au code.

Comment exporter le code d'un projet FlutterFlow ?

Au 10 novembre 2026, la page de tarifs de FlutterFlow réserve le téléchargement du code source aux offres payantes, à partir de l'offre Basic (39 $ par mois, ou 29 $ par mois en facturation annuelle). L'envoi automatique du code vers un dépôt GitHub est compris dans les offres Pro et Max. FlutterFlow propose aussi un outil en ligne de commande qui exporte le code d'un projet vers un dossier de votre choix.

Quand rester sur FlutterFlow ?

Tant que l'éditeur visuel couvre l'essentiel de vos évolutions, FlutterFlow reste un excellent choix. Il permet de construire et de modifier des écrans très rapidement, de connecter Firebase ou Supabase sans écrire de serveur, et de produire des applications mobiles et web à partir d'un même projet.

Rester sur FlutterFlow est souvent la meilleure décision lorsque :

• votre application évolue surtout par ses écrans : nouveaux parcours, nouvelles présentations, ajustements visuels ;
• la personne qui la fait évoluer n'est pas développeur, et l'éditeur lui donne une réelle autonomie ;
• les besoins techniques restent ponctuels, et quelques actions personnalisées suffisent à les couvrir ;
• vous cherchez encore votre marché : tant que le produit change chaque semaine, la vitesse de l'éditeur compte davantage que l'architecture du code.

Il existe aussi une voie intermédiaire. Avec les offres Pro et Max, FlutterFlow envoie le code vers une branche GitHub dédiée, nommée flutterflow ; un développeur travaille sur une autre branche, puis fusionne les deux. La documentation précise que toute modification faite directement sur la branche flutterflow est écrasée au prochain envoi. Cette organisation fonctionne, à condition d'accepter deux sources de vérité, l'éditeur et le dépôt, et les conflits de fusion qui en découlent.

Quand passer au code Flutter ?

Le moment vient lorsque rester dans l'éditeur coûte davantage qu'il ne fait gagner. Cinq signes l'annoncent :

1. L'essentiel des nouvelles fonctions s'écrit en code personnalisé. L'éditeur ne sert plus qu'à afficher des écrans dont la logique vit ailleurs, et les règles propres au code personnalisé deviennent des contraintes : selon la documentation de FlutterFlow, les fonctions personnalisées n'acceptent aucun import, et une bibliothèque doit fonctionner sur le web pour que l'application tourne dans le mode de test de l'éditeur.
2. Des développeurs rejoignent le projet. Ils voudront travailler dans un dépôt Git, relire chaque modification et automatiser les tests, comme sur tout projet Flutter.
3. L'accès aux données demande des règles plus fines. FlutterFlow propose, pour chaque collection de Firestore (la base de données de Firebase), des niveaux d'accès prédéfinis : tout le monde, les utilisateurs connectés, les utilisateurs cités dans le document, l'utilisateur lui-même pour la collection des utilisateurs, ou personne. Dès que l'accès dépend d'un rôle, d'une organisation ou d'un abonnement, ces règles doivent être écrites sur mesure, et une partie de la logique gagne à passer côté serveur.
4. La logique côté serveur grandit : paiements, calculs, notifications programmées, échanges avec d'autres logiciels.
5. Votre application devient un actif à transmettre. Un investisseur, un repreneur ou un futur directeur technique attendra un code qu'il peut auditer et confier à toute équipe Flutter.

Aucun de ces signes n'indique que l'application a été mal construite. Ils indiquent qu'elle a trouvé ses utilisateurs et qu'elle a besoin de la suite.

Garder le code exporté ou le réécrire ?

Deux voies mènent au code Flutter, et l'audit permet de choisir entre elles.

Nous privilégions la seconde voie, pour une raison qui tient à notre méthode : chez nous, ce sont les maquettes qui font foi, et une application FlutterFlow en fonctionnement en est la version la plus aboutie. Chaque écran existe, chaque parcours a souvent déjà été éprouvé par de vrais utilisateurs. Elle devient la référence du développement, et nous reconstruisons le code de l'application dans une architecture conçue pour durer, en reprenant le code personnalisé lorsqu'il est sain.

Cette architecture, c'est Chassis, notre framework d'architecture Flutter publié en open source. Chaque fonctionnalité y prend la même forme : un message qui la décrit, le traitement qui l'exécute, le modèle de l'écran qui l'affiche. Chaque morceau de code a donc une place évidente, et un développeur qui découvre le projet sait d'emblée où chercher.

Comment se déroule la reprise d'un projet FlutterFlow ?

La reprise suit le même principe que tout développement d'application mobile à prix fixe chez nous : tout est décidé avant le premier jour.

1. L'audit. Vous nous transmettez le code exporté de votre projet et un accès en lecture à votre projet Firebase. Nous dressons l'inventaire des écrans, des parcours, du code personnalisé, des intégrations, des données et des règles d'accès.
2. Le périmètre écrit. L'inventaire devient la liste des écrans et des fonctions à reprendre. Les améliorations que vous souhaitez sont arrêtées à ce moment-là, et dessinées si elles touchent l'interface. Le prix et la date de livraison sont fixés.
3. La reconstruction. Nous développons l'application en Flutter à partir de votre application actuelle, dans l'architecture de Chassis. Toutes les modifications de données passent désormais par des fonctions serveur, qui vérifient qui a le droit de faire quoi.
4. Firebase, conservé et renforcé. Votre projet Firebase reste le vôtre, avec les mêmes données et les mêmes comptes utilisateurs. Nous ajoutons un environnement de test séparé, nous resserrons les règles d'accès et, si la structure des données évolue, nous migrons les données existantes.
5. La mise à jour sur les stores. La nouvelle version est publiée comme une mise à jour de votre application, sous le même identifiant, depuis vos comptes développeur Apple et Google. Tant que d'anciennes versions restent installées, les règles d'accès et la structure des données continuent de les accepter, ou l'application invite à la mise à jour : la bascule se prépare dès l'audit.
6. La remise du code. Vous recevez le code source, documenté, qui vous appartient.

Pendant toute la reprise, votre application actuelle reste en ligne : nous travaillons sur l'environnement de test, et vos utilisateurs ne voient le changement qu'au moment de la mise à jour.

Combien de temps et combien coûte une reprise ?

Le prix et la durée d'une reprise dépendent de ce que l'audit met au jour ; ils sont fixés avant le premier jour de développement et ne bougent plus ensuite. Cinq éléments les font varier :

Pour repère, une application développée chez nous à partir de maquettes validées demande 2 semaines de développement, pour un prix fixe de 12 000 €. Lorsqu'une reprise dépasse ce cadre, nous la découpons en plusieurs sprints, des cycles de 2 semaines, chacun avec son prix et sa date.

Questions fréquentes

Mes utilisateurs devront-ils créer un nouveau compte ?

Non, si votre application utilise Firebase. Les comptes sont enregistrés dans votre projet Firebase, que nous conservons : la nouvelle version s'y connecte, et vos utilisateurs retrouvent leur compte et leurs données.

Pourrai-je continuer à utiliser FlutterFlow après la reprise ?

Pas sur le même code : le code reconstruit ne provient plus de l'éditeur, et les modifications faites dans FlutterFlow ne s'y reportent plus. FlutterFlow peut en revanche rester votre outil d'esquisse : vous y concevez une nouvelle fonctionnalité, vous la testez, puis elle sert de maquette au sprint suivant.

Que faut-il nous transmettre pour l'audit ?

Le code exporté de votre projet FlutterFlow, un accès en lecture à votre projet Firebase et un accès à vos comptes développeur Apple et Google. Si votre offre FlutterFlow actuelle ne permet pas d'exporter le code, l'offre Basic, facturée au mois, le permet.

Mon application restera-t-elle en ligne pendant la reprise ?

Oui. Nous développons sur un environnement de test séparé ; vos utilisateurs continuent d'utiliser la version actuelle jusqu'à la publication de la mise à jour.