Laravel ou Symfony pourquoi j'ai tranché
J'ai développé en Symfony de 2013 à 2015, puis j'y suis repassé ponctuellement en 2020. Depuis, je livre en Laravel, et Symfony ne figure plus dans les technologies que j'affiche. Cette page explique cette décision.
Elle n'est pas neutre, et je préfère le dire tout de suite plutôt que de le laisser deviner. Elle essaie en revanche d'être honnête, ce qui n'est pas la même chose : je dis aussi ce que Symfony fait mieux, et pourquoi mon expérience a une limite de validité.
Mon Symfony n'est pas le Symfony d'aujourd'hui
C'est la précaution que je vois rarement dans les comparatifs, et elle change pourtant la valeur de tout ce qui suit. L'essentiel de ma pratique de Symfony se situe entre 2013 et 2015, c'est-à-dire à l'époque de Symfony 2 : configuration en YAML, architecture en bundles, beaucoup de cérémonie avant la première ligne utile.
Symfony a considérablement changé depuis. L'autoconfiguration et l'autowiring ont réduit la configuration à presque rien, l'organisation en bundles n'est plus imposée pour le code applicatif, et l'installation de composants s'est simplifiée. Mon passage de 2020 me l'a confirmé : plusieurs des reproches que je formulais en 2015 ne tenaient plus.
Autrement dit, si vous cherchez un verdict sur Symfony dans sa version actuelle, je ne suis pas la bonne personne. Ce que je peux dire tient à ce que j'ai vérifié en livrant.
Trois raisons, et aucune n'est « Laravel est plus moderne »
-
01
La simplicité, au sens de moins de choses à décider avant de commencer
Sur un projet neuf, Laravel me fait arriver à la première fonctionnalité utile plus vite. Ce n'est pas de la paresse : chaque décision d'architecture prise trop tôt, avant de connaître le vrai besoin, est une décision prise avec le moins d'information possible. Symfony 2 me demandait beaucoup de ces décisions dès le premier jour.
-
02
La modularité, qui n'est pas l'inverse de la simplicité
Ce qui m'a retenu, c'est de pouvoir démarrer simplement sans être bloqué ensuite. Le conteneur de services, les événements et les contrats de Laravel permettent de découpler quand le projet le réclame, au moment où il le réclame. Je commence direct, je structure quand la complexité arrive, et je n'ai jamais eu à tout reprendre pour ça.
-
03
L'écosystème et la communauté, et c'est le facteur décisif
C'est là que l'écart est le plus large et le plus vérifiable. Laravel fournit d'origine ce que la plupart des projets finissent par avoir besoin : file d'attente supervisée, authentification, facturation, recherche, temps réel, débogage, déploiement. Côté Symfony, ces briques existent aussi, mais elles sont plus souvent à assembler soi-même ou à choisir parmi des bundles tiers dont la maintenance varie. Pour quelqu'un qui livre seul, cette différence se compte en semaines.
Symfony est plus rigide, et cette rigidité protège
Honnêtement, je ne vois pas grand-chose que Symfony fasse nettement mieux au quotidien. Sauf une chose, et elle n'est pas mince : il laisse beaucoup moins de latitude, donc beaucoup moins d'occasions de mal faire.
L'exemple le plus concret est l'analyse statique. Les facades de Laravel, les propriétés dynamiques d'Eloquent et l'usage des méthodes magiques rendent une partie du code difficile à comprendre pour un analyseur : il faut lui expliquer ce que le framework fait à l'exécution. C'est précisément la raison d'être des extensions dédiées à Laravel qui existent dans l'écosystème PHPStan. Le code Symfony, avec son injection de dépendances explicite et ses constructeurs typés, se prête beaucoup plus naturellement à une analyse stricte, sans outillage de compensation.
La conséquence est très concrète : sur une équipe nombreuse, une équipe qui tourne, ou un projet destiné à vivre longtemps entre des mains changeantes, l'explicite de Symfony fait sortir plus tôt des erreurs que Laravel laisserait passer jusqu'à l'exécution. Si je devais livrer à dix développeurs de niveaux inégaux, j'y réfléchirais sérieusement.
Choisir Laravel, c'est déjà faire tourner du Symfony
C'est le point que les comparatifs oublient le plus souvent, et il est vérifiable en
trente secondes : ouvrez le fichier composer.json
de n'importe quelle application Laravel. Vous y trouverez des composants Symfony, parmi
lesquels la couche de requête et de réponse HTTP, le routage, la console et la gestion des
processus.
Laravel n'a pas réécrit ces fondations, il s'est construit dessus. Ce que vous choisissez en prenant l'un ou l'autre, ce n'est donc pas une technologie contre une autre : c'est une couche d'ergonomie posée sur une base commune, contre cette base employée directement.
Ça relativise beaucoup le débat. Les deux camps partagent une partie de leur ingénierie, et les compétences acquises d'un côté ne sont pas perdues de l'autre. C'est aussi pourquoi je n'ai aucun mal à relire du Symfony aujourd'hui, alors que je n'en écris plus.
Je prendrais Laravel
- Pour une équipe de une à trois personnes, où la vitesse de livraison prime.
- Quand le projet a besoin tôt d'une file d'attente, d'une authentification ou d'un back-office, briques fournies d'origine.
- Quand le périmètre va bouger, parce que la structure peut arriver plus tard sans tout reprendre.
- Quand il faut recruter vite : le vivier francophone et les ressources de formation sont plus abondants.
Je regarderais Symfony
- Pour une équipe nombreuse ou qui tourne, où l'explicite vaut mieux que le concis.
- Quand l'analyse statique stricte est une exigence du projet et non une option.
- Quand l'application doit vivre des années sans reprise fréquente, où le support long compte.
- Quand l'équipe en place le pratique déjà. C'est de loin le meilleur argument des cinq.
Sur les questions voisines, j'ai détaillé le choix entre freelance et agence et celui entre régie et forfait. Et mon parcours détaille ce que je pratique réellement aujourd'hui.
Laravel est-il meilleur que Symfony ?
Non, et la question est mal posée. Les deux produisent des applications solides, et Laravel s'appuie d'ailleurs sur plusieurs composants Symfony pour fonctionner. Ce qui les sépare est une philosophie : Laravel optimise la vitesse d'écriture et la richesse de l'outillage fourni, Symfony optimise l'explicite et la vérifiabilité. J'ai choisi Laravel parce que je livre seul ou en très petite équipe, pas parce que Symfony serait moins bon.
Symfony est-il plus adapté aux gros projets ?
C'est une idée reçue tenace, et elle est fausse telle quelle. Ce qui tient un gros projet, c'est l'architecture, les tests et la discipline d'équipe, pas le framework. Symfony aide davantage sur un point précis : son injection de dépendances explicite et son absence de facades rendent le code plus lisible pour un analyseur statique, donc les erreurs de structure sortent plus tôt. Sur une équipe nombreuse ou tournante, c'est un vrai gain.
Faut-il apprendre Symfony avant Laravel ?
Non. L'ordre inverse est même plus confortable : Laravel fait tomber les premières applications plus vite, ce qui laisse le temps de comprendre les concepts avant d'affronter la configuration explicite. Ceux qui commencent par Symfony apprennent la rigueur d'abord et la productivité ensuite ; les deux chemins mènent au même endroit.
Peut-on migrer un projet Symfony vers Laravel ?
Techniquement oui, mais c'est rarement une bonne idée en soi. Une réécriture de framework coûte des mois et n'apporte aucune fonctionnalité à vos utilisateurs. Elle se justifie quand la vraie raison est ailleurs : plus personne ne sait maintenir le code existant, ou la version en place n'est plus supportée. Le framework de destination est alors la conséquence de la décision, pas sa cause.