Quel est le code de statut HTTP le plus courant ?

200 OK est de loin le plus fréquent — il signifie que la requête a réussi. Côté erreurs, 404 Not Found est probablement le plus connu, suivi de 500 Internal Server Error.

Quelle est la différence entre 401 et 403 ?

401 Unauthorized signifie que vous n'êtes pas authentifié — le serveur ne sait pas qui vous êtes. 403 Forbidden signifie que le serveur vous connaît mais refuse l'accès. Pensez au 401 comme 'Qui êtes-vous ?' et au 403 comme 'Je sais qui vous êtes, mais non.'

Faut-il utiliser 301 ou 302 pour les redirections ?

Utilisez 301 Moved Permanently pour les changements d'URL permanents — il transfère la valeur SEO vers la nouvelle URL. Utilisez 302 Found pour les redirections temporaires, comme les tests A/B ou les pages de maintenance.

Que signifie un code de statut 429 ?

429 Too Many Requests signifie que vous avez atteint une limite de débit. La réponse inclut généralement un en-tête Retry-After indiquant quand réessayer. C'est courant avec les APIs qui ont des quotas de requêtes.

Pourquoi mon API retourne-t-elle des erreurs 500 de manière aléatoire ?

Les erreurs 500 intermittentes pointent souvent vers des exceptions non gérées, des conditions de course ou des problèmes de base de données intermittents. Vérifiez les logs serveur, ajoutez des limites d'erreur, et cherchez des patterns dans les occurrences.

Codes de statut HTTP : Le guide complet du développeur (2026) (2026)

Les codes de statut HTTP ne sont pas que du bachotage

Chaque réponse HTTP porte un code de statut à trois chiffres. La plupart des développeurs les connaissent jusqu'à un certain point — 200 ça marche, 404 c'est introuvable, 500 ça plante. Mais le tableau complet est plus intéressant et plus utile que ça.

Maîtriser les codes de statut HTTP signifie écrire de meilleures APIs, déboguer plus vite, et prendre des décisions plus éclairées sur les redirections, le cache et la gestion des erreurs. Ce guide est une référence pratique, pas un copier-coller de RFC.

Pour une référence rapide pendant que vous travaillez, l'outil HTTP Status Codes permet de rechercher instantanément n'importe quel code.

Les cinq catégories : un modèle mental

Les codes de statut HTTP sont regroupés en cinq classes. Le premier chiffre indique la catégorie :

Plage	Catégorie	En un mot
1xx	Informationnel	« Patience, je travaille... »
2xx	Succès	« Voilà. »
3xx	Redirection	« C'est par là. »
4xx	Erreur client	« Vous avez fait une erreur. »
5xx	Erreur serveur	« C'est de notre faute. »

Cette taxonomie vaut la peine d'être intégrée. Face à un code inconnu, le premier chiffre vous dit immédiatement si le problème est dans la requête ou sur le serveur.

2xx : Codes de succès

Ce sont les codes que l'on veut voir. Mais ils ne sont pas tous identiques.

200 OK

Le succès par défaut. La requête a fonctionné, voici le corps de la réponse. Pour les requêtes GET, et généralement pour POST/PUT quand vous retournez la ressource mise à jour.

201 Created

Utilisé quand une ressource est créée avec succès — typiquement en réponse à un POST. La bonne pratique est d'inclure un en-tête Location pointant vers la nouvelle ressource.

curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Marie Dupont", "email": "marie@exemple.fr"}'
# HTTP/2 201
# Location: /users/43

Beaucoup d'APIs retournent 200 pour tout. Ça marche, mais c'est paresseux. Retourner 201 avec un en-tête Location offre un contrat beaucoup plus clair aux développeurs clients.

204 No Content

La requête a réussi, mais il n'y a rien à retourner. Parfait pour les DELETE, ou PUT/PATCH quand vous n'avez pas besoin de renvoyer la ressource mise à jour.

Ne jamais inclure un corps avec 204. Si vous devez retourner des données après une suppression, utilisez 200 à la place.

3xx : Redirections

C'est là que les développeurs commettent les erreurs les plus coûteuses — les implications SEO et cache sont faciles à négliger.

301 Moved Permanently

La ressource a été déplacée définitivement vers une nouvelle URL. Les navigateurs mettent cette redirection en cache indéfiniment. Les moteurs de recherche transfèrent la valeur des liens (PageRank) vers la nouvelle URL.

Attention : Une fois en cache, un 301 est très difficile à annuler. Les navigateurs peuvent le mettre en cache pendant des mois. Si vous n'êtes pas sûr à 100% que la redirection est permanente, utilisez 302.

302 Found

Redirection temporaire. Le navigateur la suit mais ne la met pas en cache de manière permanente. La valeur SEO reste sur l'URL d'origine. Idéal pour les tests A/B, les pages de maintenance, les redirections après connexion.

307 / 308

307 est la version préservant la méthode de 302 (temporaire), 308 la version préservant la méthode de 301 (permanent). Lors d'une redirection d'un POST, cela garantit que la méthode ne passe pas à GET.

304 Not Modified

Le client a envoyé un GET conditionnel et la version en cache est encore valide. Le serveur envoie uniquement le code, sans corps. C'est comme ça que le cache HTTP fonctionne efficacement.

4xx : Erreurs client

Le client a envoyé quelque chose d'incorrect. C'est ici que se passe la plupart du débogage d'API.

400 Bad Request

Un code fourre-tout pour les requêtes mal formées — champs obligatoires manquants, JSON invalide, erreurs de type. Soyez aussi précis que possible dans le corps de la réponse.

{
  "error": "validation_failed",
  "details": [
    { "field": "email", "message": "Doit être une adresse email valide" },
    { "field": "age", "message": "Doit être un entier positif" }
  ]
}

401 Unauthorized

La requête nécessite une authentification et le client ne l'a pas fournie, ou a fourni des identifiants invalides. Malgré son nom « Unauthorized », ce code concerne l'authentification, pas l'autorisation.

403 Forbidden

Le client est authentifié mais n'a pas la permission d'accéder à la ressource. Le serveur sait qui vous êtes — il refuse simplement l'accès.

Cette distinction est importante :

Accéder aux données privées de quelqu'un d'autre → 403
Accéder à l'API sans token → 401
Accéder à un endpoint non inclus dans l'abonnement → 403

404 Not Found

La ressource n'existe pas. Une nuance : certaines APIs retournent 404 quand l'utilisateur n'a pas la permission d'accéder à une ressource, pour éviter de révéler son existence. C'est légitime pour les ressources sensibles.

409 Conflict

La requête entre en conflit avec l'état actuel de la ressource. Cas classiques : créer un utilisateur avec un email déjà existant, ou échec de verrouillage optimiste.

422 Unprocessable Entity

La requête est syntaxiquement valide (JSON parsable, bon Content-Type) mais sémantiquement invalide — elle viole des règles métier. Beaucoup d'APIs modernes préfèrent 422 à 400 pour les erreurs de validation.

400 : « Je ne peux même pas parser ce que vous m'avez envoyé »
422 : « J'ai bien parsé, mais ça n'a pas de sens »

429 Too Many Requests

Vous avez atteint une limite de débit. La réponse devrait inclure Retry-After et les en-têtes X-RateLimit-*.

418 I'm a Teapot

Défini dans la RFC 2324 comme un poisson d'avril — le protocole de contrôle de cafetière hypertexte (HTCPCP). Le serveur refuse de préparer du café parce qu'il est une théière. Google retourne ce code pour certaines requêtes. Le standard le plus inutile et le plus adoré d'Internet.

5xx : Erreurs serveur

Quelque chose a mal tourné côté serveur. Le client n'a rien fait de mal.

500 Internal Server Error

Le code générique « quelque chose est cassé ». Signifie généralement une exception non gérée. Tout loguer, ne jamais exposer les stack traces brutes dans les réponses, alerter en production.

502 Bad Gateway

Le serveur agissait en tant que passerelle ou proxy et a reçu une réponse invalide du serveur amont. Courant avec nginx + Node.js quand le processus Node plante ou expire.

503 Service Unavailable

Le serveur est temporairement incapable de traiter la requête — surchargé ou en maintenance. Inclure un en-tête Retry-After.

504 Gateway Timeout

La passerelle n'a pas reçu de réponse en temps opportun du serveur amont. Symptôme classique de requêtes SQL lentes, d'APIs externes qui expirent, ou de fonctions Lambda atteignant leur limite d'exécution.

Codes de statut HTTP dans la conception d'API REST

Aide-mémoire pratique :

GET /users → 200 (liste)

GET /users/ → 200 (trouvé), 404 (introuvable), 403 (interdit)

POST /users → 201 (créé), 400/422 (erreur de validation), 409 (conflit)

PUT /users/ → 200 (mis à jour avec corps), 204 (mis à jour sans corps), 404, 409

DELETE /users/ → 204 (supprimé), 404 (introuvable)

La cohérence est essentielle

Les pires APIs sont les APIs incohérentes. Décidez si vous utilisez 400 ou 422 pour les erreurs de validation, si vous retournez la ressource après une mise à jour (200) ou non (204), et respectez cette convention partout.

Ne pas retourner 200 pour tout

Certaines APIs retournent {"success": false, "error": "not found"} avec HTTP 200. Ça casse les bibliothèques clientes, complique le monitoring et ignore un standard parfaitement bon. Utilisez les bons codes de statut.

Conclusion

Les codes de statut HTTP sont un protocole de communication entre les développeurs côté client et côté serveur. Les utiliser correctement est une forme de courtoisie professionnelle — ça facilite le travail de tout le monde, du développeur frontend qui consomme votre API à l'ingénieur d'astreinte qui débogue un incident en production à 2h du matin.

Marquez l'outil HTTP Status Codes en favori pour des recherches rapides pendant le développement.