Référence3 min de lecture · Mis à jour le 21 oct. 2026

Codes HTTP et en-têtes — référence pour l'exploitation

Interpréter les codes HTTP côté exploitation (qui est en faute ?), les en-têtes utiles au diagnostic et les conventions d'API REST.

Qui est en faute ?

Code	Sens	Côté à investiguer
400	requête invalide	client (validation)
401	non authentifié	jeton absent/expiré
403	authentifié mais interdit	droits, WAF, CSRF
404	ressource absente	routage, URL, déploiement
409	conflit d'état	concurrence, doublon
422	sémantiquement invalide	règles métier
429	trop de requêtes	limitation de débit
500	erreur non gérée	application (journaux applicatifs)
502	réponse invalide de l'amont	le backend est arrêté ou plante
503	service indisponible	surcharge, maintenance, aucun backend sain
504	délai dépassé vers l'amont	backend trop lent, timeout proxy

Un 502 vu par l'utilisateur est généré par le proxy (NGINX, ALB) : regardez d'abord son journal d'erreurs, puis l'état du backend.

curl -sv -o /dev/null https://api.exemple.fr/v1/orders 2>&1 | grep -E '^[<>]'

X-Request-Id / traceparent : corrélation entre proxy, application et traces.
Retry-After : sur 429/503.
Cache-Control, ETag, Age : comprendre une réponse obsolète.
Server-Timing : décomposition du temps côté serveur.

Méthodes idempotentes : GET, PUT, DELETE — on peut les rejouer sans risque. POST ne l'est pas : prévoir une clé d'idempotence pour les paiements.

{ "statusCode": 422, "message": "La date de fin précède la date de début", "requestId": "b1f3…" }