Guides

« SPA vs PWA » est l’une des confusions les plus courantes en développement front-end, et la raison est simple : les deux termes ne sont pas du tout opposés. Une single-page application (SPA) décrit la façon dont une application est construite et navigue, tandis qu’une progressive web app (PWA) décrit ce qu’une application peut faire pour l’utilisateur. Les mettre face à face revient un peu à demander « voiture manuelle ou électrique » — vous comparez deux axes différents, et une application peut très bien être les deux, l’une, ou ni l’une ni l’autre.

Ce qu'est une SPA

Une single-page application charge un unique document HTML, puis réécrit la page dans le navigateur au fil de votre navigation, au lieu de récupérer une nouvelle page depuis le serveur à chaque clic. Après le premier chargement, le JavaScript remplace les parties concernées de l’interface et ne récupère que les données dont il a besoin, généralement sous forme de JSON depuis une API. Le résultat se rapproche d’une application de bureau ou mobile, avec des transitions instantanées et sans rechargement complet de la page. React, Vue, Svelte et Angular existent en grande partie pour rendre ce modèle praticable.

Ce qu'est une PWA

Une progressive web app est une idée entièrement différente : c’est un site web qui utilise les standards web modernes pour se comporter davantage comme une application installée. Les trois piliers sont un manifest d’application web (pour pouvoir l’ajouter à l’écran d’accueil avec une icône et un nom), un service worker (un script capable de mettre des ressources en cache et de les servir hors ligne) et HTTPS (requis pour ces capacités). Une PWA peut envoyer des notifications push, fonctionner sans connexion et se lancer dans sa propre fenêtre — le tout depuis une URL normale, sans store d’applications.

• SPA = architecture (navigation côté client, sans rechargements)
• PWA = capacités (installable, hors ligne, push)
• Une PWA est souvent une SPA — mais aucune n’exige l’autre
• Le SSR est un axe distinct (rendu, pas type d’application)
• Choisissez selon les besoins du produit, puis empilez les fonctionnalités

Pourquoi ce ne sont pas des opposés

C’est le cœur de la confusion qu’il vaut la peine de dissiper : les deux ne s’excluent pas mutuellement. Une PWA est très souvent construite comme une SPA, mais ce n’est pas obligatoire — vous pouvez ajouter un manifest et un service worker à un site multi-pages traditionnel pour en faire une PWA. De même, beaucoup de SPA ne sont pas du tout des PWA, parce qu’elles n’ajoutent jamais de support hors ligne ni d’installabilité. La SPA concerne l’architecture de navigation ; la PWA concerne la diffusion et les capacités ajoutées par-dessus.

Les compromis d'une SPA

Pris isolément, le modèle SPA vous offre une interactivité fluide à un certain coût. Une fois le bundle chargé, les interactions sont rapides parce que l’application demande des données plutôt que des documents entiers. Mais le premier chargement est plus lourd — le navigateur doit télécharger et exécuter du JavaScript avant d’afficher un contenu utile — et les moteurs de recherche peuvent ne voir qu’une coquille vide à moins que vous ne fassiez du rendu côté serveur. Les SPA brillent pour les tableaux de bord, les éditeurs et les produits de type application, moins pour les sites de contenu simples.

Les compromis d'une PWA

Les capacités d’une PWA résolvent un autre problème : le réengagement et la résilience. Le support hors ligne signifie que l’application fonctionne encore sur une connexion de train capricieuse ; l’installabilité place une icône sur l’écran d’accueil et supprime l’habillage du navigateur ; les notifications push ramènent les utilisateurs. Les compromis sont réels aussi — les service workers ajoutent une complexité de mise en cache qui peut servir du contenu périmé s’il est mal géré, et le support d’Apple sur iOS, bien que nettement amélioré, reste par endroits en retrait par rapport à Android.

Où se situe le SSR

Un troisième terme vient généralement perturber cette comparaison : le SSR, ou rendu côté serveur. Il mérite d’être distingué car c’est encore un autre axe — une stratégie de rendu, pas un type d’application. Les méta-frameworks comme Nuxt et Next.js rendent la première page sur le serveur pour que les utilisateurs et les moteurs de recherche obtiennent immédiatement un vrai contenu, puis l’hydratent en une SPA dans le navigateur. Vous pouvez combiner le SSR avec une SPA, et une PWA peut aussi utiliser le SSR ; aucune de ces étiquettes n’exclut les autres.

Comment choisir

Alors, comment choisir concrètement ? Partez de ce dont le produit a besoin, pas de l’acronyme. S’il est très interactif et se comporte comme un logiciel, l’architecture SPA convient. Si les utilisateurs gagneraient à avoir un accès hors ligne, l’installabilité ou les notifications push, ajoutez les capacités PWA par-dessus — c’est incrémental par conception, ce que signifie justement « progressive ». Si le site est surtout du contenu et que le SEO compte le plus, appuyez-vous sur le rendu côté serveur, voire sur une approche multi-pages traditionnelle, et n’ajoutez les fonctionnalités PWA que là où elles sont vraiment utiles.

À retenir

Le constat honnête, c’est que « SPA vs PWA » est le mauvais cadrage. Ce sont des couches complémentaires : l’une décide comment votre application navigue, l’autre décide ce qu’elle peut faire une fois qu’elle est là. Les applications web modernes les plus solides combinent souvent les trois idées — une SPA pour l’interactivité, le rendu côté serveur pour un premier affichage rapide et le SEO, et les fonctionnalités PWA pour le hors ligne et l’installabilité — choisies délibérément plutôt que traitées comme des camps rivaux.