Le message « Une erreur critique est survenue sur votre site » apparaît lorsqu’une erreur PHP empêche WordPress de poursuivre son exécution. L’administration peut devenir inaccessible, une page blanche peut s’afficher ou le site peut retourner une erreur 500. La priorité n’est pas de modifier plusieurs réglages au hasard : il faut préserver les preuves, identifier le changement récent, isoler le composant responsable et revenir à un état stable. Une maintenance site WordPress structurée réduit fortement le délai de rétablissement et limite les pertes de contenu ou de commandes.
Si les journaux ne permettent pas d’isoler la cause ou si l’administration reste bloquée, notre service de dépannage WordPress peut prendre le relais. Avant une restauration, vérifiez le périmètre des fichiers et de la base avec notre guide des sauvegardes WordPress.
Ce que signifie réellement une erreur critique WordPress
WordPress affiche ce message lorsqu’une erreur fatale PHP se produit dans le cœur, un thème, une extension ou du code personnalisé. Les causes fréquentes sont une extension incompatible avec la version de PHP, une mise à jour interrompue, une fonction supprimée, un fichier corrompu, une mémoire PHP insuffisante ou un conflit entre deux extensions.
Le message public ne donne généralement pas la cause exacte. Si l’adresse e-mail de l’administrateur est correctement configurée, WordPress peut envoyer un e-mail contenant un lien vers le mode de récupération. Ce lien est temporaire : utilisez-le pour vous connecter et désactiver l’extension ou le thème signalé. Il ne remplace pas l’analyse des journaux d’erreurs, surtout si aucun e-mail n’est reçu.
Agir dans le bon ordre pour éviter d’aggraver la panne
1. Vérifier l’étendue de l’incident
Testez le site dans une fenêtre de navigation privée, puis contrôlez une page publique, une page d’article, le formulaire de contact et l’URL de connexion à l’administration. Si une boutique est concernée, vérifiez également le panier, le paiement et les e-mails de commande. Une erreur limitée à l’administration ne se traite pas de la même manière qu’un site entièrement indisponible.
Notez l’heure de début, la dernière action réalisée et les mises à jour effectuées : extension installée, renouvellement de certificat, modification de thème, changement de version PHP ou intervention d’un prestataire. Cette chronologie est souvent plus utile qu’une succession de tentatives sans trace.
2. Mettre de côté toute action risquée
Ne lancez pas une nouvelle mise à jour, ne supprimez pas de fichiers et ne restaurez pas immédiatement une sauvegarde ancienne. Commencez par télécharger une copie des fichiers et exporter la base de données depuis l’hébergeur si cela reste possible. Cette copie permet de conserver les contenus récents et les éléments nécessaires au diagnostic.
Si le site reçoit des commandes ou des formulaires, informez temporairement les visiteurs avec une page de maintenance servie par l’hébergeur ou par un mécanisme externe au site en panne. Évitez d’activer un plugin de maintenance si l’administration elle-même est instable.
Identifier la cause avec les journaux WordPress et serveur
Activer le journal de débogage sans afficher les erreurs aux visiteurs
Dans le fichier wp-config.php, situé à la racine de l’installation, activez le débogage en gardant l’affichage désactivé. Définissez WP_DEBUG sur true, WP_DEBUG_LOG sur true et WP_DEBUG_DISPLAY sur false. Placez ces constantes avant la ligne indiquant d’arrêter les modifications. Rechargez ensuite une seule fois la page qui déclenche l’erreur.
Consultez le fichier wp-content/debug.log s’il est créé. Recherchez la dernière ligne contenant « Fatal error », « Uncaught Error » ou « Allowed memory size ». Le chemin affiché est déterminant : un chemin vers wp-content/plugins/nom-extension indique généralement l’extension en cause ; un chemin vers wp-content/themes/nom-theme oriente vers le thème ou son thème enfant.
Consulter aussi les logs de l’hébergement
Le journal PHP ou error log accessible dans le panneau d’hébergement peut contenir une erreur que WordPress n’a pas enregistrée. Il est particulièrement utile pour les erreurs 500, les problèmes de droits de fichiers, les limites de mémoire et les incompatibilités de version PHP. Relevez le message complet, la date, le fichier et le numéro de ligne avant toute correction.
Après le diagnostic, désactivez WP_DEBUG sur un site de production. Un fichier debug.log peut contenir des chemins internes, des requêtes ou des informations qu’il ne faut pas laisser accessibles ou s’accumuler inutilement.
Isoler une extension ou un thème fautif
Quand l’administration est accessible
Dans Extensions, désactivez d’abord l’extension citée dans les journaux ou celle mise à jour juste avant l’incident. Videz ensuite les caches applicatifs et serveur, puis testez les pages concernées. Si le site revient, ne réactivez pas immédiatement l’extension : vérifiez sa compatibilité avec votre version de WordPress et de PHP, consultez son journal des modifications et testez une mise à jour sur une copie de préproduction.
Quand l’administration est inaccessible
Connectez-vous par SFTP ou utilisez le gestionnaire de fichiers de l’hébergeur. Dans wp-content/plugins, renommez uniquement le dossier de l’extension suspecte, par exemple « mon-extension » en « mon-extension-desactivee ». WordPress ne la chargera plus. Rechargez le site. Si vous ne connaissez pas le coupable, renommez temporairement le dossier plugins en « plugins-off » pour désactiver toutes les extensions, puis restaurez son nom et isolez-les une par une.
Si les logs désignent le thème, renommez le dossier du thème actif dans wp-content/themes. WordPress peut basculer vers un thème standard présent sur le serveur. Assurez-vous donc qu’un thème par défaut compatible est bien installé. Ne supprimez pas le thème : le renommage est réversible et préserve ses fichiers.
Restaurer une sauvegarde sans perdre inutilement de données
La restauration est la bonne décision lorsque les fichiers sont altérés, qu’une mise à jour a échoué ou que l’origine du problème reste incertaine. Choisissez le point de restauration le plus récent connu comme fonctionnel, mais contrôlez d’abord sa date et son périmètre. Une sauvegarde doit idéalement contenir à la fois les fichiers WordPress, la base de données et les fichiers téléversés dans wp-content/uploads.
- Créez une copie de l’état actuel, même défaillant, des fichiers et de la base.
- Restaurez d’abord sur un environnement de préproduction si l’hébergeur le permet.
- Testez la page d’accueil, la connexion, les contenus récents, les formulaires et les fonctions métier.
- En e-commerce, comparez les commandes, comptes clients et stocks créés après la date de sauvegarde.
- Restaurez en production, videz les caches et contrôlez les journaux PHP.
Une restauration de base de données peut effacer des commandes, commentaires, demandes de contact ou réglages créés après le point choisi. Pour une boutique active, demandez à votre hébergeur ou à votre prestataire s’il existe une sauvegarde plus récente ou une possibilité de restaurer séparément fichiers et base. Ne supposez pas qu’une sauvegarde de fichiers répare une erreur provenant de la base, ni l’inverse.
Prévenir le prochain incident par une maintenance site WordPress
Une maintenance efficace repose sur des sauvegardes automatiques externalisées, vérifiées par des restaurations de test, ainsi que sur un environnement de préproduction pour les mises à jour sensibles. Planifiez les mises à jour du cœur, des extensions et des thèmes après vérification de la compatibilité PHP. Supprimez les extensions et thèmes inutilisés, conservez des accès SFTP et hébergeur sécurisés, et activez la journalisation d’erreurs côté serveur.
Sur un site professionnel, surveillez la disponibilité, l’espace disque, les erreurs PHP et l’expiration du certificat SSL. Documentez aussi les versions de PHP, WordPress, du thème et des extensions critiques. En cas d’erreur critique, ces informations permettent de reproduire le problème, de revenir à une version stable et de déployer la correction sans improvisation.
Pourquoi ne reçois-je pas l’e-mail du mode de récupération WordPress ?
L’e-mail peut être envoyé à une ancienne adresse administrateur, être filtré comme indésirable ou ne pas partir si l’envoi d’e-mails du serveur est mal configuré. Vérifiez l’adresse définie dans Réglages, consultez les indésirables et utilisez les logs PHP ou l’accès SFTP si le lien n’est pas disponible.
Une erreur critique peut-elle être causée par la version de PHP ?
Oui. Une extension ou un thème ancien peut utiliser une fonction incompatible avec une version PHP récente, tandis qu’un WordPress ou une extension à jour peut exiger une version PHP minimale. Vérifiez le message exact dans les logs avant de modifier PHP, puis testez le changement sur une préproduction.
Faut-il supprimer une extension qui provoque une erreur critique ?
Non, commencez par la désactiver ou renommer son dossier. Cela rétablit souvent le site tout en conservant les fichiers pour l’analyse. Supprimez-la seulement après avoir vérifié qu’elle n’est plus nécessaire, exporté ses données si besoin et prévu une solution de remplacement compatible.
Que faire si le fichier debug.log ne contient aucune erreur ?
Consultez le journal d’erreurs PHP de l’hébergeur et les éventuels journaux du proxy ou du pare-feu applicatif. Vérifiez aussi que le serveur peut écrire dans wp-content. Certaines erreurs surviennent avant le chargement complet de WordPress et n’apparaissent donc pas dans debug.log.
Peut-on restaurer uniquement les fichiers WordPress sans restaurer la base de données ?
Oui, si la panne provient clairement d’un fichier modifié, d’une mise à jour incomplète ou d’un thème défectueux, et que la base est saine. Inversement, une restauration de base seule peut convenir à un réglage ou une donnée corrompue. Testez toujours la combinaison choisie avant la mise en production.