Configuration Serveur Apache vs Nginx : Guide Performances et Sécurité

Apache et Nginx propulsent ensemble plus de 60 % des sites web dans le monde. Pourtant, ces deux serveurs web reposent sur des architectures fondamentalement différentes — et ce choix architectural a des conséquences directes sur les performances, la consommation de ressources et la gestion de votre infrastructure. Que vous choisissiez votre premier VPS ou que vous optimisiez un serveur existant, comprendre les forces et faiblesses de chaque solution est essentiel.

Apache et Nginx : deux philosophies, deux architectures

Apache HTTP Server

Apache est le vétéran des serveurs web. Créé en 1995, il a longtemps été le choix par défaut de quasiment tout le web. Son nom est un jeu de mots — « a patchy server » — qui reflète ses origines comme collection de correctifs appliqués au serveur NCSA HTTPd.

Architecture : un processus par connexion

Apache utilise un modèle basé sur les processus (ou les threads avec le MPM worker). Pour chaque connexion client, Apache crée un processus ou un thread dédié. C’est un modèle intuitif et stable, mais gourmand en mémoire quand le nombre de connexions simultanées augmente.

Les trois modes de fonctionnement (MPM — Multi-Processing Modules) :

• prefork : un processus par connexion. Le plus stable, le plus gourmand en RAM. Requis pour mod_php.
• worker : des threads au sein de processus. Plus léger que prefork, mais incompatible avec certains modules.
• event : une évolution de worker qui gère mieux les connexions keep-alive. Le MPM recommandé aujourd’hui.

Nginx

Nginx (prononcé « engine-X ») a été créé en 2004 par Igor Sysoev pour résoudre un problème spécifique : le « C10K problem » — comment gérer 10 000 connexions simultanées sur un seul serveur.

Architecture : événementielle et asynchrone

Nginx utilise un modèle événementiel avec un nombre fixe de processus worker. Chaque worker peut gérer des milliers de connexions simultanées grâce à un mécanisme de multiplexage (epoll sous Linux). Il n’y a pas de création de processus ou de thread par connexion — c’est ce qui rend Nginx si efficace en termes de mémoire et de performances.

Analogie : imaginez un restaurant. Apache fonctionne comme un restaurant où chaque client a son propre serveur attitré. Si 200 clients arrivent, il faut 200 serveurs. Nginx fonctionne comme un restaurant avec 4 serveurs très organisés qui gèrent 200 clients en parallèle grâce à un système de tickets. — Sophie Laurent

Tableau comparatif technique

Performances comparées

Servir du contenu statique

C’est le terrain où Nginx domine le plus clairement. Grâce à son architecture événementielle, Nginx sert les fichiers statiques (images, CSS, JavaScript, HTML) avec une efficacité remarquable.

Benchmark : 10 000 requêtes concurrentes pour un fichier statique de 10 Ko

Nginx est 2,5 fois plus rapide qu’Apache prefork et utilise 5 fois moins de mémoire. Même avec le MPM event, Apache reste derrière en performances brutes sur le statique.

Servir du contenu dynamique (PHP)

Pour le contenu dynamique, les deux serveurs délèguent le traitement à PHP. La différence réside dans la manière dont ils communiquent avec PHP.

• Apache + mod_php : PHP est intégré directement dans chaque processus Apache. Simple mais gourmand : chaque processus Apache charge PHP en mémoire, même pour servir un fichier statique.
• Apache + PHP-FPM : Apache communique avec un pool PHP-FPM séparé via un socket. Plus efficace mais nécessite une configuration supplémentaire.
• Nginx + PHP-FPM : Nginx communique avec PHP-FPM via FastCGI. C’est le seul mode possible et c’est le plus performant.

Benchmark : 1 000 requêtes concurrentes sur une page WordPress

Sur le contenu dynamique, l’écart se réduit car le goulot d’étranglement devient PHP lui-même. Nginx reste légèrement plus efficace grâce à sa consommation mémoire inférieure, ce qui laisse plus de ressources pour PHP-FPM.

Configuration : .htaccess vs fichier centralisé

Apache et .htaccess

Le fichier .htaccess est l’une des forces — et des faiblesses — d’Apache. C’est un fichier de configuration distribué que vous pouvez placer dans n’importe quel répertoire pour modifier le comportement du serveur.

Exemple de .htaccess typique (redirections, cache, sécurité) :

# Redirection HTTP vers HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Cache navigateur
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
</IfModule>

# Sécurité : bloquer l'accès aux fichiers sensibles
<FilesMatch "\.(env|log|sql|bak)$">
    Require all denied
</FilesMatch>

# Protection contre le hotlinking
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://(www\.)?monsite\.fr [NC]
RewriteRule \.(jpg|jpeg|png|webp|gif)$ - [F]

Avantages de .htaccess :

• Configuration par répertoire sans redémarrer le serveur
• Idéal pour l’hébergement mutualisé (chaque utilisateur configure son espace)
• Déploiement de règles avec le code source du site

Inconvénients de .htaccess :

• Impact sur les performances : Apache vérifie la présence d’un .htaccess dans chaque répertoire à chaque requête
• Risque de sécurité : des erreurs dans .htaccess peuvent exposer des fichiers sensibles
• Difficile à debugger : les règles s’empilent et peuvent entrer en conflit

Nginx et le fichier de configuration centralisé

Nginx n’a pas d’équivalent de .htaccess. Toute la configuration se fait dans des fichiers centralisés (nginx.conf et les fichiers de virtual hosts dans sites-available/).

Exemple de configuration Nginx équivalente :

server {
    listen 443 ssl http2;
    server_name monsite.fr www.monsite.fr;

    root /var/www/monsite.fr/public;
    index index.php index.html;

    # SSL
    ssl_certificate /etc/letsencrypt/live/monsite.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/monsite.fr/privkey.pem;

    # Cache navigateur
    location ~* \.(webp|jpg|jpeg|png|gif|css|js)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # Bloquer l'accès aux fichiers sensibles
    location ~* \.(env|log|sql|bak)$ {
        deny all;
        return 404;
    }

    # PHP via FastCGI
    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # WordPress : réécriture d'URL
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

# Redirection HTTP vers HTTPS
server {
    listen 80;
    server_name monsite.fr www.monsite.fr;
    return 301 https://$server_name$request_uri;
}

Avantages de la configuration centralisée :

• Performances optimales : la configuration est lue une seule fois au démarrage
• Cohérence : tout est au même endroit, pas de surprises
• Plus facile à auditer et à versionner (git)

Inconvénients :

• Nécessite un accès root au serveur (impossible sur un hébergement mutualisé)
• Chaque modification demande un nginx -s reload (instantané et sans interruption, mais nécessite un accès SSH)

Sécurité : configuration recommandée

Sécuriser Apache

# Masquer la version d'Apache
ServerTokens Prod
ServerSignature Off

# Désactiver le listing des répertoires
Options -Indexes

# En-têtes de sécurité
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-XSS-Protection "1; mode=block"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

# SSL/TLS
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder On
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Sécuriser Nginx

# Masquer la version de Nginx
server_tokens off;

# En-têtes de sécurité
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

# SSL/TLS
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# Limiter les requêtes (anti brute-force)
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    # ... configuration PHP
}

Pour aller plus loin sur la sécurité de l’hébergement web, consultez notre guide dédié.

Nginx comme reverse proxy : la combinaison gagnante

L’un des usages les plus courants de Nginx aujourd’hui est en tant que reverse proxy devant un serveur d’application (Node.js, Python, Go, Ruby) ou même devant Apache.

Nginx devant Apache

Cette combinaison est très répandue et offre le meilleur des deux mondes :

• Nginx gère les connexions clients, sert le contenu statique et fait office de cache
• Apache traite le contenu dynamique (PHP) avec ses modules familiers

# Nginx comme reverse proxy devant Apache
server {
    listen 443 ssl http2;
    server_name monsite.fr;

    # Contenu statique servi directement par Nginx
    location ~* \.(css|js|webp|jpg|png|gif|ico|woff2)$ {
        root /var/www/monsite.fr/public;
        expires 1y;
    }

    # Tout le reste passe à Apache (port 8080)
    location / {
        proxy_pass http://127.0.0.1:8080;
        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;
    }
}

Nginx devant Node.js

Pour les applications Node.js (Express, Fastify, Next.js), Nginx est quasi indispensable :

upstream nodejs_app {
    server 127.0.0.1:3000;
    keepalive 64;
}

server {
    listen 443 ssl http2;
    server_name app.monsite.fr;

    location / {
        proxy_pass http://nodejs_app;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

Cas d’usage : quel serveur pour quel projet ?

Choisissez Apache si…

• Vous êtes sur un hébergement mutualisé : c’est souvent le seul choix disponible, et .htaccess est indispensable dans ce contexte
• Vous avez besoin de mod_php : certaines applications legacy requièrent mod_php
• Votre équipe connaît bien Apache : la familiarité a une valeur, surtout en production
• Vous utilisez des .htaccess complexes : certains CMS (WordPress, Drupal) génèrent des .htaccess que Nginx ne peut pas interpréter nativement

Choisissez Nginx si…

• Vous gérez votre propre serveur (VPS ou dédié) : vous avez l’accès root nécessaire pour configurer Nginx
• Les performances sont prioritaires : Nginx est plus rapide et plus léger
• Vous servez beaucoup de contenu statique : sites vitrines, galeries photos, fichiers téléchargeables
• Vous avez besoin d’un reverse proxy : Nginx excelle dans ce rôle
• Vous gérez un trafic élevé : au-delà de 5 000 connexions simultanées, Nginx gère bien mieux la charge
• Vous hébergez des applications non-PHP : Node.js, Python, Go

Choisissez Nginx + Apache si…

• Vous voulez le meilleur des deux mondes : performances Nginx pour le statique, compatibilité Apache pour le dynamique
• Vous migrez progressivement d’Apache vers Nginx

Et LiteSpeed dans tout ça ?

LiteSpeed est un troisième acteur qui mérite d’être mentionné. C’est un serveur web commercial (avec une version OpenLiteSpeed gratuite) qui combine les avantages d’Apache et de Nginx :

• Compatible .htaccess : LiteSpeed lit nativement les fichiers .htaccess d’Apache
• Architecture événementielle : performances comparables à Nginx
• Cache intégré : LiteSpeed Cache pour WordPress est considéré comme le meilleur plugin de cache
• Drop-in replacement : peut remplacer Apache sans modifier la configuration

C’est la raison pour laquelle des hébergeurs comme o2switch utilisent LiteSpeed plutôt qu’Apache : les clients bénéficient de la compatibilité .htaccess avec les performances d’une architecture événementielle.

Conclusion : Apache ou Nginx ?

Le choix entre Apache et Nginx n’est plus aussi tranché qu’il y a dix ans. Voici notre recommandation synthétique :

• Pour un nouveau projet sur VPS/dédié : Nginx est le choix par défaut. Plus performant, plus léger, plus adapté aux architectures modernes.
• Pour un hébergement mutualisé : Apache (ou LiteSpeed) est votre seul choix, et c’est un bon choix avec le MPM event et PHP-FPM.
• Pour un projet legacy avec des .htaccess complexes : Apache reste la valeur sûre, ou LiteSpeed si votre hébergeur le propose.
• Pour les performances maximales : Nginx devant PHP-FPM ou Nginx comme reverse proxy devant votre application.

L’important n’est pas tant le serveur web que vous choisissez, mais la qualité de sa configuration. Un Apache bien configuré surpassera toujours un Nginx avec les paramètres par défaut. Prenez le temps de sécuriser votre hébergement, d’optimiser le cache et de surveiller les performances — quel que soit le serveur qui tourne derrière.