Travailler en local avant de déployer en production, c’est une discipline que tout développeur web sérieux adopte rapidement. Le concept de host localhost désigne précisément cette adresse de bouclage (127.0.0.1) qui permet à votre machine de se comporter comme un serveur web à part entière. Configurer correctement cet environnement avec Apache ou Nginx évite des heures de débogage inutiles et reproduit fidèlement les conditions de production. Pourtant, beaucoup de développeurs se heurtent aux mêmes obstacles : fichiers de configuration mal placés, ports en conflit, virtual hosts mal déclarés. Ce guide pratique vous donne les clés pour paramétrer chacun de ces deux serveurs efficacement, comprendre leurs différences et adopter les bonnes pratiques dès le départ.
Pourquoi l’hébergement local change tout au développement web
Localhost désigne l’ordinateur local sur lequel un programme s’exécute. Concrètement, quand vous saisissez http://localhost dans un navigateur, votre machine reçoit et traite elle-même la requête sans passer par Internet. Cette adresse de bouclage est associée par défaut à l’IP 127.0.0.1, définie dans le fichier hosts de votre système d’exploitation.
L’intérêt dépasse la simple commodité. Tester une application web en local permet de simuler un vrai serveur HTTP, de vérifier les redirections, les en-têtes de réponse, le comportement des fichiers .htaccess ou encore les règles de réécriture d’URL. Sans serveur local, vous travaillez à l’aveugle.
Les deux grands acteurs du marché des serveurs web open source sont l’Apache Software Foundation et NGINX, Inc.. Apache domine depuis les années 1990 grâce à sa flexibilité et son écosystème de modules. Nginx a gagné du terrain grâce à son architecture événementielle, particulièrement adaptée aux charges élevées. En local, les deux fonctionnent très bien. Le choix dépend surtout de ce que vous déployez en production.
Un autre avantage souvent sous-estimé : travailler avec plusieurs virtual hosts locaux. Vous pouvez faire tourner simultanément projet-a.local et projet-b.local sur la même machine, chacun pointant vers un répertoire différent. C’est exactement ce que font Apache et Nginx avec les configurations de virtual hosts.
Configurer Apache pour faire tourner un host localhost
Apache HTTP Server s’installe facilement sur Linux, macOS et Windows. Sur Ubuntu, une seule commande suffit : sudo apt install apache2. Sur macOS, Apache est préinstallé depuis des années, même si Homebrew propose une version plus récente et plus facile à gérer.
Une fois installé, le serveur écoute par défaut sur le port 80. La configuration principale se trouve dans /etc/apache2/apache2.conf sur Debian/Ubuntu, ou dans /usr/local/etc/httpd/httpd.conf si vous passez par Homebrew. Les virtual hosts, eux, se déclarent dans des fichiers séparés placés dans /etc/apache2/sites-available/.
Voici les étapes pour créer un virtual host local avec Apache :
- Créer un fichier de configuration, par exemple monprojet.conf, dans le dossier sites-available
- Déclarer le bloc VirtualHost avec l’adresse 127.0.0.1:80 et le ServerName souhaité (ex : monprojet.local)
- Définir le DocumentRoot pointant vers le dossier racine de votre projet
- Activer le site avec la commande
sudo a2ensite monprojet.conf - Ajouter la ligne 127.0.0.1 monprojet.local dans votre fichier /etc/hosts
- Relancer Apache avec
sudo systemctl reload apache2
Le module mod_rewrite mérite une attention particulière. Il gère les règles de réécriture d’URL, indispensables pour les frameworks PHP comme Laravel ou Symfony. Activez-le avec sudo a2enmod rewrite et assurez-vous que la directive AllowOverride All est bien présente dans votre bloc VirtualHost, sinon les fichiers .htaccess seront ignorés.
La documentation officielle d’Apache HTTP Server reste la référence pour les directives avancées. Elle couvre chaque paramètre avec des exemples concrets, particulièrement utile quand vous attaquez la configuration SSL en local avec des certificats auto-signés.
Mettre en place Nginx sur votre machine de développement
Nginx adopte une approche différente d’Apache. Là où Apache crée un processus ou un thread par connexion, Nginx gère les requêtes de façon asynchrone et non bloquante. En local, cette différence d’architecture est imperceptible. Mais si vous travaillez sur un projet destiné à supporter une forte charge, autant s’y habituer dès le développement.
L’installation sur Ubuntu passe par sudo apt install nginx. La configuration principale se trouve dans /etc/nginx/nginx.conf, et les virtual hosts (appelés server blocks dans le vocabulaire Nginx) se déclarent dans /etc/nginx/sites-available/.
Les étapes pour configurer un server block local avec Nginx :
- Créer un fichier de configuration dans sites-available, par exemple monprojet
- Déclarer un bloc server avec listen 80 et server_name monprojet.local
- Définir le root pointant vers le répertoire racine du projet
- Ajouter un bloc location / avec la directive tryfiles $uri $uri/ /index.php?$querystring pour les applications PHP
- Créer un lien symbolique vers sites-enabled avec
sudo ln -s /etc/nginx/sites-available/monprojet /etc/nginx/sites-enabled/ - Ajouter 127.0.0.1 monprojet.local dans /etc/hosts
- Tester la configuration avec
sudo nginx -tavant de recharger
Nginx ne lit pas les fichiers .htaccess. C’est une différence fondamentale avec Apache. Toutes les règles de réécriture doivent être intégrées directement dans le fichier de configuration du server block. Pour WordPress, la règle standard est bien documentée dans la documentation officielle de Nginx.
Pour les projets PHP, Nginx délègue le traitement à PHP-FPM via un socket Unix ou TCP. La configuration du bloc location ~ \.php$ doit pointer vers le bon socket, généralement /var/run/php/php8.x-fpm.sock. Un mauvais chemin de socket génère une erreur 502 déconcertante au premier abord.
Apache ou Nginx : lequel choisir pour travailler en local
La question revient souvent. La réponse honnête : les deux conviennent parfaitement pour un environnement de développement local. Les critères de choix sont ailleurs.
Apache s’impose quand votre projet utilise massivement les fichiers .htaccess. Les CMS comme WordPress, Joomla ou Drupal génèrent des règles .htaccess automatiquement. Avec Apache, ça fonctionne sans intervention supplémentaire. La syntaxe de configuration est aussi plus verbieuse mais plus lisible pour les débutants.
Nginx convient mieux aux projets modernes basés sur des frameworks JavaScript (Node.js, Next.js) ou des applications nécessitant un reverse proxy. Sa syntaxe de configuration est plus concise. Un server block Nginx fait souvent moitié moins de lignes qu’un VirtualHost Apache équivalent.
Sur les performances en local, la différence est négligeable. En revanche, si votre serveur de production tourne sous Nginx, travailler localement avec le même serveur réduit les surprises au déploiement. Les règles de réécriture, les redirections, les en-têtes de sécurité : tout se comporte identiquement.
Certains développeurs utilisent XAMPP ou Laragon sur Windows, qui embarquent Apache préconfiguré. Sur macOS, Valet (de Laravel) installe et configure Nginx automatiquement avec une gestion des domaines .test très pratique. Ces outils accélèrent la mise en route mais masquent la configuration sous-jacente, ce qui peut devenir un handicap quand un problème survient.
Résoudre les problèmes courants et sécuriser votre environnement local
Le problème le plus fréquent au démarrage : le port 80 déjà utilisé. Sur macOS, le service AirPlay Receiver occupe parfois ce port. Sur Windows, IIS peut être actif en arrière-plan. La commande sudo lsof -i :80 (Linux/macOS) ou netstat -ano | findstr :80 (Windows) identifie le processus fautif en quelques secondes.
Autre source d’erreurs : les permissions de fichiers. Apache et Nginx s’exécutent sous un utilisateur système (www-data sur Debian/Ubuntu). Si votre répertoire de projet n’est pas lisible par cet utilisateur, vous obtenez une erreur 403 Forbidden. sudo chown -R www-data:www-data /var/www/monprojet règle généralement le problème.
La gestion des certificats SSL en local mérite qu’on s’y attarde. L’outil mkcert génère des certificats locaux reconnus par votre navigateur sans avertissement de sécurité. Une fois installé, mkcert monprojet.local crée les fichiers .pem nécessaires à configurer dans votre VirtualHost ou server block. Travailler en HTTPS en local détecte les problèmes de contenu mixte avant la mise en production.
Pour les logs, pensez à les consulter systématiquement quand quelque chose ne fonctionne pas. Les fichiers access.log et error.log d’Apache se trouvent dans /var/log/apache2/. Ceux de Nginx dans /var/log/nginx/. La commande tail -f /var/log/nginx/error.log affiche les erreurs en temps réel pendant que vous testez.
Un dernier point souvent négligé : documenter vos configurations locales. Versionner vos fichiers de virtual hosts dans votre dépôt Git, dans un dossier devops/ ou config/, permet à tout nouveau développeur rejoignant le projet de reproduire l’environnement local en moins de dix minutes. C’est un gain de temps collectif qui s’accumule sur la durée d’un projet.