Laravel vs Symfony : mes réflexions de dev après quelques années à jongler entre les deux

Vendredi soir, call client. « On hésite entre Laravel et Symfony pour notre nouvelle plateforme. Tu conseillerais quoi ? » La question qui revient souvent.

Aujourd’hui on va parler du choix qui fait débat dans toutes les teams PHP : Laravel ou Symfony ? Après avoir bossé sur plusieurs projets avec les deux frameworks, accompagné des équipes qui utilisaient l’un ou l’autre, et vécu les joies et galères des deux écosystèmes, j’ai quelques retours à partager.

Pas de fanboying ici – juste du retour d’expérience concret sur ce qui marche, ce qui peut coincer, et surtout comment prendre une décision éclairée selon votre contexte. Parce qu’au final, c’est ça qui compte : pas le framework le plus « hype », mais celui qui va bien s’adapter à votre projet.

Le contexte qui change tout : rapidité vs robustesse

Première observation : il n’y a pas de « meilleur » framework absolu. Il y a le bon outil pour le bon contexte.

J’ai récemment travaillé sur un projet CRM avec Laravel. Petite équipe, deadline serrée, besoin de valider rapidement un concept de gestion client. Laravel a bien fait le job : authentification simple avec Breeze, gestion des contacts et leads, interface admin basique pour les commerciaux. On a livré dans les temps.

Sur un autre projet, plus gros, un ERP avec des besoins métier spécifiques et une perspective long terme, l’équipe avait choisi Symfony. Plus de configuration initiale, mais une architecture qui tenait mieux la route au fur et à mesure des évolutions fonctionnelles et des intégrations tierces.

Cette expérience illustre bien la différence : Laravel pour démarrer efficacement, Symfony pour des projets qui ont vocation à grossir et évoluer.

Architecture : les vraies différences qui comptent

mon-projet-laravel
├── app
│   ├── Console
│   ├── Exceptions
│   ├── Http
│   └── Providers
├── bootstrap
│   └── cache
├── config
├── database
│   ├── factories
│   ├── migrations
│   └── seeders
├── lang
├── public
│   └── index.php
├── resources
│   ├── js
│   ├── lang
│   └── views
├── routes
│   ├── api.php
│   ├── channels.php
│   ├── console.php
│   └── web.php
├── storage
│   ├── app
│   ├── framework
│   └── logs
├── tests
│   ├── Feature
│   └── Unit
└── vendor
Langage du code : Markdown (markdown)

mon-projet-symfony
├── bin
│   └── console
├── config
│   ├── packages
│   ├── routes
│   └── services.yaml
├── public
│   └── index.php
├── src
│   ├── Controller
│   └── Kernel.php
├── templates
├── tests
├── translations
├── var
│   ├── cache
│   └── log
└── vendor
Langage du code : Markdown (markdown)

Configuration et flexibilité

Laravel mise sur la « convention over configuration ». Moins de choix à faire, des décisions par défaut qui marchent bien. Leurs service providers et le container automatique font gagner du temps au démarrage.

// ServiceProvider basique dans Laravel
public function register() {
    $this->app->singleton(MyService::class, function ($app) {
        return new MyService();
    });
}Langage du code : PHP (php)

Symfony te laisse plus de liberté : yaml, xml, attributs PHP 8, configuration PHP pure. Plus d’options, plus de possibilités de personnalisation. Sur des projets avec des contraintes particulières, cette flexibilité peut être précieuse.

# Services.yaml dans Symfony
services:
  App\Service\MyService:
    arguments: []
    public: trueLangage du code : YAML (yaml)

Gestion des requêtes

Laravel : middleware pipeline. Logique, facile à comprendre pour une équipe qui découvre le framework.

// Middleware pipeline
Route::middleware(['auth'])->group(function () {
    Route::get('/dashboard', function () {
        // Logique ici
    });
});Langage du code : PHP (php)

Symfony : système d’événements. Plus de possibilités pour des logiques complexes, mais demande un peu plus d’expérience pour bien l’exploiter.

// EventListener dans Symfony
namespace App\EventListener;

use Symfony\Component\HttpKernel\Event\RequestEvent;

class CheckAuthListener {
    public function onKernelRequest(RequestEvent $event) {
        // Logique de vérification d'auth ici
    }
}Langage du code : PHP (php)

L’ORM : le point de divergence principal

Eloquent (Laravel) vs Doctrine (Symfony) – c’est souvent là que la différence se fait sentir.

Eloquent, c’est du Active Record : tes modèles ont des méthodes directes, tout semble naturel et intuitif. Parfait pour du CRUD standard et des relations classiques.

// Modèle Eloquent Laravel
class Article extends Model {
    protected $fillable = ['title', 'content', 'author_id'];
}Langage du code : PHP (php)

Doctrine, c’est du Data Mapper : séparation entre tes entités métier et la couche de persistence. Plus de code au début, mais plus de souplesse quand les besoins métier se complexifient.

// Entité Doctrine Symfony
/**
 * @ORM\Entity
 * @ORM\Table(name="articles")
 */
class Article {
    /**
     * @ORM\Column(type="string")
     */
    private $title;

    /**
     * @ORM\Column(type="text")
     */
    private $content;

    /**
     * @ORM\ManyToOne(targetEntity="User")
     */
    private $author;
}Langage du code : PHP (php)

Sur des projets simples, Eloquent fait gagner du temps. Sur des domaines métier riches avec des règles complexes, Doctrine montre ses avantages.

Performance : nuances importantes

Sur des applications classiques, les deux frameworks se valent largement. La différence de performance n’est pas le critère décisif.

Symfony a quelques atouts sur l’optimisation :

• Cache HTTP plus fin
• Container de services optimisé
• Profiler intégré pour identifier les points d’amélioration

Mais ces avantages ne se manifestent vraiment que sur des applications avec des contraintes de performance spécifiques.

Équipe et compétences : le facteur déterminant

Laravel : accessible mais attention aux pièges

Laravel attire par sa simplicité apparente. Eloquent, Blade, Artisan – tout paraît fluide. Le risque ? Cette simplicité peut masquer des problèmes.

J’ai vu des développeurs débutants faire des erreurs classiques : requêtes N+1 non détectées, utilisation excessive des Facades créant des couplages forts.

// Attention aux requêtes N+1 en Laravel
$articles = Article::with('author')->get(); // Charge author en eager loading pour éviter N+1
foreach ($articles as $article) {
    echo $article->author->name;
}Langage du code : PHP (php)

Symfony : plus exigeant mais formateur

Symfony demande un investissement initial plus important. Il faut comprendre l’injection de dépendances, les services, l’architecture en couches. Mais cette complexité encourage les bonnes pratiques.

// Récupération d'un service via le container
public function __construct(MyService $myService) {
    $this->myService = $myService;
}Langage du code : PHP (php)

Les développeurs qui maîtrisent Symfony ont généralement une bonne compréhension des principes architecturaux, ce qui leur sert sur tous leurs projets.

Écosystème : Laravel prend l’avantage

Laravel a un écosystème plus développé :

• Forge pour le déploiement
• Vapor pour le serverless
• Nova pour les interfaces admin
• Sanctum pour les APIs

Symfony rattrape avec ses bundles et Symfony Flex, mais Laravel garde une longueur d’avance sur l’outillage ready-to-use.

Côté communauté, Laravel est plus accessible. Documentation plus pédagogique, ressources plus nombreuses pour débuter.

Mes critères de choix pratiques

Pencher vers Laravel si :

• Équipe plutôt junior ou qui découvre PHP moderne
• Timeline serrée
• Projet avec des besoins fonctionnels classiques
• Besoin de monter rapidement en compétence

Pencher vers Symfony si :

• Équipe expérimentée
• Projet avec une perspective long terme
• Besoins métier complexes ou spécifiques
• Budget formation disponible

La réalité terrain : on change parfois d’avis

Anecdote récente : une équipe que j’accompagne a commencé avec Laravel sur un CRM interne. Après 18 mois, face à la complexification des workflows de vente et l’ajout de modules comptabilité, ils envisagent une refonte partielle avec Symfony pour certaines parties.

Ce n’est ni un échec ni une erreur – c’est l’évolution naturelle d’un projet qui grandit. Laravel leur a permis de valider le concept rapidement. Maintenant qu’ils comprennent mieux leurs besoins métier, ils peuvent choisir l’outil le plus adapté.

Mon analyse perso

Les deux frameworks sont excellents dans leur domaine. Le « mauvais » choix, c’est celui qui ne correspond pas à votre contexte : équipe, timeline, complexité du projet.

Si vous hésitez vraiment : commencez par celui qui vous fait livrer plus vite aujourd’hui, en gardant en tête que vous pourrez faire évoluer demain.

Et surtout, maîtriser les deux concepts (Active Record vs Data Mapper, convention vs configuration) vous donnera une vision plus riche de l’architecture web.