Lorsque vous saisissez une adresse dans votre navigateur, un site s’affiche presque instantanément avec fluidité. Derrière cette apparente simplicité se cache un mécanisme précis, structuré et parfaitement orchestré : le serveur web. Configurer un serveur web revient à poser les fondations d’une présence en ligne fiable, sécurisée et performante. Que vous soyez développeur débutant, administrateur système ou entrepreneur souhaitant héberger vos propres projets, maîtriser cette configuration constitue une étape incontournable. Dans cet article, nous étudions en profondeur les différentes étapes pour configurer un serveur web, depuis le choix de l’environnement jusqu’à la mise en production. L’objectif est de vous offrir une vision claire, technique et directement applicable, tout en partageant des bonnes pratiques issues de l’expérience terrain.

Les bases de la configuration de serveur web et le choix de son environnement

Avant de configurer un serveur web, il faut comprendre précisément son rôle dans une architecture informatique. Un serveur web est un logiciel chargé de recevoir des requêtes HTTP ou HTTPS envoyées par des clients, le plus souvent des navigateurs, puis de leur retourner une réponse. Cette réponse peut être une page HTML statique, une image, une feuille de style CSS, un fichier JavaScript, une API JSON ou encore une page générée dynamiquement par une application PHP, Python, Node.js, Java ou Ruby. Dans une infrastructure classique, le serveur web agit comme point d’entrée entre l’utilisateur final et l’application hébergée. Lorsqu’un internaute saisit un nom de domaine, celui-ci est résolu par le DNS vers l’adresse IP du serveur. Le navigateur établit ensuite une connexion vers le port 80 pour HTTP ou le port 443 pour HTTPS. Le serveur web analyse la requête, identifie le site concerné, applique les règles de configuration, interroge éventuellement un moteur applicatif, puis renvoie le contenu demandé. La configuration d’un serveur web ne se limite donc pas à installer un paquet logiciel. Elle implique de définir l’environnement système, le serveur HTTP, la structure des répertoires, les droits d’accès, la résolution DNS, le chiffrement TLS, les règles de sécurité, la gestion des logs, les performances réseau et la capacité à maintenir le service dans le temps. Les serveurs web les plus utilisés sont :

• Apache HTTP Server : solution historique, très flexible, compatible avec de nombreux modules et largement documentée. Apache est apprécié pour sa gestion fine des fichiers .htaccess, ce qui le rend fréquent dans les environnements mutualisés et les applications PHP traditionnelles.
• Nginx : serveur réputé pour ses performances, sa faible consommation mémoire et son excellente gestion des connexions simultanées. Il est souvent utilisé comme serveur web, reverse proxy, proxy SSL ou load balancer.
• LiteSpeed : serveur orienté performance, souvent utilisé avec WordPress et les environnements nécessitant une mise en cache avancée. Sa compatibilité avec certaines règles Apache facilite les migrations.
• Caddy : serveur moderne qui simplifie fortement la gestion HTTPS grâce à l’automatisation des certificats TLS. Il convient bien aux déploiements rapides et aux architectures légères.

Le choix du serveur web dépend du type de projet, du trafic attendu, de la pile applicative, des compétences de l’équipe technique et des contraintes d’exploitation. Pour un site PHP classique, Apache peut être pertinent grâce à sa compatibilité étendue. Pour une application à fort trafic ou une architecture microservices, Nginx est souvent préféré pour son modèle événementiel et son efficacité en reverse proxy. Pour un site WordPress très orienté performance, LiteSpeed peut offrir un gain intéressant avec un cache adapté. Il est également important de distinguer plusieurs rôles techniques. Un serveur web peut servir directement des fichiers statiques, transmettre des requêtes vers un interpréteur PHP-FPM, rediriger le trafic vers une application Node.js, exposer une API, répartir la charge entre plusieurs serveurs applicatifs ou encore terminer la connexion TLS avant de relayer le trafic en interne. Cette séparation des responsabilités améliore la sécurité, la lisibilité de l’architecture et les performances globales. Le choix du système d’exploitation constitue une autre décision structurante. En production, les distributions Linux sont majoritaires pour leur stabilité, leur sécurité, leur richesse documentaire et leur excellente intégration avec les outils d’administration serveur. Les environnements les plus courants sont :

• Debian : Distribution reconnue pour sa stabilité, sa sobriété et sa fiabilité sur le long terme. Debian est particulièrement adaptée aux serveurs de production qui privilégient la prévisibilité plutôt que les nouveautés rapides. Son cycle de publication conservateur limite les changements brusques de versions logicielles, ce qui réduit les risques d’incompatibilités après les mises à jour. Elle convient très bien à l’hébergement de sites web, d’applications PHP, de bases de données, de reverse proxies ou de services internes. Debian est aussi appréciée pour sa faible empreinte système, son gestionnaire de paquets apt, sa documentation abondante et sa grande communauté ;
• Ubuntu Server : Distribution très populaire dans les environnements cloud, DevOps et hébergement web. Basée sur Debian, elle propose une expérience d’administration accessible, un large support matériel et une excellente compatibilité avec les principaux fournisseurs cloud comme AWS, Azure, Google Cloud, OVHcloud ou Scaleway. Ses versions LTS offrent un support étendu, ce qui en fait un choix fréquent pour les serveurs web en production. Ubuntu Server est particulièrement pratique pour déployer rapidement Nginx, Apache, PHP-FPM, Docker, Kubernetes, PostgreSQL, MySQL ou des applications Node.js. Sa documentation claire et son adoption massive facilitent aussi le dépannage ;
• Rocky Linux ou AlmaLinux : Distributions orientées entreprise, conçues comme alternatives compatibles avec l’écosystème Red Hat Enterprise Linux. Elles sont souvent utilisées dans les infrastructures professionnelles qui recherchent une base stable, robuste et proche des standards d’entreprise. Rocky Linux et AlmaLinux conviennent bien aux environnements où les administrateurs système sont habitués à dnf, firewalld, SELinux et aux conventions Red Hat. Elles sont pertinentes pour les serveurs web critiques, les plateformes applicatives internes, les environnements virtualisés, les infrastructures d’hébergement et les organisations qui souhaitent remplacer CentOS tout en conservant une logique d’exploitation similaire ;
• Red Hat Enterprise Linux : Distribution commerciale destinée aux environnements professionnels soumis à des exigences élevées de support, de conformité, de sécurité et de stabilité. RHEL est particulièrement adaptée aux grandes entreprises, administrations, secteurs réglementés et infrastructures nécessitant un accompagnement éditeur, des correctifs certifiés et une compatibilité logicielle maîtrisée. Elle s’intègre très bien avec SELinux, les outils d’automatisation, les solutions de supervision, les plateformes de virtualisation et les environnements hybrides. Son principal intérêt réside dans le support professionnel, la documentation officielle, la certification matérielle et logicielle, ainsi que la continuité de service attendue dans les infrastructures critiques.

Avant l’installation du serveur web, il faut préparer correctement la machine. Celle-ci peut être un serveur physique, une machine virtuelle, une instance cloud ou un conteneur. Dans tous les cas, plusieurs paramètres doivent être vérifiés : ressources CPU, mémoire vive, espace disque, bande passante, latence réseau, système de fichiers, politique de sauvegarde et niveau d’isolation par rapport aux autres services. Un serveur web destiné à un petit site vitrine n’aura pas les mêmes besoins qu’une plateforme e-commerce ou qu’une API sollicitée en continu. Il faut anticiper la charge, le nombre de connexions simultanées, le volume des fichiers statiques, la taille des logs, la fréquence des déploiements et la présence éventuelle d’une base de données sur le même serveur. Une fois le système installé, la première étape consiste à mettre à jour les paquets afin de bénéficier des derniers correctifs de sécurité disponibles :

sudo apt update
sudo apt upgrade

Sur une distribution basée sur Red Hat, la commande équivalente sera généralement :

sudo dnf update

Il est ensuite recommandé de créer un utilisateur d’administration dédié plutôt que d’utiliser directement le compte root. Cette bonne pratique réduit les risques liés aux erreurs de manipulation et permet une meilleure traçabilité des actions effectuées sur le serveur.

adduser admin
usermod -aG sudo admin

La configuration SSH doit également être durcie dès le départ. Il est conseillé d’utiliser une authentification par clé SSH, de désactiver la connexion directe en root et, selon le contexte, de restreindre les adresses IP autorisées à se connecter. Le fichier de configuration se trouve généralement dans :

/etc/ssh/sshd_config

On peut notamment y définir :

PermitRootLogin no
PasswordAuthentication no

Après modification, le service SSH doit être rechargé avec prudence afin de ne pas perdre l’accès au serveur :

sudo systemctl reload ssh

Le pare-feu représente une autre brique fondamentale. Sur Ubuntu, l’outil ufw permet de gérer simplement les règles réseau. Une configuration minimale consiste à autoriser SSH, HTTP et HTTPS :

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Sur les distributions utilisant firewalld, on pourra employer :

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

La structure des répertoires doit aussi être pensée dès le début. Par convention, les fichiers des sites sont souvent placés dans /var/www/. Chaque site ou application peut disposer de son propre répertoire afin de séparer proprement les projets :

/var/www/site-exemple/public
/var/www/site-exemple/logs
/var/www/site-exemple/releases

Les permissions doivent être strictement contrôlées. Le serveur web ne doit disposer que des droits nécessaires à son fonctionnement. Donner des permissions trop larges, comme 777, expose le serveur à des risques importants. Dans un environnement Linux, les processus web s’exécutent généralement avec un utilisateur spécifique, par exemple www-data sur Debian et Ubuntu. La gestion DNS intervient également dans la configuration. Le nom de domaine doit pointer vers l’adresse IP publique du serveur à l’aide d’un enregistrement de type A pour IPv4 ou AAAA pour IPv6. Pour un sous-domaine comme www, on peut utiliser un enregistrement CNAME ou un second enregistrement A. Une bonne configuration DNS facilite ensuite la mise en place du certificat HTTPS. Enfin, il faut définir l’architecture globale avant de passer à la configuration avancée. Un serveur web peut fonctionner seul pour un petit projet, mais il peut aussi s’intégrer dans une architecture plus complète avec base de données séparée, cache Redis, CDN, reverse proxy, stockage objet, load balancer et supervision centralisée. Plus cette architecture est claire dès le départ, plus la configuration sera maintenable et évolutive. Ces premières étapes permettent de construire une base saine : Un système à jour, un accès administrateur sécurisé, un pare-feu actif, une arborescence cohérente, des permissions maîtrisées et un choix technique adapté au projet. C’est sur cette fondation que repose toute la suite de la configuration du serveur web.

Installer et configurer le serveur web étape par étape

La configuration concrète d’un serveur web commence par l’installation du service HTTP, puis par la création d’un hôte virtuel capable de répondre à un nom de domaine précis. Dans cet exemple, nous allons prendre le cas d’un serveur Ubuntu avec Nginx, une combinaison très fréquente en production pour héberger des sites statiques, des applications PHP, des API ou des services placés derrière un reverse proxy. Avant toute installation, il est préférable de mettre à jour l’index des paquets et les composants déjà présents sur le système :

sudo apt update
sudo apt upgrade

Vous pouvez ensuite installer Nginx :

sudo apt install nginx

Une fois l’installation terminée, vérifiez que le service est bien actif :

sudo systemctl status nginx

Si Nginx fonctionne correctement, le service doit apparaître comme actif. Vous pouvez également tester la réponse HTTP locale avec :

curl -I http://127.0.0.1

La commande doit retourner un en-tête HTTP, généralement avec un code 200 OK. Depuis un navigateur, l’accès à l’adresse IP publique du serveur doit afficher la page par défaut de Nginx. Les fichiers principaux de configuration de Nginx sont répartis dans plusieurs emplacements :

• /etc/nginx/nginx.conf : fichier principal contenant la configuration globale du serveur.
• /etc/nginx/sites-available/ : répertoire contenant les configurations disponibles des sites.
• /etc/nginx/sites-enabled/ : répertoire contenant les sites activés, généralement sous forme de liens symboliques.
• /etc/nginx/conf.d/ : répertoire pouvant contenir des fichiers de configuration additionnels.
• /var/log/nginx/access.log : journal des requêtes reçues par le serveur.
• /var/log/nginx/error.log : journal des erreurs Nginx.

Le fichier nginx.conf définit les paramètres globaux : utilisateur d’exécution, nombre de processus, gestion des connexions, inclusion des fichiers complémentaires, formats de logs et paramètres HTTP généraux. Dans la majorité des cas, il est préférable de ne pas surcharger ce fichier inutilement et de placer la configuration des sites dans des fichiers séparés. Avant de créer un site, il faut préparer son répertoire web. Par convention, on utilise souvent /var/www/ :

sudo mkdir -p /var/www/votre-site/public
sudo chown -R www-data:www-data /var/www/votre-site
sudo chmod -R 755 /var/www/votre-site

Le répertoire public doit contenir uniquement les fichiers exposés au navigateur. Les fichiers sensibles, comme les fichiers de configuration applicative, les sauvegardes, les scripts internes ou les fichiers d’environnement, ne doivent jamais être placés dans la racine publique. Pour tester rapidement le fonctionnement du site, créez une page HTML simple :

echo "<h1>Serveur web opérationnel</h1>" | sudo tee /var/www/votre-site/public/index.html

Il faut ensuite créer un bloc serveur Nginx. Ce bloc indique au serveur quel domaine écouter, quel port utiliser, où se trouvent les fichiers du site et comment traiter les requêtes.

sudo nano /etc/nginx/sites-available/votre-site

Exemple de configuration minimale pour un site statique :

server {
    listen 80;
    listen [::]:80;

    server_name votre-domaine.com www.votre-domaine.com;

    root /var/www/votre-site/public;
    index index.html index.htm;

    access_log /var/log/nginx/votre-site.access.log;
    error_log /var/log/nginx/votre-site.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

La directive listen indique les ports utilisés. Le port 80 correspond à HTTP. La directive server_name précise les noms de domaine associés à ce site. La directive root définit le répertoire racine exposé par Nginx. La directive index indique les fichiers recherchés automatiquement lorsqu’un visiteur demande un répertoire. La directive location / traite les requêtes principales. Avec try_files $uri $uri/ =404, Nginx vérifie si le fichier demandé existe, puis si un dossier correspondant existe, et retourne une erreur 404 si aucune ressource n’est trouvée. Cette règle est adaptée aux sites statiques simples.

Pour activer le site, créez un lien symbolique dans sites-enabled :

sudo ln -s /etc/nginx/sites-available/votre-site /etc/nginx/sites-enabled/

Il est conseillé de désactiver la configuration par défaut si elle n’est plus utilisée :

sudo rm /etc/nginx/sites-enabled/default

Avant tout rechargement, testez la syntaxe de la configuration :

sudo nginx -t

Si le test est valide, rechargez Nginx sans couper les connexions en cours :

sudo systemctl reload nginx

À ce stade, le serveur peut répondre à votre nom de domaine, à condition que les enregistrements DNS pointent bien vers l’adresse IP du serveur. Un enregistrement A doit pointer vers l’adresse IPv4, et un enregistrement AAAA peut être ajouté pour l’IPv6. Pour vérifier la résolution DNS depuis le serveur ou depuis votre poste, vous pouvez utiliser :

dig votre-domaine.com
dig www.votre-domaine.com

Si le site utilise PHP, Nginx ne traite pas directement le code PHP. Il transmet les fichiers PHP à PHP-FPM, un gestionnaire de processus FastCGI chargé d’exécuter les scripts. Installez PHP-FPM avec les extensions nécessaires :

sudo apt install php-fpm php-cli php-mysql php-curl php-gd php-mbstring php-xml php-zip

Le nom exact du socket PHP-FPM dépend de la version installée. Vous pouvez l’identifier avec :

ls /var/run/php/

Vous obtiendrez par exemple un socket du type :

php8.3-fpm.sock

Le bloc serveur Nginx peut alors être adapté pour traiter les fichiers PHP :

server {
    listen 80;
    listen [::]:80;

    server_name votre-domaine.com www.votre-domaine.com;

    root /var/www/votre-site/public;
    index index.php index.html index.htm;

    access_log /var/log/nginx/votre-site.access.log;
    error_log /var/log/nginx/votre-site.error.log;

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

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
    }

    location ~ /\.ht {
        deny all;
    }
}

La règle try_files $uri $uri/ /index.php?$query_string est fréquente pour les CMS et frameworks PHP. Elle permet de rediriger les requêtes non résolues vers index.php, qui devient le point d’entrée de l’application. C’est notamment le cas avec WordPress, Laravel, Symfony ou d’autres applications utilisant un routeur applicatif. La section location ~ \.php$ intercepte les fichiers PHP et les transmet à PHP-FPM via le socket Unix. L’utilisation d’un socket local est souvent plus efficace qu’une connexion TCP lorsque Nginx et PHP-FPM tournent sur le même serveur. La règle location ~ /\.ht interdit l’accès aux fichiers commençant par .ht. Même si Nginx n’utilise pas les fichiers .htaccess, cette protection évite d’exposer des fichiers sensibles lors de migrations depuis Apache.

Pour tester PHP, créez temporairement un fichier d’information :

echo "<?php phpinfo(); ?>" | sudo tee /var/www/votre-site/public/info.php

Accédez ensuite à :

http://votre-domaine.com/info.php

Si PHP-FPM fonctionne, la page d’information PHP doit s’afficher. Ce fichier doit être supprimé immédiatement après le test, car il expose des informations techniques sensibles sur le serveur :

sudo rm /var/www/votre-site/public/info.php

Pour les applications modernes, il est souvent nécessaire de configurer des règles spécifiques. Par exemple, pour WordPress, la configuration Nginx peut inclure une gestion propre des permaliens :

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

Pour Laravel ou Symfony, la racine du serveur doit pointer vers le répertoire public du projet, et toutes les requêtes doivent être redirigées vers le contrôleur frontal :

root /var/www/votre-site/public;

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

Dans le cas d’une application Node.js, Nginx est souvent utilisé comme reverse proxy. L’application écoute sur un port local, par exemple 3000, tandis que Nginx reçoit le trafic public sur les ports 80 et 443.

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

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Les en-têtes X-Real-IP et X-Forwarded-For permettent à l’application de connaître l’adresse IP réelle du client. L’en-tête X-Forwarded-Proto indique si la requête d’origine est arrivée en HTTP ou HTTPS. Ces informations sont importantes pour les logs applicatifs, les redirections, la sécurité des cookies et la génération d’URL. Pour améliorer la lisibilité de la configuration, il est possible de factoriser certains paramètres dans des fichiers réutilisables. Par exemple, vous pouvez créer un fichier dédié aux paramètres de proxy :

sudo nano /etc/nginx/snippets/proxy-headers.conf

Avec le contenu suivant :

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Puis l’inclure dans vos blocs serveur :

include snippets/proxy-headers.conf;

La gestion des erreurs doit également être prévue. Vous pouvez définir des pages d’erreur personnalisées :

error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;

Les fichiers correspondants doivent exister dans la racine publique du site Internet. Cela permet d’offrir une réponse plus propre aux utilisateurs et de mieux contrôler l’affichage en cas d’incident. Les logs doivent être surveillés dès la phase de configuration. Pour suivre les accès en direct :

sudo tail -f /var/log/nginx/votre-site.access.log

Pour consulter les erreurs :

sudo tail -f /var/log/nginx/votre-site.error.log

Les erreurs les plus fréquentes concernent les permissions de fichiers, les chemins incorrects, les sockets PHP-FPM inexistants, les directives mal placées ou les conflits entre plusieurs blocs server_name. La configuration doit ensuite être validée à plusieurs niveaux. Le test syntaxique avec nginx -t vérifie uniquement la validité de la configuration Nginx. Il ne garantit pas que le site fonctionne correctement, que PHP répond, que le DNS est correct ou que l’application n’a pas d’erreur interne. Il faut donc compléter avec des tests HTTP :

curl -I http://votre-domaine.com
curl -I http://www.votre-domaine.com

Pour afficher le contenu retourné :

curl http://votre-domaine.com

Pour tester localement un domaine avant propagation DNS, vous pouvez interroger directement l’adresse IP du serveur en envoyant l’en-tête Host :

curl -H "Host: votre-domaine.com" http://adresse-ip-du-serveur

Enfin, il est important de comprendre la différence entre redémarrer et recharger Nginx. La commande suivante recharge la configuration sans interruption notable :

sudo systemctl reload nginx

La commande suivante redémarre complètement le service :

sudo systemctl restart nginx

En production, le rechargement est généralement préférable après une modification de configuration validée. Le redémarrage complet est plutôt réservé aux changements profonds, aux incidents ou aux mises à jour nécessitant une relance du service. Cette étape permet d’obtenir un serveur web fonctionnel, capable de servir un site statique, une application PHP ou un service applicatif via reverse proxy. Une fois cette base en place, il devient possible d’ajouter la couche HTTPS, la compression, le cache, les protections de sécurité, la supervision et les mécanismes de sauvegarde indispensables à une exploitation fiable.

Sécurisation, optimisation et mise en production du serveur web

Une fois le serveur web installé et capable de répondre aux requêtes HTTP, le travail n’est pas terminé. Un serveur accessible publiquement sur Internet devient immédiatement exposé aux robots d’analyse, aux tentatives de connexion automatisées, aux scans de vulnérabilités, aux erreurs de configuration et aux pics de trafic. La mise en production doit donc intégrer trois dimensions complémentaires : la sécurité, les performances et l’exploitation continue. La première étape consiste à activer HTTPS. Le protocole HTTPS chiffre les échanges entre le navigateur et le serveur grâce à TLS. Il protège les identifiants, les cookies de session, les formulaires, les données personnelles et les échanges applicatifs. Même pour un simple site vitrine, HTTPS est devenu un standard technique attendu. Avec Nginx, la méthode la plus courante consiste à utiliser Let’s Encrypt avec Certbot. Commencez par installer les paquets nécessaires :

sudo apt update
sudo apt install certbot python3-certbot-nginx

Demandez ensuite un certificat pour votre domaine :

sudo certbot --nginx -d votre-domaine.com -d www.votre-domaine.com

Certbot vérifie que le domaine pointe bien vers le serveur, génère un certificat TLS, modifie la configuration Nginx si nécessaire, puis propose généralement de rediriger automatiquement le trafic HTTP vers HTTPS. Une fois le certificat installé, vérifiez la configuration :

sudo nginx -t
sudo systemctl reload nginx

Les certificats Let’s Encrypt ont une durée de validité limitée. Certbot installe normalement un mécanisme de renouvellement automatique via systemd timer ou cron. Il faut néanmoins tester ce renouvellement :

sudo certbot renew --dry-run

Pour inspecter les timers actifs :

systemctl list-timers | grep certbot

Une configuration HTTPS de production ne doit pas seulement installer un certificat. Elle doit aussi forcer la redirection HTTP vers HTTPS, utiliser des protocoles TLS récents et ajouter certains en-têtes de sécurité. Un exemple de bloc Nginx peut ressembler à ceci :

server {
    listen 80;
    listen [::]:80;

    server_name votre-domaine.com www.votre-domaine.com;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name votre-domaine.com www.votre-domaine.com;

    root /var/www/votre-site/public;
    index index.php index.html;

    ssl_certificate /etc/letsencrypt/live/votre-domaine.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/votre-domaine.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

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

La redirection 301 force l’utilisation de HTTPS. Les protocoles TLSv1.2 et TLSv1.3 permettent d’éviter les anciennes versions TLS devenues obsolètes. Les en-têtes de sécurité limitent certains comportements dangereux côté navigateur, comme le détournement d’affichage dans une iframe ou la mauvaise interprétation des types MIME. L’en-tête HSTS peut également être ajouté, mais avec prudence. Il indique au navigateur de toujours accéder au site en HTTPS pendant une durée définie. Une mauvaise configuration HSTS peut bloquer l’accès au site si le certificat expire ou si HTTPS est mal configuré.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Avant d’activer HSTS sur tous les sous-domaines, vérifiez que chacun d’eux fonctionne correctement en HTTPS. La sécurisation du serveur ne s’arrête pas au chiffrement. L’accès SSH doit être durci. Il est fortement recommandé de désactiver la connexion directe en root et de privilégier une authentification par clé SSH. Le fichier à modifier est généralement :

/etc/ssh/sshd_config

Paramètres recommandés :

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Après modification, vérifiez que vous disposez bien d’une session SSH fonctionnelle avec votre utilisateur administrateur avant de recharger le service :

sudo systemctl reload ssh

Changer le port SSH par défaut peut réduire le bruit généré par les robots automatisés, mais cela ne remplace pas une vraie stratégie de sécurité. Si vous modifiez le port SSH, vous devez aussi adapter le pare-feu :

Port 2222

sudo ufw allow 2222/tcp
sudo ufw delete allow OpenSSH
sudo systemctl reload ssh

Le pare-feu doit limiter les ports exposés. Pour un serveur web classique, seuls les ports nécessaires doivent être ouverts : SSH, HTTP et HTTPS.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Pour limiter les tentatives de connexion répétées, installez Fail2ban :

sudo apt install fail2ban

Créez ensuite un fichier de configuration local afin de ne pas modifier directement les fichiers par défaut :

sudo nano /etc/fail2ban/jail.local

Exemple de configuration pour SSH :

[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
findtime = 10m
bantime = 1h

Redémarrez Fail2ban :

sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Il est aussi pertinent de sécuriser Nginx contre certaines requêtes indésirables. Par exemple, vous pouvez refuser l’accès aux fichiers cachés, aux sauvegardes et aux extensions sensibles :

location ~ /\.(?!well-known) {
    deny all;
}

location ~* \.(bak|old|orig|save|sql|env|ini|log)$ {
    deny all;
}

Si votre application utilise un fichier .env, celui-ci ne doit jamais se trouver dans un répertoire public. Une fuite de fichier .env peut exposer des identifiants de base de données, des clés API ou des secrets applicatifs. La gestion des permissions est un autre point fondamental. Les fichiers du site ne doivent pas être modifiables par n’importe quel utilisateur. Une base saine consiste à attribuer les fichiers au propriétaire applicatif et à limiter les droits d’écriture du serveur web aux répertoires qui en ont réellement besoin, comme les dossiers de cache ou d’upload.

sudo chown -R deploy:www-data /var/www/votre-site
sudo find /var/www/votre-site -type d -exec chmod 750 {} \;
sudo find /var/www/votre-site -type f -exec chmod 640 {} \;

Pour un CMS comme WordPress, certains répertoires nécessitent des droits d’écriture, notamment wp-content/uploads. Il faut éviter de donner des droits d’écriture globaux à toute l’arborescence. La deuxième grande dimension concerne les performances. Un serveur web performant répond vite, consomme peu de ressources et reste stable même lorsque le nombre de requêtes augmente. L’optimisation commence par la compression des réponses textuelles. Avec Nginx, Gzip peut être activé globalement :

gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_vary on;
gzip_types
    text/plain
    text/css
    text/xml
    application/json
    application/javascript
    application/xml
    application/rss+xml
    image/svg+xml;

La compression réduit le poids transféré pour les fichiers HTML, CSS, JavaScript, JSON et XML. Elle ne doit pas être appliquée inutilement aux fichiers déjà compressés comme les images JPEG, PNG, WebP, les archives ZIP ou les fichiers PDF. Le cache navigateur permet de réduire le nombre de requêtes envoyées au serveur pour les ressources statiques. Les fichiers versionnés, comme app.84fd3.css ou main.9ac12.js, peuvent avoir une durée de cache longue :

location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|webp|woff|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

Pour les pages HTML dynamiques, il faut être plus prudent. Mettre en cache une page personnalisée ou une page contenant des données utilisateur peut provoquer des fuites d’informations. La stratégie de cache doit donc tenir compte du type de contenu, de l’authentification et du comportement applicatif. Nginx peut également servir efficacement les fichiers statiques en activant certaines options d’envoi optimisé :

sendfile on;
tcp_nopush on;
tcp_nodelay on;

Ces directives sont généralement placées dans le bloc http du fichier /etc/nginx/nginx.conf. Elles améliorent la transmission des fichiers et la gestion des paquets réseau dans de nombreux cas.

Les paramètres de connexion doivent aussi être ajustés selon le trafic attendu :

keepalive_timeout 65;
client_max_body_size 64M;
client_body_timeout 30s;
client_header_timeout 30s;
send_timeout 30s;

client_max_body_size contrôle la taille maximale des fichiers envoyés au serveur. Si vous hébergez un site avec téléversement d’images ou de documents, cette valeur doit être adaptée. Une valeur trop basse provoquera des erreurs 413 Request Entity Too Large. Pour PHP-FPM, l’optimisation passe par le réglage du nombre de processus. Le fichier de pool se trouve généralement dans :

/etc/php/8.3/fpm/pool.d/www.conf

Les paramètres suivants contrôlent la capacité de traitement PHP :

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

pm.max_children doit être dimensionné selon la mémoire disponible. Si chaque processus PHP consomme en moyenne 80 Mo et que vous pouvez allouer 1,6 Go à PHP-FPM, une valeur autour de 20 processus est cohérente. Un réglage trop élevé peut saturer la mémoire et provoquer du swap, ce qui dégrade fortement les performances. Pour les applications utilisant une base de données, les performances ne dépendent pas uniquement de Nginx. Il faut surveiller les requêtes SQL lentes, les index manquants, les connexions trop nombreuses et la taille des tables. Sur MySQL ou MariaDB, le journal des requêtes lentes peut être activé :

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

Les caches applicatifs jouent également un rôle important. Selon le projet, vous pouvez utiliser Redis, Memcached, OPcache ou un système de cache de pages. Pour PHP, OPcache est généralement indispensable en production :

sudo apt install php-opcache

Exemple de paramètres OPcache :

opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=0

Dans un environnement avec déploiements fréquents, opcache.validate_timestamps=0 impose de redémarrer ou recharger PHP-FPM après chaque mise à jour du code. Ce réglage peut améliorer les performances, mais il doit être intégré au processus de déploiement. L’utilisation d’un CDN peut soulager le serveur d’origine en distribuant les fichiers statiques depuis des points de présence proches des utilisateurs. Un CDN peut aussi absorber une partie du trafic, mettre en cache les ressources publiques, réduire la latence internationale et ajouter une couche de filtrage contre certains trafics indésirables. La mise en production doit ensuite être préparée avec méthode. Avant d’ouvrir le service au public, il faut vérifier les points suivants :

• Le nom de domaine pointe vers la bonne adresse IP.
• Les ports 80 et 443 sont accessibles depuis l’extérieur.
• Le certificat TLS est valide et couvre tous les domaines nécessaires.
• La redirection HTTP vers HTTPS fonctionne correctement.
• Les permissions de fichiers sont maîtrisées.
• Les fichiers sensibles ne sont pas exposés.
• Les logs sont actifs et consultables.
• Les sauvegardes sont configurées et testées.
• Les services redémarrent automatiquement après un reboot.

Pour vérifier que Nginx est activé au démarrage :

sudo systemctl enable nginx
sudo systemctl enable php8.3-fpm

Les sauvegardes doivent être pensées avant l’incident, pas après. Un plan de sauvegarde complet inclut les fichiers applicatifs, les fichiers téléversés, les bases de données, les fichiers de configuration et, si nécessaire, les certificats. Pour une base MySQL, une sauvegarde simple peut être réalisée avec :

mysqldump -u utilisateur -p nom_base > sauvegarde.sql

Pour automatiser une sauvegarde de fichiers avec rsync :

rsync -avz /var/www/votre-site/ utilisateur@serveur-backup:/backups/votre-site/

Une sauvegarde non testée reste incertaine, c’est un point particulièrement étudié dans le cadre d’un audit de serveur Web. Il faut donc effectuer régulièrement une restauration sur un environnement de test afin de vérifier que les données sont réellement exploitables. La surveillance du serveur est indispensable après la mise en ligne. Les commandes de base permettent déjà d’obtenir une première vision de l’état système :

top
htop
free -m
df -h
ss -tulpen
journalctl -xe

Pour observer les logs Nginx en temps réel :

sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

Pour identifier les codes HTTP les plus fréquents dans les logs :

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr

Les codes 200, 301 et 304 sont généralement attendus. Une hausse de 404, 499, 500, 502, 503 ou 504 doit être analysée. Les erreurs 502 Bad Gateway indiquent souvent un problème entre Nginx et le service applicatif, par exemple PHP-FPM arrêté, socket incorrect, application Node.js indisponible ou timeout trop court. Les tests de charge permettent de connaître les limites du serveur avant qu’un trafic réel ne les révèle. Des outils comme ab, wrk ou siege peuvent simuler plusieurs requêtes simultanées :

sudo apt install apache2-utils
ab -n 1000 -c 50 https://votre-domaine.com/

Un test de charge doit être réalisé avec prudence, idéalement sur un environnement de préproduction ou pendant une période contrôlée. L’objectif n’est pas seulement d’obtenir un nombre de requêtes par seconde, mais aussi d’observer la mémoire, le CPU, les temps de réponse, les erreurs et le comportement des services dépendants. La rotation des logs doit également être configurée pour éviter de saturer le disque. Sur Ubuntu, Nginx dispose généralement d’une configuration logrotate prête à l’emploi dans :

/etc/logrotate.d/nginx

Il faut vérifier que les fichiers de logs personnalisés sont bien pris en compte. Un disque plein peut bloquer les écritures, provoquer des erreurs applicatives et rendre le serveur instable. La supervision avancée peut ensuite être confiée à des outils spécialisés comme Prometheus, Grafana, Zabbix, Netdata ou des solutions cloud. Les métriques importantes sont notamment l’usage CPU, la mémoire disponible, l’espace disque, le nombre de connexions, les erreurs HTTP, le temps de réponse, l’état des certificats TLS, la disponibilité DNS et l’état des services applicatifs. Une bonne mise en production inclut aussi une stratégie de déploiement. Modifier directement les fichiers en production par FTP ou éditeur manuel augmente le risque d’erreur. Une approche plus fiable consiste à utiliser Git, des répertoires de versions et un lien symbolique vers la version active :

/var/www/votre-site/releases/202604261200
/var/www/votre-site/shared
/var/www/votre-site/current -> /var/www/votre-site/releases/202604261200

Cette organisation facilite les retours arrière rapides en cas de déploiement défectueux. Le serveur web pointe vers :

root /var/www/votre-site/current/public;

Enfin, la maintenance régulière doit être intégrée dans l’exploitation du serveur. Elle comprend l’application des correctifs de sécurité, le renouvellement des certificats, la vérification des sauvegardes, l’analyse des logs, le contrôle des permissions, la suppression des fichiers temporaires, la surveillance de l’espace disque et l’audit des comptes utilisateurs. Un serveur web fiable n’est pas simplement un serveur qui répond aujourd’hui. C’est une infrastructure capable de rester disponible, sécurisée, observable et maintenable dans la durée. La qualité de sa mise en production dépend autant de sa configuration initiale que de la discipline appliquée à sa supervision et à sa maintenance continue, pour anticiper également tout PRA.