Erreurs 500 : diagnostic et correction rapide

Pourquoi un site web affiche des erreurs 500 et comment les corriger : guide pratique de triage

Une erreur 500 est le genre de problème qui donne l’impression qu’un site est cassé sans expliquer pourquoi. Le navigateur affiche un message abrupt, le visiteur se retrouve face à une impasse, et la vraie cause se trouve souvent ailleurs. C’est pourquoi comprendre pourquoi un site web affiche des erreurs 500 et comment les corriger relève du triage, pas du hasard, et savoir comment corriger une erreur 500 commence par identifier le bon niveau de panne.

Commencez par une règle : ne supposez pas que chaque page d’erreur disgracieuse est une vraie erreur 500 côté serveur. Une 502, une 503, un délai d’attente de passerelle ou une page proxy brandée par Cloudflare peuvent être assez proches pour tromper même des équipes expérimentées. Une mauvaise étiquette fait perdre une heure, surtout quand on se demande au mauvais endroit erreur 500 site web que faire.

1. Vérifiez que l’erreur est bien une 500 côté serveur

Ouvrez la page dans une fenêtre privée et notez le libellé exact. Une erreur d’origine pure indique souvent « 500 Internal Server Error » ou une formule tout aussi générique, tandis qu’une couche proxy peut afficher son propre code, un identifiant de requête ou un message sur le serveur en amont. Cette petite différence compte, car une 502 pointe généralement vers une mauvaise réponse de passerelle, alors qu’une 503 signifie souvent que le service est temporairement indisponible.

Vérifiez la réponse via au moins 2 chemins : le navigateur et une requête en ligne de commande si vous en avez la possibilité. Si la page du navigateur affiche 500 mais que le serveur renvoie en réalité 502 à la périphérie, vous risquez de chercher au mauvais endroit. La correction dépend de la source, et il faut souvent diagnostiquer erreur 500 serveur avant d’agir.

Cloudflare, Fastly, nginx, Apache et votre application peuvent chacun marquer l’échec différemment. Un site peut afficher une page CDN soignée avec un libellé 5xx, tandis qu’un autre renvoie un simple écran blanc et une courte ligne dans le corps HTML. Même symptôme, origine différente.

2. Reproduisez l’erreur de manière contrôlée

Testez l’URL exacte qui échoue, pas seulement la page d’accueil. Une 500 sur /checkout peut être causée par un seul champ de formulaire, un hook de plugin ou une règle de routage, alors que la page d’accueil fonctionne parfaitement. Si le problème n’apparaît que sur 1 URL, votre recherche devient beaucoup plus ciblée.

Répétez la requête en faisant varier 3 paramètres : navigateur, appareil et moment. Si l’échec n’apparaît que dans Chrome sur ordinateur mais pas dans Safari sur mobile, vous observez peut-être un cas limite lié au script ou au cache. Si le problème survient seulement après l’import d’une newsletter ou à 2 h du matin, l’heure elle-même est un indice.

Rendez le test banal. Une requête, un changement, un résultat. Puis essayez la même URL avec un autre état de connexion, car les utilisateurs authentifiés déclenchent parfois des chemins de code que les visiteurs anonymes n’empruntent jamais. C’est particulièrement fréquent sur les sites avec un espace administrateur ou des tableaux de bord membres.

Gardez une trace simple : URL, heure, action et réponse. Quatre champs suffisent. Dès que vous avez 3 ou 4 entrées, des tendances commencent à apparaître.

3. Consultez le journal d’erreurs du serveur web pour repérer le premier point de défaillance

Le journal d’erreurs est généralement le premier endroit à consulter après deux échecs de la page. Faites correspondre l’horodatage de la 500 avec l’entrée de log la plus proche, puis lisez la ligne avant et la ligne après. La première ligne en dit souvent plus que la page d’erreur elle-même.

Vous cherchez un nom de script, un nom de module, un avertissement de permission ou un délai d’attente en amont. Une erreur fatale PHP peut nommer directement le fichier. Une erreur du serveur web peut mentionner un répertoire manquant, une mauvaise cible de réécriture ou une connexion refusée à un processus backend.

Une habitude utile : copiez l’horodatage exact de la requête en échec et comparez-le aux journaux d’accès et d’erreurs. Si le site est très fréquenté, l’événement « le plus proche » peut quand même être décalé de quelques secondes, alors vérifiez aussi le chemin de la requête et le code de statut. Un identifiant de requête unique, si votre pile en ajoute un, peut vous faire gagner beaucoup de temps.

Quand le journal cite un plugin, une bibliothèque ou un module, faites une pause à cet endroit. Lisez le contexte autour. Une ligne indiquant « allowed memory size exhausted » renvoie à des limites de ressources, tandis qu’une ligne « permission denied » pointe vers des problèmes de propriétaire ou de mode, même si les deux se traduisent par une 500.

4. Cherchez les déclencheurs de limites de ressources et de délais d’attente

Les erreurs 500 apparaissent souvent quand le serveur manque de quelque chose de basique. La mémoire en fait partie. Le temps d’exécution en est une autre. Le nombre de workers est la troisième. Quand l’un de ces éléments est saturé, la requête peut échouer avant la fin du chargement de la page.

Le manque de mémoire PHP est un cas classique. Un export de rapport, un redimensionnement d’image ou un import de produits peut demander plus de mémoire que le processus n’en dispose, et le résultat peut être une 500 au lieu d’un avertissement gracieux. Si l’échec commence lors de grosses requêtes et disparaît quand la charge baisse, c’est un suspect sérieux.

Vérifiez aussi les limites de temps d’exécution. Un script qui boucle trop longtemps peut atteindre un délai d’attente et laisser le serveur gérer les dégâts. Cela peut arriver pendant des imports, des tâches cron ou un appel API lent qui attend un autre service. Une seule dépendance lente suffit.

La saturation des workers ou des processus est plus facile à manquer, car le site peut sembler sain sous faible trafic. Puis 20 requêtes arrivent en même temps, la file d’attente se remplit, et de nouvelles requêtes commencent à échouer. Certains plans d’hébergement imposent aussi des limites au niveau du compte sur le CPU, les processus entrants ou les E/S, de sorte que le problème peut venir du forfait lui-même plutôt que du code.

Si votre pile dispose d’un monitoring, vérifiez si les 500 augmentent avec les pics de trafic. Une 500 qui n’apparaît que pendant une campagne, une mise en production ou une fenêtre de sauvegarde est souvent un problème de charge déguisé. C’est là que ce qui a changé dans la surveillance de site après peut aider à cadrer le type d’alertes dont vous aurez besoin ensuite.

5. Vérifiez les permissions des fichiers et des dossiers en dehors du CMS

Toutes les 500 ne viennent pas de l’application. Des fichiers peuvent appartenir au mauvais utilisateur après un déploiement, une synchronisation ou une migration. Les permissions des dossiers peuvent aussi dériver. Un simple changement de mode sur un répertoire peut bloquer l’écriture dans le cache, les logs ou les fichiers envoyés et déclencher un échec à la requête.

Vérifiez d’abord les emplacements qu’on oublie facilement : fichiers téléversés, fichiers temporaires, fichiers de configuration, artefacts de déploiement et répertoires de journaux. Si l’un de ces chemins n’est pas inscriptible par l’utilisateur du serveur web, le site peut échouer dès qu’il essaie d’écrire un fichier de session ou de créer une entrée de cache. C’est un petit problème avec un résultat bruyant.

Les problèmes de propriété sont particulièrement fréquents après une migration d’un hébergeur à un autre. Un fichier peut avoir les bons bits de permission mais le mauvais propriétaire, ce qui bloque quand même le processus. C’est le genre de détail qui donne à une 500 un air irrationnel jusqu’à ce qu’on regarde en dehors du CMS et qu’on inspecte directement la couche serveur.

Ne « corrigez » pas les permissions en ouvrant tout en grand. Un chmod 777 rapide peut masquer le problème, mais il crée aussi un désordre de sécurité et cache généralement la vraie erreur de propriété. Si vous avez besoin d’une base de sécurité pour le serveur après des changements, les recommandations plus larges du site sur la sécurité du site web valent la peine d’être gardées à portée de main pendant les tests.

6. Examinez les changements récents du serveur ou du déploiement

Remontez d’1 déploiement, d’1 changement d’hébergeur ou d’1 modification de configuration. Les 500 commencent souvent juste après un changement de version PHP, une réécriture du serveur web, une nouvelle règle de redirection ou une mise à jour de tâche cron. Si le problème a commencé après une migration, la migration elle-même peut être le déclencheur.

Les sauts de version PHP peuvent révéler du vieux code qui passait jusque-là sans bruit. Un module qui fonctionnait sur une version peut échouer sur une autre. Il en va de même pour les directives du serveur web acceptées le mois dernier mais qui déclenchent maintenant une erreur à la lecture de la configuration. Une seule ligne peut causer des dégâts.

Les règles de sécurité sont une autre cause fréquente. Une règle WAF, une nouvelle condition de pare-feu ou un durcissement du serveur peut bloquer une requête jugée suspecte, même lorsqu’elle est légitime. C’est là qu’un journal des changements vaut mieux que la mémoire, car on oublie souvent la « petite » mise à jour qui a cassé la route.

Si un déploiement a été impliqué, comparez la dernière version connue comme fonctionnelle avec la version actuelle. Vérifiez d’abord 3 choses : les fichiers de configuration, les règles de routage et toute nouvelle tâche d’arrière-plan. Le problème n’est souvent pas dans la fonctionnalité livrée, mais dans l’effet secondaire qui l’a accompagnée.

7. Restaurez le service avec le rollback le plus réduit et le plus sûr

Le rollback doit rester ciblé. Désactivez d’abord le changement côté serveur le plus récent, pas tout le système. Inversez un seul fichier de configuration, une seule règle ou une seule étape de déploiement à la fois pour voir quelle action rétablit le site. Si vous annulez tout d’un coup, vous perdez l’indice.

Commencez par l’élément le moins risqué qui a changé en dernier. Si une nouvelle règle de redirection est apparue 20 minutes avant la panne, commentez-la et testez à nouveau. Si un paramètre PHP a été modifié, remettez ce seul paramètre à sa valeur précédente et vérifiez encore. Le but est de rétablir le service, pas de faire un grand ménage spectaculaire.

Pour les déploiements de code, gardez une copie saine prête et revenez seulement à la version concernée. Pour la configuration serveur, enregistrez le fichier actuel avant toute modification afin de pouvoir comparer ligne par ligne. Cela paraît élémentaire parce que ça l’est, et ce sont justement les bases qui évitent les pannes les plus longues.

Parfois, le plus petit rollback sûr n’est pas technique. Si une tâche cron inonde le serveur toutes les 5 minutes, mettez-la en pause et observez le site. Si un script de sauvegarde épuise les ressources, déplacez son horaire avant de toucher à l’application. Le site ne se soucie pas de savoir pourquoi le serveur est fatigué.

8. Évitez que la même 500 ne revienne

Mettez en place une surveillance des journaux pour que la première répétition d’une 500 soit visible avant que les clients se plaignent. Une erreur isolée, c’est une chose. Cinq d’affilée sur la même route, c’est un schéma. Faites en sorte que l’alerte indique la route, l’horodatage et le texte d’erreur.

Déployez d’abord en préproduction. Une copie de staging détecte les mauvaises modifications de configuration et les incompatibilités de version avant qu’elles n’atteignent le trafic réel. Gardez la pile aussi proche que possible de la production, car un réglage serveur qui semble inoffensif dans un environnement de test peut échouer dans le vrai.

Centralisez le suivi des changements. Cela inclut les modifications de configuration, les mises à jour de plugins, les changements de PHP, les ajustements cron et les mises à jour de règles de sécurité. Si vous cartographiez déjà les changements du site, le blog ostohlo propose du contenu connexe dans le blog de la studio ostohlo, ce qui peut être utile quand vous avez besoin d’un historique plutôt que d’un souvenir.

Les alertes sont les plus utiles quand elles se répètent. Si la même réponse 500 revient après chaque déploiement ou chaque pic de trafic, haussez le niveau de vigilance et conservez une note d’incident courte avec 3 éléments : ce qui a changé, où cela a échoué et ce qui a corrigé le problème. Cette note devient votre réponse la plus rapide la prochaine fois, surtout lorsque la panne suivante arrive pendant une fenêtre de déploiement que vous n’aviez pas prévue.