Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

Écrire un message contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

Erreur 500 ou page blanche : d’où vient la panne

Une erreur 500 n’est pas un diagnostic, c’est un aveu d’échec poli. Le serveur a reçu la demande, a lancé le programme, et le programme s’est arrêté avant d’avoir produit une réponse valable. Une page entièrement blanche relève du même mécanisme, simplement affichée autrement. Le motif réel a été écrit quelque part — pas à l’écran, pour des raisons de sécurité. Tant qu’on ne l’a pas lu, tout ce qu’on tente relève de la devinette.

Décrire mon problème Écrire un message

Ce que le code 500 exclut déjà

Avant de chercher, il est utile de noter tout ce que ce code élimine. Le nom de domaine se résout correctement, sinon rien n’aurait répondu. Le serveur web fonctionne, puisque c’est lui qui a produit la page d’erreur. Le réseau fonctionne. Le compte d’hébergement n’est pas suspendu.

Le champ des causes se réduit donc à l’exécution du site : configuration du serveur pour ce site, code applicatif, ou ressources allouées à cette exécution précise. C’est une bonne nouvelle, parce que ces trois familles se distinguent par des indices simples, et qu’aucune ne demande d’attendre une réponse d’un tiers.

Cette page décrit le mécanisme commun à toutes les plateformes. Sur une boutique PrestaShop, les emplacements précis — var/logs, la constante _PS_MODE_DEV_, le dossier override/ — et les causes propres à la plateforme sont détaillés dans la page consacrée à l’erreur 500 PrestaShop. Sur WordPress, le même symptôme prend la forme de l’erreur critique WordPress.

Les causes que je rencontre, par ordre de fréquence

  • Configuration : une directive invalide dans un fichier de configuration lu par le serveur suffit à renvoyer un 500 sur toutes les pages, y compris avant que le CMS ne démarre. Une ligne ajoutée par un module de cache ou de sécurité en est souvent l’origine.
  • Code applicatif : appel à une fonction supprimée, module incompatible avec la version de PHP, surcharge écrite pour une version antérieure du cœur, cache compilé qui référence des fichiers disparus, ou simple erreur de syntaxe introduite en modifiant directement un fichier de thème — une accolade ou un point-virgule manquant suffit.
  • Ressources : mémoire allouée insuffisante pour la page demandée, limite de processus atteinte, espace disque plein empêchant l’écriture des fichiers temporaires.
  • Droits : un fichier ou un répertoire dont les permissions sont refusées par le serveur, notamment quand elles sont trop ouvertes sur certaines configurations d’hébergement partagé.

Retrouver le message réel

  1. Noter la portée avant tout

    Tout le site, une seule page, uniquement l’administration, ou seulement certaines fiches ? Une erreur globale oriente vers la configuration ou le serveur ; une erreur ciblée oriente vers un module ou une donnée précise.

  2. Ouvrir le journal d’erreurs du serveur

    C’est là que se trouve le message complet, avec le fichier et la ligne. Chez la plupart des hébergeurs il est accessible depuis le panneau, sans intervention du support.

  3. Chercher aussi le journal applicatif

    Le CMS tient son propre journal, distinct de celui du serveur. Les deux se complètent : le premier donne l’erreur technique, le second le contexte fonctionnel.

  4. Activer le mode de débogage le temps d’un essai

    Il fait réapparaître le message à l’écran. Il se désactive immédiatement après : laissé actif, il expose des chemins et des noms de tables à tous les visiteurs.

  5. Mettre de côté le fichier de configuration suspect

    Si l’erreur touche tout le site, renommer temporairement le fichier de configuration lu par le serveur dit en une seconde s’il en est l’origine.

  6. Rapprocher de la dernière intervention

    Mise à jour, installation d’un module, modification d’un fichier de thème : la panne suit presque toujours une action, même faite par quelqu’un d’autre, et même plusieurs jours plus tôt si un cache en retardait l’effet.

Quand la même panne s’affiche en page blanche

Selon la configuration du serveur, la même erreur fatale produit un écran d’erreur 500 chez l’un et une page entièrement blanche chez l’autre. Une page blanche n’est donc pas une absence de réponse : le serveur a répondu, le programme s’est arrêté en cours de route, et le message est parti dans un journal. La méthode ci-dessus s’applique telle quelle.

Un seul geste supplémentaire divise le champ des causes par deux : afficher le code source de la page. Si la fenêtre est vide, l’exécution s’est arrêtée avant d’écrire quoi que ce soit — erreur fatale de PHP ou dépassement de mémoire, exactement le même terrain qu’un 500. S’il y a du HTML mais rien de visible, le programme a fonctionné et c’est l’affichage qui est cassé : feuille de style non chargée, gabarit vide, script qui masque le contenu. Ce second cas ne se lit pas dans le journal du serveur, mais dans la console du navigateur.

Reste le cas intermédiaire, le plus riche en information : la page s’affiche à moitié puis s’arrête au milieu d’une phrase. L’exécution a été interrompue en cours d’écriture, et l’endroit exact de la coupure désigne le bloc de page en cause.

L’erreur qui ne touche qu’une partie du site

C’est le cas le plus riche en information, et le plus souvent mal exploité. Une erreur 500 limitée à une seule page signifie que le code fautif n’est exécuté que là. Ce qui distingue cette page des autres est donc la piste directe : un module accroché à cet emplacement seulement, une donnée particulière, un champ vide, une déclinaison mal formée.

  • Sur l’administration uniquement : presque toujours un module chargé côté administration, ou une page listant trop d’enregistrements.
  • Sur quelques fiches produit seulement : chercher ce que ces fiches ont en commun, pas ce qui les distingue entre elles.
  • Au moment de valider une commande : le champ des causes se réduit au tunnel et aux modules de paiement ou de transport.
  • De façon intermittente : c’est une limite de ressources, pas un défaut de code.

Continuer sur la bonne page

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Où en est votre boutique en ce moment ?
Sur quelle plateforme tourne le site ?
Que s’est-il passé juste avant la panne ?

C’est souvent l’information qui fait gagner le plus de temps au diagnostic.

De quels accès disposez-vous ? (facultatif)

Sans accès, la première étape sera de les récupérer — cela change le délai.

Quelle est l’adresse du site concerné ? (facultatif)

Un premier coup d’œil avant même la réponse permet souvent de dégrossir le diagnostic.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Une erreur 500 signifie-t-elle que mes données sont perdues ?
Non. Elle signale une exécution interrompue, pas une destruction. Les données restent en base, et dans la grande majorité des cas le site redevient normal dès que la cause de l’interruption est levée.
Pourquoi le message d’erreur n’est-il pas affiché directement ?
Parce qu’un site en production est configuré pour ne jamais exposer un chemin de fichier, un nom de table ou un identifiant. Ce serait une information exploitable. Le détail part donc dans un journal, accessible à vous seul.
L’erreur 500 est-elle un problème d’hébergement ?
Rarement au sens strict. Le serveur fonctionne puisqu’il renvoie cette page. L’hébergement est concerné quand la cause est une limite de mémoire, un disque plein ou un changement de version de PHP imposé — mais le correctif reste le plus souvent côté site.
Puis-je juste désactiver les modules un par un ?
C’est une méthode valable avec un accès aux fichiers et une sauvegarde préalable. Elle devient risquée quand la désactivation doit passer par la base de données, où une manipulation approximative coûte plus cher que la panne.
L’erreur est apparue sans que personne ne touche au site, est-ce possible ?
Oui : changement de version de PHP décidé par l’hébergeur, disque saturé, quota de base atteint, ou expiration d’une clé utilisée par un module. Aucun de ces événements ne demande d’action de votre part.
Faut-il tout réinstaller pour s’en sortir ?
Presque jamais. Une réinstallation détruit les personnalisations et ne corrige pas une incompatibilité de version, qui réapparaîtra au premier chargement. Lire le message d’erreur coûte quelques minutes et évite une remise à zéro dont on ne revient pas.

Pages liées