Une erreur 500 Internal Server Error signifie que l’application, sur le serveur, a rencontré un problème qu’elle n’a pas su gérer en construisant la réponse. Contrairement à la plupart des autres erreurs, elle ne dit pas ce qui s’est passé. C’est la façon du serveur de dire « quelque chose a cassé, et je ne dirai pas quoi au visiteur ».
Le vrai message d’erreur existe pourtant : il se trouve dans un log. Ce guide montre où le trouver, quelles causes se cachent derrière la plupart des erreurs 500 et comment être le premier prévenu quand l’une d’elles apparaît.
Ce que vous apprend une erreur 500
Une erreur 500 vient de l’application elle-même, ou du serveur web qui l’exécute. Elle signifie que la requête a atteint votre code et que ce code a échoué : une exception que personne n’a interceptée, une erreur fatale, une configuration que le serveur n’a pas pu lire. C’est ce qui la distingue des erreurs de passerelle, où le problème se situe entre deux serveurs :
500 Internal Server Error : l’application a échoué en traitant la requête.
502 Bad Gateway : un proxy a reçu une réponse invalide de l’application. Consultez notre guide sur l’erreur 502.
503 Service Unavailable : le service est surchargé ou en maintenance. Consultez notre guide sur l’erreur 503.
504 Gateway Timeout : l’application a mis trop de temps à répondre. Consultez notre guide sur l’erreur 504.
Une erreur 500 sur une seule page indique généralement un bug dans le code de cette page. Une erreur 500 sur toutes les pages indique en général qu’un élément partagé a cassé : la configuration, la connexion à la base de données, un fichier que toute l’application charge.
Commencez par ce qui a changé
La plupart des erreurs 500 apparaissent juste après un changement. Avant de lire le moindre log, demandez-vous ce qui s’est passé dans la dernière heure :
Un déploiement ou un merge sur la branche principale
Une mise à jour d’extension, de thème, de framework ou du langage
Une modification d’un fichier de configuration, du .htaccess ou des variables d’environnement
Un mot de passe ou une clé d’API renouvelé
Un serveur dont le disque est plein ou dont les permissions ont changé
Si le moment correspond, annuler le changement est souvent le moyen le plus rapide de remettre le site en ligne. Cherchez la cause ensuite, sans vos clients pour témoins.
Trouver le vrai message d’erreur
La page 500 est générique, le log est précis. L’endroit où chercher dépend de votre stack :
# nginx and Apache
tail -n 50 /var/log/nginx/error.log
tail -n 50 /var/log/apache2/error.log
# PHP-FPM
tail -n 50 /var/log/php8.3-fpm.log
# Applications run by systemd
journalctl -u myapp –since « 15 min ago »
# Docker
docker logs –since 15m myapp
Repérez l’horodatage de la requête en échec. L’entrée correspondante indique généralement le fichier, la ligne et la raison : une fonction non définie, une classe manquante, une base de données qui a refusé le mot de passe.
Sous WordPress, activez le log de débogage dans wp-config.php. Il écrit les erreurs dans wp-content/debug.log sans les afficher aux visiteurs :
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
Désactivez-le une fois terminé : le log peut devenir volumineux et contenir des informations sensibles.
Causes fréquentes et solutions
Une erreur dans le code
Une exception non interceptée ou une erreur fatale dans le code qui construit la page. Le log indique le fichier et la ligne. Les déclencheurs typiques : une fonction appelée avec des données inattendues, une valeur vide alors qu’elle ne devrait pas l’être, ou du code qui fonctionne sur la machine du développeur mais qui a besoin d’une extension PHP ou d’une version de bibliothèque absente du serveur. Corrigez le code, ou revenez à la dernière version qui fonctionnait.
Une mise à jour d’extension ou de thème
Sous WordPress et les autres CMS, la mise à jour d’une extension ou d’un thème est la cause la plus fréquente. Le log indique le dossier de l’extension. Si vous n’avez plus accès à l’administration, renommez ce dossier via SSH ou SFTP pour la désactiver :
mv wp-content/plugins/some-plugin wp-content/plugins/some-plugin.disabled
Le site revient sans elle. Mettez-la ensuite à jour à nouveau, remplacez-la ou contactez son développeur avec l’erreur relevée dans le log.
Un fichier .htaccess défectueux
Sous Apache, une seule ligne erronée dans le .htaccess fait tomber tout le site avec une erreur 500. Le log d’erreurs indique Invalid command ou nomme la directive qu’il n’a pas comprise. Renommez le fichier pour tester, puis rétablissez les lignes une par une. Sous WordPress, enregistrer les réglages des permaliens en génère un nouveau.
PHP à court de mémoire
Allowed memory size of 134217728 bytes exhausted signifie qu’une requête a eu besoin de plus de mémoire que ne l’autorise memory_limit. Augmenter la limite peut aider, mais une requête qui a besoin de centaines de mégaoctets charge généralement trop de données d’un coup. Identifiez ce qu’elle charge avant de lui en donner davantage.
Permissions et propriétaires des fichiers
Après un déploiement, une restauration ou une copie manuelle, des fichiers peuvent se retrouver attribués au mauvais utilisateur. Le serveur web ne peut alors plus lire le code ni écrire dans ses dossiers de cache et d’upload, et le log indique Permission denied. Rendez la propriété à l’utilisateur sous lequel tournent le serveur web ou PHP. Les dossiers ont normalement besoin de 755 et les fichiers de 644 ; ne réglez jamais le problème avec 777.
Un disque plein
Quand le disque est plein, les applications ne peuvent plus écrire les sessions, les caches, les uploads ni les logs, et échouent d’une manière qui se termine par une erreur 500. Vérifiez l’espace et les inodes :
df -h
df -i
Les vieux logs, sauvegardes et caches sont les coupables habituels. La surveillance de serveur avec une alerte disque à 80 ou 90 % détecte le problème des jours avant qu’il ne casse le site.
Erreurs de connexion à la base de données
Un mot de passe modifié, un serveur de base de données arrêté ou une limite de connexions atteinte. L’application ne peut plus rien charger et échoue sur toutes les pages. Le log indique l’erreur de base de données. Vérifiez que la base tourne, que les identifiants de la configuration sont à jour et combien de connexions sont ouvertes par rapport à la limite.
L’erreur 500 qui renvoie un 200
Une page cassée ne le dit pas toujours. Certaines applications interceptent l’erreur et affichent une page aimable « Une erreur est survenue » avec un statut 200, et un CMS peut afficher une liste de produits vide sans broncher. Pour un outil de surveillance qui ne regarde que le code de statut, tout semble normal.
Vérifiez aussi le contenu. Un moniteur de disponibilité peut exiger qu’une page contienne un mot toujours présent quand elle fonctionne, comme le nom du produit ou « Ajouter au panier », et considérer son absence comme un échec. Notre checklist de ce qu’il faut surveiller indique quelles pages méritent ce type de vérification.
Comment la surveillance détecte les erreurs 500
Une erreur 500 après un déploiement peut passer inaperçue pendant des heures si elle ne touche qu’une page. Le paiement casse, la page d’accueil fonctionne toujours, et l’équipe l’apprend par l’e-mail d’un client ou par une baisse des ventes.
Surveillez les pages qui rapportent de l’argent. Ajoutez des moniteurs de disponibilité pour le paiement, la connexion, l’inscription et l’API, pas seulement pour la page d’accueil, avec des vérifications de contenu là où un 200 peut cacher une erreur.
Confirmez avant d’alerter. Uptimecheck vérifie jusqu’à chaque minute depuis Stockholm, Londres et New York, et confirme chaque échec depuis un second emplacement : une requête isolée en échec ne réveille personne.
Voyez ce qui a cassé. L’incident contient la réponse en échec, avec le code de statut et la page d’erreur, ainsi qu’une capture d’écran de ce qu’a vu le visiteur.
Testez des parcours complets. Une connexion ou un paiement qui échoue à l’étape trois renvoie un 200 à l’étape un. Les parcours multi-étapes enchaînent les étapes et vous indiquent laquelle a échoué.
Checklist erreur 500
Demandez-vous ce qui a changé dans la dernière heure, et revenez en arrière si le moment correspond.
Retrouvez l’horodatage de la requête en échec dans le log d’erreurs.
Lisez l’erreur : fichier, ligne et raison.
Écartez les causes habituelles : une extension, le .htaccess, la mémoire, les permissions, le disque, la base de données.
Corrigez la cause, puis supprimez les réglages de débogage que vous avez activés.
Surveillez les pages clés chaque minute, avec des vérifications de contenu là où un 200 peut cacher une erreur.
Testez les connexions et les paiements comme des parcours, pas comme des pages isolées.