En bref. La négociation de contenu utilise les informations de la requête pour sélectionner une représentation, tandis que les en-têtes de réponse décrivent le contenu choisi et ses dépendances pour la mise en cache.

Définition : La négociation de contenu (content negotiation) est le mécanisme HTTP qui sélectionne une représentation, c’est-à-dire une forme transférable de l’état d’une ressource, par exemple dans un format ou une langue donnés. Dans la négociation pilotée par le serveur, celui-ci utilise les informations de la requête, dont les en-têtes de préférence, pour choisir parmi les représentations disponibles.

Points clés

La RFC 9110, HTTP Semantics de l’IETF, publiée en juin 2022, appelle « négociation proactive » la sélection pilotée par le serveur.
Selon la RFC 9111, HTTP Caching de l’IETF, un cache, qui stocke des réponses pour les réutiliser, vérifie les en-têtes de requête mentionnés dans le champ Vary de la réponse avant toute réutilisation sans revalidation.
Au 17 octobre 2026, la documentation de Google sur l’exploration des pages adaptatives selon les paramètres régionaux indique que Googlebot envoie ses requêtes sans en-tête Accept-Language.

Comment les en-têtes de requête orientent-ils la sélection ?

Un type de média identifie un format de données, comme text/html. Dans la RFC 9110, Accept exprime les préférences de type de média pour la réponse, Accept-Language les préférences linguistiques et Accept-Encoding les codages de contenu acceptables, comme la compression gzip.

Ces exemples d’en-têtes de requête proviennent de la RFC :

Accept: text/plain; q=0.5, text/html,
       text/x-dvi; q=0.8, text/x-c
Accept-Language: da, en-gb;q=0.8, en;q=0.7
Accept-Encoding: compress, gzip

Le paramètre q attribue un poids relatif à chaque préférence. Sa valeur va de zéro à un ; zéro signifie « inacceptable » et l’absence de poids équivaut à un. Dans l’exemple linguistique, le danois est préféré, suivi de l’anglais britannique, puis des autres variantes de l’anglais.

Le serveur compare ces préférences aux représentations dont il dispose. L’absence d’un en-tête de négociation n’exprime aucune préférence pour la dimension concernée. Si aucune représentation disponible ne satisfait les préférences indiquées, le serveur peut renvoyer 406 Not Acceptable ou ignorer la préférence et envoyer une représentation de repli.

Que décrivent les en-têtes de réponse et Vary ?

La réponse décrit la représentation sélectionnée. La RFC 9110 définit Content-Type pour son type de média, Content-Encoding pour les codages de contenu appliqués et Content-Language pour les langues naturelles du public auquel elle est destinée.

La RFC donne cet exemple d’en-tête de réponse :

Vary: accept-encoding, accept-language

Il signale que ces champs de requête, y compris leur absence, ont pu influencer la sélection. Un cache stocke des réponses pour les réutiliser ultérieurement. Selon la RFC 9111, la réutilisation sans revalidation exige que les valeurs des champs mentionnés dans Vary correspondent, après une éventuelle normalisation qui préserve leur sens. Un champ absent correspond à un autre champ absent. La spécification indique aussi que l’omission de l’en-tête Vary dans les réponses par défaut peut entraîner la réutilisation de réponses en cache moins adaptées.

Pourquoi la négociation linguistique compte-t-elle pour l’exploration ?

Une page adaptative selon les paramètres régionaux modifie son contenu en fonction du pays présumé du visiteur ou de sa langue préférée. La documentation de Google sur ces pages avertit que Google peut ne pas repérer le contenu destiné à certains paramètres régionaux. L’absence documentée d’Accept-Language rend la réponse à une requête sans ce champ pertinente lors d’un audit de l’exploration.

Google recommande des URL distinctes pour les versions régionales ou linguistiques, reliées par des annotations de versions linguistiques alternatives utilisant l’attribut hreflang. Chaque version dispose alors de sa propre adresse.

Comment vérifier la sélection effectuée par un site ?

Une vérification pratique s’appuie sur les champs de requête et de réponse définis dans la RFC 9110 : comparer des requêtes vers la même URL avec différentes valeurs d’Accept, d’Accept-Language ou d’Accept-Encoding, puis comparer le contenu renvoyé et les en-têtes de représentation. Le contrôle inclut une requête sans préférence linguistique. Pour les réponses destinées à une réutilisation sélective en cache, il consiste aussi à vérifier que Vary mentionne les champs de requête qui interviennent dans la sélection.

Termes associés

Questions fréquentes

Un en-tête Accept oblige-t-il le serveur à envoyer le format indiqué ?

Le serveur peut respecter votre préférence ou l’ignorer. La RFC 9110 autorise une réponse 406 Not Acceptable lorsque les représentations disponibles ne satisfont pas les préférences demandées, ainsi qu’une réponse de repli qui ignore la préférence.

Dois-je définir Vary lorsque je propose plusieurs langues à une même URL ?

La RFC 9110 recommande Vary sur les réponses pouvant être mises en cache et destinées à une réutilisation sélective, y compris lorsque Accept-Language détermine la langue. Si votre sélection dépend de cet en-tête, Vary: Accept-Language informe les caches de cette dépendance.

Sources

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

Négociation de contenu