PWA : manifest, service worker et installation

Une PWA (Progressive Web App, application web progressive) est un site web qui s'installe sur l'écran d'accueil d'un téléphone et fonctionne comme une application : il s'ouvre en plein écran, sans barre d'adresse, et reste utilisable hors ligne. Il lui faut trois ingrédients : être servi en HTTPS, avoir un manifeste qui décrit l'application, et un service worker, un script qui intercepte les requêtes pour servir des fichiers en cache. Ce chapitre transforme la version web d'AppliFrais, le front React et TypeScript construit avec Vite dans le cours React (build et déploiement), en PWA installable, puis compare cette solution à l'application React Native.

C'est quoi une PWA ?

Une PWA n'est pas une technologie à part : c'est un site web ordinaire, en HTML, CSS et JavaScript, auquel on ajoute deux fichiers. Elle garde tous les avantages du Web (une adresse suffit, aucune compilation, aucun magasin, une mise à jour visible au prochain chargement) et gagne trois capacités d'application :

Le terme a été proposé en 2015 par Alex Russell, ingénieur chez Google, et la designer Frances Berriman. Les éléments techniques, eux, sont des standards du W3C, pris en charge par tous les navigateurs modernes, avec des différences sur iPhone.

Le manifeste

Le manifeste est un fichier JSON qui décrit l'application installée : son nom, ses icônes, sa couleur, la page de démarrage et le mode d'affichage. Dans un projet Vite, il se place dans le dossier public/, qui est servi tel quel :

{
  "name": "AppliFrais – Notes de frais GSB",
  "short_name": "AppliFrais",
  "description": "Saisie et suivi des fiches de frais des visiteurs médicaux",
  "lang": "fr",
  "start_url": "/",
  "scope": "/",
  "display": "standalone",
  "orientation": "portrait",
  "background_color": "#ffffff",
  "theme_color": "#1d4ed8",
  "icons": [
    { "src": "/icones/icone-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icones/icone-512.png", "sizes": "512x512", "type": "image/png" },
    { "src": "/icones/icone-masquable-512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
  ]
}

Le manifeste est déclaré dans le <head> de index.html, avec quelques balises pour iOS :

<link rel="manifest" href="/manifest.webmanifest" />
<meta name="theme-color" content="#1d4ed8" />
<link rel="apple-touch-icon" href="/icones/icone-192.png" />

Le service worker

Un service worker est un script JavaScript que le navigateur exécute à part de la page, en arrière-plan. Il se place entre la page et le réseau : chaque requête de la page (une page, un script, une image, un appel d'API) passe par son événement fetch, et il décide de la réponse : celle du réseau, une copie en cache, ou une page de secours.

Le service worker d'AppliFrais, public/sw.js :

// sw.js — le service worker d'AppliFrais Web
const VERSION = 'applifrais-v3';
const COQUILLE = ['/', '/index.html', '/hors-ligne.html', '/icones/icone-192.png'];

// 1. Installation : on met en cache la coquille de l'application.
self.addEventListener('install', (event) => {
  event.waitUntil(caches.open(VERSION).then((cache) => cache.addAll(COQUILLE)));
});

// 2. Activation : on supprime les caches des versions précédentes.
self.addEventListener('activate', (event) => {
  event.waitUntil(
    caches.keys().then((cles) => Promise.all(cles.filter((cle) => cle !== VERSION).map((cle) => caches.delete(cle)))),
  );
});

// 3. Chaque requête de la page passe par ici.
self.addEventListener('fetch', (event) => {
  const requete = event.request;
  if (requete.method !== 'GET') return; // POST, PUT, DELETE : toujours le réseau
  const url = new URL(requete.url);

  if (url.origin !== self.location.origin) return; // l'API (autre origine) n'est jamais mise en cache

  if (requete.mode === 'navigate') {
    // Les pages : le réseau d'abord, la page hors ligne si le réseau ne répond pas.
    event.respondWith(fetch(requete).catch(() => caches.match('/hors-ligne.html')));
    return;
  }

  // Les fichiers statiques (JS, CSS, images) : le cache d'abord, le réseau sinon.
  event.respondWith(
    caches.match(requete).then(
      (enCache) =>
        enCache ??
        fetch(requete).then((reponse) => {
          if (reponse.ok) {
            const copie = reponse.clone(); // une réponse ne se lit qu'une fois
            caches.open(VERSION).then((cache) => cache.put(requete, copie));
          }
          return reponse;
        }),
    ),
  );
});

Le cycle de vie d'un service worker a trois étapes :

1. install : la première fois, ou quand le fichier sw.js a changé d'un seul octet, le navigateur installe la nouvelle version. On en profite pour mettre en cache la coquille : les fichiers indispensables pour afficher quelque chose sans réseau. event.waitUntil fait attendre le navigateur jusqu'à la fin du remplissage.
2. activate : la nouvelle version prend la main, une fois que plus aucun onglet n'utilise l'ancienne. On supprime alors les caches des versions précédentes : c'est pour cela que le nom du cache contient une version (applifrais-v3), à changer à chaque déploiement.
3. fetch : à chaque requête de la page, le service worker choisit la réponse avec event.respondWith. S'il n'appelle pas respondWith, la requête suit son cours normal, sur le réseau.

L'enregistrement se fait depuis le code de la page, par exemple dans src/main.tsx de l'application React :

if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/sw.js').catch((e) => console.error('Service worker non enregistré', e));
  });
}

Le service worker ne fonctionne qu'en HTTPS (et sur localhost, pour le développement), parce qu'il intercepte tout le trafic de la page : sur une connexion en clair, un intermédiaire pourrait installer le sien. Sa portée est le dossier où il se trouve : placé à la racine, /sw.js contrôle tout le site.

Les stratégies de cache

Chaque type de ressource appelle une stratégie différente :

Avec Vite : vite-plugin-pwa

Écrire le service worker à la main est le meilleur moyen de le comprendre. Dans un vrai projet, le greffon vite-plugin-pwa (version 2) le génère au moment du vite build : il produit le manifeste, la liste exacte des fichiers à mettre en cache avec leurs empreintes, et le code de mise à jour, à partir de la bibliothèque Workbox de Google.

npm install --save-dev vite-plugin-pwa

// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import { VitePWA } from 'vite-plugin-pwa';

export default defineConfig({
  plugins: [
    react(),
    VitePWA({
      registerType: 'autoUpdate',
      manifest: {
        name: 'AppliFrais – Notes de frais GSB',
        short_name: 'AppliFrais',
        lang: 'fr',
        theme_color: '#1d4ed8',
        icons: [
          { src: '/icones/icone-192.png', sizes: '192x192', type: 'image/png' },
          { src: '/icones/icone-512.png', sizes: '512x512', type: 'image/png' },
        ],
      },
    }),
  ],
});

Installer la PWA

Les navigateurs ne proposent l'installation que si le site remplit des conditions : servi en HTTPS, un manifeste avec un nom, des icônes de 192 et 512 pixels, une start_url et un mode d'affichage standalone, fullscreen ou minimal-ui.

Sur Chrome et les navigateurs de la même famille, la page peut proposer son propre bouton « Installer » : elle intercepte l'événement beforeinstallprompt, le garde, et l'utilise au clic. Cet événement n'existe ni dans Safari ni dans Firefox : sur iPhone, il faut expliquer à l'utilisateur le chemin Partager → « Sur l'écran d'accueil ».

Les notifications push dans une PWA

Une PWA peut recevoir des notifications push avec l'API Push du Web : le service worker reçoit un événement push et affiche la notification avec self.registration.showNotification(). Le serveur envoie les messages avec le protocole Web Push, signés par une paire de clés VAPID. Sur iPhone, ces notifications ne fonctionnent que depuis iOS 16.4, et seulement si la PWA a été ajoutée à l'écran d'accueil : un utilisateur qui reste dans Safari ne les reçoit pas. C'est l'une des raisons qui font préférer une application installée quand les notifications sont essentielles.

Tester une PWA

Les outils de développement de Chrome (F12) ont un onglet Application fait pour cela :

• Manifest : affiche le manifeste lu, ses erreurs et l'aperçu des icônes ;
• Service workers : l'état du service worker, le bouton Update, la case Update on reload (recharger la nouvelle version à chaque fois, pratique en développement) et la case Offline, qui simule l'absence de réseau ;
• Cache storage : le contenu de chaque cache ;
• Storage → Clear site data : tout effacer pour repartir de zéro.

Le scénario de test minimal : charge l'application, coche Offline, recharge : la coquille doit s'afficher, et une page non mise en cache doit montrer hors-ligne.html. Puis modifie VERSION, recharge, et vérifie dans Cache storage que l'ancien cache a disparu.

PWA ou application React Native ?

Pour un outil interne simple, utilisé ponctuellement, une PWA est souvent le meilleur rapport effort-résultat : ton application React existante devient installable en une après-midi. Dès qu'il faut des notifications fiables, un stockage sécurisé ou le matériel du téléphone, l'application native l'emporte. Pour l'E6, une PWA ajoutée à ton application web montre une compétence réelle, mais elle reste du code exécuté dans un navigateur : si tu comptes sur elle pour la situation « terminal mobile », vérifie ce point avec ton enseignant.

{
  "short_name": "Frais",
  "start_url": "/",
  "display": "browser",
  "icons": [{ "src": "/icone.png", "sizes": "64x64", "type": "image/png" }]
}