Vous démarrez un nouveau projet PHP en 2026 et vous hésitez entre écrire du code vanilla, adopter Laravel ou opter pour Symfony — sans savoir lequel correspond réellement à votre cas d’usage, à la taille de votre équipe et à vos contraintes de maintenance long terme. Ce guide vous donne une réponse claire, technique, sans marketing.
Choisissez Laravel pour la vélocité, Symfony pour la robustesse d’entreprise, vanilla uniquement pour les microservices ultra-légers.
Pourquoi cette question revient en 2026
PHP fête ses 31 ans en 2026, et pourtant la question du choix entre vanilla et framework reste l’une des plus débattues dans la communauté. La sortie de PHP 8.3, puis les améliorations de PHP 8.4 ont redistribué les cartes. Le JIT (Just-In-Time compiler), les fibers pour la programmation asynchrone et les nouvelles syntaxes expressives ont rendu le code PHP vanilla beaucoup plus agréable à écrire qu’il y a cinq ans. Dans le même temps, Laravel a sorti sa version 11 avec des changements architecturaux majeurs, et Symfony 7 a consolidé son écosystème autour des composants autonomes.
La vraie question n’est pas « quel framework est le meilleur » — c’est « quel outil correspond à mon contexte ». Un développeur solo qui livre un SaaS en trois mois n’a pas les mêmes besoins qu’une équipe de vingt personnes qui maintient une plateforme bancaire sur dix ans. Ce guide vous aide à identifier votre contexte et à faire le bon choix.
Prérequis techniques
| Prérequis | Version minimale | Statut |
|---|---|---|
| PHP | 8.3+ | ✅ Vérifié |
| Composer | 2.7+ | ✅ Vérifié |
Extensions pdo, mbstring, xml, curl |
— | ❌ À configurer |
PHP vanilla en 2026 : vraiment une option ?
Écrire du PHP sans framework est souvent présenté comme un choix de nostalgique. C’est une caricature. Il existe des cas d’usage légitimes où le vanilla PHP est la meilleure réponse technique : un microservice qui expose deux ou trois endpoints REST, un script de traitement batch en CLI, ou une fonction serverless sur AWS Lambda. Dans ces situations, embarquer un framework entier est une dette inutile. Laravel pèse plusieurs dizaines de mégaoctets de dépendances, Symfony un peu moins grâce à son approche par composants, mais dans les deux cas le temps de bootstrap est non nul.
Avec PHP 8.3, le vanilla bénéficie des typed class constants, d’une meilleure gestion des attributs et du JIT qui offre des gains mesurables sur du code CPU-intensif. Pour un script de parsing CSV ou de traitement d’images, PHP vanilla compilé avec le JIT activé peut dépasser un framework en performance brute. Le point de douleur reste le même : tout ce que vous n’écrivez pas vous-même, vous devrez le réinventer. Authentification, sessions, validation, routing, ORM — chaque brique que les frameworks fournissent clé-en-main devient un chantier à part entière.
Pour les projets dépassant 5 000 lignes ou impliquant plusieurs développeurs, le vanilla PHP devient un handicap organisationnel. Sans conventions partagées, chaque développeur impose ses propres patterns et la base de code se fragmente. C’est là que les frameworks prennent toute leur valeur : non pas comme des boîtes magiques, mais comme des langages communs qui permettent à une équipe de travailler de façon cohérente.
Laravel 11 : vitesse, expressivité, écosystème
Laravel est aujourd’hui le framework PHP le plus populaire au monde, et ce n’est pas un accident. Depuis sa création par Taylor Otwell en 2011, Laravel a constamment choisi l’expressivité et la productivité comme boussole. Laravel 11 a simplifié la structure des projets en réduisant drastiquement le nombre de fichiers générés par défaut. Exit les providers et middlewares explicites pour les petits projets : tout se configure dans un seul fichier bootstrap/app.php. C’est un choix controversé, mais qui reflète une philosophie claire : moins de friction pour les nouveaux projets.
L’écosystème Laravel est son atout le plus décisif. Livewire pour les interfaces dynamiques sans JavaScript, Filament pour les back-offices, Inertia.js pour les SPA hybrides, Octane pour les performances avec Swoole ou RoadRunner, Horizon pour les queues, Telescope pour le debugging, Sanctum et Passport pour l’authentification API. Pour un développeur solo ou une petite équipe, cet écosystème permet de livrer des fonctionnalités complexes en un temps record. La courbe d’apprentissage est douce : un développeur junior devient productif en quelques semaines.
Les limites de Laravel apparaissent sur les très grandes applications. La magie d’Eloquent peut devenir un piège sur des schémas complexes avec beaucoup de relations. Le chargement eager/lazy mal maîtrisé génère des requêtes N+1 difficiles à détecter en production. Les façades, si pratiques en développement, rendent les tests unitaires plus verbeux et l’analyse statique moins efficace. Sur une codebase de 200 000 lignes avec vingt développeurs, ces choix de design commencent à peser.
Symfony 7 : architecture, composants, longévité
Symfony est l’opposé philosophique de Laravel. Là où Laravel privilégie la convention et la magie, Symfony mise sur la configuration explicite et la modularité. Symfony 7, compatible PHP 8.2+, a consolidé l’approche par attributs PHP pour la configuration des routes, des validations et de la sérialisation. Un attribut #[Route('/api/users', methods: ['GET'])] sur un contrôleur suffit là où il fallait autrefois des fichiers YAML de cent lignes. C’est un compromis réussi entre la verbosité historique de Symfony et l’expressivité attendue en 2026.
La vraie force de Symfony est sa décomposabilité. Les composants — HttpKernel, Routing, DependencyInjection, Console, EventDispatcher, Validator, Serializer — sont utilisés indépendamment par des dizaines de projets PHP, dont Laravel lui-même pour certains d’entre eux. Un microservice Symfony avec uniquement HttpKernel et Routing démarre en quelques millisecondes et consomme très peu de mémoire. Sa rétrocompatibilité est garantie sur des cycles de trois à cinq ans, et la migration d’une version à l’autre est documentée en détail.
Doctrine, l’ORM associé à Symfony, est plus verbeux qu’Eloquent mais beaucoup plus puissant sur les schémas complexes. Il impose de définir explicitement les entités, les mappings et les relations, ce qui semble fastidieux au démarrage mais devient un avantage sur des applications métier complexes. La typage fort et l’analyse statique avec PHPStan ou Psalm fonctionnent bien mieux avec Doctrine qu’avec Eloquent — un argument décisif pour les équipes qui pratiquent la qualité de code sérieusement.
Étape 1 : installer votre environnement
Avant toute chose, vérifiez que votre environnement PHP répond aux exigences minimales. PHP 8.3 est le minimum recommandé en 2026 pour bénéficier des dernières optimisations du JIT et des nouvelles syntaxes. Composer 2.7 apporte des améliorations significatives sur la résolution des dépendances et la vitesse d’installation.
- Vérifiez votre version PHP :
php -vdoit retourner8.3.xou supérieur - Vérifiez Composer :
composer --versiondoit retourner2.7.xou supérieur - Vérifiez les extensions actives :
php -m— assurez-vous de voirpdo_mysql,mbstring,xmletcurldans la liste
Étape 2 : créer votre projet
Une fois l’environnement validé, la création du projet diffère selon le framework choisi. Laravel propose son installeur officiel via Composer, tandis que Symfony dispose d’un CLI dédié qui offre des options de configuration plus fines dès le départ. Dans les deux cas, la commande génère une structure de projet complète et installe toutes les dépendances nécessaires.
-
Laravel — installez via Composer :
composer create-project laravel/laravel mon-projet
Puis lancez le serveur :cd mon-projet && php artisan serve -
Symfony — installez via le CLI officiel :
symfony new mon-projet --version="7.*" --webapp
Puis lancez le serveur :cd mon-projet && symfony server:start - Validez l’installation en accédant à
http://localhost:8000— la page d’accueil du framework confirme que tout fonctionne
Étape 3 : configuration initiale
La configuration initiale est l’étape souvent négligée qui conditionne pourtant la solidité de toute la suite. Les deux frameworks utilisent un fichier .env pour les variables d’environnement sensibles — base de données, clés API, mode debug. Ne commitez jamais ce fichier dans votre dépôt Git : il doit rester dans votre .gitignore.
- Copiez le fichier d’environnement :
cp .env.example .env -
Configurez votre base de données dans
.env:
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_DATABASE=mon_projet
DB_USERNAME=root
DB_PASSWORD=secret -
Laravel — générez la clé d’application :
php artisan key:generate
Symfony — définissezAPP_SECRETavec une chaîne aléatoire de 32 caractères dans.env
Comparatif : Laravel vs Symfony vs Vanilla
| Critère | Laravel 11 | Symfony 7 | Vanilla PHP 8.3 |
|---|---|---|---|
| Vitesse de démarrage projet | ⚡ Très rapide | 🔧 Modérée | 🐢 Lente |
| Courbe d’apprentissage | Douce | Raide | Variable |
| Performance brute | Bonne | Très bonne | Excellente |
| Maintenabilité long terme | Bonne | Excellente | Faible |
| Écosystème | Très riche | Riche | Inexistant |
| Tests unitaires | Correct | Excellent | Libre |
| Analyse statique (PHPStan) | Correct | Excellent | Excellent |
| Adapté aux équipes larges | Oui | Oui | Non |
| Idéal pour microservices | Moyen | Oui | Oui |
Dépannage : 3 problèmes fréquents
Problème 1 : extensions PHP manquantes au démarrage
L’erreur la plus fréquente lors de l’installation d’un framework est une extension PHP absente. Laravel et Symfony déclarent leurs dépendances dans composer.json, mais Composer ne peut pas activer les extensions système à votre place. Si vous voyez une erreur du type « The requested PHP extension ext-mbstring is missing », voici la marche à suivre.
- Listez les extensions actives :
php -m | grep -E "pdo|mbstring|xml|curl" - Sur Ubuntu/Debian, installez les extensions manquantes :
sudo apt install php8.3-mbstring php8.3-xml php8.3-curl php8.3-pdo-mysql - Sur macOS avec Homebrew :
brew install php && pecl install extension_name - Redémarrez PHP-FPM ou votre serveur web après installation :
sudo systemctl restart php8.3-fpm
Problème 2 : erreur 500 ou page blanche au premier lancement
Une page blanche ou une erreur 500 sans message apparent est souvent liée à des permissions incorrectes sur les dossiers de cache ou de logs, ou à une clé d’application non générée. Ce problème touche principalement Laravel mais peut aussi survenir sur Symfony.
- Vérifiez les permissions :
chmod -R 775 storage bootstrap/cache(Laravel) ouchmod -R 777 var/(Symfony) - Consultez les logs en temps réel :
tail -f storage/logs/laravel.logoutail -f var/log/dev.log - Vérifiez que la clé d’application est bien définie :
php artisan key:generate(Laravel) - Videz tous les caches :
php artisan optimize:clear(Laravel) ouphp bin/console cache:clear(Symfony)
Problème 3 : Composer timeout ou dépendances bloquées
Sur des connexions lentes ou des environnements avec des restrictions réseau, Composer peut bloquer sur la résolution ou le téléchargement des dépendances. C’est particulièrement fréquent en entreprise derrière un proxy ou sur des serveurs CI/CD avec des limites de temps strictes.
- Augmentez le timeout Composer :
COMPOSER_PROCESS_TIMEOUT=600 composer install - Videz le cache Composer :
composer clear-cache - Utilisez le flag no-cache pour forcer un téléchargement propre :
composer install --no-cache - Configurez un miroir Packagist local si vous êtes en entreprise : ajoutez un bloc
repositoriesdans votrecomposer.json
Astuces pro
- REPL interactif : utilisez
php artisan tinkersur Laravel oucomposer require --dev psy/psyshsur Symfony pour tester du code en temps réel sans créer de fichier - Analyse statique : intégrez PHPStan niveau 8 dès le début du projet —
composer require --dev phpstan/phpstan— corriger 10 000 erreurs en fin de projet est un cauchemar - Debug des routes :
php artisan route:list(Laravel) ouphp bin/console debug:router(Symfony) pour lister toutes vos routes et détecter les conflits immédiatement
Bonus : déploiement rapide avec Docker
En 2026, déployer un projet PHP sans Docker est rare dans les équipes professionnelles. Laravel Sail propose une configuration Docker clé-en-main qui inclut PHP, Nginx, MySQL et Redis sans aucune configuration manuelle. Installez-le avec composer require laravel/sail --dev, publiez la configuration avec php artisan sail:install, puis démarrez l’environnement complet avec ./vendor/bin/sail up -d. Pour Symfony, l’image officielle dunglas/frankenphp avec FrankenPHP — le nouveau serveur PHP basé sur Caddy — offre d’excellentes performances en production et simplifie le déploiement en un seul conteneur autonome.
Quelle que soit votre stack, adoptez dès le départ un pipeline CI/CD avec GitHub Actions ou GitLab CI qui lance les tests, l’analyse statique et le build Docker à chaque push. Cette discipline, mise en place en début de projet, vous évitera des dizaines d’heures de debugging en production.
Quel choix faire en 2026 ?
Si vous lancez un nouveau projet en 2026, voici la règle simple : choisissez Laravel si vous voulez livrer vite et que votre équipe est petite à moyenne. Choisissez Symfony si votre application a une longévité de cinq ans ou plus, une équipe nombreuse, ou des contraintes métier complexes. Choisissez le vanilla PHP uniquement si vous écrivez un microservice ou un outil CLI isolé avec moins de 2 000 lignes de code.
Le meilleur framework est celui que votre équipe maîtrise et que vous pouvez maintenir dans la durée. Un projet Laravel bien structuré vaut mieux qu’un projet Symfony mal architecturé, et inversement. L’outil ne fait pas le développeur — mais le bon outil pour le bon contexte fait une vraie différence sur le long terme.