Progressive web app : ce qu'elle change vraiment

Une progressive web app est un site web qui s’installe sur l’écran d’accueil, se lance en plein écran et reste consultable sans réseau. Trois briques la rendent possible : un manifeste, un service worker et une connexion HTTPS. Aucun store, aucune commission, une seule base de code à maintenir.

Ce qui sépare une PWA d’un site mobile classique

Un site responsive s’adapte à la taille de l’écran. Une progressive web app va plus loin : elle ajoute des capacités habituellement réservées aux logiciels installés, sans jamais quitter le navigateur.

Le mot progressive renvoie à l’amélioration progressive, un principe de conception ancien du web. Le même code sert un vieil Android d’entrée de gamme et un iPhone récent : chaque appareil reçoit ce qu’il sait exécuter, personne ne tombe sur une page cassée. Un navigateur qui ignore les service workers affiche le site normalement, simplement privé du cache hors ligne.

Le terme a été forgé en 2015 par la designer Frances Berriman et Alex Russell, ingénieur sur Google Chrome. La documentation MDN de Mozilla décrit ces applications comme des sites combinant service workers, manifeste et amélioration progressive pour offrir une expérience proche des applications natives.

Trois différences se voient tout de suite côté utilisateur. L’icône prend place sur l’écran d’accueil au même rang que les autres applications. Le lancement se fait en plein écran, barre d’adresse masquée. Le contenu déjà consulté reste affichable quand le réseau tombe dans un tunnel ou un ascenseur.

Les trois briques techniques à mettre en place

Aucune magie derrière une PWA. Trois éléments suffisent à transformer un site existant, et le chantier se compte en jours quand la base technique est saine.

Le manifeste, la carte d’identité de l’application

Le manifeste web est un fichier JSON déclaré dans l’en-tête de vos pages. Il décrit le comportement de l’application une fois installée. Sa spécification, Web Application Manifest, est publiée par le Web Applications Working Group du W3C.

Les champs qui comptent réellement :

• name et short_name : le libellé complet et celui affiché sous l’icône
• icons : au minimum une icône carrée de 512 pixels, plus les tailles intermédiaires
• start_url : la page ouverte au lancement, souvent différente de la page d’accueil publique
• display : la valeur standalone masque l’interface du navigateur
• theme_color et background_color : couleur de la barre système et de l’écran de démarrage

Le service worker, un proxy entre le site et le réseau

Un service worker est un script JavaScript exécuté dans un fil séparé, à côté de la page. Il intercepte les requêtes réseau et décide de servir une réponse depuis le cache, depuis le serveur, ou de combiner les deux. Sa spécification a été reprise par le Web Applications Working Group du W3C après la fermeture du groupe de travail dédié, en mars 2025.

C’est cette brique qui rend le mode hors ligne possible. Elle sert aussi de socle aux notifications push et à la synchronisation en arrière-plan sur Android.

HTTPS, la condition d’accès

Un service worker ne s’enregistre que sur une origine sécurisée. HTTPS reste donc obligatoire en production, avec une tolérance pour localhost pendant le développement. La contrainte n’a rien d’administratif : un service worker voit passer tout le trafic d’un domaine, et une interception réseau suffirait à détourner l’application entière. Les réflexes de cybersécurité pour protéger les données valent pour le reste de la chaîne.

Installer une progressive web app depuis le navigateur

L’installation ne passe par aucun store. Le parcours diffère nettement entre Android et iOS, et cet écart explique la majorité des déceptions constatées sur les taux d’installation.

Sur Chrome, le navigateur détecte les critères d’installabilité et propose l’ajout à l’écran d’accueil. Google a assoupli ces critères : l’obligation de fournir un service worker doté d’un gestionnaire fetch() a été retirée sur mobile dans Chrome 108, en 2022, puis sur ordinateur dans Chrome 112, en 2023. Le blog Chrome for Developers en donne le motif : des développeurs ajoutaient un gestionnaire vide pour cocher la case, au détriment des performances.

L’événement beforeinstallprompt vous rend la main sur le moment de la proposition. Une invitation déclenchée après une action réussie, un article lu ou un panier constitué, convertit mieux qu’une bannière affichée dès la première seconde. Cet arbitrage relève du design d’expérience autant que de la technique.

Sur iPhone, le parcours restait manuel : bouton Partager, puis « Sur l’écran d’accueil ». Apple a rebattu les cartes avec Safari 26, présenté sur le blog WebKit en septembre 2025. Tout site ajouté à l’écran d’accueil s’ouvre désormais comme une application web par défaut, et l’utilisateur dispose d’un réglage « Ouvrir comme application web » au moment de l’ajout. WebKit résume la nouvelle règle sans détour : il n’existe plus aucune exigence d’installabilité dans Safari. Le manifeste conserve son utilité, il n’a plus valeur de condition.

Notifications push : ce qui fonctionne, et depuis quand

Le rattrapage d’Apple sur les notifications push date de 2023. WebKit a publié en février 2023 l’annonce de la prise en charge du Web Push pour les applications web sur iOS et iPadOS 16.4. Deux conditions accompagnent cette ouverture : l’application doit avoir été ajoutée à l’écran d’accueil, et son manifeste doit déclarer display en standalone ou fullscreen.

La demande d’autorisation obéit à une règle stricte, rappelée par WebKit : elle doit répondre à une interaction directe de l’utilisateur, un appui sur un bouton d’abonnement par exemple. Une demande déclenchée au chargement de la page est ignorée. Le même palier a introduit l’API Badging, qui affiche une pastille de compteur sur l’icône de l’application.

Sur Android, aucune de ces restrictions. La notification fonctionne dans le navigateur comme dans l’application installée, toujours via le service worker.

Trois erreurs reviennent dans les projets qui plafonnent :

• solliciter l’autorisation avant que l’utilisateur ait perçu la valeur du service
• envoyer des messages commerciaux sur un canal ouvert pour du transactionnel
• oublier que l’utilisateur iOS installe d’abord, ce qui ajoute une étape au tunnel

Ce que la PWA gagne face à une application native

Les études publiées par Google sur web.dev mesurent l’écart entre visiteurs classiques et utilisateurs d’une PWA installée, pas le simple passage au responsive. La nuance change tout dans la lecture des chiffres.

Rakuten 24, enseigne japonaise de produits du quotidien, a mesuré sur un mois un bond de 450 % du taux de rétention des visiteurs, une hausse de 200 % du taux de conversion et de 150 % des ventes par client. L’étude, publiée en novembre 2020, précise que la comparaison porte sur les utilisateurs ayant installé la PWA face aux visiteurs web qui ne l’ont pas fait.

Le poids explique une part de l’écart. La PWA du marchand indonésien Blibli pèse moins de 1 Mo, soit 24 fois moins que son application Android, d’après l’étude de cas publiée sur web.dev en juin 2021. Twitter Lite, dossier plus ancien documenté en 2017, chargeait 600 Ko de données contre 23,5 Mo pour l’installation Android correspondante.

Le reste tient à l’économie du projet :

• une seule base de code au lieu de deux, ce qui pèse directement sur le prix de création d’une application
• zéro commission de store sur les transactions réalisées dans l’application
• zéro cycle de validation Apple ou Google avant chaque mise à jour
• des pages indexables par les moteurs de recherche, contrairement au contenu enfermé dans une application native

Les limites qui disqualifient la PWA

Une PWA ne remplace pas tout. Les frontières se situent moins dans le rendu visuel que dans l’accès au matériel et dans la durée de vie des données locales.

L’accès aux capteurs reste partiel sur iOS. Bluetooth, NFC, USB et la plupart des capteurs avancés ne sont pas exposés aux applications web sous WebKit, là où Chrome sur Android en ouvre une partie. Un projet de paiement sans contact ou de pilotage d’objet connecté bute donc sur ce mur.

Le stockage local, lui, reste révocable. Les données mises en cache par un service worker vivent dans un quota de stockage administré par le navigateur, qui purge les origines les moins visitées quand l’espace manque. Une application censée garantir des semaines de données consultables sur un chantier hors réseau sécurise mal cette promesse.

Trois autres cas appellent le natif sans discussion :

• les jeux et les interfaces graphiquement lourdes, où chaque image par seconde compte
• les traitements de fond continus, suivi GPS d’un trajet ou synchronisation programmée
• la distribution par les stores quand la découverte organique constitue le canal d’acquisition principal

Le cadre réglementaire ajoute une part d’incertitude. En février 2024, Apple avait annoncé la suppression des applications web sur l’écran d’accueil dans l’Union européenne, au nom de sa mise en conformité avec le Digital Markets Act, avant de renoncer début mars 2024 et de maintenir la fonctionnalité dans iOS 17.4. L’épisode a rappelé qu’une brique du web ouvert dépend aussi des décisions des éditeurs de navigateurs.

Trancher entre PWA et natif sans se tromper

La question ne se règle pas par préférence technique. Cinq points suffisent à décider, à condition de les traiter dans cet ordre.

1. Listez les fonctions matérielles réellement mobilisées par votre produit, pas celles imaginées pour plus tard.
2. Vérifiez la part d’iPhone dans votre audience : les limites de WebKit pèsent proportionnellement à cette part.
3. Estimez la valeur du canal store dans votre acquisition, nulle pour un service B2B, décisive pour un produit grand public.
4. Mesurez le budget disponible sur trois ans, maintenance comprise, pas seulement le coût de la première version.
5. Testez l’appétence à l’installation sur un échantillon d’utilisateurs avant de généraliser.

La stratégie mixte reste fréquente sur le terrain : la PWA sert de premier palier, elle valide l’usage et l’audience, le natif prend le relais sur les fonctions qui l’exigent. Le comparatif des trois familles techniques, natif, hybride et PWA, aide à situer votre projet avant l’arbitrage budgétaire.

Une PWA hérite aussi des obligations du web. Contraste, navigation clavier, alternatives textuelles, libellés de champs : les critères d’accessibilité s’appliquent intégralement, et les traiter après la livraison coûte plusieurs fois le prix.

Prochaine étape : ouvrez l’onglet Application des outils de développement de votre navigateur sur le site actuel, vérifiez la présence du manifeste et du service worker, puis mesurez le temps d’affichage sur un mobile en réseau dégradé. Ce diagnostic prend deux heures et tranche une question de fond : construire la PWA sur l’existant ou repartir d’une base neuve, décision à poser au moment de valider l’idée de produit.