Erreur 400 : causes et solutions

Une erreur HTTP 400 « Bad Request » signifie que le serveur a reçu la requête, mais qu’il refuse de la traiter parce qu’elle est invalide ou mal formée. Le message est le même pour le visiteur, un formulaire ou une API, mais la bonne correction dépend entièrement du contexte.

Avant de vider tous les caches ou de modifier le serveur, commencez donc par répondre à une question simple : l’erreur touche-t-elle une seule personne, une seule action ou l’ensemble du site ?

Que signifie exactement le code HTTP 400 ?

Le code 400 appartient à la famille des réponses HTTP 4xx. Il indique que la requête envoyée ne respecte pas ce que le serveur attend : URL incorrecte, en-tête trop volumineux, corps JSON invalide, champ obligatoire absent ou format de données non reconnu.

Il faut le distinguer de quelques codes proches :

• 401 : une authentification est requise ou invalide ;
• 403 : la requête est comprise, mais l’accès est interdit ;
• 404 : la ressource demandée n’existe pas ;
• 413 : le fichier ou la requête dépasse la taille autorisée ;
• 422 : la syntaxe est comprise, mais les données ne passent pas la validation.

Identifier rapidement l’origine de l’erreur

L’erreur apparaît sur une seule URL

Vérifiez l’adresse copiée, les caractères spéciaux et les paramètres placés après le point d’interrogation. Une URL tronquée, un espace non encodé ou un paramètre répété suffit parfois à produire une erreur 400.

L’erreur touche une seule personne

Le navigateur peut envoyer un cookie ancien ou un en-tête devenu trop volumineux. Testez la même page dans une fenêtre privée, puis dans un autre navigateur. Si elle fonctionne, supprimez uniquement les données du site concerné plutôt que tout l’historique.

L’erreur apparaît après un formulaire ou un téléversement

Contrôlez les champs obligatoires, le format des dates, la taille et le type du fichier. Côté application, la validation doit expliquer précisément le champ refusé au lieu de renvoyer une page 400 générique.

L’erreur concerne une API

Comparez la requête réelle avec la documentation : méthode HTTP, URL, paramètres, en-tête Content-Type, authentification et structure JSON. Un JSON incomplet, une virgule finale ou une chaîne envoyée à la place d’un nombre sont des causes fréquentes.

Plusieurs pages ou tous les utilisateurs sont touchés

Le problème est probablement côté serveur, proxy, pare-feu applicatif ou déploiement. Relevez l’heure exacte, l’URL et l’action réalisée, puis examinez les journaux correspondants. Évitez de désactiver une protection globalement sans avoir identifié la règle en cause.

Corriger une erreur 400 côté visiteur

1. Rechargez la page depuis son adresse officielle. Évitez un ancien favori ou un lien copié partiellement.
2. Testez en navigation privée. Ce test permet de repérer rapidement un cookie ou une extension en cause.
3. Supprimez les données du site concerné. Reconnectez-vous ensuite si la session a été effacée.
4. Réduisez le fichier envoyé. Vérifiez également son extension et son format réel.
5. Notez le scénario reproductible. L’URL, l’heure et l’action précédente aideront le support à retrouver la requête dans les journaux.

Corriger une erreur 400 côté site ou API

1. Reproduisez le problème sans données sensibles. Utilisez les outils réseau du navigateur ou un client API pour observer la méthode, l’URL, les en-têtes et la réponse.
2. Lisez les journaux applicatifs et du proxy. Le message côté serveur est souvent plus précis que la page affichée au visiteur.
3. Validez et normalisez les entrées. Définissez les formats acceptés, les tailles maximales et des messages d’erreur exploitables.
4. Vérifiez les limites d’infrastructure. Taille des en-têtes, cookies, corps de requête, règles du pare-feu et configuration du reverse proxy doivent rester cohérents.
5. Ajoutez un test de non-régression. Une requête valide doit réussir et une requête invalide doit produire une réponse claire, sans révéler d’information interne.

Quel impact une erreur 400 peut-elle avoir sur le SEO ?

Une erreur 400 isolée sur un formulaire interne ou une API privée n’affecte pas automatiquement le référencement du site. En revanche, si une URL publique destinée à être indexée renvoie durablement un code 400 à Googlebot, Google ne peut pas exploiter son contenu et peut finir par la retirer de l’index.

Google explique que les réponses 4xx, à l’exception notamment du code 429, ne fournissent pas de contenu indexable. La priorité est donc de restaurer une réponse 200 sur l’URL canonique utile, puis de corriger les liens internes qui génèrent des adresses invalides. Consultez la documentation officielle de Google sur les erreurs HTTP.

Ne redirigez pas toutes les erreurs vers l’accueil : une redirection sans rapport masque le problème et dégrade la compréhension du parcours.

Prévenir les erreurs Bad Request

• valider les données dans l’interface et à nouveau sur le serveur ;
• encoder correctement les URL et leurs paramètres ;
• limiter la taille des cookies et des en-têtes ;
• journaliser un identifiant de requête sans stocker de secret ;
• surveiller les volumes de réponses 400 par route après chaque déploiement ;
• tester les formulaires, téléversements et contrats API dans la suite automatisée.

À retenir

Le code 400 ne donne pas une cause unique : il indique seulement que la requête est inexploitable. Un test en navigation privée aide le visiteur, tandis que les journaux, le détail de la requête et la validation des entrées permettent au propriétaire du site de trouver la vraie origine.

Si l’erreur se répète sur un parcours important, je peux vous aider à diagnostiquer et fiabiliser votre application web. Pour poursuivre le diagnostic, consultez aussi les guides consacrés aux erreurs 404, 500 et 502.