Une PWA (Progressive Web App) est un site web qui se comporte comme une application mobile native — installation sur le homescreen, notifications push, fonctionnement offline, accès à la caméra et au microphone. Elle combine la portée du web (URL partagable) avec l'expérience d'une app (performance,沉浸感). Les PWA représentent+68% de visites supplémentaires vs sites mobiles classiques (Google, 2024).
Une PWA repose sur 3 piliers : (1) Service Worker — script qui fonctionne en arrière-plan, interceptant les requêtes réseau et permettant le cache offline, (2) Web App Manifest — fichier JSON qui définit l'apparence de l'app sur le homescreen (icône, nom, theme color), (3) HTTPS obligatoire — les Service Workers ne fonctionnent que sur HTTPS (et localhost). Une PWA bien construite peut être indistinguishable d'une app native sur mobile. Les métriques clés : Time to Install (temps avant la première installation), Engaged Sessions (sessions de +2 min après2 jours).
Une PWA, c'est comme un immigrant qui a la double nationalité. Il peut entrer dans le pays par la porte principale (le web, via URL) — n'importe qui peut le trouver. Mais une fois sur place, il a tous les droits d'un citoyen (l'app native) : il peut s'installer sur le homescreen, envoyer des notifications push, et continuer à travailler même si le réseau coupe (offline). Il n'a pas besoin de passer par l'App Store (magasin d'apps) pour s'installer — vous cliquez sur « Installer » et c'est fait.
Le Service Worker est le cœur technique de la PWA. Il intercepte toutes les requêtes réseau et décide : (1) Cache First — si la ressource est en cache, la servir depuis le cache (idéal pour les assets statiques), (2) Network First — toujours essayer le réseau d'abord, fallback sur le cache (ideal pour les pages dynamiques), (3) Stale-While-Revalidate — servir le cache immédiatement, mettre à jour le cache en arrière-plan (ideal pour les news). Résultat : le site fonctionne100% offline avec le contenu previously visited. La stratégie de cache doit être définie par type de ressource.
Le Web App Manifest (manifest.json) définit comment l'app apparaît sur le homescreen : (1) name — nom affiché sous l'icône, (2) short_name — si le nom est trop long (max 12 caractères), (3) icons — 192×192 et 512×512 (obligatoire pour l'App Store), (4) start_url — l'URL qui se lance quand on clique sur l'icône, (5) display — standalone (pas de browser chrome), (6) theme_color — la couleur de la barre de statut. Une fois le manifest en place, Chrome affiche une bannière « Ajouter à l'écran d'accueil » automatiquement.
Les notifications push web permettent de re-engager les utilisateurs même quand le navigateur est fermé. Mécanisme : (1) Permission — l'utilisateur accepte les notifications, (2) Subscription — le Service Worker génère un endpoint de subscription (Push API), (3) Envoi — vous envoyez une notification via un service (OneSignal, Firebase Cloud Messaging). Les notifications push PWA ont un taux de clic de 12-18% (vs3-5% pour l'email). Cependant, 60% des utilisateurs rejettent la permission à la première demande — il faut demander au bon moment (après une action positive).
Un média d'actualités (800K visites/mois) a transformé son site en PWA. Avant : site mobile lent (LCP 4.2s), aucune rétention après la première visite. Après : (1) Service Worker avec Stale-While-Revalidate pour les articles, (2) Cache des10 derniers articles lus, (3) Manifest avec icône et theme color, (4) Notifications push pour les breaking news. Résultat : LCP -55% (4.2s → 1.9s), install prompt accepté par 31% des visiteurs, notifications push : taux de clic +15%,，重新 engagement rate+42%, sessions par utilisateur +2.3 pages/session.
| Métrique | Valeur |
|---|---|
| Visites supplémentaires PWA | +68% vs site mobile |
| Taux de clic notifications push | 12-18% |
| Acceptation install prompt | 31% (post-interaction) |
| Rejet permission notifications | 60% (première demande) |
| Réduction LCP | -55% (cache offline) |
| Réengagement notifications | +42% (sessions récurrentes) |