500 Internal Server Error

Ce que signifie cette erreur et comment la reconnaître

• Le navigateur affiche une page 500 Internal Server Error vide, générique ou personnalisée.
• Une page qui fonctionnait auparavant échoue après une modification du code, l’installation ou la mise à jour d’un plugin ou d’un thème, un déploiement ou un changement de configuration.
• Seules certaines URL, certains formulaires, écrans d’administration ou fonctionnalités du site échouent, tandis que le reste du site demeure disponible.
• Un log PHP, applicatif ou du serveur web enregistre une erreur fatale, une erreur de syntaxe, un problème de permissions, une dépendance manquante ou un dépassement de ressources au même moment.
• Répéter la requête produit la même réponse 500, même si des échecs intermittents peuvent se produire lorsqu’une limite de ressources ou une dépendance applicative est en cause.

Causes principales, classées par probabilité

1. Échec du code applicatif, d’un plugin, d’un thème ou d’un module — Une erreur de syntaxe, une erreur fatale, une mise à jour incompatible ou une condition non gérée peut empêcher la requête d’aboutir.
2. Configuration Apache invalide — Une directive mal formée ou non prise en charge dans .htaccess, ou une règle nécessitant un module désactivé, peut déclencher une réponse 500. .htaccess s’applique aux configurations basées sur Apache, et non à tous les serveurs web.
3. Permissions ou propriété incorrectes des fichiers ou répertoires — Des téléversements manuels, des migrations et des déploiements peuvent empêcher le processus web de lire les fichiers requis.
4. Épuisement de la mémoire ou du temps d’exécution PHP — De gros imports, des requêtes coûteuses ou des extensions gourmandes en ressources peuvent dépasser les limites configurées ; certains environnements renvoient alors une erreur 500.
5. Configuration ou dépendances de déploiement manquantes — Des identifiants de base de données modifiés, une variable d’environnement absente, un package indisponible ou un runtime incompatible peuvent interrompre l’application.
6. Fichiers d’application ou du CMS incomplets ou corrompus — Une mise à jour interrompue peut laisser des fichiers du cœur manquants ou endommagés.

Comment corriger le problème

1. Confirmer la portée et l’heure de l’échec

Rechargez l’URL exacte qui renvoie une erreur 500 et notez l’heure, y compris le fuseau horaire. Vérifiez si l’ensemble du site échoue ou si le problème concerne uniquement une route, un formulaire, un écran d’administration, une fonctionnalité de plugin ou un type de requête. Un échec limité à une fonctionnalité rend son code et ses dépendances récents plus suspects ; un échec généralisé oriente davantage vers la configuration du serveur, le déploiement ou les fichiers du cœur.

2. Vérifier d’abord les logs pertinents

Consultez le error_log PHP, le log d’erreurs du serveur web et le log de l’application ou du CMS disponibles sur l’hébergement. Les emplacements courants incluent /var/log/apache2/error.log pour Apache et /var/log/nginx/error.log pour Nginx, mais l’organisation varie selon l’hébergeur. Faites correspondre les entrées avec l’heure de l’échec et notez le fichier, le numéro de ligne, l’exception, le message upstream ou la directive de configuration. La page générique affichée par le navigateur ne suffit pas à identifier la cause.

3. Isoler une modification récente du code ou d’une extension

Si le log identifie un fichier, un plugin, un thème, un module ou une modification de déploiement, annulez cette modification ou désactivez le composant concerné dans un environnement testable. Sur un CMS, utilisez l’espace d’administration lorsqu’il est disponible. Si l’espace d’administration est inaccessible, SFTP ou le gestionnaire de fichiers de l’hébergeur peut vous permettre de renommer le répertoire du composant concerné. Modifiez un seul composant à la fois, puis retestez l’URL en échec. Si l’erreur disparaît, examinez la compatibilité, la configuration et les mises à jour disponibles avant de le réactiver.

4. Tester .htaccess uniquement avec Apache

Si le log signale une erreur d’analyse de .htaccess ou si l’échec a commencé après une modification d’une règle Apache, effectuez une sauvegarde et renommez temporairement .htaccess en .htaccess.bak via SFTP ou le gestionnaire de fichiers de l’hébergeur. Retestez la page. Si elle fonctionne, restaurez ou recréez soigneusement le fichier et ajoutez les directives personnalisées progressivement. Une directive non prise en charge ou un module Apache manquant peut être à l’origine du problème. N’appliquez pas cette étape à une configuration utilisant uniquement Nginx, où .htaccess n’est pas utilisé pour configurer les requêtes.

5. Corriger prudemment les permissions et la propriété

Lorsque le log signale un problème de permissions ou de propriété, comparez le chemin concerné avec un fichier fonctionnel ou avec les paramètres documentés par l’hébergeur. 644 pour les fichiers et 755 pour les répertoires sont des paramètres courants, mais les valeurs correctes dépendent de l’hébergeur et du modèle de déploiement. Corrigez le chemin concerné via SFTP, SSH ou le gestionnaire de fichiers de l’hébergeur, et ne rendez pas les fichiers ou répertoires accessibles en écriture à tous comme solution de facilité.

6. Examiner les limites de ressources PHP et de l’application

Si le log mentionne un épuisement de la mémoire, un temps d’exécution maximal ou une limite similaire, identifiez l’opération qui consomme la ressource, comme un import volumineux ou une tâche coûteuse d’un plugin. N’ajustez memory_limit ou max_execution_time dans le php.ini, .user.ini, les paramètres de l’hébergement ou la configuration de déploiement que si votre hébergeur l’autorise. Réduisez également la charge ou corrigez l’opération inefficace ; augmenter une limite peut seulement reporter l’échec.

7. Comparer les paramètres de déploiement et les fichiers requis

Pour les échecs apparus après un déploiement ou une migration, comparez les variables d’environnement, les identifiants de base de données, les versions du runtime, les dépendances installées, les chemins de fichiers et la configuration générée avec l’environnement fonctionnel. Vérifiez que les fichiers requis sont présents et que l’application peut accéder à la base de données ou au service configuré. Utilisez la variable, le package ou l’erreur de connexion manquant indiqué dans le log comme point de départ, plutôt que de modifier des paramètres sans rapport.

8. Restaurer les fichiers endommagés uniquement après avoir conservé les éléments de preuve

Si une mise à jour incomplète ou un fichier du cœur corrompu est en cause, enregistrez le log pertinent et une copie des fichiers actuels avant toute réparation. Restaurez ensuite des fichiers connus comme fiables ou relancez le processus de mise à jour pris en charge par la plateforme, en utilisant une sauvegarde si elle est disponible. Retestez l’URL d’origine et vérifiez qu’aucune nouvelle erreur correspondante n’est inscrite dans le log.

Prévention et vérification du correctif

• Sauvegardez les fichiers et la base de données avant d’installer ou de mettre à jour un plugin, un thème, un module ou un composant du CMS.
• Testez les modifications du code et de .htaccess sur une copie de staging lorsque c’est possible, et conservez une configuration connue comme fiable pour pouvoir revenir en arrière.
• Déployez les variables de configuration et les dépendances de manière cohérente entre les environnements, et vérifiez les fichiers requis après les migrations.
• Surveillez les logs d’erreurs PHP, de l’application et du serveur web au lieu de vous fier uniquement aux vérifications externes de disponibilité.
• Effectuez une seule modification à la fois, notez ce qui a changé et retestez l’URL exacte qui a échoué.
• Conservez les diagnostics détaillés dans les logs côté serveur au lieu de les afficher aux visiteurs sur un site en production.

Questions fréquentes