Dès qu'un projet d'application mobile démarre, une question revient avant même la première maquette : faut-il la construire en natif, en cross-platform, ou en faire une PWA ? La réponse engage le budget, les délais, les performances et la capacité à faire évoluer l'outil pendant des années. C'est une décision d'architecture, pas une question de goût.
Le piège classique est de choisir l'approche à la mode, ou celle que l'on maîtrise déjà, puis d'habiller ce choix de bonnes raisons. La bonne démarche est inverse : partir des usages réels de l'application, des contraintes de performance et du public visé, puis laisser ces éléments désigner l'approche la plus adaptée. Voici comment raisonner, approche par approche, puis les critères qui tranchent vraiment.
Trois familles, trois logiques
Il existe trois grandes manières de livrer une application sur téléphone. Le natif consiste à écrire une application dédiée à chaque système, avec les outils du système : une base pour iOS, une autre pour Android. Le cross-platform mutualise une seule base de code qui produit les deux applications, via un cadre comme React Native ou Flutter. La PWA, enfin, est un site web conçu pour se comporter comme une application : il s'installe sur l'écran d'accueil et fonctionne même hors connexion, sans passer par les magasins d'applications.
Aucune de ces familles n'est supérieure dans l'absolu. Chacune fait un compromis différent entre performance, coût, portée et accès aux fonctions du téléphone. Comprendre ces compromis est la seule façon de choisir en connaissance de cause, plutôt que de subir une décision prise trop tôt.
Le natif : performance et accès complet au système
Une application native est écrite dans le langage attendu par chaque plateforme : Swift ou Objective-C côté Apple, Kotlin ou Java côté Android. Elle parle directement au système d'exploitation, ce qui lui donne les meilleures performances possibles et un accès immédiat à toutes les fonctions du téléphone : capteurs, caméra, notifications fines, animations très fluides, fonctionnement hors ligne avancé.
Cette qualité a un prix. Deux plateformes signifient deux bases de code à écrire, à tester et à maintenir, souvent par des profils différents. Le coût de départ et le coût d'entretien sont donc plus élevés. Le natif se justifie quand l'expérience mobile est le cœur du produit, pas un simple complément, et quand la moindre lenteur ou limitation se paierait en abandons d'utilisateurs.
Quand le natif est le bon choix
- L'application exploite intensément le matériel : caméra temps réel, capteurs, géolocalisation continue, Bluetooth.
- La fluidité et le temps de réponse sont décisifs : jeu, montage, cartographie, graphismes animés.
- Le mobile est le produit lui-même, pas une extension d'un service qui vit ailleurs.
- Vous visez une expérience irréprochable sur chaque plateforme et acceptez d'en payer le coût de maintenance.
- Des fonctions système récentes doivent être disponibles dès leur sortie, sans attendre qu'un cadre tiers les prenne en charge.
Le cross-platform : une base de code, deux plateformes
Le cross-platform répond à une frustration simple : pourquoi écrire deux fois la même application ? Avec un cadre comme React Native ou Flutter, on écrit une seule base de code qui produit les versions iOS et Android. On mutualise la logique métier, les écrans et une grande partie des tests. Le gain de temps et de budget est réel, surtout pour une application orientée contenu, formulaires, listes et parcours classiques.
Le compromis se situe sur les cas limites. Pour les fonctions très spécifiques à une plateforme ou très gourmandes, il faut parfois descendre dans du code natif en complément, et la dépendance au cadre choisi devient une variable à surveiller dans la durée. Pour la grande majorité des applications de service, ce compromis est largement favorable : on couvre les deux mondes avec une équipe et une base unique, sans sacrifier une qualité perceptible par l'utilisateur.
Quand le cross-platform est le bon choix
- Vous devez être présent sur iOS et Android avec un budget et un calendrier maîtrisés.
- L'application est centrée sur du contenu, des parcours et des échanges avec un serveur, plus que sur le matériel du téléphone.
- Vous voulez faire évoluer les deux versions en parallèle, sans doubler l'effort à chaque nouveauté.
- Les performances attendues sont élevées mais pas extrêmes : la plupart des applications métier entrent dans ce cas.
- Une seule équipe doit pouvoir porter le produit dans la durée, sans se disperser sur deux bases distinctes.
La PWA : le web qui s'installe
Une application web progressive, ou PWA, est un site web qui adopte les codes d'une application : installation sur l'écran d'accueil, plein écran, notifications sur certaines plateformes et fonctionnement hors connexion grâce à une mise en cache locale. Elle se diffuse par une simple adresse web, sans passer par les magasins d'applications ni leurs processus de validation. Une seule base sert le web et le mobile.
Ses limites tiennent à sa nature web : l'accès à certaines fonctions avancées du téléphone reste partiel et varie selon les systèmes, et l'absence des magasins peut peser quand la présence dans un store fait partie de la crédibilité attendue. En contrepartie, la PWA est souvent la voie la plus rapide et la plus économique pour mettre un outil utile entre les mains des utilisateurs, et pour le faire évoluer sans friction de déploiement.
Quand la PWA est le bon choix
- Vous voulez une présence mobile rapide, économique et facile à mettre à jour.
- Le même outil doit servir sur ordinateur et sur téléphone, avec une base unique.
- Les fonctions avancées du matériel ne sont pas au cœur de l'usage.
- La diffusion par une simple adresse web est un avantage : pas d'attente de validation, pas de mise à jour à faire installer.
- Vous voulez valider un usage auprès de vrais utilisateurs avant d'investir dans une application plus lourde.
Les vrais critères de décision
Une fois les trois familles comprises, le choix ne se joue pas sur la technologie en elle-même, mais sur ce que l'application doit faire et pour qui. Les mêmes questions reviennent à chaque projet, et leurs réponses pointent presque toujours vers une approche plutôt qu'une autre. L'erreur serait de décider d'abord de l'outil, puis d'adapter le besoin à l'outil.
Prenez ces questions dans l'ordre. Elles partent de l'usage, passent par les contraintes de performance et de budget, et finissent par la durée de vie attendue du produit. C'est cette dernière qui est le plus souvent négligée, alors qu'elle pèse lourd : une application vit, se corrige et évolue bien après sa mise en ligne.
Les questions à se poser avant de trancher
- Que fait vraiment l'application, et de quelles fonctions du téléphone a-t-elle réellement besoin ?
- Vos utilisateurs sont-ils plutôt sur iOS, sur Android, ou sur les deux de façon équilibrée ?
- La performance brute est-elle un critère vital, ou un bon niveau suffit-il largement ?
- Quel budget et quel délai sont tenables pour la première version, puis pour la maintenance ?
- La présence dans les magasins d'applications est-elle indispensable à votre crédibilité ?
- Qui fera évoluer l'application dans deux ans, et avec quelle taille d'équipe ?
Le coût caché : ce qui vient après la mise en ligne
Le choix d'architecture n'est jamais une décision ponctuelle : il engage toute la vie de l'application. Une base native double le travail de maintenance mais offre un contrôle total. Un cadre cross-platform fait gagner un temps précieux mais lie le produit à l'évolution de ce cadre. Une PWA simplifie le déploiement mais demande de composer avec les limites du web. Dans tous les cas, le vrai coût n'est pas celui du lancement, c'est celui des années qui suivent : systèmes qui changent, correctifs de sécurité, nouvelles fonctions, montée en charge.
C'est pour cette raison que nous concevons chaque application sur mesure avec l'accompagnement qui va avec. Chez Horyond, chaque service inclut un abonnement d'accompagnement : hébergement, tableau de bord pour suivre l'usage, support, sécurité et évolutions au fil du temps. Nous aidons d'abord à choisir la bonne approche pour votre projet, puis nous restons pour la faire durer. Notre promesse tient en une phrase : on conçoit vos outils, et on reste. Le meilleur moyen de valider votre choix est d'en parler : tout commence par un appel découverte gratuit en visio.
La bonne architecture n'est pas la plus impressionnante, c'est celle qui sert le mieux l'usage réel de vos utilisateurs sur la durée.
Notre règle de conception mobile
Natif, cross-platform ou PWA : lequel est le moins cher ?
En règle générale, la PWA est la plus économique au départ car une seule base sert le web et le mobile, suivie du cross-platform qui couvre iOS et Android avec une base unique, puis du natif qui demande deux bases distinctes. Mais le coût de départ n'est qu'une partie de l'équation : la maintenance dans la durée pèse souvent plus lourd, et c'est elle qu'il faut regarder avant de trancher.
Le cross-platform offre-t-il la même performance que le natif ?
Pour la grande majorité des applications de service, l'utilisateur ne perçoit aucune différence. L'écart devient visible sur les usages extrêmes : graphismes animés, traitement temps réel, exploitation intensive des capteurs. Si votre application entre dans ces cas, le natif garde l'avantage ; sinon, le cross-platform offre un excellent compromis entre qualité et coût.
Une PWA peut-elle remplacer une application dans les magasins ?
Souvent oui, surtout pour un outil centré sur du contenu et des parcours qui n'a pas besoin des fonctions avancées du matériel. La PWA s'installe sur l'écran d'accueil et fonctionne hors connexion. La présence dans un magasin reste utile quand elle fait partie de la crédibilité attendue ou quand vous visez des fonctions système que le web ne couvre pas encore.