Featured image of post Potentiel et implémentation des PWA (Progressive Web Apps) : Le pouvoir du Service Worker
Frontend Web

Potentiel et implémentation des PWA (Progressive Web Apps) : Le pouvoir du Service Worker

Explication complète des PWA, allant du cycle de vie du Service Worker au cache hors ligne et aux notifications push.

1. Introduction : Qu’est-ce qu’une PWA ?

Les technologies web ont connu une évolution spectaculaire au cours des dernières décennies. En partant d’une simple collection de liens de documents HTML statiques, en passant par la manipulation dynamique du DOM, la communication asynchrone via Ajax, et l’avènement des SPA (Single Page Application), il est désormais possible de construire des applications offrant une expérience utilisateur (UX) qui rivalise, voire surpasse, celle des applications natives. À la pointe de cette évolution se trouvent les PWA (Progressive Web Apps).

Une PWA est, en bref, “une application web qui combine l’accessibilité du Web avec les performances et l’UX élevés d’une application native”. Avec les applications web traditionnelles, il était normal de voir un écran d’erreur indiquant “Vous n’êtes pas connecté à Internet” (le fameux jeu du dinosaure sur Chrome) lorsqu’on y accédait hors ligne. Cependant, si la technologie PWA est correctement implémentée, il devient possible de lancer l’application même hors ligne, de consulter du contenu mis en cache et de synchroniser des données en arrière-plan.

Cet article explique en détail et de manière exhaustive l’ensemble du concept des PWA, depuis le cycle de vie de leur cœur, le Service Worker, jusqu’aux stratégies de cache avancées, l’intégration avec IndexedDB et les perspectives d’avenir.

2. Application native vs PWA

Lors du développement d’une application web, la question “Faut-il adopter une application native ou une PWA ?” est toujours au centre des débats. Comprendre en profondeur les avantages et les inconvénients de chacune permet de faire le meilleur choix technologique pour votre projet.

2.1. Forces et faiblesses des applications natives

La plus grande force des applications natives (applications développées en Swift/Objective-C pour iOS, Kotlin/Java pour Android, etc.) est d’avoir un accès complet aux API du système d’exploitation. Cela permet d’implémenter des fonctionnalités avancées exploitant pleinement l’appareil photo, le GPS, le Bluetooth, le NFC, divers capteurs, etc. De plus, étant optimisées pour le système d’exploitation, les performances de rendu sont très élevées, ce qui donne un avantage considérable aux applications natives pour les jeux nécessitant de nombreuses animations complexes ou des graphismes 3D.

D’un autre côté, les applications natives présentent des faiblesses (défis) majeures, telles que :

  • Coûts de développement et d’apprentissage : Il est nécessaire de maintenir des bases de code séparées pour iOS et Android (cela peut être atténué par des frameworks multiplateformes comme React Native ou Flutter, mais ce n’est jamais complètement réduit à zéro).
  • Examen sur les magasins d’applications : L’application ne peut être publiée sans passer par l’examen de l’App Store d’Apple ou de Google Play, et des délais d’attente de plusieurs jours peuvent survenir lors des mises à jour.
  • Barrières à l’acquisition d’utilisateurs : Le processus d’ouverture du magasin d’applications, de recherche, de téléchargement et d’installation est un obstacle important (friction) pour l’utilisateur.

2.2. Les problèmes résolus par les PWA

Les PWA visent à surmonter les faiblesses des applications natives tout en tirant parti des atouts du Web.

  • Une source, usages multiples : Une base de code unique développée avec les technologies web standards (HTML, CSS, JavaScript) fonctionne sur tous les appareils équipés d’un navigateur (mobile, tablette, bureau).
  • Mises à jour immédiates sans examen : Étant donné qu’une PWA est un simple site web, elle n’a pas besoin de passer par l’examen d’un magasin d’applications. Les utilisateurs peuvent toujours utiliser la dernière version simplement en mettant à jour les fichiers sur le serveur.
  • Expérience fluide sans installation : L’utilisateur peut commencer à utiliser l’application simplement en accédant à une URL. S’il l’apprécie, il peut l’ajouter à l’écran d’accueil (“Installer”) pour la lancer depuis une icône d’application, comme une application native.
  • Partageabilité via des liens : Pouvoir partager un écran ou un état spécifique via une URL est une arme puissante propre au Web.

Bien sûr, les PWA ont aussi leurs limites. En particulier dans l’environnement iOS (Safari), l’implémentation des API Web a souvent été retardée en raison des politiques d’Apple, le support des notifications Push était insuffisant jusqu’à récemment, et il y a des restrictions strictes sur le fonctionnement en arrière-plan. Cependant, ces dernières années, Safari a également renforcé son support des PWA, et cet écart se réduit progressivement.

3. Les 3 piliers d’une PWA

Pour réaliser une PWA, les trois éléments technologiques principaux suivants sont nécessaires.

3.1. HTTPS (Communication sécurisée)

Les fonctionnalités puissantes d’une PWA (Service Worker, notifications Push, Géolocalisation, etc.) ne fonctionnent que dans un environnement HTTPS pour des raisons de sécurité (l’environnement de développement local localhost est autorisé en tant qu’exception). C’est pour éviter que ces fonctionnalités ne soient altérées ou abusées par des tiers malveillants via des attaques de type homme du milieu (man-in-the-middle).

3.2. Web App Manifest

Le Web App Manifest (manifest.json) est un fichier JSON qui fournit au navigateur des métadonnées sur l’application web. Il permet de définir l’icône de l’application, le nom, la couleur de thème, le mode d’affichage, etc., et contrôle son apparence semblable à celle d’une application native lorsqu’elle est installée sur un appareil.

3.3. Service Worker

Le Service Worker est la baguette magique qui élève une PWA du statut de simple site web à celui “d’application”. C’est un environnement JavaScript exécuté par le navigateur en arrière-plan, qui fonctionne sur un thread distinct de la page web. Il peut intercepter (proxifier) les requêtes réseau, gérer le cache et recevoir des notifications Push.

4. Paramètres détaillés du Web App Manifest

Le Web App Manifest est le fichier de configuration qui représente le visage de la PWA. Il détermine l’apparence et le comportement lorsque l’utilisateur installe l’application.

Voici un exemple de configuration courante de manifest.json.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
  "name": "Progressive Web App Example",
  "short_name": "PWA Example",
  "description": "A comprehensive example of a Progressive Web App.",
  "start_url": "/?source=pwa",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0055ff",
  "icons": [
    {
      "src": "/images/icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png",
      "purpose": "any maskable"
    },
    {
      "src": "/images/icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "orientation": "portrait",
  "scope": "/"
}

Explication des principales propriétés

  • name et short_name : Les noms affichés dans l’invite d’installation et sous l’icône de l’application sur l’écran d’accueil. L’écran d’accueil ayant un espace limité, short_name est utilisé en priorité.
  • start_url : L’URL chargée en premier lorsque l’utilisateur lance l’application depuis l’icône de l’écran d’accueil. En ajoutant un paramètre de suivi (ex. ?source=pwa), il est possible d’identifier les accès depuis la PWA dans les outils d’analyse web.
  • display : Spécifie le mode d’affichage de l’application.
    • standalone : Masque complètement l’interface utilisateur du navigateur (barre d’URL, bouton retour, etc.) et l’affiche comme une application native. C’est le réglage le plus recommandé.
    • fullscreen : Utilise tout l’écran, masquant même la barre d’état (idéal pour les jeux et les applications vidéo).
    • minimal-ui : N’affiche que l’interface de navigation de base.
    • browser : L’affiche comme un onglet de navigateur normal.
  • theme_color et background_color : Définissent la couleur de thème de l’application et la couleur de fond de l’écran de démarrage (splash screen) lors du lancement.
  • icons : Un tableau d’images utilisées comme icônes de l’application. Il est recommandé de préparer plusieurs tailles (au moins 192x192 et 512x512) pour s’adapter aux différentes résolutions des appareils. Spécifier purpose: "maskable" permet d’optimiser le recadrage de l’icône sur Android, etc.

5. Le cœur et le cycle de vie du Service Worker

Le Service Worker est ce que l’on devrait appeler le “cœur” d’une PWA. Contrairement au JavaScript traditionnel exécuté dans une page web, il n’a pas accès au DOM. À la place, il sert de médiateur pour les requêtes réseau, manipule le cache et effectue des synchronisations en arrière-plan.

5.1. Le cycle de vie du Service Worker

Le Service Worker possède son propre cycle de vie, indépendant de la page. Comprendre précisément ce cycle de vie est la clé pour éviter les problèmes de cache inattendus (comme l’écran qui ne change pas après une mise à jour).

Le diagramme Mermaid suivant illustre les transitions d’état du Service Worker.

  stateDiagram-v2
    direction TB
    "Analysé" --> "En cours d'installation" : "Inscription"
    "En cours d'installation" --> "Installé (En attente)" : "Succès"
    "En cours d'installation" --> "Redondant" : "Erreur"
    "Installé (En attente)" --> "En cours d'activation" : "Tous les clients fermés / skipWaiting()"
    "En cours d'activation" --> "Activé" : "Succès"
    "En cours d'activation" --> "Redondant" : "Erreur"
    "Activé" --> "Redondant" : "Remplacé par un nouveau SW"
  1. Analysé (Parsed) : L’état où le navigateur a téléchargé le script du Service Worker et terminé son analyse syntaxique.
  2. En cours d’installation (Installing) : L’état où l’événement install est déclenché. Cette phase est principalement utilisée pour mettre en cache au préalable (Pre-caching) les ressources statiques (HTML, CSS, JS, images, etc.) indispensables au fonctionnement de l’application. Si l’installation échoue (ex. échec de sauvegarde dans le cache), le Service Worker est abandonné.
  3. Installé / En attente (Installed / Waiting) : L’installation est terminée, mais l’ancien Service Worker existant est encore actif dans d’autres onglets, il attend donc son remplacement. On passe à la phase suivante lorsque l’utilisateur ferme tous les onglets puis les rouvre, ou en appelant self.skipWaiting().
  4. En cours d’activation (Activating) : L’état où l’événement activate est déclenché. Cette phase est principalement utilisée pour supprimer les caches inutiles créés par l’ancien Service Worker et effectuer un nettoyage.
  5. Activé (Activated) : Il est pleinement opérationnel et peut contrôler/gérer les événements fetch et push provenant de la page.
  6. Redondant (Redundant) : État après un échec d’installation, un échec d’activation, ou s’il a été remplacé par une nouvelle version du Service Worker.

5.2. Enregistrement du Service Worker

Pour utiliser un Service Worker, il faut d’abord l’enregistrer depuis le thread JavaScript principal.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// main.js ou dans la balise <script> de index.html
if ("serviceWorker" in navigator) {
  window.addEventListener("load", () => {
    navigator.serviceWorker
      .register("/sw.js", { scope: "/" })
      .then((registration) => {
        console.log("Enregistrement du ServiceWorker réussi avec la portée : ", registration.scope);
      })
      .catch((error) => {
        console.error("Échec de l'enregistrement du ServiceWorker : ", error);
      });
  });
}

Ce qui est important ici, c’est la portée (scope) du Service Worker. Par défaut, il n’intercepte que les requêtes sous le répertoire où le fichier du Service Worker est placé. En d’autres termes, s’il s’agit de /sw.js, il peut intercepter les requêtes vers / de tout le site, mais s’il est placé dans /js/sw.js, il ne pourra intercepter que les requêtes sous /js/.

6. Guide complet des stratégies de cache

Le plus grand avantage du Service Worker est de pouvoir intercepter les requêtes réseau (événement fetch) et d’implémenter des stratégies de cache personnalisées. Il est nécessaire d’utiliser la bonne stratégie de cache selon le type de ressource (image, réponse d’API, HTML) et les exigences de l’application.

6.1. Cache First (Priorité au cache)

C’est la stratégie la plus basique et la plus rapide. Elle vérifie d’abord le cache, le renvoie s’il existe, et s’il n’existe pas, va le chercher sur le réseau, puis sauvegarde le résultat dans le cache. C’est idéal pour les ressources statiques qui ne changent pas souvent, comme les fichiers images et les polices.

  flowchart TD
    "Page" -->|"1. Requête"| "Service Worker"
    "Service Worker" -->|"2. Vérifier le cache"| "Cache"
    "Cache" -->|"3a. Succès du cache"| "Service Worker"
    "Service Worker" -->|"4a. Réponse"| "Page"
    "Cache" -->|"3b. Échec du cache"| "Réseau"
    "Réseau" -->|"4b. Réponse"| "Service Worker"
    "Service Worker" -->|"5b. Sauvegarder dans le cache"| "Cache"
    "Service Worker" -->|"6b. Réponse"| "Page"

6.2. Network First (Priorité au réseau)

C’est une stratégie qui donne la priorité à la récupération systématique des données les plus récentes. Elle envoie d’abord une requête au réseau, et si elle réussit, sauvegarde le résultat dans le cache et le renvoie à la page. Elle ne se replie (fallback) sur le cache que si la communication réseau échoue, par exemple en mode hors ligne. C’est adapté aux données d’articles ou aux réponses d’API fréquemment mises à jour.

  flowchart TD
    "Page" -->|"1. Requête"| "Service Worker"
    "Service Worker" -->|"2. Récupérer"| "Réseau"
    "Réseau" -->|"3a. Succès"| "Service Worker"
    "Service Worker" -->|"4a. Sauvegarder dans le cache"| "Cache"
    "Service Worker" -->|"5a. Réponse"| "Page"
    "Réseau" -->|"3b. Erreur / Hors ligne"| "Service Worker"
    "Service Worker" -->|"4b. Vérifier le cache"| "Cache"
    "Cache" -->|"5b. Succès du cache"| "Service Worker"
    "Service Worker" -->|"6b. Réponse de repli"| "Page"

6.3. Stale-while-revalidate (Renvoyer le cache obsolète tout en mettant à jour en arrière-plan)

C’est une stratégie moderne et très puissante qui concilie vitesse et fraîcheur. Lorsqu’une requête est effectuée, elle renvoie immédiatement le cache (données périmées/stale) pour un rendu d’écran rapide. En même temps, en arrière-plan (while-revalidate), elle envoie une requête au réseau pour récupérer les dernières données et mettre à jour le cache. L’utilisateur verra les données les plus récentes lors de son prochain accès.

  flowchart TD
    "Page" -->|"1. Requête"| "Service Worker"
    "Service Worker" -->|"2. Vérifier le cache"| "Cache"
    "Cache" -->|"3. Succès du cache (Réponse rapide)"| "Service Worker"
    "Service Worker" -->|"4. Retourner une réponse périmée"| "Page"
    "Service Worker" -.->|"5. Récupérer (Arrière-plan)"| "Réseau"
    "Réseau" -.->|"6. Réponse du réseau"| "Service Worker"
    "Service Worker" -.->|"7. Mettre à jour le cache"| "Cache"

6.4. Cache Only / Network Only (Cache uniquement / Réseau uniquement)

  • Cache Only : Renvoie une réponse exclusivement à partir du cache. Si elle n’existe pas, cela génère une erreur. Utilisé uniquement pour des ressources spécifiques dont le téléchargement préalable est garanti de manière certaine.
  • Network Only : Ignore complètement le cache et effectue toujours une requête au réseau. Utilisé pour les communications qui ne doivent pas être mises en cache, comme les API d’authentification ou les requêtes POST.

7. Exemple d’implémentation du Service Worker (Explication détaillée du code)

Maintenant, sur la base du cycle de vie et des stratégies de cache évoqués précédemment, regardons un exemple concret d’implémentation de sw.js (fichier du Service Worker).

7.1. Événement d’installation et pré-mise en cache

Lors de l’événement install, la structure (shell) de l’application (HTML de base, CSS, JS) est mise en cache au préalable. Cela permet d’afficher immédiatement la structure de l’application lors des accès ultérieurs ou hors ligne.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// sw.js
const CACHE_NAME = "pwa-cache-v1";
const PRECACHE_URLS = [
  "/",
  "/index.html",
  "/css/style.css",
  "/js/app.js",
  "/images/logo.png",
  "/offline.html"
];

self.addEventListener("install", (event) => {
  console.log("[ServiceWorker] Événement d'installation");
  
  // En appelant self.skipWaiting(), on saute l'état d'attente pour l'activer immédiatement.
  self.skipWaiting();

  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => {
      console.log("[ServiceWorker] Pré-mise en cache des pages hors ligne");
      return cache.addAll(PRECACHE_URLS);
    })
  );
});

7.2. Événement d’activation et nettoyage du cache

Lors du changement de version du nom du cache (par exemple de pwa-cache-v1 à v2), il est nécessaire de supprimer les anciens caches inutiles pour économiser l’espace de stockage. Cela se fait lors de l’événement activate.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

self.addEventListener("activate", (event) => {
  console.log("[ServiceWorker] Événement d'activation");
  
  // self.clients.claim() permet de prendre immédiatement le contrôle de toutes les pages actuellement ouvertes.
  event.waitUntil(self.clients.claim());

  event.waitUntil(
    caches.keys().then((cacheNames) => {
      return Promise.all(
        cacheNames.map((cacheName) => {
          if (cacheName !== CACHE_NAME) {
            console.log("[ServiceWorker] Suppression de l'ancien cache :", cacheName);
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

7.3. Gestion de l’événement Fetch

Voici un exemple d’implémentation avancée qui intercepte l’événement fetch et bascule de stratégie en fonction du type de ressource demandée. Les traitements divergent, par exemple : les images utilisent “Cache First”, et les requêtes de navigation HTML utilisent “Network First” avec repli (fallback).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

self.addEventListener("fetch", (event) => {
  const request = event.request;
  const url = new URL(request.url);

  // Les requêtes POST et les requêtes vers des domaines externes passent directement par le réseau
  if (request.method !== "GET") return;

  // Les requêtes HTML (transitions de page) utilisent la stratégie Network First + repli hors ligne
  if (request.mode === "navigate" || request.headers.get("accept").includes("text/html")) {
    event.respondWith(
      fetch(request)
        .then((response) => {
          return caches.open(CACHE_NAME).then((cache) => {
            cache.put(request, response.clone());
            return response;
          });
        })
        .catch(() => {
          // En cas d'erreur réseau (hors ligne), récupération depuis le cache, sinon renvoie la page hors ligne dédiée
          return caches.match(request).then((cachedResponse) => {
            return cachedResponse || caches.match("/offline.html");
          });
        })
    );
    return;
  }

  // Les ressources statiques comme les images utilisent la stratégie Cache First
  if (url.pathname.match(/\.(png|jpg|jpeg|gif|svg|css|js)$/)) {
    event.respondWith(
      caches.match(request).then((cachedResponse) => {
        if (cachedResponse) {
          return cachedResponse;
        }
        return fetch(request).then((networkResponse) => {
          return caches.open(CACHE_NAME).then((cache) => {
            cache.put(request, networkResponse.clone());
            return networkResponse;
          });
        });
      })
    );
    return;
  }

  // Pour les autres requêtes d'API, etc., on applique Stale-while-revalidate
  event.respondWith(
    caches.match(request).then((cachedResponse) => {
      const fetchPromise = fetch(request).then((networkResponse) => {
        return caches.open(CACHE_NAME).then((cache) => {
          cache.put(request, networkResponse.clone());
          return networkResponse;
        });
      });
      // S'il y a un cache, on le renvoie d'abord, puis on poursuit la récupération en arrière-plan. S'il n'y a pas de cache, on attend fetchPromise.
      return cachedResponse || fetchPromise;
    })
  );
});

8. Intégration avec IndexedDB : Gestion de données plus avancée

L’API caches (Cache Storage) du Service Worker est très adaptée pour sauvegarder des réponses HTTP complètes (fichiers HTML, images, CSS, etc.). Cependant, cela peut être insuffisant pour gérer des données structurées manipulées par l’application (réponses d’API au format JSON, données de paramètres utilisateur, données textuelles postées hors ligne, etc.).

C’est là qu’intervient IndexedDB.

IndexedDB est une base de données NoSQL asynchrone et transactionnelle intégrée au navigateur. Elle permet de stocker de très grandes quantités de données et des recherches complexes par index sont possibles.

8.1. Pourquoi le Cache Storage seul est-il insuffisant ?

Par exemple, imaginez que vous ajoutiez une nouvelle tâche dans une application ToDo en mode hors ligne. À ce moment, il est difficile de sauvegarder la “requête POST d’ajout de tâche” elle-même dans le Cache Storage. Pour répondre à la nécessité de sauvegarder une action effectuée hors ligne et de la renvoyer lors du retour en ligne, il est nécessaire d’avoir une intégration permettant de sauvegarder temporairement les données de la tâche dans IndexedDB, puis d’extraire les données de la base pour les envoyer à l’API au moment de la synchronisation en arrière-plan (décrite ci-dessous).

8.2. Utilisation d’IndexedDB dans un Service Worker

Il est également possible d’accéder à IndexedDB depuis la portée du Service Worker. Étant donné qu’utiliser directement l’API d’IndexedDB tend à rendre le code complexe, il est courant d’utiliser idb, une bibliothèque wrapper légère fournie par Google.

Dans une PWA dotée de fonctionnalités hors ligne avancées, où une liste d’articles JSON récupérée via une API est sauvegardée non pas dans l’API de cache mais dans IndexedDB pour y être gérée et interrogée en détail, cet IndexedDB joue un rôle crucial.

9. Notifications Push et Synchronisation en arrière-plan (Background Sync)

Les fonctionnalités qui rapprochent le plus les PWA des applications natives sont les notifications Push et le fonctionnement en arrière-plan.

9.1. API Web Push

Le Web Push est un mécanisme permettant de réveiller un Service Worker depuis un serveur et de délivrer une notification à l’utilisateur, même si l’application n’est pas ouverte.

  1. Abonnement (Subscribe) : Demande la permission à l’utilisateur pour les notifications côté navigateur, récupère les informations d’abonnement au service Push (point de terminaison et clé de chiffrement) et les sauvegarde sur votre propre serveur.
  2. Envoi (Push) : Envoie un message depuis votre propre serveur vers le service Push du fournisseur du navigateur (FCM ou le service de notification Push d’Apple).
  3. Réception (Push Event) : Lorsque le service Push envoie des données à l’appareil, le navigateur lance le Service Worker en arrière-plan et déclenche l’événement push. Le Service Worker appelle la méthode self.registration.showNotification() et affiche l’interface utilisateur de notification native de l’OS.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

self.addEventListener("push", (event) => {
  const data = event.data ? event.data.json() : {};
  const title = data.title || "Vous avez un nouveau message";
  const options = {
    body: data.body || "Veuillez ouvrir l'application pour vérifier.",
    icon: "/images/icons/icon-192x192.png",
    badge: "/images/icons/badge.png",
  };

  event.waitUntil(self.registration.showNotification(title, options));
});

9.2. Background Sync (Synchronisation en arrière-plan)

Imaginons qu’un utilisateur clique sur le bouton pour envoyer un message alors qu’il est hors ligne dans le métro. Dans une application web normale, cela entraînerait une erreur, mais en utilisant l’API Background Sync, le navigateur surveille le “moment où la connexion réseau est rétablie” et génère un événement sync pour le Service Worker.

Du côté de l’application, les données sont sauvegardées temporairement dans IndexedDB lors du mode hors ligne, et une tâche de synchronisation est enregistrée auprès du Service Worker (registration.sync.register('send-messages')). Ensuite, lors du retour en ligne et du déclenchement de l’événement sync, les données sont extraites d’IndexedDB et envoyées au serveur. Grâce à cela, l’utilisateur peut continuer à utiliser l’application sans se soucier de l’état du réseau.

10. L’avenir des PWA et ses défis (Évolution via le Project Fugu)

Les PWA continuent d’évoluer. En particulier, une initiative appelée Project Fugu (Web Capabilities), dirigée par Google, Microsoft, Intel, etc., rend la frontière entre le Web et le natif encore plus floue.

L’objectif du Project Fugu est de permettre un accès sécurisé depuis le Web aux puissantes fonctionnalités de l’OS qui n’étaient auparavant permises qu’aux applications natives. Ainsi, de nouvelles API comme les suivantes sont continuellement implémentées dans les navigateurs :

  • Web Bluetooth API : Communication directe avec des appareils IoT
  • Web USB API / Web Serial API : Connexion avec du matériel spécifique
  • File System Access API : Lecture et écriture directes de fichiers sur le système de fichiers local de l’utilisateur (important pour les IDE et les PWA d’éditeurs)
  • Contact Picker API : Accès aux données du carnet d’adresses de l’appareil
  • Web Share Target API : Enregistrement de la PWA comme destination dans le “Menu de partage” de l’OS

En ce qui concerne les défis, la situation du support d’Apple (iOS/Safari) est toujours mentionnée. Apple, en raison d’équilibres avec la vie privée, la sécurité et le modèle économique de l’App Store, adopte une attitude prudente vis-à-vis d’une grande partie des API du Project Fugu. Cependant, il est également vrai qu’ils renforcent progressivement leur support des PWA en réponse à la forte demande des utilisateurs, comme le support du Web Push dans iOS 16.4.

Dans le développement futur d’applications web, les PWA ne seront plus une simple option, mais deviendront sans aucun doute la norme technologique requise (baseline) pour offrir la meilleure expérience aux utilisateurs.

11. Conclusion

Dans cet article, nous avons expliqué à un niveau très approfondi les concepts de base des PWA, allant du cycle de vie complexe du Service Worker aux diverses stratégies de cache, à l’intégration avec IndexedDB, et aux dernières tendances technologiques du Web.

Lorsque vous touchez au Service Worker pour la première fois, vous pourriez être déconcerté par son asynchronisme et le comportement du cache. Cependant, en comprenant correctement son cycle de vie et en choisissant et implémentant la stratégie de cache appropriée, vous pouvez construire une application web incroyablement rapide et résiliente.

L’expérience “ça fonctionne même hors ligne” engendre pour l’utilisateur une confiance profonde et un attachement à l’application qui va bien au-delà d’une simple fonctionnalité pratique. N’hésitez pas à intégrer la technologie PWA dans vos propres projets et à exploiter tout le potentiel du Web.

comments powered by Disqus