Mettre Symfony en Production : les Étapes Clés du Déploiement

Vous avez fini de développer votre application Symfony ? Vous vous demandez comment la mettre en ligne sans tout casser ? La peur de l’erreur 500 ou d’une faille de sécurité vous bloque ?

Cet article est un guide complet pour déployer votre application Symfony sur un serveur de production, étape par étape et sans jargon inutile. Vous aurez toutes les commandes et les bonnes configurations pour réussir.

Prérequis Indispensables Avant le Déploiement

Avant même de penser à uploader votre code, il faut s’assurer que votre serveur est prêt. Quelques vérifications simples vous éviteront bien des maux de tête plus tard. C’est une étape de préparation de l’environnement.

D’abord, la version de PHP. Symfony est très clair sur ses exigences. Pour les versions récentes comme Symfony 6 ou 7, vous devez avoir au minimum PHP 8.1 ou 8.2 installé sur votre serveur. Une version plus ancienne ne fonctionnera pas. Vous devez aussi vérifier que les extensions PHP nécessaires sont activées.

intl
pdo_mysql (ou pdo_pgsql selon votre base de données)
gd (si vous manipulez des images)
opcache (pour les performances)
json, xml, ctype

Ensuite, vous devez avoir Composer sur le serveur. C’est l’outil qui gère les dépendances de votre projet. Ne le confondez pas avec le Composer que vous avez sur votre machine locale, c’est bien sur le serveur de production qu’il doit être présent pour l’installation des paquets.

L’outil Symfony CLI est très pratique pour vérifier tout ça. Installez-le sur votre serveur et lancez la commande symfony check:requirements. Elle vous listera exactement ce qui manque ou ce qui n’est pas bien configuré. Vous pouvez installer Symfony CLI depuis le site officiel.

Enfin, assurez-vous d’avoir un accès SSH à votre serveur et les droits nécessaires pour créer des dossiers et modifier des fichiers. Sans ça, vous ne pourrez rien faire.

Configuration du Serveur Web : Apache vs Nginx

Le serveur web, comme Apache ou Nginx, est la porte d’entrée de votre application. C’est lui qui reçoit les requêtes des visiteurs et les transmet à Symfony. Sa configuration est donc critique, surtout pour la sécurité.

Point de sécurité essentiel : La racine de votre site web (ce qu’on appelle DocumentRoot sur Apache ou root sur Nginx) doit OBLIGATOIREMENT pointer vers le dossier /public de votre projet Symfony. Jamais à la racine du projet. Sinon, vos fichiers de configuration, comme .env, seraient accessibles publiquement, exposant vos mots de passe de base de données et autres secrets.

Que vous utilisiez Apache ou Nginx, le principe reste le même. Vous devez créer un « hôte virtuel » (VirtualHost) qui définit comment les requêtes pour votre nom de domaine doivent être traitées. Voici deux exemples de configuration de base.

Configuration Apache (virtualhost) Configuration Nginx (server block)

Configuration Apache (virtualhost)	Configuration Nginx (server block)
`<VirtualHost *:80> ServerName votre-domaine.com DocumentRoot /var/www/votre-projet/public <Directory /var/www/votre-projet/public> AllowOverride All Order Allow,Deny Allow from All Require all granted </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>`	`server { listen 80; server_name votre-domaine.com; root /var/www/votre-projet/public; index index.php; location / { try_files $uri /index.php$is_args$args; } location ~ ^/index\.php(/\|$) { fastcgi_pass unix:/var/run/php/php8.2-fpm.sock; fastcgi_split_path_info ^(.+\.php)(/.*)$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; fastcgi_param DOCUMENT_ROOT $realpath_root; internal; } location ~ \.php$ { return 404; } }`

<VirtualHost *:80>
    ServerName votre-domaine.com

    DocumentRoot /var/www/votre-projet/public

    <Directory /var/www/votre-projet/public>
        AllowOverride All
        Order Allow,Deny
        Allow from All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

server {
    listen 80;
    server_name votre-domaine.com;

    root /var/www/votre-projet/public;
    index index.php;

    location / {
        try_files $uri /index.php$is_args$args;
    }

    location ~ ^/index\.php(/|$) {
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
        internal;
    }

    location ~ \.php$ {
        return 404;
    }
}

Les 7 Étapes Clés pour Mettre Symfony en Production

Maintenant que le serveur est prêt, on peut passer au déploiement de l’application. Voici les 7 étapes à suivre dans l’ordre. Chaque étape est importante pour garantir que votre application fonctionne correctement et en toute sécurité. On va voir ensemble les commandes exactes à lancer.

1. Uploader le Code Source (via Git)

La meilleure méthode pour envoyer votre code sur le serveur est d’utiliser Git. Oubliez le FTP, qui est lent et peu fiable. Avec Git, vous êtes sûr d’avoir la bonne version du code et vous pouvez facilement revenir en arrière si besoin.

Connectez-vous en SSH à votre serveur, allez dans le dossier où vous voulez installer votre projet (par exemple /var/www/) et clonez votre dépôt :

git clone votre-url-de-depot.git votre-projet

Pour les mises à jour futures, il vous suffira de faire un git pull pour récupérer les derniers changements. C’est propre et efficace.

2. Installer les Dépendances de Production

Votre code est sur le serveur, mais il manque tous les paquets externes (les « vendors »). Il faut les installer avec Composer. Mais attention, on n’utilise pas la même commande qu’en développement.

La commande à utiliser est : composer install --no-dev --optimize-autoloader. C’est une commande optimisée pour la production.

--no-dev : Cette option est cruciale. Elle indique à Composer de ne pas installer les dépendances qui ne servent qu’au développement (comme les outils de débogage ou de test). Votre projet sera plus léger.
--optimize-autoloader : Cette option améliore les performances de Symfony en créant une « carte » optimisée des classes de votre projet.

3. Configurer les Variables d’Environnement

C’est une étape critique pour la sécurité. En développement, vous utilisez un fichier .env.local pour vos configurations locales. Ce fichier ne doit JAMAIS être envoyé sur le serveur de production, car il contient des secrets (mot de passe de base de données, clés API…).

Règle d’or : Le fichier .env.local doit être listé dans votre .gitignore et ne doit jamais être versionné. Les secrets de production se configurent directement sur le serveur.

Sur votre serveur, vous allez créer un fichier .env.local qui contiendra les variables pour la production. La variable la plus importante est APP_ENV, qui doit être mise à prod. Pensez aussi à désactiver le mode debug.

APP_ENV=prod : Active le mode production de Symfony (meilleures performances, moins de logs).
APP_DEBUG=0 : Désactive les messages d’erreur détaillés pour les visiteurs.

C’est aussi ici que vous configurez l’accès à votre base de données. Par exemple, pour une base PostgreSQL, votre DATABASE_URL ressemblera à ça :

DATABASE_URL="postgresql://nom_utilisateur:mot_de_passe@127.0.0.1:5432/nom_base_donnees?serverVersion=15&charset=utf8"

Une autre méthode, encore plus sécurisée, est d’utiliser les variables d’environnement du serveur directement, sans passer par un fichier .env.local. Par exemple avec la commande export SYMFONY_ENV=prod.

4. Préparer la Base de Données

Maintenant que Symfony sait comment se connecter à la base de données, il faut créer les tables. Si vous utilisez Doctrine, c’est très simple grâce aux migrations.

Lancez simplement cette commande pour appliquer toutes les migrations qui n’ont pas encore été jouées sur la base de données de production :

php bin/console doctrine:migrations:migrate

La commande vous demandera une confirmation avant de modifier la structure de la base de données. C’est une sécurité pour éviter les erreurs.

5. Compiler les Assets (si Encore/Webpack est utilisé)

Si votre projet utilise Symfony Encore ou Webpack pour gérer les fichiers CSS et JavaScript, vous devez les « compiler » pour la production. Cette étape va minifier vos fichiers et les optimiser pour qu’ils se chargent plus vite.

La commande dépend de votre configuration, mais c’est généralement :

npm run build

Cette commande doit être lancée depuis la racine de votre projet, où se trouve le fichier package.json.

6. Vider et Préchauffer le Cache

En production, Symfony utilise un système de cache très agressif pour être le plus rapide possible. Après chaque déploiement qui modifie le code, il est indispensable de vider l’ancien cache et de le reconstruire.

La commande pour ça est simple, mais il faut bien préciser l’environnement prod :

php bin/console cache:clear --env=prod

Cette commande va non seulement supprimer les anciens fichiers de cache, mais aussi en « préchauffer » un nouveau (warmup), pour que le premier visiteur n’ait pas à attendre que tout se construise.

7. Gérer les Permissions des Fichiers

Dernière étape, mais très importante. Symfony a besoin d’écrire dans certains dossiers, notamment var/cache/ et var/log/. Il faut s’assurer que l’utilisateur du serveur web (souvent www-data sur Debian/Ubuntu) a les droits pour le faire.

Si les permissions ne sont pas bonnes, vous aurez une belle erreur 500. Il existe plusieurs méthodes pour gérer ça (chown, chmod, ACL), mais une approche simple est de donner la propriété des dossiers au serveur web :

sudo chown -R www-data:www-data var/

Adaptez www-data au nom de l’utilisateur de votre serveur web si nécessaire.

Optimisations et Bonnes Pratiques Post-Déploiement

Votre application Symfony est en production, bravo ! Mais le travail n’est pas totalement fini. Voici quelques points à vérifier pour garantir la performance et la maintenance sur le long terme.

Tâches planifiées (Cron) : Si vous utilisez Symfony Messenger pour des tâches asynchrones, vous devez configurer un cron sur votre serveur pour lancer régulièrement le consommateur de messages.
Gestion des logs : En mode prod, les logs sont moins verbeux mais restent essentiels pour surveiller les erreurs. Assurez-vous que les logs s’écrivent bien dans var/log/prod.log et mettez en place un système de rotation (logrotate) pour ne pas saturer votre disque.
Sauvegardes régulières : C’est la base. Mettez en place des sauvegardes automatiques de votre base de données et de vos fichiers (surtout les fichiers uploadés par les utilisateurs).
Cache externe : Pour les applications à fort trafic, le cache de Symfony sur le système de fichiers peut devenir un goulot d’étranglement. Pensez à utiliser un système de cache plus performant comme Redis ou Memcached.

Questions Fréquentes (FAQ) sur le Déploiement Symfony

Voici des réponses directes aux questions que beaucoup de développeurs se posent lors d’un premier déploiement.

Comment gérer les secrets et clés API en production ?

La meilleure méthode est d’utiliser les variables d’environnement natives du serveur. La plupart des hébergeurs permettent de les définir via une interface. C’est plus sécurisé que de les stocker dans un fichier .env.local sur le serveur. Pour les projets plus complexes, vous pouvez regarder du côté de Symfony Vault.

Dois-je utiliser composer update en production ?

NON, jamais. La commande composer update met à jour vos dépendances vers de nouvelles versions, ce qui peut casser votre application. En production, on utilise toujours composer install, qui installe les versions exactes définies dans votre fichier composer.lock. C’est la garantie de la stabilité.

Comment revenir en arrière en cas de problème ?

C’est l’un des gros avantages de Git. Si le déploiement cause un bug, vous pouvez très rapidement revenir à la version précédente. La commande git revert permet d’annuler un commit. Des stratégies plus avancées comme le déploiement « blue/green » permettent des mises à jour sans aucune interruption de service.

Quelle est la différence entre cache:clear et cache:warmup ?

La commande cache:clear fait les deux : elle supprime le cache existant PUIS elle le préchauffe (warmup). La commande cache:warmup, elle, ne fait que construire le cache, sans le vider au préalable. En déploiement, php bin/console cache:clear --env=prod est presque toujours la bonne commande à utiliser.