Codes de statut HTTP : le guide complet de tous les codes de réponse

Toute réponse HTTP commence par un nombre à trois chiffres, et ce nombre est la façon la plus brève pour le serveur de vous dire ce qui est arrivé à votre requête. La plupart du temps vous ne le voyez pas : la page se charge et le navigateur passe à la suite. Le nombre ne devient visible que lorsque quelque chose ne va pas, c’est-à-dire précisément quand vous avez besoin de savoir ce qu’il signifie.

Les codes de statut ne sont pourtant pas de simples diagnostics : ce sont des instructions. Un 301 demande à un moteur de recherche de déplacer définitivement son entrée d’index ; un 429 indique à un client exactement comment ralentir ; un 503 dit à un robot de revenir plus tard au lieu de retirer votre page. Renvoyer le mauvais code est l’une des manières les plus discrètes de perdre du trafic, car rien ne casse visiblement. Ce guide parcourt chaque classe, les codes que vous rencontrerez vraiment, et la manière de vérifier ce qu’une URL renvoie réellement.

Pourquoi les codes de statut comptent

Quatre publics lisent vos codes de statut, et chacun agit différemment :

• Les navigateurs. Ils décident de suivre ou non une redirection, de réutiliser une copie en cache, et de renvoyer ou non le corps d’un formulaire.
• Les moteurs de recherche. Le code décide si une URL est indexée, fusionnée avec une autre, réessayée plus tard ou abandonnée. Servir une jolie page « introuvable » avec un 200 est l’erreur classique : on dit au robot que la page existe et il la garde dans l’index.
• Les clients d’API. Un client bien écrit se branche sur le code. Un 429 ou un 503 méritent une nouvelle tentative ; un 400 jamais, car réessayer une requête mal formée produit la même erreur.
• Votre propre supervision. Les taux d’erreur et les alertes reposent presque toujours sur les codes de statut : un service qui renvoie 200 avec une erreur dans le corps est invisible pour ses propres tableaux de bord.

Les cinq classes

Le premier chiffre indique à qui incombe la responsabilité et quoi faire ensuite. Si vous ne retenez rien d’autre, retenez ce tableau.

La séparation entre 4xx et 5xx est celle qui compte le plus en pratique, car elle répond à la seule question qui vaille pendant un incident : est-ce à moi de le corriger, ou à eux ?

Les codes que vous rencontrerez vraiment

Il existe des dizaines de codes enregistrés, mais une journée de travail en implique peut-être quinze. Les codes de succès sont les plus simples. 200 OK est la réponse ordinaire. 201 Created est la bonne réponse à un POST qui a créé quelque chose, et il devrait porter un en-tête Location pointant vers la nouvelle ressource. 204 No Content dit que la requête a réussi et qu’il n’y a délibérément rien à renvoyer, ce qui est la bonne réponse à un DELETE. 206 Partial Content est ce qui permet la navigation dans une vidéo et la reprise de téléchargement.

Redirections : 301, 302, 307 et 308

Les redirections causent plus de dégâts SEO que toute autre classe, presque toujours parce que les formes permanente et temporaire sont inversées.

• 301 Moved Permanently : l’URL a changé définitivement. Les moteurs transfèrent les signaux de classement vers la nouvelle adresse et remplacent finalement l’ancienne dans leur index. À utiliser pour les migrations de domaine, le passage de HTTP à HTTPS et l’ajout ou le retrait du www.
• 302 Found : temporaire. L’ancienne URL reste indexée puisque vous avez annoncé son retour. À utiliser pour les tests A/B, les courtes fenêtres de maintenance et un routage géographique que vous comptez annuler.
• 307 Temporary Redirect : comme 302, mais la méthode et le corps sont garantis préservés. Un POST redirigé en 307 arrive en POST ; historiquement, certains clients transformaient un POST redirigé en GET.
• 308 Permanent Redirect : l’équivalent permanent du 307 : mêmes règles de cache que 301, avec la méthode préservée.
• 304 Not Modified : pas vraiment une redirection. Il répond à une requête conditionnelle et signifie « votre copie en cache est encore bonne », ce qui explique qu’un site bien configuré transfère bien moins de données que son poids ne le suggère.

Deux règles : n’enchaînez jamais des redirections quand un seul saut suffit, car chaque saut coûte de la latence et du budget d’exploration ; et ne redirigez jamais toutes les pages manquantes vers l’accueil. Cette seconde habitude paraît propre et raconte quelque chose de faux aux utilisateurs comme aux robots.

Erreurs client : 400, 401, 403, 404 et 429

La famille 4xx dit que le problème venait de la requête. Les distinctions méritent d’être justes, car les clients réagissent différemment à chacune.

• 400 Bad Request : syntaxe incorrecte : JSON cassé, champ obligatoire absent, paramètre impossible à analyser. Jamais réessayable tel quel.
• 401 Unauthorized : mal nommé ; il signifie non authentifié. Aucune identification, ou des identifiants que le serveur n’a pu vérifier. Il devrait inclure un en-tête WWW-Authenticate.
• 403 Forbidden : le serveur sait qui vous êtes et vous n’avez toujours pas le droit. Se réauthentifier n’y changera rien.
• 404 Not Found : rien n’existe à cette URL. Le serveur ne dit pas si cela a déjà existé.
• 405 Method Not Allowed : l’URL existe mais pas pour ce verbe. Ajoutez un en-tête Allow listant ceux qui fonctionnent.
• 409 Conflict : la requête entre en conflit avec l’état actuel, par exemple une clé en doublon ou une version périmée.
• 410 Gone : la ressource a existé et a été retirée volontairement. Les moteurs abandonnent un 410 plus vite qu’un 404 : c’est le meilleur choix quand vous avez retiré du contenu exprès.
• 422 Unprocessable Content : la syntaxe est analysable mais les valeurs échouent à la validation. Utile pour distinguer « je ne peux pas lire ceci » de « je l’ai lu et c’est faux ».
• 429 Too Many Requests : vous avez dépassé une limite de débit. Accompagnez-le toujours d’un en-tête Retry-After ; sans lui, les clients réessaient immédiatement et aggravent la surcharge.

Erreurs serveur : 500, 502, 503 et 504

Un 5xx signifie que votre requête était raisonnable et que le serveur a échoué quand même. Les quatre codes courants désignent des couches différentes, ce qui les rend vraiment utiles pendant un incident.

• 500 Internal Server Error : une exception non gérée dans l’application. Le fourre-tout générique, et la première chose à chercher dans les journaux.
• 502 Bad Gateway : un proxy ou un répartiteur de charge a reçu une réponse vide ou invalide en amont. Généralement, l’application derrière le proxy a planté ou n’écoutait pas.
• 503 Service Unavailable : le serveur est surchargé ou en maintenance. C’est le seul code de la famille à renvoyer délibérément, avec un en-tête Retry-After, pendant une interruption planifiée : les robots conservent la page et reviennent.
• 504 Gateway Timeout : le proxy a attendu l’amont et a renoncé. Cela désigne une dépendance lente plutôt qu’un plantage.

Pendant une panne, la différence entre 502 et 504 vous dit si votre application est morte ou seulement devenue lente, ce qui est souvent l’indice le plus rapide disponible.

Codes de statut et SEO

Les moteurs considèrent le code de statut comme la déclaration faisant autorité sur une URL, et ils lui font plus confiance qu’à n’importe quel contenu de la page. Quatre conséquences en découlent :

1. Les « soft 404 » gaspillent le budget d’exploration. Un message « page introuvable » servi avec un 200 maintient une URL morte dans l’index, en concurrence avec vos vraies pages. Renvoyez un vrai 404 ou 410.
2. Utilisez 301 pour un déplacement définitif. Un 302 sur un vrai déplacement laisse l’ancienne URL indexée et partage les signaux entre deux adresses.
3. Gardez les chaînes de redirection courtes. Chaque saut ajoute de la latence et les robots n’en suivent qu’un nombre limité avant d’abandonner. Faites pointer l’ancienne URL directement vers la destination finale.
4. Renvoyez 503 pendant la maintenance. Un 503 avec Retry-After dit au robot de revenir. Un délai dépassé ou un 500 ressemble à un site cassé.

Les redirections interagissent aussi avec HTTPS. Si votre redirection de http:// vers https:// est en place mais que le certificat est invalide ou expiré, les visiteurs voient un avertissement du navigateur avant que la redirection n’ait d’importance : il vaut donc la peine de vérifier le certificat avec le vérificateur de certificats SSL en même temps.

Comment vérifier un code de statut

Votre navigateur masque le code quand le chargement réussit : il faut donc le demander explicitement. Trois méthodes fiables :

1. Le panneau réseau du navigateur. Ouvrez les outils de développement, rechargez et lisez la colonne Statut. Cette vue montre toute la chaîne de redirections, ce qu’un seul nombre ne peut pas faire.
2. curl -I https://example.com. Une requête HEAD affiche la ligne de statut et les en-têtes sans télécharger le corps. Ajoutez -L pour suivre les redirections et voir chaque saut.
3. Une référence consultable. Quand vous avez le nombre et qu’il vous faut la signification, les obligations et les causes typiques, notre référence des codes de statut HTTP liste chaque code et la conduite à tenir.

Deux points à vérifier au-delà du nombre lui-même. D’abord, testez l’URL exacte qu’un utilisateur atteindrait, avec ou sans barre oblique finale, car les deux se résolvent souvent différemment. Ensuite, si la réponse est un 429, lisez la valeur de Retry-After et vérifiez que l’attente de votre client la respecte vraiment ; le calculateur de limite de débit transforme une limite en intervalles concrets.

Erreurs courantes à éviter

• Renvoyer 200 avec une erreur dans le corps. La supervision, les caches, les robots et les clients lisent le code, pas votre JSON. C’est l’erreur la plus lourde de conséquences de la liste.
• Utiliser 302 pour un déplacement définitif. Les signaux de classement restent sur l’ancienne URL, parfois pendant des mois.
• Rediriger tous les 404 vers l’accueil. Cela vous cache les liens cassés et produit des « soft 404 » pour les robots.
• 403 là où 401 convient. Un client qui reçoit 403 n’essaiera pas de s’authentifier, puisque 403 dit que l’authentification n’est pas le problème.
• 429 sans Retry-After. Les clients devinent, en général en réessayant aussitôt, ce qui est exactement le comportement que la limite doit empêcher.
• Laisser la maintenance renvoyer un délai dépassé. Renvoyez 503 avec Retry-After pour conserver vos entrées d’index.
• De longues chaînes de redirection après une migration. Chaque migration ajoute un saut ; réduisez-les à un seul la prochaine fois que vous toucherez aux règles.

Vérifiez vos propres codes

Les codes de statut sont le diagnostic le moins coûteux du web : un nombre, aucune authentification, et une réponse sans ambiguïté sur le fait qu’une URL fonctionne, a été déplacée ou a échoué. Commencez par vérifier ce que renvoient vos pages importantes, confirmez que vos redirections sont permanentes là où elles doivent l’être et temporaires là où il le faut, et assurez-vous que chaque chemin d’erreur renvoie un code conforme à ce qui s’est réellement produit.

Outils et guides associés :

• Codes de statut HTTP : référence consultable de tous les codes de réponse.
• Calculateur de limite de débit : transforme une limite en intervalles sûrs et en Retry-After.
• Recherche DNS : vérifiez qu’un domaine se résout avant de déboguer ses réponses.
• Vérificateur de certificats SSL : contrôlez le certificat derrière votre redirection HTTPS.
• Redirections 301 et 302 : laquelle choisir et ce que voit le SEO - quelle redirection utiliser et ce que chacune change pour votre classement.
• 404 ou 410 : ce que chacun dit à Google d’une page supprimée - ce que chaque code indique à Google sur une page supprimée.

Questions fréquentes