Les différentes configurations d’Apache

Apache a la réputation d’être bavard. On ouvre un fichier, on tombe sur des dizaines de directives, puis sur d’autres fichiers qui semblent faire presque la même chose ailleurs. C’est souvent là que commencent les bricolages : on ajoute une ligne dans le premier .conf venu, on relance le service, et on espère que le bon bloc sera pris en compte. En pratique, Apache est assez logique, mais il faut regarder sa configuration par couches. Tant qu’on ne sait pas si on touche un réglage global, un hôte virtuel, un répertoire précis ou un module, on corrige rarement le bon problème.

Le plus utile n’est donc pas d’apprendre une liste de directives par coeur. Il faut surtout comprendre où elles s’appliquent, dans quel ordre Apache les lit et ce qu’on gagne à séparer proprement les rôles. C’est cette lecture-là qui évite les configurations qui marchent « un peu », jusqu’au jour où un nouveau site, un certificat TLS ou une règle de réécriture fait tout dérailler.

Pour rester sur la même logique, jetez aussi un œil à Comment exposer votre site local au réseau local avec Laragon ou Apache.

Configuration globale, la base qui s’applique à tout le serveur

La configuration globale sert à définir le comportement général du serveur : utilisateur système, répertoires, journaux, modules chargés, options de sécurité, limites, ports d’écoute. Selon la distribution, on la trouve dans httpd.conf, apache2.conf ou dans un ensemble de fichiers inclus. C’est ici qu’on décide par exemple qu’Apache écoutera sur le port 80 ou 443, où seront stockés les logs, ou encore quels modules seront actifs.

Le piège classique consiste à mettre trop de logique métier à cet endroit. Un projet web particulier n’a pas grand-chose à faire dans la configuration globale. Si un réglage ne concerne qu’un site, il vaut mieux le garder dans un bloc <VirtualHost>. Cela limite les effets de bord et rend la lecture plus nette quand on revient six mois plus tard.

Autre point important : la configuration globale est aussi l’endroit où l’on structure les inclusions. Sur Debian et Ubuntu, le découpage entre mods-available, mods-enabled, sites-available et sites-enabled n’est pas décoratif. Il permet d’activer ou désactiver proprement un module ou un site sans réécrire tout le socle. Sur des serveurs gérés à plusieurs, ce découpage fait gagner du temps et évite les doublons.

# Vérifier la configuration complète chargée
apachectl -S
apachectl -M
apachectl configtest

Ces trois commandes disent souvent plus de choses qu’une longue séance de devinettes. apachectl -S permet de voir les vhosts réellement chargés, -M la liste des modules actifs et configtest détecte les erreurs de syntaxe avant un redémarrage raté.

Les VirtualHost, là où les sites commencent vraiment à se différencier

Le bloc <VirtualHost> sert à dire à Apache : pour cette adresse, ce port et ce nom d’hôte, voilà le comportement attendu. C’est là qu’on définit le ServerName, les alias éventuels, le DocumentRoot, les logs du site, les règles de réécriture spécifiques, les certificats TLS si l’on est en HTTPS. Dans la vraie vie, c’est souvent ce niveau de configuration qu’on modifie le plus.

Quand plusieurs sites cohabitent sur le même serveur, un vhost propre par site reste la solution la plus saine. On peut aussi distinguer un vhost HTTP qui redirige vers HTTPS, puis un vhost HTTPS qui contient la configuration applicative. Cela rend la lecture bien plus simple qu’un bloc unique qui mélange redirections, sécurité et logique de publication.

<VirtualHost *:80>
    ServerName exemple.fr
    ServerAlias www.exemple.fr
    DocumentRoot /var/www/exemple/public

    ErrorLog ${APACHE_LOG_DIR}/exemple-error.log
    CustomLog ${APACHE_LOG_DIR}/exemple-access.log combined

    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</VirtualHost>

Ce genre de bloc reste lisible parce qu’il fait une chose claire : accueillir le domaine en HTTP puis rediriger vers HTTPS. Si l’on commence à entasser des règles destinées à plusieurs applications, on finit avec des comportements difficiles à prédire.

Il faut aussi garder en tête que l’ordre de chargement des fichiers peut compter. Un vhost par défaut trop permissif ou un ServerName oublié peut envoyer des requêtes vers le mauvais site. Quand un domaine semble afficher la mauvaise application, le problème n’est pas toujours PHP, le framework ou le DNS. C’est parfois juste Apache qui a choisi le premier vhost disponible.

Répertoires, permissions et héritage des directives

Apache ne se limite pas aux vhosts. Une bonne partie du comportement se joue à l’intérieur des blocs <Directory>, <Location> et parfois <Files>. C’est là qu’on autorise ou non l’accès à un chemin, qu’on active des options comme Indexes, qu’on décide si un .htaccess sera pris en compte, ou qu’on limite certaines URL.

La différence entre ces blocs mérite d’être claire. <Directory> travaille sur le système de fichiers. <Location> travaille sur l’URL. <Files> cible des noms de fichiers. Mélanger les trois sans savoir pourquoi conduit souvent à des règles qui ont l’air correctes mais ne s’appliquent jamais au bon endroit.

Le sujet des .htaccess revient souvent. Ils peuvent rendre service dans des environnements mutualisés ou quand on n’a pas la main sur la configuration centrale. Mais sur un serveur qu’on administre soi-même, mieux vaut déplacer ces règles dans la configuration Apache. C’est plus rapide, plus lisible et plus prévisible. En plus, cela évite de laisser n’importe quelle option modifiable dans l’arborescence du site.

• AllowOverride None pour bloquer les surcharges inutiles
• Require all granted ou des règles plus fines pour contrôler l’accès
• Options -Indexes pour éviter l’affichage du contenu d’un dossier
• Des blocs ciblés par répertoire pour séparer public, privé et fichiers générés

Modules, réécriture et performance : ne pas tout activer par réflexe

Apache sait faire énormément de choses grâce à ses modules : réécriture d’URL, proxy inverse, compression, en-têtes HTTP, SSL, authentification, cache, PHP via différents modes. Cette richesse est pratique, mais elle pousse aussi à activer des briques sans réfléchir. Or chaque module ajoute de la complexité au diagnostic.

mod_rewrite est le meilleur exemple. Il dépanne beaucoup de cas, mais devient vite illisible si on l’utilise comme une boîte à outils universelle. Pour une redirection simple, Redirect de mod_alias suffit souvent et se lit beaucoup mieux. Il n’y a pas de médaille pour la règle la plus compacte si personne ne la comprend plus au prochain incident.

Sur la performance aussi, la configuration dépend du contexte. Un petit site vit très bien avec une configuration modeste. Une plateforme plus chargée demandera de regarder le modèle de processus, les workers, la compression, le cache et parfois le rôle d’Apache dans une architecture plus large derrière un répartiteur ou un proxy. Là encore, la bonne question n’est pas « quelle directive magique ajouter » mais « quel est le rôle exact de ce serveur ».

Une configuration Apache saine ressemble rarement à un gros fichier monolithique. Elle ressemble plutôt à un ensemble cohérent : une base globale courte, des vhosts clairs, des permissions explicites, peu de magie, et des tests avant chaque rechargement. À partir de là, même un changement sensible devient beaucoup moins stressant.