Table des codes de statut HTTP
Consultez la liste complète des codes de statut HTTP normalisés (1xx à 5xx), avec leur nom canonique et une explication en français. Recherchez par numéro, mot-clé ou filtrez par catégorie.
62 codes
Le serveur a reçu les en-têtes de la requête et le client peut continuer à envoyer le corps de la requête.
Le serveur accepte de changer de protocole, comme demandé par l'en-tête Upgrade du client (par exemple vers WebSocket).
Le serveur traite la requête mais n'a pas encore de réponse disponible ; évite que le client ne considère la connexion comme rompue (WebDAV).
Permet au serveur d'envoyer des en-têtes préliminaires (comme des ressources à précharger) avant la réponse finale.
La requête a réussi. Le contenu de la réponse dépend de la méthode utilisée (GET renvoie une ressource, POST le résultat d'une action, etc.).
La requête a réussi et une nouvelle ressource a été créée, généralement en réponse à une requête POST ou PUT.
La requête a été acceptée pour traitement, mais ce traitement n'est pas encore terminé ou garanti.
La requête a réussi mais les informations renvoyées proviennent d'une source tierce plutôt que du serveur d'origine.
La requête a réussi mais il n'y a aucun contenu à renvoyer ; utile après une suppression ou une mise à jour sans corps de réponse.
La requête a réussi et demande au client de réinitialiser le formulaire ou la vue ayant servi à l'envoyer.
Le serveur renvoie uniquement une partie de la ressource, en réponse à un en-tête Range (utile pour le téléchargement repris ou le streaming vidéo).
La réponse contient plusieurs statuts indépendants pour plusieurs sous-requêtes, encodés en XML (WebDAV).
Évite de répéter plusieurs fois les mêmes membres dans une réponse Multi-Status liés à une même ressource DAV (WebDAV).
Le serveur a traité la requête et la réponse est le résultat d'une ou plusieurs manipulations d'instance appliquées à la ressource actuelle.
La requête a plusieurs réponses possibles ; le client (ou l'utilisateur) doit choisir parmi les options proposées.
La ressource a été déplacée définitivement vers une nouvelle URL. À utiliser pour les redirections permanentes, favorisées pour le SEO.
La ressource se trouve temporairement à une autre URL. Contrairement à 301, elle indique un déplacement non permanent.
Le client doit récupérer la ressource demandée via une requête GET à une autre URL, typiquement après un POST réussi.
La ressource n'a pas été modifiée depuis la dernière requête ; le client peut utiliser sa version en cache.
La ressource demandée doit être accédée via le proxy indiqué. Obsolète et déconseillé pour des raisons de sécurité.
Redirection temporaire qui, contrairement à 302, impose de conserver la même méthode et le même corps de requête.
Redirection permanente qui, contrairement à 301, impose de conserver la même méthode et le même corps de requête.
Le serveur ne peut pas traiter la requête à cause d'une syntaxe invalide ou de paramètres incorrects envoyés par le client.
Une authentification est requise ou a échoué. Le client doit s'identifier (malgré le nom, il s'agit bien d'authentification, pas d'autorisation).
Réservé pour un usage futur lié au paiement ; rarement utilisé tel quel, parfois détourné par certaines API pour des limites de quota.
Le serveur a compris la requête mais refuse de l'exécuter : le client est identifié mais n'a pas les droits nécessaires.
Le serveur ne trouve pas la ressource demandée. Ne préjuge pas de son caractère temporaire ou permanent.
La méthode HTTP utilisée (GET, POST, DELETE...) n'est pas autorisée pour la ressource ciblée.
Le serveur ne peut produire de réponse correspondant aux critères d'Accept envoyés par le client (format, langue, encodage).
Le client doit d'abord s'authentifier auprès du proxy utilisé pour accéder à la ressource.
Le serveur a mis fin à la connexion car le client n'a pas envoyé de requête complète dans le délai imparti.
La requête entre en conflit avec l'état actuel de la ressource, par exemple lors de modifications concurrentes.
La ressource demandée n'existe plus et a été supprimée définitivement, sans adresse de redirection connue.
Le serveur exige la présence de l'en-tête Content-Length, absent de la requête envoyée.
Une condition préalable fournie dans les en-têtes de la requête (comme If-Match) n'est pas satisfaite par le serveur.
Le corps de la requête dépasse la taille que le serveur est disposé ou capable de traiter.
L'URI fournie est trop longue pour être interprétée par le serveur.
Le format du corps de la requête n'est pas pris en charge par le serveur ou la ressource ciblée.
La plage demandée via l'en-tête Range ne peut être fournie, souvent car elle dépasse la taille réelle de la ressource.
Le serveur ne peut pas satisfaire les exigences indiquées dans l'en-tête Expect de la requête.
Code humoristique issu d'un poisson d'avril de l'IETF (RFC 2324) : le serveur refuse de préparer du café car c'est une théière.
La requête a été envoyée à un serveur incapable de produire une réponse, notamment en cas de mauvaise réutilisation de connexion.
La requête est syntaxiquement correcte mais contient des erreurs sémantiques qui empêchent son traitement (validation de données).
La ressource visée est verrouillée et ne peut être modifiée tant que le verrou n'est pas levé (WebDAV).
La requête a échoué car elle dépendait d'une autre requête qui a elle-même échoué (WebDAV).
Le serveur refuse de traiter une requête risquant d'être rejouée, envoyée avant l'établissement complet de la connexion (early data TLS).
Le serveur refuse de traiter la requête avec le protocole actuel et demande au client de passer à un autre protocole.
Le serveur exige que la requête contienne des conditions préalables, afin d'éviter les conflits de mise à jour concurrente.
Le client a envoyé trop de requêtes dans un laps de temps donné (limitation de débit, rate limiting).
Les en-têtes de la requête sont trop volumineux pour être traités par le serveur.
La ressource n'est pas accessible pour des raisons légales, par exemple suite à une décision de justice ou une censure.
Le serveur a rencontré une situation inattendue qui l'empêche de traiter la requête, sans autre précision.
Le serveur ne prend pas en charge la fonctionnalité requise pour traiter la requête (méthode inconnue ou non supportée).
Le serveur, agissant comme passerelle ou proxy, a reçu une réponse invalide du serveur en amont.
Le serveur n'est temporairement pas en mesure de traiter la requête, souvent en cas de surcharge ou de maintenance.
Le serveur, agissant comme passerelle ou proxy, n'a pas reçu de réponse à temps du serveur en amont.
Le serveur ne prend pas en charge la version du protocole HTTP utilisée dans la requête.
Erreur de configuration interne du serveur liée à la négociation de contenu (RFC 2295), rarement rencontrée en pratique.
Le serveur ne peut pas stocker la représentation nécessaire pour terminer la requête, faute d'espace disponible (WebDAV).
Le serveur a détecté une boucle infinie lors du traitement de la requête (WebDAV).
Des extensions supplémentaires à la requête sont nécessaires pour que le serveur puisse la traiter.
Le client doit s'authentifier pour obtenir l'accès réseau, comme sur un portail captif de connexion Wi-Fi.
Comprendre les grandes familles de codes
Les codes de statut HTTP sont regroupés en cinq familles selon leur premier chiffre. Les codes 1xx sont des réponses d'information, envoyées avant une réponse finale pour signaler qu'un traitement est en cours ou qu'un protocole change. Les codes 2xx confirment qu'une requête a réussi, avec des nuances : 200 pour un succès générique, 201 après une création de ressource, 204 quand il n'y a rien à renvoyer.
Les codes 3xx indiquent qu'une action supplémentaire est nécessaire pour terminer la requête, le plus souvent suivre une redirection vers une autre URL. Le choix entre redirection permanente (301, 308) et temporaire (302, 307) a un impact direct sur le référencement et la mise en cache côté navigateur, donc mieux vaut ne pas s'y tromper.
Les codes 4xx signalent une erreur imputable au client : requête mal formée, authentification manquante, ressource introuvable, ou trop de requêtes envoyées trop vite. Les codes 5xx signalent au contraire que le serveur reconnaît son échec à traiter une requête qui était pourtant valide, par exemple à cause d'une panne interne ou d'un service en amont indisponible.
D'où viennent ces codes ?
Les codes de statut HTTP sont définis par des RFC successives (notamment la RFC 9110 qui consolide la sémantique HTTP) et maintenus dans un registre officiel par l'IANA (Internet Assigned Numbers Authority). Certains proviennent d'extensions spécifiques comme WebDAV (207, 423, 424, 507, 508) utilisées pour la gestion de fichiers distants, tandis que d'autres sont d'usage très général et présents dans quasiment toutes les API web.
Cette table sert de référence rapide pour du développement web, du débogage d'API, ou de la configuration de serveurs et de proxys. Elle ne remplace pas la lecture des spécifications officielles pour les cas d'usage avancés, mais couvre les codes que vous rencontrerez dans l'immense majorité des situations courantes.
401 Unauthorized signifie que le client n'est pas authentifié (ou que son authentification a échoué) : le serveur ne sait pas qui vous êtes. 403 Forbidden signifie que le serveur vous a identifié mais refuse l'accès car vous n'avez pas les droits nécessaires. En résumé : 401 = « connectez-vous », 403 = « vous êtes connecté mais interdit d'accès ».
301 Moved Permanently indique un déplacement définitif : les moteurs de recherche transfèrent le référencement vers la nouvelle URL et les navigateurs peuvent mettre la redirection en cache durablement. 302 Found (ou 307 pour une redirection stricte sur la méthode) indique un déplacement temporaire, à utiliser par exemple pour une redirection de maintenance ou un test A/B, sans transférer le référencement.
Le code 418 « I'm a Teapot » provient d'un poisson d'avril de l'IETF publié en 1998 (RFC 2324, Hyper Text Coffee Pot Control Protocol). Il n'a jamais été retiré de la liste IANA et certains frameworks et API l'utilisent encore aujourd'hui, souvent de façon humoristique.
Elle couvre les codes normalisés les plus courants et documentés par l'IANA (une soixantaine au total), suffisants pour l'immense majorité des usages en développement web. Certains codes très rares, propres à des serveurs ou frameworks spécifiques (codes non standards renvoyés par certains CDN par exemple), n'y figurent pas.
Oui par définition : toute la famille 5xx signale que le serveur reconnaît avoir échoué à traiter une requête pourtant valide. Cela ne veut pas dire que la cause est forcément un bug côté serveur applicatif : elle peut venir d'une base de données indisponible, d'un service tiers en amont (502, 504) ou d'une saturation temporaire (503).
404 Not Found convient quand vous ne savez pas si la ressource reviendra un jour. 410 Gone est plus précis et signale explicitement que la ressource a été supprimée intentionnellement et définitivement, ce qui peut aider les moteurs de recherche à désindexer la page plus rapidement.