Ce qu’est vraiment le choix
Une application native est écrite dans le langage et les outils propres à chaque plateforme : Swift pour iOS, Kotlin pour Android. Deux plateformes, c’est deux bases de code, habituellement construites par deux groupes de spécialistes. React Native permet à une équipe d’écrire une seule application en JavaScript ou en TypeScript avec React; il se décrit lui-même comme « écrit en JavaScript, rendu avec du code natif », avec des composants qui correspondent aux éléments natifs de chaque plateforme [1]. Les écrans sont de vrais écrans natifs, pas une page web dans un emballage.
Ce n’est pas un choix marginal. Le site de React Native cite parmi les applications construites avec lui celles de Meta, de Microsoft (dont Office, Outlook et Teams), de Shopify et de Discord [1]. Flutter est l’autre option multiplateforme courante, avec des compromis semblables et sa propre approche de rendu; l’essentiel de ce qui suit s’y applique aussi.
Quand React Native est le meilleur choix
- Les applications d’affaires faites de formulaires, de listes, de tableaux de bord, de réservations, de paiements, de messages et d’avis. C’est la plupart des applications.
- Les produits qui ont aussi une application web. Les compétences React, et une partie du code comme les modèles de données et la validation, sont partagées avec le web.
- Les équipes qui veulent une seule base de code à entretenir, un seul ensemble de tests, et des fonctions qui arrivent sur les deux plateformes en même temps.
- Les projets où arriver dans les deux magasins avec un seul budget compte plus que d’aller chercher le dernier raffinement propre à chaque plateforme.
Quand une application React Native a besoin de quelque chose que le cadre ne fournit pas, comme un appareil Bluetooth particulier ou un widget propre à une plateforme, un module natif est écrit pour cette partie en Swift ou en Kotlin. Le reste de l’application reste partagé.
Nous commençons habituellement les projets React Native avec Expo, une boîte à outils open source autour de React Native qui gère les compilations, les soumissions aux magasins et les mises à jour, et nous n’ajoutons des modules natifs que là où une fonction en a besoin. Le projet reste ainsi près du chemin standard, ce qui facilite les mises à niveau et la reprise du code par une autre équipe.
Quand le natif vaut le travail supplémentaire
- Les graphismes lourds, le traitement de la caméra ou de l’audio en temps réel, la réalité augmentée et les jeux, où chaque image compte.
- L’intégration profonde à la plateforme : widgets, applications de montre, écrans de voiture, traitement en arrière-plan aux limites strictes, ou nouvelles fonctions de la plateforme le jour de leur sortie.
- Les applications qui n’auront jamais besoin que d’une plateforme, comme une application iPad interne pour une équipe qui n’utilise que des iPad.
- Les organisations qui ont déjà de solides équipes iOS et Android et le budget pour les occuper toutes les deux.
Côte à côte
| React Native | Natif (Swift et Kotlin) | |
|---|---|---|
| Bases de code | Une seule, avec de petits modules natifs au besoin | Deux, une par plateforme |
| Apparence et comportement | Composants natifs; très proche du natif pour une application d’affaires | Exactement natif, avec chaque détail de la plateforme |
| Performance | Bonne pour une application typique; les graphismes lourds demandent du soin ou des modules natifs | La meilleure possible, avec accès direct à chaque API de la plateforme |
| Nouvelles fonctions de la plateforme | Habituellement offertes après un délai, ou par un module natif | Offertes le jour de la sortie |
| Partage avec une application web | Les compétences, et une partie du code comme la validation et les types de données | Peu ou rien |
| Équipe | Des développeurs React et TypeScript, avec quelques connaissances natives | Des spécialistes iOS et Android |
| Entretien | Un seul ensemble de fonctions et de tests; des mises à niveau du cadre à prévoir | Deux ensembles de fonctions et de tests à garder en phase |
Ce que les magasins exigent dans tous les cas
Les magasins se moquent de la façon dont une application est construite, mais ils fixent des règles qui façonnent chaque projet mobile et son calendrier.
- La revue prend du temps. Apple indique qu’en moyenne, 90 % des soumissions sont révisées en moins de 24 heures [2], mais un refus veut dire une correction et une nouvelle revue : prévoyez une marge pour les lancements.
- Les lignes directrices d’Apple demandent qu’une application offre des fonctions, du contenu et une interface qui la placent au-delà d’un site web réemballé [3]. Une page web dans une coquille d’application risque d’être refusée.
- La ligne directrice 2.5.2 d’Apple précise qu’une application ne peut pas télécharger ni exécuter du code qui ajoute ou modifie des fonctions [3]. Les applications React Native peuvent pousser certaines mises à jour à distance, mais les nouvelles fonctions doivent passer par une version révisée.
- Google Play exige que les nouvelles applications et les mises à jour ciblent une version récente d’Android : à partir du 31 août 2026, Android 16, niveau d’API 36, pour la plupart des applications [4]. L’exigence monte avec chaque version d’Android : toute application a donc besoin de mises à niveau régulières pour continuer de publier des mises à jour.
Ce dernier point est un coût récurrent de toute application mobile, native ou non. Les mises à niveau des plateformes, les nouvelles tailles d’appareils et les changements de politique des magasins arrivent chaque année : prévoyez l’entretien au budget dès le départ.
Quand vous n’avez besoin ni de l’un ni de l’autre
Certaines applications n’ont pas besoin d’être dans un magasin. Une application web adaptative fonctionne sur tous les téléphones, peut être ajoutée à l’écran d’accueil et se met à jour dès que vous déployez, sans revue. Si vos utilisateurs viennent à l’occasion, vous trouvent par la recherche ou des liens, et n’ont besoin ni du mode hors ligne, ni de la localisation en arrière-plan, ni d’avis riches, commencez par le web.
- Ce qui convient au web : portails clients, réservations et commandes, tableaux de bord, outils internes utilisés au bureau comme en déplacement.
- Ce qui convient à une application de magasin : les produits d’usage quotidien, le travail hors ligne sur le terrain, les fonctions de caméra et de capteurs, des avis poussés fiables, et tout ce que les utilisateurs s’attendent à trouver dans un magasin.
- Un parcours courant : lancer l’application web, apprendre ce que les gens font sur leur téléphone, puis construire l’application mobile pour ces parcours.
Commencer par le web n’est pas du travail perdu. Le serveur, le volet d’administration, le modèle de données et une bonne partie du design passent directement à l’application mobile : la deuxième étape coûte donc moins cher que si vous aviez commencé par elle.
La moitié invisible d’une appli
Peu importe comment les écrans sont construits, une grande partie d’un projet mobile est le même travail en dessous, et c’est souvent la plus grosse part.
- Le serveur : la base de données et les API auxquelles l’application parle, avec la connexion, les permissions et un volet d’administration pour le personnel. Natif ou React Native, c’est commun.
- Le hors ligne et la synchronisation : si les gens utilisent l’application là où le signal est faible, elle doit conserver le travail sur le téléphone et le réconcilier plus tard sans rien perdre ni dupliquer. C’est autant un travail de conception que de code.
- Les avis poussés : des certificats et des clés pour Apple et Google, un service pour les envoyer, et des réglages pour que les utilisateurs choisissent ce qu’ils reçoivent.
- Les tests sur de vrais appareils : différentes tailles d’écran, des versions plus anciennes du système d’exploitation, des réseaux lents et des sessions interrompues. Les tests automatisés couvrent la logique; des personnes avec de vrais téléphones couvrent le reste.
- La gestion des versions : fiches des magasins, captures d’écran, déclarations de confidentialité, déploiements progressifs, rapports de plantage et un moyen de revenir en arrière.
Une soumission qui chiffre les écrans, mais pas cette moitié, va bouger. Demandez qu’elle soit détaillée.
Deux projets mobiles, chiffrés selon notre grille
Les exemples ci-dessous montrent la fourchette selon notre grille tarifaire d’aujourd’hui, avec les heures par rôle et l’échéancier de paiement. Le premier est une application iPhone seule. Le second couvre iOS et Android avec une application web et un volet d’administration. Si vous choisissez deux applications natives distinctes plutôt qu’une base de code partagée, la plus grande partie du travail mobile se fait deux fois; ouvrez l’un ou l’autre exemple dans l’estimateur et nous pourrons chiffrer cette variante avec vous.
Exemple chiffré en direct
Une application iPhone
Seize écrans sur iOS avec connexion, paiements intégrés, avis poussés et analytique, sur un design sur mesure, avec des renseignements personnels.
- Développement
- ≈ 57 200 USD à 87 400 USD, livré en 26 semaines au plus81 400 $ CA à 124 400 $ CA
Les prix dans votre devise sont des estimations au taux du jour de la Banque du Canada. Toute la facturation se fait en CAD ou en USD.
Effort estimé par rôle
- Développement
- 318 à 486 h
- Concepteur de produits
- 57 à 87 h
- Ingénieur assurance qualité
- 39 à 59 h
- Développeur dorsal principal
- 38 à 59 h
- Concepteur de produits principal
- 38 à 58 h
- Gestionnaire de projet
- 37 à 57 h
- Développeur dorsal
- 35 à 54 h
- Développeur frontal
- 32 à 49 h
- Développeur mobile
- 25 à 39 h
- Ingénieur principal
- 24 à 36 h
- Architecte logiciel
- 21 à 32 h
- Développeur mobile principal
- 20 à 30 h
- Développeur frontal principal
- 19 à 29 h
- Développeur dorsal junior
- 18 à 27 h
- Développeur frontal junior
- 13 à 19 h
- Développeur mobile junior
- 11 à 17 h
- Rédacteur technique
- 7 à 10 h
- Ingénieur DevOps
- 6 à 10 h
Modalités de paiement
- Acompte 20 %
- 16 280 $ CA à 24 880 $ CA
- Découverte 10 %
- 8 140 $ CA à 12 440 $ CA
- Maquettes approuvées 10 %
- 8 140 $ CA à 12 440 $ CA
- Première version sur appareils 30 %
- 24 420 $ CA à 37 320 $ CA
- Soumission aux boutiques 10 %
- 8 140 $ CA à 12 440 $ CA
- Mise en ligne 10 %
- 8 140 $ CA à 12 440 $ CA
- Retenue, 30 jours après la mise en ligne (10 %)
- 8 140 $ CA à 12 440 $ CA
Exemple chiffré en direct
Des applications iOS et Android avec une application web
Vingt-deux écrans sur iOS, Android et le web, avec connexion, paiements, un volet d’administration pour le personnel, des avis et de l’analytique, et un plan de soutien après le lancement.
- Développement
- ≈ 97 600 USD à 149 000 USD, livré en 25 semaines au plus139 000 $ CA à 212 600 $ CA
Les prix dans votre devise sont des estimations au taux du jour de la Banque du Canada. Toute la facturation se fait en CAD ou en USD.
Effort estimé par rôle
- Développement
- 528 à 807 h
- Concepteur de produits
- 107 à 164 h
- Concepteur de produits principal
- 71 à 109 h
- Gestionnaire de projet
- 68 à 104 h
- Développeur frontal
- 64 à 98 h
- Développeur dorsal principal
- 63 à 96 h
- Ingénieur assurance qualité
- 61 à 93 h
- Développeur dorsal
- 57 à 88 h
- Ingénieur principal
- 40 à 61 h
- Développeur frontal principal
- 38 à 59 h
- Développeur mobile
- 34 à 52 h
- Architecte logiciel
- 34 à 52 h
- Développeur dorsal junior
- 29 à 44 h
- Développeur mobile principal
- 27 à 41 h
- Développeur frontal junior
- 26 à 39 h
- Développeur mobile junior
- 15 à 23 h
- Ingénieur DevOps
- 13 à 20 h
- Rédacteur technique
- 11 à 16 h
Modalités de paiement
- Acompte 20 %
- 27 800 $ CA à 42 520 $ CA
- Découverte 9,2 %
- 12 788,00 $ CA à 19 559,20 $ CA
- Maquettes approuvées 9,2 %
- 12 788,00 $ CA à 19 559,20 $ CA
- Fonctions principales 7,6 %
- 10 564,00 $ CA à 16 157,60 $ CA
- Développement complet 5 %
- 6 950 $ CA à 10 630 $ CA
- Première version sur appareils 20,1 %
- 27 939,00 $ CA à 42 732,60 $ CA
- Tests et corrections 2,5 %
- 3 475 $ CA à 5 315 $ CA
- Soumission aux boutiques 6,7 %
- 9 313,00 $ CA à 14 244,20 $ CA
- Mise en ligne 9,7 %
- 13 483,00 $ CA à 20 622,20 $ CA
- Retenue, 30 jours après la mise en ligne (10 %)
- 13 900 $ CA à 21 260 $ CA
Après le lancement, dans tous les cas
Une application mobile n’est jamais terminée comme un site web peut l’être. Chaque année apporte de nouvelles versions du système d’exploitation, de nouveaux appareils et de nouvelles règles des magasins, et les utilisateurs s’attendent à ce que l’application suive. Prévoyez un rythme de versions, mensuel ou trimestriel, qui regroupe de petites améliorations et les mises à niveau qu’exigent les plateformes, et gardez les rapports de plantage et l’analytique actifs pour savoir quels problèmes comptent. Avec React Native, ajoutez les mises à niveau du cadre à cette liste; avec des applications natives, faites tout deux fois.
Comment décider
- 01
Listez les fonctions qui touchent l’appareil
Caméra, localisation, Bluetooth, travail en arrière-plan, widgets, données de santé. Chacune est une question de prise en charge native.
- 02
Demandez-vous si l’une doit être la meilleure de sa catégorie
Si une fonction est le produit, comme un effet de caméra en temps réel, elle peut justifier du code natif pour cette fonction ou pour toute l’application.
- 03
Vérifiez vos plateformes
Si vos utilisateurs sont à la fois sur iOS et Android, une base de code partagée est le choix par défaut. S’ils sont tous sur une seule, le natif pour celle-là est raisonnable.
- 04
Pensez au web
Si vous avez aussi besoin d’une application web, React Native partage avec elle des compétences et une partie du code.
- 05
Planifiez les années après le lancement
Qui l’entretiendra, et pouvez-vous embaucher pour cela? Des développeurs React et TypeScript sont plus faciles à trouver que deux spécialistes natifs.