Flutter ou React Native : comment choisir pour votre application en 2026
Flutter ou React Native ? Le retour d'expérience d'un développeur freelance qui a livré une application avec chacun, et le critère qui tranche vraiment.
- flutter
- react-native
- mobile

Il n'y a pas de gagnant absolu entre Flutter et React Native : les deux permettent de livrer aujourd'hui une application soignée sur iOS et Android à partir d'une seule base de code. Le critère qui tranche vraiment n'est presque jamais technique, il tient en une question : qui va écrire ce code, et surtout qui va le maintenir dans deux ans ? Une équipe qui fait déjà du React et du TypeScript pour le web ira naturellement vers React Native, tandis qu'une équipe qui part d'une page blanche, avec une interface très dessinée à rendre rigoureusement à l'identique sur les deux plateformes, sera plus à l'aise avec Flutter.
Je ne compare pas ici deux fiches techniques trouvées en ligne. Je développe et je maintiens une application en Flutter et une autre en React Native, toutes les deux publiées sur les stores. Ce qui suit vient de là : de ce que j'ai constaté en écrivant le code, en publiant les mises à jour et en corrigeant les bugs remontés par de vrais utilisateurs.
Avant tout : êtes-vous sûr d'avoir besoin d'une application ?
Une bonne partie des projets qui m'arrivent avec la question « Flutter ou React Native ? » n'ont en réalité besoin ni de l'un ni de l'autre. Un site web bien fait, rapide et installable sur l'écran d'accueil couvre beaucoup de besoins, sans passer par la validation des stores ni par deux systèmes d'exploitation à suivre en parallèle. J'ai consacré un article entier à ce préalable, et je vous conseille de le lire avant de choisir une techno : application mobile ou site web.
Si la réponse reste « une application », parce qu'il vous faut des notifications, un fonctionnement sans réseau, des capteurs ou une présence sur les stores, alors la question du framework se pose pour de bon.
Ce que fait chacun, concrètement
Flutter
Flutter s'écrit en Dart et dessine lui-même son interface, avec son propre moteur graphique (Impeller, autrefois Skia). Autrement dit, il ne demande pas à iOS ou à Android de fabriquer un bouton : il peint le bouton pixel par pixel. La conséquence est directe, et c'est souvent la raison pour laquelle on le choisit : ce que vous voyez sur un iPhone est ce que vous voyez sur un Android, à l'identique, animations comprises. Flutter fournit un catalogue de widgets complet, dans le style Material comme dans le style Cupertino, et son écosystème de bibliothèques passe par pub.dev.
React Native
React Native s'écrit en JavaScript ou en TypeScript, avec React, et s'appuie sur les composants natifs de la plateforme : un champ de saisie est un vrai champ de saisie du système, avec ses comportements, son clavier et ses réflexes d'accessibilité. La nouvelle architecture (Fabric pour le rendu, TurboModules et JSI pour le pont avec le natif) est désormais la voie par défaut, et la différence se sent sur les interactions un peu exigeantes. Surtout, Expo simplifie considérablement la vie : le démarrage d'un projet, la génération des builds et la diffusion des mises à jour deviennent des opérations de routine plutôt que des chantiers. Et l'écosystème npm est le même que celui du web.
| Critère | Flutter | React Native |
|---|---|---|
| Langage | Dart | JavaScript / TypeScript |
| Rendu de l'interface | moteur graphique intégré | composants natifs de la plateforme |
| Cohérence visuelle iOS / Android | identique par défaut | proche des habitudes de chaque OS |
| Écosystème | pub.dev | npm, partagé avec le web |
| Partage avec un site web | logique métier surtout | logique, types et parfois composants |
| Mise en route | outillage officiel intégré | Expo, très rapide à démarrer |
| Profil de développeur | plutôt mobile | du web au mobile |
Le critère qui tranche vraiment : l'équipe et le code déjà en place
Sur le papier, les deux savent tout faire. En pratique, ce qui fait la différence sur la durée, c'est le nombre d'allers-retours mentaux que votre équipe devra faire.
Si votre produit web est en React, vos développeurs connaissent déjà les composants, les hooks, la gestion d'état, TypeScript et la moitié des bibliothèques qu'ils vont utiliser. Ils réutilisent leurs réflexes, souvent leur logique métier, parfois leurs types et leurs appels d'API tels quels. Le coût d'entrée est faible et, ce qui compte davantage, la personne qui corrigera un bug dans un an sera à l'aise dans les deux dépôts.
Si vous partez de zéro, sans dette React, la question ne se pose pas dans les mêmes termes. Dart s'apprend vite, sa documentation est de très bonne qualité, et vous n'héritez pas des habitudes du web quand elles ne s'appliquent pas au mobile. Si en plus votre interface est très dessinée, avec une direction artistique forte à respecter au pixel près sur les deux plateformes, Flutter vous évitera une longue série de petits ajustements par système.
Deux applications, deux choix opposés
Govo, en Flutter
Govo est une application de gestion des heures de conduite pour auto-école, disponible sur le Play Store et l'App Store : suivi des disponibilités des élèves et des moniteurs, planification des leçons. Je l'ai écrite en Flutter, avec GetX pour l'état, Firebase pour les notifications, et une API NestJS/Node côté serveur.
Le contexte le justifiait. Il n'y avait pas d'application web React à réutiliser, l'interface est dense — des plannings, des créneaux, beaucoup d'écrans de saisie — et il fallait qu'elle se comporte exactement pareil sur le téléphone du moniteur et sur celui de l'élève, sans rattraper sans cesse les écarts entre plateformes. Flutter a été un choix de confort de fabrication, pas un choix idéologique.
En Plein Air, en React Native avec Expo
En Plein Air est une application de randonnée disponible sur l'App Store : guidage sur le tracé avec alerte quand on sort du sentier, repérage des bivouacs, météo Météo-France corrigée de l'altitude, et un fonctionnement complet sans réseau, ce qui est la moindre des choses en montagne. Elle est écrite en React Native avec Expo, et son site catalogue est en Next.js.
Ici, le partage de langage a pesé lourd dans la décision. L'application et le site parlent le même TypeScript, manipulent les mêmes structures de données pour les itinéraires, et je passe de l'un à l'autre sans changer de tête. Expo a fait le reste : mettre en route le projet, produire les builds et diffuser les mises à jour n'a jamais été le sujet difficile — le sujet difficile, c'était le hors-ligne et la précision du guidage.
Ces deux projets, que vous retrouverez avec les autres sur ma page projets, illustrent le même principe : le choix a suivi le contexte, jamais une préférence de principe.
Les questions qu'on se pose trop tard
Qui reprendra le projet ? C'est la question la plus importante et la moins posée. Si votre prestataire s'arrête, si votre développeur part, qui reprend ? On trouve généralement plus facilement des profils React que des profils Dart, simplement parce que le web en produit beaucoup, mais un bon développeur mobile apprend Flutter sans difficulté. Ce qui compte, c'est votre capacité à recruter dans votre bassin, pas une moyenne mondiale.
L'accès aux fonctions natives et aux SDK tiers. Les deux savent parler au natif, et pour les besoins courants — caméra, position, notifications, paiement, biométrie — il existe des bibliothèques matures des deux côtés. La vraie question porte sur les SDK spécifiques que votre métier impose : un lecteur de badge, une brique bancaire, un objet connecté. Vérifiez avant de choisir si le SDK propose un module officiel pour l'un ou pour l'autre : c'est souvent ce point très concret qui décide à votre place.
Le poids de l'application. Flutter embarque son moteur de rendu, ce qui donne un plancher un peu plus haut ; React Native s'appuie davantage sur ce que la plateforme fournit déjà. Sur une application réelle, la différence se resserre vite face au poids des images, des polices et des cartes embarquées. À surveiller, sans en faire un critère de choix à lui seul.
Les mises à jour d'iOS et d'Android. Chaque automne apporte son lot d'ajustements. Flutter dessine son interface, donc une nouveauté visuelle du système ne casse rien mais n'arrive pas non plus toute seule : il faut attendre qu'elle soit portée. React Native suit le natif de plus près, ce qui joue dans les deux sens — vous héritez plus vite des évolutions, et vous héritez aussi de leurs surprises. Dans les deux cas, prévoyez un budget de maintenance annuel : une application mobile qu'on ne touche pas pendant deux ans devient une application qu'on réécrit.
La grille de décision
Choisissez Flutter si vous partez de zéro sans base de code React, si votre interface est très dessinée et doit être rigoureusement identique sur iOS et Android, si votre application est riche en écrans et en animations sur mesure, ou si votre équipe mobile est déjà à l'aise avec Dart.
Choisissez React Native (avec Expo) si vous avez déjà du React ou du TypeScript en production, si un site web et l'application doivent partager de la logique et évoluer ensemble, si vous voulez recruter dans le vivier web, ou si vous cherchez le chemin le plus court entre la première ligne de code et une version testable par vos utilisateurs.
La question ne se pose même pas si vous ne visez qu'une seule plateforme avec des besoins natifs très pointus — traitement audio ou vidéo temps réel, usage intensif des capteurs, intégration profonde au système : partez directement en natif, Swift ou Kotlin. Et si votre besoin tient dans un navigateur, restez sur le web : c'est moins cher à faire vivre et vous publiez quand vous voulez.
En résumé
Flutter et React Native sont deux bons outils. Le mauvais choix n'est pas de prendre l'un plutôt que l'autre, c'est de prendre celui que personne autour de vous ne saura maintenir. Partez de votre équipe, de votre code existant, de vos contraintes de recrutement et des SDK que votre métier vous impose : la réponse tombe presque toujours d'elle-même.
Si vous préparez ce projet, prenez le temps de cadrer le besoin avant la techno — j'ai résumé ce qu'il faut réunir dans mon guide pour rédiger un brief à un développeur freelance. Et si vous voulez qu'on regarde votre cas précis plutôt qu'un tableau comparatif, écrivez-moi : je vous dirai franchement lequel des deux je choisirais, ou si je vous déconseille l'application.

