Les Progressive Web App (PWA)

Tu as sûrement déjà vu ce petit encart “Ajouter à l’écran d’accueil” en visitant un site sur mobile. Derrière, il y a souvent une Progressive Web App : un site web qui adopte les codes d’une application native, installation sur l’écran d’accueil, fonctionnement hors ligne, notifications push, sans passer par un store, sans validation, avec un seul code pour toutes les plateformes.

Ce site (justement construit avec Astro, voir Comment créer son propre blog personnel avec Astro) n’est pas une PWA, mais les mêmes briques web modernes s’appliquent dès qu’on veut aller plus loin.

Qu’est-ce qu’une PWA

Une PWA repose sur trois piliers techniques :

Le HTTPS, obligatoire pour activer les fonctionnalités avancées du navigateur
Le Service Worker, un script qui tourne en arrière-plan et intercepte les requêtes réseau
Le Web App Manifest, un fichier JSON qui décrit l’application (nom, icônes, couleurs, écran de démarrage)

Combinés, ces trois éléments permettent à un navigateur de proposer l’installation du site comme une vraie application, avec sa propre icône et sa propre fenêtre, sans passer par un store.

Pour aller plus loin : Que sont les progressive web apps ? et les critères d’installabilité des progressive web apps.

Service Worker : le coeur du fonctionnement offline

Le Service Worker s’installe une première fois puis reste actif indépendamment de l’onglet ouvert. Il se place entre l’application et le réseau et peut :

Mettre en cache les ressources statiques (HTML, CSS, JS, images)
Répondre à une requête directement depuis le cache si le réseau est indisponible
Synchroniser des données en arrière-plan une fois la connexion revenue

Les stratégies de cache les plus courantes sont Cache First (on sert le cache, on ne va sur le réseau qu’en cas d’absence), Network First (on tente le réseau, on retombe sur le cache en cas d’échec) et Stale While Revalidate (on sert le cache immédiatement tout en le rafraîchissant en tâche de fond).

Pour aller plus loin : Mise en cache du service worker et mise en cache HTTP.

Le manifest.json et l’installation sur l’écran d’accueil

Le fichier manifest.json déclare les métadonnées de l’application :

name et short_name
icons (plusieurs tailles, dont au moins une en 512x512 pour les stores Android)
start_url, display (standalone pour masquer la barre d’adresse)
theme_color et background_color

{
  "name": "Mon Super Site",
  "short_name": "MonSite",
  "start_url": "/",
  "display": "standalone",
  "theme_color": "#111111",
  "background_color": "#ffffff",
  "icons": [
    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

C’est ce fichier, combiné au Service Worker, qui déclenche l’invite d’installation (le fameux “Add to Home Screen”) sur Chrome et la plupart des navigateurs Android.

Exemple d'invite d'installation d'une PWA sur Android

Pour aller plus loin : Ajouter un fichier manifeste d’application Web.

Pour générer manifest, icônes et Service Worker sans tout écrire à la main, PWABuilder est un outil pratique : il analyse un site existant, pointe les manquants et génère les packages pour les stores (Android, iOS, Windows).

Notifications push et engagement utilisateur

Les notifications push reposent sur la Push API et le Service Worker : le navigateur reçoit un message même quand l’application n’est pas ouverte, et le Service Worker se charge de l’afficher. Cela suppose :

Une demande de permission explicite à l’utilisateur
Un serveur capable d’envoyer des messages via les services de push du navigateur
Un contenu utile et rare, sous peine de désactivation par l’utilisateur

const button = document.getElementById("notifications");
button.addEventListener("click", () => {
  Notification.requestPermission().then((result) => {
    if (result === "granted") {
      randomNotification();
    }
  });
});

Pour aller plus loin : Re-engageable Notifications and Push.

Avantages : performance, coût, portée

Performance : les ressources en cache se chargent quasi instantanément, y compris en réseau dégradé
Coût : un seul projet à maintenir, pas de frais de publication sur les stores
Portée : accessible depuis un simple lien, indexable par les moteurs de recherche, installable sans friction

Limites et pièges (support iOS, stockage, le piège du cache)

Support iOS/Safari : historiquement en retard sur les notifications push et certaines API, à vérifier au cas par cas selon la version d’iOS ciblée
Stockage : le cache et l’IndexedDB restent soumis aux quotas du navigateur, qui peut purger les données les moins utilisées
Le piège du cache : une stratégie Cache First mal maîtrisée peut servir une version obsolète du site pendant des jours si le Service Worker n’est jamais mis à jour. Il faut prévoir une stratégie de versionning du cache (changement du nom de cache à chaque déploiement) et un mécanisme de purge des anciennes versions, sans quoi les utilisateurs restent bloqués sur une ancienne build sans le savoir

Pour aller plus loin : Mise en cache.

Exemple concret : TOPLA en PWA

TOPLA est une PWA utilitaire pour jeux de société, qui applique concrètement les points précédents (manifest, cache, installation).

Captures d'écrans de l'application TOPLA

Conclusion : quand choisir une PWA plutôt qu’une app native

La PWA est pertinente quand l’objectif est la portée et la rapidité de mise en marché : un seul code, pas de store, une installation en un clic. L’app native reste préférable quand le produit dépend fortement d’API matérielles poussées (Bluetooth avancé, capteurs spécifiques) ou d’une présence obligatoire sur les stores pour la visibilité.