La question du framework n'est pas triviale

Choisir un framework, c'est choisir avec qui on va travailler pendant des années. C'est choisir une communauté, une philosophie, une façon de penser les problèmes. Ce choix a des conséquences sur la productivité, sur la maintenabilité des projets, sur les compétences qu'on accumule.

J'ai évalué plusieurs options avant de me fixer sur Laravel. Voici pourquoi j'ai écarté les alternatives et pourquoi Laravel reste mon choix sur tous les projets, en 2026.

Pourquoi pas Symfony

Symfony est excellent. C'est un framework mature, bien architecturé, utilisé dans des projets critiques à grande échelle. Des équipes entières l'utilisent avec raison.

Mais Symfony est verbeux. Configurer une application Symfony de zéro, c'est beaucoup de YAML, beaucoup de dossiers, beaucoup de services à déclarer explicitement. Pour des projets solo ou des équipes réduites, cette verbosité est une charge sans contrepartie équivalente.

Symfony brille sur des architectures complexes avec de nombreux développeurs, des niveaux de séparation stricts, des besoins de configuration fine. Ce n'est pas le profil de mes projets.

Pourquoi pas WordPress

WordPress fait tourner une part considérable du web. Pour un blog simple ou un site vitrine avec une interface client non technique, c'est parfois le bon outil.

Mais WordPress est une dette technique qui s'accumule. Les plugins tiers créent des interdépendances fragiles. La base de code du core est un héritage de vingt ans qui montre son âge. Dès qu'on sort des cas d'usage standard (un blog, un e-commerce avec WooCommerce), on se retrouve à lutter contre WordPress plutôt qu'à travailler avec lui.

Pour des applications web avec une logique métier réelle (gestion de projets, portails clients, APIs), WordPress n'est pas adapté. Et même pour un blog, je préfère construire quelque chose de propre en Laravel que de gérer la complexité d'un WordPress à jour.

Pourquoi pas Node.js

Node.js et son écosystème (Express, Fastify, NestJS) sont des choix valides, surtout pour des APIs temps réel ou des applications qui bénéficient naturellement de JavaScript côté serveur et côté client.

Mais l'écosystème PHP, pour du développement web classique, est plus stable sur le long terme. Les packages Laravel suivent une politique de compatibilité claire, les migrations de version sont documentées, les breaking changes sont annoncés. L'écosystème npm peut être plus agité : des packages abandonnés, des dépendances en cascade, des changements de paradigme qui rendent du code vieux de deux ans difficile à maintenir.

Pour le type de projets que je développe, Laravel sur PHP est plus prévisible sur cinq ans.

Ce que Laravel apporte

Eloquent. L'ORM de Laravel est l'un des plus agréables à utiliser que j'aie rencontrés. Les relations (hasMany, belongsTo, belongsToMany, morphMany) s'expriment de façon naturelle. Les scopes permettent de centraliser les requêtes fréquentes. Les accesseurs et mutateurs gardent la logique de transformation des données dans le modèle.

Artisan. L'interface en ligne de commande de Laravel couvre tout : génération de code (controllers, migrations, models, seeders), gestion du cache, exécution des migrations, envoi d'emails de test, commandes personnalisées. Sur un projet comme vs81.fr, j'ai des commandes Artisan pour les newsletters planifiées et le nettoyage des données obsolètes.

Blade. Le moteur de templates est simple, extensible, et s'intègre parfaitement avec Tailwind CSS v4 et Alpine.js. Les composants Blade (x-components) permettent de construire un système de composants réutilisables sans framework JavaScript.

Middleware et Pipeline. La gestion des requêtes HTTP via les middleware est claire et composable. Authentification, autorisation, rate limiting, CSRF, logging : chaque préoccupation transversale vit à sa place.

Queues et Events. Pour les opérations asynchrones (envoi d'emails en masse, traitement de fichiers uploadés), Laravel propose un système de queues et d'événements qui fonctionne avec des backends variés (database, Redis, SQS). Sur un hébergement mutualisé sans Redis, le driver database est suffisant pour les volumes que je traite.

De v5 à v13 : une évolution cohérente

J'utilise Laravel depuis la version 5. Chaque version majeure a apporté des améliorations significatives sans déstabiliser les projets existants : Laravel 8 (models avec factories repensées), Laravel 9 (PHP 8.0 minimum, Flysystem 3), Laravel 10 (type declarations généralisées), Laravel 11 (structure allégée, configuration simplifiée), Laravel 12 et 13 (affinements).

La philosophie de l'équipe Laravel ("make the common case easy, and the uncommon case possible") n'a pas changé. C'est ce qui fait que je peux revenir sur un projet Laravel vieux de trois ans et le comprendre encore.

Un outil, pas une religion

Je ne prétends pas que Laravel est la réponse à tous les problèmes. Pour une API ultra-performante avec des milliers de requêtes concurrentes par seconde, d'autres solutions sont plus adaptées. Pour un script d'automatisation simple, PHP brut est plus rapide que de charger un framework.

Mais pour des applications web de taille moyenne (portails clients, blogs avancés, outils internes, sites avec logique métier), Laravel est le choix que je ferais encore aujourd'hui, en 2026, en connaissant toutes les alternatives.