Codes HTTP 4xx : signification, diagnostic et solutions aux erreurs 400 à 499

Les codes HTTP 400 à 4xx indiquent qu’une requête ne peut pas être satisfaite parce que le client semble avoir commis une erreur ou ne remplit pas une condition nécessaire. 400 signale généralement une requête mal formée, 401 une authentification absente ou invalide, 403 un accès refusé, 404 une ressource introuvable et 429 un nombre excessif de requêtes.

Le bon correctif dépend du code exact : répéter aveuglément la même requête ne résout ni une syntaxe incorrecte, ni une autorisation insuffisante, ni une URL inexistante.

L’expression « erreur côté client » ne signifie pas toujours que l’utilisateur est personnellement responsable. Le client peut être un navigateur, une application mobile, un robot, un script, un SDK ou un serveur intermédiaire. Une mauvaise configuration du site, du CDN ou de l’API peut aussi provoquer une réponse 4xx adressée au client. Le code décrit la manière dont le serveur classe le résultat ; il ne localise pas automatiquement la panne physique.

Ce guide fournit une liste structurée des principaux codes officiels, distingue les statuts standards des extensions propres à certains serveurs et propose une méthode de diagnostic utilisable sur un site web, WordPress ou une API.

Que signifie la classe des codes HTTP 4xx ?

Un code de statut HTTP est un entier à trois chiffres placé dans la réponse d’un serveur. Le premier chiffre définit la famille : 1xx pour l’information, 2xx pour le succès, 3xx pour la redirection, 4xx pour une erreur qui semble liée au client et 5xx pour une erreur que le serveur reconnaît de son côté.

La RFC 9110 précise qu’une réponse 4xx devrait, sauf pour une requête HEAD, contenir une représentation expliquant la situation et indiquant si elle est temporaire ou permanente. Une page HTML peut afficher cette explication à un humain. Une API peut renvoyer un objet JSON structuré.

Il faut distinguer le statut de la cause profonde. Une application qui refuse volontairement une requête invalide renvoie correctement 400 ou 422 : son serveur fonctionne. Une règle WAF trop stricte peut cependant bloquer une requête légitime avec 403. Dans ce second cas, la réponse est conforme au protocole mais la politique applicative doit être corrigée.

Les deux derniers chiffres ne constituent pas une sous-classification mathématique. 401 n’est pas une version plus grave de 400, et 429 n’est pas nécessairement plus critique que 404. Chaque nombre enregistré possède sa propre sémantique.

Tableau des principaux codes HTTP 400 à 4xx

Cette liste reprend les codes les plus utiles enregistrés par l’IANA. Certains numéros sont non attribués, provisoires ou réservés. Un code aperçu dans les journaux d’un produit peut aussi être une extension privée et ne pas figurer dans le registre officiel.

Comment distinguer 400, 401, 403 et 404 ?

Ces quatre codes sont les plus fréquents, mais leurs solutions sont différentes. 400 Bad Request signifie que le serveur juge la requête incorrecte. L’URL peut contenir une syntaxe invalide, le JSON être mal fermé, les en-têtes se contredire ou le message être impossible à analyser. Répéter la requête sans modification échouera généralement encore.

401 Unauthorized signifie en pratique « non authentifié ». Le nom prête à confusion : le serveur demande des identifiants ou refuse ceux qui ont été fournis. La réponse doit inclure un défi `WWW-Authenticate` applicable à la ressource. Pour une API, il faut vérifier l’expiration du jeton, sa signature, son audience et le schéma `Bearer`.

403 Forbidden signifie que le serveur comprend la demande mais refuse de la traiter. L’utilisateur peut être authentifié sans posséder le rôle nécessaire. Un pare-feu, une règle IP, une restriction géographique ou des permissions de fichiers peuvent aussi produire ce statut. Le guide CritiquePlus sur l’erreur 403 Forbidden et ses solutions détaille le diagnostic navigateur, WordPress, CDN et serveur.

404 Not Found indique que le serveur ne trouve pas la représentation demandée ou ne souhaite pas révéler son existence. Le statut ne dit pas si l’absence est temporaire ou permanente. Pour une suppression volontaire et durable, 410 Gone est plus explicite.

Quelle différence entre 400, 409 et 422 dans une API ?

Une API fiable ne devrait pas transformer toutes les erreurs en 400. 400 convient quand la requête ne peut pas être interprétée ou viole une exigence générale. 409 Conflict convient lorsque la demande est valide mais entre en conflit avec l’état actuel de la ressource. 422 Unprocessable Content signifie que le type et la syntaxe du contenu sont compris, mais que les instructions ne peuvent pas être exécutées.

Supposons une création de compte. Un JSON mal fermé justifie 400. Un nom d’utilisateur déjà occupé peut justifier 409 parce que l’état actuel crée le conflit. Une adresse e-mail correctement transmise mais rejetée par une règle de validation peut justifier 422. La documentation de l’API doit rester cohérente afin que les clients sachent quoi corriger.

La RFC 9457 définit le format `application/problem+json` pour renvoyer des détails d’erreur lisibles par les machines. Un objet peut contenir `type`, `title`, `status`, `detail` et `instance`, plus des extensions propres au service. Le statut HTTP reste la classification principale ; le corps apporte le contexte.

Exemple conceptuel :

`{"type":"https://api.exemple.com/problems/email","title":"Donnée invalide","status":422,"detail":"L’adresse e-mail est déjà utilisée"}`

Il faut éviter d’exposer une trace de pile, une requête SQL, une clé secrète ou des informations internes. Le message doit aider le client sans révéler les détails exploitables de l’infrastructure.

Comment interpréter 405, 406, 415 et 426 ?

Ces codes concernent la manière d’échanger avec la ressource. 405 Method Not Allowed apparaît lorsqu’une URL existe, mais n’accepte pas la méthode utilisée. Une route en lecture peut autoriser GET et HEAD mais refuser POST. La réponse doit indiquer les méthodes autorisées dans l’en-tête `Allow`.

406 Not Acceptable concerne la réponse souhaitée. Le client demande, via `Accept`, un format que le serveur ne peut produire. 415 Unsupported Media Type concerne plutôt le contenu envoyé : le serveur refuse le type déclaré dans `Content-Type` ou l’encodage du corps. Confondre Accept et Content-Type est une source classique d’erreur dans les API.

426 Upgrade Required indique que le serveur refuse le protocole actuel mais pourrait accepter la requête après passage à un autre protocole. La réponse doit contenir un en-tête `Upgrade` indiquant le ou les protocoles requis. Il ne faut pas employer 426 comme simple message de mise à jour d’une application mobile si aucune évolution protocolaire HTTP n’est réellement proposée.

Scénario fréquent : une API attend `application/json`, mais le client envoie un formulaire avec `application/x-www-form-urlencoded`. Si le serveur ne prend pas ce format en charge, 415 est plus précis que 400. Si le JSON est accepté mais qu’un champ métier est invalide, 422 devient plus utile.

Que signifient les erreurs de délai, taille et en-têtes ?

408 Request Timeout signifie que le serveur n’a pas reçu une requête complète dans le délai qu’il était prêt à attendre. Une connexion lente, un client bloqué ou un intermédiaire peuvent en être la cause. Le client peut réessayer, mais une répétition immédiate et illimitée risque d’aggraver la charge.

413 Content Too Large indique que le corps dépasse la limite. Sur WordPress, ce problème apparaît souvent lors d’un téléversement si les limites PHP, du serveur web, du proxy et du CDN ne sont pas cohérentes. Augmenter une seule limite ne suffit pas si une couche placée avant l’application bloque toujours la requête.

414 URI Too Long concerne l’adresse elle-même. Il ne faut pas placer un volume important de données ou un jeton long dans la chaîne de requête. Utilisez une méthode et un corps adaptés, tout en évitant d’insérer des secrets dans l’URL, car les URL apparaissent dans l’historique et les journaux.

431 Request Header Fields Too Large vise les en-têtes. Des cookies accumulés sont une cause fréquente dans le navigateur. Côté utilisateur, supprimer les données du site peut résoudre le problème. Côté développeur, il faut limiter la taille des cookies et éviter de stocker un état volumineux côté client.

416 Range Not Satisfiable apparaît lorsqu’un client demande une plage inexistante, par exemple des octets situés au-delà de la fin d’un fichier. Les lecteurs vidéo, gestionnaires de téléchargement, caches et CDN doivent comparer la plage demandée avec la taille réelle et gérer les changements de ressource.

Comment gérer 408, 425 et 429 sans créer une boucle de requêtes ?

Les erreurs temporaires ne doivent pas déclencher des répétitions agressives. Pour 429 Too Many Requests, le serveur peut fournir `Retry-After`, exprimé en secondes ou sous forme de date HTTP. Le client doit respecter cette indication, appliquer un délai exponentiel et ajouter une part aléatoire afin que plusieurs clients ne repartent pas au même instant. Le guide des bugs et erreurs courantes de ChatGPT montre un cas concret de 429 produit par une limite de fréquence.

Pour 408, une nouvelle tentative peut réussir si le réseau ou la charge était temporairement dégradé. Une requête non idempotente exige cependant de vérifier si l’opération a déjà été exécutée. Un paiement ne doit pas être envoyé une seconde fois sans clé d’idempotence ou contrôle de l’état de la transaction.

425 Too Early protège notamment contre le rejeu de données envoyées avec le mécanisme 0-RTT de TLS. Le client doit réessayer après établissement complet de la connexion, sans considérer l’opération comme définitivement refusée.

Une application doit définir un nombre maximal de tentatives. Sinon, un incident partiel peut provoquer une tempête de requêtes et prolonger la panne.

Codes WebDAV et statuts 4xx moins fréquents

WebDAV étend HTTP pour gérer des ressources distantes. 423 Locked indique qu’une ressource est verrouillée. 424 Failed Dependency signifie que l’opération a échoué parce qu’une action dont elle dépendait n’a pas abouti. Ces statuts sont rares dans une navigation classique mais apparaissent dans les logiciels de synchronisation, d’édition collaborative ou de stockage.

421 Misdirected Request peut se produire lorsqu’une connexion est réutilisée pour un hôte que le serveur ne sait pas servir. Le routage TLS, le SNI, HTTP/2, le proxy inverse ou la mutualisation de domaines sont des pistes. Une 421 répétée sur un seul hôte doit être analysée dans la chaîne client–CDN–proxy–origine.

428 Precondition Required demande au client d’utiliser une requête conditionnelle, par exemple `If-Match`, pour éviter qu’une modification écrase silencieusement le travail d’un autre utilisateur. 412 Precondition Failed indique ensuite que la condition fournie n’est pas satisfaite, souvent parce que l’ETag a changé.

451 Unavailable For Legal Reasons signale une indisponibilité liée à une demande juridique ou réglementaire. La réponse peut contenir un lien décrivant la demande. Ce code ne doit pas servir à masquer une panne technique ou une simple restriction commerciale.

Le code 418 possède une histoire humoristique. Dans le registre IANA actuel, sa phrase est « Unused ». Il reste reconnu culturellement mais ne constitue pas un bon choix pour une erreur métier réelle, car il ne donne aucune instruction utile au client.

Codes 4xx non standards : 444, 499 et autres extensions

Tous les codes visibles dans des journaux ne sont pas des standards IETF. Nginx utilise notamment 444 pour fermer une connexion sans envoyer de réponse HTTP et 499 dans ses journaux lorsque le client ferme la connexion avant que le serveur ne termine sa réponse. Ces valeurs sont utiles pour l’exploitation, mais leur sémantique dépend du produit.

Cloudflare et d’autres intermédiaires emploient également des codes propres à leurs services. Il faut consulter la documentation du fournisseur et identifier la couche qui a généré le statut. Une page servie par un CDN peut afficher un code que l’application d’origine n’a jamais produit.

Cette distinction évite deux erreurs : présenter une extension comme un standard universel ou programmer un client en supposant que tous les serveurs lui donnent le même sens. Pour une API publique, privilégiez les statuts enregistrés et documentez chaque extension indispensable.

Le code 499 illustre aussi la difficulté d’attribuer la responsabilité. Le journal dit que le client a fermé la connexion, mais celui-ci a peut-être abandonné parce que l’origine était trop lente. Il faut rapprocher temps de réponse, traces applicatives, délais du proxy et événements client avant de conclure.

Comment diagnostiquer une erreur 4xx dans un navigateur, WordPress ou une API ?

Commencez par capturer le code exact, l’URL, la méthode, l’heure, le contexte d’authentification et le corps de réponse. Dans le navigateur, l’onglet Réseau des outils de développement montre la requête, les en-têtes et la réponse. Dans une API, utilisez les journaux avec un identifiant de corrélation, sans enregistrer les secrets.

Suivez ensuite ce parcours :

1. reproduire la requête de façon contrôlée ;
2. déterminer si tous les utilisateurs sont touchés ;
3. comparer navigateur, réseau et compte ;
4. vérifier CDN, WAF, proxy et origine ;
5. consulter les journaux de la couche qui a émis la réponse ;
6. corriger la cause, puis retester sans cache ;
7. surveiller le taux du code concerné après déploiement.

Sur WordPress, une 403 peut venir des permissions, d’un plugin de sécurité ou de `.htaccess`. Une 404 peut venir des permaliens ou d’une ressource supprimée. Une 413 pointe souvent vers une limite d’upload. Une 429 peut provenir d’une protection anti-bot ou d’une API externe. Désactiver toutes les protections n’est pas une méthode durable : isolez la règle exacte.

Pour une erreur de connexion qui n’a reçu aucune réponse HTTP, ne cherchez pas un code 4xx inexistant. Le guide ERR_EMPTY_RESPONSE explique le cas où la connexion se ferme sans en-têtes ni corps HTTP. De même, ERR_CONNECTION_TIMED_OUT concerne un délai réseau qui peut survenir avant toute réponse HTTP. Si le navigateur interrompt plutôt une réponse HTTP/2 mal formée, consultez le diagnostic de ERR_HTTP2_PROTOCOL_ERROR.

Quel est l’impact SEO des erreurs 4xx ?

Google indique qu’il n’utilise pas le contenu des URL qui renvoient un code 4xx. Une URL déjà indexée est progressivement retirée si elle continue de répondre ainsi. Une 404 ou 410 correcte n’est donc pas une pénalité : elle informe que la ressource n’est plus disponible. Le problème vient plutôt des erreurs involontaires, des liens internes cassés et des pages importantes bloquées.

N’effectuez pas une redirection massive de toutes les 404 vers la page d’accueil. Cette pratique crée une expérience trompeuse et peut être interprétée comme une soft 404. Redirigez vers une ressource réellement équivalente. Si aucune alternative n’existe, conservez une vraie 404 ou 410 avec une page utile pour l’humain.

Une page 404 personnalisée doit quand même renvoyer le statut HTTP 404. Afficher « page introuvable » avec un code 200 crée une soft 404. Vérifiez le statut avec les outils de développement, `curl -I` ou l’inspection d’URL dans Search Console.

Surveillez également les 403 et 429 adressées à Googlebot. Un WAF trop agressif peut empêcher l’exploration. Ne placez pas Googlebot sur liste blanche à partir du seul user-agent, facilement usurpable ; utilisez les méthodes officielles de vérification et corrigez les règles qui créent le blocage.

Les liens internes doivent mener vers des URL fonctionnelles. Le guide sur les codes de statut HTTP doit lui-même rester accessible en 200 afin de servir de ressource centrale.

FAQ

Une erreur 4xx vient-elle toujours de mon ordinateur ?

Non. « Client Error » décrit la classe de réponse. La cause peut venir d’un navigateur, d’une application, d’un compte, mais aussi d’une route incorrecte, d’un WAF ou d’une politique serveur mal configurée.

Quelle différence entre 404 et 410 ?

404 indique que la ressource n’est pas trouvée sans préciser la durée. 410 indique que la suppression est volontaire et considérée comme permanente. Les deux conduisent les moteurs à retirer l’URL, mais 410 est plus explicite.

Pourquoi 401 signifie-t-il Unauthorized alors qu’il concerne l’authentification ?

Le nom historique prête à confusion. Dans la pratique HTTP, 401 signifie que des identifiants valides manquent. 403 correspond davantage au cas où l’accès reste interdit malgré une identité connue.

Faut-il renvoyer 400 ou 422 pour un formulaire invalide ?

Utilisez 400 si la requête est mal formée ou impossible à interpréter. Utilisez 422 si le contenu est syntaxiquement correct mais échoue aux règles de traitement. Le plus important est de documenter une convention stable.

Une 429 doit-elle toujours contenir Retry-After ?

Ce champ est recommandé mais pas systématiquement présent. Le client doit le respecter lorsqu’il existe et prévoir un backoff raisonnable lorsqu’il manque.

Les codes 444 et 499 sont-ils officiels ?

Non. Ce sont notamment des conventions associées à Nginx. Elles sont utiles dans ses journaux mais ne doivent pas être décrites comme des statuts HTTP universels.

Sources officielles consultées

• IANA, Hypertext Transfer Protocol Status Code Registry.
• IETF, RFC 9110 — HTTP Semantics.
• IETF, RFC 9112 — HTTP/1.1.
• IETF, RFC 9457 — Problem Details for HTTP APIs.
• IETF, RFC 6585 — Additional HTTP Status Codes.
• IETF, RFC 4918 — HTTP Extensions for WebDAV.
• IETF, RFC 7725 — An HTTP Status Code to Report Legal Obstacles.
• IETF, RFC 8470 — Using Early Data in HTTP.
• IETF, RFC 9209 — Proxy-Status HTTP Response Header Field.
• Google Search Central, How HTTP status codes affect Google’s crawlers.
• Mozilla MDN, HTTP response status codes.
• Nginx, Module ngx_http_rewrite_module.