Codes statut HTTP : la liste utile et le diagnostic

Un code statut HTTP est le nombre à trois chiffres que le serveur place en tête de chaque réponse : 200 quand tout va bien, 404 quand la ressource n'existe pas, 503 quand le service est à genoux. Les cinq classes sont fixées par la RFC 9110, et le premier chiffre indique déjà où chercher, du côté de la requête pour un 4xx, du côté du serveur pour un 5xx.

Le premier chiffre dit presque tout

Trois chiffres, et vous savez déjà à qui parler.

Le serveur ouvre sa réponse par une ligne de statut du genre HTTP/1.1 404 Not Found. Le nombre compte, le texte qui suit ne compte pas : la phrase de raison est purement indicative et rien n'empêche un serveur d'écrire HTTP/1.1 404 Rien ici. En HTTP/2 et en HTTP/3 elle a d'ailleurs disparu, le statut voyage seul dans le pseudo en-tête :status, ce qui explique pourquoi les outils de développement des navigateurs n'affichent plus qu'un nombre nu sur la plupart des sites récents.

Les cinq classes sont définies par la RFC 9110, publiée en juin 2022, qui a remplacé la RFC 7231. La plage va de 100 à 599, sans exception.

Une règle sauve beaucoup de code client : quand un code inconnu arrive, la RFC 9110 demande de le traiter comme le code x00 de sa classe. Un 499 se gère donc comme un 400 et un 599 comme un 500. Votre parseur n'a jamais besoin d'une liste exhaustive.

Classe	Sens	Codes courants	Qui doit agir
1xx	Réponse provisoire	100, 101, 103	Personne, la réponse finale arrive ensuite
2xx	Succès	200, 201, 204, 206	Personne
3xx	Redirection	301, 302, 304, 307, 308	Le client, qui suit le lien ou réutilise son cache
4xx	La requête est fautive	400, 401, 403, 404, 429	Celui qui appelle
5xx	Le serveur est fautif	500, 502, 503, 504	L'hébergeur ou le développeur backend

Les codes que vous croiserez cette semaine

En production, la même quinzaine de codes revient en boucle.

Certains imposent un en-tête, et beaucoup d'implémentations l'oublient. Un 401 doit être accompagné d'un WWW-Authenticate décrivant le schéma d'authentification attendu (RFC 9110, section 15.5.2). Un 405 doit renvoyer un en-tête Allow listant les méthodes acceptées (section 15.5.6). Un 304 doit répéter les en-têtes de validation qu'une réponse 200 aurait portés, ETag en tête, sinon le cache du client se désynchronise au rafraîchissement suivant.

204 et 304 n'ont pas de corps. Pas un octet, sous peine de voir certains proxys couper la connexion.

Code	Nom	Ce qu'il faut faire
204	No Content	Succès sans contenu, typique d'un DELETE ou d'un PUT d'API
206	Partial Content	Réponse à un en-tête Range, utilisé par les lecteurs vidéo et les reprises de téléchargement
301	Moved Permanently	Mettre à jour le lien, la cible devient l'adresse de référence
304	Not Modified	Rien à retélécharger, la copie en cache reste valable
400	Bad Request	Corriger la requête, souvent un JSON malformé ou un en-tête trop long
401	Unauthorized	Fournir des identifiants, la réponse doit contenir WWW-Authenticate
403	Forbidden	Vérifier les droits, les règles du pare-feu applicatif, les permissions de fichiers
404	Not Found	Vérifier l'URL et les règles de réécriture
410	Gone	La ressource a été supprimée volontairement et ne reviendra pas
429	Too Many Requests	Ralentir, et respecter la valeur de Retry-After
500	Internal Server Error	Lire les logs applicatifs, l'erreur est dans le code
502	Bad Gateway	Le reverse proxy n'a pas obtenu de réponse exploitable de l'origine
503	Service Unavailable	Surcharge ou maintenance, Retry-After indique quand revenir
504	Gateway Timeout	L'origine a répondu trop tard, regarder proxy_read_timeout

Quatre confusions qui font perdre des heures

401 contre 403. Le 401 signifie « je ne sais pas qui vous êtes », le 403 signifie « je le sais et c'est non ». Un jeton absent ou expiré donne un 401 ; un jeton valide sur une ressource interdite donne un 403. Beaucoup d'API renvoient un 403 alors que l'utilisateur n'a jamais été authentifié, ce qui envoie le client réessayer au lieu de le pousser vers la page de connexion.

301, 302, 307, 308. Les deux premiers datent d'une époque où les navigateurs transformaient un POST redirigé en GET, comportement que la norme tolère encore. Les deux derniers conservent la méthode et le corps. Le cas de panne classique : un formulaire de paiement envoyé en POST sur http, redirigé en 302 vers la version https, arrive en GET avec un corps vide et le panier disparaît. Un 308 réglait le problème.

404 contre 410. Le premier dit « pas trouvé », le second dit « supprimé pour de bon ». Utilisez 410 pour une annonce expirée ou une fiche produit retirée du catalogue.

Le pire des quatre reste le 200 menteur : une API qui répond HTTP/1.1 200 OK avec {"error":"user not found"} dans le corps. Les sondes de supervision voient un 200, ne sonnent jamais, et la panne dure jusqu'au premier appel d'un client. Un code de statut se choisit en fonction du résultat réel du traitement, pas de la capacité du serveur à produire une réponse.

Les codes qui ne viennent pas de la norme

Certains nombres n'existent que chez un éditeur. Ils sont pourtant les plus utiles au diagnostic, parce qu'ils désignent le maillon cassé.

Cloudflare occupe la plage 520 à 527 plus le 530. Le plus parlant est le 524 : la connexion vers l'origine a bien été établie, mais aucune réponse complète n'est arrivée dans les 100 secondes accordées par défaut. Ce n'est donc pas Cloudflare qui tombe, c'est votre serveur qui traîne.

nginx, lui, écrit 499 dans ses logs quand le client a fermé la connexion avant la réponse. Ce code ne part jamais sur le réseau, il n'existe que dans access.log. Une salve de 499 signale en général des visiteurs qui abandonnent, ou un équilibreur de charge dont le délai est plus court que celui de votre application.

IIS ajoute des sous-codes visibles dans ses journaux : 404.13 ne veut pas dire « page absente » mais « corps de requête trop volumineux », le seuil par défaut de maxAllowedContentLength étant de 30 000 000 octets. Les envois de fichiers échouent là, silencieusement, avec un 404 qui envoie l'administrateur chercher au mauvais endroit.

Quant au 418 I'm a teapot, il vient du protocole de café HTCPCP publié le 1er avril 1998 dans la RFC 2324. La RFC 9110 le laisse réservé pour empêcher toute réattribution.

Code Cloudflare	Cause réelle
520	Réponse vide ou non conforme renvoyée par l'origine
521	L'origine refuse la connexion, souvent un pare-feu qui bloque les IP de Cloudflare
522	La connexion TCP vers l'origine n'aboutit pas
523	Origine injoignable, en général un enregistrement DNS erroné
524	Connexion ouverte, aucune réponse complète dans les 100 secondes
525	Échec de la poignée de main TLS avec l'origine
526	Certificat de l'origine expiré, auto-signé ou non valide

Vérifier un code en ligne de commande

Trois commandes suffisent la plupart du temps.

Pour obtenir le code seul, sans le corps : curl -sS -o /dev/null -w '%{http_code}\n' https://exemple.fr. Pour dérouler une chaîne de redirection avec l'adresse finale : curl -sS -L -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' https://exemple.fr. Un piège récurrent : curl -I envoie une requête HEAD, et certaines applications répondent différemment à HEAD et à GET, parfois par un 405. Quand le résultat surprend, refaites le test en GET avec l'option -D - pour afficher les en-têtes.

Côté serveur, le code se lit dans le journal d'accès. Avec le format combined de nginx, la variable $status est le champ qui suit immédiatement la requête entre guillemets, ce qui rend le repérage des erreurs serveur trivial : grep ' 50[0-9] ' /var/log/nginx/access.log | tail -50.

Sur les redirections, la documentation Google Search Central indique que Googlebot suit jusqu'à dix sauts par exploration. Enchaîner cinq 301 pour arriver à la bonne page reste donc lisible pour un moteur, mais chaque saut ajoute un aller-retour réseau pour un visiteur mobile. Aplatissez la chaîne à un seul saut quand vous en avez la main.

Dernier réflexe : une valeur de Retry-After se lit soit en secondes (Retry-After: 120), soit sous forme de date HTTP absolue. Un client qui ignore cet en-tête sur un 429 se fait bloquer plus longtemps, parfois définitivement.

• -o /dev/null : jette le corps, garde les métadonnées
• -w '%{http_code}' : affiche le code final après redirections
• -D - : imprime tous les en-têtes de réponse sur la sortie standard
• -L : suit les redirections, à combiner avec %{num_redirects}
• --resolve exemple.fr:443:203.0.113.10 : teste une origine précise sans toucher au DNS

Testez vos connaissances

Questions fréquentes

Quelle différence entre une erreur 401 et une erreur 403 ?

Le 401 indique une authentification manquante ou invalide et doit être accompagné d'un en-tête WWW-Authenticate précisant le schéma attendu. Le 403 indique que l'identité est connue mais que l'accès est refusé : mauvais rôle, quota dépassé, règle de pare-feu applicatif. Réessayer avec les mêmes identifiants n'a de sens que dans le premier cas.

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

La documentation Google Search Central présente les 404 comme un phénomène normal du web, qui n'entraîne pas de pénalité sur le reste du site. Ce qui coûte, c'est autre chose : des liens internes cassés qui gaspillent le budget d'exploration, et des pages autrefois positionnées qui disparaissent sans redirection vers un équivalent. Redirigez quand un équivalent existe, laissez le 404 ou le 410 sinon.

Pourquoi mon site renvoie-t-il un 502 par intermittence ?

Un 502 vient du reverse proxy, pas de l'application : il a joint l'origine mais n'a pas obtenu de réponse exploitable. Sur une pile nginx et PHP-FPM, la cause la plus fréquente est un pool de processus saturé, avec dans error.log une ligne du type connect() to unix:/run/php-fpm.sock failed (11: Resource temporarily unavailable). Regardez pm.max_children et le nombre de requêtes simultanées avant de toucher au reste.

Faut-il choisir 301 ou 308 pour une redirection permanente ?

Pour des pages consultées en GET, 301 suffit et reste le mieux compris par les moteurs de recherche. Pour une API ou tout point d'entrée appelé en POST, PUT ou DELETE, préférez 308 : il garantit que la méthode et le corps sont conservés, là où un 301 autorise le client à basculer en GET.

Que signifie une erreur 522 sur Cloudflare ?

La connexion TCP entre Cloudflare et votre serveur d'origine n'a pas pu s'établir. Trois causes couvrent presque tous les cas : le serveur d'origine est arrêté, un pare-feu bloque les plages d'adresses de Cloudflare, ou l'origine est saturée au point de ne plus accepter de nouvelles connexions. Testez l'origine directement avec curl --resolve pour trancher.

À lire aussi

api · cache · cdn · agent utilisateur