La méthode, le code de statut et les en-têtes sont trois des signaux les plus utiles des requêtes et réponses HTTP. Leur examen permet souvent de comprendre une grande partie d’un problème avant même de lire le corps.
Les débutants se concentrent souvent sur les données : réception du JSON, présence ou absence d’un champ. C’est utile, mais il faut d’abord comprendre l’intention du client, son interprétation par le serveur et le contexte technique de la requête. Méthode, statut et en-têtes donnent ces informations.
Savoir les interpréter avec assurance accélère nettement l’analyse des défauts.
Méthode
La méthode HTTP exprime l’intention du client : ce qu’il cherche à faire, pas le résultat obtenu.
- →GET — récupérer des données.
- →POST — créer une entité ou déclencher une action.
- →PUT — remplacer entièrement une ressource.
- →PATCH — modifier une partie d’une ressource.
- →DELETE — supprimer une ressource ou la rendre inactive.
Les équipes n’utilisent pas toujours les méthodes parfaitement ; tenez-en compte tout en comprenant leur sens. Si un GET provoque un changement de données, il faut l’examiner. Créer une entité via GET enfreint les conventions API et les attentes relatives au cache, à la répétition et à l’absence d’effets de modification.
L’idempotence est aussi essentielle. Certaines méthodes peuvent être répétées sans modifier le résultat voulu, d’autres non. Cela compte pour les nouvelles tentatives, clics répétés, réseaux instables et tests automatiques. Envoyer accidentellement deux fois une requête peut avoir des conséquences différentes avec POST et PUT ; prévoyez-le dans les tests.
Code de statut
Le code de statut résume techniquement le traitement d’une requête. Il n’explique pas tout, mais indique immédiatement la catégorie du résultat.
- →1xx — information technique intermédiaire.
- →2xx — requête traitée avec succès.
- →3xx — redirection ou étape supplémentaire nécessaire.
- →4xx — problème de requête, de données ou d’accès du client.
- →5xx — erreur côté serveur.
Ces catégories donnent une première lecture de la situation. Un testeur expérimenté va plus loin et connaît les codes individuels courants.
- →200 OK — requête réussie.
- →201 Created — entité créée.
- →204 No Content — opération réussie sans corps de réponse.
- →301 / 302 / 307 / 308 — redirections.
- →400 Bad Request — le serveur refuse la requête sous sa forme actuelle.
- →401 Unauthorized — le client n’est pas correctement authentifié.
- →403 Forbidden — le client est reconnu mais n’a pas le droit d’accès.
- →404 Not Found — ressource introuvable.
- →409 Conflict — conflit d’état.
- →422 Unprocessable Content — structure valide, mais sens métier ou données non conformes à la validation.
- →500 Internal Server Error — erreur interne du serveur.
- →502, 503, 504 — problèmes entre services, de surcharge ou de disponibilité.
L’objectif est de comprendre comment les codes orientent l’analyse, pas de mémoriser tout le tableau.
Par exemple, 401 et 403 n’ont pas le même sens. Un 404 peut indiquer une URL inexistante ou une entité inexistante. Un 200 ne garantit pas la justesse métier. Un 500 ne localise pas exactement l’échec, mais indique vite que le problème dépasse le formulaire frontend.
Pourquoi 200 OK garantit peu de choses à lui seul
L’un des pièges courants consiste à supposer qu’une réponse API 200 signifie que tout va bien. Elle peut encore :
- →Renvoyer des données incorrectes.
- →Renvoyer une liste vide à la place d’un objet attendu.
- →Cacher une erreur métier dans un champ error.
- →N’exécuter qu’une partie de l’opération.
- →Renvoyer des données périmées depuis un cache.
Interprétez donc toujours le statut avec le corps de réponse et le contexte du scénario. Un succès technique n’implique pas forcément un comportement produit correct.
En-têtes
Les en-têtes apportent du contexte aux requêtes et aux réponses. Ils paraissent souvent secondaires jusqu’à l’analyse de problèmes réels.
- →Type de données (Content-Type).
- →Format de réponse attendu (Accept).
- →Autorisation (Authorization).
- →Cookies.
- →Langue ou paramètres régionaux.
- →Cache (Cache-Control, ETag, If-None-Match).
- →Identifiants de corrélation.
- →Politiques CORS.
- →Politiques de sécurité.
Les en-têtes sont importants en QA, car ils expliquent souvent des bugs apparemment « étranges ».
- →Le backend attend application/json, mais le client envoie un autre Content-Type.
- →Un jeton existe, mais a été placé dans le mauvais en-tête.
- →Un cookie n’est pas arrivé ou n’a pas été enregistré.
- →Le cache a renvoyé une ancienne version des données.
- →Le navigateur a bloqué une requête à cause de CORS.
- →Un reverse proxy a réécrit certains en-têtes.
- →La requête indique une langue, mais la réponse en utilise une autre.
Les en-têtes sont une partie essentielle du protocole : ils transportent un contexte indispensable. Sans lui, une requête peut être techniquement valide mais logiquement incorrecte.
Utilité pratique en QA
Prenons un bug : l’utilisateur ne peut pas enregistrer son profil.
L’UI ne montre qu’un message d’erreur. Les signaux HTTP peuvent révéler des situations très différentes :
- →Une requête PATCH a été envoyée, mais le serveur renvoie 400 pour un champ invalide.
- →La requête utilise POST alors que le backend attend PATCH.
- →Le serveur renvoie 403, car le rôle ne possède pas la permission requise.
- →Le client envoie un mauvais Content-Type.
- →L’opération réussit, mais le frontend ne sait pas traiter 204 No Content.
- →La requête réussit, mais le cache ou un rechargement affiche d’anciennes données.
Toutes ces situations peuvent ressembler au même bug « le profil ne s’enregistre pas ». Pour l’équipe, ce sont six catégories de problèmes. Méthode, statut et en-têtes indiquent où chercher.
Ce que les testeurs QA doivent vérifier
- →La méthode utilisée.
- →L’URL appelée.
- →Les principaux en-têtes envoyés.
- →Le code de statut reçu.
- →Les en-têtes reçus.
- →La cohérence du corps avec le sens du scénario.
Avec une méthode systématique, les journaux réseau cessent d’être du « bruit » et révèlent une structure claire.
Points essentiels pour les testeurs QA
- →La méthode exprime l’intention du client.
- →Le code de statut indique le résultat technique du traitement.
- →Les en-têtes transportent le contexte essentiel des requêtes et réponses.
- →200 OK ne garantit pas la bonne réalisation d’un scénario métier.
- →De nombreux défauts sont plus faciles à localiser en interprétant ensemble méthode, statut et en-têtes.
Lectures complémentaires
- →Dans cette base de connaissances : HTTP et HTTPS
- →Dans cette base de connaissances : authentification et autorisation
- →Ressource externe : Codes de statut des réponses HTTP sur MDN