Le Guide Ultime des Codes de Statut HTTP
Les codes de statut HTTP indiquent le résultat du traitement d'une requête par un serveur web. Ils sont regroupés en cinq classes, chacune représentant une catégorie différente de réponse. Comprendre ces codes est essentiel pour les développeurs web, les concepteurs d'API, les administrateurs système et toute personne travaillant avec les technologies web. Les codes de statut permettent aux clients — qu'il s'agisse de navigateurs, d'applications mobiles ou d'autres serveurs — de comprendre ce qui est arrivé à leur requête et comment procéder.
Comment Fonctionnent les Codes de Statut HTTP
Lorsqu'un client envoie une requête HTTP à un serveur, le serveur répond avec un code de statut à trois chiffres suivi d'une phrase de raison lisible par l'humain. Le premier chiffre du code de statut définit la classe de la réponse. Les deux chiffres restants n'ont aucun rôle de catégorisation spécifique mais offrent une granularité au sein de chaque classe. Les codes de statut sont définis par l'Internet Assigned Numbers Authority (IANA) sur la base de spécifications publiées dans des documents RFC. En 2025, il existe plus de 70 codes de statut HTTP officiellement enregistrés, bien que seulement environ 30 à 40 soient couramment utilisés.
Référence Rapide
| Classe | Catégorie | Signification |
|---|---|---|
| 1xx | Informationnel | Requête reçue, traitement en cours |
| 2xx | Succès | Requête reçue, comprise et acceptée |
| 3xx | Redirection | Action supplémentaire nécessaire pour compléter la requête |
| 4xx | Erreur Client | Requête avec une syntaxe incorrecte ou ne pouvant être satisfaite |
| 5xx | Erreur Serveur | Le serveur n'a pas pu satisfaire une requête valide |
1xx - Informationnel
Ces codes indiquent que le serveur a reçu les en-têtes de la requête et que le client devrait continuer à envoyer le corps, ou que le serveur passe à un protocole différent. Ce sont des réponses provisoires sans contenu réel.
| Code | Nom | Description |
|---|---|---|
| 100 | Continuer | Serveur a reçu les en-têtes, le client devrait continuer à envoyer le corps |
| 101 | Changement de Protocole | Le serveur change de protocole (ex. mise à niveau vers WebSocket) |
| 102 | Traitement | Le serveur traite la requête mais pas encore de réponse (WebDAV) |
| 103 | Indices Précoces | Précharger les ressources pendant que le serveur prépare la réponse, utilisé pour l'optimisation des performances |
Le statut 100 Continue est souvent utilisé conjointement avec l'en-tête de requête Expect: 100-continue. Lorsqu'un client envoie cet en-tête, il attend une confirmation avant d'envoyer une charge utile importante. Cela évite le gaspillage de bande passante lorsque le serveur va rejeter la requête sur la base des seuls en-têtes.
Le 101 Switching Protocols est la pierre angulaire des connexions WebSocket. Lorsqu'un client envoie un en-tête Upgrade: websocket, le serveur répond avec 101 pour confirmer le changement de protocole de HTTP vers WebSocket, permettant une communication bidirectionnelle en temps réel.
Le 103 Early Hints est une addition relativement récente (RFC 8297) qui permet aux serveurs d'envoyer des indices au navigateur sur les ressources critiques (CSS, JavaScript, polices) qui seront nécessaires par la réponse finale. Cela permet au navigateur de commencer à précharger ces ressources avant que la réponse complète ne soit prête, améliorant les performances perçues.
2xx - Succès
Ces codes indiquent que la requête du client a été reçue, comprise et acceptée avec succès. C'est la catégorie que tout développeur espère voir.
| Code | Nom | Description |
|---|---|---|
| 200 | OK | Réponse standard de succès pour les requêtes GET, POST, PUT |
| 201 | Créé | Ressource créée avec succès, généralement en réponse à POST |
| 202 | Accepté | Requête acceptée pour traitement mais pas encore terminée |
| 203 | Info Non Officielle | Réponse d'une source tierce, pas du serveur d'origine |
| 204 | Pas de Contenu | Succès, mais aucun corps de réponse à retourner |
| 205 | Réinitialiser le Contenu | Dit au navigateur d'effacer le formulaire/document actuel |
| 206 | Contenu Partiel | Ressource partielle retournée, utilisée pour les requêtes de plage et téléchargements repris |
| 207 | Multi-Statut | Codes de statut multiples pour ressources multiples (WebDAV) |
| 208 | Déjà Signalé | Ressource déjà signalée (WebDAV) |
Le 200 OK est le code de statut le plus courant. Il indique que la requête a réussi et que le corps de la réponse contient les données demandées. Pour les requêtes GET, le corps contient la représentation de la ressource. Pour les requêtes POST, il contient le résultat de l'action.
Le 201 Created devrait être retourné lorsqu'une nouvelle ressource est créée à la suite d'une requête POST ou PUT. La réponse devrait inclure un en-tête Location pointant vers l'URL de la ressource nouvellement créée. Par exemple, après la création d'un nouvel utilisateur, retournez 201 Created avec l'URL du profil utilisateur dans l'en-tête Location.
Le 204 No Content est utile pour les requêtes DELETE ou les mises à jour PUT où le corps de la réponse est vide. Il indique au client que l'opération a réussi mais qu'il n'y a rien à retourner. Le navigateur ne devrait pas changer sa vue de document actuelle.
3xx - Redirection
Ces codes indiquent que le client doit entreprendre une action supplémentaire pour compléter la requête, généralement en suivant une redirection vers une URL différente.
| Code | Nom | Description |
|---|---|---|
| 300 | Choix Multiples | Représentations multiples possibles, le client doit choisir |
| 301 | Déplacé de Façon Permanente | La ressource a une nouvelle URL permanente, mettre à jour les favoris |
| 302 | Trouvé | Redirection temporaire, continuer à utiliser l'URL originale à l'avenir |
| 303 | Voir Autre | Rediriger vers une URL différente en utilisant la méthode GET |
| 304 | Non Modifié | Ressource non modifiée, utiliser la version en cache |
| 307 | Redirection Temporaire | Redirection temporaire préservant la méthode HTTP |
| 308 | Redirection Permanente | Redirection permanente préservant la méthode HTTP |
La distinction entre 301 et 302 est critique pour le SEO. Les moteurs de recherche traitent les redirections 301 comme permanentes, transférant la puissance de classement de l'URL originale vers la nouvelle URL. Une redirection 302 ne transfère pas la valeur SEO car l'URL originale est censée revenir.
Le 304 Not Modified est utilisé conjointement avec des en-têtes de requête conditionnelle comme If-Modified-Since ou If-None-Match (ETags). Lorsque le client a une version en cache d'une ressource, il peut demander au serveur si la ressource a changé. Si ce n'est pas le cas, le serveur retourne 304 sans corps, économisant la bande passante des deux côtés.
Les codes 307 et 308 préservent la méthode HTTP utilisée dans la requête originale, contrairement à 302 et 301 qui peuvent changer POST en GET. Cette distinction est importante pour les points de terminaison API où la préservation de la méthode de requête est cruciale.
4xx - Erreur Client
Ces codes indiquent que le client a envoyé une requête problématique. L'erreur est du côté client — le serveur fonctionne correctement.
| Code | Nom | Description |
|---|---|---|
| 400 | Mauvaise Requête | Syntaxe ou paramètres de requête invalides |
| 401 | Non Autorisé | L'authentification est requise ou a échoué |
| 402 | Paiement Requis | Réservé pour utilisation future, rarement implémenté |
| 403 | Interdit | Client authentifié mais n'a pas la permission |
| 404 | Non Trouvé | La ressource demandée n'existe pas |
| 405 | Méthode Non Autorisée | La méthode HTTP n'est pas supportée pour cette URL |
| 406 | Non Acceptable | Impossible de générer une réponse correspondant aux en-têtes Accept |
| 407 | Authentification Proxy | Doit d'abord s'authentifier auprès du proxy |
| 408 | Délai de Requête Expiré | Le serveur a expiré en attendant la requête |
| 409 | Conflit | La requête entre en conflit avec l'état actuel du serveur |
| 410 | Parti | Ressource supprimée définitivement, pas d'adresse de transfert |
| 411 | Longueur Requise | L'en-tête Content-Length est requis |
| 412 | Condition Préalable Échouée | Les en-têtes de requête conditionnelle ont été évalués à faux |
| 413 | Charge Utile Trop Grande | Le corps de la requête dépasse les limites du serveur |
| 414 | URI Trop Long | L'URL dépasse la longueur maximale autorisée par le serveur |
| 415 | Type Média Non Supporté | Content-Type non supporté par le serveur |
| 416 | Plage Non Satisfaisable | L'en-tête Range ne peut pas être satisfait |
| 417 | Attente Échouée | L'en-tête Expect ne peut pas être satisfait |
| 422 | Entité Non Traitable | Corps de requête syntaxiquement correct mais sémantiquement invalide |
| 423 | Verrouillé | La ressource est verrouillée (WebDAV) |
| 424 | Dépendance Échouée | Requête échouée car une autre requête a échoué (WebDAV) |
| 426 | Mise à Niveau Requise | Le client devrait passer à un protocole différent |
| 428 | Condition Préalable Requise | Le serveur d'origine exige que la requête soit conditionnelle |
| 429 | Trop de Requêtes | Le client a dépassé les limites de débit |
| 431 | En-tête de Requête Trop Grand | Les en-têtes dépassent la taille maximale |
| 451 | Indisponible pour Raisons Légales | Ressource bloquée en raison d'exigences légales |
Le 400 Bad Request est le fourre-tout des erreurs client. Utilisez-le lorsque le serveur ne peut pas traiter la requête en raison d'une syntaxe malformée, de paramètres de requête invalides ou d'un corps de requête malformé. Incluez toujours un message d'erreur descriptif dans le corps de la réponse pour aider les clients à résoudre le problème.
Le 401 Unauthorized est retourné lorsque le client n'a pas fourni de justificatifs d'authentification valides. La réponse devrait inclure un en-tête WWW-Authenticate indiquant le schéma d'authentification (Basic, Bearer, Digest, etc.) attendu par le serveur.
Le 403 Forbidden diffère du 401 en ce que le client est authentifié mais ne dispose pas des permissions suffisantes. Par exemple, un utilisateur normal essayant d'accéder à un point de terminaison administrateur devrait obtenir 403, pas 401.
Le 404 Not Found est le code de statut HTTP le plus connu. Il indique que le serveur ne peut pas trouver la ressource demandée. Attention à ne pas révéler si la ressource existe mais est cachée — retourner 404 pour les ressources inexistantes et interdites est une pratique de sécurité courante.
Le 409 Conflict est utile pour les API REST en cas de conflit de version. Par exemple, lorsqu'une requête PUT met à jour une ressource qui a été modifiée par un autre utilisateur depuis que le client l'a récupérée.
Le 429 Too Many Requests est essentiel pour la limitation de débit des API. Il devrait inclure un en-tête Retry-After indiquant combien de temps le client devrait attendre avant de faire une autre requête.
5xx - Erreur Serveur
Ces codes indiquent que le serveur a rencontré une erreur lors du traitement d'une requête valide. Le problème est du côté serveur.
| Code | Nom | Description |
|---|---|---|
| 500 | Erreur Interne du Serveur | Erreur serveur générique, aucun détail spécifique disponible |
| 501 | Non Implémenté | Le serveur ne supporte pas la fonctionnalité demandée |
| 502 | Mauvaise Passerelle | Le serveur amont a retourné une réponse invalide |
| 503 | Service Indisponible | Serveur temporairement indisponible (surchargé ou en panne) |
| 504 | Délai de Passerelle Expiré | Le serveur amont n'a pas répondu à temps |
| 505 | Version HTTP Non Supportée | Le serveur ne supporte pas la version du protocole HTTP utilisée |
| 506 | Variante Aussi en Négociation | Erreur de configuration du serveur dans la négociation de contenu |
| 507 | Stockage Insuffisant | Le serveur ne peut pas stocker la représentation (WebDAV) |
| 508 | Boucle Détectée | Le serveur a détecté une boucle infinie (WebDAV) |
| 509 | Limite de Bande Passante Dépassée | Pas un statut officiel, utilisé par certains modules Apache |
| 510 | Non Étendu | Des extensions supplémentaires sont requises pour la requête |
| 511 | Authentification Réseau Requise | Le client doit s'authentifier pour accéder au réseau |
Le 500 Internal Server Error est le fourre-tout des défaillances côté serveur. Il ne devrait jamais être retourné pour des requêtes client invalides — celles-ci devraient utiliser les codes 4xx. Une réponse 500 indique que quelque chose s'est mal passé dans la logique de traitement du serveur.
Le 502 Bad Gateway se produit typiquement lorsqu'un proxy ou un équilibreur de charge reçoit une réponse invalide d'un serveur amont. Par exemple, si un serveur d'application plante ou retourne une réponse malformée, le proxy inverse retourne 502 au client.
Le 503 Service Unavailable est utilisé lorsque le serveur est temporairement surchargé ou en maintenance. Incluez un en-tête Retry-After pour que les clients et robots sachent quand réessayer. On le voit couramment pendant les fenêtres de déploiement ou les pics de trafic.
Le 504 Gateway Timeout se produit lorsqu'un serveur dans une chaîne (par exemple, un proxy inverse parlant à un serveur d'application) ne reçoit pas de réponse en temps opportun d'un autre serveur. Le délai d'expiration par défaut est généralement de 30 à 120 secondes selon l'infrastructure.
Guide d'Utilisation des Codes de Statut
| Scénario | Code de Statut |
|---|---|
| Requête GET réussie | 200 |
| POST réussi (création) | 201 |
| DELETE réussi | 204 |
| Échec de validation de formulaire | 422 |
| Utilisateur non connecté | 401 |
| L'utilisateur manque de permission | 403 |
| Ressource non trouvée | 404 |
| Limite de débit dépassée | 429 |
| Plantage serveur | 500 |
| Point de terminaison API non encore implémenté | 501 |
| Maintenance temporaire | 503 |
Meilleures Pratiques pour l'Utilisation des Codes de Statut HTTP
Utilisez toujours le code de statut le plus spécifique qui s'applique à votre situation. Retourner une erreur 500 générique quand un 503 ou 504 est plus approprié rend le débogage plus difficile pour les consommateurs d'API. Incluez des messages d'erreur descriptifs et des identifiants d'erreur uniques dans vos corps de réponse pour faciliter le débogage. Pour les API REST, envisagez également d'inclure un code d'erreur lisible par machine que les clients peuvent traiter programmatiquement. Enfin, assurez-vous que vos réponses d'erreur respectent le type de contenu demandé via la négociation de contenu — retournez JSON pour les clients API et HTML pour les pages d'erreur basées sur navigateur.
Utilisez l'outil Référence des Codes de Statut HTTP pour des consultations rapides chaque fois que vous avez besoin de vous rappeler la signification ou l'utilisation appropriée d'un code de statut HTTP.
