Ce que React Native fait réellement
Une idée fausse circule encore : React Native produirait une application web déguisée. C'est inexact. L'interface affichée utilise les composants du système, et l'utilisateur voit des éléments natifs. Ce qui est mutualisé, c'est la logique applicative et la description des écrans.
La conséquence pratique est simple : sur des écrans classiques, listes, formulaires, navigation, détail, un utilisateur ne fait pas la différence. Et c'est précisément ce que contient la majorité des applications métier.
La question n'est donc pas de savoir si React Native est acceptable, mais où se situe la frontière au-delà de laquelle il cesse de l'être.
L'économie réelle, et ce qu'elle n'est pas
L'argument central est le coût. Une base de code, une équipe, un cycle de livraison, contre deux développements distincts.
L'économie est réelle, mais elle n'est pas de moitié. Il reste toujours une part de travail spécifique par plateforme : conventions de navigation différentes, gestion des permissions, publication sur deux magasins aux règles distinctes, comportements divergents sur certains écrans. Compter une économie de l'ordre du tiers à la moitié est réaliste ; annoncer un développement pour le prix d'un ne l'est pas.
L'économie la plus durable se situe ailleurs : dans la maintenance. Une correction est écrite une fois et bénéficie aux deux plateformes, et les deux versions ne divergent pas fonctionnellement au fil des années. C'est un gain qui se cumule chaque année, alors que l'économie initiale est ponctuelle.
Où le natif garde un avantage net
Trois domaines, et ils sont identifiables dès le cadrage.
Le rendu graphique intensif. Jeu, traitement d'image ou de vidéo en direct, réalité augmentée, animations complexes enchaînées : ces usages exploitent le matériel à un niveau où l'intermédiaire coûte trop cher.
L'intégration matérielle poussée. Bluetooth vers un appareil de mesure, capteurs spécialisés, traitements en arrière-plan de longue durée. Ces fonctions restent accessibles depuis React Native, mais au prix de modules natifs à écrire et à maintenir. Si l'essentiel de l'application repose dessus, le bénéfice de la mutualisation disparaît.
L'adoption immédiate des nouveautés. Une fonctionnalité annoncée à une conférence système est disponible en natif tout de suite, et en React Native quand un pont existe. Pour une application dont l'argument commercial est d'être à jour, ce décalage compte.
La question de la dépendance
Choisir React Native, c'est ajouter une couche entre votre code et les systèmes, et donc dépendre de sa maintenance et de celle des bibliothèques tierces qui l'accompagnent.
Le socle est solide et largement utilisé en production, y compris par de très grandes applications. Le point de vigilance n'est pas là : il est dans les bibliothèques annexes. Une application mobile en assemble facilement plusieurs dizaines, et certaines sont maintenues par une seule personne. Une bibliothèque abandonnée devient un chantier de remplacement au pire moment, généralement lors d'une montée de version majeure d'un système.
Ce risque se pilote : limiter le nombre de dépendances, vérifier leur activité avant de les intégrer, et prévoir un budget annuel de mise à niveau. Ce dernier point n'est pas propre à React Native, mais il y est plus sensible.
Le calcul sur trois ans
Comparer deux devis initiaux conduit presque toujours à la mauvaise décision, parce que la maintenance représente l'essentiel du coût d'une application mobile sur sa durée de vie.
Chaque année apporte une version majeure par système, des règles de publication qui évoluent, et des dépendances à mettre à jour. En natif, ce travail est fait deux fois. En React Native, il est fait une fois pour la logique et partiellement deux fois pour ce qui touche aux plateformes.
Sur trois ans, l'écart se creuse en faveur de la base unique dans la majorité des applications métier. Il s'inverse pour les applications à forte composante graphique ou matérielle, où le coût d'optimisation et les modules natifs annulent le bénéfice.
La question qui tranche
Vos écrans ressemblent-ils à des listes, des formulaires et des fiches, ou à autre chose ?
Si vous êtes dans le premier cas, ce qui est la situation de la plupart des applications professionnelles, React Native fera le travail, et l'argent économisé sera mieux employé à la qualité du produit qu'à la reproduction du même écran deux fois.
Si votre application est visuellement singulière ou technologiquement exigeante, le natif n'est pas un luxe, c'est la condition pour que le produit fasse ce que vous en attendez.
