Le code HTTP 406 fait partie de ces messages d’erreur moins connus que le 404 ou le 500, mais il peut bloquer l’accès à une page, perturber une API ou compliquer le diagnostic d’un problème serveur. Derrière son intitulé officiel, “Not Acceptable”, il signale un désaccord entre ce que le client demande et ce que le serveur est capable de fournir.
Le code HTTP 406, aussi appelé 406 Not Acceptable, indique qu’un serveur a bien compris la requête envoyée par le navigateur, une application ou un robot, mais qu’il ne peut pas renvoyer une réponse dans un format jugé acceptable par le client. Autrement dit, la ressource existe potentiellement, mais la manière dont elle devrait être livrée pose problème.
Cette erreur appartient à la famille des codes HTTP 4xx, qui signalent généralement un problème côté client ou dans la requête envoyée. Elle ne signifie donc pas forcément que le site est hors service. Elle indique plutôt un écart entre les préférences exprimées dans la requête et les formats disponibles côté serveur.
Dans la pratique, le code 406 est souvent lié aux mécanismes de négociation de contenu. Lorsqu’un navigateur demande une page, il peut préciser les types de contenus qu’il accepte : HTML, JSON, XML, image WebP, langue française, encodage gzip, etc. Si le serveur ne peut répondre à aucune de ces conditions, il peut retourner une erreur 406.
Pour comprendre le statut HTTP 406, il faut regarder ce qui se passe dans les en-têtes de requête. Lorsqu’un client contacte un serveur, il ne demande pas toujours simplement “donne-moi cette page”. Il peut aussi préciser sous quelle forme il souhaite la recevoir.
Plusieurs en-têtes HTTP peuvent intervenir, notamment Accept, qui indique les formats MIME acceptés, Accept-Language, qui précise les langues préférées, ou encore Accept-Encoding, qui concerne les méthodes de compression. Le serveur compare ces indications avec ce qu’il peut fournir.
Par exemple, une application peut demander uniquement une réponse en application/json. Si le serveur ne propose que du HTML pour l’URL concernée, il peut considérer qu’aucune réponse acceptable n’est disponible. Dans ce cas, il renvoie un code 406 au lieu de transmettre une ressource dans un format non souhaité.
Ce mécanisme est utile, car il permet d’adapter les contenus aux usages : pages web pour les navigateurs, données structurées pour les API, langues différentes selon l’utilisateur. Mais lorsqu’il est mal configuré, il peut produire des erreurs difficiles à interpréter pour un visiteur comme pour un administrateur.
Une erreur 406 Not Acceptable peut apparaître dans des contextes variés. Elle n’a pas une cause unique, ce qui explique pourquoi son diagnostic demande souvent de croiser plusieurs indices : type de requête, configuration serveur, CMS utilisé, extensions installées ou règles de sécurité.
Sur un site WordPress, par exemple, une extension de sécurité peut bloquer certains paramètres d’URL ou certaines chaînes de caractères dans une requête. Le serveur peut alors répondre par un code 406 plutôt que par une page classique. Ce comportement vise souvent à protéger le site, mais il peut aussi créer de faux positifs.
Dans d’autres cas, l’erreur survient dans une API REST. Un développeur envoie une requête avec un en-tête Accept trop précis, comme une version particulière d’un format, alors que le serveur ne connaît pas cette variante. Le problème n’est pas forcément la ressource, mais le dialogue entre client et serveur.
Le code 406 est parfois confondu avec d’autres erreurs HTTP. Pourtant, sa signification est spécifique. Un 404 indique qu’une ressource est introuvable, alors qu’un 406 suggère plutôt que la ressource ne peut pas être fournie dans le format demandé. La nuance est importante pour éviter un mauvais diagnostic.
Il se distingue aussi du 403 Forbidden, qui correspond à une interdiction d’accès. Dans ce cas, le serveur refuse de livrer la ressource, même si la requête est compréhensible. Pour situer cette différence, un refus d’accès côté serveur répond à une logique d’autorisation, tandis que le 406 relève surtout de l’acceptabilité du contenu.
Le 405 Method Not Allowed est encore différent : il indique que la méthode HTTP utilisée, par exemple POST, GET ou DELETE, n’est pas autorisée pour l’URL demandée. Une analyse de une méthode non autorisée par le serveur permet de mieux comprendre cette distinction entre format de réponse et méthode de requête.
Ces différences ne sont pas seulement théoriques. Elles orientent les actions à mener. Face à un 404, on vérifie l’existence de la page. Face à un 403, on contrôle les droits. Face à un HTTP 406, on examine surtout les en-têtes, les formats disponibles et les règles de négociation.
Pour l’internaute, une erreur 406 se traduit souvent par une page blanche, un message technique ou une réponse incompréhensible. Même si elle est moins fréquente que d’autres erreurs, elle peut dégrader la qualité de navigation, notamment si elle touche des pages importantes, des formulaires ou des zones de connexion.
Du point de vue du référencement naturel, le risque dépend de l’ampleur du problème. Une erreur isolée, temporaire et peu visible aura généralement un impact limité. En revanche, si des pages stratégiques renvoient régulièrement un statut 406 aux robots d’exploration, les moteurs peuvent rencontrer des difficultés à analyser le contenu.
Googlebot et les autres robots envoient leurs propres en-têtes HTTP. Une configuration trop restrictive peut donc bloquer certains accès sans affecter tous les utilisateurs humains. C’est l’un des pièges du code 406 : le site peut sembler fonctionner normalement dans un navigateur, tout en renvoyant une réponse non acceptable à certains clients.
Pour un site éditorial, e-commerce ou institutionnel, il est donc recommandé de surveiller les logs serveur et les rapports d’exploration. Des occurrences répétées de 406 Not Acceptable peuvent révéler un problème discret mais pénalisant pour l’indexation, la conversion ou la stabilité technique.
Le diagnostic commence par l’identification du contexte. L’erreur apparaît-elle sur une page précise, sur tout le site, uniquement avec une API, ou seulement depuis certains navigateurs ? Cette première étape permet de distinguer un problème global de configuration d’un cas plus ciblé.
Il faut ensuite analyser les en-têtes de requête. Des outils comme les consoles développeur des navigateurs, curl, Postman ou les journaux serveur permettent de voir quel en-tête Accept est envoyé et quelle réponse le serveur retourne. Une différence entre deux clients peut révéler l’origine de l’erreur.
Les logs du serveur web sont également précieux. Ils peuvent indiquer si la réponse 406 provient du serveur lui-même, d’un module de sécurité, d’un proxy, d’un CDN ou d’une application. Cette information évite de modifier inutilement le code du site lorsque le blocage vient d’une règle externe.
Sur un CMS, il est utile de désactiver temporairement les extensions de sécurité, de cache ou d’optimisation, puis de tester à nouveau. Si l’erreur disparaît, la cause se trouve probablement dans une règle appliquée par l’un de ces composants. Cette méthode doit être menée avec prudence, idéalement sur un environnement de test.
La correction dépend de la cause identifiée. Si le problème vient du client, il peut suffire d’élargir l’en-tête Accept pour autoriser plusieurs formats de réponse. Dans une API, par exemple, demander application/json sans exclure toutes les autres variantes peut éviter un rejet inutile.
Si le blocage vient du serveur, il faut vérifier les règles de négociation de contenu, les directives Apache ou Nginx, les paramètres du CDN et les modules de sécurité. Une règle trop agressive peut être ajustée pour laisser passer les requêtes légitimes tout en conservant une protection efficace.
Dans le cas d’un pare-feu applicatif, la solution consiste souvent à identifier la règle qui déclenche le blocage. Il ne s’agit pas de désactiver toute la sécurité, mais de créer une exception précise pour un endpoint, un paramètre ou un type de requête fiable. Cette approche limite les risques.
Pour les sites utilisant un CMS, la mise à jour des extensions, du thème et du noyau peut aussi résoudre certaines incompatibilités. Une extension ancienne peut générer des en-têtes incorrects ou interagir maladroitement avec le serveur. Un contrôle après chaque changement important permet de prévenir la réapparition du code HTTP 406.
Le code 406 signifie que le serveur ne peut pas fournir une réponse conforme aux critères exprimés par le client. Il ne s’agit ni d’une page forcément introuvable, ni d’un serveur nécessairement en panne, mais d’un problème de format accepté, de langue, d’encodage ou de règle de traitement.
Sa résolution passe par une lecture méthodique des en-têtes, des logs et de la configuration technique. Pour un site web comme pour une API, l’enjeu est de trouver le bon équilibre entre précision des réponses, compatibilité des clients et sécurité. Bien traité, un 406 Not Acceptable devient moins une anomalie obscure qu’un signal utile pour améliorer la fiabilité du service.
