# Configurer mod_expires sous Apache pour un cache navigateur efficace
> 365 jours : une durée de cache raisonnable pour une image jamais renommée après publication, bien loin des quelques minutes, voire de l'absence totale d'expiration, appliquées par défaut sur la plupart des serveurs Apache.
- Auteur : WordPress Développement
- Publié le : 2026-10-08
- Mis à jour le : 2026-09-30
- Catégorie : Hébergement & serveurs
- URL : https://www.wpmoderne.fr/hebergement/mod-expires-apache-cache-navigateur/
## L’essentiel
- mod_expires ajoute un en-tête Expires calculé à partir du type MIME du fichier servi
- ExpiresByType permet des durées différenciées selon le type de fichier statique concerné
- Une image jamais renommée après publication supporte une durée de cache bien plus longue qu'une feuille de style appelée à évoluer
## 365 jours pour un fichier qui ne change jamais
365 jours : une durée de cache raisonnable pour une image jamais renommée après publication, bien loin des quelques minutes, voire de l'absence totale d'en-tête d'expiration, souvent laissées par défaut sur un serveur Apache tout juste installé. Le module `mod_expires` ajoute automatiquement un en-tête `Expires` (et l'en-tête `Cache-Control` associé, contenant `max-age`) à chaque réponse, en calculant la date d'expiration à partir du type MIME du fichier concerné et d'une durée définie dans la configuration.
Sans ce module actif, ou avec une configuration par défaut restée minimaliste, le navigateur d'un visiteur revalide potentiellement chaque fichier statique à chaque nouvelle visite, un aller-retour réseau superflu pour un fichier qui n'a, dans les faits, pas changé depuis des mois.
## Différencier les durées par type de fichier
> L'essentiel à retenir : mod_expires ajoute un en-tête Expires calculé à partir du type MIME du fichier servi ; ExpiresByType permet des durées différenciées selon le type de fichier statique concerné ; Une image jamais renommée après publication supporte une durée de cache bien plus longue qu'une feuille de style appelée à évoluer
La directive `ExpiresByType` permet d'attribuer une durée de cache adaptée à chaque type de contenu, plutôt qu'une seule valeur uniforme pour l'ensemble du site :
```
ExpiresActive On
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType text/html "access plus 0 seconds"
```
Cette différenciation reflète une réalité importante sur un site WordPress : les images de médiathèque, une fois publiées, changent rarement de contenu sous une même adresse, ce qui justifie une durée longue d'un an. Les feuilles de style et scripts, en revanche, évoluent au rythme des mises à jour de thème ou d'extensions, ce qui justifie une durée plus modérée. Le contenu HTML lui-même, généré dynamiquement à chaque requête sur WordPress, ne doit jamais recevoir d'en-tête d'expiration, sous peine d'afficher un contenu figé pendant une durée non souhaitée.
## Contourner le vrai problème du changement de contenu
Une durée de cache longue pose une question légitime : que se passe-t-il si le contenu d'un fichier change réellement, par exemple après le remplacement d'une image ou la mise à jour d'une feuille de style ? La réponse la plus robuste ne consiste pas à raccourcir la durée de cache par prudence, ce qui annulerait le bénéfice recherché, mais à changer l'adresse du fichier lui-même lors de chaque modification, une pratique déjà largement répandue via un numéro de version ajouté à l'adresse des feuilles de style et scripts par WordPress lui-même, ou via un nom de fichier différent pour chaque nouvelle version d'une image.
```
```
Avec ce paramètre de version dans l'adresse, une nouvelle valeur force le navigateur à télécharger une copie fraîche, sans jamais avoir besoin de raccourcir la durée de cache globale du site pour anticiper un changement futur incertain.
## Pièges fréquents
- Appliquer une durée d'un an uniforme à tous les types de fichiers, y compris au contenu HTML généré dynamiquement, ce qui fige des pages qui devraient au contraire toujours rester à jour
- Oublier que `mod_expires` doit être activé sur le serveur (`a2enmod expires` sous Debian ou Ubuntu) avant que la configuration ne produise le moindre effet, une étape parfois oubliée lors d'une migration de serveur
- Configurer une durée longue sans mécanisme de changement d'adresse à la modification, ce qui contraint un visiteur à conserver une ancienne version bien après sa mise à jour réelle sur le serveur
## Vérifier l'en-tête réellement renvoyé
Une simple requête avec les en-têtes affichés confirme la présence et la valeur exacte de l'en-tête `Expires` pour un fichier donné, une vérification à effectuer systématiquement après toute modification de cette configuration, plutôt que de supposer son bon fonctionnement sans confirmation directe.
```
curl -I https://exemple.fr/wp-content/uploads/2022/08/photo.jpg
```
## En résumé
> Un fichier statique qui ne change jamais de contenu n'a aucune raison d'être redemandé au serveur à chaque visite, seulement d'être redemandé le jour où son adresse change réellement.
Différencier les durées de cache par type de fichier avec `ExpiresByType`, tout en combinant cette approche à un changement d'adresse systématique lors des mises à jour, offre un cache navigateur à la fois efficace et sans risque de contenu obsolète affiché par erreur.