MobileApplication métierMéthodeBudget
Application web, PWA ou native : que choisir ?
6 min de lecture
Pour une application métier utilisée par vos équipes, une application web, installable sous forme de PWA, couvre la majorité des besoins pour un coût plus bas qu'une application native : un seul code, aucune validation des stores, des mises à jour immédiates. L'application native s'impose quand l'usage exige un accès profond au téléphone (suivi en arrière-plan, Bluetooth, longues périodes hors ligne) ou une présence sur l'App Store et Google Play pour vos clients.
Ce guide compare les trois options critère par critère, sans jargon, et dit honnêtement où chacune s'arrête.
Trois façons de livrer une application
L'application web s'ouvre dans un navigateur, sur ordinateur, tablette ou téléphone. Rien à installer : une adresse suffit. C'est la forme naturelle d'un back-office, d'un portail client ou d'un outil de gestion.
La PWA (Progressive Web App) est une application web qui va plus loin. Selon web.dev, le guide de Google sur les PWA, elle « peut être installée », obtient une icône sur l'écran d'accueil, s'ouvre dans une fenêtre autonome sans interface de navigateur, et peut continuer à afficher du contenu hors connexion. Le même guide rappelle qu'une application web atteint n'importe quel appareil avec un seul code.
L'application native est écrite pour un système précis, iOS ou Android, et se télécharge sur l'App Store ou Google Play. Elle a accès à tout le matériel du téléphone, au prix de deux applications à construire, à faire valider et à maintenir. Les outils multiplateformes (React Native, Flutter) partagent une grande partie du code entre les deux systèmes, sans supprimer la publication sur les stores.
Le comparatif critère par critère
| Critère | Web | PWA | Native |
|---|---|---|---|
| Installation | Aucune | Écran d'accueil | Store |
| Hors-ligne | Non | Partiel | Complet |
| Notifications | Ordinateur, Android | Oui (iOS 16.4+) | Oui |
| Mises à jour | Immédiates | Immédiates | Validation store |
Trois lignes méritent une explication.
Le hors-ligne. Une PWA garde ses écrans en cache et peut enregistrer des saisies pour les envoyer au retour du réseau. C'est suffisant pour un technicien qui traverse une zone blanche. Pour un inventaire de plusieurs jours dans un entrepôt sans couverture, avec des milliers de lignes et des conflits à résoudre entre deux saisies, une application native donne plus de marge.
Les notifications sur iPhone. C'était longtemps l'argument contre les PWA. Apple a ajouté le Web Push aux applications web en 2023 : selon l'annonce de WebKit, depuis iOS et iPadOS 16.4, une application web ajoutée à l'écran d'accueil peut demander l'autorisation d'envoyer des notifications, après une action de l'utilisateur comme un clic sur un bouton. Une simple page ouverte dans Safari ne le peut pas : l'installation reste nécessaire.
Les mises à jour. Une application web est à jour dès que vous la déployez. Une application native passe par la revue d'Apple et de Google à chaque version, et vos utilisateurs doivent l'installer. Pour un outil métier qui évolue chaque semaine, la différence se sent vite.
Ce que le natif fait mieux
Il serait malhonnête de prétendre qu'une PWA fait tout. Le natif garde l'avantage sur :
- le suivi en arrière-plan, par exemple la géolocalisation continue d'un chauffeur quand l'écran est éteint ;
- certains accès matériels, selon le système : Bluetooth, NFC, capteurs spécifiques, lecteurs professionnels. Le support web varie fortement d'un navigateur à l'autre, et Safari sur iPhone en propose moins que Chrome sur Android ;
- les longues périodes hors ligne avec beaucoup de données locales ;
- la visibilité sur les stores, quand vos clients cherchent une application par son nom dans l'App Store ;
- la fluidité extrême d'une interface très animée, comme un jeu ou un outil de dessin.
Si l'un de ces points est au cœur de votre usage, le natif se justifie. S'il s'agit d'un « ce serait bien », il pèse rarement assez pour doubler le travail.
Ce que coûte chaque option
Le coût ne vient pas des écrans mais du nombre de choses à construire et à entretenir.
- Web ou PWA : un seul code pour l'ordinateur, la tablette et le téléphone, souvent partagé avec le back-office. Aucun compte développeur, aucune commission sur les ventes, aucune attente de validation.
- Natif : deux applications (ou un code multiplateforme), en plus du back-office et du serveur qui existent dans tous les cas. Il faut un compte Apple Developer à 99 dollars par an et un enregistrement Google Play à 25 dollars, une revue à chaque version, et des mises à jour imposées par les nouvelles versions d'iOS et d'Android.
Un piège à connaître : emballer un site web dans une coquille pour le publier sur l'App Store ne suffit pas. Les règles de revue d'Apple (règle 4.2) demandent qu'une application offre des fonctions et une interface qui dépassent celles d'un « site web reconditionné ». Si la présence sur le store est indispensable, elle se prévoit dès le départ.
Pour les postes de coût d'une application mobile en détail, voyez notre article sur le prix d'une application mobile pour une entreprise.
Quatre questions pour trancher
- Qui utilise l'application ? Vos salariés, sur des appareils que vous maîtrisez, s'accommodent très bien d'une PWA. Des clients grand public qui cherchent votre marque sur l'App Store attendent plus souvent une application de store.
- Quelles fonctions du téléphone sont indispensables ? Listez-les précisément. Appareil photo, scan de code-barres, géolocalisation ponctuelle et signature fonctionnent en web. Suivi en arrière-plan et Bluetooth avancé orientent vers le natif.
- Combien de temps sans réseau ? Quelques minutes ou quelques heures : une PWA. Plusieurs jours avec beaucoup de données : le natif.
- À quel rythme l'outil va-t-il évoluer ? Un outil métier change souvent pendant ses premiers mois. Le web évite d'attendre une validation à chaque correction.
Si vos réponses penchent vers le web, commencez par là. Le choix n'est pas définitif : le serveur, les données et le back-office se réutilisent, et seule l'interface mobile serait réécrite si un besoin natif apparaît. Le choix entre les deux grands outils multiplateformes est traité dans React Native ou Flutter.
Des situations typiques
| Besoin | Option raisonnable |
|---|---|
| Back-office, gestion, reporting | Application web |
| Saisie terrain, photos, signature | PWA |
| Portail client avec notifications | PWA |
| Suivi GPS continu d'une flotte | Native |
| Application grand public vendue en store | Native |
Ce tableau donne une tendance, pas une règle. Un même projet combine souvent un back-office web et une interface mobile installable : c'est même le cas le plus fréquent pour une PME.
La position de LPR Studio
Notre socle technique est le web : React, Next.js et TypeScript, des outils standard et documentés. Nous construisons des applications qui fonctionnent sur ordinateur, tablette et téléphone, installables quand l'usage s'y prête. Nous ne vous dirons pas qu'une PWA remplace tout : quand votre besoin relève vraiment du natif, nous le disons au moment du prototype, avant tout chiffrage. Le délai d'une première version est détaillé dans combien de temps faut-il pour développer une application, et notre méthode sur la page approche.
Par où commencer
Partez des usages, pas de la forme : qui se sert de l'outil, où, avec quel réseau et quelles fonctions du téléphone. Chez LPR Studio, le prototype visuel est gratuit et présenté en visio sous 5 jours ouvrés ; il montre l'application sur ordinateur et sur mobile, et c'est le bon moment pour vérifier qu'une version web suffit à votre équipe.