React Native ou développement natif ?

01

Comprendre ce que les deux approches changent

React Native permet de construire une application mobile avec React, en JavaScript ou TypeScript, et des composants qui s’appuient sur les plateformes natives. Dans cet article, le développement natif désigne une réalisation propre à iOS et une autre propre à Android, avec leurs outils respectifs. Le serveur, les règles métier exposées par API et le travail de conception peuvent rester communs dans les deux approches.

Côté Apple, SwiftUI permet de créer des interfaces en Swift et peut cohabiter avec UIKit. Côté Android, Jetpack Compose est un outil de création d’interfaces natives avec des API Kotlin. Ces exemples aident à situer les écosystèmes ; ils ne résument pas toutes les architectures possibles ni les bases de code déjà en place.

02

Partir des usages et des appareils à couvrir

Commencez par décrire une action complète : réserver une prestation, envoyer une demande, consulter un dossier ou enregistrer une intervention sans réseau. Précisez les utilisateurs, les informations nécessaires et le résultat attendu. Une liste d’écrans ne permet pas encore de comprendre les contraintes de l’application.

Déterminez ensuite les appareils réellement concernés. Une équipe équipée uniquement d’iPhone et un service destiné au grand public sur iOS et Android ne posent pas la même question de mutualisation. Indiquez aussi les versions de système à prendre en charge, les conditions de connexion, les exigences d’accessibilité et les fonctions propres au téléphone. Ces éléments donnent un périmètre comparable aux équipes consultées.

03

Quand React Native est une piste pertinente

React Native mérite une évaluation lorsque le produit doit évoluer sur iOS et Android avec des parcours proches : comptes, consultation de contenus, formulaires, réservations ou suivi de demandes, par exemple. Une base partagée peut faciliter la coordination des évolutions communes, à condition que les intégrations nécessaires soient maîtrisées et que l’équipe sache entretenir cette base.

Le partage ne signifie pas que tout le code doit être identique. La documentation React Native prévoit explicitement des variantes selon la plateforme, notamment avec le module Platform et des fichiers propres à iOS ou Android. Il faut donc identifier les différences utiles dès la conception plutôt que viser un taux de partage théorique.

Demandez une démonstration des parcours importants sur les deux systèmes. Examinez les formulaires, le clavier, la navigation, les autorisations et les états d’erreur. L’intérêt de la mutualisation doit se juger sur le travail réellement partagé et sur la qualité obtenue pour les utilisateurs.

04

Quand approfondir l’option native

Accordez une attention particulière au natif lorsque la valeur du produit dépend d’un SDK fourni uniquement pour une plateforme, d’un traitement matériel exigeant ou de parcours très différents entre iOS et Android. Ce sont des sujets à instruire avec un prototype et la documentation du fournisseur, sans conclure à partir du seul nom d’une fonctionnalité.

React Native permet aussi de relier du code natif à l’application au moyen de modules et de composants natifs. Une fonction particulière n’exclut donc pas automatiquement cette approche. Il faut vérifier la solution disponible, sa compatibilité et la responsabilité de son entretien.

Comparez deux réalisations du point critique si l’incertitude le justifie : une intégration dans une application partagée et une réalisation directement dans l’environnement natif. Évaluez ce qui fonctionne, les limites constatées et l’effort de suivi. Une application déjà stable et maintenable mérite également un examen avant toute décision de réécriture.

05

Mesurer les performances sur des parcours réels

La documentation React Native recommande de tester les performances avec une version de production, car le mode développement ajoute du travail à l’exécution. Une comparaison utile doit donc employer des versions représentatives de celles qui seront distribuées, avec un protocole identique.

Définissez ce que vous voulez mesurer : temps avant un écran utilisable, fluidité d’une liste, réponse après une action, consommation mémoire ou comportement pendant une session prolongée. Testez sur des appareils représentatifs du public, y compris les moins puissants que vous souhaitez prendre en charge, avec des données et des conditions réseau réalistes.

Cherchez ensuite l’origine du problème observé : écran trop chargé, images, échanges avec le serveur, traitement local ou intégration particulière. Une lenteur d’API ne se résout pas par un changement de technologie mobile. Les optimisations nécessaires doivent être identifiées avant d’attribuer l’écart à React Native ou au natif.

06

Comparer le budget et la maintenance sur la durée

Une base de code partagée ne permet pas de diviser mécaniquement un budget par deux. Le cadrage, le design, le serveur, les intégrations, les tests et la publication restent à organiser. À l’inverse, deux applications natives peuvent partager des contrats d’API, des règles de conception et une partie des outils de suivi. Comparez le travail réel, avec les mêmes livrables et les mêmes critères de qualité.

Pour chaque option, faites préciser les dépendances utilisées, le suivi des nouvelles versions de système, le traitement des incidents et la responsabilité des publications. Une équipe familière de React pour le web doit encore démontrer ses compétences mobiles. Une équipe native doit expliquer comment elle coordonne les évolutions entre les plateformes.

Le budget doit aussi rendre visible ce qui se passe après la première version : nouveaux parcours, adaptations techniques, changements de services externes et transmission à une autre équipe. Prévoyez l’accès au code, aux comptes de publication, aux environnements et à la documentation. Ces conditions comptent autant que le choix initial pour garder la maîtrise du produit.

07

Décider avec six critères et des preuves

Pour chaque critère, indiquez le besoin, la preuve disponible et l’incertitude restante. Un point essentiel non validé doit déclencher un test, même si les autres critères semblent favorables. Il est plus utile de comprendre une contrainte bloquante que d’additionner des notes donnant une impression de précision.

Les deux situations ci-dessous sont fictives et servent uniquement à illustrer la démarche. Elles ne décrivent pas des résultats clients et ne permettent pas de déduire le choix technique d’un autre projet.

08

Valider le point critique avant d’engager la réalisation

Un prototype technique doit lever une incertitude précise : fonctionnement d’un SDK, synchronisation après une coupure, traitement d’une vidéo ou comportement sur un appareil cible. Une maquette cliquable aide à tester les parcours, mais ne prouve pas que ces contraintes techniques sont résolues.

À la fin de cette étape, conservez les résultats des essais, les limites et les décisions. La recommandation doit expliquer pourquoi l’option retenue convient au périmètre, quelles compétences elle demande et ce qui pourrait conduire à la réévaluer. Vous pouvez alors engager une première version avec des critères de validation partagés, puis ajuster la suite à partir des usages observés.