Aujourd’hui, les utilisateurs attendent des services numériques rapides, intuitifs et disponibles sur tous types de supports : ordinateurs, mobiles, voire accessible hors connexion. L’enjeu n’est plus uniquement technologique, mais bien expérientiel et stratégique. L’architecture retenue doit répondre à ces attentes tout en s’inscrivant dans les contraintes internes du projet (budget, équipe, roadmap).
C’est précisément à cette intersection entre usage, performance et organisation que le choix architectural prend tout son sens. Il ne s’agit pas uniquement de choisir une solution technique, mais bien d’opter pour un modèle qui soutient la stratégie produit, les ambitions UX et les capacités de l’équipe projet.
Deux grands paradigmes s’opposent (et nous le verrons plus loin, se complètent aujourd’hui !) : SPA (Single Page Application) et MPA (Multi Page Application). Ce sont deux manières très différentes de concevoir une application Web, avec des impacts profonds sur l’expérience utilisateur, l’organisation des équipes et même la stratégie de déploiement.
Avant d’aborder les différences entre MPA et SPA, il est utile de rappeler ce que l’on entend par « architecture Web ». Dans un projet numérique, l’architecture Web désigne la manière dont les différentes briques techniques (interfaces, serveurs, données) sont organisées pour dialoguer entre elles et délivrer une expérience aux utilisateurs.
Elle conditionne notamment la façon dont les pages sont générées, comment les données sont récupérées, où se fait le rendu des contenus (côté serveur ou navigateur), et comment le système évolue dans le temps.
Choisir une architecture, c’est donc décider comment l’information circule entre les front-end (client ou navigateur) et le back-end (serveur), quel niveau de réactivité on souhaite, quel niveau de contrôle on garde sur le SEO ou la sécurité, et comment on anticipe la maintenance ou la montée en charge en cas de forte affluence.
C’est dans ce cadre que se posent deux modèles devenus structurants : les MPA (Multi Page Applications) et les SPA (Single Page Applications).
Le modèle MPA repose sur une logique serveur : chaque action de navigation déclenche une requête http vers le back-end, qui retourne une nouvelle page HTML entièrement générée côté serveur.
Dans une architecture MPA, la logique de navigation repose sur des principes simples et éprouvés, hérités du web-traditionnel. Voici les éléments fondamentaux qui la caractérisent :
Ces architectures conservent plusieurs atouts structurels qui en font encore aujourd’hui un choix pertinent pour de nombreux projets, en particulier ceux orientés contenu ou nécessitant une indexabilité optimale.
Comme toute approche, ce modèle présente aussi un certain nombre de contraintes, notamment sur l’expérience utilisateur et les possibilités d’interaction dynamique. Voici les principales limites à prendre en compte :
Dans une SPA, seule une page HTML est initialement chargée. L’application repose ensuite sur une communication asynchrone avec des APIs pour mettre à jour l’interface, sans rechargement complet.
Une architecture SPA repose sur une dynamique applicative radicalement différente, où la logique de navigation est entièrement pilotée côté client. Voici les fondements qui structurent ce type d’approche :
Ces architectures présentent des avantages techniques majeurs pour les applications interactives, en particulier lorsqu’on cherche à optimiser l’expérience utilisateur et à fluidifier les échanges avec le serveur. Voici les principaux atours à retenir :
Même si ces architectures apportent une grande souplesse dans l’expérience utilisateur, elles ne sont pas exemptes de contraintes importantes, en particulier sur le plan technique et organisationnel. Voici les principaux points de vigilance à garder en tête :
La grille de comparaison ci-dessous analyse différents critères techniques des architectures SPA et MPA et permet de mieux comprendre leurs avantages et leurs limites respective.
| Critère | SPA | MPA |
| Rendu initial (TTFB*) | Plus lent (poids JS) | Plus rapide (HTML direct) |
| Interaction utilisateur | Très fluide | Navigation page par page |
| Modèle de routage | Côté client | Côté serveur |
| SEO natif | Mauvais sans SSR/SSG | Excellent par défaut |
| Progressive enhancement | Difficile sans gestion JS fine | Natif (HTML) |
| Testabilité | Front testable en isolation (Jest, Cypress) | Full-stack test plus simple |
| Debug / logs | Nécessite instrumentation JS (Sentry) | Logs serveur classiques |
| Monitoring UX | Complexe, nécessite du RUM** | Plus simple via logs d’accès |
| Charge serveur | Moindre (API stateless) | Plus élevée (rendu complet) |
| Coût de maintenance | Complexité côté front | Complexité côté back |
| Accessibilité | À construire manuellement | Plus « naturelle » sans JS |
* TTFB : Time to first byte, ou temps écouté entre la demande d’une ressource et le début de l’arrivée du premier octet d’une réponse.
** RUM : Real User Monitoring, ou mesure qui consiste à observer le comportement des utilisateurs réels sur les applications.
Pour illustrer concrètement les différences entre SPA et MPA, voici deux cas réels qui incarnent chacun une logique architecturale bien distincte. L’un mise sur la fluidité d’usage dans un contexte collaboratif, l’autre sur la solidité et la lisibilité dans un cadre institutionnel à forte exigence de référencement. Voyons cela à travers deux exemples d’applications aux usages très différents.
L’objectif de Trello est de permettre à des équipes projet de collaborer efficacement via une interface visuelle centrée sur les tâches, les statuts, les échéances et les membres impliqués. L’application facilite ainsi l’organisation des flux de travail, le suivi des responsabilités et la coordination en temps réel, même à distance.
Sur le plan de l’architecture, Trello repose sur une architecture SPA. Cette approche s’appuie sur des composants dynamiques fortement interactifs, une gestion d’état avancée et un recours massif aux appels API et WebSocket pour garantir des interactions sans rechargement de page et une synchronisation instantanée des données entre utilisateurs.
Les principaux atouts observés dans cette proposition d’architecture sont à la fois sur le plan fonctionnel et technique :
En revanche, comme toute solution technique, une architecture SPA présente également certaines contraintes qu’il vaut mieux anticiper, en particulier dans les projets avec de fortes exigences en SEO, en accessibilité ou qui nécessite un maintien sur le long terme.
L’objectif de la cour de cassation est de proposer un accès fiable, structuré et lisible à un vaste corpus de décisions et contenus juridiques. Cette proposition doit également répondre aux exigences spécifiques des institutions publiques en matière d’accessibilité, de transparence et de référencement naturel. L’objectif fonctionnel central est ici la diffusion de contenus textuels, hiérarchisés et facilement consultable par un large public, sans interactivité poussée.
Concernant l’architecture, le site repose sur une architecture MPA traditionnelle, générée côté serveur via un framework PHP. Ce choix assure une robustesse éprouvée, une simplicité de maintenance et une compatibilité native avec les moteurs de recherche, tout en limitant les dépendances JavaScript, ce qui en fait une solution particulièrement adaptée aux sites institutionnels à dominante éditoriale.
Les principaux bénéfices observés dans ce contexte applicatif expliquent pourquoi ce type d’architecture est souvent retenu pour des outils éditoriaux comme celui-ci :
Malgré ces avantages structurels, certains freins subsistent lorsqu’on s’intéresse à l’expérience utilisateur moderne ou à la possibilité d’introduire plus d’agilité dans l’interface :
Entre SPA pure et MPA classique, une nouvelle génération d’architectures hybrides permet de combiner les avantages de chaque modèle.
| Technologie | Principe | Usage idéal |
| Symfony UX + Turbo | Comportements interactifs progressifs avec Stimulus & Turbo | Plus rapide (HTML direct) |
| HTMX | Interactions HTML-over-the-wire sans JS custom | Projets full server avec logique métier centralisée |
| Next.js / Nuxt | SPA avec SSR, pré-rendering, routing optimisé | Applications complexes avec besoin SEO & UX |
Ces approches hybrides fonctionnent en combinant différents modes de rendu pour adapter le comportement de l’application aux besoins métier de chaque page.
Par exemple, un framework comme Next.js permet de mixer du Server Side Rendering (SRR) pour les pages critiques en SEO, du Static Site Generation (SSG) pour les pages rarement mises à jour, et du Client Side Rendering (CSR) pour les composants très interactifs.
Concrètement, cela signifie que l’on peut pré-générer certaines pages à la volée côté serveur (pour l’indexation et la performance initiale), tout en conservant la fluidité d’une SPA sur les interactions internes ou les modules applicatifs. Cela permet d’ajouter de l’interactivité là où c’est réellement utile, sans réécrire toute la logique applicative, ni renoncer au bénéfices SEO ou à la simplicité de maintenance.
Ce type d’architecture rassure les équipes techniques, reste soutenable en budget, et offre un compromis particulièrement efficace pour les projets publics ou mixtes, où coexistent exigences d’accessibilité, de performance et d’expérience utilisateur avancée.
Chez Adimeo, nous avons accompagné plusieurs projets où le choix d’architecture a été structurant. L’un d’eux concernait une plateforme métier avec de fortes exigences en matière de réactivité UX et de scalabilité. Après analyse, nous avons opté pour une architecture hybride basée sur Next.js, combinant le meilleur des deux mondes : un SEO solide grâce au SSR, et une UX fluide grâce au client-side rendering. À l’inverse, pour un site institutionnel public, le choix d’une MPA classique avec Drupal (base Symfony) s’est imposé naturellement pour des raisons de simplicité, d’accessibilité et de référencement.
Ne vous laissez pas guider uniquement par les effets de mode ou les préférences techno internes. Avant de trancher, prenez le temps d’avaluer vos réels besoins et vos contraintes projet et dès la phase de cadrage, posez-vous ces questions :
Bonnes pratiques à retenir
Pas besoin de partir sur une usine à gaz ou de réinventer la roue. Une architecture simple et bien cadrée vaut souvent mieux qu’un choix trop ambitieux mal maîtrisé.
Sur cette base, quelques bonnes pratiques peuvent guider votre décision :
Mal choisir son architecture applicative ne se traduit pas toujours pas des bugs visibles ou des échecs techniques immédiats. Le plus souvent, ce sont des décisions prises trop rapidement, sans suffisamment de recul métier ou organisationnel, qui fragilisent la suite du projet.
Je vous partage les quelques pièges récurrents qu’il est utile d’identifier dès la phase de cadrage :
Être attentif à ces écueils ne garantit par un projet parfait, mais permet d’éviter des erreurs coûteuses et de construire une base solide, à la fois techniquement et stratégiquement.
Pour conclure, bien choisir son architecture Web, c’est avant tout trouver le bon équilibre. La vraie question n’est plus « SPA ou MPA ? » mais plutôt : « De quoi a-t-on vraiment besoin et à quel moment ? ».
Dans la majorité des projets, un modèle hybride permet d’aller droit au but, sans sacrifier l’expérience utilisateur ni la simplicité technique. Le bon choix, c’est celui qui vous simplifie la vie… et celle de vos utilisateurs.
Vous avez un doute ? Chez Adimeo, nous accompagnons nos clients dans la conception d’architectures Web adaptées à leurs enjeux réels, sans dogme technologique. Nos interventions couvrent :
Crédit photo : TU IS