Migration React Native vers Flutter : coûts

Tous les quelques mois, un CTO nous contacte avec une variante de la même question. Son équipe a une app React Native. Elle tourne depuis deux ou trois ans. Et quelque chose a changé : il leur faut de meilleures performances, ils veulent livrer sur desktop, ils ajoutent des intégrations matérielles que le bridge JS rend compliquées. La question posée est de savoir s’il faut migrer vers Flutter.

Cet article traite de cette décision. Pas de “quel framework choisir pour un nouveau projet” (c’est le sujet de notre comparaison Flutter et React Native). Voici la question plus difficile : vous avez déjà une base de code React Native, votre équipe la connaît, et vous pesez si le coût d’une migration vaut ce que vous obtiendrez de l’autre côté.

Soyons honnêtes : Unlock’d n’a jamais mené de migration complète de React Native vers Flutter comme mission client. Ce que nous avons fait, c’est évaluer la faisabilité de migrations pendant des appels de discovery, auditer des bases de code React Native pour estimer ce que coûterait une reconstruction en Flutter, et construire des apps Flutter dans des domaines où les équipes React Native atteignent souvent des plafonds. Cet article s’appuie sur cette expérience accumulée, pas sur un projet unique.

Les signes que votre app React Native atteint ses limites

React Native fonctionne bien pour beaucoup d’apps. Si la vôtre entre dans une catégorie où le framework commence à forcer, vous reconnaîtrez ces schémas.

Performances d’animation et de rendu. L’architecture à bridge de React Native fait passer les mises à jour d’interface par un runtime JavaScript. Pour la plupart des apps, cela reste invisible. Mais dès qu’il faut un contrôle à la frame près, comme des animations à 60 fps, des visualisations en temps réel ou des interfaces qui se rafraîchissent à chaque message WebSocket, le bridge devient le goulot d’étranglement. Flutter rend directement, sans runtime dans la boucle. Pour la plateforme d’enchères Lava, cela comptait : l’horloge à prix dégressif devait s’animer à 60 fps même sur du matériel Windows d’entrée de gamme, avec 100 points de prix redessinés 20 fois par seconde. C’est le type d’exigence où le modèle de rendu de Flutter offre des outils que React Native n’expose pas.

Performances sur les grandes listes. React Native a progressé ici avec la New Architecture, mais les équipes signalent encore des performances de scroll irrégulières sur des listes complexes, en particulier avec des renderers d’items personnalisés ou des vues imbriquées.

BLE et intégration matérielle. L’écosystème BLE de React Native est fragmenté. Vous assemblez souvent plusieurs packages de mainteneurs différents avec des hypothèses différentes. La librairie BLE de Flutter est plus consolidée : un package bien maintenu qui couvre tout le cycle de vie d’une connexion. Si vous ajoutez de la connectivité matérielle à votre app, ou si les intégrations matérielles sont ce qui vous a fait regarder Flutter au départ, c’est un critère réel. La companion app de Classified Cycling gère des connexions BLE avec quatre types d’appareils en extérieur. Elle a été construite en Flutter dès le départ, précisément pour cette raison.

Extension au web et au desktop. Le support web et desktop de React Native s’est amélioré, mais reste une cible secondaire. S’il vous faut une base de code unique qui tourne de façon fiable sur iOS, Android, le web et Windows desktop, le support multi-plateforme de Flutter est réellement équivalent sur ces cibles. La plateforme d’enchères Lava est livrée sur Windows desktop et sur le web depuis la même base de code Flutter, avec le même moteur de rendu et la même gestion d’état.

Friction de la migration vers la New Architecture. La New Architecture de React Native (Fabric + TurboModules) est une nette amélioration, mais migrer des apps existantes peut faire mal. Si vous avez de toute façon une mise à niveau d’infrastructure React Native majeure devant vous, certaines équipes trouvent le coût total de cette migration comparable à celui d’une réécriture Flutter, et la question devient alors avec quoi vous préférez finir.

Quand la migration N’A PAS de sens

Voici la section qu’on voit rarement dans le matériel marketing autour de Flutter. Migrer n’est pas toujours le bon choix.

Votre app fonctionne bien. Si les utilisateurs sont contents, que les crashs sont rares et qu’aucune plainte ne porte sur les performances, le dossier économique d’une migration est faible. Une migration est un gros investissement dont le résultat paraît identique aux utilisateurs. Les gains techniques doivent se traduire en résultats business réels.

Votre équipe React Native est productive et satisfaite. L’écosystème React Native est mature. Si votre équipe est rapide, confiante et ne se heurte à aucun mur, changer de framework impose une période de vélocité réduite pendant l’apprentissage de Dart et des patterns Flutter. C’est un coût réel.

Aucune extension multi-plateforme prévue. La force de Flutter se cumule quand vous livrez sur plusieurs plateformes depuis une seule base de code. Si le mobile est votre cible permanente et que vous n’avez aucun projet desktop ou web, cet avantage ne vous concerne pas.

Budget serré sans ROI clair. Les migrations coûtent de l’argent. Si vous ne pouvez pas nommer un résultat business précis qui en découle (livrer plus vite, supporter une nouvelle plateforme, réduire les crashs, permettre une intégration matérielle aujourd’hui impossible), le dossier ne tient pas. La technologie de pointe à elle seule n’est pas un argument business.

Fourchettes de coût et de délai d’une migration

Ce sont des estimations honnêtes basées sur ce que nous avons vu en mission de discovery. Ce ne sont pas des garanties. Les projets réels sont plus désordonnés.

Quelques éléments font grimper le coût plus vite que le nombre d’écrans ne le laisse penser :

Les équivalents des modules natifs. Chaque module natif React Native a besoin d’un équivalent Flutter. Certains ont un remplaçant direct. D’autres exigent des platform channels sur mesure ou, parfois, des bindings FFI vers du code natif. Inventoriez vos modules natifs tôt. C’est en général la principale source d’écart dans les estimations.

La réécriture de la gestion d’état. Les patterns Redux et MobX ne se mappent pas 1:1 sur Riverpod ou Bloc. La logique est transposable, le code non. Une grande app avec un store Redux mature demandera une refonte architecturale délibérée, pas une simple traduction.

Les différences de comportement par plateforme. Les cas limites du comportement iOS et Android que votre équipe a appris en production doivent être réappris dans un contexte Flutter. L’évitement du clavier, la gestion des safe areas, les parcours de permission par plateforme et le routage des deep links ont tous des idiomes légèrement différents.

La reconstruction de l’infrastructure de test. Vos widget tests et tests d’intégration existants ne se transfèrent pas. Vous reconstruisez la suite de tests de zéro dans le framework de test de Flutter.

Pièges courants de la migration

Les équipes qui sous-estiment une migration butent presque toujours sur le même ensemble de problèmes.

Stratégies de migration

Toutes les migrations ne suivent pas le même schéma. Il existe trois approches principales, avec des profils de risque différents.

Pour la plupart des équipes avec qui nous parlons, la réécriture complète est le choix le plus pratique sur des apps petites à moyennes. Le pattern strangler paraît séduisant parce qu’il semble moins risqué, mais faire tourner une base de code hybride RN + Flutter est réellement complexe. Vous maintenez deux systèmes de gestion d’état, deux stacks de navigation et un pont entre les deux. La charge opérationnelle s’accumule vite. Le pattern strangler a plus de sens sur de grandes apps à fort trafic, où une bascule complète est commercialement risquée.

Si vous envisagez une migration pour des besoins d’intégration matérielle, voyez notre article sur le développement d’apps BLE en Flutter pour ce que ce travail implique vraiment. Si votre app a des fonctionnalités e-commerce et que vous pesez une reconstruction face à une approche hybride, notre article sur l’intégration Flutter et Magento couvre les deux patterns.

À quoi ressemble une mission de discovery

Quand des équipes viennent nous voir avec des questions de migration, voici comment nous abordons l’évaluation.

Audit de la base de code. Nous passons en revue la base React Native existante : nombre d’écrans, complexité des composants, inventaire des modules natifs, architecture de gestion d’état, couverture de tests et configuration CI/CD. L’objectif est un inventaire factuel, pas un jugement sur la qualité.

Inventaire des modules natifs. Nous mappons chaque module natif sur son équivalent Flutter, ou le signalons comme demandant du sur-mesure. C’est l’entrée la plus importante de l’estimation de coût. Une base avec cinq modules natifs qui ont des équivalents Flutter bien maintenus n’a rien à voir avec une base dont les cinq modules réclament des implémentations sur mesure.

Scoring de complexité. Nous attribuons un niveau de complexité à chaque grand domaine : complexité d’interface, profondeur de la gestion d’état, intégrations natives, exigences offline, comportement spécifique aux plateformes. Cela donne une estimation pondérée plutôt qu’une estimation au nombre d’écrans.

Estimation de délai et de budget. Sur la base de l’audit, nous produisons une fourchette avec des intervalles de confiance honnêtes. Nous précisons quelles hypothèses portent l’estimation et ce qui la ferait déraper.

Recommandation go/no-go. Nous donnons notre avis honnête sur l’intérêt de migrer compte tenu de l’app et du contexte business précis. Si la réponse est non, nous le disons. Une évaluation juste est plus utile qu’un projet lancé pour de mauvaises raisons.

À retenir

Les décisions de migration méritent plus de rigueur que la plupart des équipes n’en mettent. Avant de vous engager, assurez-vous de pouvoir répondre à ces questions.

Pouvez-vous nommer le problème précis que la migration résout ? Les performances d’un écran donné, l’extension au desktop, une intégration matérielle que vous ne pouvez pas construire aujourd’hui, une architecture qui ralentit votre équipe. Si la réponse est vague, le ROI le sera aussi.

Avez-vous inventorié vos modules natifs ? Ce seul facteur explique l’essentiel de l’écart entre les estimations de coût de migration. Faites-le avant tout autre travail de cadrage.

Le dossier tient-il sur l’horizon de temps de la migration ? Une migration de 4 à 6 mois qui débouche sur 18 mois de livraison plus rapide se défend. Une migration de 6 mois pour une app aux releases stables et peu fréquentes est plus dure à justifier.

Avez-vous envisagé l’alternative strangler ? Sur de grandes apps, embarquer des modules Flutter progressivement peut réduire le risque commercial, même si cela augmente la complexité technique. La bonne réponse dépend de la taille de votre équipe, de la pression commerciale et de votre tolérance au risque.

Les équipes qui réussissent le mieux leurs migrations sont celles qui y sont entrées avec des données justes. Celles qui galèrent sont celles qui ont sous-estimé la complexité de leurs modules natifs et supposé que la base de code se porterait plus vite qu’elle ne l’a fait.