Développement
PWA en 2026 : une vraie alternative aux stores ?
Installation, hors-ligne, notifications : ce qu'une PWA sait faire en 2026, ses limites réelles sur iOS, et les cas où les stores restent imbattables.
Oui, une PWA est une vraie alternative aux stores en 2026, mais pour certains usages seulement. Une Progressive Web App s'installe depuis le navigateur, fonctionne hors-ligne, envoie des notifications (y compris sur iPhone depuis iOS 16.4, avec des conditions), et se déploie sans review ni commission. Elle reste en revanche pénalisée sur iOS (installation cachée, stockage précaire, accès matériel limité) et invisible là où les gens cherchent des apps : sur les stores. La bonne lecture n'est pas « PWA contre native » mais « quel canal de distribution pour quel produit ».
Voici ce qu'une PWA sait réellement faire aujourd'hui, ses limites précises, et la grille de décision honnête.
Une PWA, concrètement
Une PWA est un site web doté de trois superpouvoirs : un manifeste qui le déclare installable (icône, nom, plein écran), un service worker qui lui permet de fonctionner hors-ligne et de recevoir des notifications, et le HTTPS. Installée, elle se comporte comme une app : icône sur l'écran d'accueil, lancement sans barre de navigateur, données locales.
Son argument économique est massif : une seule base de code web couvre Android, iOS, et tous les ordinateurs ; les mises à jour se déploient instantanément, sans review d'Apple ni de Google, sans attendre que les utilisateurs installent quoi que ce soit ; et il n'y a ni commission de 15 à 30 % sur les paiements, ni compte développeur, ni cycle de soumission. Pour un budget donné, une PWA livre plus de produit que deux apps natives.
Ce qu'une PWA sait faire en 2026
L'écart avec les apps natives s'est nettement resserré, surtout côté Android et navigateurs Chromium :
- Installation : sur Android, Chrome propose l'installation de façon visible, et les PWA peuvent même être publiées sur le Play Store (via TWA, Trusted Web Activity). Sur ordinateur, Chrome et Edge installent les PWA comme des applications de bureau.
- Hors-ligne : le service worker met en cache l'app et ses données ; une PWA bien construite se lance et fonctionne sans réseau, avec synchronisation au retour de la connexion.
- Notifications push : totales sur Android et desktop. Sur iOS et iPadOS, disponibles depuis iOS 16.4 (2023), mais uniquement si l'utilisateur a d'abord installé la PWA sur son écran d'accueil, puis accordé la permission. Les badges de notification sur l'icône fonctionnent aussi, dans les mêmes conditions.
- Matériel et capteurs, côté Chromium : caméra, micro, géolocalisation, Bluetooth (Web Bluetooth), USB, NFC sur Android : l'étendue des API web sur Chrome couvre l'essentiel des besoins d'une app métier.
- Paiements : Stripe et consorts fonctionnent nativement dans le web, sans commission de store. C'est l'une des raisons pour lesquelles les grands médias et beaucoup de SaaS poussent leurs abonnements via le web.
Des entreprises majeures assument ce choix depuis des années : les versions « Lite » des grands réseaux sociaux, les outils de commande de restauration, une bonne partie du SaaS B2B vivent très bien en PWA.
Les limites réelles, et elles sont surtout sur iOS
L'honnêteté impose de dire où ça coince, car ça coince toujours au même endroit : Safari et iOS, qui représentent une part majeure des usages en France.
- L'installation est cachée. Sur iPhone, installer une PWA exige d'ouvrir le menu Partager puis « Sur l'écran d'accueil ». Aucune incitation native, pas de bouton « Installer » : la plupart des utilisateurs ignorent que c'est possible. Le taux d'installation s'en ressent massivement, et c'est la limite numéro un en pratique.
- Le stockage est précaire. Safari peut effacer les données locales d'un site (et donc d'une PWA non installée) après des périodes d'inactivité ; le stockage est plafonné. Une PWA iOS ne peut pas promettre « tes données sont là pour toujours » sans un compte et une synchronisation serveur.
- Les notifications restent conditionnelles. Le chemin installation manuelle puis permission fait perdre l'essentiel des utilisateurs en route. Pour un produit dont les notifications sont le cœur (messagerie, alertes), c'est rédhibitoire sur iOS.
- L'accès matériel est restreint. Pas de Web Bluetooth, pas de NFC en écriture, pas d'exécution en arrière-plan digne de ce nom sur iOS. Une app de suivi GPS en continu, de balance connectée ou de badge NFC ne se fera pas en PWA sur iPhone.
- Le précédent de 2024. Apple a tenté de désactiver les PWA installées dans l'Union européenne lors de l'entrée en vigueur du DMA (iOS 17.4), avant de reculer sous la pression. Les PWA fonctionnent, mais l'épisode rappelle que sur iOS, leur sort dépend d'un acteur qui n'a aucun intérêt à les voir prospérer.
- L'absence des stores est aussi une absence de distribution. Pas de fiche App Store, pas de recherche de store, pas de collection « apps du moment ». Pour beaucoup de produits grand public, le store est le premier canal de découverte ; une PWA doit construire toute sa distribution ailleurs (SEO, publicité, bouche-à-oreille).
Le point qui décide à lui seul dans la moitié des cas : les notifications sur iPhone. Si ton produit a besoin que l'utilisateur iOS reçoive des alertes de façon fiable dès le premier jour, sans manipulation d'installation préalable, la PWA n'est pas le bon véhicule. C'est le critère à trancher avant tous les autres.
Les cas où la PWA gagne
- Les outils internes et B2B. Utilisateurs connus, à qui on peut dire « installe-la comme ça » ; pas besoin de store ; mises à jour instantanées pour tout le monde. C'est le terrain roi de la PWA, et le choix par défaut que nous recommandons pour les outils métier.
- Le MVP et la validation d'idée. Tester une demande sans payer le ticket d'entrée des stores (comptes, review, captures, délais) : une PWA se lance en jours et s'itère en continu. Si la traction vient, une app native peut suivre.
- Le contenu et le e-commerce. Lecture, catalogues, réservation, commande : des usages ponctuels où l'installation n'est même pas nécessaire, et où le paiement web sans commission change les marges.
- Les produits à forte audience Android. Marchés et publics où Android domine : la PWA y offre une expérience quasi native, installation visible comprise, voire une présence Play Store via TWA.
- L'abonnement vendu sur le web. Éviter la commission des stores sur un SaaS ou un média : le web est le seul canal où 100 % du prix payé te revient (moins les frais bancaires).
Les cas où les stores restent incontournables
- Les notifications critiques grand public sur iOS, on l'a vu : messagerie, alertes, tout produit dont l'engagement dépend du push.
- L'accès matériel avancé : Bluetooth, NFC, capteurs en arrière-plan, widgets, Apple Watch, HealthKit. Le terrain natif, sans discussion.
- La crédibilité et le réflexe de recherche. Pour le grand public, « ça existe en app ? » signifie « c'est sur le store ? ». Une marque grand public sans app store part avec un déficit de confiance, et renonce au canal de découverte que représente la recherche sur les stores.
- Les achats intégrés et la monétisation par abonnement mobile. Paradoxe assumé : la commission des stores est aussi une machine à convertir. L'achat en deux taps avec le moyen de paiement déjà enregistré convertit mieux qu'un formulaire de carte bancaire web, et pour beaucoup d'apps grand public, ce surcroît de conversion vaut la commission.
- La performance et l'intégration système : jeux exigeants, traitement vidéo, expériences très animées, intégration profonde avec l'OS.
La grille de décision en cinq questions
- Tes utilisateurs iOS ont-ils besoin de notifications fiables dès le premier contact ? Oui : stores. Non : PWA possible.
- As-tu besoin de matériel (Bluetooth, NFC, arrière-plan, montre) ? Oui : stores. Non : PWA possible.
- Peux-tu dire à tes utilisateurs comment installer l'app (outil interne, B2B, communauté) ou dépends-tu de la découverte spontanée ? Découverte spontanée : les stores sont un canal d'acquisition. Utilisateurs captifs : la PWA suffit.
- Ton modèle repose-t-il sur l'abonnement mobile impulsif ? Oui : les achats intégrés des stores convertissent mieux. Vente réfléchie via le web : la PWA garde 100 % du prix.
- Quel est ton budget ? Serré : la PWA livre un produit complet là où le même budget ne paie qu'une app native à moitié finie.
Les deux options ne sont pas exclusives, et la trajectoire la plus maligne est souvent séquentielle : commencer en PWA pour valider le produit à moindre coût, puis, une fois la traction prouvée, porter vers les stores, éventuellement en réutilisant une grande partie du code (une app React Native réutilise la logique d'une base React web, et une TWA met la PWA telle quelle sur le Play Store). On ne choisit pas pour toujours, on choisit pour la phase où on est.
Ce qu'il faut retenir
En 2026, la PWA est une alternative crédible et économique pour les outils internes, le B2B, le contenu, le e-commerce et les MVP : installation, hors-ligne et notifications sont là, et le déploiement sans store ni commission change l'économie d'un projet. Elle reste dominée par les stores dès qu'il faut des notifications iOS fiables, du matériel, ou la découverte spontanée du grand public. Le choix se fait produit par produit, sur cinq questions, et il n'est pas définitif.
Si tu hésites entre PWA et app native pour ton projet, décris-le via notre page devis : on te dira franchement quel véhicule correspond à ton cas, y compris si c'est le moins cher des deux. Et si tu veux apprendre à construire et publier toi-même, du web aux stores, c'est le parcours proposé par Capmedia Academy.
Passe à la pratique
Lire, c'est bien. Construire, c'est mieux.
Tout ce qu'on explique ici s'apprend en faisant, sur Capmedia Academy : le parcours complet pour créer et publier ta première application, en français, et les trois premières formations sont offertes.