Erreur 500, 502, 503 et 504 — ce qu’elles signifient et qui appeler quand elles touchent votre site

Si vous voyez cette erreur sur le site de quelqu’un d’autre — une boutique, une banque, une administration — ce n’est pas un problème de votre ordinateur ni de votre connexion. Un code qui commence par 5 signifie que le serveur, de l’autre côté, a lâché. Rechargez la page dans quelques minutes ; si cela ne suffit pas, réessayez plus tard. Il n’y a rien d’autre à faire de votre côté de l’écran.

S’il s’agit de votre site, le code d’erreur vaut plus qu’il n’y paraît. Il ne dit pas seulement que « quelque chose ne marche pas ». Il dit sur quel tronçon du chemin entre le navigateur et la base de données quelque chose a lâché — et c’est ce qui décide qui il faut appeler : l’hébergeur, le prestataire qui a réalisé le site ou le fournisseur d’un service qui se trouve entre les deux.

Cet article explique comment lire ce code. Comment être averti d’une erreur avant qu’un client ne vous appelle, nous l’expliquons dans l’article sur le monitoring de site web.

Quatre codes, quatre endroits dans la chaîne

Quand quelqu’un ouvre une page, son navigateur parle rarement directement au programme qui construit cette page. Entre les deux se trouve généralement un intermédiaire — un réseau de diffusion de contenu (CDN), un serveur web qui reçoit le trafic ou un autre serveur mandataire (proxy) — et derrière lui l'application : WordPress, une boutique, un système de gestion de contenu. L’application, à son tour, interroge une base de données et des services externes. Chacun de ces éléments peut lâcher, et chacun lâche différemment.

Les quatre codes sont définis dans la spécification HTTP, et chaque définition désigne l’endroit de la panne :

• 500 — le serveur a rencontré « an unexpected condition » qui l’a empêché de traiter la requête. Une panne dans l’application.
• 502 — le serveur, agissant comme passerelle ou mandataire, « received an invalid response » du serveur qu’il a sollicité. Une panne entre l’intermédiaire et l’application : l’application a répondu, mais mal — ou n’a pas répondu du tout parce qu’elle ne tourne pas.
• 503 — le serveur est « currently unable to handle the request due to a temporary overload or scheduled maintenance ». Un refus temporaire : surcharge ou travaux.
• 504 — l’intermédiaire « did not receive a timely response » du serveur derrière lui. L’application n’a pas répondu à temps.

D’où la première règle pour lire une erreur : vue depuis le navigateur, une panne ressemble toujours à la même chose — la page ne s’ouvre pas — mais le code dit où chercher. Un prestataire qui commence chaque incident par redémarrer le serveur ignore la moitié de l’information que le serveur lui a donnée.

Erreur 500 — erreur interne du serveur

L’erreur 500 est le code serveur le plus recherché et le plus mal compris. Elle laisse penser que « le serveur est cassé ». Elle signifie quelque chose de plus étroit : le programme qui devait traiter cette requête précise est tombé sur une situation qu’il n’avait pas prévue et s’est arrêté. Le serveur fonctionne — il a bien répondu, en donnant un code. C’est l’application qui a lâché, et souvent pour un seul type de requête.

Nous en avons un exemple récent sur notre propre site. Pendant plusieurs heures, l’envoi de fichiers dans notre système de gestion de contenu s’est soldé par une erreur 500, et dans nos notes de travail le problème a atterri dans la colonne « panne de production — on attend ». Le site fonctionnait normalement pendant tout ce temps, et les autres enregistrements passaient sans problème. La cause était la forme de la requête elle-même : un champ était envoyé dans un format que l’application n’acceptait pas pour les envois de fichiers. Une fois la requête corrigée, le même serveur a accepté le même fichier du premier coup. La leçon est générale : une erreur 500 dit que quelque chose a planté dans le code qui traite cette requête. Avant de chercher une panne de serveur, il vaut la peine de vérifier si l’erreur apparaît partout ou seulement pour une action.

Sur les sites WordPress, la cause d’une erreur 500 est généralement l’une de ces trois :

• Une extension ou un thème — le plus souvent juste après une mise à jour, quand la nouvelle version n’est pas compatible avec le reste. C’est pourquoi on met à jour élément par élément, avec une sauvegarde avant : on sait alors quoi annuler.
• La version de PHP — un changement sur le serveur après lequel un code plus ancien cesse de fonctionner. Cela peut arriver sans aucune action de votre part, quand l’hébergeur désactive une ancienne version.
• Une limite de ressources — un script a dépassé la mémoire ou le temps que le serveur autorise. Typique lors de gros imports, de la génération de miniatures et des sauvegardes réalisées par une extension.

Le journal d’erreurs du serveur — accessible dans l’interface de l’hébergeur ou chez votre prestataire — indique généralement la cause directement, avec le nom du fichier et le numéro de ligne. La première question à poser à votre prestataire face à une erreur 500 est donc : que dit le journal d’erreurs pour cette minute-là ? La réponse « on a redémarré le serveur et ça marche » signifie que personne n’y a regardé, et l’erreur reviendra à la prochaine requête identique.

Erreur 500 — comment la corriger, étape par étape

Voici l’ordre qui mène le plus souvent à la cause par le chemin le plus court — y compris quand c’est votre prestataire qui s’en charge et que vous voulez savoir s’il s’y prend bien :

1. L’erreur apparaît-elle partout, ou pour une seule action ? Page d’accueil, sous-page, administration, formulaire, panier. Une erreur limitée à une action restreint la recherche à une seule fonction — et exclut presque la « panne de serveur ».
2. Le journal d’erreurs de cette minute-là. Dans l’interface de l’hébergeur ou chez votre prestataire. Dans WordPress, on peut aussi activer l’écriture des erreurs dans un fichier du dossier wp-content — un réglage qui consigne les erreurs dans un journal au lieu de les montrer aux visiteurs.
3. Le dernier changement. Une mise à jour, une nouvelle extension, un changement de version de PHP, une mise en production. Si l’erreur a commencé juste après, annuler ce seul changement est plus rapide que chercher la cause.
4. Désactiver l’extension fautive sans l’administration. Si vous ne pouvez pas entrer dans l’administration, on désactive une extension en renommant son dossier sur le serveur — WordPress cesse alors de la charger. Nous décrivons la même méthode dans l’article sur les mises à jour.
5. Une sauvegarde, si la cause reste invisible. Restaurer l’état d’avant la panne revient à décider combien de données depuis ce moment vous êtes prêts à perdre — c’est pourquoi c’est au propriétaire de trancher, et pourquoi la condition est une sauvegarde que quelqu’un a déjà restaurée au moins une fois.

Pour les erreurs 502 et 503, l’ordre est semblable ; seulement, l’étape deux concerne le journal de l’intermédiaire et la charge du serveur, et l’étape trois les mises en production et les changements de formule d’hébergement.

« Il y a eu une erreur critique sur ce site »

Les propriétaires de sites WordPress voient ce message plus souvent qu’un simple code 500. WordPress lui-même, depuis la version 5.2, intercepte les erreurs les plus graves de l’application : au lieu d’une page blanche, il affiche aux visiteurs un message indiquant que le site rencontre des difficultés techniques.

Ce qui se passe en arrière-plan compte davantage. Selon la note de l’équipe WordPress, le système envoie alors un message à l’adresse e-mail de l’administrateur du site avec un lien secret vers le mode de récupération. En suivant ce lien, les extensions ou thèmes à l’origine de l’erreur sont mis en pause — mais uniquement pour la personne qui a utilisé le lien. Elle peut se connecter à l’administration, désactiver l’extension fautive ou restaurer la version précédente, pendant que les visiteurs voient toujours le message d’erreur.

Le mécanisme fonctionne bien, à une condition : quelqu’un doit recevoir ce message. L’adresse de l’administrateur est définie à l’installation et rarement revue. Si le site a été mis en place il y a quelques années par une agence ou par un collaborateur qui a quitté l’entreprise, le lien de récupération arrive dans une boîte que personne ne lit. C’est le même problème que celui que nous décrivons dans l’article sur le contrat de maintenance, à propos du domaine et des accès : les adresses de contact des systèmes dont dépend votre site doivent mener à quelqu’un dans l’entreprise. La vérification prend une minute — dans l’administration de WordPress, sous les réglages généraux.

Erreur 502 Bad Gateway — ce que cela signifie

« Bad Gateway » signifie à peu près « mauvaise passerelle ». La passerelle, c’est l’intermédiaire : le serveur qui reçoit la requête du navigateur et la transmet à l’application. Une erreur 502 signifie que l’intermédiaire a demandé la page à l’application, et que ce qui est revenu ne pouvait pas être transmis — ou que rien n’est revenu, parce que l’application n’a pas accepté la connexion.

En pratique, une erreur 502 signifie le plus souvent que le programme qui produit le site derrière l’intermédiaire ne tourne pas ou est en train de redémarrer. Le serveur web est debout, le réseau fonctionne, mais le processus qui devait générer la page est tombé — faute de mémoire, après une erreur ou pendant la mise en production d’une nouvelle version. C’est pourquoi une erreur 502 peut être brève : elle apparaît quelques dizaines de secondes pendant une mise à jour, puis disparaît.

Ce que cela implique pour le propriétaire :

• Une 502 de quelques secondes pendant une mise en production tient généralement à la façon dont les mises en production sont faites, pas à une panne. On peut l’éviter, mais c’est une décision sur le processus de mise en production, pas une réparation.
• Une 502 qui revient sans mise en production est une application qui plante. La question pour votre prestataire : pourquoi le processus s’arrête-t-il, et que contient son journal ?
• Une 502 renvoyée par votre CDN — si le site est derrière un réseau de diffusion de contenu — signifie que le CDN fonctionne mais n’arrive pas à joindre votre serveur. On vérifie d’abord le serveur, pas le CDN.

Le même code s’affiche souvent accompagné d’autres mots : « 502 Bad Gateway nginx », « HTTP 502 », « 502 Proxy Error ». Tous signifient la même chose. Le mot qui suit le code est simplement le nom de l’intermédiaire qui l’a signalé — ici, le serveur web nginx — et il vous dit quel journal ouvrir.

Erreur 503 — service temporairement indisponible

L’erreur 503 est le seul de ces codes qu'un site devrait parfois renvoyer volontairement. La spécification le prévoit pour deux situations : la surcharge et les travaux planifiés. Dans les deux cas, le serveur peut ajouter un en-tête Retry-After qui indique quand il vaut la peine de réessayer.

La surcharge signifie que le serveur reçoit plus de requêtes qu’il ne peut en traiter et en refuse une partie plutôt que de toutes les servir trop lentement. Chez un hébergement mutualisé, une erreur 503 peut aussi être la manière dont l’hébergeur signale que le site a dépassé les ressources qui lui sont attribuées. Si elle apparaît régulièrement aux heures de pointe, c’est le signe que la formule d’hébergement est trop petite ou que le site consomme trop par page affichée — ce qui se voit généralement aussi dans les Core Web Vitals.

Les travaux planifiés sont la deuxième situation, et la règle est simple : si le site doit être indisponible un moment, qu’il réponde par une erreur 503, et non par une page « maintenance en cours » renvoyant le code 200. Pour un visiteur, les deux se ressemblent. Pour un moteur de recherche, la première signifie « revenez plus tard », la seconde « voici à quoi ressemble cette page désormais ». WordPress le fait lui-même lors des mises à jour : le temps de l’installation, il affiche un court message de maintenance avec exactement ce code, 503, et un en-tête Retry-After réglé sur 600 secondes — c’est ainsi que c’est écrit dans son code source.

Erreur 504 Gateway Timeout

L’erreur 504 est proche parente de la 502, à une différence près : l’intermédiaire n’a pas reçu une mauvaise réponse — il n’en a reçu aucune à temps. L’application travaillait, mais si longtemps que l’intermédiaire a cessé d’attendre.

Les causes typiques sont des opérations longues par nature, déclenchées pendant un affichage de page ordinaire : un import de produits, la génération d’un rapport, une sauvegarde lancée par une extension, une requête lente sur une base contenant beaucoup d’entrées, un service externe — paiement, transporteur, système de stock — qui répond lui-même lentement. Chacune peut fonctionner correctement et provoquer quand même une erreur 504, parce que l’intermédiaire a son propre délai d’attente, indépendant de l’application.

C’est pourquoi une erreur 504 se corrige rarement « sur le serveur ». Elle se corrige dans l’application : on déplace les opérations longues vers des tâches exécutées en arrière-plan au lieu de les lancer pendant l’affichage de la page, et on optimise les requêtes lentes. Relever le délai de l’intermédiaire peut servir de contournement rapide, mais cela signifie seulement que les visiteurs fixeront plus longtemps une page qui charge avant de voir le même problème.

Les codes 52x derrière Cloudflare

Si votre site se trouve derrière Cloudflare — comme beaucoup de sites, dont le nôtre — vous verrez souvent, à la place des 502 et 504, des codes de la série 52x. Ce ne sont pas des codes de la spécification HTTP, mais des désignations propres à Cloudflare, qui précisent ce qui s’est mal passé entre lui et votre serveur. Selon la documentation de Cloudflare :

• 520 — le serveur web a renvoyé une erreur inconnue,
• 521 — le serveur web est hors service (il a refusé la connexion),
• 522 — le délai de connexion est dépassé,
• 524 — le délai d’attente de la réponse est dépassé.

Les quatre disent la même chose que les 502 et 504 : Cloudflare fonctionne, le problème est derrière lui, sur votre serveur ou en chemin vers celui-ci. Contacter l’assistance de Cloudflare change rarement quelque chose ; contacter votre hébergeur, généralement oui.

Ce que Google fait des erreurs serveur

Une panne courte ne nuira pas à votre positionnement. Une panne longue, si — et Google décrit ce mécanisme assez précisément dans sa documentation.

Les erreurs 5xx — ainsi que le 429 — amènent les robots de Google à ralentir temporairement la récupération des pages de votre serveur, proportionnellement au nombre d’adresses qui renvoient une erreur. Les adresses indexées restent dans l’index, mais celles qui renvoient durablement une erreur serveur finissent par en être retirées. Dès que le serveur répond de nouveau correctement, Google revient progressivement à son rythme habituel.

En pratique, le plus dangereux n’est donc pas une erreur isolée, mais une erreur dont personne n’a connaissance : une page de boutique qui renvoie une erreur 500 depuis une semaine pour un type de produit, une sous-page avec un formulaire qui a cessé de fonctionner après une mise à jour. Ces adresses disparaissent des résultats sans bruit. Dans Search Console, elles apparaissent dans le rapport d’indexation des pages comme erreurs serveur — et c’est l’un des rares rapports qui mérite d’être consulté chaque semaine plutôt que chaque trimestre.

429 Too Many Requests — quand le site se défend

Le 429 n’est pas un code de la série 5xx, mais il appartient à la même discussion. La spécification le définit comme la réponse à un trop grand nombre de requêtes en peu de temps — un mécanisme de protection contre les robots, les attaques et le trafic excessif. Comme pour le 503, le serveur peut indiquer un Retry-After.

Le propriétaire d’un site devrait le connaître pour une raison : un pare-feu qui protège le site contre les robots peut aussi bloquer ceux des moteurs de recherche. Google traite le 429 comme une erreur serveur et ralentit ; si cela dure, les conséquences sont celles de toute erreur persistante. Après avoir activé une nouvelle protection contre les robots — chez l’hébergeur, dans le CDN ou par une extension — vérifiez dans Search Console que le robot de Google n’a pas commencé à essuyer des refus.

Qui appeler — code, emplacement, destinataire

Un code d’erreur ne remplace pas un diagnostic, mais il permet de commencer par la bonne personne.

Si une entreprise externe s’occupe de votre site, ce tableau sert aussi à tester votre contrat : sait-on qui est le destinataire de chaque ligne, et dans quel délai il doit réagir ? Comment l’inscrire dans le contrat, nous l’expliquons dans l’article sur le contrat de maintenance.

Ce que cet article laisse volontairement de côté

• Les erreurs 404, 403, 401 et 400 — ce sont des erreurs côté requête, avec un autre diagnostic et un autre destinataire ; nous les traitons, avec une carte de tous les codes, dans l'article sur l’erreur 404.
• Les redirections 301 et 302 — la migration de site web, où elles sont au cœur de toute l’opération.
• Comment repérer une erreur avant un client — le monitoring de site web.
• La restauration du site quand la cause reste introuvable — une sauvegarde que quelqu’un a déjà restaurée.

Le résumé le plus court : un code d’erreur serveur est une adresse, pas un diagnostic. Une 500 renvoie à l’application et à son journal, les 502 et 504 à la liaison entre l’intermédiaire et l’application, la 503 à la charge ou aux travaux, les 52x au serveur derrière Cloudflare. Et avant de conclure que « le serveur est en panne », vérifiez si l’erreur apparaît partout ou seulement pour une action — notre propre erreur 500 était justement du second type.