« On passe à Nginx » revient dans chaque audit — parfois pour de bonnes raisons, parfois parce qu'un blog de 2014 l'a dit. Pourtant l'Apache du mutualisé héberge encore des milliers de WordPress sans urgence grâce à .htaccess. Et des stacks modernes tournent nginx devant Apache précisément parce que personne n'a migré les règles.
Nginx et Apache ne sont pas deux religions. Ce sont deux points dans le chemin des requêtes avec des forces différentes. Choisir « le meilleur » sans cartographier HTTP → PHP → statique → cache, c'est optimiser le mauvais étage.
Cartographier le chemin d'une requête
Avant de comparer des benchmarks, tracez ce qui se passe quand un visiteur charge une page. La requête passe-t-elle d'abord par un CDN ? Le serveur web sert-il des fichiers statiques directement, ou tout est-il renvoyé vers PHP ? Qui peut modifier les règles de réécriture — l'équipe technique ou le client via .htaccess ?
| Étape | Rôle nginx | Rôle Apache |
|---|---|---|
| TLS termination | Excellent | Correct (mod_ssl) |
| Fichiers statiques | Très rapide (sendfile) | Correct |
| Reverse proxy app | Natif, léger | mod_proxy |
| Réécriture URL | try_files, maps | .htaccess, mod_rewrite |
| PHP | Via PHP-FPM upstream | PHP-FPM ou mod_php |
| Auth basique répertoire | auth_basic | .htaccess AuthType |
La question utile : quelle part du trafic touche le serveur web avant PHP — et qui doit pouvoir changer les règles sans redéployer ?
Scénarios concrets : trois profils types
Scénario A — SaaS PHP-FPM, API + SPA
Environ septante pour cent des assets passent par un CDN. Pas de .htaccess client. Besoin de rate limiting et de proxy WebSocket. Nginx seul (ou nginx + CDN) suffit ; Apache n'apporte rien de décisif.
Scénario B — Hébergement mutualisé multi-clients WordPress
Règles .htaccess par site, plugins qui écrivent des rewrite rules, support mod_php historique. Apache reste le choix naturel — ou nginx avec conversion manuelle des règles, ce qui a un coût de migration souvent sous-estimé.
Scénario C — Transition progressive
Legacy Apache + nouvelle application Node. Nginx frontal → Apache (port 8080) + Node (port 3000) par bloc location. Architecture courante quand on ne peut pas tout migrer d'un coup.
Performance : ce que les benchmarks oublient
Nginx gagne sur connexions concurrentes et fichiers statiques. Apache avec mpm_event + PHP-FPM reste compétitif pour du PHP dynamique modéré. Le goulot d'étranglement est souvent PHP et MySQL, pas le serveur web lui-même.
Mesurez avant migration : TTFB origin avec et sans cache, part des réponses 304/200 statiques servies directement par nginx, coût mémoire de mod_php versus PHP-FPM. Un changement de serveur web sans ces chiffres, c'est parfois des semaines de migration pour cinq pour cent de gain — alors qu'un index SQL manquant vaut cinquante pour cent.
Hébergement mutualisé, VPS ou PaaS
Sur mutualisé, Apache et .htaccess sont souvent imposés ; nginx reste rarement configurable. Sur VPS, le choix est libre : nginx + PHP-FPM est recommandé pour un nouveau projet sans dette .htaccess. Sur PaaS, une couche d'abstraction (Caddy, Traefik) masque le serveur web — vous ne choisissez plus vraiment.
Sur VPS, installez un seul frontal sauf architecture hybride documentée — évitez nginx + Apache sans raison (double configuration TLS, double surface d'erreur).
Pour WordPress spécifiquement, le comparatif Apache ou nginx pour WordPress complète cette lecture. Pour une stack plus légère, voir aussi Nginx ou Caddy.
Le sommet : la réputation remplace rarement l'inventaire des requêtes
Changer de serveur web sans profiler, c'est parfois semaines de migration pour cinq pour cent de gain — alors qu'un index base de données vaut cinquante pour cent.
Décider et avancer sans angle mort
Sur une demi-journée, vous pouvez trancher sans angle mort. Tracez dix requêtes types (accueil, API, admin, asset). Listez les dépendances .htaccess et modules Apache requis. Mesurez le TTFB pour vérifier si le serveur web est vraiment le goulot. Si vous choisissez nginx, planifiez la conversion des règles et testez les redirections 301. Si vous combinez les deux, nginx ne doit servir que de proxy — un seul propriétaire de la configuration.
Consultez Apache ou nginx pour WordPress et Nginx ou Caddy. Pour choisir l'hébergement sous-jacent, parcourez l'annuaire et le comparateur.
Questions fréquentes
Nginx remplace-t-il toujours Apache ?
Non. Nginx est souvent meilleur en frontal (TLS, cache, reverse proxy). Apache reste pertinent si vous dépendez de .htaccess par répertoire, de mod_php legacy, ou de modules sans équivalent nginx. Le bon choix se lit dans votre stack, pas dans la réputation du logo.
Quelle combinaison pour PHP moderne ?
Nginx + PHP-FPM est le standard actuel. Apache + PHP-FPM fonctionne aussi. Évitez mod_php sur une production chargée : les workers mélangent charge web et charge PHP, ce qui complique le dimensionnement.
Peut-on utiliser les deux ?
Oui. Nginx en reverse proxy devant Apache ou devant des applications Node/Python est une architecture courante en migration progressive. L'important est de documenter qui termine TLS et où vivent les règles de réécriture.
Comment trancher en 30 minutes ?
Listez le pourcentage de trafic statique, le besoin .htaccess, les modules requis et la compétence équipe. Si quatre-vingts pour cent statique/CDN + PHP-FPM → nginx frontal. Si des dizaines de règles .htaccess client → Apache ou budget migration nginx.
Nginx ou Apache se choisit sur le chemin des requêtes — pas sur le logo de la slide architecture.