Une erreur HTTP indique qu’une demande n’a pas abouti comme prévu. Le code et le message affichés donnent une piste, mais il faut les rapprocher de l’heure, de l’action effectuée et des journaux pour trouver la cause. Le problème peut concerner une page, une application, l’hébergement ou un service intermédiaire.
Avant de modifier votre site
- Notez le code exact, le message, la page concernée, l’heure et le fuseau horaire. Conservez une capture et, s’il apparaît, l’identifiant de la requête.
- Déterminez ce qui est touché : une seule page, l’administration, les formulaires ou tout le site. Notez le dernier changement connu, par exemple une mise à jour, une publication ou une modification de redirection.
- Pour une simple page de consultation, essayez une fois dans une fenêtre privée ou un autre navigateur. Ce test aide à comparer les sessions; il ne corrige pas la cause. Ne multipliez pas les tentatives si un blocage ou une limite est affiché.
- Si l’erreur suit un paiement, une commande ou l’envoi d’un formulaire, vérifiez d’abord si l’opération a été enregistrée. Un délai dépassé ne signifie pas nécessairement qu’elle a échoué; la renvoyer peut créer un doublon.
Si le navigateur affiche plutôt un problème de résolution du domaine ou un avertissement de certificat, conservez ce message précis. Ne contournez pas l’avertissement de sécurité pour poursuivre.
Erreurs 400 à 499 : vérifier la demande et les accès
- 400, Bad Request : la demande est rejetée comme incorrecte. Vérifiez l’adresse et l’action qui déclenche le message. Si le problème n’apparaît que dans une session, sauvegardez votre travail avant d’effacer uniquement les données de ce site; cette action peut vous déconnecter.
- 401, Unauthorized : une authentification valide est requise. Utilisez la connexion habituelle du site et le compte autorisé pour cette zone. Les identifiants d’un répertoire protégé peuvent être distincts de ceux de WordPress ou de l’espace client. Gardez la protection par mot de passe active.
- 403, Forbidden : l’accès est refusé. Vérifiez que vous consultez la bonne adresse avec les droits prévus. Une restriction d’accès, une règle de sécurité, des permissions ou une page d’accueil manquante peuvent nécessiter une vérification. Le code seul ne permet pas de choisir laquelle.
- 404, Not Found : la page demandée est introuvable ou sa présence n’est pas divulguée. Vérifiez les fautes de frappe, les majuscules et les liens après un déplacement de page. Si vous gérez le site, confirmez que la page est publiée et que sa route est toujours valide avant de modifier les redirections.
- 406, Not Acceptable : le serveur ne peut pas fournir une représentation acceptable selon la demande. Certaines applications ou couches de sécurité utilisent aussi ce code. Notez l’action précise qui le déclenche; le code ne suffit pas à identifier ModSecurity comme cause.
- 413, Content Too Large : le contenu envoyé dépasse une taille acceptée. Relevez la taille du fichier et la limite affichée. Une application, le serveur ou un intermédiaire peut imposer cette limite. Demandez quelle méthode d’importation convient avant d’augmenter des paramètres.
- 429, Too Many Requests : une limite de fréquence est atteinte. Arrêtez les tentatives répétées et respectez le délai indiqué s’il y en a un. Notez toute tâche automatique récente. Une nouvelle adresse IP ou la désactivation d’une protection ne constitue pas une correction appropriée.
Erreurs 500 à 504 : examiner le traitement de la demande
- 500, Internal Server Error : une condition inattendue empêche le traitement. Notez les modifications récentes et consultez les erreurs disponibles. Une erreur de code, de configuration ou de ressources fait partie des pistes à confirmer.
- 502, Bad Gateway : un intermédiaire a reçu une réponse invalide du service en amont. Notez si le problème touche toutes les pages ou seulement une fonction.
- 503, Service Unavailable : le service ne peut pas traiter la demande pour le moment, notamment pendant une maintenance ou une surcharge. Respectez les indications affichées et signalez les interruptions persistantes ou répétées.
- 504, Gateway Timeout : un intermédiaire n’a pas reçu la réponse attendue à temps. Précisez l’opération et sa durée approximative; évitez de relancer un traitement long ou une transaction sans vérifier son résultat.
Si le problème suit une modification de WordPress, consultez notre guide de dépannage après une modification. Préservez l’état du site et les données récentes avant de décider d’un retour en arrière.
Message 508 « Resource Limit Reached »
Sur un hébergement utilisant CloudLinux, ce message peut signaler une limite de processus d’entrée simultanés. Vérifiez les mesures et les limites atteintes à l’heure du problème. D’autres ressources peuvent provoquer un ralentissement ou d’autres erreurs; un seul code ne décrit pas toute la consommation du compte.
Le code standard 508 « Loop Detected », utilisé dans le contexte WebDAV, a un autre sens. Relevez donc le message complet. Notre guide de consultation des ressources explique comment préparer les mesures utiles. Une erreur isolée ne suffit pas à conclure qu’un changement de forfait est nécessaire.
Si votre site utilise Cloudflare
Conservez le code exact, l’heure et le Ray ID affiché, s’il est présent. Les erreurs 52x peuvent demander des vérifications différentes : connexion au serveur d’origine, temps de réponse ou certificat. La présence du logo Cloudflare ne permet pas à elle seule d’attribuer la panne. Gardez les protections et le niveau de chiffrement en place pendant l’analyse.
Consulter les informations disponibles dans cPanel
Si l’outil est proposé pour votre service, ouvrez Mesures > Erreurs (Metrics > Errors). Il affiche des entrées récentes du journal du serveur web, avec une limite de 300 entrées. Les erreurs d’une application ou d’un service intermédiaire peuvent se trouver ailleurs. L’absence d’entrée correspondante ne prouve pas l’absence de problème.
Comparez aussi l’heure de l’incident avec l’historique de Resource Usage ou CPU and Concurrent Connection Usage, lorsque cet outil est disponible. Si vous ne trouvez pas ces informations, notre équipe peut vous orienter selon votre service.
Garder une intervention ciblée
Évitez de désactiver globalement ModSecurity ou le pare-feu applicatif, d’ouvrir les permissions à 777, ou de supprimer ou renommer le fichier .htaccess pour tester au hasard. Ce fichier peut contenir des protections, des redirections et les règles nécessaires à l’application. Si une règle bloque une action légitime, demandez une analyse ciblée à partir de l’erreur observée.
Obtenir de l’aide de Nuagerie
Ouvrez ou complétez une demande dans votre espace client Nuagerie. Indiquez le site et la page concernés, le code exact, l’heure avec le fuseau, les étapes pour reproduire le problème, son impact et les changements récents. Ajoutez une capture ou un court extrait pertinent du journal si vous en disposez. Notre équipe pourra vous demander votre adresse IP en privé si elle est utile pour retrouver la requête.
Retirez des captures et des liens les mots de passe, clés, jetons de session ou de réinitialisation, données de clients et informations sans rapport avec l’incident. Ne publiez pas vos journaux sur une page accessible à tous.
Ces éléments permettent à notre équipe de relier les symptômes aux informations de l’hébergement et de préciser les vérifications à mener avec votre développeur. Si le site rencontre régulièrement des limites ou nécessite une intervention applicative, parlez-nous de vos besoins : nous pourrons examiner les options d’optimisation, de développement et d’hébergement adaptées à votre usage.
