VKT Toolkit · 8 octobre 2026 · 9 min

PWA ou application native : la comparaison honnête de 2026

Presque tous les articles « PWA ou application native » sont écrits par quelqu'un qui vend l'une des deux. Celui-ci est écrit par une équipe qui a livré une PWA — neuf petits outils, sans store, sans file d'attente de validation, sans bannière d'installation — et qui vous dira quand même de faire du natif si votre produit en a besoin.

Voici donc la version honnête. Une PWA, c'est un site web plus trois choses : un manifest qui permet de l'installer sur l'écran d'accueil, un service worker qui la fait fonctionner hors ligne, et HTTPS. Une application native, c'est un binaire que vous soumettez, faites valider et distribuez. Ce qui tranche vraiment tient en quatre points : l'argent, les mises à jour, les capacités et la façon dont on vous trouve.

La vraie différence, en une phrase

Une application native, ce sont trois produits — une version iOS, une version Android et une présence web — que vous maintenez séparément. Une PWA, c'est une seule base de code servie en HTTPS, qui se trouve aussi être installable. Tout l'argument d'architecture tient dans cette phrase, et le reste en découle.

Un chiffre qui coulait autrefois les PWA n'est plus un problème : les service workers — la brique qui rend le hors ligne possible — atteignent aujourd'hui environ 96 % des utilisateurs dans le monde. « Ça ne marche pas sur assez d'appareils » n'est plus un argument en 2026. La seule raison d'éviter une PWA est une capacité précise qui manque, et cela se concentre presque entièrement sur iOS.

L'argent : commissions, développement, maintenance

Il y a ici deux coûts différents, constamment confondus : ce que coûte la construction et ce que coûte la distribution.

La surprise est du côté de la distribution. Une PWA tourne sur votre propre domaine et encaisse via votre propre passerelle : pas de frais d'inscription, pas de commission, pas d'intermédiaire. Les applications natives paient les deux, et le plus cher est la commission : un pourcentage du chiffre d'affaires, pour toujours. Apple prélève 30 % en standard, ou 15 % avec le Small Business Program (moins d'un million de dollars par an). Google prélève 15 % sur le premier million, puis 30 %. L'inscription elle-même est modique : 99 dollars par an chez Apple, 25 dollars une fois chez Google.

Cela a bougé en 2025 et 2026, et les détails comptent. Après l'injonction dans l'affaire Epic contre Apple, les applications iOS aux États-Unis peuvent renvoyer vers leur propre paiement web, et Apple a proposé une commission d'environ 15 % sur ces achats par lien externe — un chiffre encore débattu, non tranché. Google a ouvert la facturation externe aux États-Unis, au Royaume-Uni et dans l'EEE le 30 juin 2026, mais continue de prélever des frais de service sur les ventes par lien externe (10 % sur les abonnements, 20 % sur les autres biens numériques). Chez Google, le lien externe vous fait donc économiser les 5 % de frais de facturation, pas la commission entière. Les biens physiques et les services sont en général exemptés de commission dans les deux stores : c'est pourquoi une boutique de produits physiques ne l'a jamais payée.

Le contre-argument honnête : si votre application ne vend rien de numérique, l'argument de la commission s'évapore et la visibilité du store vaut peut-être plus que les frais évités. Ne faites pas une PWA juste pour esquiver des frais que vous n'auriez jamais payés. La validation est aussi plus rapide que sa réputation — Apple traite la plupart des soumissions en une journée —, donc « pas de file d'attente » est un atout, pas un argument en soi.

Ce qu'une PWA ne peut toujours pas faire (surtout sur iOS)

Les écarts se sont beaucoup réduits, et il faut le dire clairement, car « les PWA sont bridées » a vieilli. Les notifications push sont arrivées sur les PWA installées sous iOS 16.4 (mars 2023). Safari 18.4 a apporté Declarative Web Push et Screen Wake Lock. Et sous iOS 26, tout site ajouté à l'écran d'accueil s'ouvre par défaut comme une application autonome, sans habillage du navigateur.

Ce qui n'a pas bougé, c'est le tableau ci-dessous. Si l'un de ces points est sur le chemin critique de votre produit, vous ne choisissez pas entre une bonne et une moins bonne option : vous choisissez entre le natif et un produit plus faible.

Trois points méritent une phrase de plus. Sur iOS, le stockage n'est pas une base de données. WebKit peut effacer les données qu'un site a écrites s'il reste longtemps sans être ouvert : traitez le local comme un cache et gardez la copie de référence sur votre serveur. Tous les navigateurs d'iOS tournent sur WebKit — Chrome et Firefox héritent des règles de Safari —, il n'y a donc aucune concurrence de moteurs pour faire avancer les capacités PWA sur iOS, et c'est pourquoi ce tableau bouge lentement. Enfin, le push sur iOS exige l'installation au préalable, ce qui alourdit discrètement l'enjeu du parcours d'installation : très peu de sites vont jusque-là, et encore moins expliquent comment faire.

Android, à l'inverse, est excellent sur ce terrain : Chrome propose sa propre invite d'installation, le push enrichi fonctionne, les API matérielles sont disponibles, et une Trusted Web Activity permet de publier la même PWA sur Google Play si vous voulez une fiche. Si votre public est majoritairement sur Android, l'argument de la PWA devient bien plus fort.

Portée et rétention sont deux sujets différents

Ici, on quitte la technique — et c'est pourtant souvent ce qui décide.

Sur la portée, la PWA gagne structurellement, et largement. Une PWA est votre site web : chaque page peut être explorée, indexée et classée, et lue par les moteurs de réponse IA, où se règle désormais une part croissante des questions. Une application native n'existe dans rien de tout cela : vous concourez dans la recherche du store, contre tous ceux qui ont payé les mêmes 99 dollars. Si votre croissance repose sur « les gens cherchent le problème que je résous », sur les deux, seule la PWA peut jouer.

Sur la rétention, le natif gagne, et c'est le push qui décide. Une application native envoie du push enrichi sans prérequis, actualise ses données en arrière-plan et vit dans un widget d'écran d'accueil. Une PWA ne peut rien faire de tout cela en arrière-plan sur iOS, et ne pousse qu'après l'installation manuelle. Si votre public est majoritairement sur iPhone et que les notifications sont votre boucle de rétention, ce seul fait tranche.

C'est pourquoi, pour beaucoup d'équipes, la réponse honnête n'est pas de choisir : une PWA pour l'acquisition, une application native pour vos meilleurs clients. La PWA recueille tous ceux qui arrivent d'un résultat de recherche ; le natif s'occupe de ceux qui vous aiment déjà assez pour télécharger quelque chose. Les deux sont de vraies stratégies, et elles partagent un backend.

Pour éviter de citer des chiffres périmés : les grands succès PWA — Twitter Lite, Pinterest, Starbucks — datent de 2017. Prenez-les comme l'histoire qui a prouvé l'idée, pas comme des références à promettre. Le marché, lui, se porte bien : les PWA sont estimées à environ 3,14 milliards de dollars en 2026, avec une croissance proche de 30 % par an.

Comment décider

Oubliez les conseils génériques. Comptez combien de ces points se trouvent sur le chemin critique de votre produit :

• Bluetooth, NFC, USB ou accès approfondi aux capteurs ;
• synchronisation fiable en arrière-plan, géolocalisation en arrière-plan ou toute tâche devant tourner application fermée ;
• widgets d'écran d'accueil ou présence sur l'écran verrouillé ;
• push enrichi ou silencieux comme boucle principale, avec un public majoritairement sur iPhone ;
• être découvert par des gens qui parcourent le store ;
• travail intensif en graphismes : jeux, montage vidéo ou photo, AR.

Deux ou plus : faites du natif. Sur iOS, vous ne contournerez pas cela, et vous livrerez un compromis que vous appellerez un choix de design.

Un ou zéro : la PWA est presque toujours le meilleur premier pari. Une seule base de code, des mises à jour en minutes plutôt qu'un cycle de validation, aucune commission, et un trafic de recherche qui s'accumule au lieu d'être loué à un store. En cas de doute, livrez la PWA d'abord et mesurez : ajouter une application native plus tard coûte moins cher que de découvrir qu'elle était inutile.

Et si votre idée est petite — un compteur, un outil de vérification, un truc de deux minutes à tripoter —, il n'y a pas de débat. Personne ne télécharge une application de 40 Mo pour éclater une bulle une seule fois. C'est exactement là que vit notre propre suite : neuf outils minuscules, installés d'un geste, fonctionnels hors ligne ensuite. L'alternative serait de demander à un inconnu de passer trois minutes dans un store pour trente secondes de jeu. Un lien bat un téléchargement, toujours.

Questions fréquentes

D'autres guides sur le blog VKT.