Flutter ou FlutterFlow en 2026 : quand choisir quoi ?

Flutter ou FlutterFlow en 2026 : quand choisir quoi ?

Choisir entre écrire du Flutter et construire dans FlutterFlow, c'est surtout choisir qui pourra modifier le produit dans deux ans, et à quel prix.

Réponse courte. D'après la documentation et la page de tarifs lues le 7 novembre 2026, FlutterFlow est un outil visuel qui génère un projet Flutter ; ce n'est pas un concurrent de Flutter mais une autre façon de le produire. Le téléchargement du code figure dans les offres payantes (de 29 à 113 dollars par mois en facturation annuelle selon l'offre, hors sièges supplémentaires). La question utile est de savoir qui modifiera le projet ensuite : l'outil convient tant que l'on reste dans ce qu'il propose, et le code convient quand le produit doit durer et sortir du cadre. Pour le hors ligne complexe et le paiement Mobile Money, nous n'avons trouvé dans la documentation de FlutterFlow ni fonction native ni exemple : cela passe par du code personnalisé et des appels d'API, et reste à valider sur votre cas.

Transparence. BOVO Digital est une agence basée à Abomey-Calavi (Bénin) qui développe des applications en code Flutter : nous avons un intérêt dans ce sujet. Cet article ne repose sur aucun projet, aucun client, aucun prix et aucun résultat de BOVO. Il lit la documentation de FlutterFlow, la documentation de Flutter et la page de tarifs de FlutterFlow, le 7 novembre 2026. Nous n'avons construit aucune application avec FlutterFlow pour cet article et nous n'avons mesuré ni vitesse de développement, ni performance, ni coût réel de maintenance.

Ce que chacun est, d'après sa propre documentation

Flutter. La documentation de Flutter (affichée pour Flutter 3.47, page mise à jour le 28 octobre 2026) présente le framework comme un moyen de construire des applications multiplateformes à partir d'une seule base de code. Le dépôt flutter/flutter est sous licence BSD-3-Clause d'après l'API GitHub (consultée le 7 novembre 2026), et son dernier push date du même jour. Vous écrivez du Dart, vous choisissez vos paquets et votre architecture, vous versionnez et vous publiez vous-même. Il n'y a pas d'abonnement à l'outil.

FlutterFlow. La page de tarifs (lue le 7 novembre 2026) indique que « FlutterFlow's visual builder is now FlutterFlow Studio » : l'ancien éditeur visuel a changé de nom, et la documentation parle de FlutterFlow Studio. Le produit propose un éditeur visuel, des modèles, une logique d'actions assemblée visuellement, des intégrations (Firebase et Supabase sont listés) et un déploiement. D'après la page des réglages de projet, le projet généré tourne par défaut sur Android, iOS et le web ; les cibles macOS et Windows sont en alpha et l'assistance déclare ne pas pouvoir les prendre en charge.

Le point à retenir : FlutterFlow génère du Flutter. Le choix n'est donc pas « Flutter contre autre chose », mais « qui écrit et modifie le code Flutter, un outil ou des développeurs ».

Ce que coûte FlutterFlow, d'après la page de tarifs

Les prix suivants sont lus sur la page de tarifs officielle, le 7 novembre 2026. Les tarifs sont susceptibles de changer et sont en dollars américains.

La page ajoute qu'un deuxième siège coûte 55 $ par mois (41,25 $ en annuel) sur Pro, et que les sièges 2 à 5 coûtent 85 $ par mois (63,75 $ en annuel) sur Max. Il existe aussi une offre Enterprise sur devis. Une partie de la consommation (l'IA) est partagée entre les membres de l'équipe : nous ne détaillons pas cette partie, qui n'est pas l'objet de l'article.

Dans le tableau de fonctions de la même page, ce qui compte pour une décision :

• Téléchargement du code (« Download project source code ») : non inclus en Free, inclus en Basic, Pro et Max.
• Paquets tiers pub.dev et dépôts GitHub : non inclus en Free, inclus à partir de Basic.
• Intégration de paiement (« Stripe and other payment providers ») : non inclus en Free, inclus à partir de Basic.
• Déploiement en un clic sur les stores : non inclus en Free, inclus à partir de Basic.
• Poussée du code vers GitHub et extension VS Code : Pro et Max seulement.
• Collaboration en temps réel : Pro et Max seulement.
• Branches : branche principale seule en Free et Basic, jusqu'à 2 branches de plus en Pro, jusqu'à 5 de plus en Max.

Ces tarifs sont un abonnement par éditeur et par mois, tant que le projet vit dans l'outil. Ils ne disent rien du coût d'un développeur ou d'une agence, et nous n'en donnons pas ici.

Ce que l'outil permet, d'après sa documentation

• Appels d'API. La page des appels REST décrit les méthodes GET, POST, PUT, PATCH et DELETE, des en-têtes personnalisés, plusieurs formats de corps et la lecture de la réponse par chemins JSON. Les « appels privés », recommandés pour les secrets, sont déployés comme des Cloud Functions et demandent que Firebase soit connecté.
• Code personnalisé. La page sur le code personnalisé décrit des fonctions, des actions et des widgets personnalisés en Dart, et l'ajout de paquets pub.dev. Elle signale des limites : les fonctions personnalisées n'acceptent pas d'imports personnalisés, les widgets personnalisés ne peuvent pas retourner de valeur, et le changement vers la nouvelle disposition du code personnalisé est irréversible pour un projet.
• Paiement. La page Stripe décrit des paiements par carte, Apple Pay et Google Pay. Elle exige un compte Stripe, la configuration de Firebase et le passage du projet Firebase à l'offre Blaze, car la transaction est traitée par des Cloud Functions. Mobile Money n'y figure pas. Le menu de la documentation liste aussi des pages Braintree, Razorpay et RevenueCat que nous n'avons pas lues.
• Hébergement web. D'après la page de publication web, FlutterFlow héberge les applications web publiées, sur un sous-domaine flutterflow.app ou un domaine personnalisé (un domaine gratuit dans les offres payantes). Nous n'y avons pas trouvé d'option d'auto-hébergement décrite.
• Hors ligne. La page SQLite décrit une base SQLite locale, chargée depuis un fichier fourni, avec des requêtes de lecture et de mise à jour. Elle précise que SQLite n'est pas pris en charge sur le web, et ne traite ni migrations ni synchronisation avec un serveur.
• Collaboration. Le tableau de tarifs donne le nombre d'éditeurs et la collaboration en temps réel (voir plus haut). La page sur les branches (mise à jour affichée : 26 octobre 2026) décrit des branches internes à l'outil, des commits, et des conflits de fusion que l'on résout en choisissant des changements ou en éditant le YAML à la main.

Un point d'attention : certaines pages de documentation (collaboration, branches) citent encore des noms d'offres (Growth, Business) qui ne figurent plus sur la page de tarifs lue le même jour. Fiez-vous à la page de tarifs pour le prix, et vérifiez dans l'outil ce que votre offre inclut.

Le coût caché de l'export du code

Récupérer le code est possible sur les offres payantes. La question qui compte est ce que l'on fait ensuite, et la documentation donne trois indications.

1. Le code exporté est organisé et reste lié à l'outil. La page sur la structure du projet décrit des dossiers par page, un dossier custom_code/ pour le code écrit par le développeur et un dossier flutter_flow/ dont elle dit : « This directory is generated by FlutterFlow Studio ». Elle ne dit pas si ces fichiers peuvent être modifiés à la main ni comment maintenir ce code hors de l'outil.
2. Le flux est à sens unique. La page de poussée vers GitHub précise que FlutterFlow pousse toujours vers une branche nommée flutterflow, qu'il ne faut pas la modifier directement (les changements « will be overwritten by the next push from FlutterFlow Studio »), et recommande une branche develop séparée où fusionner par pull request. De même, la page d'export par CLI (mise à jour : 26 octobre 2026) avertit qu'un nouvel export peut écraser des fichiers et propose un fichier .flutterflowignore pour protéger des fichiers comme android/app/build.gradle ou ios/Runner/Info.plist. Elle ne dit pas si du code exporté puis modifié peut être réimporté dans l'outil.
3. L'assistance ne couvre pas le code personnalisé. La politique d'assistance exclut « l'implémentation et le dépannage des widgets personnalisés et du code ».

Notre lecture, qui est un raisonnement et non une mesure : deux modes de vie sont possibles pour un projet. Soit il reste dans l'outil, et l'on paie l'abonnement tant qu'on veut le modifier visuellement ; soit on quitte l'outil, on reprend le code comme n'importe quel projet Flutter, et on perd la possibilité de continuer à le modifier visuellement sans fusionner à la main. Entre les deux, avec des modifications faites des deux côtés, il faut tenir une discipline de branches et de fusions, et c'est un coût d'équipe, pas un coût d'abonnement. La page sur la propriété des données (mise à jour : 26 octobre 2026) dit que vous possédez ce que vous construisez et que les applications sont conçues pour fonctionner indépendamment des services de FlutterFlow ; elle ne décrit pas la procédure de sortie.

Ce que nous ne savons pas sur ce point : si un projet exporté se compile sans dépendance à un service de FlutterFlow, combien de temps prend une reprise par une équipe qui ne connaît pas l'outil, et ce qui arrive à un projet dans l'outil quand l'abonnement s'arrête.

Hors ligne et Mobile Money : ce que dit chaque côté

Hors ligne. Flutter en code laisse le choix de la base et de la synchronisation. Nous avons comparé les bases dans notre article sur Drift, Isar et Hive ; la page offline-first de Flutter décrit les niveaux de support hors ligne et la synchronisation. FlutterFlow propose SQLite en lecture et mise à jour locales, pas sur le web, et sa page ne traite ni migrations ni synchronisation. Une écriture locale d'abord, avec file d'envoi et gestion des doublons, serait à concevoir en code personnalisé. Rien de ce que nous avons lu ne dit que c'est impossible, ni qu'un exemple existe.

Mobile Money. Aucun des deux côtés n'a de paiement Mobile Money natif dans les pages que nous avons lues. En code Flutter, on appelle l'API de l'agrégateur ou son SDK, ce que détaille notre article sur les SDK Mobile Money. Dans FlutterFlow, les appels REST et le code personnalisé permettent d'appeler une API ; le paiement lui-même et la confirmation côté serveur (webhook) restent à construire, et les appels privés passent par Firebase. Nous n'avons testé aucun agrégateur avec FlutterFlow.

Qui peut modifier quoi

Cette grille résume des pages lues. Elle ne dit rien de la rapidité de réalisation, et nous ne comparons pas les vitesses de développement : nous n'avons aucune mesure indépendante.

Comparatif honnête

Comment décider

1. Qui modifiera le produit dans deux ans ? Si c'est quelqu'un de l'entreprise qui ne code pas, un outil visuel a un sens. Si c'est un développeur, ou une agence, le code est plus direct.
2. Quelle est la durée de vie prévue ? Pour un produit de quelques mois à valider, l'abonnement et la limite du cadre pèsent peu. Pour un produit de plusieurs années, le coût de sortie et de reprise compte davantage.
3. Le hors ligne est-il central ? Si l'utilisateur saisit des données sans connexion et qu'elles doivent être synchronisées sans doublon, prévoyez du code personnalisé dans les deux cas, et lisez notre article sur le hors ligne avant de choisir.
4. Le paiement Mobile Money est-il au cœur du produit ? Il faut construire l'appel, la confirmation par webhook et le recoupement. L'outil visuel n'enlève pas ce travail.
5. Combien de personnes éditent ? Selon la page de tarifs, l'édition à plusieurs et la collaboration en temps réel demandent Pro ou Max. Comptez les sièges.
6. Voulez-vous partir de l'outil ? Si oui, exportez un projet d'essai avant de vous engager et faites-le relire par un développeur Flutter indépendant.

Quand chacun est le mauvais choix

FlutterFlow est le mauvais choix si :

• le produit repose sur des fonctions natives ou une logique sur mesure que le code personnalisé ne couvre pas sans contourner les limites listées par la documentation ;
• l'équipe prévoit de modifier surtout le code généré, parce que le flux à sens unique vers GitHub transforme chaque modification manuelle en travail de fusion ;
• le mode hors ligne avec synchronisation est le cœur du produit, parce que la documentation lue ne décrit ni migration ni synchronisation ;
• le produit doit être hébergé à un endroit imposé, parce que nous n'avons pas trouvé d'auto-hébergement décrit pour les applications web.

Flutter en code est le mauvais choix si :

• personne ne peut maintenir du Dart dans l'entreprise ou chez son prestataire ;
• il s'agit de tester une idée sur quelques écrans, sans exigence de durée ni de logique complexe ;
• le calendrier ne permet pas de mettre en place l'architecture, les tests et les publications que le code demande.

Ce sont des critères de décision issus de notre lecture, pas des seuils mesurés.

Ce que nous ne savons pas

• La vitesse de développement et la performance des applications générées. Nous n'avons aucune mesure indépendante et nous n'en donnons aucune.
• La qualité du code exporté : lisibilité, dette technique, effort de reprise par une équipe extérieure.
• Ce qui arrive à un projet quand l'abonnement s'arrête, et si le projet exporté fonctionne sans aucune dépendance à FlutterFlow.
• L'écart entre la documentation et les tarifs, qui utilisent des noms d'offres différents le même jour. Nous ne savons pas laquelle des pages est à jour sur les branches et la collaboration.
• Le paiement Mobile Money et le hors ligne synchronisé dans FlutterFlow. Nous avons lu la documentation, pas testé un agrégateur ni une file d'envoi.
• Les autres pages de paiement (Braintree, Razorpay, RevenueCat) : listées, non lues.
• La facturation en francs CFA. La page de tarifs affiche des dollars ; nous n'avons pas vérifié la devise facturée, les taxes ni les moyens de paiement acceptés depuis le Bénin.
• Les autres outils visuels (FlutterFlow n'est pas le seul) : non comparés ici.

Sources consultées le 7 novembre 2026

Les pages de tarifs sont susceptibles de changer.

• FlutterFlow, tarifs : flutterflow.io/pricing (page lue le 7 novembre 2026, rendue côté serveur ; prix en dollars).
• FlutterFlow, documentation : export par CLI (mise à jour affichée : 26 octobre 2026), CLI, poussée vers GitHub, code personnalisé, structure du projet, propriété des données (26 octobre 2026), réglages du projet, publication web, paiement Stripe, appels REST, SQLite, collaboration, branches (26 octobre 2026), politique d'assistance.
• Flutter : docs.flutter.dev (Flutter 3.47, mise à jour affichée : 28 octobre 2026), Offline-first ; licence et activité du dépôt lues via l'API GitHub de flutter/flutter.

Pour aller plus loin

Pour le budget d'un projet Flutter, voir le prix d'une application Flutter et comment créer une application mobile. Pour comparer Flutter à une autre technologie, Flutter ou React Native, et pour juger un prestataire, comment choisir une agence de développement mobile. Sur le hors ligne et le paiement, Drift, Isar ou Hive et les SDK Mobile Money.

Un projet d'application mobile à cadrer, en code ou avec un outil visuel ? Découvrez notre agence Flutter.