Ton site affiche le message “Une erreur critique est survenue sur ce site” ?
Ce n’est jamais agréable. Surtout quand cela arrive au mauvais moment, c’est-à-dire à peu près toujours. Le site ne répond plus, l’administration est parfois inaccessible, et le petit message WordPress a le don de donner l’impression que tout vient de brûler.
Bonne nouvelle, ce n’est pas forcément le cas.
Une erreur critique WordPress vient souvent d’un plugin, d’un thème, d’une version PHP incompatible ou d’un bout de code qui a décidé de partir en freestyle. Dans tous les cas, le plus important est de ne pas cliquer partout dans la panique, c’est rarement une stratégie. Même si, sur le moment, ça soulage presque.

C’est quoi une erreur critique WordPress ?
Une erreur critique WordPress apparaît quand WordPress rencontre une erreur PHP suffisamment grave pour empêcher le site de fonctionner correctement.
Le site peut alors afficher un message du type :
“Une erreur critique est survenue sur ce site.”
Selon la situation, l’erreur peut bloquer tout le site, seulement une page, l’espace d’administration ou une fonctionnalité précise. WordPress ne dit pas simplement qu’il y a un petit souci. Il indique qu’il ne peut plus continuer le chargement normalement.
Le plus souvent, le problème ne vient pas d’un site “fichu”. Il vient plutôt d’un élément qui provoque une erreur au mauvais endroit. Un plugin incompatible, un thème mal mis à jour, une fonction PHP absente, une mémoire serveur trop faible… Bref, quelque chose qui coince, et WordPress s’arrête de tourner avant de faire encore plus de dégâts.
Pourquoi cette erreur apparaît-elle ?
Une erreur critique arrive souvent après un changement.
Le site fonctionnait bien, puis quelque chose a été modifié. Une extension a été mise à jour. Un thème a changé de version. L’hébergeur a modifié PHP. Un bout de code a été ajouté dans functions.php. Une mise à jour s’est interrompue. Et là, c’est rideau !
Les causes les plus fréquements observées sont :
- un plugin incompatible après une mise à jour ;
- un thème qui déclenche une erreur PHP ;
- une version PHP trop ancienne ou trop récente ;
- un conflit entre deux extensions ;
- un extrait de code ajouté au mauvais endroit ;
- une mise à jour WordPress interrompue ;
- une mémoire PHP insuffisante ;
- un fichier corrompu ;
- une extension de sécurité trop agressive ;
- un problème côté hébergement.
Le dernier élément modifié est souvent un bon suspect. Ce n’est pas toujours le coupable, mais au moins quelqu’un à interroger. Dans WordPress, les pannes laissent souvent des indices. Il faut simplement les chercher et éviter d’arriver sur la scène avec une tronçonneuse.
Ce qu’il faut faire avant de toucher au site
Le premier réflexe devrait être de ne rien casser de plus.
Quand un site est hors ligne, l’urgence donne envie d’aller vite. Pourtant, une intervention trop rapide peut aggraver la situation. Supprimer un dossier au hasard, changer la version PHP sans noter l’ancienne, restaurer une sauvegarde trop vieille ou modifier un fichier en production peut transformer une panne simple en vrai bazar.
Avant d’intervenir, prends quelques minutes pour vérifier :
- ce qui a été modifié récemment ;
- si une sauvegarde existe ;
- si l’administration WordPress est accessible ;
- si un e-mail d’erreur a été reçu ;
- si le site est totalement bloqué ou seulement partiellement ;
- si l’hébergeur signale un incident ;
- si le problème touche aussi les visiteurs non connectés.
Ce petit temps d’observation évite beaucoup d’erreurs
Un site WordPress, ce n’est pas un meuble IKEA. Quand il reste deux pièces à la fin, ce n’est pas forcément normal.
Vérifier l’e-mail envoyé par WordPress
Depuis WordPress 5.2, WordPress peut envoyer un e-mail quand il détecte une erreur critique.
Cet e-mail est précieux, car il peut indiquer l’extension, le thème ou le fichier responsable. Il peut aussi contenir un lien vers le mode de récupération WordPress, qui permet parfois d’accéder à l’administration même quand le site public est bloqué.
Il faut donc vérifier la boîte mail de l’administrateur du site. Pense aussi aux spams, aux anciennes adresses et aux boîtes mail qui ne reçoivent plus rien depuis des mois. Ça arrive plus souvent qu’on ne l’avoue.
L’e-mail peut contenir :
- le nom du plugin concerné ;
- le nom du thème concerné ;
- le fichier qui déclenche l’erreur ;
- la ligne de code fautive ;
- un lien vers le mode de récupération ;
- des informations techniques utiles.
Si cet e-mail est disponible, il peut faire gagner beaucoup de temps. Il donne une première piste au lieu de chercher à l’aveugle.
Utiliser le mode de récupération WordPress
Le mode de récupération WordPress permet parfois de reprendre la main sans passer par FTP.
Si WordPress a envoyé un lien de récupération, il suffit de l’ouvrir, de se connecter, puis de désactiver l’extension ou le thème signalé. Dans beaucoup de cas, le site revient immédiatement en ligne.
La marche à suivre reste assez simple :
- ouvrir l’e-mail envoyé par WordPress ;
- cliquer sur le lien de récupération ;
- se connecter à l’administration ;
- repérer l’extension ou le thème signalé ;
- désactiver l’élément concerné ;
- vérifier si le site fonctionne à nouveau.
Une fois le site remis en ligne, il ne faut pas s’arrêter là. Le problème doit être compris et corrigé proprement. Si un plugin déclenche l’erreur, il faudra vérifier sa compatibilité, sa dernière mise à jour, son support voir son remplacement.
Remettre le site en ligne règle l’urgence. Comprendre pourquoi il est tombé évite le deuxième épisode. Car personne n’a envie d’une saison 2 intitulée “Erreur critique, le retour”.
Si l’administration WordPress est inaccessible
Il arrive que l’administration WordPress soit elle aussi bloquée.
Là, il faut passer par l’hébergement, un accès FTP/SFTP ou le gestionnaire de fichiers fourni par l’hébergeur. L’objectif n’est pas de bricoler partout, mais de désactiver temporairement ce qui peut provoquer l’erreur.
La méthode la plus courante consiste à désactiver tous les plugins d’un coup en renommant leur dossier.
Depuis le serveur, il faut aller dans :
/wp-content/
Puis renommer le dossier :
plugins
en :
plugins-old
WordPress ne trouve alors plus les extensions et les désactive automatiquement. Si le site revient en ligne, cela signifie très probablement qu’un plugin est responsable.
Il faudra ensuite renommer le dossier plugins-old en plugins, puis identifier l’extension fautive une par une.
Ce n’est pas très glamour, mais c’est efficace. Un peu comme couper les plombs pour savoir quel appareil fait disjoncter la maison.
Identifier le plugin responsable
Quand les plugins semblent en cause, il faut trouver lequel déclenche l’erreur.
Le plus propre est de procéder progressivement. Il ne s’agit pas de tout réactiver d’un coup en espérant que WordPress se sente mieux. Spoiler : WordPress n’a pas de sentiments. Il n’a que des erreurs PHP.
Une méthode facile consiste à :
- réactiver un plugin ;
- vérifier le site ;
- réactiver le plugin suivant ;
- vérifier à nouveau ;
- continuer jusqu’au retour de l’erreur ;
- noter le dernier plugin activé.
Quand l’erreur revient, le dernier plugin qui a été réactivé est probablement responsable.
Le problème peut venir d’une incompatibilité avec WordPress, avec PHP, avec le thème ou avec une autre extension. Il peut aussi venir d’une mise à jour récente du plugin. Dans ce cas, mieux vaut vérifier s’il existe une nouvelle version corrective ou contacter le support de l’extension.
Si le plugin n’est plus maintenu depuis longtemps, il faut envisager de le remplacer. Un plugin abandonné sur un site professionnel, c’est rarement une bonne idée.
C’est un peu comme garder une rallonge électrique rafistolée au scotch. Tant que ça marche, tout va bien. Jusqu’au jour où non.
Vérifier le thème WordPress
Si les plugins ne sont pas responsables, le thème doit être vérifié.
Un thème peut provoquer une erreur critique WordPress après une mise à jour, une modification du fichier functions.php, un changement de version PHP ou une incompatibilité avec une extension en place.
Quand l’administration est accessible, le test consiste à activer temporairement un thème par défaut, comme Twenty Twenty-Four ou Twenty Twenty-Five si le site en dispose.
Si le site revient avec un thème par défaut, le problème vient probablement du thème actif ou du thème enfant.
Si cela est la cas, il faut contrôler :
- les fichiers modifiés récemment ;
- le fichier functions.php ;
- le thème enfant ;
- la compatibilité PHP ;
- la dernière mise à jour du thème ;
- les fonctions personnalisées ;
- les erreurs visibles dans les logs.
Quand l’administration est inaccessible, changer le thème demande davantage de prudence. Il peut être nécessaire d’intervenir dans la base de données ou de renommer le dossier du thème via FTP. Si tu n’es pas à l’aise avec cette partie, mieux vaut éviter l’improvisation. La base de données n’est pas l’endroit idéal pour jouer à “on verra bien”.
Activer le debug dans WordPress
Quand la cause n’est pas évidente, les logs deviennent indispensables.
WordPress permet d’activer le mode debug depuis le fichier wp-config.php. La bonne pratique consiste à enregistrer les erreurs dans un fichier de log, sans les afficher publiquement aux visiteurs. Pour comprendre le fonctionnement et les constantes utiles, le debug WordPress permet de voir comment utiliser WP_DEBUG, WP_DEBUG_LOG et WP_DEBUG_DISPLAY.
Dans le fichier wp-config.php, il est possible d’ajouter ou d’adapter ces lignes avant la phrase “That’s all, stop editing!” :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
Les erreurs sont généralement enregistrées dans ce fichier :
/wp-content/debug.log
Ce fichier peut indiquer le plugin, le thème, le fichier exact et la ligne qui posent problème. Il peut aussi faire apparaître une erreur de mémoire, une fonction absente ou une incompatibilité PHP.
Une fois le diagnostic terminé, il faut désactiver le debug. Le laisser actif trop longtemps peut générer un fichier très lourd. Et afficher des erreurs techniques aux visiteurs n’est jamais une bonne idée.
Le linge sale technique se lave côté serveur, pas en vitrine.
Vérifier la version PHP
La version PHP joue un rôle important dans la stabilité d’un site WordPress.
Une erreur critique peut apparaître si la version de PHP est trop ancienne pour un plugin récent, ou trop récente pour un vieux thème qui n’a pas suivi. Dans les deux cas, WordPress peut se retrouver face à une fonction inconnue, une syntaxe obsolète ou une incompatibilité.
Il faut donc vérifier sur l’hébergement :
- la version PHP actuelle ;
- la version utilisée avant l’erreur si elle a changé ;
- la compatibilité du thème ;
- la compatibilité des plugins principaux ;
- les recommandations de WordPress ;
- les messages dans les logs serveur.
Si l’erreur est apparue juste après un changement de version PHP, il peut être utile de revenir temporairement à la version précédente. Cela permet de remettre le site en ligne le temps d’identifier le problème.
Ce retour en arrière doit rester temporaire. Garder une version PHP trop ancienne pendant des années, c’est comme laisser une serrure fatiguée sur une porte importante. Elle tient peut-être encore, mais ce n’est pas franchement rassurant.
Augmenter la mémoire PHP
Certaines erreurs critiques viennent d’une mémoire PHP insuffisante.
C’est fréquent sur les sites qui utilisent beaucoup de plugins, un constructeur de pages lourd, WooCommerce, des extensions de sécurité, des sauvegardes automatiques ou des imports volumineux.
Un message comme “Allowed memory size exhausted” indique généralement que WordPress manque de mémoire pour exécuter une action.
Il est parfois possible d’augmenter la mémoire dans wp-config.php :
define( 'WP_MEMORY_LIMIT', '256M' );
Cette modification peut remettre le site en ligne, mais elle ne règle pas toujours le fond du problème. Si un plugin consomme beaucoup trop de ressources, il faudra comprendre pourquoi et éventuellement le remplacer.
Donner plus de mémoire à un plugin mal optimisé peut aider à court terme. Mais si le plugin continue à manger comme un ogre au buffet, il faudra quand même regarder ce qu’il fait et si il est vraiment utile.
Restaurer une sauvegarde sans se précipiter
Quand le site est hors ligne, restaurer une sauvegarde peut sembler être la solution la plus simple.
Parfois, c’est effectivement le bon choix. Mais il faut éviter de restaurer trop vite, surtout sur un site actif.
Avant de lancer une restauration, mieux vaut vérifier avant :
- la date de la sauvegarde ;
- si elle contient les fichiers et la base de données ;
- si le problème existait déjà au moment de la sauvegarde ;
- si des formulaires ont été reçus depuis ;
- si des commandes WooCommerce ont été passées ;
- si des contenus ont été publiés entre-temps ;
- si la restauration va écraser des données importantes.
Sur un site vitrine simple, une sauvegarde récente peut sauver la mise rapidement. Sur une boutique ou un site avec espace membre, la restauration doit être préparée avec soin.
Une sauvegarde, c’est un filet de sécurité. Ce n’est pas un bouton magique à presser les yeux fermés.
Hébergez votre site chez o2switch
Faites comme XT DESIGN WEB, choisissez o2switch. Un hébergeur engagé écologiquement avec 94% d’énergie décarbonnée. Des performances au rendez-vous et un support exeptionnel.
Vérifier les fichiers du cœur WordPress
Si les plugins, le thème et PHP ne semblent pas responsables, il faut envisager un problème dans les fichiers du cœur WordPress.
Cela peut arriver après une mise à jour interrompue, un transfert FTP incomplet, une mauvaise manipulation, un fichier corrompu ou une infection.
Quand l’administration est accessible, WordPress permet de réinstaller la version courante depuis le tableau de bord. Cette action remet les fichiers principaux sans toucher normalement au contenu du site.
Si l’administration est inaccessible, la réinstallation manuelle demande plus d’attention. Il ne faut pas écraser le dossier wp-content, le fichier wp-config.php, les médias ou les fichiers personnalisés.
Les éléments à préserver absolument sont :
- le dossier wp-content ;
- le fichier wp-config.php ;
- les médias ;
- les sauvegardes ;
- les fichiers personnalisés ;
- la base de données.
Cette étape ne doit pas être faite à la légère. Le cœur WordPress se manipule proprement, pas en mode “je glisse tout sur FTP et on verra”. Ce genre de méthode se termine rarement bien.
Vérifier s’il y a un piratage
Toutes les erreurs critiques ne viennent pas d’un piratage.
Heureusement, la plupart du temps, il s’agit plutôt d’un conflit technique. Mais certains signes doivent pousser à vérifier la sécurité du site.
Il faut être vigilant si l’erreur arrive avec :
- des fichiers inconnus sur le serveur ;
- des redirections étranges ;
- des utilisateurs administrateurs inconnus ;
- des plugins installés sans intervention ;
- des alertes de sécurité ;
- des fichiers modifiés sans raison ;
- des pages spam indexées dans Google ;
- une lenteur soudaine ;
- des messages suspects dans les logs.
Si un piratage est possible, remettre le site en ligne ne suffira pas. Il faut tout d’abord nettoyer, sécuriser, changer les accès, vérifier les utilisateurs, contrôler les fichiers et comprendre comment l’intrusion a eu lieu.
Une faille non corrigée finit souvent par revenir. Et elle ne revient jamais avec un bouquet de fleurs.
C’est là que la maintenance WordPress proactive prend tout son sens. Les mises à jour, les sauvegardes, la surveillance de sécurité et les contrôles réguliers évitent que des petits signaux deviennent de vraies urgences.
Suivre un ordre de dépannage logique
Pour remettre un site en ligne, mieux vaut avancer dans le bon ordre.
Voici une méthode simple :
- vérifier l’e-mail d’erreur WordPress ;
- tenter le mode de récupération ;
- faire une sauvegarde si possible ;
- désactiver les plugins via FTP si l’admin est bloquée ;
- réactiver les plugins un par un ;
- tester le thème ;
- activer les logs avec WP_DEBUG_LOG ;
- vérifier la version PHP ;
- augmenter temporairement la mémoire PHP si nécessaire ;
- consulter les logs serveur ;
- restaurer une sauvegarde seulement si c’est pertinent ;
- sécuriser le site après remise en ligne.
Cet ordre de progression évite de partir dans tous les sens. Le but n’est pas seulement d’effacer le message d’erreur. Il faut aussi comprendre ce qui l’a provoqué.
Un site remis en ligne sans diagnostic peut retomber au prochain clic, à la prochaine mise à jour ou au prochain changement de serveur. Et là, ce n’est plus une panne isolée. C’est une série de plusieurs saisons, avec un scénario franchement pénible.
Exemple concret avec la mise à jour d’un plugin
Imaginons un cas très courant.
Un plugin est mis à jour. Quelques secondes plus tard, le site affiche une erreur critique WordPress. L’administration n’est plus accessible.
Le plus simple est de passer par FTP ou par le gestionnaire de fichiers de l’hébergeur. Il faut alors aller dans le répertoire wp-content/plugins, et renommer le dossier du plugin suspect en ajoutant par exemple “-old”. Si le site revient en ligne, le plugin est probablement le responsable.
Il faudra ensuite :
- vérifier s’il existe une mise à jour corrective ;
- regarder les notes de version du plugin ;
- contacter le support si nécessaire ;
- vérifier la compatibilité avec PHP ;
- remplacer l’extension si elle n’est plus maintenue ;
- tester le site après la correction.
Une fois que le site est remis en ligne, il faut vérifier les pages importantes, les formulaires, les menus, le cache et les fonctionnalités clés. Le site peut être debout, mais encore boiter un peu. Autant vérifier avant que les visiteurs ne le remarquent.
Exemple concret avec une version PHP incompatible
Autre situation classique.
L’hébergeur modifie la version PHP, ou la version est changée manuellement depuis le panneau de l’hébergement. Le site affiche ensuite une erreur critique.
Dans ce cas là, il faut vérifier la version PHP actuelle et regarder si l’erreur mentionne un plugin ou un thème. Si le problème est apparu immédiatement après le changement de version PHP, un retour temporaire à l’ancienne version peut permettre de remettre le site en ligne.
Ensuite, il faudra mettre à jour ou remplacer les éléments incompatibles, puis repasser sur une version PHP récente et supportée.
La réparation se fait en deux temps. On remet d’abord de l’air dans le pneu. Ensuite, on cherche le clou.
Faut-il activer les mises à jour automatiques ?
Les mises à jour automatiques peuvent être utiles, mais elles doivent être utilisées avec prudence.
Sur un petit site très simple, elles peuvent fonctionner sans problème. Sur un site professionnel avec des plugins premium, un thème personnalisé, WooCommerce ou des fonctionnalités importantes, il vaut mieux éviter de tout laisser se mettre à jour sans aucun contrôle.
La pratique des professionnels consiste à :
- faire une sauvegarde avant les mises à jour importantes ;
- tester en préproduction quand c’est possible ;
- mettre à jour les extensions sensibles une par une ;
- vérifier le site après chaque mise à jour ;
- contrôler et tester les formulaires ;
- vérifier toutes les pages clés ;
- garder un accès rapide aux sauvegardes.
Les mises à jour sont indispensables pour la sécurité et la stabilité d’un site. Le souci, ce n’est pas de mettre à jour. Le souci, c’est de le faire sans filet, en croisant les doigts comme si WordPress était une machine à sous.
Comment éviter une nouvelle erreur critique ?
Une fois le site remis en ligne, il faut réduire les risques de récidive.
Un site WordPress doit rester fiable dans le temps. Il ne suffit pas qu’il soit joli au moment de sa mise en ligne. Il doit aussi supporter les mises à jour, les évolutions PHP, les changements de plugins et les petits imprévus du quotidien.
Ces quelques bonnes pratiques font déjà une vraie différence :
- supprimer les plugins inutiles ;
- éviter les extensions abandonnées ;
- garder WordPress à jour ;
- maintenir le thème à jour ;
- vérifier la compatibilité PHP ;
- faire des sauvegardes régulières externalisées ;
- tester les mises à jour importantes ;
- limiter les bouts de code ajoutés au hasard ;
- documenter les modifications ;
- surveiller les erreurs serveur.
Un site WordPress professionnel doit être pensé pour rester stable, évolutif et maintenable. La partie visible compte, bien sûr, mais la base technique compte tout autant.
Un beau site qui tombe à chaque mise à jour finit vite par perdre son charme et son utilité.
Quand demander de l’aide ?
Certaines situations méritent de ne pas insister seul trop longtemps.
Il vaut mieux demander de l’aide si :
- le site est une boutique WooCommerce ;
- l’administration est inaccessible ;
- aucune sauvegarde fiable n’est disponible ;
- l’erreur revient après chaque correction ;
- le fichier debug.log est incompréhensible ;
- la base de données doit être modifiée ;
- des signes de piratage apparaissent ;
- le site génère des demandes de contact importantes ;
- chaque minute hors ligne coûte des ventes ou de la crédibilité.
Il n’y a rien de ridicule à déléguer ce genre d’intervention. Le vrai risque, c’est de vouloir réparer vite sans savoir exactement ce qui est modifié.
Sur WordPress, une petite action peut suffire à corriger. Une autre petite action peut suffire à casser davantage. Tout le charme du métier, en quelque sorte.
En conclusion
Une erreur critique WordPress fait toujours peur, mais elle ne signifie pas forcément que le site est perdu.
Dans la majorité des cas, la cause se trouve du côté d’un plugin, d’un thème, d’une version PHP, d’un manque de mémoire ou d’un bout de code incompatible. Le plus important est d’avancer dans le bon ordre. Il faut vérifier l’e-mail WordPress, tenter le mode de récupération, désactiver les plugins si nécessaire, tester le thème, lire les logs, puis corriger proprement.
Un site remis en ligne sans diagnostic peut retomber au prochain changement, et ce genre de surprise n’a rien de très festif.
Un WordPress fiable se sauvegarde, se surveille et se maintient. Ce n’est pas la partie la plus spectaculaire du web, mais c’est souvent elle qui évite les grands moments de solitude devant un écran blanc.
Je suis Xavier, fondateur de XT DESIGN WEB. Mon truc : transformer des offres parfois floues en solution WordPress claires, rapides et bien référencées. Mon parcours atypique (École Boulle → 21 ans chef de projet & architecte de solutions → 7+ ans webdesigner/webmaster) m’aide à marier esthétique et rigueur technique pour livrer des sites beaux, stables et faciles à gérer. J’accompagne les TPE/PME, indépendants et startups sur la création, le SEO et la maintenance, avec pédagogie, transparence et zéro jargon. J'accompagne les TPE/PME,
Je suis Xavier, fondateur de XT DESIGN WEB. Mon truc : transformer des offres parfois floues en solution WordPress claires, rapides et bien référencées. Mon parcours atypique (École Boulle → 21 ans chef de projet & architecte de solutions → 7+ ans webdesigner/webmaster) m’aide à marier esthétique et rigueur technique pour livrer des sites beaux, stables et faciles à gérer. J’accompagne les TPE/PME, indépendants et startups sur la création, le SEO et la maintenance, avec pédagogie, transparence et zéro jargon. J'accompagne les TPE/PME,