Une MPA en 2026, old fashioned mais plutôt pertinent.

Petit tour d’horizon

Nous sommes en fin d’été 2026, la première version de React date de 13 ans (2013), et presque toutes les solutions web sont désormais basées sur des frameworks JavaScript et des architectures de type Single Page Application (SPA).

Les bonnes vieilles applications Multi-Page (MPA) sont rapidement devenues ringardes face à la promesse d’interactivité et de fluidité offerte par les SPA. Je me souviens moi-même très bien du moment un peu vertigineux où, sur ma première page AngularJS, j’ai vu le DOM se mettre à jour sans rechargement de page**, ou encore quand** j’ai pu naviguer d’une vue à l’autre sans jamais quitter l’application.

Dans mon petit cercle de développeurs web freelances avec qui je travaille, presque systématiquement, quand un nouveau projet from scratch arrive, la question ne se pose même plus : ce sera un back en Node (Express ou Nest dans 99 % des cas) et un front dans la sainte trinité des SPA (React, Vue ou Angular).

Pourtant

Pourtant, si je pense sincèrement que, dans de nombreux cas, une séparation claire entre le front et le back s’avère totalement bénéfique, sur les projets que je dois gérer seul, avec des budgets et des délais serrés, je reste totalement convaincu que développer une application Multi-Page avec un bon gros PHP/Symfony reste souvent la solution la plus pragmatique.

Le Majestic Monolith

Derrière ce concept se cache David Heinemeier Hansson, le créateur de Ruby on Rails.

Ce dernier, quand il ne parle pas de sujets de société ou de politique, est absolument fascinant sur le plan technique et conceptuel, et il a une vision très claire (et souvent clivante) de ce que doit être une application web bien conçue.

Il défend l’idée que, pour la majorité des projets web, un monolithe bien structuré est souvent plus efficace qu’une architecture éclatée en microservices ou en SPA. Selon lui, la complexité introduite par la séparation front/back et la multiplication des services peut rapidement devenir un frein à la productivité et à la maintenabilité.

En résumé, le Majestic Monolith prône une approche où tout est centralisé, mais de manière organisée et réfléchie, permettant ainsi de gagner en simplicité et en efficacité.

Si le concept va bien au-delà de la simple question de séparer ou non le front et le back, il insiste sur l’importance de la cohérence et de ne pas over-engineer une application inutilement. L’objectif étant de pouvoir développer rapidement de nouvelles fonctionnalités sans sacrifier pour autant la qualité du code ou du rendu final.

Le rapport avec les MPA ?

Dans le cas où vous développez une SPA, pour un gain de fluidité et d’interactivité, vous devrez accepter d’ajouter une couche non négligeable de complexité :

La gestion de la synchronisation entre votre front-end et votre back-end.
- Il faudra rapatrier les données sous forme de JSON via de nombreux appels API.
- Agréger ces données côté front et les rendre utilisables dans votre application.
- Maintenir un état cohérent dans votre application front-end, souvent en utilisant des bibliothèques comme Redux, Pinia ou NgRx pour les plus acharnés.
La gestion des erreurs et des états de chargement côté front-end, pour garantir une expérience utilisateur fluide, même en cas de problèmes de communication avec le back-end.
L’hébergement est également un peu plus complexe, car il faudra maintenir à la fois le front-end et le back-end, souvent sur des serveurs ou des services distincts, ce qui peut ajouter des contraintes supplémentaires en termes de déploiement et de gestion des ressources.

Bref, tout cela, c’est du code en plus à écrire, maintenir et tester.

Petit exemple

Prenons un exemple concret : imaginez que vous deviez simplement créer un système d’authentification pour votre application web, quelque chose de simple, basé sur un couple login/mot de passe et un JWT côté client.

Côté back-end

Pour le back-end, vous auriez besoin de :

Créer une route pour l’authentification (par exemple, /login).
Vérifier les informations d’identification de l’utilisateur.
Générer un JWT si les informations sont correctes.
Retourner le JWT au client.

Exemple tout pourri en Node :

// Route /login
async function login(req, res) {
    const user = await findUserByEmail(req.body.email);
    if (!user || !passwordVerify(req.body.password, user.password)) {
        return res.status(401).json({ error: 'Invalid credentials' });
    }
    const token = generateJWT(user);
    return res.json({ token });
}

Côté front-end

Pour le front-end, vous auriez besoin de :

Créer un formulaire de connexion pour que l’utilisateur puisse entrer son email et son mot de passe.
Envoyer les informations d’identification au back-end via une requête HTTP (par exemple, fetch ou axios).
Recevoir le JWT en réponse et le stocker côté client (par exemple, dans le localStorage ou les cookies).
Injecter le JWT dans les en-têtes des requêtes HTTP ultérieures pour authentifier l’utilisateur auprès du back-end.

Et si le JWT ne contient pas d’informations sur l’utilisateur, vous devrez alors effectuer une requête supplémentaire au back-end pour récupérer les détails de l’utilisateur après l’authentification.

Retour côté back-end

Lorsque le front-end effectue une requête pour récupérer les détails de l’utilisateur après l’authentification, le back-end doit :

Vérifier le JWT envoyé dans les en-têtes de la requête.
Extraire l’identité de l’utilisateur à partir du JWT.
Récupérer les détails de l’utilisateur depuis la base de données.
Retourner les détails de l’utilisateur au front-end.

Exemple tout pourri en Node :

// Route /me pour récupérer les détails de l'utilisateur
async function getUserDetails(req, res) {
    const token = req.headers['authorization']?.split(' ')[1];
    if (!token) {
        return res.status(401).json({ error: 'No token provided' });
    }
    const userId = verifyJWT(token);
    if (!userId) {
        return res.status(401).json({ error: 'Invalid token' });
    }
    const user = await findUserById(userId);
    return res.json({ user });
}

Retour côté front-end

Vous avez récupéré les informations de l’utilisateur, vous allez pouvoir les parser, les stocker dans l’état de votre application et mettre à jour l’interface utilisateur en conséquence.

Ce n’est rien de fondamentalement compliqué, mais c’est un exemple typique de la manière dont un front-end et un back-end peuvent interagir pour gérer l’authentification et la récupération des informations utilisateur.

Cela fait beaucoup de code. Du code qui peut planter, qu’il faut maintenir et sécuriser.

Trust the boring tech

Et c’est là que j’en arrive à nos good old MPA.

Pour moi, une MPA, c’est se baser sur un framework backend capable de générer directement des templates HTML. Dans ce cas, pas d’API séparée, pas de JWT à faire circuler entre le client et le serveur, pas d’état à synchroniser…

Votre identification se base sur les protocoles classiques de gestion de session HTTP, comme les cookies de session. Les principaux frameworks backend gèrent cela depuis des années : c’est un problème largement résolu.

Une fois connecté, vous aurez toujours accès aux informations de l’utilisateur directement depuis le serveur via une méthode du genre getUser(), que vous pourrez exploiter partout dans l’application (y compris dans vos templates HTML).

La seule chose que vous aurez à faire, c’est créer une jolie page HTML avec un formulaire de connexion classique, ajouter une petite protection CSRF (largement gérée par les frameworks backend modernes), et le reste est pris en charge automatiquement.

C’est pour moi le plus gros point fort de l’application Multi-Page, toutes les couches de votre application sont contenues au même endroit. Vous pouvez donc faire transiter l’information et l’état de votre base de données sur l’ensemble de votre application sans avoir à gérer des mécanismes complexes de synchronisation entre le front-end et le back-end.

Moins de code, moins de risques de plantage, et moins de complexité à gérer pour vous en tant que développeur.

En tant que freelance ou développeur solo

Si vous devez mener un projet from scratch en solo, vous devez vous focaliser sur la création de valeur. Créer de la valeur, c’est livrer des fonctionnalités robustes et utiles à vos utilisateurs, plutôt que de passer trop de temps à gérer des complexités techniques inutiles.

Le temps que vous gagnez à ne pas avoir à faire de la glue entre votre front-end et votre back-end peut être investi dans l’architecture technique de votre application, dans l’écriture d’un code plus robuste (DDD, TDD, Clean Code…) et dans l’amélioration continue de votre produit.

Oui, mais l’UX reste naze sur une MPA

C’est effectivement vrai : sur une application Multi-Page, l’expérience utilisateur est, par défaut, un peu moins sexy que sur une application Single-Page. Nous verrons qu’il existe des solutions pour atténuer cela, mais avant tout, je vous invite à vous poser quelques questions sur les besoins réels de vos utilisateurs et sur les priorités de votre projet.

Si vous réalisez une application B2B qui doit répondre à des cas d’utilisation professionnels bien précis, est-il vraiment important que toute l’UI se mette à jour en temps réel ?

La plupart des applications B2B que j’ai développées se sont avérées être, en réalité, des formulaires plus ou moins interactifs et des listes de données triables. La majeure partie de la complexité de ces applications réside souvent dans la gestion des règles métier et des permissions, plutôt que dans l’interface utilisateur elle-même.

De plus, le CSS d’aujourd’hui permet bien souvent de créer des interfaces visuellement attractives sans bombarder le client avec du JavaScript. Une grande partie de l’aspect plaisant d’une interface utilisateur repose sur son design et la manière dont les éléments sont disposés et animés, plutôt que sur des interactions dynamiques complexes.

Donc, avant de vous lancer dans la création d’une SPA complexe, demandez-vous si cela apporte réellement de la valeur à vos utilisateurs, ou si une MPA bien conçue peut suffire.

En plus de cela, il existe des solutions JavaScript minimalistes qui permettent de faire passer votre bonne vieille application Multi-Page pour une SPA, mais j’en parlerai dans un prochain article.

Pour nos “amis” Vibe-Codeurs

Si vous faites partie de ces personnes qui se vantent de ne plus avoir écrit une ligne de code depuis des mois, voire de n’en avoir jamais écrit de leur vie, sachez que l’approche MPA peut être intéressante. Pourquoi ? Parce qu’elle a pour avantage de rassembler tout votre contexte applicatif au sein d’un seul et même monolithe. Il est donc plus simple pour votre agent de développer des fonctionnalités complètes : en une seule session de code, il peut dérouler l’ensemble des couches de l’application, de la requête SQL jusqu’au design du rendu front-end, sans avoir à jongler entre différents contextes ou frameworks.

Les inconvénients de la MPA

Évidemment, les applications Multi-Page ne sont pas la solution parfaite pour tous les projets. Même si l’on met de côté le rechargement complet des pages, on peut noter quelques cas où ce type de configuration complique la vie.

Vous avez plusieurs front-ends : Typiquement, une application web et une application mobile. Si votre serveur est configuré pour générer du HTML au lieu du JSON, vous allez avoir des difficultés pour diffuser vos données vers votre application mobile. On peut évidemment créer des endpoints spécifiques pour une API, mais cela demande un effort supplémentaire de conception logicielle pour éviter de dupliquer la logique métier. Typiquement, il faudrait séparer votre logique métier dans des Use Cases distincts, qui pourraient être réutilisés par des controllers différents selon le front-end ciblé. C’est faisable, mais cela demande un certain niveau de discipline et une architecture bien pensée.
Votre application est très interactive : Si votre application nécessite beaucoup d’interactions en temps réel, comme des mises à jour instantanées ou des fonctionnalités de type chat, une MPA peut devenir lourde et moins réactive. Dans ce cas, une SPA ou une approche hybride pourrait offrir une meilleure expérience utilisateur.

Retours d’expérience et conclusions

De mon côté, depuis la création de Shifumi, j’ai développé trois applications métier from scratch, et pour les raisons évoquées plus haut, j’ai opté pour l’approche Multi-Page.

Que ce soit pour la phase de développement initiale, la maintenance ou l’évolution des fonctionnalités, aujoud’hui enocre, c’est un choix que je défends.

Pendant le développement, j’ai pu itérer plus rapidement sur les fonctionnalités, tout en consacrant plus de temps à l’architecture et à la qualité du code.

Pour la maintenance, le debug est plus rapide et aussi un peu plus simple. La stack trace est plus facile à suivre sur un gros monolithe.

Enfin, pour l’évolution des fonctionnalités, il est plus aisé d’ajouter de nouvelles fonctionnalités sans se soucier de la synchronisation entre plusieurs front-ends ou de la complexité d’une architecture distribuée.

Un cas typique ou l’apporche MPA est super utile, c’est avec l’IA. Une fois que j’ai terminé de préparer un usecase metier (assisté ou non par l’IA), je peux demander a un agent de générer une vue à partir du code métier sans avoir à switcher de projet et de préparer un contexte spécifique, je lui passe simplement mon usecase, un brief de ce que je veux voir affiché et je le laisse travailler. Si ça ne correspond pas à 100% à ce que j’avais en tête, je peux ajuster à la main ou relancer l’agent avec des instructions supplémentaires.

Quand on travaille en freelance, la vélocité gagnée grâce à cette approche est vraiment précieuse. Mes clients reviennent souvent vers moi pour de petites évolutions ponctuelles sur ces applications, et je peux intervenir rapidement, même lorsque je suis occupé sur d’autres projets en parallèle.

Cela me permet de maintenir un bon niveau de satisfaction client, tout en optimisant mon temps et mes ressources.

En conclusion, même en 2026, je continue de considérer l’approche Multi-Page, et plus globalement le bon gros monolithe, comme une solution viable et efficace pour de nombreux projets web, surtout lorsque je suis le principal développeur sur ces projets.