202 Accepted signifie que le serveur a accepté la requête, mais ne l’a pas encore menée à bien, et ne le fera peut-être jamais. HTTP n’offre aucun moyen de communiquer plus tard le résultat d’un traitement en arrière-plan : le code 202 est donc volontairement non engageant.
Il sert aux traitements par lots, aux exports, au transcodage vidéo, aux files de messages et à tout autre travail exécuté en arrière-plan. Une bonne réponse 202 indique au client comment suivre la suite : une URL où consulter l’état du traitement (dans le corps ou dans un en-tête Location) et une estimation de sa fin, parfois avec Retry-After.
Les clients considèrent le code 202 comme un succès. Les émetteurs de webhooks, par exemple, l’acceptent comme n’importe quel code 2xx pour confirmer qu’un événement a bien été reçu.
Exemple de réponse
HTTP/1.1 202 Accepted
Date: Fri, 06 Nov 2026 10:15:32 GMT
Location: https://api.example.com/v1/exports/3f9c
Retry-After: 30
Content-Type: application/json
Content-Length: 31
{"id":"3f9c","status":"queued"}SEO et vérification des redirections
Le code 202 n’a pas sa place sur des pages destinées aux moteurs de recherche. Les robots d’exploration le considèrent comme un succès, mais il n’y a généralement rien à indexer. Les balises de mesure d’audience (beacons) et les points de terminaison de suivi renvoient souvent 202 ou 204, ce qui ne pose aucun problème puisqu’ils ne sont pas explorés comme des pages.
Causes fréquentes et cas d’usage
- Une API a mis en file d’attente une tâche longue et renvoie une URL permettant d’interroger son état.
- Un récepteur de webhooks accuse immédiatement réception d’un événement et le traite plus tard.
- Un point de terminaison de journalisation ou de mesure d’audience accepte des données sans confirmer leur enregistrement.