Chapitre 8.4 — Symfony UX vs SPA React : où placer la frontière

Partie 8 : Symfony UX — Chapitre 4/4 Version de référence : Symfony 7.4 / Next.js 15.

⏱️ TL;DR

Ce n’est pas « UX ou React », c’est « quelle partie mérite quoi ». Les deux coexistent dans BookLab.

Symfony UX gagne pour : back-office, CRUD interne, contenus SEO, formulaires, quand on veut peu de JS, un seul langage/déploiement et du progressive enhancement.

La SPA (Next.js) gagne pour : UI riche à état client, offline, interactions à haute fréquence, app mobile partageant l’API, edge/CDN, et l’immense écosystème React.

Le coût de Symfony UX = un aller-retour serveur par interaction. Le coût d’une SPA = une API à bâtir + du JS/état à gérer + du SEO à soigner.

BookLab tranche : back-office admin en Symfony UX ; front public de réservation en Next.js consommant l’API. C’est l’architecture de tout le cours.

Vous maîtrisez désormais les deux mondes — c’est ce qui vous rend rare (Partie 17).

🎯 Objectifs

Comparer honnêtement Symfony UX et une SPA React.
Identifier les critères de décision.
Appliquer la frontière à BookLab.
Assumer un choix d’architecture argumenté.

1. Deux modèles, deux courbes

Symfony UX part du HTML serveur et ajoute juste ce qu’il faut de réactivité (progressive enhancement). Le curseur monte de « statique » à « très interactif » progressivement.
La SPA part de l’état client et consomme une API. Très interactive dès le départ, au prix d’une API et d’une complexité front.

2. Le comparatif honnête

Critère	Symfony UX	SPA Next.js
Quantité de JS	Faible	Élevée
SEO / contenu indexable	Natif (HTML serveur)	À soigner (SSR/RSC)
API séparée nécessaire	Non	Oui
Interactivité riche (état client)	Limitée (round-trips)	Excellente
Offline / PWA	Faible	Fort
App mobile partageant le back	Non (pas d’API)	Oui (l’API sert web + mobile)
Vitesse de développement (CRUD/admin)	Très rapide	Plus lente (front + API)
Un seul langage / déploiement	Oui (PHP/Twig)	Non (PHP + TS, 2 déploiements)
Écosystème de composants UI	Modeste	Immense (React)
Temps réel	Turbo + Mercure (déclaratif)	Mercure/WebSocket côté client

Aucun n’est « meilleur ». Ils optimisent des choses différentes.

3. Les critères de décision

Posez-vous, écran par écran :

Cet écran a-t-il besoin d’un état client riche (interactions instantanées, manipulation locale complexe, offline) ? → SPA.
Est-ce du contenu qui doit être référencé / robuste sans JS ? → serveur (UX).
Plusieurs clients consommeront-ils la même logique (web + mobile + partenaires) ? → une API (donc SPA/headless côté web).
Est-ce un CRUD / back-office interne ? → Symfony UX (rapidité imbattable).
Quelle est la contrainte réseau ? Round-trips acceptables → UX ; latence critique / haute fréquence → SPA.

⚠️ Piège des deux camps : (1) le fan de React qui monte une SPA + une API pour un back-office CRUD de 5 écrans — surdimensionné, lent à livrer. (2) le puriste serveur qui force LiveComponents sur une UI ultra-interactive offline — frustrant pour l’utilisateur. Choisissez selon l’écran, pas selon l’idéologie.

4. La frontière de BookLab

BookLab applique la règle « le bon outil pour chaque face » :

Back-office admin (prestataires, réservations, stats) : Symfony UX. C’est interne, CRUD-lourd, sans besoin de SEO ni d’offline. On le livre vite (EasyAdmin + quelques LiveComponents pour la recherche/filtres).
Front public de réservation (parcours client, SEO, UX soignée, futur mobile) : Next.js consommant l’API Symfony (Parties 10-12). État client riche, edge, écosystème React.

C’est exactement l’architecture premium évoquée depuis la Partie 1 : Symfony fait le fond et sert les deux visages, chacun avec la techno adaptée.

5. Pourquoi maîtriser les deux vous rend rare

La plupart des développeurs sont soit « full JS » (React partout, y compris là où c’est excessif), soit « full serveur » (Twig partout, y compris là où une SPA s’impose). Savoir placer la frontière — et implémenter les deux côtés — est une compétence d’architecte, rare et bien valorisée (Partie 17). Vous ne « choisissez pas un camp » : vous choisissez, par écran, l’outil qui sert le mieux l’utilisateur et le budget.

💡 Pour un dev Next.js : cette partie ne vous demande pas d’abandonner React — elle vous donne une corde de plus à votre arc. Sur une mission, proposer « back-office EasyAdmin/UX livré en 3 jours + front Next.js soigné sur l’API » est une offre plus maligne (et moins chère à produire) que « tout en SPA ». C’est un argument commercial autant que technique.

✏️ Exercices

Exercice 1. Pour chacun de ces écrans de BookLab, choisissez UX ou SPA et justifiez : (a) tableau de bord admin des réservations ; (b) page publique « réserver un créneau » ; (c) éditeur de disponibilités en glisser-déposer temps réel côté prestataire.

✅ Solution

(a) Symfony UX : interne, CRUD, pas de SEO/offline, livraison rapide (EasyAdmin + LiveComponents). (b) Next.js SPA (sur l’API) : public, SEO important, UX soignée, futur mobile — le front premium. (c) SPA / JS riche : le glisser-déposer temps réel au pixel exige un état client (les round-trips d’un LiveComponent seraient trop lents) — soit un composant React dans le front Next.js, soit du JS/Stimulus local avancé, avec synchro via Mercure.

Exercice 2. Un client veut « une app moderne ». Un dev propose tout en SPA React + API. Pour un back-office admin de 6 entités, quel contre-argument donnez-vous ?

✅ Solution

Pour un back-office CRUD interne, une SPA + API est surdimensionnée : il faut bâtir et sécuriser une API, gérer l’état et le routage front, soigner l’auth SPA — pour un gain d’UX marginal sur des écrans d’administration. EasyAdmin/Symfony UX livre le même résultat en une fraction du temps (et du budget), avec un seul langage/déploiement. On réserve la SPA au front public où l’UX et le SEO comptent vraiment. « Moderne » ne veut pas dire « SPA partout ».

Exercice 3. Formulez en une phrase la règle de décision UX vs SPA.

✅ Solution

« On choisit par écran : rendu serveur (Symfony UX) pour le CRUD interne, le SEO et la rapidité de livraison ; SPA (Next.js sur l’API) pour l’état client riche, l’offline, le mobile partagé et les UI très interactives. »

🧠 Quiz de révision

1. La question est-elle « UX ou SPA » ?

Non : c’est « quel écran mérite quoi ». Les deux coexistent ; on place la frontière selon les besoins de chaque écran.

2. Deux forces de Symfony UX ?

Au choix : SEO natif, pas d’API à bâtir, peu de JS, un seul langage/déploiement, rapidité de livraison (CRUD/admin), progressive enhancement.

3. Deux forces d’une SPA Next.js ?

Au choix : état client riche, offline/PWA, interactions haute fréquence, API partagée avec le mobile, edge/CDN, écosystème React.

4. Comment BookLab répartit-il UX et SPA ?

Back-office admin en Symfony UX (interne, CRUD, rapide) ; front public en Next.js consommant l’API (SEO, UX riche, mobile futur). Le cœur Symfony sert les deux.

5. Pourquoi maîtriser les deux est-il un atout ?

Parce que placer la frontière et implémenter les deux côtés est une compétence d’architecte, rare et valorisée — on choisit le bon outil par écran, pas un camp.

Fin de la Partie 8. Vous savez rendre un back-office réactif sans SPA (Stimulus, Turbo, LiveComponents) et décider quand une SPA Next.js s’impose. La frontière de BookLab est claire. Place maintenant aux formulaires, puis à la sécurité et à l’API pour Next.js.

Prochaine étape : Partie 9 — Formulaires, validation & upload — collecter et valider des données proprement.