Ce qui fait d'une PWA une PWA
Le terme Progressive Web App a été inventé par les ingénieurs Google Alex Russell et Frances Berriman en 2015. Une décennie plus tard, le concept est passé d'une expérience de navigateur à une véritable stratégie de production utilisée par des entreprises allant de Twitter (aujourd'hui X Lite) et Pinterest à Starbucks et Uber. Le mot « progressive » fait référence à l'approche en couches : une PWA est une application web en son cœur, et elle améliore progressivement son comportement à mesure que l'environnement du navigateur le prend en charge.
Trois piliers techniques définissent une PWA :
- Service worker. Un fichier JavaScript qui s'exécute dans un thread séparé, agit comme un proxy réseau entre le navigateur et internet, et permet la fonctionnalité hors ligne, la synchronisation en arrière-plan et les notifications push.
- Manifeste d'application web. Un fichier JSON qui indique au navigateur comment présenter l'application lorsqu'elle est installée — son nom, ses icônes, sa couleur de thème, son mode d'affichage et son URL de démarrage.
- HTTPS. Les service workers nécessitent un contexte sécurisé. Chaque PWA de production doit être servie via HTTPS (localhost est exempté pendant le développement).
Si vous décidez encore si une PWA est la bonne architecture pour votre produit, notre article Application web vs native vs PWA : comment choisir en 2026 analyse le compromis complet entre coût, portée et capacités. Ce guide suppose que vous avez pris la décision et souhaitez développer.
Service workers : le moteur sous le capot
Un service worker est l'élément le plus important d'une PWA. Le comprendre en profondeur évite les erreurs de production les plus courantes — caches périmés, délais de mise à jour, fallbacks hors ligne défectueux — qui donnent une mauvaise réputation aux PWA lorsqu'elles sont implémentées sans soin.
Voici comment fonctionne le cycle de vie :
- Inscription. La page principale inscrit le script du service worker :
navigator.serviceWorker.register('/sw.js'). - Installation. L'événement
installse déclenche. C'est ici que vous ouvrez un cache et pré-mettez en cache votre app shell. - Activation. Après l'installation, le nouveau service worker attend que tous les onglets utilisant l'ancienne version soient fermés avant de s'activer. Pendant l'événement
activate, vous supprimez les anciens caches. - Interception des requêtes. Une fois actif, le service worker intercepte chaque requête réseau via l'événement
fetch. C'est là que vivent les stratégies de cache. - Inactivité et arrêt. Le navigateur peut terminer un service worker inactif à tout moment pour économiser de la mémoire. Ne stockez jamais d'état dans des variables globales du service worker — utilisez IndexedDB ou l'API Cache à la place.
Stratégies de cache en pratique
Le gestionnaire fetch du service worker est l'endroit où vous décidez comment chaque type de ressource est servi. Il n'existe pas de meilleure stratégie unique — la bonne approche dépend de la fréquence de changement de la ressource et du niveau de péremption acceptable.
Workbox (de Google) est la bibliothèque de facto pour implémenter ces schémas. Elle gère le précache avec des hachages d'intégrité, le cache à l'exécution avec des plugins d'expiration et la gestion des noms de cache. Sauf raison impérieuse d'écrire manuellement la logique de cache, utilisez Workbox.
Les quatre schémas que vous utiliserez dans presque toutes les PWA :
- Cache-First. Vérifier d'abord le cache ; accéder au réseau uniquement si la ressource n'est pas en cache. Idéal pour les ressources statiques qui changent rarement.
- Network-First. Essayer le réseau ; en cas d'échec, utiliser le cache. Idéal pour les endpoints API où la fraîcheur est critique.
- Stale-While-Revalidate. Servir immédiatement depuis le cache, puis mettre à jour le cache en arrière-plan. Équilibre vitesse et fraîcheur pour les ressources qui se mettent à jour périodiquement.
- Network-Only. Toujours aller sur le réseau ; ne jamais utiliser le cache. Pour les analyses, les paiements, la connexion/déconnexion.
Manifeste d'application web et installabilité
Le Web App Manifest est un fichier JSON qui définit l'apparence et le comportement de votre PWA lorsqu'elle est installée. Les champs clés du manifeste pour 2026 :
id(nouveau en 2023). Un identifiant stable pour l'application. Si vous modifiezstart_url, spécifieridgarantit que le navigateur traite la nouvelle version comme une mise à jour de l'application installée existante.screenshots. Requis pour l'interface d'installation plus riche qu'Android 14 + Chrome 119+ affiche avant l'invite d'installation.- Icônes masquables. Les icônes adaptatives Android sont rognées en cercle, squircle ou autre forme. Sans icône masquable, votre logo apparaîtra avec un remplissage blanc à l'intérieur de la forme.
display: "standalone". L'application installée masque le chrome du navigateur (barre d'adresse) et ressemble à une application native.
Invites d'installation et ajout à l'écran d'accueil
Amener les utilisateurs à installer votre PWA est un événement de conversion comme un autre. L'interface d'installation par défaut du navigateur est facile à manquer. La création d'une invite d'installation personnalisée améliore considérablement les taux d'installation.
Sur Android (Chrome) : le navigateur déclenche l'événement beforeinstallprompt lorsque tous les critères d'installabilité sont remplis. Capturez-le et déclenchez-le lors d'un geste utilisateur. Suivez le taux d'installation comme indicateur produit et testez en A/B le moment de l'invite — la montrer après une action significative de l'utilisateur convertit nettement mieux qu'au premier chargement.
Sur iOS (Safari) : il n'y a pas d'événement beforeinstallprompt. L'utilisateur doit appuyer manuellement sur le bouton Partager puis sur « Ajouter à l'écran d'accueil ». Votre meilleure option est un modal expliquant le geste avec une courte animation.
Développement pour le mode hors ligne
La prise en charge hors ligne est la fonctionnalité qui différencie le plus radicalement une PWA d'une application web standard. Bien faite, elle offre une expérience complète ou dégradée mais utile lorsque l'utilisateur n'a pas de réseau.
Le schéma fondamental est l'app shell : pré-mettre en cache l'ensemble minimal de ressources nécessaires pour rendre le squelette de l'interface et les servir depuis le cache à chaque chargement. Au-delà, trois API alimentent la fonctionnalité hors ligne :
- API Cache. Stockage clé-valeur pour les paires Request/Response. Workbox l'encapsule avec expiration, nettoyage et versionnage.
- IndexedDB. Une base de données complète côté client avec des transactions, des index et des curseurs. Des bibliothèques comme Dexie.js rendent l'API ergonomique.
- API Background Sync. Met en file d'attente les requêtes réseau effectuées hors ligne et les rejoue lorsque la connectivité est rétablie.
Notifications push de bout en bout
Les notifications push sont l'un des outils de ré-engagement les plus puissants disponibles pour une PWA. Le flux technique comporte cinq étapes : (1) demander la permission de notification lors d'un geste utilisateur, (2) s'abonner au service push pour obtenir un objet PushSubscription, (3) envoyer cet abonnement à votre serveur, (4) depuis votre serveur, envoyer un message push au service push via le protocole Web Push, (5) le service worker reçoit un événement push et affiche une notification.
Note iOS : les notifications push pour les PWA sur l'écran d'accueil sont prises en charge à partir d'iOS 16.4. La PWA doit être installée sur l'écran d'accueil — le push ne fonctionne pas pour les PWA s'exécutant dans l'onglet du navigateur sur iOS.
Capacités PWA : iOS vs Android en 2026
La parité de plateforme entre iOS et Android s'est considérablement améliorée au cours des trois dernières années, mais des écarts significatifs subsistent. Ce tableau est précis au milieu de 2026 basé sur WebKit 17.x et Chrome 125 :
| Capacité | Android (Chrome 125+) | iOS (Safari 17.x) |
|---|---|---|
| Ajouter à l'écran d'accueil / invite d'installation | Invite système (beforeinstallprompt) | Manuel — Partager > Ajouter à l'écran d'accueil |
| Mode d'affichage standalone | Prise en charge complète | Prise en charge complète |
| Service workers & cache | Prise en charge complète | Prise en charge complète |
| Notifications push web | Prise en charge complète | PWA installée uniquement (iOS 16.4+) |
| Background Sync | Prise en charge complète | Partielle (sync one-shot uniquement, iOS 13+) |
| Background Fetch | Pris en charge (Chrome 74+) | Non pris en charge |
| Stockage persistant | Pris en charge, accord utilisateur requis | Pris en charge (iOS 15.2+) |
| API Badging | Prise en charge complète | Pris en charge (iOS 16.4+) |
| Web Share API | Prise en charge complète | Prise en charge complète |
| Screen Wake Lock | Prise en charge complète | Non pris en charge |
| Web Bluetooth | Pris en charge (Chrome, pas Firefox) | Non pris en charge |
| Web NFC | Pris en charge (Chrome Android) | Non pris en charge |
| WebAuthn / Passkeys | Prise en charge complète | Prise en charge complète (iOS 16+) |
Quand une PWA est le bon choix
Développez une PWA lorsque :
- Votre principal canal de distribution est la recherche web (SEO) et vous ne souhaitez pas fragmenter la découvrabilité entre une boutique d'applications et une page web.
- Vos utilisateurs sont sur un ensemble diversifié d'appareils et de systèmes d'exploitation.
- Vos besoins hors ligne sont modérés — contenu en cache, soumissions de formulaires en file d'attente, CRUD de base depuis un IndexedDB local.
- Les contraintes budgétaires rendent le maintien de bases de code iOS et Android natives séparées impraticable.
- Vous développez un produit riche en contenu (actualités, documentation, cours, catalogue e-commerce).
Envisagez plutôt le natif ou React Native lorsque :
- Vous avez besoin de Bluetooth, NFC, GPS en arrière-plan continu ou de capacités AR avancées.
- Votre produit est un jeu ou une expérience de streaming audio/vidéo.
- La présence en boutique d'applications est un signal de confiance dans votre marché.
- Vous avez besoin d'une intégration OS profonde : widgets, raccourcis vocaux, extensions de partage.
Consultez notre article Application web vs native vs PWA pour l'analyse complète des coûts et de la portée. Notre service de développement d'applications web inclut les PWA comme résultat de première classe.
Checklist de développement PWA
Utilisez cette checklist avant de déployer une PWA en production :
| Domaine | Point de la checklist | Notes |
|---|---|---|
| HTTPS | Servi en HTTPS partout | Tous les sous-domaines utilisés par l'application |
| Manifeste | Manifeste valide lié dans <head> | Valider avec Lighthouse ou DevTools > Application |
| Manifeste | Icônes à 192px et 512px (any + maskable) | Icône maskable manquante = icône avec remplissage blanc sur Android |
| Service worker | Enregistré et actif | Vérifier DevTools > Application > Service Workers |
| Hors ligne | Page de fallback hors ligne retourne 200 | Tester avec DevTools > Network > mode Hors ligne |
| Installation | Invite d'installation personnalisée sur Android | Capturer beforeinstallprompt ; ne pas se fier à la mini-infobar |
| Installation | Modal/tooltip d'installation iOS | Détecter iOS + non standalone ; afficher le guide du geste Partager |
| Performance | LCP < 2,5s sur 4G (Lighthouse) | App shell depuis le cache devrait être sous 1s en visite répétée |
| Push | Permission demandée uniquement lors d'un geste utilisateur | Jamais au chargement de la page — taux de blocage immédiat |
| Accessibilité | Score d'accessibilité Lighthouse >= 90 | WCAG 2.2 AA — pertinent pour l'EAA (UE) |
| Mise à jour | Cache versionné et vidé à l'activation | Anciens caches supprimés dans l'événement activate ; tester le chemin de mise à jour |
FAQ
Qu'est-ce qu'une Progressive Web App et en quoi diffère-t-elle d'une application web ordinaire ?
Une Progressive Web App est une application web qui utilise des API navigateur modernes — principalement des service workers, le Web App Manifest et la Push API — pour offrir une expérience comparable à une application native. Elle peut fonctionner hors ligne, mettre en cache des ressources pour des chargements quasi instantanés, recevoir des notifications push et être installée sur l'écran d'accueil sans passer par une boutique d'applications.
Les PWA fonctionnent-elles sur iOS en 2026 ?
Oui, avec des nuances. iOS 16.4+ prend en charge Web Push (PWA sur l'écran d'accueil), Background Sync, l'API Badging et le stockage persistant. Cependant, iOS ne dispose pas de Background Fetch, de Bluetooth/NFC complet ni de Screen Wake Lock. Le flux d'installation nécessite un geste manuel — pas d'invite système. Pour la plupart des PWA, la prise en charge iOS est suffisante en 2026.
Quelle stratégie de cache dois-je utiliser pour ma PWA ?
Cache-First pour les ressources statiques qui changent rarement. Network-First pour les API où la fraîcheur est critique. Stale-While-Revalidate pour les pages où un contenu légèrement périmé est acceptable. Workbox de Google automatise ces trois schémas.
Comment déclencher l'invite d'installation sur Android ?
Capturez l'événement beforeinstallprompt (déclenché lorsque les critères d'installabilité sont remplis : HTTPS, manifeste valide, service worker avec gestionnaire fetch) et appelez prompt() lors d'un geste utilisateur. Sur iOS, présentez un modal expliquant le geste Partager > Ajouter à l'écran d'accueil.
Une PWA peut-elle envoyer des notifications push ?
Oui. Demandez la permission, abonnez-vous au service push, envoyez l'abonnement à votre serveur, envoyez un message push depuis votre serveur, et le service worker affiche la notification. Sur iOS, la PWA doit être installée sur l'écran d'accueil (iOS 16.4+).
Quand dois-je créer une PWA plutôt qu'une application native ?
Une PWA est le bon choix lorsque votre canal principal est la recherche web, vos utilisateurs sont sur des appareils divers, vos besoins hors ligne sont modérés et vous n'avez pas besoin de Bluetooth, NFC ou d'une intégration OS profonde. Voir notre comparaison complète sur Application web vs native vs PWA.
Quelle taille peut avoir le cache d'une PWA ?
Chrome accorde environ 60 % de l'espace disque total. Planifiez votre cache avec soin : pré-mettez en cache uniquement les ressources shell (généralement moins de 5 Mo) et mettez en cache les réponses API sélectivement avec des limites d'expiration. Appelez navigator.storage.persist() pour éviter l'éviction sous pression.
Dernière mise à jour le 16 juin 2026. Les détails techniques reflètent les matrices de prise en charge de WebKit 17.x et Chrome 125+ en vigueur à la mi-2026.