Si vous cherchez une agence PWA, la décision est déjà prise, ou presque. Un article qui vous félicite de ce choix ne sert à rien. Celui-ci décrit ce qu'une Progressive Web App remplace réellement, ce qu'elle ne remplacera pas, ses limites documentées sur iOS, et les cas où le budget serait mieux dépensé ailleurs. Le sujet est saturé de contenus recopiés depuis 2018: prérequis abrogés, chiffres sans source.
Qu'est-ce qu'une PWA remplace réellement ?
Une PWA n'est pas une catégorie de logiciel. C'est un site web auquel on ajoute des éléments optionnels: un manifest, éventuellement un service worker, et la possibilité d'être ajouté à l'écran d'accueil ou au Dock. Le mot « progressive » ne garantit aucun comportement. Une PWA ne fonctionne pas hors ligne par défaut: il faut écrire un service worker et une stratégie de cache, la versionner, la tester. Ce service worker exige un contexte sécurisé, donc HTTPS, avec http://localhost toléré en développement.
Ce qu'elle remplace en pratique:
- une application native qui ne fait qu'afficher du contenu déjà en ligne: catalogue, espace client, suivi de commande;
- un site mobile lent sur réseau instable, à condition d'investir dans le cache;
- un canal de notification, auprès des seuls utilisateurs qui ont installé la web app.
Ce qu'elle ne remplace pas: l'App Store, la synchronisation en arrière-plan sur iOS, et le réflexe d'ouvrir une icône que personne n'a installée.
Que veut dire « installable » du point de vue d'un utilisateur ?
« Installable » n'est pas une propriété du code, c'est un geste que quelqu'un doit accomplir. C'est cette question qui décide du projet.
Sur iOS, personne ne peut déclencher l'installation à votre place
L'événement beforeinstallprompt, qui permet d'afficher un bouton « Installer » maison, n'est pas standard: il vient de la spécification Manifest Incubations du WICG, et MDN le classe en disponibilité limitée, hors Baseline. Il n'existe ni sur Safari ni sur Firefox. Sur iPhone, l'ajout passe obligatoirement par le menu Partager, geste que la majorité des visiteurs ignore. Depuis iOS 16.4, les navigateurs tiers peuvent aussi le proposer; avant iOS 16.3 inclus, c'était réservé à Safari.
Les prérequis, eux, ont disparu. Depuis Safari 26 (iOS 26 et iPadOS 26), WebKit indique qu'il n'y a plus aucune condition d'installabilité et que tout site ajouté à l'écran d'accueil s'ouvre par défaut comme une web app, l'utilisateur pouvant décocher l'option. Le meta tag apple-mobile-web-app-capable et le manifest ne sont plus des conditions d'entrée. Sur macOS, « Add to Dock » fonctionne depuis Safari 17 pour n'importe quel site.
Sur Android et Chromium, les prérequis ne sont plus ceux qu'on lit partout
Chrome, Edge et Samsung Internet demandent un manifest avec name ou short_name, des icônes 192 px et 512 px, un start_url, un display ou display_override, et prefer_related_applications à false ou absent, en HTTPS. Le service worker n'est plus un prérequis d'installation depuis le menu: Chrome a retiré cette obligation en version 108 sur mobile et 112 sur desktop, annonce du 5 décembre 2023. Nuance oubliée partout, "l'algorithme qui declenche l'invitation automatique exige toujours, lui, un handler fetch(): c'est encore ce qu'indique l'annonce Chrome du 5 decembre 2023." Aligner la reponse de la FAQ sur la meme formulation.. Firefox desktop ne permet pas l'installation via manifest; sur Android, tous les navigateurs majeurs la supportent.
Quelles sont les vraies limites d'iOS ?
« Apple ne supporte pas les PWA » est faux, et de plus en plus faux. La contrainte n'est pas le support des API, c'est que presque tout dépend d'une installation manuelle.
Le push existe sur iPhone, mais seulement dans une web app installée
Le Web Push est arrivé sur iOS et iPadOS 16.4, uniquement pour les web apps ajoutées à l'écran d'accueil, jamais depuis un onglet Safari: viser la notification impose d'obtenir d'abord l'installation. La demande de permission doit répondre à une interaction directe, WebKit écrivant « as long as that request is in response to direct user interaction, such as tapping on a 'subscribe' button ». Aucun prompt au chargement. La Badging API suit la même règle depuis iOS 16.4, et depuis iOS 18.4 le Declarative Web Push affiche une notification sans service worker installé.
La session n'est pas partagée avec le navigateur
Apple documente le point depuis la WWDC23: « Home Screen web apps have a standalone, app-like experience on iOS, with separate cookies and storage from the browser. » Un utilisateur connecté dans Safari devra se reconnecter dans la web app, sur le même téléphone. Sur macOS c'est l'inverse: « we copy website cookies when a web app on Mac is added to the Dock ». Une recette menée sur Mac ne verra donc jamais le problème.
Le scope décide de ce qui casse
Les liens du scope s'ouvrent dans la web app; ceux qui en sortent s'ouvrent, sur iOS, dans Safari View Controller. L'impact est direct sur les paiements externes, Stripe Checkout, PayPal, une redirection 3-D Secure, et sur les SSO tiers: l'utilisateur sort visiblement de l'application au pire moment. Le mode display: standalone retire la barre d'URL et l'interface du navigateur, en gardant la barre d'état; minimal-ui conserve retour, avant et rechargement. Retirer la barre d'URL supprime aussi le partage de lien natif et le bouton retour: un coût à assumer, pas un gain gratuit.
Il n'y a pas de synchronisation en arrière-plan
Le Periodic Background Sync suit la même règle, Chrome depuis la version 80. La promesse « le formulaire hors ligne repart tout seul quand le réseau revient » ne tient pas sur iPhone, pas plus que le rafraîchissement en arrière-plan: la file locale ne se vide qu'à la réouverture de l'application.
Le stockage: ce que dit vraiment la politique WebKit
L'ITP supprime tout le stockage écrit par script après 7 jours sans interaction avec le site, IndexedDB, localStorage, sessionStorage, enregistrements et cache des service workers: « ITP deletes all cookies created in JavaScript and all other script-writeable storage after 7 days of no user interaction with the website. » L'exception mérite une ligne dans toute note d'arbitrage: « the first-party domain of home screen web applications is exempt from ITP's 7-day cap on all script-writeable storage ». "C'est ce qui rend l'installation defendable sur iOS quand le produit a besoin d'un etat local durable" - un enonce qui reste un avis mais ne se deguise plus en fait documente., et l'exact inverse de la légende du « iOS efface les données au bout de 7 jours ».
Le plafond de 50 Mo cité partout n'a, lui, aucune source primaire. La politique WebKit s'exprime en pourcentage d'espace disque: jusqu'à 60 % par origine pour une application navigateur, 15 % pour les autres. L'éviction se fait en LRU, sauf page active ou stockage persistant, ce que navigator.storage.persist() permet de demander, supporté par Safari depuis 15.2.
Quels arguments PWA faut-il arrêter de reprendre ?
Le score PWA de Lighthouse n'existe plus
Lighthouse 12.0.0 a supprimé la catégorie PWA, conséquence du changement des critères d'installabilité de Chrome. Corriger aux deux endroits: dans le corps, "Les notes de version du 22 avril 2024 l'annoncent, pour une livraison dans les DevTools de Chrome 126"; dans le TL;DR, "(notes de version du 22 avril 2024)". Une recommandation qui demande de viser 100 sur ce score parle d'un indicateur disparu.
Le cache d'un service worker n'améliore pas le référencement
Le Web Rendering Service de Google ne conserve pas d'état entre les chargements de page: « WRS does not retain state across page loads ». localStorage, sessionStorage et les cookies HTTP sont vides d'un chargement à l'autre: le cache d'un service worker ne sert qu'aux humains déjà venus. Deux réflexes restent utiles: Googlebot refuse les demandes de permission, caméra ou notifications, donc un code qui ne gère pas le refus peut ne rien afficher au crawler; et il cache les ressources très agressivement, d'où le fingerprinting dans le nom de fichier.
Les seuils Core Web Vitals restent un LCP sous 2,5 s, un INP sous 200 ms et un CLS sous 0,1, au 75e percentile des chargements réels, INP ayant remplacé FID en 2024. "Google ecrit que les Core Web Vitals « are used by our ranking systems », tout en precisant que de bons scores ne garantissent aucun positionnement: « there's more to great page experience than Core Web Vitals scores alone ». Aucun poids ni seuil couperet n'est publie." Une PWA ne les améliore pas mécaniquement: une SPA lourde coche toutes les cases du format et rate les seuils.
Les chiffres de conversion cités partout
Les études les plus reprises existent bien, publiées par Google sur web.dev: Twitter Lite, dont la mise à jour du 17 mai 2017 annonce 65 % de pages par session en plus et 600 Ko contre 23,5 Mo pour l'application Android, mais aussi Flipkart, Goibibo, Orange, BookMyShow ou Rakuten 24. Ce qui est vérifiable, c'est que Google a publié ces études. Les chiffres, eux, sont déclarés par les entreprises, datent de 2017 à 2019 et se comparent à des sites mobiles de l'époque sans baseline explicitée: ils décrivent des projets, pas une propriété du format.
Dans quels cas une PWA n'est pas le bon choix ?
Quand le modèle repose sur la notification et que l'audience est sur iPhone
Le push exige l'installation manuelle. Si votre rétention dépend de la capacité à rappeler des utilisateurs qui ne reviennent pas d'eux-mêmes, le premier maillon de la chaîne est un geste que vous ne pouvez ni déclencher ni estimer: "aucune reference publique ne permet de projeter un taux d'installation sur votre audience: les chiffres qui circulent viennent de produits qui n'ont ni votre trafic ni votre parcours".. Une application native, elle, demande la permission au premier lancement, après une installation que l'utilisateur sait faire.
Quand le parcours critique passe par un tunnel externe
Paiement redirigé, 3-D Secure, SSO tiers: chaque sortie du scope bascule dans Safari View Controller sur iOS. C'est réparable, avec un paiement embarqué dans le scope, mais c'est une contrainte d'architecture, pas un détail. Si le prestataire n'est pas négociable, le mode standalone dégrade le parcours au lieu de l'améliorer.
Quand la promesse est « ça marche sans réseau et ça se synchronise seul »
Applications terrain, inventaire, livraison. Ni Background Sync ni Periodic Background Sync n'existent sur iOS: la remontée n'a lieu qu'à la réouverture de l'application. Si le cahier des charges promet une synchronisation autonome, une PWA ne peut pas l'honorer sur iPhone.
Quand la présence sur l'App Store fait partie du besoin
La guideline 4.2 d'Apple est explicite: « Your app should include features, content, and UI that elevate it beyond a repackaged website. » La 4.2.2 ajoute qu'une application ne doit pas être avant tout du matériel marketing, un web clipping ou une collection de liens. Une PWA emballée telle quelle n'est pas distribuable sur l'App Store. Côté Google Play, l'inverse est vrai: la publication passe par une Trusted Web Activity empaquetée avec Bubblewrap, avec manifest complet, fichier Digital Asset Links sur /.well-known/assetlinks.json et livraison en Android App Bundle signé.
Quand personne ne budgète la maintenance du cache
Un service worker est un proxy installé entre vos utilisateurs et votre serveur. Mal versionné, il sert du contenu périmé et rend un correctif urgent difficile à propager. L'argument de la base de code unique est réel, mais il faut lui soustraire le coût du service worker, de l'invalidation de cache et des tests sur deux plateformes inégales. C'est ce raisonnement qu'il faut comparer au natif, pas un ratio de coût inventé.
Quand vos visiteurs viennent d'une recherche et ne reviennent jamais
Un site éditorial ou une landing d'acquisition n'a rien à gagner à l'installation: la couche PWA devient du poids mort, alors que le travail utile porte sur les Core Web Vitals et la vitesse de rendu.
Dans quels cas est-ce le bon choix ?
Le format tient dans quatre situations. Un outil à usage récurrent avec une audience authentifiée, back office, extranet, portail client, commande B2B: le taux d'installation n'y est plus un pari puisque vous pouvez le demander à vos utilisateurs, et l'exemption ITP vous donne un état local durable. Une audience majoritairement Android, où le chemin d'installation est plus fluide et le Play Store reste ouvert. Un produit déjà livré en application web, dont la valeur attendue est la consultation hors ligne et une icône de lancement, pas l'accès aux API système. Enfin une contrainte budgétaire qui rend irréaliste deux bases natives plus une version web, à condition d'aligner les promesses sur ce que le web supporte sur iOS. Reste un risque à inscrire noir sur blanc: Apple a annoncé la suppression des web apps d'écran d'accueil dans l'UE au titre du DMA, avec iOS 17.4, avant de faire marche arrière.
Le travail utile, avant la première ligne de service worker, consiste à trancher trois choses: le périmètre du scope, la stratégie de cache et le parcours d'installation. C'est l'ordre dans lequel nous cadrons un projet de Progressive Web App, parce que ces trois décisions déterminent tout le reste, y compris ce qu'il faudra renoncer à promettre.
Une PWA échappe-t-elle aux obligations d'accessibilité ?
Non, et l'argument « ce n'est qu'un site » ne tient pas. Le RGAA, en version 4.1.2, vise le secteur public, les délégataires d'une mission de service public et les entreprises à partir de 250 millions d'euros de chiffre d'affaires. Son champ couvre les sites internet comme les applications mobiles: une PWA installée y entre quel que soit l'angle retenu.
Ajouter apres la premiere phrase: "Une exception decide de la plupart des cas: les micro-entreprises de moins de 10 salaries dont le chiffre d'affaires annuel ou le total de bilan n'excede pas 2 millions d'euros sont exemptees des obligations applicables aux services, e-commerce compris. Au-dela de ces deux seuils, la boutique est dans le champ." Un site n'y est pas un « produit »: une boutique en ligne existant avant l'entrée en vigueur ne bénéficie pas de l'exemption liée aux produits. Point pratique: le mode standalone retire la barre d'URL, donc des repères de navigation, à remplacer par des contrôles explicites.
Comment trancher en une demi-journée
Cinq questions suffisent:
- La notification est-elle un confort ou la condition de survie du produit ? Si c'est la seconde et que l'audience est iPhone, le débat n'est plus technique.
- Le parcours critique sort-il du scope, pour un paiement ou un SSO ? Testez-le en standalone sur un iPhone réel avant de signer.
- Faut-il écrire des données sans réseau et les remonter sans action de l'utilisateur ? iOS ne le fera pas.
- L'App Store fait-il partie de la distribution attendue ? La guideline 4.2 s'applique, et une Trusted Web Activity ne couvre que Google Play.
- Qui maintient le service worker dans douze mois, avec quelle procédure de purge du cache ?
Une PWA bien cadrée résout un problème précis, sur une audience précise, avec des renoncements écrits noir sur blanc. Vendue comme alternative universelle au natif, elle produit un projet techniquement conforme dont personne ne comprend, six mois plus tard, pourquoi il ne tient pas ses promesses. La différence se joue avant le cadrage, pas dans la qualité du code.