Une application native est développée spécifiquement pour iOS et Android et distribuée par les stores ; une PWA (progressive web app) est une application web installable sur l’écran d’accueil, capable de fonctionner hors connexion, développée une seule fois pour tous les appareils. Pour la majorité des applications métier internes (équipes terrain, entrepôt, chantier, commerciaux), la PWA est le choix le plus simple et le plus économe en maintenance. Le natif s’impose quand l’application dépend de fonctions matérielles avancées, d’un fonctionnement intensif en arrière-plan ou d’une visibilité dans les stores auprès du grand public.
Ce guide pose les définitions, puis propose une grille de décision fondée sur vos usages réels plutôt que sur les modes technologiques.
Native, multiplateforme, PWA : de quoi parle-t-on ?
Trois grandes familles se partagent le terrain, et la frontière entre elles est plus fine qu’on ne le croit.
- L’application native est écrite dans les langages propres à chaque plateforme (Swift pour iOS, Kotlin pour Android). Elle accède à toutes les fonctions du téléphone et offre l’expérience la plus intégrée, au prix de deux bases de code à développer et maintenir.
- L’application multiplateforme (React Native, Flutter) produit des applications installables depuis les stores à partir d’un code largement commun. C’est le compromis le plus répandu quand une présence dans les stores est nécessaire.
- La PWA est, selon la définition de MDN, une application construite avec les technologies du web mais qui offre une expérience comparable à celle d’une application propre à une plateforme. Comme un site, elle fonctionne sur tous les appareils à partir d’un seul code ; comme une application, elle peut être installée, fonctionner hors connexion et s’intégrer à l’appareil.
Concrètement, une PWA s’ouvre d’abord dans le navigateur, puis l’utilisateur l’ajoute à son écran d’accueil. Elle se lance alors dans sa propre fenêtre, sans barre d’adresse, avec son icône, comme n’importe quelle application. Google résume l’ambition sur web.dev : toucher n’importe quel utilisateur, sur n’importe quel appareil, avec une seule base de code.
Que sait faire une PWA en 2026 ?
Les capacités du web ont beaucoup progressé, et une partie des objections d’il y a quelques années ne tiennent plus.
Ce qui fonctionne bien sur les navigateurs actuels :
- l’installation sur l’écran d’accueil et le lancement en plein écran ;
- le fonctionnement hors connexion grâce aux service workers, des scripts qui s’exécutent en arrière-plan et interceptent les requêtes réseau ;
- l’appareil photo, la lecture de codes-barres et de QR codes via la caméra, la géolocalisation, les fichiers ;
- les notifications push, y compris sur iPhone : depuis iOS et iPadOS 16.4, comme l’a annoncé l’équipe WebKit, une web app ajoutée à l’écran d’accueil peut demander l’autorisation d’envoyer des notifications, à condition que la demande fasse suite à une action explicite de l’utilisateur.
Ce qui reste limité ou inégal :
- certaines API matérielles, comme Web Bluetooth, que MDN classe comme expérimentale et non disponible dans plusieurs des navigateurs les plus utilisés ;
- les traitements longs en arrière-plan quand l’application est fermée (suivi GPS continu, synchronisation lourde) ;
- l’intégration fine au système : widgets, raccourcis avancés, interactions avec d’autres applications installées.
La règle pratique : listez les fonctions dont votre application a réellement besoin, puis vérifiez chacune sur les appareils de vos utilisateurs, en particulier sur iPhone.
Comment choisir : la grille de décision
Le bon choix dépend de cinq questions : qui sont les utilisateurs, comment ils reçoivent l’application, de quelles fonctions de l’appareil elle a besoin, dans quelles conditions de réseau elle est utilisée, et qui la maintiendra.
| Critère | PWA | Multiplateforme | Native |
|---|---|---|---|
| Utilisateurs | Salariés, partenaires, clients B2B | Grand public ou B2B exigeant une app de store | Grand public, usage quotidien intensif |
| Distribution | Un lien, aucune validation | Stores (validation Apple et Google) | Stores (validation Apple et Google) |
| Mises à jour | Immédiates pour tous | Via les stores, versions multiples en circulation | Via les stores, versions multiples en circulation |
| Hors connexion | Oui, à concevoir avec soin | Oui | Oui |
| Fonctions matérielles avancées | Limitées et variables selon le navigateur | Larges, via des modules | Complètes |
| Bases de code | Une, partagée avec la version bureau | Une pour le mobile, une pour le web | Deux pour le mobile, une pour le web |
| Effort de maintenance | Le plus faible | Intermédiaire | Le plus élevé |
Deux critères pèsent souvent plus que les autres dans une PME ou une ETI.
La version bureau. Une application métier est rarement uniquement mobile : le technicien saisit sur son téléphone, mais le planificateur, le responsable qualité et la comptabilité travaillent sur grand écran. Avec une PWA, c’est la même application web, avec une interface adaptée à chaque écran. Avec du natif, il faut développer et maintenir une application web à côté.
La distribution. Pour une application interne, passer par les stores est une contrainte plus qu’un avantage : comptes développeurs, validations, publication privée ou gestion de flotte. Apple rappelle d’ailleurs dans ses règles de validation (section 4.2) qu’une application doit apporter des fonctionnalités, des contenus et une interface qui la placent au-dessus d’un simple site web reconditionné. Une PWA se distribue par un lien ou un QR code, et chaque mise en ligne profite immédiatement à tous les utilisateurs.
Dans quels cas la PWA est-elle le bon choix ?
La PWA est particulièrement adaptée aux situations suivantes :
- Les applications terrain : bons d’intervention, rapports de visite, états des lieux, relevés. C’est le cas typique d’une application de gestion des interventions, où l’essentiel est la saisie rapide, la photo, la signature du client et le hors-ligne.
- Le suivi de chantier, avec des équipes qui changent souvent et des téléphones personnels ou de chantier hétérogènes, comme nous le détaillons pour le BTP.
- L’entrepôt et la logistique : préparation, réception, inventaire, avec lecture de codes-barres par la caméra ou par des terminaux durcis équipés d’un navigateur.
- Les portails clients et partenaires, consultés tantôt sur ordinateur, tantôt sur mobile, sans que l’utilisateur ait envie d’installer une application de plus.
- Les premières versions d’un produit : une PWA permet de valider l’usage auprès de vrais utilisateurs avant d’investir dans des applications de store, dans l’esprit d’un MVP.
Dans quels cas faut-il du natif ou du multiplateforme ?
Le natif, ou le multiplateforme, reste préférable dans plusieurs cas :
- Une application grand public dont la découverte passe par les stores et qui doit être présente sur l’écran d’accueil de milliers d’utilisateurs.
- Des fonctions matérielles avancées : communication Bluetooth avec des capteurs ou des équipements, NFC, suivi de localisation en continu, traitement d’images lourd sur l’appareil.
- Un fonctionnement en arrière-plan soutenu : synchronisation régulière de gros volumes même application fermée, enregistrement continu.
- Une intégration poussée au système : widgets, raccourcis, partage avancé avec d’autres applications.
Une stratégie fréquente consiste à combiner les deux : l’application web (et PWA) couvre l’essentiel des usages au bureau et sur le terrain, et une application multiplateforme ciblée ne traite que le cas qui l’exige, par exemple la connexion à un équipement en Bluetooth. Les deux s’appuient sur les mêmes API et la même base de données.
Les points de vigilance, quel que soit le choix
Quelle que soit la technologie retenue, les mêmes sujets font la différence entre une application adoptée et une application contournée :
- Concevoir le hors-ligne dès le départ : quelles données sont disponibles sans réseau, comment les saisies sont mises en file d’attente, comment les conflits sont résolus quand deux personnes modifient le même dossier.
- Penser l’ergonomie terrain : gros boutons, contraste élevé pour l’extérieur, saisie minimale, valeurs proposées par défaut. Les principes de l’UX des applications métier s’appliquent doublement sur mobile.
- Sécuriser l’authentification : session longue mais révocable, déconnexion à distance d’un appareil perdu, chiffrement des données stockées localement.
- Tester sur les vrais appareils des utilisateurs, y compris les plus anciens, et pas seulement sur le dernier modèle du chef de projet.
- Prévoir l’intégration avec l’ERP, le CRM ou l’outil de planification, pour que les données saisies sur le terrain arrivent là où elles servent.
En résumé
Pour une application métier destinée à vos équipes, vos partenaires ou vos clients professionnels, commencez par vous demander si une PWA ne suffit pas : c’est le cas le plus fréquent, et le plus économe à faire vivre. Réservez le natif ou le multiplateforme aux usages qui l’exigent vraiment, et identifiez-les fonction par fonction plutôt que par principe.
Vous hésitez entre les deux pour votre projet ? Décrivez vos utilisateurs et vos contraintes dans notre diagnostic de projet : en deux minutes, vous obtenez une première orientation, et nous revenons vers vous avec une analyse détaillée.
