Progressive Web App (PWA) : ce qu'elle peut faire pour une entreprise en 2026

Avant de lancer deux applications natives, une pour iOS et une pour Android, une question mérite d'être posée : une Progressive Web App suffirait-elle ? Une PWA est un site web qui s'installe sur l'écran d'accueil, fonctionne hors connexion et peut envoyer des notifications. Cet article explique ce que c'est, ce qu'elle permet réellement en 2026, ce qu'elle ne permet pas, et comment décider. Il a été publié le 21 février 2026 et revu le 17 octobre 2026 : les chiffres qu'aucune source ne permettait de vérifier ont été retirés, et le support d'Apple est mis à jour.

Qu'est-ce qu'une Progressive Web App

Une Progressive Web App est un site web qui se comporte comme une application : on l'ouvre depuis un navigateur, mais on peut aussi l'installer sur l'écran d'accueil d'un téléphone ou d'un ordinateur, où elle s'ouvre dans sa propre fenêtre. « Progressive » signifie que l'expérience s'adapte : sur un navigateur ancien, c'est un site classique ; sur un navigateur récent, les fonctions avancées s'activent.

Techniquement, une PWA repose sur trois briques, décrites par la documentation de référence de web.dev et de MDN :

• Un service worker, un script qui tourne en arrière-plan et gère le cache, le fonctionnement hors connexion et la réception des notifications.
• Un manifeste d'application, un fichier JSON qui décrit l'application pour son installation : nom, icônes, couleurs, mode d'affichage.
• Le HTTPS, obligatoire pour que le navigateur accepte le service worker.

Pas de kit de développement propriétaire, pas de langage spécifique, pas de passage obligatoire par un store.

Ce que les PWA ont prouvé : deux cas documentés

Les chiffres qui circulent sur les PWA sont souvent anciens et rarement sourcés. Deux études de cas, publiées par les équipes elles-mêmes, tiennent la route :

• Twitter Lite, devenue l'expérience mobile web par défaut de Twitter en avril 2017 : 65 % de pages par session en plus, 75 % de tweets envoyés en plus, 20 % de rebond en moins, pour une application de 600 Ko sur le réseau, contre 23,5 Mo à télécharger pour installer l'application Android native (web.dev, mise à jour du 17 mai 2017).
• Pinterest, qui a reconstruit son site mobile en environ trois mois : l'ancien site mettait 23 secondes à devenir interactif ; avec la PWA, le temps passé a augmenté de 40 %, les revenus publicitaires générés par les utilisateurs de 44 % et les interactions principales de 60 % (étude de cas d'Addy Osmani, 2017).

Ces deux cas datent de 2017 et concernent des services à très fort trafic mobile. Ils montrent ce qu'une PWA rapide peut changer, pas ce qu'elle changera pour une PME : leurs résultats viennent d'un site mobile beaucoup plus léger que celui qu'il remplaçait.

PWA ou application native : le comparatif honnête

Un seul code au lieu de deux. Une application native demande en général deux développements, iOS et Android. Une PWA est une seule base de code qui fonctionne sur téléphone, tablette et ordinateur.

Les mises à jour. Une application native passe par la validation de l'App Store et du Play Store, puis par la mise à jour sur chaque téléphone. Une PWA se met à jour comme un site : la nouvelle version est servie au prochain chargement.

L'accès. Une PWA s'ouvre par une simple adresse : un lien, un QR code, un résultat de recherche. Pas d'installation préalable, et chaque page peut être indexée par les moteurs de recherche, ce qu'une application native ne permet pas.

Où le natif garde l'avantage. Les jeux 3D exigeants, les applications qui ont besoin d'un accès poussé au matériel (Bluetooth avancé, NFC, réalité augmentée), celles qui doivent tourner en continu en arrière-plan, et celles dont la présence dans les stores est un canal d'acquisition en soi.

Le point qui a longtemps bloqué : iPhone et iPad

Pendant des années, l'objection principale aux PWA était Apple. Elle a beaucoup reculé :

• Notifications : depuis iOS et iPadOS 16.4, en 2023, une web app ajoutée à l'écran d'accueil peut demander l'autorisation d'envoyer des notifications push, à condition que la demande suive une action directe de l'utilisateur, comme un bouton « S'abonner ». Les notifications apparaissent sur l'écran verrouillé, dans le centre de notifications et sur l'Apple Watch (WebKit, février 2023). Un site ouvert dans Safari, sans installation, ne peut pas le faire.
• Union européenne : en février 2024, Apple a d'abord retiré les web apps d'écran d'accueil dans les versions bêta d'iOS 17.4 pour l'Union européenne, avant de revenir sur sa décision et de les maintenir, construites sur WebKit (Engadget, mars 2024). L'épisode rappelle qu'Apple garde la main sur ce que les web apps peuvent faire sur ses appareils.

Sur iPhone, l'installation reste manuelle : il faut passer par le menu de partage puis « Sur l'écran d'accueil ». Sur Android et sur les navigateurs Chromium pour ordinateur, le navigateur peut proposer l'installation lui-même.

Des usages pertinents pour une entreprise

• Le commerce en ligne : un catalogue rapide sur mobile, consultable même avec une connexion faible, avec des notifications pour les clients qui les ont acceptées.
• La restauration et les lieux d'accueil : une carte et une commande accessibles par QR code, sans application à télécharger.
• Les outils métier : suivi de chantier, portail client, prise de commande pour une équipe terrain, qui doivent fonctionner hors réseau et se synchroniser au retour de la connexion.
• L'événementiel : programme, plan, notifications pendant l'événement, pour un public qui ne téléchargera pas une application pour deux jours.

Les points techniques à maîtriser

La stratégie de cache. Quelles ressources mettre en cache, pour combien de temps, et comment servir une nouvelle version sans laisser l'utilisateur sur l'ancienne : c'est la partie la plus délicate. Un service worker mal configuré peut servir indéfiniment une version périmée du site. Les stratégies classiques sont « cache d'abord » pour les fichiers statiques et « réseau d'abord » pour les données qui changent.

Les notifications. C'est un atout, et un risque : trop de notifications, et l'utilisateur coupe tout. Ne demandez l'autorisation qu'après une action qui la justifie, ce qu'iOS impose de toute façon.

La performance. Une PWA lente déçoit davantage qu'un site lent, parce qu'elle promet l'expérience d'une application. Google publie des seuils pour les Core Web Vitals : un LCP sous 2,5 secondes, un INP sous 200 millisecondes et un CLS sous 0,1 pour au moins 75 % des visites (web.dev). Ce sont de bons objectifs de départ ; notre article sur la vitesse de chargement détaille les optimisations qui permettent de les atteindre.

Comment décider, et par où commencer

1. Listez les parcours indispensables : lesquels doivent marcher hors connexion, lesquels justifient une notification.
2. Vérifiez les besoins matériels : si un parcours exige du Bluetooth avancé, du NFC ou un fonctionnement continu en arrière-plan, le natif s'impose pour ce parcours.
3. Commencez petit : un manifeste, un service worker qui met en cache l'essentiel, une page hors connexion. Les frameworks courants (Next.js, Nuxt, Angular, ou une bibliothèque comme Workbox) simplifient cette couche.
4. Testez sur de vrais appareils, iPhone compris, et dans de mauvaises conditions réseau.
5. Mesurez : installations, visiteurs qui reviennent, conversions, Core Web Vitals mesurés sur le terrain.

Pour beaucoup de projets, la réponse n'est pas « PWA ou natif » mais « PWA d'abord » : un seul code, servi à tout le monde, et une application native plus tard, seulement pour les parcours qui l'exigent vraiment.