Qu'est-ce qu'une PWA (Progressive Web App) ?

Une PWA est une app web qui utilise des service workers, un manifeste et HTTPS pour être installable, fonctionner hors ligne et recevoir des notifications push. Le terme, forgé par Alex Russell et Frances Berriman en 2015, désigne ce qui comble l’écart entre un site web et une app installée sans quitter le web : une seule base de code, une icône sur l’écran d’accueil, une fenêtre autonome et un écran qui continue de fonctionner quand le train entre dans un tunnel. L’angle que ce glossaire ajoute, et que les guides frontend passent sous silence : une PWA reste un client — le service worker met en cache, mais c’est votre backend qui fait foi.

Points clés

Les trois piliers, et le backend derrière eux

// JavaScript — the PWA's three pillars + the backend behind them
// 1 · Service worker: caches the shell, buffers writes when offline
navigator.serviceWorker.register('/sw.js');

// 2 · Manifest (public/manifest.json) makes it installable:
//    { "name": "Notes", "display": "standalone", "start_url": "/", "icons": [...] }

// 3 · HTTPS is required — service workers refuse to run otherwise.

// The catch: the SW cache is a MIRROR, not the source of truth.
// saveEventually() stores the write offline and sends it when back online:
const note = new Parse.Object('Note').set('text', draft);
await note.saveEventually(); // the BaaS is authoritative; the cache was a buffer

// Flutter / Dart — Back4app Flutter SDK (Flutter web compiles to a PWA)
// The service worker caches the app shell; data still lives on the backend.
final note = ParseObject('Note')..set('text', draft);
await note.save();
// Offline-first pattern: write locally, queue, and sync when connectivity
// returns — the API/BaaS is the source of truth, the cache is a local mirror.
// Push notifications need a BACKEND to send them; the client only subscribes.

// Swift — a native shell can host a PWA/WebView; the backend is shared
// The point of parity: whatever the client (PWA, native, web), the
// source of truth is the same backend API.
var note = Note()
note.text = draft
_ = try await note.save()
// Offline-first: cache locally, sync when online — the API is authoritative.
// Web push (PWA) and native push (APNs) both need a backend to SEND them.

// Kotlin — a native shell can host a PWA/WebView; the backend is shared
// The point of parity: whatever the client (PWA, native, web), the
// source of truth is the same backend API.
val note = ParseObject("Note")
note.put("text", draft)
note.save()
// Offline-first: cache locally, sync when online — the API is authoritative.
// Web push (PWA) and native push (APNs/FCM) both need a backend to SEND them.

Un service worker est un script d’arrière-plan placé entre l’app et le réseau, à la manière d’un proxy — il met le shell en cache et le sert hors ligne ; un manifeste d’application web est un fichier de métadonnées JSON (nom, icônes, display: standalone, URL de démarrage) qui rend l’app installable ; et HTTPS est obligatoire, car les service workers refusent de s’exécuter hors d’un contexte sécurisé. Ces trois éléments constituent la façade de l’app. Le save() des onglets de code montre ce qu’il y a derrière : le cache est un miroir, et lorsque le réseau revient, l’écriture se synchronise avec le backend qui fait autorité.

Comment une PWA sert une page hors ligne

Stratégies de cache hors ligne

La décision se prend ressource par ressource, pas à l’échelle de l’app : le shell veut du cache-first pour un chargement instantané ; les données vivantes de l’utilisateur veulent du network-first pour la fraîcheur ; un fil d’actualité peut se contenter de stale-while-revalidate pour paraître instantané et se corriger tout seul. Quelle que soit la stratégie, le cache est un tampon de lecture/écriture au-dessus de l’API — les écritures hors ligne sont mises en file d’attente localement et réconciliées à la reconnexion, la même discipline de rattrapage que tout client offline-first exige.

D’où viennent réellement les notifications push

Le mécanisme que presque aucun glossaire n’explique, et la raison pour laquelle une PWA a besoin d’un backend ne serait-ce que pour notifier. Le client ne fait que s’abonner : il demande la permission et reçoit un endpoint d’abonnement. L’envoi est un travail de serveur — votre backend → le service push du navigateur → l’événement push du service worker → une notification affichée. Le service worker peut se réveiller pour l’afficher alors que l’app est fermée, mais rien n’arrive si un backend ne l’a pas envoyée : « les PWA ont le push » n’est donc qu’une moitié de feature sans la moitié serveur. L’article sur les notifications push détaille la chaîne de livraison ; ce qui compte ici, c’est que le web push comme le push natif aboutissent à votre code qui décide d’envoyer.

PWA vs. app native

L’asymétrie honnête se trouve dans la dernière ligne : iOS est le point faible des PWA — installation uniquement via le menu Partager, pas d’invite d’installation automatique, push seulement une fois l’app installée et seulement sur les versions récentes, synchronisation en arrière-plan incomplète. Sur Android et desktop, l’écart avec le natif est faible ; sur iOS, c’est le facteur décisif pour de nombreux produits.

Cas d’usage courants

• Contenu et e-commerce — portée, SEO et faible friction d’installation l’emportent sur un téléchargement en store pour atteindre de nouveaux utilisateurs.
• Outils internes — des apps installables et tolérantes au hors ligne pour des utilisateurs connus, sans distribution par un store.
• Apps de terrain offline-first — capturer des données sans réseau, synchroniser au retour du signal ; le schéma du cache comme tampon.
• Portée multiplateforme à petit budget — une seule base de code web pour couvrir des plateformes qu’un développement natif multiplierait par trois.
• En complément d’une app native — le même backend sert une PWA pour la portée et une app native pour la profondeur.

Devriez-vous construire une PWA ? Matrice de décision

Limites et trade-offs

• iOS plafonne l’ensemble. Installation manuelle via le menu Partager, push conditionné et lacunes de la synchronisation en arrière-plan font d’iOS la contrainte qui tranche le plus souvent entre PWA et natif.
• L’accès au matériel est partiel. Bluetooth, NFC, contacts et API avancées de caméra sont limités ou absents selon l’OS — les apps très liées à l’appareil réclament toujours du natif.
• Le cache n’est pas la base de données. Traiter le cache du service worker comme la source de vérité ouvre la porte aux écritures perdues et aux conflits de données périmées ; c’est un tampon au-dessus du backend qui fait autorité.
• Le push est moitié client, moitié serveur. S’abonner est facile ; une PWA a toujours besoin d’un backend pour envoyer, si bien que « hors ligne et push » est une feature backend qui porte un badge frontend.
• La découvrabilité est à double tranchant. Pas de gardien de store, mais pas de vitrine de store non plus ; vous échangez la curation et le cérémonial d’installation contre une URL.

Les PWA sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. C’est la moitié backend de la feature que les piliers frontend ne font que compléter : le service worker met le shell en cache, mais Back4app est la source de vérité dont ce cache est le miroir — utilisateurs authentifiés, données synchronisées qui réconcilient les écritures hors ligne à la reconnexion, et le serveur qui envoie réellement le web push auquel une PWA ne peut que s’abonner. Comme un seul backend sert aussi bien une PWA qu’une app web classique ou une app native grâce à des SDK par plateforme, la portée multiplateforme que la PWA promet côté frontend trouve son pendant côté backend, écrit une seule fois — le client met en cache, la plateforme se souvient, et les deux moitiés de « installable, hors ligne et push » se rejoignent enfin.