Avant d'écrire la première ligne de code d'une application, une décision structure tout le projet : application native, multiplateforme ou PWA ? Ce choix influence le budget, les délais, l'expérience utilisateur, la maintenance et même les possibilités de distribution. Il n'existe pas de réponse universelle, mais il existe des critères clairs pour décider.
Cet article compare les trois approches (Kotlin et Swift d'un côté, Flutter et React Native de l'autre, les applications web progressives enfin), explique leurs forces et leurs limites, et vous donne une grille de décision. Pour la question du budget, voyez notre guide sur le prix d'une application mobile.
Les trois approches en deux minutes
L'application native
Une application native est écrite dans le langage et avec les outils officiels de chaque système : Swift (ou Objective-C) pour iOS, Kotlin (ou Java) pour Android. Vous obtenez deux applications distinctes, deux bases de code, et un accès direct à toutes les fonctions du téléphone dès leur sortie.
L'application multiplateforme
Une seule base de code produit les applications iOS et Android. Deux technologies dominent :
- Flutter (Google), basé sur le langage Dart. D'après la documentation officielle, une même base de code peut cibler le mobile (iOS et Android), le web, le bureau (Windows, macOS, Linux) et des appareils embarqués, avec un moteur de rendu qui donne le contrôle de chaque pixel. Source : flutter.dev, multi-plateforme.
- React Native (Meta), basé sur JavaScript et React. Selon sa documentation, les composants React se traduisent en éléments d'interface natifs de la plateforme, et non en vue web ; le projet recommande d'utiliser un framework comme Expo pour les nouvelles applications. Source : reactnative.dev.
La PWA (Progressive Web App)
Une PWA est un site web conçu pour se comporter comme une application : installable sur l'écran d'accueil, utilisable avec une connexion intermittente, avec une icône et un affichage plein écran. Elle se distribue par une simple adresse web, sans passer par un store.
Comparatif synthétique
| Critère | Natif (Swift / Kotlin) | Multiplateforme (Flutter / React Native) | PWA |
|---|---|---|---|
| Bases de code | 2 (une par système) | 1 | 1 (le site) |
| Accès aux fonctions du téléphone | Complet, dès la sortie | Très large, via des modules ; parfois code natif en plus | Limité, variable selon le navigateur |
| Présence sur les stores | Oui | Oui | Non (installation depuis le navigateur) |
| Budget et délai de départ | Les plus élevés | Intermédiaire | Les plus bas |
| Cohérence iOS / Android | Deux interfaces à maintenir | Une interface partagée | Une interface |
| Hors-ligne, notifications avancées | Oui | Oui | Partiel |
| Maintenance | Deux chantiers | Un chantier + mises à jour du framework | Un chantier |
Ce tableau est une grille de lecture qualitative, pas une mesure de performance : aucune technologie n'est « meilleure » dans l'absolu.
Quand le natif est le bon choix
Le natif se justifie quand l'application dépend fortement du système :
- accès précoce à de nouvelles API iOS ou Android (widgets, capteurs, services système) ;
- traitement lourd en temps réel (vidéo, audio, graphisme avancé) ;
- exigence maximale d'intégration avec le système (comportements en arrière-plan, géolocalisation fine) ;
- équipe ou produit déjà centrés sur un seul système.
Chez Hanoon Labs, l'application de stationnement Park France a été conçue en Kotlin avec Jetpack Compose et s'appuie sur des données ouvertes publiques : un cas où le travail se concentre sur une plateforme.
Le revers : si vous voulez aussi iOS, il faut une seconde application, avec son propre cycle de développement et de tests. Le budget et les délais augmentent d'autant.
Quand le multiplateforme est le meilleur compromis
Pour la grande majorité des applications d'entreprise, de service ou de marketplace, le multiplateforme couvre le besoin : écrans, formulaires, listes, cartes, paiements, notifications, appareil photo, scanner, stockage local. L'avantage décisif est la base de code unique : une fonction développée une fois, testée une fois, publiée sur les deux systèmes.
Nos exemples concrets, tous issus de notre portfolio :
- PDF Nova pour Android, développée avec Flutter, regroupe scanner, OCR, édition, signature et protection AES-256 ; l'application est en test fermé sur Google Play.
- Flash-Destock, une place de marché de bons plans locaux à Paris (pass QR, tableau de bord commerçant, back-end Supabase et PostGIS), également en test fermé sur Google Play.
- Cachet, application de devis et factures qui fonctionne hors-ligne, avec des préréglages fiscaux par pays.
Flutter ou React Native ?
La question revient systématiquement. Quelques critères de choix honnêtes :
- Compétences existantes : si votre équipe maîtrise déjà JavaScript et React (par exemple sur un site web), React Native réduit la courbe d'apprentissage. Flutter demande d'apprendre Dart, un langage simple à prendre en main pour des développeurs expérimentés.
- Interface sur mesure : Flutter dessine lui-même ses composants, ce qui donne beaucoup de contrôle visuel et une apparence identique sur tous les appareils. React Native s'appuie sur les composants de la plateforme, ce qui rapproche l'apparence de chaque système.
- Partage avec le web : React Native permet de réutiliser des compétences et parfois du code côté web ; Flutter peut aussi cibler le web, mais son usage se pense au cas par cas.
- Écosystème : les deux disposent de nombreuses bibliothèques. Vérifiez toujours qu'une dépendance critique (paiement, carte, scanner) est maintenue activement avant de vous engager.
Dans les deux cas, le choix compte moins que la qualité de l'architecture, du cadrage et des tests.
Les limites à connaître
Le multiplateforme ajoute une couche entre votre code et le système. Pour une fonction très spécifique, il faut parfois écrire un petit module natif. Et les mises à jour du framework, comme celles des systèmes, demandent un suivi régulier. Rien de rédhibitoire, mais à intégrer dans la maintenance.
La PWA : un bon point de départ, avec des limites réelles
Une PWA est intéressante quand le besoin est avant tout de consulter ou de saisir de l'information, quand vous voulez toucher le plus de monde sans passer par un store, ou comme première étape pour valider un usage.
Il faut toutefois connaître ses contraintes, notamment sur iPhone. La documentation web.dev détaille l'installation : sur iOS et iPadOS, il n'existe pas d'invite d'installation dans le navigateur ; l'utilisateur doit passer par le menu Partager puis « Sur l'écran d'accueil ». Le badge d'icône et les raccourcis ne sont pas pris en charge, et l'application installée s'exécute dans un processus distinct, avec un rendu ou un stockage qui peuvent différer de l'onglet du navigateur. Source : web.dev, installation d'une PWA.
En pratique :
- Avantages : pas de commission de store, mise à jour instantanée, une seule base de code, coût réduit.
- Limites : visibilité inférieure à celle d'une fiche sur l'App Store ou Google Play, accès restreint à certaines fonctions du téléphone, expérience d'installation moins évidente pour le grand public.
Beaucoup de projets gagnent à commencer par un site ou une application web bien pensée, puis à passer en application multiplateforme quand l'usage est validé. Notre page sur le développement d'applications web détaille cette voie.
La distribution : stores, frais et règles
Le choix technique ne dispense pas des règles de publication. Pour les deux stores, comptez le programme développeur Apple à 99 USD par an (Apple Developer Program) et les frais d'inscription uniques de 25 USD pour Google Play (aide Google Play Console). Les comptes Google Play personnels créés après novembre 2023 doivent aussi réaliser un test fermé avec 12 testeurs pendant 14 jours avant la production (règles Google Play). Une PWA évite ces étapes, mais aussi la visibilité des stores.
Si vous vendez des biens ou services numériques dans l'application, la commission App Store est de 30 %, ou 15 % pour les membres de certains programmes dont le Small Business Program (source Apple ci-dessus). Cela peut orienter le modèle économique, quelle que soit la technologie.
L'impact sur la maintenance et l'équipe
Le choix de départ se paie ou se rentabilise sur la durée.
- Natif : deux applications, donc deux jeux de tests, deux cycles de mise en production et souvent deux compétences à mobiliser. Les nouveautés d'un système sont disponibles immédiatement, mais chaque fonction est à développer deux fois.
- Multiplateforme : une fonction s'écrit une fois. Il faut en contrepartie suivre les versions du framework et des bibliothèques, et vérifier le comportement sur les deux systèmes à chaque mise à jour importante.
- PWA : une seule version à déployer, sans validation de store. En revanche, le comportement varie selon les navigateurs et les versions du système, ce qui demande des tests sur plusieurs appareils.
Dans tous les cas, prévoyez des tests automatisés pour les parcours critiques et un budget annuel d'évolution. Une application qui n'est pas mise à jour finit par être retirée ou bloquée par les évolutions des systèmes.
Les erreurs de choix les plus fréquentes
- Choisir la technologie à la mode plutôt que celle qui répond à l'usage : une application de formulaires n'a pas besoin des mêmes outils qu'un jeu en 3D.
- Développer deux applications natives dès la version 1 sans avoir validé l'usage : le budget double avant de savoir si le produit trouve son public.
- Partir sur une PWA en espérant les mêmes capacités qu'une application : vérifiez la liste des fonctions dont vous avez besoin, en particulier sur iPhone.
- Ignorer les compétences de l'équipe de maintenance : une base de code qu'aucun développeur disponible ne maîtrise devient un risque.
- Oublier l'accessibilité et les différentes tailles d'écran : elles doivent être traitées dès la conception, quelle que soit la technologie.
Grille de décision
Posez-vous ces questions dans l'ordre :
- L'application doit-elle vraiment être sur les stores ? Sinon, étudiez d'abord la PWA ou une application web.
- Utilise-t-elle des fonctions système très spécifiques ou du traitement lourd en temps réel ? Oui : natif. Non : passez à la suite.
- Voulez-vous iOS et Android avec un budget maîtrisé ? Oui : multiplateforme.
- Quelles compétences possédez-vous en interne ? Elles pèsent sur Flutter ou React Native.
- Quelle est la durée de vie du produit ? Un produit à long terme avec une équipe dédiée peut justifier du natif ; un produit à valider vite, du multiplateforme ou de la PWA.
FAQ
Une application multiplateforme est-elle moins performante ?
Pour la plupart des usages courants (listes, formulaires, cartes, paiement), la différence n'est pas perceptible par l'utilisateur lorsque l'application est bien conçue. Les cas exigeants (jeux, traitement vidéo temps réel) demandent une étude spécifique, voire du natif.
Peut-on passer d'une PWA à une application native plus tard ?
Oui. L'interface et la logique métier se réécrivent, mais le back-end, les données et la réflexion produit sont conservés. C'est une trajectoire fréquente.
Flutter ou React Native pour une jeune entreprise ?
Les deux sont solides. Choisissez selon les compétences disponibles, le niveau de personnalisation visuelle souhaité et la qualité des bibliothèques dont vous dépendez.
Une PWA suffit-elle pour une application professionnelle ?
Pour un outil interne, un tableau de bord ou un service de consultation, souvent oui. Pour des notifications fiables sur iPhone, un fort usage du hors-ligne ou l'accès au matériel, évaluez une application dédiée.
Faut-il tout décider avant de contacter un prestataire ?
Non. Un bon cadrage commence justement par ces questions. Présentez votre objectif et vos contraintes, le choix technique en découle.
Conclusion
Le natif apporte le maximum de contrôle, le multiplateforme le meilleur équilibre budget, délai et couverture, la PWA une entrée en matière économique et sans store. Le bon choix est celui qui répond à votre usage réel, à votre budget et à votre capacité de maintenance. Découvrez notre approche de la création d'application mobile ou parlons de votre projet pour obtenir une recommandation argumentée.
