La question est posée comme une question technique. Elle se tranche presque toujours sur trois éléments qui n’ont rien de technique : votre budget, la taille de votre équipe et la durée pendant laquelle l’application devra vivre.
Ce que coûte réellement le natif
Développer en natif signifie deux bases de code, deux compétences, deux cycles de test et deux corrections pour chaque bug. Le surcoût observé se situe entre 60 et 90 % par rapport à une base multiplateforme, et il ne disparaît pas après la livraison : il se répète à chaque évolution.
Quand le natif se justifie vraiment
Il se justifie quand l’application dépend fortement du matériel ou des performances graphiques : traitement vidéo en temps réel, réalité augmentée, capteurs peu courants, ou lorsqu’une équipe interne maîtrise déjà une plateforme et va reprendre la maintenance.
Ce que React Native et Flutter font bien
Formulaires, listes, cartes, notifications, mode hors-ligne, appareil photo, paiement : ces besoins, qui représentent l’écrasante majorité des applications d’entreprise, sont couverts sans écrire une ligne de code natif. Et quand une exception apparaît, un module natif se greffe sur la base commune.
Choisir le natif « au cas où » revient à payer deux fois une option qu’on n’utilisera pas.
Le critère que l’on oublie
Qui maintiendra l’application dans deux ans ? Si la réponse est « une petite équipe » ou « nous ne savons pas encore », le multiplateforme réduit le risque, parce qu’il divise par deux la surface à maintenir.
Notre recommandation par défaut
Commencer en multiplateforme, mesurer, et ne passer au natif que sur la partie précise qui l’exige. Nous n’avons encore jamais eu à réécrire une application entière pour cette raison.