Les codes de statut HTTP expliqués : ceux qu'on confond vraiment

Le premier chiffre est la seule partie que certains clients lisent

La RFC 9110 exige d'un client qu'il comprenne la classe d'un code de statut même s'il ne reconnaît pas le code lui-même, et qu'il traite tout code inconnu comme le x00 de sa classe. Un client qui n'a jamais entendu parler du 451 le gère comme un 400 ; un 599 inconnu est géré comme un 500. C'est cette règle qui rend l'espace extensible, et elle signifie aussi que la classe porte presque tout le comportement : les caches en déduisent la conservation, les proxys les retentatives, les robots l'indexation — le plus souvent avant même d'analyser ton corps de réponse.

Conséquence pratique : renvoyer un 200 avec l'erreur décrite dans le corps place l'échec là où rien d'autre ne peut le voir. Ta sonde de disponibilité passe au vert, ton CDN met la page d'erreur en cache et un moteur de recherche l'indexe comme un vrai document. C'est le problème du soft 404 sous sa forme générale, et il mérite un audit, car la correction tient en une ligne — le code de statut — et non en une refonte.

Redirections : lesquelles conservent ton POST

La grille des quatre codes de redirection croise en réalité deux questions : permanent ou temporaire, et la méthode survit-elle. 301 et 308 sont permanents, 302 et 307 temporaires ; 307 et 308 sont les deux qui interdisent au client de modifier la requête. MDN est direct sur la raison d'être de la paire récente : le 301 exigeait déjà que la méthode et le corps restent inchangés, mais cette exigence était mal appliquée par les clients anciens, qui basculaient en GET. Impossible de corriger le parc installé : on a donc frappé deux nouveaux codes avec la garantie inscrite dans leur définition.

Le choix découle donc du trafic. Pour une page qui ne reçoit que des GET, le 301 convient et c'est ce à quoi les moteurs sont le plus habitués. Pour un chemin d'API, une cible de formulaire ou tout ce qui peut recevoir POST, PUT ou DELETE, utilise 308 et la requête arrive intacte. Une mise en garde sur la permanence : les navigateurs mettent un 301 en cache de façon agressive, parfois bien plus longtemps que prévu, si bien qu'un 301 émis pendant un test peut survivre au test sur des machines auxquelles tu n'as pas accès. Sers du 302 ou du 307 tant que rien n'est tranché.

Les erreurs le plus souvent mal renvoyées

401 et 403 forment la paire qui coûte le plus de temps au support. Le 401 signifie que la requête ne portait pas d'informations d'authentification valides, et MDN précise qu'il s'accompagne d'un en-tête WWW-Authenticate décrivant le schéma attendu par le serveur — c'est une invitation à réessayer avec des identifiants. Le 403 est la situation inverse : les identifiants sont parfaitement valides et le client n'a malgré tout pas la permission pour cette action. Renvoyer un 401 à un utilisateur connecté demande à son client de se réauthentifier, ce qui produira exactement le même refus, et lui laisse croire que sa connexion est cassée alors qu'elle ne l'est pas.

404 et 410 ne diffèrent que par le degré de certitude, et c'est tout l'enjeu. La recommandation de MDN est explicite : si l'exploitant du serveur ignore si la situation est temporaire ou définitive, il faut un 404. Le 410 s'emploie quand tu as retiré la chose exprès et qu'elle ne reviendra pas — il est cacheable par défaut et dit aux robots de cesser de demander. Le Retry-After, lui, est un en-tête qui porte soit un délai en secondes, soit une date HTTP ; sur un 503 il estime la durée d'indisponibilité du service, sur un 429 il indique combien de temps attendre avant une nouvelle requête. C'est une indication, pas un contrat, et MDN note que la prise en charge par les clients est inégale — mais Googlebot le respecte, ce qui suffit à justifier de le poser lors d'une maintenance planifiée.

Questions fréquentes

Une migration de site doit-elle utiliser 301 ou 308 ?

Pour les pages qui ne sont récupérées qu'en GET, le 301 est le choix sûr, celui que tous les robots et proxys traitent depuis des décennies. Prends le 308 pour tout ce qui peut recevoir un POST, un PUT ou un DELETE — points de formulaire, routes d'API, récepteurs de webhooks — car c'est là qu'un client rétrogradant la méthode en silence transforme une redirection en corps de requête perdu. Rien n'empêche d'utiliser les deux sur la même migration, route par route.

Que doit renvoyer une API quand la validation échoue ?

Emploie 400 Bad Request quand la requête elle-même est malformée et que le serveur ne peut pas l'analyser — JSON cassé, en-tête obligatoire manquant. Emploie 422 Unprocessable Content quand la syntaxe est correcte mais que le contenu enfreint tes règles, par exemple un corps bien formé dont la date de fin précède la date de début. Ce qu'il ne faut pas renvoyer, c'est un 500, qui impute au serveur une erreur du client et pollue ton budget d'erreurs, ni un 200 avec le problème décrit dans le corps, qui masque l'échec à toutes les couches situées entre toi et l'appelant.

Les 404 nuisent-elles au référencement ?

Un 404 est une réponse valide et honnête, et une part normale de tout site qui existe depuis un certain temps ; une page qui n'existe plus doit le dire. Le mal vient des substituts. Un soft 404 — une page avenante servie en statut 200 — maintient des URL mortes dans l'index et dépense du budget d'exploration pour rien. Rediriger en bloc toutes les pages manquantes vers l'accueil est la même erreur déguisée en 301. Si la suppression était délibérée et définitive, le 410 le dit clairement.