Single page application (SPA) : avantages, limites et cas d’usage

Une single page application (SPA, ou application monopage) est une application web qui charge une seule page HTML au premier accès, puis redessine l’écran en JavaScript à chaque action, sans jamais recharger la page. Gmail, Google Maps et Trello fonctionnent ainsi. La navigation y est instantanée et l’interface réagit comme un logiciel installé. La décision importante porte sur la première page. Sans rendu serveur, elle arrive vide et le JavaScript la construit dans le navigateur, ce qui suffit pour un outil utilisé derrière une connexion (back-office, outil métier, SaaS). Avec un rendu serveur (SSR), le serveur envoie cette première page déjà remplie, puis l’application continue en SPA : c’est ce qu’il faut aux pages publiques que Google et les assistants IA doivent lire. Cet article explique comment fonctionne une SPA, compare les deux façons de la servir à un site multipage, détaille ses avantages et ses limites, puis aide à décider s’il faut un rendu serveur.

Qu’est-ce qu’une single page application ?

Une single page application est une application web qui ne charge qu’une seule page HTML, au premier accès, accompagnée du code JavaScript de l’application. Ce code prend ensuite en main tout l’affichage dans le navigateur. Quand l’utilisateur clique sur un lien ou un bouton, le navigateur ne demande pas de nouvelle page au serveur. Il demande seulement les données nécessaires, en général au format JSON via une API, puis le JavaScript met à jour la partie de l’écran concernée.

L’adresse dans la barre du navigateur change quand même (/factures, /clients/42), grâce à l’API History du navigateur. L’utilisateur peut donc garder un favori, partager un lien ou revenir en arrière comme sur un site classique.

On croise la SPA partout dans les outils du quotidien :

• Gmail, où la boîte de réception, un message et la rédaction s’enchaînent sans rechargement
• Google Maps, qui charge les tuiles de la carte au fil du déplacement
• Trello, où une carte glissée d’une colonne à l’autre s’enregistre sans quitter le tableau
• le lecteur web de Spotify, dont la musique continue pendant que vous changez de page

Le terme date du milieu des années 2000, quand les pages web ont commencé à charger des données sans se recharger, grâce à AJAX. Des frameworks comme AngularJS (2010), puis React (2013) et Vue.js (2014), ont ensuite rendu ce modèle accessible à toutes les équipes.

Comment fonctionne une SPA ?

Une SPA peut servir sa première page de deux façons.

• Sans rendu serveur, le serveur envoie une page HTML presque vide et le JavaScript. Le navigateur exécute ce code, qui appelle l’API et construit l’écran. On parle de rendu côté client (CSR, pour client-side rendering). Une SPA créée avec React et React Router, Vue.js ou Angular fonctionne ainsi par défaut.
• Avec un rendu serveur (SSR, pour server-side rendering), le serveur exécute le même code pour produire une page HTML complète, que le navigateur affiche tout de suite. Le JavaScript arrive ensuite et rend la page interactive. Next.js, Nuxt ou React Router en mode framework font ce travail.

Dans les deux cas, l’application fonctionne ensuite en SPA : chaque clic déclenche un simple appel à l’API, puis le navigateur redessine uniquement ce qui change.

graph TD
    A["L’utilisateur ouvre l’application"] --> B{"Rendu serveur ?"}
    B -->|Non| C["Le serveur envoie une page presque vide et le JavaScript"]
    C --> D["Le JavaScript appelle l’API et construit l’écran"]
    B -->|Oui| E["Le serveur envoie une page complète, affichée tout de suite"]
    E --> F["Le JavaScript arrive et rend la page interactive"]
    D --> G["L’application fonctionne en SPA"]
    F --> G
    G --> H["À chaque clic, seules les nouvelles données sont demandées"]
    H --> I["Seule la zone concernée est redessinée, sans rechargement"]
    I --> H

Un site multipage classique (MPA, pour multi-page application) fonctionne autrement : le serveur fabrique une page HTML complète à chaque clic et le navigateur recharge tout. WordPress, la plupart des sites e-commerce et les médias en ligne fonctionnent ainsi. La génération statique utilisée par la Jamstack produit elle aussi des pages complètes, mais au moment du déploiement.

SPA avec ou sans rendu serveur, site multipage : quelles différences ?

Critère	SPA sans rendu serveur	SPA avec rendu serveur (SSR)	Site multipage (MPA)
Premier affichage	Plus lent, tout le JavaScript doit être exécuté	Rapide, la page arrive complète	Rapide, la page arrive complète
Navigation ensuite	Instantanée, seules les données transitent	Instantanée, seules les données transitent	Un rechargement complet à chaque clic
Interactions complexes (glisser-déposer, édition en direct)	Naturelles	Naturelles	Possibles, avec plus d’effort
Référencement sur Google	Google doit exécuter le JavaScript, avec un délai	Contenu lisible dès la réception de la page	Contenu lisible dès la réception de la page
Citation par ChatGPT, Claude, Perplexity	Leurs robots n’exécutent pas le JavaScript et voient une page vide	Contenu lisible	Contenu lisible
Hébergement du front-end	Fichiers statiques sur un CDN, peu coûteux	Un serveur Node.js qui rend les pages	Un serveur qui génère les pages
Complexité de développement	La plus faible	Plus forte, le code tourne sur le serveur et dans le navigateur	Faible pour des pages simples

Quels sont les avantages d’une SPA ?

Une navigation instantanée

Une fois l’application chargée, le navigateur change d’écran en échangeant seulement quelques données avec le serveur. L’utilisateur ne voit plus de page blanche entre deux clics. Sur un outil qu’une équipe ouvre le matin et garde toute la journée, la différence se sent vite : un gestionnaire qui traite deux cents dossiers par jour enchaîne les écrans sans attendre.

Des interactions dignes d’un logiciel installé

Une SPA garde l’état de l’interface en mémoire pendant toute la session, ce qui rend naturels le glisser-déposer, l’édition à plusieurs en temps réel, les formulaires qui se valident à la frappe ou les tableaux filtrés à la volée. Les outils collaboratifs, les éditeurs et les tableaux de bord reposent presque tous sur ce modèle pour cette raison.

Un front-end et un back-end séparés

Dans une SPA, le serveur n’expose qu’une API. La même API peut ensuite servir une application mobile, un partenaire ou un agent IA. Les équipes front et back avancent en parallèle, sur un contrat d’API défini ensemble. Avec TypeScript des deux côtés, ce contrat se vérifie même à la compilation.

Un hébergement simple et peu coûteux

Sans rendu serveur, le front-end d’une SPA se résume à des fichiers statiques. Netlify, Cloudflare ou un bucket S3 les servent pour quelques euros par mois, même avec beaucoup d’utilisateurs. Seule l’API demande un vrai serveur.

Un fonctionnement hors connexion possible

Avec un service worker, une SPA peut garder ses fichiers et une partie des données en cache, puis synchroniser les modifications au retour du réseau. Elle devient alors une application web progressive (PWA), installable sur l’écran d’accueil du téléphone.

Quelles sont les limites d’une SPA ?

Sans rendu serveur, un contenu mal lu par les moteurs et les assistants IA

Sans rendu serveur, la page HTML d’une SPA arrive presque vide : le texte n’existe qu’après l’exécution du JavaScript. Google sait exécuter ce JavaScript, mais il met ces pages en file d’attente, ce qui retarde leur indexation. Google recommande toujours le rendu serveur ou le pré-rendu dans sa documentation sur le SEO JavaScript, deux techniques qui accélèrent aussi l’affichage.

Les assistants IA lisent encore moins bien les SPA. L’hébergeur Vercel a mesuré en décembre 2024 qu’aucun des grands robots IA n’exécutait le JavaScript, alors que GPTBot (OpenAI) et le robot de Claude (Anthropic) faisaient respectivement 569 et 370 millions de requêtes par mois sur son réseau. Une page produit ou un article affichés par une SPA sans rendu serveur restent donc invisibles pour ChatGPT, Claude ou Perplexity. Le rendu serveur règle ce problème, puisque le SEO technique d’une page publique commence par un HTML complet envoyé par le serveur.

Un premier chargement plus lourd

Sans rendu serveur, le navigateur doit télécharger et exécuter le code de l’application avant d’afficher quoi que ce soit. Avec un rendu serveur, la page s’affiche tout de suite, mais elle ne réagit aux clics qu’une fois ce code chargé. Sur un ordinateur de bureau avec la fibre, l’écart reste faible. Sur un téléphone d’entrée de gamme en 4G, une application mal découpée peut mettre plusieurs secondes à s’afficher. Le découpage du code par écran (code splitting) et le chargement différé des bibliothèques lourdes réduisent ce délai, à condition d’y penser dès le départ.

Des comportements du navigateur à reconstruire

Un site multipage hérite gratuitement de comportements que la SPA doit recréer :

• la position de défilement quand on revient en arrière
• l’annonce du changement de page aux lecteurs d’écran, et le placement du focus clavier
• le titre de l’onglet et les balises meta de chaque écran
• le suivi des pages vues dans l’outil de mesure d’audience

Les routeurs modernes (React Router, TanStack Router, Vue Router) en gèrent une partie. L’accessibilité demande toujours un travail explicite, souvent oublié.

Une sécurité à penser côté serveur

Tout le code d’une SPA part dans le navigateur de l’utilisateur, qui peut le lire et le modifier. Masquer un bouton ne protège donc rien : chaque droit doit être vérifié par l’API. Choisissez aussi avec soin où stocker le jeton de connexion, puisqu’un jeton gardé dans le localStorage peut être volé par une faille XSS. Un cookie HttpOnly limite ce risque.

Une SPA avec ou sans rendu serveur ?

Posez-vous une question avant toutes les autres : l’écran doit-il être trouvé par quelqu’un qui ne connaît pas encore le produit ? Si la réponse est non, une SPA sans rendu serveur est souvent le meilleur choix, parce qu’elle reste la plus simple à développer et à héberger.

Une SPA sans rendu serveur convient bien à :

• un back-office ou un outil interne, utilisé par des salariés connectés
• une application métier qui remplace des fichiers Excel ou un vieux logiciel
• l’espace connecté d’un SaaS, où chaque client voit ses propres données
• un tableau de bord qui se met à jour en temps réel
• un éditeur collaboratif ou un outil de dessin

Prévoyez un rendu serveur, ou une génération des pages à l’avance, pour :

• un site vitrine, un blog, une page d’offre
• le catalogue d’un site e-commerce
• une documentation publique
• toute page que vous voulez voir citée par un assistant IA

Plusieurs produits conçus par Lonestone combinent un site public généré à l’avance et une SPA sans rendu serveur. Rolebase, une plateforme de gouvernance partagée, a ainsi un site public construit avec Astro et une application React qui fonctionne en SPA derrière la connexion. Raconte.ai, un SaaS d’interviews clients menées par une IA vocale, suit la même découpe. Le boilerplate open source de Lonestone contient d’ailleurs deux applications React, l’une sans rendu serveur, l’autre avec, pour démarrer un projet avec l’architecture qui correspond à ses écrans.

Quelles options pour servir les pages en 2026 ?

Les frameworks récents laissent choisir, parfois page par page, comment la première page arrive dans le navigateur.

• Le rendu serveur (SSR) : Next.js, Nuxt ou React Router en mode framework génèrent le HTML de chaque page à la demande, puis l’application continue en SPA dans le navigateur. Les robots lisent le contenu et l’utilisateur garde une navigation rapide.
• La génération statique (SSG) : Next.js ou Astro produisent toutes les pages au moment du déploiement. Next.js garde ensuite une navigation de SPA, alors qu’Astro produit par défaut un site multipage. Le site de Lonestone fonctionne ainsi, avec Astro.
• Les îlots d’interactivité : Astro envoie une page statique et n’active en JavaScript que les composants qui en ont besoin, comme un simulateur ou un formulaire.
• Les transitions entre pages d’un site multipage : l’API View Transitions anime le passage d’une page à l’autre sans JavaScript. Chrome, Edge et Safari la prennent en charge depuis 2024 pour les sites multipages. Sur Firefox, la page change simplement sans animation.

Pour un produit avec une partie publique et une partie connectée, une SPA avec rendu serveur couvre les deux avec un seul framework. Elle demande en contrepartie un serveur Node.js en production et un peu plus de rigueur sur ce qui s’exécute côté serveur ou côté navigateur. Pour un outil interne sans partie publique, une SPA sans rendu serveur, en React et Vite, reste plus simple à développer, à tester et à héberger.

Avec quels frameworks créer une SPA ?

React reste le choix le plus courant, associé à Vite pour la compilation et à React Router ou TanStack Router pour la navigation entre les écrans, ou Next.js quand il faut un rendu serveur. Son écosystème de composants et de bibliothèques est le plus large. Une équipe qui connaît React a déjà fait une bonne partie du chemin pour développer des applications iOS et Android en React Native. On construit aussi très bien des SPA avec Vue.js (ou Nuxt pour le rendu serveur), Angular ou Svelte. Les alternatives à React ont chacune leurs points forts, donc le choix dépend surtout des compétences de l’équipe qui maintiendra le code.

L’API d’une SPA peut être écrite dans n’importe quel langage. Lonestone la développe en TypeScript avec Node.js et NestJS. Le front-end et le back-end partagent alors les mêmes types, ce qui évite une bonne partie des bugs d’intégration.

Décider du rendu serveur dès le cadrage

Une single page application reste le bon modèle pour une interface riche qu’on garde ouverte longtemps. Sans rendu serveur, elle convient aux outils derrière une connexion. Les pages qui doivent être trouvées sur Google ou citées par une IA ont besoin d’un rendu serveur ou d’une génération à l’avance. La plupart des projets ont les deux besoins, donc on décide au cadrage quels écrans demandent un rendu serveur, avant la première ligne de code. Changer d’architecture en cours de route coûte bien plus cher que d’y réfléchir au départ.

Lonestone conçoit des applications web depuis 2014 pour plus de 200 clients, avec des ingénieurs qui ont pour la plupart entre 10 et 25 ans d’expérience. Pour un back-office, un outil interne ou un SaaS, confiez votre projet à une agence de développement web sur mesure qui choisit l’architecture selon l’usage de chaque écran. L’échange, les conseils et le devis sont gratuits.

FAQ

Questions fréquentes

Qu’est-ce qu’une single page application (SPA) ?

Une single page application est une application web qui charge une seule page HTML au premier accès, puis met à jour l’écran en JavaScript à chaque action de l’utilisateur, sans recharger la page. Le navigateur demande seulement des données à une API. Gmail, Google Maps et Trello sont des exemples connus de SPA. Ce modèle se distingue du site multipage, où le serveur envoie une page complète à chaque clic.

Une SPA est-elle mauvaise pour le SEO ?

Une SPA sans rendu serveur est difficile à référencer, parce que son contenu n’apparaît qu’après l’exécution du JavaScript. Google exécute ce JavaScript avec un délai, alors que les robots de ChatGPT, Claude et Perplexity ne l’exécutent pas du tout et voient une page vide. Une SPA avec rendu serveur (Next.js, Nuxt, React Router en mode framework) envoie au contraire un HTML complet, la base du SEO technique, puis garde sa navigation de SPA. Pour un outil derrière une connexion, le référencement est sans objet, donc une SPA sans rendu serveur convient très bien.

Quelle est la différence entre une SPA et une PWA ?

Le terme SPA désigne une architecture : l’application tient dans une seule page HTML, redessinée en JavaScript. Une PWA (application web progressive) est un site installable sur l’écran d’accueil, capable de fonctionner hors connexion et d’envoyer des notifications. Une PWA est souvent construite comme une SPA, mais un site multipage peut aussi en devenir une. Une SPA devient une application web progressive quand l’équipe lui ajoute un service worker et un manifeste.

React est-il une single page application ?

React est une bibliothèque JavaScript pour construire des interfaces. Elle sert à créer une SPA sans rendu serveur, avec Vite et un routeur comme React Router, ou une SPA avec rendu serveur, grâce à Next.js ou React Router en mode framework. Le besoin de rendu serveur dépend donc du projet. Les composants React restent en grande partie les mêmes dans les deux cas. Lonestone développe des applications React dans les deux modes.

Quand faut-il ajouter un rendu serveur à une SPA ?

Une SPA a besoin d’un rendu serveur (SSR) dès que ses pages doivent attirer des visiteurs depuis Google ou être citées par des assistants IA : site vitrine, blog, catalogue e-commerce, documentation publique. Le rendu serveur aide aussi pour les pages consultées une seule fois sur mobile, puisque la page s’affiche avant la fin du chargement du JavaScript. Pour un back-office, un outil interne ou l’espace connecté d’un SaaS, une SPA sans rendu serveur suffit et reste plus simple à héberger.

Combien coûte le développement d’une application web en SPA ?

Le coût d’une application en SPA dépend surtout du nombre d’écrans, des règles métier et des intégrations avec d’autres logiciels, bien plus que de la présence d’un rendu serveur. Sans rendu serveur, l’hébergement coûte peu, puisque le front-end se résume à des fichiers statiques servis par un CDN. Pour un outil interne, le prix démarre à quelques milliers d’euros. Lonestone propose un échange et un devis gratuits pour le développement d’outils métier.