En bref. Les requêtes HTTP conditionnelles permettent aux clients de vérifier les réponses stockées à l’aide de validateurs et de réutiliser le contenu lorsque la revalidation renvoie 304 Not Modified.

Définition : Les requêtes HTTP conditionnelles comportent des champs d’en-tête qui précisent les conditions à vérifier avant d’appliquer la méthode demandée. Lors de récupérations répétées, ces conditions peuvent utiliser un validateur, une valeur décrivant une version précédemment récupérée, pour vérifier si le contenu stocké reste utilisable.

Points clés

La RFC 9110, HTTP Semantics définit deux formes de validateurs : les dates de modification et les étiquettes d’entité (entity tags), qui identifient les versions de la représentation d’une ressource.
La RFC 9111, HTTP Caching précise qu’une réponse 304 Not Modified permet à un cache de mettre à jour et de réutiliser une réponse stockée.
En juin 2026, la documentation de Google sur ses robots d’exploration indique la prise en charge des paires d’en-têtes ETag/If-None-Match et Last-Modified/If-Modified-Since.

Quels en-têtes transmettent les validateurs ?

Les définitions des validateurs dans la RFC 9110 décrivent ETag comme une chaîne opaque entre guillemets. Last-Modified fournit la date et l’heure auxquelles le serveur estime que la représentation sélectionnée a été modifiée pour la dernière fois. La spécification donne les exemples suivants :

ETag: "xyzzy"
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

Un validateur fort change chaque fois que les données de la représentation changent. Un validateur faible peut regrouper des versions considérées comme équivalentes pour la réutilisation ; un ETag faible porte le préfixe W/. La spécification autorise les étiquettes faibles pour la validation du cache au moyen de If-None-Match, qui utilise une comparaison faible.

Lors d’une requête GET ultérieure, le client peut envoyer l’étiquette stockée dans un en-tête de requête, comme dans cet exemple de la spécification :

If-None-Match: "xyzzy"

La condition correspondante fondée sur une date est If-Modified-Since.

Comment fonctionne la revalidation ?

Un cache stocke des réponses pour les réutiliser. Les règles de fraîcheur de la RFC 9111 permettent à une réponse fraîche, dont la durée de fraîcheur n’est pas encore écoulée, de satisfaire des requêtes ultérieures sans contacter le serveur d’origine. La directive max-age de Cache-Control ou l’en-tête Expires peuvent fournir une date d’expiration explicite.

Lorsqu’un cache dispose d’une réponse stockée qu’il ne peut pas servir directement, par exemple parce qu’elle est périmée, il peut envoyer une requête conditionnelle contenant les validateurs stockés. Ce processus s’appelle la revalidation. Une réponse 304 permet au cache de mettre à jour les métadonnées stockées et de réutiliser le contenu. Une réponse complète, qui inclut le contenu, remplace la réponse stockée désignée pour cette requête, et les règles de mise en cache déterminent si cette nouvelle réponse peut être stockée.

Selon la RFC 9110, une réponse 304 ne contient ni contenu ni champs de fin (trailers) : le client utilise sa représentation stockée.

Qu’est-ce que cela change pour la récupération par les robots d’exploration ?

La présentation des robots d’exploration et des outils de récupération de Google indique que Googlebot prend en charge la mise en cache lorsqu’il explore à nouveau des URL pour Google Search. Chaque robot d’exploration ou outil de récupération utilise la mise en cache selon les besoins du produit auquel il est associé.

La documentation recommande de définir à la fois ETag et Last-Modified. Lorsque les deux sont présents, les robots d’exploration de Google utilisent ETag ; Google le recommande parce qu’il évite les problèmes de formatage des dates. Pour la mise en œuvre, la documentation renvoie les propriétaires de sites vers leur hébergeur ou leur fournisseur de système de gestion de contenu.

Termes associés

Questions fréquentes

Que se passe-t-il si vous envoyez les deux conditions ?

La RFC 9110 impose au destinataire d’ignorer If-Modified-Since lorsque If-None-Match est présent. La condition portant sur l’étiquette d’entité est prioritaire.

Pouvez-vous imposer une validation avant chaque réutilisation ?

Selon la RFC 9111, une réponse portant Cache-Control: no-cache sans argument doit être transmise pour validation et une réponse positive doit être reçue avant toute réutilisation. Une validation réussie peut permettre la réutilisation du contenu stocké.

Sources

Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO

Requêtes HTTP conditionnelles