Un développeur déploie Laravel sur un VPS « identique au local ». Le fichier .env est copié avec APP_DEBUG=true, la file d'attente reste en driver sync, le scheduler n'existe pas, le répertoire storage/ n'est pas accessible en écriture. La machine est correcte. L'environnement de production ne l'est pas. Laravel oblige à séparer clairement la brique matérielle de la configuration applicative — sinon chaque déploiement devient une loterie.
La confusion revient sans cesse en support : on achète un serveur « Laravel-ready » parce que PHP 8.3 est installé, puis on oublie de mettre en cache routes et vues, de lancer les workers ou de verrouiller les permissions. Le serveur exécute le code ; l'environnement décide s'il s'exécute en mode démo ou en mode production. Tant que ces deux cartes ne sont pas lues séparément, les incidents ressemblent à des bugs applicatifs alors qu'ils viennent du déploiement.
Serveur et environnement : deux cartes distinctes
Le serveur regroupe le système d'exploitation, nginx ou Apache, PHP-FPM, Redis éventuellement, les correctifs de sécurité. L'environnement regroupe le fichier .env, la clé APP_KEY, les URLs de base de données, la configuration mail, le driver de file d'attente et les caches Laravel (config:cache, route:cache, view:cache). La couche build ajoute composer install --no-dev et la compilation Vite ou Mix. La couche runtime ajoute les workers supervisés et la ligne cron qui appelle schedule:run chaque minute.
| Couche | Exemples | Erreur fréquente |
|---|---|---|
| Serveur | nginx, PHP-FPM 8.2, Redis | Croire que PHP installé = production prête |
| Environnement | .env, APP_KEY, QUEUE | .env de staging recopié en live |
| Build | Composer sans dev, assets compilés | Dépendances de développement en production |
| Runtime | workers, scheduler | Jobs en sync, cron absent |
Un serveur Laravel-ready mal configuré reste une application Laravel en mode démonstration.
Checklist de déploiement qui tient la route
Les variables d'environnement doivent afficher APP_ENV=production, APP_DEBUG=false, des clés uniques et des URLs correctes. Les dépendances passent par composer install --no-dev --optimize-autoloader. Les assets front sont compilés en CI ou localement puis déployés ; php artisan storage:link crée le lien symbolique attendu. Après chaque déploiement, regénérez les caches de configuration, routes et vues. Les répertoires storage/ et bootstrap/cache/ doivent être accessibles en écriture par l'utilisateur PHP-FPM.
Les files d'attente exigent Supervisor ou systemd avec Redis ou une table dédiée ; surveillez failed_jobs. Le scheduler nécessite une entrée cron * php artisan schedule:run. Les migrations se lancent avec migrate --force seulement après sauvegarde de la base. Chaque étape peut être automatisée — Forge, Envoyer, GitHub Actions, Deployer — mais la liste reste la même que vous cliquiez ou scriptiez.
Choisir l'hébergeur au-delà du processeur
Un hébergeur Laravel crédible propose PHP récent, les extensions documentées, Redis installable ou managé, SSH, cron fiable et une voie de déploiement sans interruption — symlink de release ou déploiement progressif si le trafic est critique. Un environnement de staging minimal avec .env distinct évite les mauvaises surprises. Le mutualisé peut suffire pour une petite application ; dès que queues et workers entrent en jeu, VPS ou plateforme managée devient la norme.
Alignez la version PHP avec Choisir une version de PHP et les dépendances avec Composer en production. Octane et Horizon ajoutent de la complexité utile seulement après preuve de goulot d'étranglement FPM ou de besoin de tableau de bord sur les files Redis.
Le sommet : le déploiement réussi est invisible
Parcourez les hébergeurs PHP dans l'annuaire et comparez les offres avec Redis et accès SSH via le comparateur.
Décider et avancer sans angle mort
Versionnez un modèle .env.production sans secrets et injectez les clés via votre pipeline ou votre gestionnaire de secrets. Automatisez le déploiement avec les étapes cache, migration et redémarrage des workers dans un ordre documenté. Configurez Supervisor pour les files d'attente et testez un rollback vers la release précédente avant le premier incident réel. Surveillez failed_jobs et les journaux applicatifs dès la mise en ligne. Enfin, vérifiez que le scheduler tourne vraiment — un cron manquant se remarque souvent trois semaines plus tard quand les rapports ne partent plus.
Questions fréquentes
Quelle différence entre serveur et environnement Laravel ?
Le serveur désigne la machine — système, serveur web, version PHP. L'environnement désigne le contexte applicatif : fichier .env, valeur APP_ENV=production, caches de configuration et clés API. Confondre les deux mène à APP_DEBUG=true en production ou à des clés de staging en ligne.
FPM ou Laravel Octane en production ?
PHP-FPM reste le choix robuste par défaut. Octane avec Swoole ou RoadRunner peut gagner sur une API à fort trafic, mais impose des contraintes de compatibilité sur les packages. Commencez par FPM sauf benchmark qui prouve le contraire.
Comment gérer les queues Laravel ?
Supervisor ou systemd doit relancer queue:work ou queue:listen. Utilisez Redis ou une file en base — jamais le driver sync en production pour les e-mails et jobs lourds.
Que demander à un hébergeur pour Laravel ?
PHP 8.2 ou plus récent, Composer, Redis, cron fiable, accès SSH, extensions utiles (intl, bcmath, pcntl pour les workers) et une procédure de déploiement sans interruption documentée.
En Laravel, la production commence quand .env dit production — pas quand le DNS pointe vers le VPS.