Héberger une application Laravel en France : prérequis serveur, choix de l’offre et déploiement

Hébergement Laravel : les prérequis serveur à vérifier avant de commander

Un hébergement Laravel se juge d’abord sur quatre points : la version de PHP, les extensions chargées, la présence de Composer et la possibilité de pointer la racine web sur le dossier public. Vérifiez-les avant de signer, pas après le premier déploiement raté.

Version de PHP et extensions requises

La documentation officielle fixe la version minimale de PHP pour chaque version majeure du framework : PHP 8.2 au minimum pour Laravel 11 et 12, PHP 8.3 au minimum pour Laravel 13. La liste des extensions requises est la même dans tous les cas :

• Ctype, cURL, DOM, Fileinfo, Filter, Hash ;
• Mbstring, OpenSSL, PCRE, PDO (avec le pilote de votre base : pdo_mysql ou pdo_pgsql) ;
• Session, Tokenizer, XML.

Sur un mutualisé Plesk, la version de PHP se choisit par domaine dans Paramètres PHP, où s’affichent aussi les extensions actives. Sur un VPS Debian ou Ubuntu, apt install php8.3-fpm php8.3-cli php8.3-mysql php8.3-mbstring php8.3-xml php8.3-curl php8.3-zip php8.3-intl couvre l’essentiel. Contrôlez ensuite avec php -m.

Composer, le gestionnaire de dépendances

En production, Composer sert à installer le dossier vendor à partir de composer.lock, jamais à mettre à jour les dépendances. Si l’hébergement ne fournit ni Composer ni accès SSH, lancez composer install dans votre intégration continue et livrez vendor avec l’application. Prévoyez une limite mémoire PHP d’au moins 512 Mo pour Composer et certaines commandes Artisan. Enfin, APP_DEBUG doit valoir false : la page d’erreur détaillée expose vos variables d’environnement à tout visiteur.

Base de données, Node et compilation des assets avec Vite

Laravel fonctionne avec MySQL, MariaDB, PostgreSQL et SQLite. En mutualisé, la base est MySQL ou MariaDB, créée depuis Plesk ; sur un VPS, vous installez le moteur de votre choix. Créez un utilisateur dédié à l’application, limité à sa base, et reportez les identifiants dans le .env (DB_CONNECTION, DB_HOST, DB_DATABASE, DB_USERNAME, DB_PASSWORD). PostgreSQL exige l’extension pdo_pgsql, rarement présente en mutualisé.

Pourquoi compiler les assets avant le déploiement

Les fichiers CSS et JavaScript sont compilés par Vite : npm run build produit le dossier public/build et son manifest.json, que Laravel lit pour générer les balises. Trois raisons de lancer cette compilation sur votre poste ou dans votre intégration continue, et non sur le serveur :

1. Node n’est pas disponible sur un mutualisé classique, et sur un VPS il ajoute des paquets à maintenir pour rien : le serveur n’a besoin que du résultat.
2. La compilation consomme mémoire et processeur ; en mutualisé, les limites CloudLinux (LVE) peuvent l’interrompre.
3. Un artefact compilé une fois garantit que préproduction et production servent les mêmes fichiers.

Générez donc public/build dans le pipeline et copiez-le avec l’application, ou versionnez-le dans une branche deploy si vous déployez uniquement par Git.

Racine web, permissions, fichier .env et HTTPS

Quatre réglages font la différence entre une application qui tourne et une application exposée. Ils se font une fois, à la création de l’hébergement.

La racine web sur le dossier public

Seul le dossier public doit être servi. app, config, storage et .env restent hors de portée du navigateur. Dans Plesk, ouvrez Hébergement et DNS, puis Paramètres d’hébergement, et remplacez la racine du document httpdocs par httpdocs/public. Sur un VPS avec Nginx, la directive est root /var/www/app/public;, complétée par la règle recommandée par la documentation :

location / {
    try_files $uri $uri/ /index.php?$query_string;
}

Permissions de storage et bootstrap/cache

Laravel écrit dans storage (logs, sessions, vues compilées) et bootstrap/cache (configuration et routes mises en cache). L’utilisateur qui exécute PHP doit pouvoir y écrire. Sur un VPS où vous déployez avec un compte deploy et où PHP-FPM tourne sous www-data :

sudo chown -R deploy:www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache

En mutualisé Plesk, PHP s’exécute sous l’utilisateur de l’abonnement : les permissions par défaut suffisent. Lancez php artisan storage:link une fois si vos fichiers envoyés doivent être publics.

Le .env ne va jamais dans Git

Le .env contient la clé d’application, les mots de passe de base de données et les clés d’API. Il est exclu par le .gitignore fourni ; créez-le à la main sur chaque serveur et générez la clé avec php artisan key:generate. Le guide sur les variables d’environnement Laravel et Node.js détaille où déclarer ces valeurs et le piège de env() après config:cache.

HTTPS dès le premier jour

Activez un certificat Let’s Encrypt avant de pointer le domaine (dans Plesk : Certificats SSL/TLS ; sur un VPS : Certbot), forcez la redirection vers HTTPS et renseignez APP_URL en https://. Sinon, asset() et route() génèrent des URL mixtes.

Files d’attente, planificateur et cache : ce qui tourne en arrière-plan

C’est ici que l’offre devient décisive : file d’attente (e-mails, PDF, appels d’API) et planificateur (purges, facturation) supposent un processus qui tourne en dehors des requêtes web.

Le planificateur : une seule ligne de cron

Toutes les tâches planifiées sont déclenchées par une entrée cron unique, exécutée chaque minute :

* * * * * cd /var/www/app && php artisan schedule:run >> /dev/null 2>&1

Dans Plesk, l’équivalent se crée dans Tâches planifiées, type « Exécuter une commande », avec l’exécutable PHP de la bonne version (souvent /opt/plesk/php/8.3/bin/php). En mutualisé, vérifiez qu’une exécution par minute est acceptée.

La file d’attente : un démon qui ne s’arrête pas

Un worker lancé par php artisan queue:work tourne indéfiniment ; il faut un superviseur qui le relance s’il plante ou au redémarrage de la machine. Sur un VPS, c’est le rôle de Supervisor, avec une configuration proche de celle de la documentation :

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/app/artisan queue:work database --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=www-data
numprocs=2
redirect_stderr=true
stdout_logfile=/var/www/app/storage/logs/worker.log
stopwaitsecs=3600

Un mutualisé n’autorise pas de démon persistant : CloudLinux limite le nombre et la durée des processus. Deux replis existent. Le pilote sync (QUEUE_CONNECTION=sync) exécute les tâches dans la requête : simple, mais l’utilisateur attend. Ou une tâche planifiée chaque minute qui lance php artisan queue:work --stop-when-empty --max-time=50 : les tâches partent avec jusqu’à une minute de délai. Acceptable pour des e-mails, pas pour des traitements lourds.

Cache : OPcache et caches Laravel

OPcache garde le bytecode PHP en mémoire ; en mutualisé NovaHoster, il est fourni avec PHP 8.x. Laravel ajoute ses caches de configuration, de routes, de vues et d’événements, générés au déploiement par php artisan optimize. Pour le cache applicatif et les sessions, file ou database suffit en mutualisé ; Redis demande un VPS ou un dédié.

Hébergement Laravel : mutualisé Plesk, VPS ou serveur dédié ?

Le choix tient à une question : votre application a-t-elle besoin de processus persistants (workers, Redis, WebSockets) et d’un contrôle sur la pile logicielle ? Si non, un mutualisé Plesk bien réglé suffit à un site vitrine, un intranet léger ou une API à faible trafic. Si oui, il faut un VPS ou un dédié. Le guide qui compare mutualisé, VPS et dédié traite la question en général ; le tableau l’applique à Laravel.

Quand le mutualisé suffit

Un hébergement web mutualisé avec Plesk, PHP 8.x, OPcache et disques NVMe convient à une application qui sert des pages et des formulaires, envoie quelques e-mails par jour et accepte une file d’attente exécutée par cron. Il est hébergé en France, sauvegardé chaque jour et protégé par Imunify360 ; ses limites sont celles de CloudLinux.

Quand passer au VPS

Dès que vous avez besoin de Supervisor, de Redis, d’une version précise de PostgreSQL, de Laravel Octane ou de plusieurs environnements isolés, un serveur VPS avec accès root devient le bon outil. Point à connaître avant de commander : les VPS NovaHoster sont hébergés en Roumanie, en Moldavie ou en Russie, pas en France. Si vos clients ou votre contrat exigent une localisation française des données, passez au mutualisé ou au dédié.

Quand choisir le dédié infogéré

Un serveur dédié en France apporte le contrôle du VPS avec des ressources exclusives et une localisation française. Si votre équipe ne veut pas administrer de système, l’infogérance serveur prend en charge monitoring, mises à jour, sécurité et incidents : vous ne gardez que le déploiement de l’application.

Déployer Laravel avec Git dans Plesk ou sur un VPS

Le déploiement par Git rend chaque mise en production traçable et reproductible, et permet un retour arrière en changeant de révision. Le guide pour déployer une application depuis Git sur NovaHoster détaille la connexion du dépôt, les clés SSH et les branches ; voici ce qui est propre à Laravel.

Dans Plesk

1. Dans l’abonnement, ouvrez Git, ajoutez le dépôt distant et choisissez la branche de production (main ou deploy).
2. Définissez le chemin de déploiement sur httpdocs et vérifiez que la racine du document est httpdocs/public.
3. Créez le .env dans httpdocs par le gestionnaire de fichiers ou par SSH : Git ne le fournira pas.
4. Dans Actions de déploiement, saisissez les commandes de la section suivante, avec le chemin complet de PHP et de Composer.
5. Activez le déploiement automatique à la réception (webhook) ou gardez le déploiement manuel.

Sur un VPS

Avant la première ligne de Laravel, sécurisez la machine : utilisateur non root, clés SSH, pare-feu, mises à jour automatiques. Le guide pour sécuriser un VPS Linux en 30 minutes donne la procédure commande par commande. Installez ensuite Nginx, PHP-FPM, la base, Composer et Supervisor, puis clonez le dépôt dans /var/www/app avec un compte deploy.

La forme la plus simple est un script deploy.sh déclenché par SSH depuis votre pipeline : git fetch, git checkout de l’étiquette voulue, puis la séquence ci-dessous. Quand les déploiements deviennent fréquents, passez à une structure par versions (dossier releases, lien symbolique current, storage partagé) telle que Deployer ou Laravel Envoy la mettent en place : la bascule devient atomique.

Les commandes à exécuter après chaque déploiement, et le retour arrière

L’ordre compte. Cette séquence, à placer dans les actions de déploiement Plesk ou dans votre script, couvre une mise en production standard :

php artisan down --retry=30
composer install --no-dev --optimize-autoloader --no-interaction
php artisan migrate --force
php artisan optimize
php artisan queue:restart
php artisan up

• down affiche la page de maintenance et évite qu’une requête s’exécute à moitié sur l’ancien code.
• composer install --no-dev --optimize-autoloader installe les versions exactes du composer.lock, sans outils de développement, avec l’autoloader optimisé recommandé par la documentation.
• migrate --force applique les migrations ; sans --force, Artisan demande en production une confirmation que personne n’est là pour donner.
• optimize enchaîne config:cache, event:cache, route:cache et view:cache. Rappel : après config:cache, le .env n’est plus lu pendant les requêtes.
• queue:restart demande aux workers de se terminer après la tâche en cours ; Supervisor les relance avec le nouveau code.

Si vous avez réglé opcache.validate_timestamps=0, ajoutez un rechargement de PHP-FPM (sudo systemctl reload php8.3-fpm) après optimize, sinon OPcache continue de servir l’ancien code.

Retour arrière

Le code se remet en place en revenant à l’étiquette précédente (git checkout v1.4.2 ou déplacement du lien current), suivi de composer install, php artisan optimize:clear, php artisan optimize et queue:restart. La base est le point délicat : migrate:rollback --step=1 n’est sûr que si la méthode down() a été écrite et testée, et une colonne supprimée ne revient pas avec ses données. Deux règles : exporter la base juste avant migrate, et écrire des migrations compatibles avec l’ancien code.

Sauvegardes, logs et surveillance d’une application Laravel

Sauvegardes : la base et storage/app

Le code est dans Git ; le reste doit être sauvegardé : la base de données, le dossier storage/app (fichiers envoyés par les utilisateurs) et le .env. En mutualisé NovaHoster, les sauvegardes quotidiennes sont incluses et se restaurent depuis Plesk. Sur un VPS, elles sont à votre charge : mysqldump ou pg_dump planifié, rsync de storage/app vers une autre machine, et un test de restauration à date fixe.

Logs : où regarder quand ça casse

Laravel écrit dans storage/logs/laravel.log. En production, réglez LOG_CHANNEL=daily pour un fichier par jour et LOG_LEVEL=warning ou error pour ménager le disque. Une erreur 500 sans trace dans ce fichier vient souvent d’un problème antérieur au démarrage de Laravel (permissions, version de PHP, extension manquante) et se trouve alors dans les logs PHP-FPM ou Apache. Le guide pour lire les logs et diagnostiquer une application en production donne la méthode et les erreurs typiques.

Surveillance : la route /up et les workers

Depuis Laravel 11, l’application expose une route de santé sur /up qui répond 200 si elle démarre sans exception. Faites-la interroger chaque minute par un outil de supervision externe, avec alerte. Surveillez aussi que le planificateur s’exécute (une tâche qui écrit un horodatage dans le cache) et que les workers sont vivants (supervisorctl status). Suivez aussi l’espace disque.

Liste de contrôle de mise en production

À cocher avant d’ouvrir le DNS vers le nouvel hébergement Laravel, puis à relire à chaque changement d’offre.

Serveur et offre

• Version de PHP conforme au minimum de votre version de Laravel ; extensions requises présentes (php -m).
• Composer accessible, ou dossier vendor livré par le pipeline.
• Racine web sur public ; l’URL /.env renvoie 404 ou 403.
• Besoins en workers et en Redis évalués ; localisation vérifiée (France pour le mutualisé et le dédié, pas pour le VPS).

Configuration

• APP_ENV=production, APP_DEBUG=false, APP_URL en HTTPS, APP_KEY générée.
• Utilisateur de base de données dédié et limité à la base de l’application.
• Certificat SSL actif et redirection HTTP vers HTTPS en place.
• storage et bootstrap/cache en écriture pour l’utilisateur PHP ; storage:link créé si nécessaire.
• Assets compilés dans public/build ; aucun fichier public/hot.

Arrière-plan et déploiement

• Cron schedule:run chaque minute, vérifié avec php artisan schedule:list et une tâche témoin.
• Workers sous Supervisor sur VPS et dédié ; sync ou worker par cron en mutualisé, choix assumé.
• Séquence de déploiement versionnée, avec queue:restart, exécutée une fois en préproduction, retour arrière compris.

Exploitation

• Sauvegarde de la base et de storage/app planifiée, restauration testée.
• LOG_CHANNEL=daily, niveau de log adapté, espace disque surveillé.
• Route /up supervisée avec alerte ; personne d’astreinte identifiée.
• Sur VPS : système sécurisé et mises à jour automatiques actives ; sur dédié : périmètre de l’infogérance connu de l’équipe.

Guides liés

Pour aller plus loin sur le même sujet, et sur ce qui l’entoure :

• Configurer les environnements d’une application Laravel ou Node.js — Configurez proprement les variables d’environnement Laravel et Node.js, protégez les secrets et évitez les erreurs de cache, de mode debug…
• Lire les logs et diagnostiquer une application en production — Méthode pratique pour analyser les logs Laravel et Node.js, distinguer erreur de code, configuration, quota et processus, puis préparer un…
• Déployer une application depuis Git sur NovaHoster — Apprenez à préparer un dépôt Git, configurer un déploiement NovaHoster et diagnostiquer les erreurs de branche, dépendances, permissions et…
• Administrer un abonnement Plesk sans interrompre son site — Découvrez une méthode fiable pour administrer un abonnement Plesk, modifier les réglages d’un domaine et limiter les risques avant chaque…
• Changer d’hébergeur WordPress sans perdre son référencement : la méthode complète, phase par phase — Changer d’hébergeur WordPress sans perdre son référencement : préparation, copie, test, bascule DNS avec TTL abaissé, vérifications SEO et…

Sources techniques

[1] Laravel — Deployment : server requirements, optimization, health route [2] Laravel — Installation [3] Laravel — Queues : running the queue worker, Supervisor configuration [4] Laravel — Task Scheduling : running the scheduler [5] Composer — Introduction and installation [6] Plesk — Plesk Obsidian Customer’s Guide