Qu'y a-t-il dans une réponse HTTP ?

Mar 12, 2026 · 4 min read

Chaque fois que votre navigateur charge une page ou que votre JavaScript appelle fetch(), un serveur renvoie une réponse HTTP. Vous voyez le résultat — une page rendue, des données JSON, un message d’erreur — mais la réponse elle-même contient plus de structure que la plupart des développeurs n’y pensent consciemment. Comprendre cette structure vous donne un modèle mental plus clair lors du débogage dans les DevTools ou de la gestion des réponses dans le code.

Une réponse HTTP comporte trois parties : une ligne d’état, des en-têtes et un corps optionnel.

Points clés à retenir

Chaque réponse HTTP se compose de trois parties : une ligne d’état (ou pseudo-en-tête :status en HTTP/2 et HTTP/3), des en-têtes et un corps optionnel.
Les codes d’état sont regroupés par leur premier chiffre — 2xx pour le succès, 3xx pour la redirection, 4xx pour les erreurs client et 5xx pour les erreurs serveur.
Les en-têtes de réponse contrôlent la mise en cache, la sécurité, les cookies et l’interprétation du contenu — ils indiquent au navigateur comment traiter la charge utile, pas seulement ce qu’elle est.
Tous les en-têtes de réponse ne sont pas accessibles au JavaScript frontend dans les requêtes cross-origin. Les serveurs doivent utiliser Access-Control-Expose-Headers pour autoriser l’accès au-delà de l’ensemble par défaut sécurisé.

L’anatomie d’une réponse HTTP : état, en-têtes, corps

La ligne d’état

En HTTP/1.1, la réponse commence par une seule ligne d’état :

HTTP/1.1 200 OK

Cette ligne contient la version du protocole, un code d’état à trois chiffres et une phrase de raison lisible par l’humain. La phrase de raison est uniquement informative — c’est le code d’état sur lequel les navigateurs et les clients agissent réellement.

Les codes d’état HTTP sont regroupés par leur premier chiffre :

Plage	Signification
1xx	Informatif (requête reçue, traitement en cours)
2xx	Succès (200 OK, 201 Created, 204 No Content)
3xx	Redirection (301 Moved Permanently, 304 Not Modified)
4xx	Erreur client (400 Bad Request, 401 Unauthorized, 404 Not Found)
5xx	Erreur serveur (500 Internal Server Error, 503 Service Unavailable)

Une remarque sur HTTP/2 et HTTP/3 : La ligne d’état textuelle ci-dessus est spécifique au format de transmission HTTP/1.1. En HTTP/2 et HTTP/3, il n’y a pas de ligne d’état. Au lieu de cela, l’état est transmis via un pseudo-en-tête :status (par exemple, :status: 200). La sémantique est identique — le code d’état signifie la même chose — mais la représentation diffère. Les DevTools normalisent la représentation, vous verrez donc toujours le code d’état familier quelle que soit la version du protocole.

En-têtes de réponse HTTP : ce qu’ils font réellement

Les en-têtes de réponse sont des métadonnées. Ils indiquent au navigateur comment traiter la réponse, et non ce qu’est le contenu. Chaque en-tête est un nom insensible à la casse suivi de deux points et d’une valeur.

Voici les catégories que vous rencontrerez le plus souvent :

Métadonnées de contenu

Content-Type: application/json; charset=utf-8 — indique au navigateur dans quel format se trouve le corps et comment le décoder.
Content-Length: 1024 — la taille du corps en octets.

Mise en cache

Cache-Control: max-age=3600, public — indique au navigateur et aux CDN combien de temps mettre en cache la réponse.
ETag: "abc123" — une empreinte de la ressource, utilisée pour les requêtes conditionnelles. Si la ressource n’a pas changé, le serveur renvoie 304 Not Modified au lieu du corps complet.

Sécurité

Content-Security-Policy — restreint les sources à partir desquelles le navigateur peut charger des scripts, des styles et d’autres ressources.
Strict-Transport-Security — indique au navigateur de se connecter uniquement via HTTPS pendant une durée spécifiée.

Cookies

Set-Cookie: session=xyz; HttpOnly; Secure — demande au navigateur de stocker un cookie. Une seule réponse peut inclure plusieurs en-têtes Set-Cookie, un par cookie.

Une contrainte importante : tous les en-têtes de réponse ne sont pas accessibles au JavaScript frontend. Par défaut, l’API Fetch n’expose qu’un petit ensemble d’en-têtes « sûrs » à partir des réponses cross-origin. Les serveurs doivent explicitement lister les en-têtes supplémentaires dans Access-Control-Expose-Headers pour que votre JavaScript puisse les lire.

Le corps de la réponse

Le corps est la charge utile réelle — HTML, JSON, une image, un fichier. Toutes les réponses n’en ont pas. Une réponse 204 No Content ou 304 Not Modified omet intentionnellement le corps. Dans ces cas, le code d’état lui-même est le message.

L’en-tête Content-Type indique au navigateur comment interpréter ce qui arrive dans le corps.

Fonctionnalités moins courantes à connaître

Les réponses HTTP peuvent également inclure des réponses informatives comme 103 Early Hints, qui permet aux serveurs de suggérer des ressources à précharger avant l’arrivée de la réponse principale. Les trailers — en-têtes envoyés après le corps — existent en HTTP/1.1 (avec l’encodage de transfert fragmenté) et en HTTP/2 et HTTP/3 en tant qu’en-têtes de fin, mais sont rarement rencontrés dans le travail frontend quotidien. Ils valent la peine d’être connus, mais vous ne les verrez pas souvent dans les DevTools.

Conclusion

Considérez une réponse HTTP comme une enveloppe. Le code d’état vous indique si la livraison a réussi. Les en-têtes sont des instructions à l’extérieur — manipuler avec précaution, réfrigérer après ouverture, expire dans 24 heures. Le corps est ce qu’il y a à l’intérieur. Lorsque quelque chose ne fonctionne pas, vérifiez d’abord le code d’état, puis les en-têtes — ils vous disent généralement exactement ce qui s’est mal passé et quoi faire ensuite.

FAQ

Content-Length spécifie la taille exacte du corps de la réponse en octets. Transfer-Encoding, généralement défini sur chunked, signifie que le corps est envoyé par morceaux sans taille totale prédéterminée. En HTTP/1.1, une réponse utilise l'un ou l'autre. L'encodage fragmenté est courant pour le contenu généré dynamiquement lorsque le serveur ne connaît pas la taille finale à l'avance.

Pour les requêtes cross-origin, l'API Fetch n'expose par défaut qu'un ensemble limité d'en-têtes de réponse autorisés par CORS. Ceux-ci incluent Cache-Control, Content-Language, Content-Type, Expires, Last-Modified et Pragma. Pour accéder à tout autre en-tête depuis JavaScript, le serveur doit l'inclure dans l'en-tête de réponse Access-Control-Expose-Headers.

Utilisez 204 No Content lorsque le serveur traite avec succès une requête mais n'a pas de corps à renvoyer. C'est courant pour les opérations DELETE ou les soumissions de formulaires où le client n'a pas besoin de données mises à jour en réponse. Un 200 OK est plus approprié lorsque vous souhaitez renvoyer une charge utile de confirmation ou une ressource mise à jour au client.

Ouvrez les DevTools avec F12 ou Ctrl+Shift+I, allez dans l'onglet Réseau (Network) et cliquez sur n'importe quelle requête dans la liste. Le panneau En-têtes (Headers) affiche à la fois les en-têtes de requête et de réponse. Vous pouvez également filtrer par type de requête et rechercher des noms d'en-têtes spécifiques. L'onglet Réponse (Response) affiche le contenu brut du corps renvoyé par le serveur.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.