Le message « Une erreur critique est survenue sur ce site » peut apparaître après une mise à jour, l’activation d’une extension ou une modification de thème. Parfois, il est remplacé par un écran blanc ou une erreur 500. Ces symptômes se ressemblent, mais ne désignent pas forcément la même panne.
La priorité est de retrouver ce qui a changé et de vérifier si l’administration WordPress reste accessible. Désactiver des extensions une par une, modifier le fichier de configuration ou augmenter la mémoire au hasard peut masquer le vrai problème et compliquer la remise en état.
Ce guide vous aide à distinguer les cas courants, à utiliser les outils de récupération disponibles et à transmettre les bonnes informations si une intervention est nécessaire.
Que signifie une erreur critique WordPress ?
WordPress affiche ce message lorsqu’une erreur PHP grave empêche une partie du site de fonctionner. Elle peut provenir d’une extension, du thème, d’un code personnalisé ou d’un environnement serveur devenu incompatible après une mise à jour. Le texte visible indique que le site a échoué, mais pas toujours quel composant est responsable.
Un écran blanc peut avoir une cause similaire, mais aussi résulter d’une réponse vide, d’un problème serveur ou d’un blocage côté navigateur ou cache. Une erreur HTTP 500 est encore plus générale : elle signifie que le serveur n’a pas pu traiter la requête, sans prouver à elle seule que WordPress a déclenché une erreur critique.
À retenir
- Notez l’heure et la première page où le problème apparaît.
- Reliez la panne à une mise à jour ou modification récente, sans supposer que ce changement est forcément la cause.
- Vérifiez séparément le site public et l’administration.
- Conservez le message exact et les journaux avant de modifier des fichiers.
Les premiers contrôles sans modifier le site
Avant d’intervenir, vérifiez si la panne est générale ou limitée à un parcours. Ouvrez plusieurs URL importantes, essayez l’administration et testez depuis une fenêtre privée ou un autre réseau. Un cache local peut afficher un état ancien ; à l’inverse, une erreur intermittente peut ne pas se reproduire à chaque essai.
Relevez :
- le texte exact affiché et le code HTTP si vous pouvez le consulter ;
- les pages touchées et celles qui fonctionnent encore ;
- l’heure du premier constat et le fuseau horaire ;
- la dernière mise à jour ou modification effectuée ;
- les courriels techniques reçus par l’adresse administrateur ;
- les changements récents côté hébergement, PHP, DNS ou certificat SSL.
Ne relancez pas plusieurs fois une opération de paiement, d’envoi de formulaire ou de publication tant que vous ne savez pas si elle a été prise en compte. Une erreur d’affichage ne signifie pas toujours que l’action côté serveur a échoué.
Utiliser le mode de récupération WordPress
Depuis WordPress 5.2, le mode de récupération peut aider à reprendre l’accès lorsqu’une erreur fatale est détectée pendant le chargement d’une page. Dans certains cas, WordPress envoie à l’adresse de l’administrateur un courriel décrivant l’incident et contenant un lien temporaire de connexion en mode de récupération.
Où chercher le message ?
Vérifiez la boîte de réception de l’adresse administrateur du site, les courriers indésirables et les filtres. Le courriel peut ne pas arriver si l’envoi depuis le serveur est mal configuré. L’absence de message ne prouve donc pas que le mode de récupération n’a pas été déclenché.
Que permet ce mode ?
Le lien peut ouvrir une session où l’extension ou le thème à l’origine de l’erreur est suspendu pour votre compte, afin de vous laisser examiner la situation. Cela ne signifie pas que le composant est réparé pour tous les visiteurs. Avant de désactiver quoi que ce soit, notez son nom, le message d’erreur et l’heure de l’événement.
N’ouvrez pas un lien de récupération transmis par une personne inconnue. Si le courriel paraît légitime, confirmez qu’il correspond au domaine du site et qu’il vient bien de la notification WordPress attendue. La documentation officielle explique les conditions du mode de récupération WordPress et ses limites.
Comment trouver la cause de l’erreur ?
La piste la plus utile est souvent la première erreur enregistrée au moment de la panne, pas le dernier message affiché dans le navigateur.
Consulter les journaux disponibles
Les journaux d’erreurs PHP ou du serveur, accessibles depuis l’hébergement, peuvent révéler un fichier, une extension ou une ligne impliquée. Notez l’heure et le chemin indiqués. Ne publiez pas ces journaux en ligne : ils peuvent contenir des chemins internes, des informations techniques ou des données sensibles.
Comparer avec les changements récents
Si la panne a commencé immédiatement après une mise à jour, celle-ci est une piste à vérifier, non une preuve définitive. Une mise à jour peut révéler une incompatibilité préexistante entre plusieurs extensions, le thème ou la version de PHP. Contrôlez aussi les modifications de code, de configuration et les changements d’hébergement effectués dans la même période.
Activer le journal de débogage uniquement si nécessaire
Si les journaux de l’hébergeur ne suffisent pas, WordPress documente des réglages de diagnostic comme WP_DEBUG et WP_DEBUG_LOG. Ils doivent être utilisés avec précaution et, sur un site public, l’affichage direct des erreurs doit rester désactivé : un message technique visible peut exposer des informations aux visiteurs.
Le journal doit être protégé, consulté par une personne autorisée puis désactivé ou sécurisé une fois le diagnostic terminé. Ne laissez pas un mode de débogage bavard en place sur un site en production. Consultez le guide officiel sur le débogage WordPress avant de toucher au fichier de configuration.
Pourquoi éviter de désactiver les extensions au hasard ?
Une extension peut sembler responsable parce que le problème est apparu juste après sa mise à jour. Mais désactiver plusieurs composants en production en même temps peut interrompre des fonctions essentielles : formulaires, paiements, espace client, sécurité ou affichage Divi.
Avant toute désactivation, vérifiez :
- si le même défaut apparaît sur toutes les pages ou seulement sur un module ;
- si le message technique mentionne précisément un fichier ou une extension ;
- si une sauvegarde exploitable et un accès à l’hébergement sont disponibles ;
- si vous pouvez reproduire le problème sur une copie de test ;
- comment revenir à l’état initial si le site se dégrade davantage.
Quand l’administration est inaccessible, la désactivation manuelle par renommage de dossier ou manipulation de base de données peut être utile dans certains scénarios, mais elle n’est pas anodine. Faites-la uniquement avec un point de restauration clair et en sachant comment rétablir exactement les noms et réglages. N’effectuez pas ce test pendant une transaction ou une période d’activité importante sans mesurer le risque.
Erreur critique, écran blanc ou erreur 500 : comment les distinguer ?
| Symptôme | Ce qu’il indique | Premier contrôle |
|---|---|---|
| Message WordPress « erreur critique » | Une erreur fatale a été détectée pendant le chargement d’une partie du site. | Courriel de récupération, journaux PHP et composant cité. |
| Écran blanc | La réponse est vide ou le contenu n’a pas pu être rendu ; plusieurs causes sont possibles. | Tester plusieurs URL, navigateur et journaux du serveur. |
| Erreur HTTP 500 | Le serveur n’a pas pu terminer la requête ; ce code ne désigne pas une cause unique. | Journal du serveur à l’heure exacte et changements récents. |
| Erreur limitée à l’administration | Le site public peut rester opérationnel alors qu’un écran de gestion échoue. | Vérifier le compte, le parcours concerné et les erreurs PHP associées. |
Ces cas peuvent se recouper. Le code HTTP, le texte affiché, la portée de la panne et les journaux doivent être examinés ensemble avant de choisir une correction.
Comment rétablir le site et vérifier la correction ?
Une correction durable doit rétablir les parcours utiles, pas seulement faire disparaître un message.
Travailler sur une copie lorsque le risque le justifie
Pour un site commercial ou un site dont la panne a plusieurs causes possibles, une copie de test réduit le risque de casser davantage la production. Avant toute restauration, vérifiez la date de la sauvegarde, les données qui seraient remplacées et la possibilité de revenir en arrière. Notre guide détaille les points à contrôler pour sauvegarder et restaurer un site WordPress.
Corriger la cause identifiée
Selon les éléments recueillis, la solution peut être une mise à jour compatible, un retour temporaire à une version précédente, la correction d’un code personnalisé, le remplacement d’un fichier endommagé ou un ajustement côté serveur. Ne combinez pas plusieurs changements sans les noter : sinon, vous ne saurez pas lequel a réglé ou aggravé la panne.
Tester les fonctions qui comptent
Après correction, contrôlez au minimum :
- la page d’accueil et les pages de services ;
- l’administration et les fonctions qui échouaient ;
- les formulaires et les courriels associés ;
- les affichages sur mobile et ordinateur ;
- les journaux d’erreurs et les éventuelles nouvelles alertes.
La réparation d’un site WordPress peut couvrir le diagnostic et le rétablissement, tandis qu’un dépannage WordPress répond à une panne qui bloque l’activité. Après remise en service, une maintenance WordPress aide à planifier les mises à jour, sauvegardes et contrôles, sans garantir qu’aucune panne ne surviendra.
Quand demander de l’aide ?
Faites-vous accompagner si l’administration est inaccessible, si les erreurs persistent après une mise à jour, si le site est utilisé pour des commandes ou des demandes clients, ou si vous ne disposez ni de sauvegarde vérifiée ni d’accès technique. Une intervention devient également prudente lorsque le journal mentionne du code personnalisé ou un composant dont vous ne connaissez pas le rôle.
Pour accélérer le diagnostic, transmettez le message exact, les URL affectées, l’heure de début, les changements récents et les actions déjà tentées. Ne communiquez pas votre mot de passe par courriel ou dans un formulaire public ; utilisez un accès temporaire et révoquez-le après intervention.
FAQ : erreur critique WordPress
Comment réparer une erreur critique WordPress ?
Commencez par noter le message et l’heure, vérifier le courriel de récupération WordPress et consulter les journaux PHP. Identifiez le composant ou changement lié à la panne avant de modifier le site. Si la cause reste incertaine, testez sur une copie et préparez un retour arrière avant toute désactivation ou restauration.
Pourquoi WordPress affiche-t-il un écran blanc ?
Un écran blanc peut être lié à une erreur PHP, une réponse vide, un problème serveur, un cache ou une incompatibilité. Il ne permet pas de désigner une extension sans vérification. Comparez plusieurs pages et consultez les journaux du serveur au moment exact de l’incident.
Le mode de récupération WordPress répare-t-il automatiquement le site ?
Non. Il peut aider un administrateur à accéder au site lorsque WordPress détecte certaines erreurs fatales. Il permet d’examiner la situation, mais le composant en cause doit encore être corrigé et les parcours publics contrôlés.
Dois-je activer WP_DEBUG sur mon site en production ?
Le débogage peut être utile pour établir un diagnostic, mais n’affichez pas les erreurs techniques aux visiteurs. Protégez les journaux, évitez d’y laisser des données sensibles et désactivez ou sécurisez les réglages après analyse. Suivez la documentation WordPress et les recommandations de l’hébergeur.
Une mise à jour peut-elle provoquer une erreur critique ?
Oui, une mise à jour peut révéler une incompatibilité entre une extension, le thème, du code personnalisé ou la version de PHP. La proximité temporelle est une piste, mais les journaux et les tests doivent confirmer la cause avant un retour arrière ou une désactivation.
Conclusion : diagnostiquer avant de corriger
Une erreur critique, un écran blanc et une erreur 500 signalent tous qu’un parcours échoue, mais leurs causes ne sont pas interchangeables. Relevez le symptôme, comparez-le aux changements récents, consultez le mode de récupération et les journaux, puis intervenez sur la cause établie. La correction est terminée seulement lorsque les pages et les fonctions importantes ont été testées, sur ordinateur comme sur mobile.
Ressources pour aller plus loin
Sur ce site : sauvegarder un site WordPress, comprendre les types de maintenance WordPress et les contrôles de sécurité essentiels.
Documentation officielle : mode de récupération WordPress ; débogage WordPress.
