Apache ou Nginx : que choisir ?

Apache et Nginx servent tous deux du HTTP, mais leurs modèles de configuration et de concurrence diffèrent. Le choix ne se joue pas sur une mode : il dépend de l'application existante, de la manière dont vous voulez gérer les réécritures et des compétences disponibles pour exploiter le serveur.

Deux architectures

Apache traite les connexions avec des processus ou des threads, selon le module multi-processus (MPM) actif. Nginx utilise une boucle d'événements : quelques processus gèrent un grand nombre de connexions, ce qui réduit la mémoire consommée par connexion. Cette différence explique sa réputation sur les fichiers statiques et le reverse proxy, pas une supériorité universelle.

.htaccess et PHP-FPM

Si l'application fournit un .htaccess (WordPress, anciens CMS, règles de réécriture), Apache l'applique sans redémarrage, au prix d'une lecture du fichier à chaque requête. Nginx ignore .htaccess : il faut traduire les règles dans le bloc server. Dans les deux cas, PHP 8.4 passe par PHP-FPM sur Debian 13 ; libapache2-mod-php8.4 reste possible, mais mélange le serveur web et l'interpréteur dans le même processus.

Critères concrets

• Reprise d'une application documentée pour Apache, avec de nombreuses règles .htaccess : Apache est plus direct.
• Reverse proxy, terminaison TLS, plusieurs backends, beaucoup de statique : Nginx est le choix courant.
• Besoin d'un module Apache précis ou d'un panneau qui l'exige : Apache.
• Compétences de l'équipe et cohérence avec la préproduction : critère décisif, avant les benchmarks.

Ne faites pas tourner les deux sur le port 80. Choisissez-en un et arrêtez l'autre :

sudo systemctl disable --now apache2
sudo systemctl status nginx

Vérifier la configuration

sudo apachectl configtest
sudo nginx -t
sudo ss -ltnp '( sport = :80 or sport = :443 )'

Le dernier contrôle doit montrer un seul serveur en écoute par port. Pour une migration, testez d'abord sur un port secondaire ou un domaine de préproduction, puis comparez les codes HTTP avec curl -I. Une page d'accueil correcte ne prouve pas que les réécritures fonctionnent : testez les URL sans extension, les redirections et les erreurs 404.

En cas de doute, gardez la configuration la plus simple à maintenir pour votre équipe. Un serveur compris et sauvegardé vaut mieux qu'un serveur théoriquement plus rapide mais mal configuré.