Consultation des Codes de Statut HTTP
Référence rapide des codes de statut HTTP avec descriptions
1xx Information(4)
Le client doit continuer à envoyer le reste de la requête.
Le serveur comprend et va basculer vers un protocole différent.
Le serveur a reçu la requête et la traite.
Retourne certains headers avant la réponse finale pour préchargement.
2xx Succès(10)
Requête réussie. La réponse contient les données demandées.
Requête réussie et une nouvelle ressource créée. Courant pour POST.
Requête acceptée pour traitement, mais pas encore complétée.
Requête réussie, mais l'information peut venir d'une tierce partie.
Requête réussie, mais pas de contenu dans la réponse. Courant pour DELETE.
Requête réussie, le client devrait réinitialiser la vue du document.
Le serveur a livré un contenu partiel. Utilisé pour reprendre téléchargements.
Multiples codes de statut dans la réponse (WebDAV).
Les bindings DAV déjà listés dans une réponse précédente (WebDAV).
Le serveur a complété la requête GET utilisant une manipulation d'instance.
3xx Redirection(8)
Multiples représentations disponibles, le client devrait choisir une.
Ressource définitivement déplacée à une nouvelle URL. Utilisez la nouvelle URL.
Ressource temporairement à une autre URL.
Utilisez GET pour récupérer la ressource depuis une autre URL.
Ressource non modifiée. Utilisez la version en cache.
Utilisez le proxy spécifié (déprécié).
Redirection temporaire avec la même méthode et corps.
Redirection permanente avec la même méthode.
4xx Erreur client(29)
Le serveur ne peut comprendre le format de la requête.
Authentification requise.
Réservé pour usage futur. Courant pour contenu paywall.
Le serveur comprend mais refuse d'autoriser.
La ressource n'existe pas. Code de statut le plus courant.
La méthode de requête n'est pas supportée.
Ne peut retourner un contenu correspondant au header Accept.
Le client doit d'abord s'authentifier avec le proxy.
Le serveur a expiré en attendant la requête.
La requête est en conflit avec l'état du serveur. Courant pour PUT.
Ressource définitivement supprimée.
La requête doit inclure le header Content-Length.
Les conditions dans les headers de requête ne sont pas satisfaites.
Corps de requête trop grand.
URL de requête trop longue.
Format du corps de requête non supporté.
La plage demandée est invalide.
Les exigences du header Expect ne sont pas satisfaites.
Easter egg RFC 2324. Le serveur refuse de faire du café.
Requête envoyée au mauvais serveur.
Requête bien formée mais erreurs sémantiques.
Ressource verrouillée (WebDAV).
Requête échouée due à un échec précédent (WebDAV).
Le serveur refuse de traiter une requête potentiellement rejouée.
Le client devrait basculer vers TLS.
La requête nécessite des headers conditionnels.
Limite de taux dépassée. Ralentissez.
Headers de requête trop grands.
Ressource indisponible pour raisons légales.
5xx Erreur serveur(11)
Le serveur a rencontré une condition inattendue.
Le serveur ne supporte pas la fonctionnalité requise.
Le serveur a reçu une réponse invalide de l'upstream.
Le serveur temporairement incapable de traiter la requête.
Le serveur a expiré en attendant une réponse upstream.
Version HTTP non supportée.
Erreur de configuration de négociation de contenu.
Le serveur ne peut stocker la ressource (WebDAV).
Boucle infinie détectée (WebDAV).
Extensions supplémentaires requises.
Authentification réseau requise.
Qu'est-ce que les codes de statut HTTP ?
L’outil des codes de statut HTTP explique les réponses renvoyées par un serveur à un navigateur, un robot, une application ou un client API après une requête. Les codes 2xx indiquent généralement une réussite, les 3xx une redirection, les 4xx un problème côté client et les 5xx une erreur côté serveur, mais les différences sont importantes. Un 401 n’est pas un 403, un 404 n’a pas le même sens qu’un 410, et un 301 n’a pas les mêmes effets SEO qu’un 302. Cette référence aide à comprendre rapidement un code et à choisir la prochaine vérification technique.
Comment utiliser
Référence rapide
- Cliquez sur n'importe quelle fiche de code de statut pour la copier
- Utilisez le champ de recherche pour trouver rapidement un code précis
- Cliquez sur les étiquettes de catégorie pour filtrer par type de statut
- Survolez les codes pour afficher des descriptions détaillées
Notes de débogage
- Commencez par lire la famille du statut : 2xx succès, 3xx redirection, 4xx erreur client, 5xx erreur serveur.
- Pour le débogage d'API, analysez le code de statut avec le corps de la réponse, les en-têtes, la méthode de requête et les journaux serveur : le code seul explique rarement tout le problème.
Cas d’utilisation
Principe technique
Les codes de statut HTTP sont des entiers à 3 chiffres renvoyés sur la ligne de début de réponse, définis par la spécification de sémantique HTTP. La référence normative actuelle est le RFC 9110 (HTTP Semantics, juin 2022), qui obsolète la série RFC 7231 précédente, avec des extensions dans le RFC 9111 (Caching), le RFC 9112 (HTTP/1.1), le RFC 9113 (HTTP/2) et le RFC 9114 (HTTP/3). Le premier chiffre définit la classe de réponse pour que les codes non reconnus aient un traitement prévisible : 1xx informationnel (intérimaire, la réponse finale suit), 2xx succès, 3xx redirection (une action supplémentaire de l'agent utilisateur est requise), 4xx erreur client (la requête est malformée ou ne peut être satisfaite) et 5xx erreur serveur. Les caches et intermédiaires doivent traiter les codes inconnus comme le code de classe générique x00 (par ex. un 4xx inconnu est traité comme 400), ce qui rend la famille de statut significative même pour les codes propriétaires ou d'extension. Les codes de redirection portent une sémantique de préservation de méthode qui a historiquement divergé de l'intention. Le RFC 9110 section 15.4 rend la distinction explicite : 301 Moved Permanently et 302 Found peuvent réécrire un POST en GET (le comportement de facto sur lequel tous les navigateurs se sont mis d'accord à la fin des années 1990, codifié dans le RFC 7231) ; 307 Temporary Redirect et 308 Permanent Redirect exigent que l'agent utilisateur répète la même méthode et le même corps. Les outils SEO transfèrent généralement le poids équivalent au PageRank sur les 301 et 308 et traitent les 302/307 comme préservant le signal de l'URL originale. Les codes conditionnels 304 Not Modified et 412 Precondition Failed dépendent des en-têtes If-None-Match / If-Modified-Since / ETag / Last-Modified de la requête, et 206 Partial Content répond à un en-tête Range avec un en-tête Content-Range et un corps multipart/byteranges lorsque plusieurs plages sont demandées. Les classes 4xx et 5xx portent des détails de contrat dans les en-têtes. 401 Unauthorized doit inclure un défi WWW-Authenticate listant les schémas acceptés (Bearer, Basic, Digest, Negotiate) ; sans cela, la réponse est techniquement malformée. 405 Method Not Allowed doit inclure un en-tête Allow listant les méthodes supportées. 429 Too Many Requests, 503 Service Unavailable et 301/307/308 avec Retry-After permettent au serveur de signaler un délai soit en secondes (Retry-After: 120), soit en date HTTP (Retry-After: Wed, 21 Oct 2025 07:28:00 GMT) selon le RFC 9110 section 10.2.3. Le RFC 9110 déprécie 305 Use Proxy et 306 (réservé/inutilisé), conserve 418 I'm a teapot comme le code humoristique documenté du RFC 2324 / RFC 7168, et réorganise les 1xx pour que seuls 100 Continue et 101 Switching Protocols soient obligatoires à la couche HTTP/1.1 ; 102 Processing et 103 Early Hints (RFC 8297) sont des extensions optionnelles principalement exposées via la logique de bord CDN.
- Référence normative : RFC 9110 (HTTP Semantics, juin 2022) obsolète les RFC 7230-7235 ; les extensions se trouvent dans les RFC 9111 (Caching), 9112 (format HTTP/1.1), 9113 (HTTP/2), 9114 (HTTP/3).
- Codes inconnus dégradés vers le code de classe (x00) : un 4xx inconnu est mis en cache et rendu comme 400, un 5xx inconnu comme 500 — c'est ce qui fait du premier chiffre un contrat.
- Préservation de méthode : 301/302 autorisent historiquement la réécriture POST → GET (codifiée après la divergence des navigateurs du début des années 1990) ; 307/308 exigent que la même méthode et le même corps soient rejoués — utiliser 308 pour les déplacements permanents de points de terminaison API.
- 401 Unauthorized doit porter WWW-Authenticate ; 405 Method Not Allowed doit porter Allow ; l'absence de ces en-têtes est une violation de la spécification qui perturbe les clients HTTP bien conçus.
- Retry-After (RFC 9110 section 10.2.3) sur 429/503/301/307/308 : accepte soit des delta-seconds (Retry-After: 120), soit une date HTTP (Retry-After: Wed, 21 Oct 2025 07:28:00 GMT) — les clients doivent parser les deux formes.
- Mise en cache conditionnelle : 304 Not Modified répond aux correspondances If-None-Match / If-Modified-Since sans corps ; 206 Partial Content répond au Range avec Content-Range et soit le corps partiel, soit un document multipart/byteranges.
- Le RFC 9110 déprécie 305 Use Proxy et 306 (réservé), préserve 418 I'm a teapot du RFC 2324 / RFC 7168 comme code humoristique, et traite 102 Processing / 103 Early Hints (RFC 8297) comme des extensions 1xx optionnelles que de nombreux proxys suppriment.
Exemples
Succès 2xx - 200 OK et 204 No Content
200 OK GET /api/users -> corps de réponse retourné
201 Created POST /api/posts -> nouvelle ressource à l'en-tête Location
204 No Content DELETE /api/posts/42 -> succès, corps vide
206 Partial Requête Range pour le streaming vidéo ou les téléchargements reprenables
RFC : RFC 7231 section 6.3 définit les codes de statut de succès 2xxRedirections 3xx - 301 vs 302 vs 304
301 Moved Permanently -> sûr pour le SEO, les navigateurs mettent en cache la nouvelle URL pour toujours
302 Found -> redirection temporaire, ne pas mettre en cache la cible
304 Not Modified -> la copie en cache est encore fraîche (correspondance ETag/Last-Modified)
307 Temporary Redirect -> comme 302 mais la méthode NE doit PAS changer (POST reste POST)
308 Permanent Redirect -> comme 301 mais préserve la méthode de la requête
RFC : RFC 7231 section 6.4 définit les codes de redirection 3xx
RFC : RFC 7232 section 4.1 définit la sémantique 304 Not ModifiedErreurs client 4xx - authentification vs permission
400 Bad Request JSON malformé, champ requis manquant
401 Unauthorized Jeton manquant ou invalide - l'appelant doit s'authentifier
403 Forbidden Authentifié mais non autorisé à accéder à cette ressource
404 Not Found La ressource n'existe pas (ou faire semblant qu'elle n'existe pas, pour la sécurité)
409 Conflict Clé en double, incompatibilité de version de verrouillage optimiste
429 Too Many Reqs Limite de débit atteinte - voir l'en-tête Retry-After
RFC : RFC 7231 section 6.5 définit les codes d'erreur client 4xx
RFC : RFC 6585 section 4 définit 429 Too Many RequestsErreurs serveur 5xx - débogage d'un upstream
500 Internal Server Error Exception non gérée dans le code de l'app - vérifiez les logs
502 Bad Gateway Nginx/upstream a reçu une réponse invalide du backend
503 Service Unavailable Maintenance, surcharge, ou app en démarrage
504 Gateway Timeout L'upstream n'a pas répondu dans le délai imparti du proxy
RFC : RFC 7231 section 6.6 définit les codes d'erreur serveur 5xx
Tri rapide : 5xx = notre faute, 4xx = faute de l'appelantVraie session curl montrant plusieurs codes
$ curl -I https://example.com/old-page
HTTP/2 301
location: https://example.com/new-page
$ curl -I https://example.com/admin
HTTP/2 401
www-authenticate: Bearer realm="api"
$ curl -X POST https://example.com/api/posts -d '{}'
HTTP/2 422
content-type: application/json
Note : 422 Unprocessable Entity est une extension WebDAV (RFC 4918) utilisée pour les erreurs de validationFAQ
Que signifient les classes 1xx, 2xx, 3xx, 4xx et 5xx ?
1xx est informationnel (rare en pratique). 2xx signifie que la requête a réussi. 3xx est une redirection — le client doit suivre une autre URL. 4xx est un problème côté client (mauvaise requête, authentification manquante, ressource manquante). 5xx est un problème côté serveur (la requête semblait correcte mais le serveur n'a pas pu la traiter). Vérifiez toujours la classe en premier en lisant une ligne de log.
Quelle est la différence entre 301 et 302 ?
301 Moved Permanently indique aux clients et aux moteurs de recherche que la ressource a définitivement bougé — les navigateurs mettent en cache la redirection de manière agressive et le « jus » SEO est transféré vers la nouvelle URL. 302 Found est une redirection temporaire ; les clients ne sont pas censés la mettre en cache à long terme. Utilisez 308 pour les redirections permanentes quand vous devez préserver la méthode de la requête, et 307 pour les redirections temporaires sous la même contrainte.
Quand renvoyer 401 plutôt que 403 ?
401 Unauthorized signifie que le client ne s'est pas authentifié, ou que les identifiants envoyés sont invalides — la réponse devrait inclure un en-tête WWW-Authenticate. 403 Forbidden signifie que le serveur a compris qui est le client et refuse de servir cette ressource quoi qu'il arrive. Se connecter résout 401 ; se connecter ne résout pas 403.
Dois-je utiliser 404 ou 410 pour des ressources qui n'existent plus ?
404 Not Found signifie « je ne trouve pas ceci ; ça existe peut-être ailleurs ou ça reviendra plus tard. » 410 Gone signifie « cette ressource était ici, elle a été retirée intentionnellement, ne la cherchez plus. » Les moteurs de recherche retirent les URL en 410 de l'index plus vite que les 404, donc 410 est le bon choix pour les pages retirées que vous ne voulez pas voir re-crawlées.
Comment lire un code de statut lors du débogage d'une API ?
Lisez d'abord la classe (4xx vs 5xx vous dit de quel côté regarder), puis le code spécifique, puis le corps de la réponse. Le corps contient généralement le vrai message d'erreur et un code d'erreur interne ; le statut HTTP n'est que la catégorie. Inspectez toujours les en-têtes comme Retry-After, WWW-Authenticate et Location en plus du statut.
Les codes non-2xx nuisent-ils au SEO ?
Certains oui, d'autres non. Des réponses 5xx persistantes signalent un site peu fiable et les moteurs de recherche finiront par réduire la fréquence d'exploration. Les redirections 301/308 transmettent le « jus » des liens ; 302/307 non. 410 retire les pages de l'index ; les 404 traînent plus longtemps. Un 200 avec un corps de soft-404 (une vraie page « non trouvée » renvoyant 200) est pire pour le SEO qu'un vrai 404 car cela remplit l'index de pages vides.
À quoi servent 418, 451 et autres codes inhabituels ?
418 « I'm a teapot » est le célèbre code d'un poisson d'avril issu du RFC 2324 — les vrais services ne devraient jamais le renvoyer en production. 451 Unavailable For Legal Reasons indique que la ressource est bloquée pour des raisons juridiques (nommé d'après Fahrenheit 451 de Bradbury). 429 Too Many Requests signale une limitation de débit et devrait être accompagné d'un en-tête Retry-After. 503 Service Unavailable est le bon code pour une maintenance planifiée.