# Apache ou nginx pour WordPress : notre comparatif après une migration réelle

> Après avoir basculé un parc de sites d'Apache vers nginx, voici ce qui a réellement changé : performance, complexité de configuration, et compatibilité avec l'existant.

- Auteur : Clément Hadrot
- Publié le : 2020-10-06
- Mis à jour le : 2020-10-06
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/apache-ou-nginx-wordpress-comparatif-migration/

## L’essentiel

- nginx gère mieux les connexions simultanées avec moins de mémoire
- Apache reste plus permissif grâce au .htaccess
- La migration exige de réécrire toutes les règles de réécriture

Le débat Apache contre nginx traîne depuis plus de dix ans dans les forums d'administration système, souvent sur un ton quasi religieux. Après avoir migré un parc d'une quinzaine de sites WordPress hébergés sur des VPS mutualisés en interne, d'Apache vers nginx, il nous semblait utile de sortir du débat théorique et de regarder ce qui a réellement changé sur des sites en production, avec du vrai trafic.

Le résultat n'est pas un vainqueur absolu, mais un ensemble de compromis différents. Ce comparatif détaille les cinq points qui ont le plus pesé dans notre décision, et ceux qui, avec le recul, méritaient plus d'attention avant de se lancer.

## Consommation mémoire, l'écart le plus net

Apache, dans sa configuration historique avec le module `mod_php`, crée un processus ou un thread par connexion, chacun chargeant l'intégralité de l'interpréteur PHP en mémoire. Sous forte charge, cela peut représenter plusieurs centaines de mégaoctets rien que pour maintenir les connexions ouvertes. nginx, de son côté, traite les connexions de façon asynchrone avec un nombre limité de processus workers, et délègue l'exécution PHP à des processus PHP-FPM séparés, réutilisés efficacement.

Sur nos VPS de 4 Go de RAM hébergeant chacun trois à quatre sites, le passage à nginx a permis une baisse de consommation mémoire d'environ 40 % à trafic comparable, ce qui a concrètement permis de réduire la taille des instances louées.

## Le confort perdu du .htaccess

Sous Apache, WordPress génère et modifie automatiquement un fichier `.htaccess` à la racine du site pour gérer les permaliens, certaines redirections, et parfois des règles ajoutées par des extensions. Ce mécanisme est pratique : un client ou un plugin peut modifier son comportement sans toucher à la configuration centrale du serveur.

> L'essentiel à retenir : nginx gère mieux les connexions simultanées avec moins de mémoire ; Apache reste plus permissif grâce au .htaccess ; La migration exige de réécrire toutes les règles de réécriture

nginx ne lit pas ce fichier. Toute règle doit être écrite dans le bloc serveur central, ce qui signifie qu'une extension qui tenterait d'ajouter une règle de réécriture via `.htaccess` ne fonctionnera simplement pas. Certains plugins de redirection ou de cache, conçus en pensant uniquement à Apache, ont dû être remplacés ou reconfigurés manuellement après la migration.

## La réécriture des règles existantes

Migrer d'un serveur à l'autre a exigé de reprendre une par une les règles accumulées dans les fichiers `.htaccess` de chaque site : redirections d'anciennes URL, blocages d'IP, protections par mot de passe sur certains répertoires. Aucune de ces règles ne se traduit automatiquement ; chacune a dû être retranscrite dans la syntaxe nginx, souvent très différente.

| Besoin | Syntaxe Apache (.htaccess) | Équivalent nginx |
| --- | --- | --- |
| Redirection 301 | `Redirect 301 /ancien /nouveau` | `rewrite ^/ancien$ /nouveau permanent;` |
| Blocage d'IP | `Deny from 1.2.3.4` | `deny 1.2.3.4;` |
| Interdire un dossier | `Options -Indexes` | `autoindex off;` |

## Gestion des connexions simultanées sous forte charge

Le point le plus visible en production concerne les pics de trafic. Lors d'une campagne d'e-mailing ayant généré un afflux soudain de visiteurs sur un des sites migrés, le comportement observé sous nginx a été nettement plus stable : les temps de réponse restaient constants, alors que le même scénario sous Apache, quelques mois plus tôt, avait provoqué un net ralentissement général du serveur, y compris pour les autres sites hébergés dessus.

## Ce qu'Apache fait encore mieux

- La configuration par répertoire via `.htaccess` reste précieuse pour déléguer des réglages sans toucher au serveur central, utile en environnement mutualisé.
- La richesse des modules disponibles (réécriture avancée, authentification variée) est plus mature côté Apache après des décennies d'existence.
- La documentation en français et les tutoriels grand public restent souvent plus abondants pour Apache.

> Changer de serveur web n'est jamais gratuit : ce n'est pas seulement remplacer un logiciel par un autre, c'est réécrire toute une couche de règles accumulées au fil des années sur chaque site.

## Notre verdict

Pour un parc de sites géré en interne, avec une équipe capable de maintenir une configuration centralisée, nginx a démontré un net avantage en performance et en stabilité sous charge. Pour un environnement mutualisé où chaque client doit pouvoir ajuster son comportement sans compétence système, Apache et son `.htaccess` restent plus pragmatiques. Le choix dépend moins de la technologie elle-même que de qui administre réellement le serveur au quotidien.