Application native, hybride ou PWA : laquelle choisir ?

« On peut faire une PWA, non ? Ça coûte moins cher. » La question arrive dans presque tous nos ateliers de cadrage. Elle est légitime. Une Progressive Web App, c’est un seul code, pas de commission de store, pas d’attente de validation, et une mise à jour visible par tous en quelques minutes.

Mais la PWA n’est pas une application au rabais. C’est un autre produit, avec ses forces et des limites précises, en particulier sur iPhone. Choisir entre natif, hybride et PWA, c’est d’abord savoir ce que votre produit doit faire, puis vérifier quelle famille le permet.

Trois familles, pas deux

Le mot « hybride » entretient la confusion. Il recouvre deux approches très différentes, qu’il faut séparer d’emblée.

Les trois premières lignes sont des applications au sens strict : un binaire publié sur les stores, installé par l’utilisateur. La différence entre elles est surtout une affaire de budget et de performance, et nous l’avons détaillée dans React Native, Flutter ou natif : comment trancher. Retenez-en un repère : sur un projet iOS + Android, le cross-platform fait économiser 30 à 40 % par rapport à deux applications natives.

La quatrième ligne change de nature. Une PWA n’est pas installée depuis un store : c’est votre site, qui se comporte comme une application une fois ajouté à l’écran d’accueil. Ses capacités ne dépendent pas de vous, mais du navigateur. Sur iPhone, c’est WebKit, le moteur de Safari, qui fixe la règle.

Ce qu’une PWA sait faire en 2026

Les choses ont beaucoup bougé ces trois dernières années, surtout côté Apple. Beaucoup d’avis qui circulent datent d’avant.

L’installation

Sur Android, Chrome (sur les appareils dotés des services Google) et Samsung Internet transforment la PWA en WebAPK : un vrai paquet Android, généré et signé par un fournisseur de confiance, qui apparaît dans le lanceur et dans les réglages comme une application classique. Le site peut afficher sa propre invitation à installer. Les autres navigateurs Android, comme Firefox, se contentent d’un raccourci qui ouvre le site dans le navigateur.

Sur iPhone, il n’existe pas d’invitation à installer : l’événement beforeinstallprompt n’y est pas pris en charge. L’utilisateur doit ouvrir le menu Partager et choisir « Sur l’écran d’accueil ». Depuis iOS 16.4, c’est possible depuis Safari, mais aussi depuis Chrome, Edge, Firefox et Orion. Et depuis iOS 26, tout site ajouté à l’écran d’accueil s’ouvre par défaut comme une application web, même sans manifeste. WebKit le résume ainsi : il n’y a plus aucune exigence d’« installabilité » dans Safari.

Conséquence pratique : sur iPhone, l’installation est simple techniquement, mais elle repose entièrement sur l’utilisateur. Il faut le lui expliquer, à l’écran, au bon moment.

Les notifications push

C’est le point qui a le plus changé. Depuis iOS et iPadOS 16.4, une PWA installée sur l’écran d’accueil peut recevoir des notifications web push. Elles s’affichent sur l’écran verrouillé, dans le centre de notifications et sur l’Apple Watch associée, et respectent les modes Concentration, comme celles d’une application native. L’API Badging permet aussi d’afficher un compteur sur l’icône.

Deux conditions limitent l’usage. La PWA doit être installée, sinon pas de push sur iPhone. Et la demande d’autorisation ne peut être déclenchée qu’en réponse à une action directe de l’utilisateur, par exemple un bouton « Activer les alertes ». Vous ne pouvez donc pas demander l’autorisation au premier lancement, comme le font beaucoup d’applications.

Sur Android, Chrome et Firefox prennent en charge le push web.

Le hors-ligne et le stockage

Un service worker permet de mettre en cache l’interface et les données, et donc d’ouvrir l’application sans réseau. Pour un catalogue, une documentation, un formulaire simple, c’est suffisant.

Le stockage a ses règles. Sur iPhone, une PWA installée dispose du même quota que le site ouvert dans Safari, et WebKit peut effacer les données d’un site que l’utilisateur n’a pas utilisé depuis un certain temps. Une application peut demander un stockage persistant avec navigator.storage.persist(), et WebKit en tient compte, notamment si le site est ouvert comme application web depuis l’écran d’accueil. Mais l’accord n’est pas garanti.

La vraie limite est ailleurs : la synchronisation en arrière-plan. L’API Background Sync, qui permet d’envoyer automatiquement les données saisies hors ligne dès que le réseau revient, n’est prise en charge ni par Safari sur iOS ni par Firefox. Elle fonctionne sur Chrome Android. Pour une équipe terrain qui travaille toute la journée sans réseau, c’est rédhibitoire ; nous avons détaillé ce cas dans notre article sur les applications hors ligne pour équipes terrain.

La présence dans les stores

Sur Google Play, une PWA peut être publiée grâce à une Trusted Web Activity : une petite application Android qui ouvre votre site en plein écran dans le navigateur. Il faut prouver, par Digital Asset Links, que le site et l’application viennent du même éditeur, et l’outil Bubblewrap génère le projet. Google le précise : le contenu doit d’abord être accessible et utile dans le navigateur.

Sur l’App Store, il n’y a pas d’équivalent. Il faut construire une application iOS qui charge le site dans une vue web, et Apple est clair dans sa règle 4.2 : une application doit offrir des fonctionnalités, du contenu et une interface qui la placent au-delà d’un site reconditionné. Un simple emballage d’une PWA a de bonnes chances d’être refusé. Les motifs de rejet les plus courants sont détaillés dans notre article sur les refus App Store et Google Play.

Ce qu’une PWA ne fait pas, ou mal

Le Web Bluetooth est classé expérimental et non « Baseline » par MDN, ce qui veut dire qu’il ne fonctionne pas dans plusieurs navigateurs majeurs. Web NFC n’existe que dans Chrome sur Android. Et le géorepérage figure parmi les capacités que web.dev classe comme inutilisables dans une PWA.

Autrement dit, tout ce qui touche au matériel ou au travail en arrière-plan reste le territoire des applications natives et cross-platform.

Quand la PWA est le bon choix

Votre trafic vient de Google. Une PWA est d’abord un site : elle est indexée, partageable par un lien, utilisable sans rien installer. Si vos utilisateurs vous trouvent par une recherche et reviennent de temps en temps, leur imposer un téléchargement leur fait perdre une étape, et à vous des utilisateurs. C’est le raisonnement que nous développons dans application e-commerce ou site mobile.

C’est un outil interne. Un back-office mobile, un outil de réservation de salles, un tableau de bord pour les équipes : pas besoin de store, pas de revue, déploiement immédiat. Vous pouvez même installer la PWA vous-même sur les appareils de l’entreprise.

L’usage est ponctuel. Commander à table, suivre une livraison, remplir un formulaire d’inscription, consulter un programme d’événement. Personne ne veut télécharger une application pour s’en servir une fois.

Vous testez un marché. Une PWA permet de valider un parcours auprès de vrais utilisateurs avant d’engager le budget d’une application iOS + Android. Si l’usage est au rendez-vous, l’interface et le back-end serviront de base à la suite.

Quand elle ne l’est pas

Votre rétention repose sur les notifications iPhone. Le push existe, mais seulement après une installation manuelle que beaucoup d’utilisateurs ne feront pas. Si votre modèle dépend d’un rappel quotidien, une application installée depuis l’App Store reste le chemin le plus fiable.

Le produit dépend du matériel. Bluetooth, NFC, lecture de badges, capteurs, géolocalisation en arrière-plan : c’est du natif ou du cross-platform, sans débat. Pour les usages très matériels, le natif garde un avantage.

Le travail hors ligne doit être fiable. Sans synchronisation en arrière-plan sur iPhone, et avec un stockage que le système peut effacer, une PWA n’est pas une base saine pour une équipe terrain.

La visibilité dans l’App Store compte. Pour un public grand public qui cherche « une application » dans le store, ne pas y être revient à ne pas exister pour lui. Et Apple ne publiera pas un simple emballage de site.

Le piège du « on commencera en PWA »

C’est un raisonnement que nous entendons souvent : PWA d’abord, application ensuite. Il fonctionne, à une condition : que le passage à l’application soit prévu dès le départ.

Ce qui se réutilise : le back-end, l’API, les données, le design et une bonne partie de la logique métier. Ce qui ne se réutilise pas, ou mal : l’interface, si vous passez sur React Native ou Flutter, et tout ce qui a été bricolé pour contourner les limites du web. Une PWA qui a accumulé des contournements pour simuler une fonction native coûte plus cher à migrer qu’un produit sobre.

Le bon réflexe est donc de concevoir l’API comme si une application native allait la consommer demain. Le surcoût est faible au départ, et il évite de tout reprendre au moment où le produit décolle.

Et le budget ?

Une PWA coûte généralement moins cher qu’une application : un seul code, pas de publication sur deux stores, pas de revue à chaque version. Mais comparer les devis à l’instant T est trompeur. Le vrai calcul porte sur deux ou trois ans.

De notre côté, une application complète iOS + Android représente 3 à 4 mois de développement et 120 à 200 jours-homme ; un MVP mobile sur une plateforme, 4 à 8 semaines et 30 à 60 jours-homme. La maintenance représente ensuite 15 à 20 % du coût initial par an. Si une PWA permet d’éviter ce palier pendant la phase de validation, c’est une excellente décision. Si elle doit être refaite en application six mois plus tard parce qu’une fonction indispensable manque sur iPhone, l’économie se transforme en double dépense. Pour situer ces paliers, notre article sur le coût d’une application mobile détaille les fourchettes.

Notre position est simple : la PWA est le bon choix quand vos trois fonctions essentielles fonctionnent sur iPhone sans contournement. Dans tous les autres cas, une application cross-platform est presque toujours un meilleur investissement, et le natif reste justifié quand le matériel est au cœur du produit.

Pour aller plus loin : notre page création d’application mobile explique comment nous choisissons la technologie au cadrage, et pourquoi ce choix se fait avant la première maquette.

Sources

• WebKit, « Web Push for Web Apps on iOS and iPadOS »
• WebKit, « WebKit Features in Safari 26.0 »
• WebKit, « Updates to Storage Policy »
• MDN, « Making PWAs installable »
• MDN, « Web Bluetooth API »
• MDN, « Background Synchronization API »
• web.dev, « Installation » (Learn PWA)
• web.dev, « Capabilities » (Learn PWA)
• Android Developers, « Trusted Web Activities »
• Apple, App Store Review Guidelines, règle 4.2
• Can I use, Push API
• Can I use, Background Sync
• Can I use, Web NFC