Flutter vs React Native: Comment Nous Choisissons (et Pourquoi Nous Avons Choisi Flutter)

On nous pose cette question dans presque chaque appel de découverte : “Pourquoi Flutter et pas React Native ?”

Parfois c’est un CTO qui fait une vraie due diligence. Parfois c’est une équipe de direction qui suppose que React Native, c’est pareil que React, et que leur équipe web peut “aussi faire du mobile.” Ce sont des conversations très différentes.

Voici ce que nous avons appris en livrant des apps Flutter en production pendant des années, et pourquoi nous n’avons jamais eu de projet où React Native aurait été le meilleur choix.

Côte à Côte

Les tableaux sont utiles, mais ils ne disent pas ce que ça fait vraiment de construire avec chaque framework. Voici ce que nous avons appris sur des projets réels.

Flutter pour les Apps Bluetooth Low Energy (BLE)

Quand Classified Cycling est venu nous voir, ils avaient déjà fait leurs recherches. Ils avaient besoin d’une app compagnon qui se connecterait à du matériel de transmission sans fil via Bluetooth Low Energy, pousserait des mises à jour firmware par voie aérienne, et gérerait plusieurs types d’appareils sur iOS et Android.

Ils ont choisi Flutter avant même notre implication, spécifiquement grâce à son écosystème BLE. Après des années de développement sur plusieurs versions majeures, l’app gère désormais les connexions à quatre types de matériel différents, s’intègre à deux écosystèmes partenaires (Shimano DI2 et TRP CMD), et gère les mises à jour firmware pour tous. Le choix a tenu bon.

La couche BLE dans Flutter gère le cycle de vie complet : scan, connexion, authentification par challenge-response sur des caractéristiques chiffrées, lecture des niveaux de batterie, push firmware via Nordic DFU, et gestion des différences de bonding entre types d’appareils. Ça fonctionne de manière fiable en conditions extérieures, là où le Bluetooth est le plus imprévisible.

Est-ce que ça aurait pu être construit en React Native ? Techniquement oui. Mais l’écosystème Flutter pour le BLE est plus consolidé. Une seule bibliothèque bien maintenue couvre l’ensemble du cycle de vie de connexion. En React Native, vous assemblez plusieurs bibliothèques avec des mainteneurs différents et des hypothèses différentes sur la gestion de l’état BLE.

Performances Flutter : 60fps sur du Matériel d’Entrée de Gamme

Pour la plateforme d’enchères Lava, nous avons construit une horloge en temps réel où le prix baisse toutes les 50 millisecondes et des centaines d’acheteurs enchérissent simultanément. Un décalage visuel de 100ms signifie qu’un acheteur enchérit au mauvais prix.

Le moteur de rendu de Flutter nous a permis de diviser l’horloge en deux couches de peinture indépendantes : le travail coûteux (redessiner 100 points de prix et étiquettes) tourne au rythme de l’horloge, tandis que le travail léger (animer l’indicateur de prix actif) tourne au taux de rafraîchissement de l’écran. Cette séparation architecturale n’est possible que parce que Flutter vous donne un contrôle direct sur le pipeline de rendu. Vous ne travaillez pas à travers un bridge et n’attendez pas qu’un runtime JavaScript traite votre frame.

Le résultat : 60fps sur le web, même sur des appareils d’entrée de gamme. Nous en avons écrit en détail dans notre auction clock deep dive.

En React Native, la New Architecture a comblé une grande partie de l’écart de performances pour les apps typiques. Mais quand vous avez besoin d’un contrôle au niveau du frame sur ce qui se redessine et quand, le modèle de rendu de Flutter vous donne des outils que l’architecture de React Native n’expose pas.

Flutter Desktop vs React Native

Le client d’enchères Lava tourne sur desktop Windows et navigateurs web depuis la même codebase Flutter. Même rendu, même gestion des connexions WebSocket, même gestion d’état. Le support desktop n’était pas une arrière-pensée ajoutée après coup. C’était une cible de premier ordre dès le premier jour.

L’assistant d’installation d’Ubuntu est construit avec Flutter. L’outillage interne de Google l’utilise pour le desktop. Quand nous disons à nos clients “Flutter tourne sur desktop,” nous ne parlons pas d’une fonctionnalité expérimentale. C’est de l’infrastructure de production.

L’histoire desktop de React Native s’améliore grâce aux contributions de Microsoft, mais c’est encore un effort séparé avec ses propres contraintes. Si le support multiplateforme est une exigence fondamentale (pas un bonus), Flutter est le choix le plus sûr aujourd’hui.

Apps Hybrides Flutter : Envelopper l’Infrastructure Web Existante

Toutes les apps ne partent pas de zéro. Hubo, un détaillant belge de bricolage avec plus de 160 magasins, avait déjà un site e-commerce complet. Construire une app native qui dupliquait toute cette fonctionnalité aurait été du gaspillage. À la place, nous avons construit un shell Flutter qui enveloppe leur plateforme web existante dans une app native, avec des fonctionnalités sélectionnées implémentées nativement : notifications push, carte de fidélité, localisateur de magasins.

Flutter et React Native supportent tous deux les web views intégrées. Mais l’avantage de Flutter ici, c’est le contrôle. Le shell natif gère le cycle de vie de l’app, le deep linking et les fonctionnalités spécifiques à la plateforme, tandis que les web views gèrent la navigation produit et le paiement. La frontière entre natif et web est invisible pour l’utilisateur.

Ce pattern hybride est courant pour les entreprises qui ont déjà une infrastructure web et veulent une présence mobile sans tout reconstruire. Flutter fait que les parties natives se sentent natives tout en exploitant ce qui existe déjà.

Votre Équipe React Peut-Elle Créer une App React Native ?

Nous n’avons jamais eu de projet où nous avons recommandé React Native plutôt que Flutter. Mais nous avons eu des conversations où la direction supposait que React Native était le choix évident parce que “nous avons déjà une équipe web React.”

React Native et React partagent le modèle de composants et la syntaxe JSX. Mais le développement mobile est une discipline différente. Connexions BLE, notifications push, traitement en arrière-plan, déploiement sur les stores, permissions spécifiques aux plateformes, stockage hors ligne. Un développeur web React ne sera pas productif sur ces problèmes juste parce que la syntaxe lui semble familière.

La courbe d’apprentissage pour Dart est réelle mais courte. La plupart des développeurs sont à l’aise en une semaine. Et ce qu’ils gagnent, c’est un framework où mobile, desktop et web sont de vrais citoyens égaux, pas des ajouts greffés sur une architecture mobile-first.

Depuis Nos Projets

Ces chiffres proviennent d’apps Flutter en production que nous construisons et maintenons.

Migrer de React Native vers Flutter

Si vous avez une app React Native existante et que vous atteignez des plafonds de performance, que vous luttez avec des incohérences entre plateformes, ou que vous cherchez à vous étendre au desktop et au web, migrer vers Flutter mérite d’être envisagé. Nous aidons les équipes à évaluer si une migration a du sens et à planifier la transition sans perturber ce qui fonctionne déjà.

Une migration n’est pas toujours le bon choix. Mais quand les exigences de votre app ont dépassé ce que React Native gère bien, Flutter vous donne de la marge pour évoluer.

Quand Nous Recommandons Flutter

• Les performances comptent (UIs temps réel, animations, intégration matérielle)
• Vous avez besoin d’une cohérence pixel-perfect entre les plateformes
• Vous construisez pour plus que le mobile (web, desktop, embarqué)
• Le Bluetooth ou l’IoT est impliqué
• Vous partez de zéro sans codebase mobile existante

Notre Avis

Le pire choix, c’est de choisir un framework sur la base du battage médiatique plutôt que de vos besoins réels. Nous avons choisi Flutter parce que nos projets impliquent du rendu personnalisé, de la connectivité matérielle et une portée multiplateforme au-delà d’iOS et Android. Pour ces cas d’usage, Flutter nous donne un avantage que nous n’échangerions pas. Découvrez comment nous travaillons sur notre page services de développement Flutter.