Comprendre les pages d’erreurs HTTP sur le Web

Introduction aux pages d’erreurs HTTP

Lorsque nous sur­fons sur Inter­net ou tra­vaillons sur un site, tout ne se déroule pas tou­jours comme sou­hai­té. Il se peut qu’une page soit introu­vable (erreur 404), qu’un ser­veur soit momen­ta­né­ment hors ser­vice (erreur 503), ou qu’un uti­li­sa­teur essaie d’at­teindre une res­source sans y avoir droit (erreur 403). Dans tous ces cas, une page dédiée appa­raît : la page d’erreur HTTP.

Ces pages ne se contentent pas d’être de simples notes tech­niques. Elles occupent une place cru­ciale dans l’ex­pé­rience uti­li­sa­teur et dans la liai­son entre votre site web, ses visi­teurs et les moteurs de recherche. Mal éla­bo­rées, elles créent de la confu­sion ou peuvent pous­ser à quit­ter le site. Bien réa­li­sées, elles peuvent au contraire appor­ter une assu­rance, orien­ter effi­ca­ce­ment et même conso­li­der votre répu­ta­tion de marque.

Dans cet article, nous exa­mi­ne­rons les caté­go­ries prin­ci­pales de codes d’erreur :

• Les erreurs liées au client (4xx),
• Les erreurs liées au ser­veur (5xx),
• Ensuite, nous nous concen­tre­rons sur la fameuse page 404, un élé­ment incon­tour­nable de tout site web bien conçu.

Les erreurs côté client (4xx)

Les codes d’er­reur HTTP du groupe 4xx signalent une ano­ma­lie dans la requête envoyée au ser­veur. Ces erreurs indiquent que la requête est erro­née, mal struc­tu­rée ou ne peut être exé­cu­tée dans sa condi­tion actuelle.

Ces erreurs se pro­duisent cou­ram­ment et peuvent pro­ve­nir de :

• L’u­ti­li­sa­teur : URL incor­recte, ten­ta­tive d’ac­cès à une res­source interdite.
• Le navi­ga­teur : requête incor­recte, sou­ci lié aux cookies.
• Le code de l’ap­pli­ca­tion : des liens bri­sés, des requêtes API erronées.
• L’err­reur de pro­gram­ma­tion côté fron­tend : à cor­ri­ger par le développeur.

Voi­ci les plus courantes :

Erreur 400 : Requête incorrecte (Bad Request)

La requête adres­sée au ser­veur est incor­rec­te­ment for­ma­tée ou non valide. Cela pour­rait être dû à une URL erro­née, des carac­tères spé­ciaux mal codés, ou des infor­ma­tions mal orga­ni­sées (comme dans un formulaire).

Exemples :

• Un for­mu­laire com­por­tant des champs absents ou incor­rec­te­ment validés
• Une URL qui ne res­pecte pas la syn­taxe appropriée
• Une redi­rec­tion mal mise en place par une extension

Côté uti­li­sa­teur : le simple fait de vider le cache peut par­fois être suf­fi­sant.
Du point de vue du déve­lop­peur : soyez vigi­lant face aux conflits JavaS­cript ou aux erreurs dans les en-têtes HTTP.

Erreur 401 : Non autorisé (Unauthorized)

Cette erreur signi­fie que l’ac­cès à la res­source est limi­té et exige une authen­ti­fi­ca­tion. Habi­tuel­le­ment, cela indique que l’u­ti­li­sa­teur n’a pas sou­mis les iden­ti­fiants néces­saires (ou qu’ils sont erronés).

À noter : l’i­den­ti­fi­ca­tion de l’u­ti­li­sa­teur est incor­recte ou absente.
Exemple : un dos­sier sécu­ri­sé et l’u­ti­li­sa­teur qui n’a pas été sai­si cor­rec­te­ment le mot de passe.

Erreur 403 : Interdit (Forbidden)

L’er­reur HTTP 403 indique que le ser­veur a com­pris la requête mais refuse d’au­to­ri­ser l’ac­cès à la res­source deman­dée. Cette erreur peut sur­ve­nir dans deux contextes dis­tincts : avec ou sans authen­ti­fi­ca­tion préa­lable de l’utilisateur.

Carac­té­ris­tiques principales :

• Le ser­veur traite et com­prend la demande
• L’ac­cès est refu­sé pour des rai­sons d’autorisation
• Peut se pro­duire que l’u­ti­li­sa­teur soit authen­ti­fié ou non

Cas de figure :

Sans authen­ti­fi­ca­tion : L’u­ti­li­sa­teur n’est pas connec­té et tente d’ac­cé­der à une res­source protégée

• Exemple : Ten­ta­tive d’ac­cès direct à une page d’administration

Avec authen­ti­fi­ca­tion : L’u­ti­li­sa­teur est iden­ti­fié mais ne dis­pose pas des per­mis­sions nécessaires

• Exemple : un uti­li­sa­teur avec le rôle Abon­né est connec­té et tente d’ac­cé­der à des fonc­tion­na­li­tés réser­vées aux uti­li­sa­teurs avec un rôle Administrateurs

D’autres exemples :

• Une page d’ad­mi­nis­tra­tion acces­sible uni­que­ment aux uti­li­sa­teurs ayant le rôle approprié
• Une API REST néces­si­tant des per­mis­sions spé­ci­fiques ou un token avec des droits insuffisants
• Un fichier sur un ser­veur avec des per­mis­sions res­tric­tives (chmod 600)

À noter : ne pas confondre avec l’er­reur 401 (Non auto­ri­sé), qui indique un sou­ci d’au­then­ti­fi­ca­tion (iden­ti­fiants absents, incor­rects ou obso­lètes). L’er­reur 403 concerne l’au­to­ri­sa­tion, pas l’authentification.

Erreur 404 : Page non trouvée (Not Found)

L’erreur la plus célèbre ! Elle indique que la res­source deman­dée n’existe pas ou plus. Cela peut être dû à un lien cas­sé, une URL mal tapée, ou une page supprimée.

La 404 n’est pas for­cé­ment un pro­blème grave, mais elle mérite d’être bien gérée (nous y revien­drons plus loin).

Erreur 408 : Délai d’attente de la requête dépassé (Request Timeout)

La demande com­plète n’a pas été trans­mise au ser­veur dans les délais. Ceci peut se pro­duire si la connexion de l’u­ti­li­sa­teur est lente ou peu fiable.

Exemple : lors d’un pic de tra­fic, cette erreur pour­rait se pro­duire ponctuellement.

Erreur 429 : Trop de requêtes (Too Many Requests)

Le client a sou­mis un nombre exces­sif de requêtes dans un laps de temps res­treint. Le ser­veur l’in­ter­dit tem­po­rai­re­ment pour pré­ve­nir d’é­ven­tuelles sur­charges ou attaques.

Exemples :

• Un uti­li­sa­teur actua­li­sant une page en boucle
• Un script ou un bot mal configuré
• Un ser­vice de sur­veillance ou une exten­sion qui effec­tue un nombre exces­sif d’ap­pels à l’API

Les erreurs côté serveur (5xx)

À la dif­fé­rence des erreurs 4xx, qui sont liées à une requête mal for­mu­lée ou par­tielle du côté de l’u­ti­li­sa­teur, les erreurs 5xx indiquent un pro­blème lié au ser­veur lui-même. La requête a été cor­rec­te­ment envoyée par le client (navi­ga­teur), mais le ser­veur n’a pas réus­si à y four­nir une réponse appro­priée. Ces erreurs peuvent être pas­sa­gères, mais leur récur­rence peut avoir un impact signi­fi­ca­tif sur la dis­po­ni­bi­li­té, la cré­di­bi­li­té et le réfé­ren­ce­ment d’un site.

Erreur 500 : Problème interne au serveur (Internal Server Error)

Une erreur géné­rique indi­quant qu’un pro­blème est sur­ve­nu sur le ser­veur, mais sans four­nir davan­tage de pré­ci­sions. Cela pour­rait être dû à un exten­sion Word­Press défaillante, un thème mal pro­gram­mé, un fichier .htac­cess erro­né, ou un script PHP qui échoue.

La source la plus com­mune des redou­tées « pages blanches » sur un site web. On évoque fré­quem­ment le terme « White Screen of Death » ou WSOD (Écran Blanc de la Mort). Le ser­veur fait face à une erreur cri­tique (géné­ra­le­ment PHP), tou­te­fois, étant don­né que l’af­fi­chage des erreurs est désac­ti­vé en pro­duc­tion (display_errors = Off), aucun mes­sage ne s’af­fiche à l’é­cran : l’u­ti­li­sa­teur ne voit qu’une page blanche.

Exemple : l’ac­ti­va­tion d’une exten­sion qui entre en conflit avec une autre ou qui dépasse la capa­ci­té de mémoire du serveur.

Erreur 502 : Mauvaise passerelle (Bad Gateway)

Cette erreur indique qu’un ser­veur inter­mé­diaire (pas­se­relle ou proxy) a reçu une réponse inva­lide de la part d’un autre ser­veur en amont.

Elle sur­vient fré­quem­ment sur les sites uti­li­sant un proxy inverse (reverse proxy), un CDN comme Cloud­flare ou une archi­tec­ture en cas­cade (par exemple Nginx devant Apache).

Exemple : un site der­rière Cloud­flare peut affi­cher une erreur 502 si le ser­veur d’origine est lent à répondre ou ren­voie une erreur.

Erreur 503 : Service Indisponible (Service Unavailable)

Le ser­veur n’est pas en mesure de trai­ter la demande (la requête) pour le moment. Cela peut être dû à une sur­charge, à une inter­ven­tion de main­te­nance, ou à une res­source qui n’est pas dis­po­nible ponctuellement.

C’est une erreur tem­po­raire : elle indique au navi­ga­teur de ten­ter à nou­veau plus tard.

Exemples :
– Un site web qui subit une affluence de visi­teurs et qui dépasse la capa­ci­té de son ser­veur.
– Une main­te­nance pla­ni­fiée du site, par exemple lors d’une mise à jour WordPress.

👉 Quand une mise à jour est déclen­chée dans Word­Press, le CMS génère auto­ma­ti­que­ment un fichier .main­te­nance. Ce fichier pro­duit une erreur 503 indi­quant que le site est tem­po­rai­re­ment indis­po­nible pen­dant l’opération.

Erreur 504 : Délai d’attente de la passerelle dépassé (Gateway Timeout)

Le ser­veur n’a pas obte­nu de réponse dans les délais requis d’un autre ser­veur ou d’un ser­vice en aval. Cela peut être dû à un appel externe qui prend trop de temps (API, base de don­nées à dis­tance), ou à une confi­gu­ra­tion incor­recte du proxy ou du reverse proxy.

Exemple : une demande d’A­PI (par exemple, Stripe ou un CRM tiers) qui prend trop de temps pour répondre, empê­chant le char­ge­ment de la page.

Zoom sur la page 404 : une page indispensable

La page d’er­reur 404 est celle qui est la plus connue par­mi toutes les pages d’er­reurs. Elle indique que la page deman­dée n’existe pas ou n’est plus dis­po­nible sur le ser­veur. À l’op­po­sé d’autres erreurs, la 404 n’est pas néces­sai­re­ment une ano­ma­lie : elle est inté­grée au fonc­tion­ne­ment nor­mal du Web.

Il faut cepen­dant être vigi­lant : une page 404 qui n’est pas per­son­na­li­sée ou mal conçue peut frus­trer l’u­ti­li­sa­teur… voir, au pire, l’empêcher d’ac­cé­der aux conte­nus du site (voir ci-dessous). 

Pourquoi il ne faut jamais garder la page 404 par défaut ?

Par défaut, une page 404 se limite à signa­ler qu’un conte­nu est introu­vable, géné­ra­le­ment avec un mes­sage très tech­nique ou sans per­son­na­li­té. Cela dépeint votre site sous un jour défa­vo­rable et laisse l’u­ti­li­sa­teur sans option et dans l’in­ca­pa­ci­té de faire quoi que ce soit.

Une erreur 404 peut se produire :

• Suite à une modi­fi­ca­tion ou sup­pres­sion d’URL.
• En rai­son d’un lien défec­tueux (interne ou externe).
• Après une faute de frappe de l’utilisateur.

Ima­gi­nez-vous arri­ver pour la pre­mière fois sur un site par le biais d’un lien erro­né et tom­ber sur cette page (ci-des­sous), allez-vous persévérer ?

👉 Votre objec­tif : évi­ter le blo­cage. Il est néces­saire de pro­po­ser une alter­na­tive claire.

Comment adapter sa page d’erreur 404 ?

Que vous optiez pour un thème Word­Press, un édi­teur de pages ou du code per­son­na­li­sé, la per­son­na­li­sa­tion de la page 404 est à la fois facile et stratégique.

Voi­ci quelques suggestions :

• Pré­sen­tez un mes­sage pré­cis et apai­sant (évi­tez l’ar­got technique).
• Incor­po­rer un lien vers la page prin­ci­pale ou le moteur de recherche du site.
• Mettre l’ac­cent sur les der­niers articles, les caté­go­ries ou les pro­duits populaires.
• Uti­li­ser un élé­ment gra­phique ou un ton déca­lé (tout en res­tant clair)

💡 Sur Word­Press, vous avez la pos­si­bi­li­té de conce­voir un fichier 404.php au sein de votre thème, ou bien d’op­ter pour une exten­sion spé­ci­fique afin de per­son­na­li­ser cette page sans avoir besoin de coder.

Et côté SEO ?

Une erreur 404 n’est pas pro­blé­ma­tique en soi, à condi­tion qu’elle soit cor­rec­te­ment gérée.

Voi­ci quelques bonnes pratiques :

• Ne ren­voyez pas toutes les erreurs 404 vers la page d’ac­cueil : Google désap­prouve cette pratique.
• Si vous sup­pri­mez ou sub­sti­tuez une page, il est conseillé de faire des redi­rec­tions 301.
• Consul­tez la Search Console pour sur­veiller vos erreurs 404 et pour iden­ti­fier les liens cassés.

👉 Une bonne page d’er­reur 404 guide l’u­ti­li­sa­teur et les moteurs de recherche sur ce qui se pro­duit. C’est autant un outil d’ex­pé­rience uti­li­sa­teur qu’un signal technique.

Conclusion

Les pages d’er­reur HTTP repré­sentent un élé­ment essen­tiel du fonc­tion­ne­ment d’un site inter­net. Même si elles indiquent un sou­ci, elles peuvent éga­le­ment ser­vir comme un outil pour amé­lio­rer l’ex­pé­rience uti­li­sa­teur à condi­tion d’être cor­rec­te­ment inter­pré­tées et gérées efficacement.

Notez que :

• Les erreurs 4xx concernent les requêtes des uti­li­sa­teurs (URL erro­née, accès refu­sé, etc.).
• Les erreurs 5xx indiquent un sou­ci du côté du ser­veur (sur­charge, panne, confi­gu­ra­tion incorrecte).
• La page d’er­reur 404 doit être soi­gneu­se­ment conçue, aus­si bien pour l’u­ti­li­sa­teur que pour la per­cep­tion de votre marque.

Pour finir, n’ou­bliez pas de contrô­ler fré­quem­ment vos erreurs à l’aide des logs du ser­veur ou de la Google Search Console. Un site de confiance est éga­le­ment un site qui gère effi­ca­ce­ment les situa­tions inattendues.

Pho­to de l’image mise en avant : mer­ci à 道灵