Guide
La référence des codes de statut HTTP recense 72 codes : tous les codes standard définis par la RFC 9110 (100–101, 200–206, 300–308, 400–418, 421, 422, 426, 500–505), les codes étendus définis par les RFC 6585 / 7725 / 8297 / 8470 et la série WebDAV (103, 207, 208, 226, 423–425, 428, 429, 431, 451, 506–511), ainsi que les codes non standard absents de toute RFC mais croisés tous les jours en production — les 444 et 499 de nginx, les 520–526 de Cloudflare.
Mis à jour le 2026-09-094 sources10 min read
La référence des codes de statut HTTP recense 72 codes : tous les codes standard définis par la RFC 9110 (100–101, 200–206, 300–308, 400–418, 421, 422, 426, 500–505), les codes étendus définis par les RFC 6585 / 7725 / 8297 / 8470 et la série WebDAV (103, 207, 208, 226, 423–425, 428, 429, 431, 451, 506–511), ainsi que les codes non standard absents de toute RFC mais croisés tous les jours en production — les 444 et 499 de nginx, les 520–526 de Cloudflare.
Contrairement aux tableaux qui se limitent au « sens », chaque code est décrit en quatre volets : sa sémantique ; dans quels cas vous le verrez ; ce que le front-end / client doit faire en le recevant (réessayer ? rediriger vers la connexion ? lire quel en-tête de réponse ?) ; et quand le back-end doit le renvoyer, avec quels en-têtes. Les codes fréquents ont en plus un volet « erreurs fréquentes », car la plupart des problèmes de codes en production ne viennent pas d'une méconnaissance mais d'un mauvais usage — un échec métier renvoyé en 200, un utilisateur non connecté renvoyé en 403, une limitation de débit renvoyée en 503.
En haut de page figurent aussi sept comparaisons de codes faciles à confondre : 401 vs 403, 301/302/307/308, 400 vs 422, 404 vs 410, 502/503/504, 200/201/202/204, 429 vs 503. Ce sont les duos les plus demandés en entretien, en revue de code et en dépannage.
502) ; la fiche correspondant exactement s'affiche en tête.Contenu de la fiche obtenue en cherchant « 429 » (extrait) :
La réponse back-end correspondante ressemble à ceci :
429 Too Many Requests trop de requêtes RFC 6585
Sens trop de requêtes envoyées dans un laps de temps donné (limitation de débit).
Quand limitation de fréquence d'une API, trop de tentatives de connexion, crawler ralenti, quota par minute d'une API d'IA dépassé.
Front lire l'en-tête Retry-After (secondes ou date) puis réessayer avec un backoff exponentiel ; afficher « réessayez plus tard » ; ne pas réessayer immédiatement.
Back renvoyer Retry-After et les en-têtes RateLimit-* ; compter par utilisateur / IP / clé d'API.
Erreurs renvoyer 403 ou 503 pour une limitation : le client ne peut pas distinguer un problème de droits d'une attente à respecter.HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30
RateLimit-Limit: 60
RateLimit-Remaining: 0
RateLimit-Reset: 30
{"error":"rate_limited","message":"60 requêtes maximum par minute, réessayez dans 30 secondes"}Le premier chiffre du code détermine sa classe, et c'est volontaire : même si le client ne connaît pas un code précis (par exemple le récent 425), il peut le traiter correctement par classe — 4xx « ne réessayez pas tel quel, le problème vient de la requête », 5xx « une nouvelle tentative est possible plus tard », 3xx « regardez Location ». La RFC 9110 exige explicitement que le client comprenne la sémantique des classes, et non qu'il connaisse chaque code. C'est aussi pourquoi un code de statut personnalisé doit tomber dans la bonne centaine.
Une erreur de nommage historique. Aux débuts de HTTP, authentication (qui vous êtes) et authorization (ce que vous pouvez faire) n'étaient pas distingués ; 401 a été nommé Unauthorized, mais l'en-tête WWW-Authenticate qui l'accompagne et la sémantique « une nouvelle tentative avec des identifiants peut réussir » parlent bien d'authentification. La RFC 9110, au §15.5.2, écrit désormais « lacks valid authentication credentials ». Retenez une phrase : 401 = connectez-vous, 403 = même connecté, c'est non. Le front-end en déduit s'il faut rediriger vers la page de connexion ou afficher « accès refusé » ; inversé, on obtient des utilisateurs connectés sans cesse renvoyés vers la connexion.
Les quatre codes de redirection courants forment une matrice 2×2. 301 et 308 sont permanents (navigateurs et moteurs de recherche retiennent la nouvelle adresse), 302 et 307 sont temporaires. Historiquement, les navigateurs transformaient un POST en GET sur les 301/302 ; la RFC 9110 entérine cette réalité et fournit avec 307/308 une version stricte qui « doit conserver la méthode et le corps de la requête ». Pour basculer un site en https, un 301 convient ; pour migrer un endpoint d'API, une requête POST exige 307/308, faute de quoi le corps est perdu.
Le 304 est souvent pris pour « une requête économisée ». En réalité, le navigateur a bien envoyé au serveur une requête conditionnelle avec If-None-Match / If-Modified-Since ; le serveur compare et répond 304 sans corps : ce qui est économisé, c'est le transfert, pas l'aller-retour. Économiser réellement des requêtes repose sur Cache-Control: max-age (pendant la durée de validité, le navigateur ne demande rien du tout) ; les deux se combinent : on utilise directement la ressource pendant max-age, puis une requête conditionnelle permet d'obtenir un 304 qui prolonge la validité. Dans les DevTools, "200 (from disk cache)" correspond au premier cas, "304" au second.
La combinaison 5xx la plus fréquente en production, et savoir les distinguer réduit directement le périmètre d'investigation. Un reverse proxy (Nginx, passerelle, CDN) n'atteint pas l'amont, ou l'amont renvoie quelque chose d'invalide : 502 — allez voir si le processus applicatif est tombé. L'amont signale explicitement être occupé ou en maintenance : 503, généralement renvoyé volontairement — regardez les health checks et le disjoncteur. L'amont tarde à répondre : 504 — regardez les requêtes lentes et la configuration des délais. Cloudflare découpe ces trois cas en 520–526 : 521 ≈ 502 (connexion refusée), 522/524 ≈ 504 (délai de connexion ou de lecture), 525/526 relevant de la couche TLS.
L'antipattern le plus courant consiste à renvoyer 200 à toutes les requêtes et à placer l'erreur dans un champ code du corps. Résultat : le CDN met en cache les pages d'erreur, les alertes 5xx de la supervision ne fonctionnent plus, fetch().ok du navigateur perd son sens et aucune politique de nouvelle tentative n'est possible. La bonne approche : le code HTTP exprime « ce qui s'est passé au niveau de la requête » (sémantique de la RFC 9110), le code métier du corps exprime « le détail métier » — les deux se répartissent le travail au lieu de se remplacer. Un stock insuffisant, c'est 422 + {"code":"OUT_OF_STOCK"}, pas 200 + {"code":500}.
La comparaison 502 / 503 / 504 indique si l'application est tombée, retirée du trafic ou trop lente ; les fiches Cloudflare 52x donnent directement la piste « pare-feu d'origine / certificat / délai ».
Écrivez vos intercepteurs d'après le volet « front / client » : 401 rafraîchit le token ou redirige vers la connexion, 403 signale un manque de droits, 429 lit Retry-After pour temporiser, les 5xx se retentent un nombre limité de fois et remontent l'erreur.
La création d'une ressource renvoie-t-elle bien 201 + Location ? La suppression, 204 ? Une validation métier échouée, 400 ou 422 ? La limitation de débit s'accompagne-t-elle de Retry-After ? Les volets « back-end » et « erreurs fréquentes » forment la liste de contrôle de la revue.
Les sept comparaisons couvrent les questions de « différence » les plus courantes ; la section Fonctionnement explique le nommage de 401, l'apparition des 307/308 et le vrai rôle du 304.
Le serveur d'entrée du site (la passerelle) n'arrive pas à joindre le back-end qui traite réellement la requête ; c'est souvent un processus back-end planté ou en redémarrage. Côté utilisateur, il ne reste qu'à actualiser plus tard ; s'il s'agit de votre propre site, examinez le processus back-end et les journaux d'erreur de la passerelle.
Client : lisez l'en-tête Retry-After, attendez le délai avant de réessayer, et en cas d'échecs répétés, recourez à un backoff exponentiel (1 s, 2 s, 4 s…) en informant l'utilisateur que les actions sont trop fréquentes. Serveur : accompagnez toujours le 429 d'un Retry-After et, idéalement, des en-têtes RateLimit-* pour que le client lève le pied à l'avance.
Cela dépend de l'objet demandé. GET /users/123 alors que 123 n'existe pas : 404 ; GET /users?name=xxx sans résultat : 200 + tableau vide. Un résultat vide sur une liste est un cas légitime — « il y a un résultat, et il est vide » —, pas une erreur.
Un 204 n'a pas de corps de réponse : json() sur une chaîne vide lève une SyntaxError. Testez d'abord response.status === 204 (ou response.headers.get('content-length') === '0') avant de décider d'analyser ou non.
Ce sont des codes internes que nginx écrit dans ses journaux d'accès : 444 signifie que nginx a fermé la connexion sans aucune réponse, 499 que le client a coupé avant que nginx ne réponde. Côté navigateur, on voit « connexion réinitialisée » ou aucune réponse du tout.
Les données de codes sont téléchargées avec la page ; la recherche, le filtrage, la copie et les favoris se font localement dans le navigateur, sans aucune requête. Les favoris sont conservés dans le localStorage de la machine. Les liens externes pointent vers le RFC Editor, l'IANA et la documentation Cloudflare ; une fois cliqués, ils relèvent du site de destination.
Mis à jour le 2026-09-09
Les 72 codes de RFC 9110, leurs extensions et les codes non standard de nginx/Cloudflare, chacun avec sa signification, ses cas d’usage, le traitement côté front et back et les erreurs fréquentes ; 7 comparaisons de codes faciles à confondre ; recherche, copie et favoris
Cet outil n’est pas entièrement traduit ; certains contenus utilisent la langue source ou une langue de repli.
La requête a été reçue et le traitement continue ; les navigateurs n'exposent presque jamais ces codes aux scripts de la page.
Les en-têtes de la requête ont été reçus ; le client peut continuer à envoyer le corps.
RFC 9110 §15.2.1
Le serveur accepte de changer de protocole via l'en-tête Upgrade.
RFC 9110 §15.2.2
Le serveur a reçu la requête et la traite, mais aucune réponse finale n'est encore prête.
RFC 2518 (WebDAV, obsolète)
Quelques en-têtes sont envoyés avant la réponse finale — surtout Link: preload — pour que le navigateur charge plus tôt certaines ressources.
RFC 8297
La requête a été reçue, comprise et traitée avec succès.
La requête a réussi ; le corps contient la ressource demandée ou le résultat de l'opération.
RFC 9110 §15.3.1
La requête a réussi et une nouvelle ressource a été créée.
RFC 9110 §15.3.2
La requête a été acceptée mais pas encore traitée — le reçu d'une tâche asynchrone.
RFC 9110 §15.3.3
La réponse a réussi, mais son contenu a été modifié par un proxy intermédiaire.
RFC 9110 §15.3.4
Succès, mais sans corps de réponse.
RFC 9110 §15.3.5
Succès, et le client doit réinitialiser la vue du document (par exemple vider un formulaire).
RFC 9110 §15.3.6
Seule une partie de la ressource est renvoyée (requête Range réussie).
RFC 9110 §15.3.7
Le corps est du XML et chaque sous-ressource indique son propre statut.
RFC 4918 (WebDAV)
Dans une réponse 207, la même ressource a déjà été signalée plus haut et n'est pas répétée.
RFC 5842 (WebDAV)
Le serveur a appliqué des manipulations d'instance (encodage delta) à l'instance courante et renvoyé la différence.
RFC 3229
Le client doit effectuer une action supplémentaire — généralement demander une autre adresse — avant que la requête aboutisse.
La ressource a plusieurs représentations ; le client doit en choisir une.
RFC 9110 §15.4.1
La ressource a définitivement déménagé vers la nouvelle URL indiquée dans Location ; utiliser cette URL désormais.
RFC 9110 §15.4.2
La ressource est temporairement ailleurs ; redemander l'URL d'origine la prochaine fois.
RFC 9110 §15.4.3
Récupérer le résultat depuis Location avec GET, quelle que soit la méthode de cette requête.
RFC 9110 §15.4.4
La ressource n'a pas changé — utiliser la copie du cache.
RFC 9110 §15.4.5
La ressource doit être accessible via le proxy indiqué dans Location.
RFC 9110 §15.4.6 (obsolète)
Devait indiquer un changement de proxy dans un brouillon ; le code est réservé et inutilisé.
RFC 9110 §15.4.7
Redirection temporaire, et le client doit renvoyer la requête avec la même méthode et le même corps.
RFC 9110 §15.4.8
Redirection permanente qui conserve aussi la méthode et le corps (la version stricte du 301).
RFC 9110 §15.4.9
La requête elle-même pose problème : syntaxe, authentification, ressource absente, fréquence excessive… réessayer à l'identique ne fonctionnera pas.
Le serveur ne comprend pas la requête : syntaxe erronée, paramètres manquants ou mal formés, ou JSON impossible à analyser.
RFC 9110 §15.5.1
Les identifiants sont absents ou invalides — « qui êtes-vous ? » (le nom Unauthorized signifie en réalité non authentifié).
RFC 9110 §15.5.2
Réservé aux futurs paiements numériques ; la spécification ne définit aucune sémantique précise.
RFC 9110 §15.5.3 (réservé)
Le serveur sait qui vous êtes, mais vous n'avez pas la permission — « vous ne pouvez pas ». Se réauthentifier n'y changera rien.
RFC 9110 §15.5.4
Le serveur ne trouve pas la ressource demandée et ne précise pas si c'est temporaire ou définitif.
RFC 9110 §15.5.5
La ressource existe mais ne prend pas en charge cette méthode HTTP.
RFC 9110 §15.5.6
Le serveur n'a aucune représentation satisfaisant Accept / Accept-Language.
RFC 9110 §15.5.7
Il faut d'abord s'authentifier auprès du serveur proxy (la version proxy du 401).
RFC 9110 §15.5.8
Le serveur a attendu trop longtemps la requête (le client n'a jamais fini de l'envoyer).
RFC 9110 §15.5.9
La requête entre en conflit avec l'état actuel de la ressource ; l'utilisateur peut le résoudre en modifiant la requête.
RFC 9110 §15.5.10
La ressource a existé puis a été définitivement supprimée, sans adresse de redirection.
RFC 9110 §15.5.11
Le serveur exige que la requête porte Content-Length.
RFC 9110 §15.5.12
Une condition des en-têtes de requête (If-Match, If-Unmodified-Since) n'est pas satisfaite.
RFC 9110 §15.5.13
Le corps de la requête dépasse la taille autorisée par le serveur.
RFC 9110 §15.5.14 (anciennement Payload Too Large)
L'URL est trop longue pour que le serveur la traite.
RFC 9110 §15.5.15
Le serveur ne prend pas en charge le format (Content-Type) du corps de la requête.
RFC 9110 §15.5.16
L'intervalle d'octets demandé dans l'en-tête Range dépasse la taille de la ressource.
RFC 9110 §15.5.17
Le serveur ne peut pas satisfaire l'en-tête Expect.
RFC 9110 §15.5.18
Blague d'un RFC du 1er avril 1998 ; à ne pas utiliser en HTTP réel.
RFC 2324 (RFC poisson d'avril) ; marqué inutilisé par la RFC 9110
La requête a atteint un serveur qui ne peut pas répondre pour cette autorité (domaine).
RFC 9110 §15.5.20
La syntaxe et le format sont corrects, mais la requête est sémantiquement intraitable (échec de validation métier).
RFC 9110 §15.5.21 (anciennement Unprocessable Entity)
La ressource est verrouillée.
RFC 4918 (WebDAV)
Cette opération a échoué parce qu'une opération dépendante a échoué avant.
RFC 4918 (WebDAV)
Le serveur refuse de traiter une requête susceptible d'être rejouée (données précoces TLS 1.3 0-RTT).
RFC 8470
Le serveur refuse de traiter la requête sur le protocole actuel et demande de passer à celui indiqué dans Upgrade.
RFC 9110 §15.5.22
Le serveur exige un en-tête conditionnel (comme If-Match) pour éviter les mises à jour perdues.
RFC 6585
Trop de requêtes ont été envoyées dans une fenêtre de temps donnée (limitation de débit).
RFC 6585
Un en-tête de requête (un champ ou le total) est trop grand.
RFC 6585
La ressource est retenue pour des raisons légales (droit d'auteur, injonctions). Le numéro rend hommage au roman Fahrenheit 451.
RFC 7725
Le serveur sait qu'il a échoué ou ne peut pas satisfaire une requête valide ; un nouvel essai plus tard peut réussir.
Le serveur a rencontré une condition inattendue et n'a pas pu terminer la requête.
RFC 9110 §15.6.1
Le serveur ne prend pas en charge la fonctionnalité nécessaire à la requête (souvent une méthode inconnue).
RFC 9110 §15.6.2
Un serveur agissant comme passerelle ou proxy a reçu une réponse invalide de son amont.
RFC 9110 §15.6.3
Le serveur ne peut temporairement pas traiter la requête (surcharge ou maintenance), en général pour un moment seulement.
RFC 9110 §15.6.4
La passerelle/le proxy a expiré en attendant une réponse de l'amont.
RFC 9110 §15.6.5
Le serveur ne prend pas en charge la version majeure de HTTP utilisée par la requête.
RFC 9110 §15.6.6
Une mauvaise configuration de négociation de contenu crée une boucle.
RFC 2295
Le serveur ne peut pas stocker le contenu nécessaire à la requête.
RFC 4918 (WebDAV)
Une boucle infinie a été détectée pendant le traitement de la requête.
RFC 5842 (WebDAV)
La requête doit d'abord être étendue davantage pour que le serveur puisse la traiter.
RFC 2774 (historique)
Le client doit d'abord s'authentifier au niveau réseau (portail captif) avant d'accéder à Internet.
RFC 6585
Absents de toute RFC, ils n’apparaissent que dans les journaux de certains serveurs ou les pages d’erreur des CDN ; les connaître fait gagner beaucoup de temps de diagnostic.
nginx ferme la connexion sans envoyer de réponse ; visible uniquement dans les journaux nginx.
spécifique à nginx
Le client s'est déconnecté avant que le serveur ne réponde ; visible uniquement dans les journaux nginx.
spécifique à nginx
La réponse de l'origine à Cloudflare était vide, mal formée ou ses en-têtes trop volumineux.
spécifique à Cloudflare
Cloudflare n'arrive pas à joindre l'origine (connexion TCP refusée).
spécifique à Cloudflare
La connexion TCP de Cloudflare vers l'origine a expiré.
spécifique à Cloudflare
Cloudflare ne peut pas router vers l'origine (problème de DNS ou de routage réseau).
spécifique à Cloudflare
TCP était connecté, mais l'origine n'a pas renvoyé de réponse HTTP en 100 secondes.
spécifique à Cloudflare
La poignée de main TLS entre Cloudflare et l'origine a échoué.
spécifique à Cloudflare
En mode Full (strict), le certificat d'origine est expiré, auto-signé ou ne correspond pas au domaine.
spécifique à Cloudflare