PK Systems PK Systems
Web et marketing

Codes de statut HTTP

Référence cherchable de chaque code de statut HTTP — 1xx à 5xx, RFC 7231 et au-delà.

Codes de statut HTTP

100 Continue #

Réponse intermédiaire signalant que le serveur a reçu les en-têtes de la requête et que le client doit poursuivre l'envoi du corps. Définie dans la RFC 9110 section 15.2.1.

Cause fréquente

Le client a envoyé un en-tête Expect: 100-continue pour vérifier que le serveur acceptera un corps volumineux avant de le transmettre.

Quand l'utiliser

Utilisé entre les en-têtes et le corps des envois volumineux (PUT, POST) afin que le client ne gaspille pas de bande passante pour une requête que le serveur rejetterait.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 100 Continue
101 Switching Protocols #

Le serveur accepte la demande de changement de protocole demandée via l'en-tête Upgrade. Définie dans la RFC 9110 section 15.2.2.

Cause fréquente

Une mise à niveau a été négociée — typiquement vers WebSocket ou HTTP/2 en clair (h2c).

Quand l'utiliser

Renvoyé pour valider une poignée de main WebSocket (Upgrade: websocket) ou tout changement de protocole négocié sur la même connexion.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 101 Switching Protocols
200 OK #

La requête a réussi. Le sens dépend de la méthode HTTP. Définie dans la RFC 9110 section 15.3.1.

Cause fréquente

Le statut par défaut pour toute requête réussie qui retourne un corps (GET, HEAD, POST, etc.).

Quand l'utiliser

Utilisez-le pour les réponses réussies qui contiennent une représentation, comme une page HTML, un payload JSON ou un téléchargement de fichier.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 200 OK
201 Created #

La requête a abouti et a créé une nouvelle ressource. L'URL de la nouvelle ressource doit figurer dans l'en-tête Location. Définie dans la RFC 9110 section 15.3.2.

Cause fréquente

Un POST ou un PUT a créé une ressource sur le serveur.

Quand l'utiliser

Renvoyez-le après avoir créé une ressource (utilisateur, commande, fichier) avec un en-tête Location pointant sur la nouvelle URL.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 201 Created
202 Accepted #

La requête a été acceptée pour traitement, mais ce dernier n'est pas terminé. Définie dans la RFC 9110 section 15.3.3.

Cause fréquente

Le serveur a mis le travail en file d'attente — par exemple un job en arrière-plan, une tâche de rendu ou un lot d'e-mails.

Quand l'utiliser

Idéal pour les workflows asynchrones : renvoyez 202 avec une URL de statut que le client peut interroger.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 202 Accepted
204 No Content #

La requête a réussi, mais il n'y a pas de corps à renvoyer. Définie dans la RFC 9110 section 15.3.5.

Cause fréquente

Un PUT, DELETE ou POST a réussi sans données à retourner.

Quand l'utiliser

Parfait pour les actions qui aboutissent sans charge utile (suppression, accusé de réception, mise à jour silencieuse).

curl -i -X HEAD https://example.com/path
# HTTP/1.1 204 No Content
206 Partial Content #

Le serveur n'envoie qu'une partie de la ressource, comme demandé via Range. Définie dans la RFC 9110 section 15.3.7.

Cause fréquente

Le client a envoyé un en-tête Range pour reprendre un téléchargement ou diffuser un média.

Quand l'utiliser

Utilisé pour la lecture de vidéos, la reprise de téléchargements et toute requête HTTP partielle.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 206 Partial Content
301 Moved Permanently #

La ressource a une nouvelle URL définitive ; les clients devraient mettre à jour leurs liens. Définie dans la RFC 9110 section 15.4.2.

Cause fréquente

Un site a été restructuré ou une URL canonique a changé.

Quand l'utiliser

Indispensable pour les redirections SEO permanentes (HTTPS, www, refonte d'URL).

curl -i -X HEAD https://example.com/path
# HTTP/1.1 301 Moved Permanently
302 Found #

La ressource est temporairement disponible à une autre URL. Définie dans la RFC 9110 section 15.4.3.

Cause fréquente

Redirection temporaire — souvent après une connexion ou la soumission d'un formulaire.

Quand l'utiliser

Utilisez-la pour les redirections temporaires lorsque la méthode peut changer ; préférez 307 pour préserver POST.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 302 Found
303 See Other #

Le client doit récupérer la ressource via GET à une autre URL. Définie dans la RFC 9110 section 15.4.4.

Cause fréquente

Un POST a abouti et le serveur veut que le client charge une page de confirmation via GET.

Quand l'utiliser

Modèle classique POST-puis-Redirect-puis-GET pour empêcher la double soumission de formulaires.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 303 See Other
304 Not Modified #

La ressource n'a pas changé depuis la dernière requête conditionnelle ; le client peut servir sa version en cache. Définie dans la RFC 9110 section 15.4.5.

Cause fréquente

Le client a envoyé If-None-Match ou If-Modified-Since et le serveur confirme que sa copie est encore valide.

Quand l'utiliser

Renvoyée par les CDN et serveurs HTTP pour économiser de la bande passante sur les ressources statiques.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 304 Not Modified
307 Temporary Redirect #

Comme 302 mais préserve explicitement la méthode et le corps de la requête. Définie dans la RFC 9110 section 15.4.8.

Cause fréquente

La ressource est temporairement déplacée et la méthode HTTP doit être conservée.

Quand l'utiliser

Préférez-le à 302 lorsque vous redirigez un POST/PUT et que vous voulez que le client rejoue la même méthode.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 307 Temporary Redirect
308 Permanent Redirect #

Comme 301 mais préserve explicitement la méthode et le corps. Définie dans la RFC 7538.

Cause fréquente

Redirection permanente où la méthode doit rester identique (souvent côté API).

Quand l'utiliser

Utilisez 308 pour des changements d'URL durables sur des API qui acceptent autre chose que GET.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 308 Permanent Redirect
400 Bad Request #

Le serveur ne peut pas traiter la requête à cause d'une syntaxe invalide ou d'un payload mal formé. Définie dans la RFC 9110 section 15.5.1.

Cause fréquente

JSON invalide, paramètre manquant, en-tête mal formé ou échec de validation du schéma.

Quand l'utiliser

Renvoyez-le quand la requête est syntaxiquement ou sémantiquement incorrecte avant toute logique métier.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 400 Bad Request
401 Unauthorized #

L'authentification est requise et a échoué ou n'a pas été fournie. La réponse doit inclure un en-tête WWW-Authenticate. Définie dans la RFC 9110 section 15.5.2.

Cause fréquente

Jeton expiré, identifiants manquants ou en-tête Authorization invalide.

Quand l'utiliser

Utilisez-la quand l'utilisateur doit s'authentifier (ou se réauthentifier) pour accéder à la ressource.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 401 Unauthorized
403 Forbidden #

Le serveur a compris la requête mais refuse de l'exécuter. L'authentification ne changera pas l'issue. Définie dans la RFC 9110 section 15.5.4.

Cause fréquente

Permissions insuffisantes, blocage par règle de pare-feu ou restriction géographique.

Quand l'utiliser

Renvoyez 403 lorsque l'utilisateur est authentifié mais n'a pas le droit d'effectuer l'action.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 403 Forbidden
404 Not Found #

Le serveur n'a rien trouvé qui corresponde à l'URI de la requête. Définie dans la RFC 9110 section 15.5.5.

Cause fréquente

L'URL est mal orthographiée, la ressource a été supprimée ou le routage ne correspond à aucune route.

Quand l'utiliser

Réponse par défaut pour les chemins inconnus et les ressources qui peuvent revenir un jour.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 404 Not Found
405 Method Not Allowed #

La méthode HTTP n'est pas prise en charge pour cette ressource. La réponse doit inclure un en-tête Allow. Définie dans la RFC 9110 section 15.5.6.

Cause fréquente

Tentative d'utiliser POST sur une route en lecture seule, ou DELETE sur une ressource immuable.

Quand l'utiliser

Renvoyez-la avec un en-tête Allow listant les méthodes acceptées (par ex. Allow: GET, HEAD).

curl -i -X HEAD https://example.com/path
# HTTP/1.1 405 Method Not Allowed
406 Not Acceptable #

Le serveur ne peut pas produire de réponse correspondant à l'en-tête Accept du client. Définie dans la RFC 9110 section 15.5.7.

Cause fréquente

Le client demande un type de média ou un encodage qu'aucune représentation ne propose.

Quand l'utiliser

Rare en pratique — la plupart des API renvoient 200 avec une représentation par défaut au lieu de 406.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 406 Not Acceptable
408 Request Timeout #

Le serveur a fermé la connexion après avoir attendu trop longtemps une requête complète. Définie dans la RFC 9110 section 15.5.9.

Cause fréquente

Le client a ouvert une connexion mais n'a pas envoyé la requête à temps.

Quand l'utiliser

Émis par les proxys et les serveurs avec un timeout de connexion paresseuse.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 408 Request Timeout
409 Conflict #

La requête est en conflit avec l'état actuel de la ressource. Définie dans la RFC 9110 section 15.5.10.

Cause fréquente

Mise à jour concurrente, ETag invalide ou tentative de créer un doublon (e-mail unique, slug pris).

Quand l'utiliser

Utilisez-la pour les contrôles de concurrence optimiste et les violations de contraintes d'unicité.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 409 Conflict
410 Gone #

La ressource a été supprimée définitivement et ne reviendra pas. Définie dans la RFC 9110 section 15.5.11.

Cause fréquente

Suppression intentionnelle d'une page ou d'un endpoint que vous voulez voir oublier des index.

Quand l'utiliser

Préférez-la à 404 quand vous voulez que les moteurs de recherche désindexent rapidement.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 410 Gone
411 Length Required #

Le serveur exige un en-tête Content-Length. Définie dans la RFC 9110 section 15.5.12.

Cause fréquente

Le client a envoyé une requête sans Content-Length sur une route qui en a besoin.

Quand l'utiliser

Pratique pour les uploads où vous refusez le transfert chunked sans longueur déclarée.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 411 Length Required
413 Content Too Large #

Le payload de la requête dépasse les limites du serveur. Définie dans la RFC 9110 section 15.5.14.

Cause fréquente

Upload de fichier trop volumineux, JSON gigantesque ou body au-delà de client_max_body_size.

Quand l'utiliser

Utilisée par Nginx, les CDN et les API pour rejeter les corps trop gros avant la lecture.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 413 Content Too Large
414 URI Too Long #

L'URI de la requête est trop longue pour être interprétée. Définie dans la RFC 9110 section 15.5.15.

Cause fréquente

Une chaîne de requête démesurée, souvent issue d'un GET avec des centaines de paramètres.

Quand l'utiliser

Utilisez plutôt POST avec un corps JSON quand vous risquez d'atteindre cette limite.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 414 URI Too Long
415 Unsupported Media Type #

Le format du payload n'est pas pris en charge par le serveur ou la ressource. Définie dans la RFC 9110 section 15.5.16.

Cause fréquente

Le client a envoyé un Content-Type que l'endpoint n'accepte pas (par ex. text/xml sur une API JSON).

Quand l'utiliser

Renvoyez-la quand vous validez Content-Type avant le parsing du corps.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 415 Unsupported Media Type
418 I'm a teapot #

Code historique issu d'un poisson d'avril (RFC 2324) ; conservé en clin d'œil. Une théière refuse de préparer du café.

Cause fréquente

Aucune cause sérieuse — c'est de l'humour.

Quand l'utiliser

Évitez-le en production ; certains projets l'utilisent pour signaler un easter egg ou une route bloquée.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 418 I'm a teapot
422 Unprocessable Content #

La syntaxe est correcte mais les données sont sémantiquement invalides. Définie dans la RFC 9110 section 15.5.21.

Cause fréquente

Échec de validation : format d'e-mail incorrect, valeur hors plage, champ obligatoire vide.

Quand l'utiliser

Standard moderne pour les erreurs de validation dans les API REST et GraphQL (Laravel, Rails, FastAPI).

curl -i -X HEAD https://example.com/path
# HTTP/1.1 422 Unprocessable Content
423 Locked #

La ressource source ou destination est verrouillée. Définie dans la RFC 4918 (WebDAV).

Cause fréquente

Un client WebDAV a verrouillé la ressource ou un système de gestion de contenu protège un fichier.

Quand l'utiliser

Spécifique à WebDAV ; rarement émis par les API REST grand public.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 423 Locked
425 Too Early #

Le serveur ne veut pas traiter une requête qui pourrait être rejouée. Définie dans la RFC 8470.

Cause fréquente

Le client a envoyé des données 0-RTT en TLS 1.3 sur un endpoint sensible aux replays.

Quand l'utiliser

Utilisée par les serveurs HTTPS modernes pour refuser les requêtes 0-RTT trop tôt.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 425 Too Early
428 Precondition Required #

Le serveur exige une requête conditionnelle pour empêcher les pertes lors de mises à jour concurrentes. Définie dans la RFC 6585.

Cause fréquente

Un PUT a été envoyé sans en-tête If-Match sur une ressource qui exige un contrôle de concurrence.

Quand l'utiliser

Forcez-la pour les API où l'écrasement aveugle d'une ressource n'est pas acceptable.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 428 Precondition Required
429 Too Many Requests #

Le client a envoyé trop de requêtes dans un laps de temps donné. Définie dans la RFC 6585.

Cause fréquente

Limitation de débit (rate limiting) déclenchée par IP, par jeton ou par utilisateur.

Quand l'utiliser

Joignez Retry-After et un en-tête X-RateLimit-* pour aider les clients à se rétablir.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 429 Too Many Requests
431 Request Header Fields Too Large #

Les en-têtes de la requête sont trop longs au total ou individuellement. Définie dans la RFC 6585.

Cause fréquente

Un cookie monstrueux, des chaînes de Referer démesurées ou des dizaines d'en-têtes empilés.

Quand l'utiliser

Émise par les proxys et frontaux web (Nginx, IIS) qui imposent des limites de taille d'en-tête.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 431 Request Header Fields Too Large
451 Unavailable For Legal Reasons #

L'accès à la ressource est refusé pour des raisons légales. Définie dans la RFC 7725.

Cause fréquente

Censure d'État, ordonnance judiciaire, blocage DMCA ou retrait pour atteinte à la vie privée.

Quand l'utiliser

Référence à Fahrenheit 451 ; signalez clairement la nature légale du blocage.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 451 Unavailable For Legal Reasons
500 Internal Server Error #

Le serveur a rencontré une condition inattendue qui l'empêche de répondre. Définie dans la RFC 9110 section 15.6.1.

Cause fréquente

Exception non gérée, bug dans le code applicatif, dépendance critique en panne.

Quand l'utiliser

Statut générique de dernier recours — préférez des codes plus précis quand vous le pouvez (502, 503, 504).

curl -i -X HEAD https://example.com/path
# HTTP/1.1 500 Internal Server Error
501 Not Implemented #

Le serveur ne reconnaît pas la méthode de la requête ou ne sait pas la traiter. Définie dans la RFC 9110 section 15.6.2.

Cause fréquente

Méthode HTTP exotique (PATCH avant son support, par ex.) ou fonctionnalité non développée.

Quand l'utiliser

Renvoyez-la pour les fonctionnalités prévues mais pas encore disponibles ; 405 si la méthode est connue mais interdite.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 501 Not Implemented
502 Bad Gateway #

Le serveur, agissant en tant que passerelle ou proxy, a reçu une réponse invalide d'un serveur amont. Définie dans la RFC 9110 section 15.6.3.

Cause fréquente

L'application a planté, le service amont a renvoyé du HTML inattendu ou la connexion s'est fermée brutalement.

Quand l'utiliser

Symptôme courant d'un container PHP-FPM mort, d'un Node qui crash ou d'un upstream Nginx injoignable.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 502 Bad Gateway
503 Service Unavailable #

Le serveur n'est pas prêt à traiter la requête, généralement pour cause de surcharge ou de maintenance. Définie dans la RFC 9110 section 15.6.4.

Cause fréquente

Mode maintenance, panne planifiée ou tampon surchargé.

Quand l'utiliser

Joignez un en-tête Retry-After indiquant quand le client peut retenter.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 503 Service Unavailable
504 Gateway Timeout #

La passerelle ou le proxy n'a pas reçu de réponse à temps du serveur amont. Définie dans la RFC 9110 section 15.6.5.

Cause fréquente

Une requête lente vers une base de données, un service externe en surcharge ou un timeout d'upstream Nginx.

Quand l'utiliser

Indique souvent que vous avez besoin de timeouts plus courts côté client et de jobs en file d'attente côté serveur.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 504 Gateway Timeout
505 HTTP Version Not Supported #

La version majeure de HTTP utilisée dans la requête n'est pas prise en charge. Définie dans la RFC 9110 section 15.6.6.

Cause fréquente

Le client a envoyé du HTTP/0.9 ou une variante exotique que le serveur refuse.

Quand l'utiliser

Quasiment jamais vue en pratique — les versions modernes (HTTP/1.1, HTTP/2, HTTP/3) sont universellement supportées.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 505 HTTP Version Not Supported
511 Network Authentication Required #

Le client doit s'authentifier pour accéder au réseau. Définie dans la RFC 6585.

Cause fréquente

Portail captif Wi-Fi (hôtel, aéroport) qui intercepte la requête avant la connexion.

Quand l'utiliser

Standardisé pour signaler clairement aux applications qu'un portail captif bloque le trafic.

curl -i -X HEAD https://example.com/path
# HTTP/1.1 511 Network Authentication Required

Que sont les codes de statut HTTP ?

Un code de statut HTTP est le nombre à trois chiffres qu'un serveur renvoie au début de chaque réponse. Ils se regroupent en cinq familles : 1xx informationnel, 2xx succès, 3xx redirection, 4xx erreur client et 5xx erreur serveur. Les codes sont définis dans la RFC 9110 (la spécification consolidée de 2022 qui remplace l'ancienne série 7230–7235), avec des extensions dans les RFC 6585 (4xx/5xx supplémentaires), 7725 (451), 4918 (WebDAV) et 8470 (425). Bien lire un statut, c'est la différence entre corriger un bug en cinq minutes et chasser un fantôme tout l'après-midi : un 404 venant de votre CDN signifie que le chemin est faux, un 502 venant de votre proxy signifie que l'application a planté, et un 401 sans en-tête WWW-Authenticate trahit un backend mal configuré. Cette page est un aide-mémoire consultable — chaque carte indique le nom officiel, une description fondée sur les RFC, la cause typique et des extraits de code concrets que vous pouvez coller dans curl, Python, JavaScript ou PHP.

Comment utiliser cette référence

Saisissez un code ou une partie d'un nom dans le champ de recherche, ou filtrez par famille à l'aide des puces. Chaque carte se déplie pour révéler la description technique, les causes fréquentes et un extrait de code dans plusieurs langages que vous pouvez adapter. Chaque code possède sa propre ancre (par ex. #404) afin que vous puissiez créer des liens directs vers un statut précis depuis la documentation de votre équipe.

Familles de codes en un coup d'œil

Plage Famille Signification
1xxInformationnelRéponses provisoires ; rarement vues côté applicatif.
2xxSuccèsLa requête a été reçue, comprise et acceptée.
3xxRedirectionUne action supplémentaire est nécessaire (URL différente, validation de cache, etc.).
4xxErreur clientLa requête comportait un problème (entrée invalide, authentification absente, mauvaise méthode).
5xxErreur serveurLe serveur n'a pas réussi à traiter une requête apparemment valide.

Questions fréquentes

D'où viennent ces codes ?
La RFC 9110 est la spécification canonique de 2022 qui consolide l'ancienne série RFC 7231. Des codes additionnels figurent dans les RFC 6585 (428, 429, 431, 511), 7725 (451), 4918 (WebDAV) et 8470 (425).
Faut-il utiliser 401 ou 403 ?
401 signifie « vous n'êtes pas authentifié ». 403 signifie « vous êtes authentifié mais n'avez pas le droit ». Un 401 doit inclure un en-tête WWW-Authenticate listant les schémas acceptés ; un 403 ne le doit pas, car le problème ne vient pas des identifiants.
Quelle est la différence entre 301 et 308 ?
Les deux signalent une redirection permanente. 301 réécrit historiquement POST en GET dans de nombreux clients, 308 préserve explicitement la méthode et le corps. Utilisez 308 dans les nouvelles API.
Quand mon CDN renvoie-t-il un 502 plutôt qu'un 504 ?
502 (Bad Gateway) signifie que l'amont a renvoyé des données invalides ou a fermé la connexion. 504 (Gateway Timeout) signifie que l'amont a mis trop de temps. CloudFront, Cloudflare et Nginx les étiquettent différemment dans les journaux — les deux indiquent un problème applicatif.
Faut-il renvoyer 404 ou 410 pour du contenu supprimé ?
Utilisez 410 quand la ressource a été retirée intentionnellement et de façon permanente et que vous voulez que les robots l'oublient rapidement. 404 convient pour les fautes de frappe et les contenus susceptibles de revenir ; c'est aussi une réponse défendable pour des ressources dont vous ne voulez pas confirmer l'existence.
Les extraits de code sont-ils sûrs à copier ?
Ce sont des modèles minimaux destinés à la lecture et à l'adaptation. Validez toujours les entrées, gérez les erreurs et respectez la sémantique HTTP dans votre propre code — les exemples passent ces points sous silence par souci de concision.