Chapitre 1.4 — Symfony vs le monde : Laravel, Node, et les API routes de Next.js

Partie 1 : Découvrir Symfony — Chapitre 4/5 Version de référence : Symfony 7.4 LTS (novembre 2025, PHP 8.2+).

⏱️ TL;DR

• vs Laravel (l’autre grand framework PHP) : même langage, philosophies opposées. Laravel = conventions + magie + rapidité de prototypage ; Symfony = explicite + découplé + stabilité long terme. Laravel est d’ailleurs bâti sur des composants Symfony.
• vs Node : Express ≈ micro-framework (vous assemblez tout) ; NestJS ≈ le cousin conceptuel de Symfony (DI, décorateurs, structure). Symfony apporte en plus 20 ans de stabilité et un full-stack complet.
• vs les API routes de Next.js : parfaites pour un BFF léger, elles montrent leurs limites dès qu’apparaissent un vrai modèle de données, des transactions, des jobs asynchrones, de l’auth sérieuse, un back-office. C’est là que Symfony prend le relais derrière votre Next.js.
• PHP est rapide en 2026 (moteur PHP 8 + JIT, OPcache, FrankenPHP en mode worker). Le vieux cliché « PHP lent » est faux.
• La bonne question n’est pas « Symfony ou Next.js » mais « Symfony backend + Next.js frontend ». C’est le combo de ce cours.

🎯 Objectifs

• Choisir en connaissance de cause entre Symfony et Laravel selon le contexte.
• Situer Symfony par rapport à Express et NestJS.
• Reconnaître le moment où les API routes de Next.js « ne suffisent plus » et où un backend Symfony s’impose.
• Démonter les idées reçues sur la performance de PHP.

1. Le bon cadrage : ce n’est pas « ou », c’est « et »

Avant les comparaisons, plantons le décor. Vous êtes développeur Next.js. La question qui compte pour vous n’est pas « faut-il abandonner Next.js pour Symfony ? » — évidemment non. C’est :

Quand une application a besoin d’un vrai backend, où placer la frontière, et pourquoi Symfony est un excellent choix côté serveur ?

L’architecture cible de ce cours (et du marché où vous serez rare) :

Next.js gère l’expérience (rendu, SEO, UI, edge) ; Symfony gère le fond (modèle de données complexe, règles métier, sécurité, transactions, tâches de fond, intégrations). Les comparaisons ci-dessous éclairent pourquoi Symfony est taillé pour ce rôle.

2. Symfony vs Laravel

Les deux dominent le PHP moderne. Ils partagent le langage et… une partie du code (Laravel utilise HttpFoundation, Routing, Console, Mailer… de Symfony). Mais leurs philosophies divergent :

La différence d’ORM résume bien l’esprit : Eloquent (Active Record) met la logique de persistance dans l’entité ($user->save()) — pratique, rapide à écrire. Doctrine (Data Mapper) sépare l’entité (un objet PHP pur) de la persistance (gérée par un EntityManager) — plus verbeux, mais l’entité reste testable et découplée de la base. C’est la même opposition « magie vs explicite » qu’au niveau framework (Partie 6).

💡 Pour un dev Next.js : Laravel, c’est un peu l’esprit « Rails/Remix » (conventions fortes, DX au premier plan). Symfony, c’est l’esprit « NestJS/Angular » (structure, DI, explicite, entreprise). Aucun n’est « meilleur » dans l’absolu ; ils optimisent des choses différentes. Pour un backend d’API durable derrière Next.js, la rigueur et la stabilité de Symfony sont des atouts.

⚠️ Piège : « Laravel est plus simple, donc mieux » est un raccourci. La simplicité de départ de Laravel a un coût à l’échelle (magie difficile à tracer, couplage). La verbosité de départ de Symfony est un investissement qui paie sur les gros projets et le long terme. Choisissez selon l’horizon du projet, pas selon la première heure de code.

3. Symfony vs Node.js (Express, NestJS)

Côté JavaScript serveur, deux repères :

• Express est un micro-framework : un routeur HTTP minimal, à vous d’assembler validation, ORM, auth, structure. Rapide pour un petit service, mais vous réinventez l’architecture à chaque projet. Symfony, à l’inverse, fournit tout cet assemblage, cohérent et documenté.

• NestJS est le cousin conceptuel de Symfony côté Node : injection de dépendances, décorateurs (l’équivalent des attributs PHP), modules, structure imposée, inspiration Angular/Spring. Si vous connaissez NestJS, vous serez frappé par la proximité : @Injectable() ↔ un service Symfony, @Controller()/@Get() ↔ #[Route], les providers ↔ le conteneur de services.

Ce que Symfony apporte en plus de NestJS : un full-stack complet et mûr (moteur de templates Twig, formulaires, sécurité, temps réel, admin), une stabilité rare (BC promise, LTS), et un langage — PHP 8+ — pensé pour le web côté serveur (démarrage par requête, pas de fuite d’état entre requêtes, typage riche).

💡 Pour un dev Next.js : si vous aimez NestJS, vous aimerez Symfony — c’est la même rigueur, avec plus de recul et un écosystème « batteries incluses » plus fourni. Si vous ne juriez que par Express pour sa légèreté, sachez que Symfony peut aussi être minimal (grâce à Flex) puis grandir : vous n’êtes pas obligé de tout activer d’un coup.

4. Symfony vs les API routes / Route Handlers de Next.js

Le point le plus important pour vous. Next.js sait faire du backend : Route Handlers (app/api/.../route.ts), Server Actions, accès direct à une base. Pour beaucoup de cas, c’est suffisant — et il ne faut pas sur-architecturer. Mais il y a un seuil au-delà duquel un backend dédié (Symfony) devient le bon choix.

Le raisonnement clé : les Route Handlers de Next.js sont pensés pour un modèle serverless, sans état, orienté requête courte. Dès que le métier devient central — un vrai domaine, des transactions, des traitements de fond, une administration, plusieurs consommateurs de l’API — vous voulez un serveur applicatif dédié, avec état maîtrisé, outillage métier et sécurité de premier ordre. C’est exactement le terrain de Symfony.

💡 Pour un dev Next.js : la règle empirique — « quand vos API routes commencent à ressembler à un backend, donnez-leur un vrai backend ». Vous ne jetez pas Next.js : il redevient ce qu’il fait de mieux (le front, le SSR/RSC, le SEO, l’edge) et appelle votre API Symfony. C’est BookLab (Partie 11).

⚠️ Piège : ne basculez pas tout vers Symfony par principe. Pour un site vitrine, un blog, un petit formulaire de contact, un BFF de 3 routes — restez en Next.js. Le sur-découpage a un coût (deux déploiements, du réseau, du CORS). Symfony gagne quand le métier justifie un backend ; pas avant.

5. « Mais PHP, c’est lent/vieux, non ? » — non.

Le cliché a 15 ans de retard. En 2026 :

• Le moteur PHP 8 est plusieurs fois plus rapide que PHP 5/7, avec un JIT et un OPcache qui compile et met en cache le bytecode.
• PHP est typé (types stricts, enums, readonly, génériques via PHPStan) — proche de TypeScript côté rigueur (Partie 2).
• FrankenPHP (un serveur applicatif moderne écrit en Go) fait tourner Symfony en mode worker : l’application est bootstrappée une fois et sert des milliers de requêtes sans tout réinitialiser — des performances comparables à Node, avec en prime le HTTP/3, le early hints, et un binaire unique (Partie 15).
• Le modèle « une requête = un état propre » de PHP élimine par construction toute une classe de bugs de fuite d’état entre requêtes qui guette les serveurs Node long-running.

📚 Aller plus loin : jetez un œil à frankenphp.dev . Le mode worker + Symfony Runtime change la donne côté perf ; on le mettra en place en Partie 15.

⚡ Depuis Symfony 5 : à votre époque Symfony 5, on déployait surtout en PHP-FPM + Nginx (un process PHP par requête). Ça marche toujours très bien, mais l’option FrankenPHP worker mode (2023+) est la vraie nouveauté perf de la dernière génération. Gardez-la en tête ; on y arrive en fin de parcours.

6. Guide de décision (à garder)

• Petit site / BFF / blog / vitrine → Next.js seul (éventuellement un CMS headless).
• Produit à itérer très vite, équipe PHP orientée conventions → Laravel possible.
• Backend durable, API multi-consommateurs, domaine riche, entreprise, long terme, derrière un front Next.js → Symfony. C’est notre cas.
• Microservice JS existant, équipe 100 % Node → NestJS reste cohérent ; Symfony si vous voulez la stabilité PHP et son full-stack.

✏️ Exercices

Exercice 1. Un client vous demande un backend pour une plateforme de réservation multi-prestataires, avec paiement, e-mails automatiques, back-office et une app mobile prévue plus tard. Il hésite à « tout mettre dans les API routes de Next.js ». Que recommandez-vous, avec trois arguments ?

Exercice 2. En quoi NestJS est-il le meilleur point de comparaison pour un dev JS qui découvre Symfony ? Donnez trois correspondances de concepts.

Exercice 3. Vrai ou faux : « PHP est trop lent pour un backend sérieux en 2026. » Justifiez.

🧠 Quiz de révision

Prochain chapitre : 1.5 — Anatomie mentale d’une requête — le trajet requête → réponse, le front controller, où vit quoi. La carte à garder pour tout le cours.