Que sont les codes de statut HTTP ?
Les codes de statut HTTP sont les nombres à trois chiffres qu'un serveur renvoie avec chaque réponse pour indiquer au client ce qui s'est passé : la requête a abouti, la ressource a été déplacée, le client a commis une erreur ou le serveur a échoué. Ils sont définis dans la norme HTTP (RFC 9110) et constituent le moyen le plus rapide de comprendre pourquoi une page, un appel d'API ou une vérification de surveillance s'est comporté ainsi. Cet aide-mémoire couvre les codes que vous rencontrerez réellement en production, leur impact sur le SEO et l'uptime, et ceux qui méritent une alerte.
Les cinq classes de codes de statut HTTP
Le premier chiffre d'un code de statut définit sa classe. La classe vous indique immédiatement s'il s'agit d'un succès, d'une redirection, d'un problème côté client ou d'une défaillance du serveur.
Classes de codes de statut
Réponses informatives 1xx
Les codes 1xx sont des réponses intermédiaires envoyées avant la réponse finale. Les navigateurs et les bibliothèques HTTP les gèrent automatiquement ; ils apparaissent donc rarement dans les journaux ou les résultats de surveillance.
Continue
Le serveur a reçu les en-têtes de la requête et le client peut envoyer le corps. Utilisé avec l'en-tête Expect: 100-continue pour les envois volumineux.
Switching Protocols
Le serveur accepte de changer de protocole à la demande du client, le plus souvent pour passer une connexion en WebSocket.
Early Hints
Early Hints : le serveur envoie des en-têtes Link avant la réponse finale pour que le navigateur commence à précharger le CSS critique, les polices ou les scripts.
Réponses de succès 2xx
Les codes 2xx signifient que la requête a été reçue, comprise et acceptée. Pour la plupart des pages et des endpoints de health check, 200 est la réponse attendue ; toute autre réponse mérite un second regard.
OK
La requête a abouti et le corps de la réponse contient la ressource demandée. C'est la réponse normale pour les pages et les requêtes GET.
Created
La requête a abouti et a créé une nouvelle ressource, généralement après un POST vers une API. L'en-tête Location pointe en principe vers la nouvelle ressource.
No Content
La requête a abouti, mais il n'y a pas de corps à renvoyer. Courant pour les requêtes DELETE et les API qui se contentent de confirmer une action.
Partial Content
Le serveur ne renvoie qu'une partie de la ressource, car le client a envoyé un en-tête Range. Utilisé pour le streaming vidéo et les téléchargements reprenables.
Ce qu'il faut surveiller dans les réponses 2xx
- Un 200 ne prouve pas que la page fonctionne : une page d'erreur servie avec 200 apparaît comme « soft 404 » dans Google Search Console
- Vérifiez que les pages clés renvoient le contenu attendu, et pas seulement un code de succès
- Attendez-vous à 201 ou 204 de la part des endpoints d'écriture ; un 200 peut y signaler un changement d'API
- Un 206 ne devrait apparaître que là où vous servez réellement des requêtes partielles
Redirections 3xx
Les codes 3xx indiquent au client que la ressource se trouve ailleurs ou n'a pas changé. Choisir la bonne redirection compte pour le SEO : Google traite différemment les redirections permanentes et temporaires lorsqu'il décide quelle URL indexer.
Moved Permanently
Moved Permanently. La ressource a une nouvelle URL définitive. À utiliser pour les changements de domaine, les migrations HTTPS et les nouvelles structures d'URL. Les clients peuvent transformer un POST en GET en la suivant.
Found
Found. La ressource se trouve temporairement à une autre URL et l'originale doit rester indexée. À utiliser pour les déplacements courts, comme les pages de maintenance.
Not Modified
Not Modified. La copie en cache est toujours valide, le serveur n'envoie donc pas de corps. Signe que les requêtes conditionnelles et les en-têtes de cache fonctionnent.
Temporary Redirect
Temporary Redirect. Comme 302, mais le client doit répéter la requête avec la même méthode et le même corps : important pour les formulaires et les appels d'API.
Permanent Redirect
Permanent Redirect. Comme 301, mais la méthode et le corps ne doivent pas changer. Le choix sûr pour déplacer définitivement des endpoints d'API.
L'impact des redirections sur le SEO
- Google considère 301 et 308 comme un signal fort pour indexer l'URL cible, et 302 et 307 comme un signal faible (Google Search Central)
- Les robots de Google suivent par défaut jusqu'à 10 redirections, mais chaque étape ajoute de la latence : pointez vos liens directement vers l'URL finale
- Les boucles de redirection rendent une URL inaccessible aux utilisateurs comme aux robots
- Utilisez des redirections permanentes pour les déplacements définitifs ; un 302 qui dure envoie des signaux contradictoires
- Après une migration, vérifiez que les anciennes URL redirigent au lieu de renvoyer 404
Erreurs client 4xx
Les codes 4xx signifient que le serveur estime que le client a commis une erreur : une URL erronée, des identifiants manquants ou trop de requêtes. Ce sont les erreurs que les utilisateurs voient le plus souvent, et une hausse soudaine révèle généralement un lien cassé, un bug de déploiement ou un changement d'API.
Bad Request
Bad Request. Le serveur ne peut pas traiter la requête en raison d'une syntaxe incorrecte, d'un JSON invalide ou de paramètres manquants. Vérifiez la validation côté client et les payloads de l'API.
Unauthorized
Unauthorized. L'authentification est absente ou invalide. Normal sur les endpoints protégés ; une hausse peut signaler des jetons expirés ou des attaques par bourrage d'identifiants.
Forbidden
Forbidden. Le serveur a compris la requête mais la refuse, même avec des identifiants valides. Vérifiez les rôles, les permissions de fichiers et les règles du pare-feu et du CDN.
Not Found
Not Found. Le serveur ne trouve pas la ressource demandée. Généralement dû à des pages supprimées, à des fautes de frappe ou à des redirections manquantes.
Gone
Gone. La ressource a été supprimée volontairement et ne reviendra pas. Google traite 404 et 410 de la même façon : l'URL est retirée de l'index.
Too Many Requests
Too Many Requests. Le client a dépassé une limite de débit. L'en-tête Retry-After lui indique quand réessayer. Google traite le 429 comme une erreur serveur et ralentit l'exploration.
Ce qu'il faut surveiller dans les réponses 4xx
- Des 404 sur des pages qui fonctionnaient : il manque souvent une redirection après une mise en production ou une migration
- Des taux de 401/403 en hausse, qui peuvent signaler des identifiants expirés ou des règles d'accès mal configurées
- Des 400 après un déploiement, souvent le signe d'un changement d'API
- Des 429 qui touchent de vrais utilisateurs ou Googlebot : vos limites sont trop strictes
- Les URL indexées qui renvoient une erreur 4xx sont retirées de l'index de Google
Erreurs serveur 5xx
Les codes 5xx signifient que la requête était valide, mais que le serveur (ou un élément situé derrière lui) a échoué. Ce sont les erreurs qui rendent un site indisponible ; elles doivent donc toujours déclencher une alerte.
Internal Server Error
Internal Server Error. Une condition inattendue a empêché le serveur de traiter la requête : généralement une exception non gérée, une requête de base de données en échec ou une mauvaise configuration.
Bad Gateway
Bad Gateway. Un proxy, un répartiteur de charge ou un CDN a reçu une réponse invalide du serveur en amont. Vérifiez que l'application située derrière fonctionne et est joignable.
Service Unavailable
Service Unavailable. Le serveur ne peut temporairement pas traiter la requête en raison d'une surcharge ou d'une maintenance. Envoyez un en-tête Retry-After pendant les interruptions planifiées.
Gateway Timeout
Gateway Timeout. Un proxy ou une passerelle n'a pas reçu à temps la réponse du serveur en amont. Recherchez des requêtes lentes, des workers bloqués ou des problèmes réseau.
Ce qu'il faut surveiller dans les réponses 5xx
- Toute erreur 5xx sur la page d'accueil, la connexion, le paiement ou l'endpoint de health check exige une intervention immédiate
- Les 502 et 504 désignent généralement l'infrastructure entre l'utilisateur et votre application : proxys, répartiteurs de charge, CDN
- Un 503 lors des pics de trafic est un avertissement de capacité
- Des erreurs 5xx persistantes poussent Google à ralentir l'exploration et, à terme, à retirer des URL indexées (Google Search Central)
- Les erreurs 5xx intermittentes passent facilement inaperçues sans surveillance continue
Comment surveiller les codes de statut HTTP
Personne ne peut surveiller les journaux du serveur jour et nuit : automatisez-le. Un moniteur d'uptime interroge vos URL à intervalle fixe et vous alerte dès qu'une vérification échoue. Commencez par les pages qui génèrent du chiffre d'affaires ou qui comptent le plus pour vos utilisateurs, puis ajoutez les endpoints d'API et de health check. Notre guide de la surveillance de sites web explique comment choisir quoi surveiller.
Surveillez les codes de statut avec nanokoi.io
La surveillance de l'uptime de nanokoi.io vérifie vos URL toutes les 5 minutes avec l'offre Free, toutes les minutes avec Starter et toutes les 30 secondes avec Professional, et vous alerte par e-mail, Slack ou webhook lorsqu'une vérification échoue. Elle surveille aussi les certificats SSL et les enregistrements DNS, pour que vous repériez les causes d'erreurs avant vos utilisateurs. Découvrez les offres et intervalles de vérification.
Bonnes pratiques
- Surveillez les pages et endpoints critiques, pas seulement la page d'accueil
- Déclenchez une alerte pour chaque 5xx et pour les réponses 4xx des URL qui devraient toujours fonctionner
- Envoyez les alertes là où votre équipe travaille, par exemple dans un canal Slack dédié (voir notre guide de configuration d'un webhook Slack)
- Revérifiez les redirections après chaque migration ou changement d'URL
- Servez des pages d'erreur utiles avec le bon code de statut, jamais une page d'erreur avec 200
Scénarios courants de codes de statut
Les codes de statut apparaissent rarement seuls. Voici des situations que vous reconnaîtrez en production, avec les codes à surveiller et par où commencer.
Le paiement échoue sous la charge
Les clients reçoivent une erreur au moment de finaliser un achat.
500, 502, 503
Commandes perdues et paniers abandonnés
Vérifiez les journaux de l'application, les connexions à la base de données, l'état de la passerelle de paiement et la capacité du serveur
L'application mobile ne charge plus de contenu
Les utilisateurs de l'application voient soudain des écrans vides ou des messages d'erreur.
429, 401
Utilisateurs frustrés et sessions en échec
Revoyez les limites de débit de l'API, l'expiration des jetons et la logique de nouvelle tentative du client
Le trafic chute après une refonte
Les anciennes URL renvoient des erreurs au lieu de rediriger vers leur nouvel emplacement.
404, 301
Positions perdues dans les moteurs de recherche et backlinks cassés
Redirigez chaque ancienne URL en 301 ou 308, mettez à jour le sitemap et corrigez les liens internes
Images et CSS manquants pour certains utilisateurs
Les pages se chargent sans styles ni images dans certaines régions.
403, 404, 502
Un site qui semble cassé et une mauvaise expérience utilisateur
Vérifiez la configuration du CDN, la connexion au serveur d'origine, les règles d'accès et les paramètres de cache
Comment résoudre une erreur HTTP
Lorsqu'une alerte se déclenche, suivez toujours le même ordre. Vous gagnez du temps et évitez de traiter les symptômes plutôt que les causes.
- 1
Évaluer la portée et l'impact
Quelles URL sont touchées, depuis quand et pour qui ? Un seul endpoint et un domaine entier sont deux incidents très différents.
- 2
Reproduire la requête
Relancez la requête avec curl ou les outils de développement de votre navigateur. Vérifiez l'URL, la méthode, les en-têtes et le corps à la recherche de fautes ou de paramètres manquants.
- 3
Tester depuis un autre réseau
Interrogez la même URL depuis un autre lieu ou réseau pour écarter un problème local, et comparez la réponse du CDN à celle du serveur d'origine.
- 4
Vérifier les dépendances
Pour les erreurs 5xx, contrôlez les bases de données, les services backend, les API tierces et les ressources du serveur comme le CPU, la mémoire et le disque.
- 5
Examiner les changements récents
La plupart des incidents suivent un déploiement, un changement de configuration ou l'expiration d'un certificat ou d'un domaine. Consultez d'abord votre journal des modifications.
- 6
Éviter que cela se reproduise
Une fois le problème résolu, ajoutez un moniteur pour l'URL concernée et documentez l'incident pour résoudre le suivant plus vite.
FAQ sur les codes de statut HTTP
Quelle est la différence entre les codes de statut 4xx et 5xx ?
Les codes 4xx signifient que le serveur estime que le client a commis une erreur, par exemple en demandant une page inexistante ou en envoyant des identifiants invalides. Les codes 5xx signifient que la requête était valide, mais que le serveur n'a pas pu la traiter.
Faut-il utiliser une redirection 301 ou 302 ?
Utilisez 301 (ou 308) lorsqu'une page a déménagé définitivement : Google y voit un signal fort pour indexer la nouvelle URL. N'utilisez 302 (ou 307) que pour des déplacements temporaires où l'URL d'origine doit rester indexée.
Quelle est la différence entre 404 et 410 ?
404 indique que la ressource est introuvable ; 410, qu'elle a été supprimée volontairement et ne reviendra pas. Google traite les deux de la même façon et retire l'URL de son index.
Quels codes de statut HTTP doivent déclencher une alerte ?
Toute réponse 5xx, ainsi que les réponses 4xx des URL qui devraient toujours fonctionner, comme la page d'accueil, la connexion, le paiement et les endpoints de health check. Les redirections inattendues sur ces URL méritent aussi une alerte.
Repérez les erreurs HTTP avant vos utilisateurs
Surveillez vos URL clés avec nanokoi.io et recevez des alertes par e-mail, Slack ou webhook lorsqu'une vérification échoue. L'offre Free couvre jusqu'à 5 URL avec des vérifications toutes les 5 minutes.
Commencer la surveillance gratuitementAucune carte bancaire requise