Symfony ou Laravel ? Mon avis après les deux en production
Sur cette page
Symfony ou Laravel ? Mon avis, après les deux en production : Laravel dès que j’ai le choix, Symfony quand le projet l’impose. Je travaille avec Symfony depuis 2017, de la version 3.4 à la version 7 aujourd’hui, et j’ai refait seul mon webzine, YubiGeek, en Laravel. Voici ce qui me fait pencher, et ce qui m’agace des deux côtés.
D’où je parle : Symfony et Laravel en production
D’octobre 2017 à novembre 2021, j’ai développé des projets web internes en Symfony 3.4, puis 4, dans la région d’Aix-en-Provence. Depuis octobre 2022, Symfony est au cœur de mon poste de développeur fullstack, à Marseille, avec Ibexa, une plateforme de gestion de contenus construite sur Symfony. J’y travaille aujourd’hui en Symfony 7.
Laravel, je l’ai appris pour moi : le cours d’OpenClassrooms en février 2020, puis YubiGeek, le webzine geek que j’avais fondé en 2015. En 2021 et 2022, je l’ai refait seul en Laravel 8 et Livewire, et c’est cette version qui a tourné en production.
Mon verdict : Laravel dès que j’ai le choix
Quand le choix me revient, je prends Laravel. C’est mon framework préféré : sa syntaxe se lit bien, des routes aux requêtes d’Eloquent ; Livewire rend une page dynamique sans écrire de JavaScript ; et un projet démarre vite, avec l’authentification, les files d’attente et les e-mails déjà prévus.
Quand le projet l’impose, c’est Symfony, et ce n’est pas une punition. Son cadre est clair, ses conventions tiennent sur les gros projets, ses versions LTS rendent les mises à jour prévisibles, et ses composants se réutilisent d’un projet à l’autre.
| Symfony | Laravel | |
|---|---|---|
| Ce que j’en fais | Mon travail, depuis 2017 | Mes projets : YubiGeek, refait seul |
| Version | 7 aujourd’hui | 8 pour YubiGeek |
| Ce qui me plaît | Un cadre clair, des conventions, des LTS, des composants réutilisables | Une syntaxe lisible, Livewire, un démarrage rapide |
| Ce qui m’agace | La configuration, la verbosité, la courbe d’apprentissage | Une version majeure par an, des outils payants |
| Base de données | Doctrine, que je préfère | Eloquent |
Pourquoi j’ai refait YubiGeek en Laravel
Je connaissais déjà Symfony. Pour YubiGeek, j’ai pourtant choisi Laravel, pour trois raisons : l’envie d’apprendre, Livewire, qui m’évitait d’écrire du JavaScript, et la vitesse, parce que j’étais seul à le développer.
Doctrine ou Eloquent : là, je préfère Symfony
C’est le paradoxe de mon avis : mon framework préféré est Laravel, mais pour la base de données, je préfère Doctrine, l’ORM de Symfony, à Eloquent, celui de Laravel.
Les deux ne pensent pas de la même façon. Avec Doctrine, une entité est un objet PHP ordinaire, qu’un gestionnaire enregistre en base (le modèle Data Mapper). Avec Eloquent, chaque modèle sait s’enregistrer lui-même (le modèle Active Record).
Ce qui m’agace dans Symfony, et dans Laravel
Dans Symfony : la configuration, la verbosité, et une courbe d’apprentissage raide pour un débutant.
Dans Laravel : le rythme et le prix. Le framework sort une version majeure chaque année, vers le premier trimestre, comme l’annonce sa documentation, et il faut suivre. Et les outils les plus pratiques de son écosystème, comme Forge ou Nova, sont payants.
Mon framework préféré est Laravel, et j’écris du Symfony tous les jours. C’est ce qu’on appelle un métier.
Symfony ou Laravel pour débuter en 2026 ?
Ni l’un ni l’autre : le PHP sans framework d’abord. C’est le même conseil que pour l’IA, que je donne dans mon avis sur le vibe coding : les fondamentaux d’abord.
J’ai appris le PHP sur le Site du Zéro et sur les forums, des années avant mon premier projet en Symfony. Ce que je fais aujourd’hui en Symfony et en Laravel est sur ma page d’expertise, et l’histoire complète est sur la page mon parcours.
Sources
- Laravel, notes de version et politique de versions (site externe), en anglais.
- Symfony, calendrier des versions (site externe), en anglais.