---
title: "Erreur critique WordPress : panne technique ou site compromis ?"
description: "Une erreur critique WordPress signifie que PHP a rencontré une erreur fatale et a arrêté le chargement du site. 6 causes produisent ce message. 5 sont techniques, de l’extension mal mise à jour à la limite mémoire du serveur, et le site revient en ligne dès que le composant fautif est désactivé. La sixième est […]"
url: "https://kentin-canelas.fr/erreur-critique-wordpress/"
author: "Kentin Canelas"
date: "2026-08-16T21:51:41+00:00"
modified: "2026-08-17T08:38:09+00:00"
lang: "fr_FR"
categories: ["WordPress"]
---

# Erreur critique WordPress : panne technique ou site compromis ?

Une erreur critique WordPress signifie que PHP a rencontré une erreur fatale et a arrêté le chargement du site.

6 causes produisent ce message. 5 sont techniques, de l’extension mal mise à jour à la limite mémoire du serveur, et le site revient en ligne dès que le composant fautif est désactivé.

La sixième est une intrusion, et les manipulations habituelles ne feront alors que masquer le problème. 3 vérifications de 2 minutes permettent de trancher avant de toucher à quoi que ce soit. C’est ce tri que je détaille ici, dans l’ordre où je le fais sur un dossier réel.

À retenir- WordPress affiche ce message depuis la version 5.2, sortie en 2019 : avant, c’était un écran blanc sans explication.
- Le mode de récupération envoie un lien par e-mail, valable **1 jour** par défaut, à raison d’**un envoi par 24 heures**.
- Les 3 signaux d’intrusion à vérifier : fichiers modifiés récemment, comptes administrateurs inconnus, alertes dans Search Console.
- Restaurer une sauvegarde sans avoir vérifié ce point peut remettre en ligne la porte dérobée en même temps que le site.
- Un nettoyage complet démarre à **290 euros HT**, avec une garantie de re-intervention de 30 jours.

## Que veut dire « Il y a eu une erreur critique sur ce site » ?

Ce message signifie que PHP a rencontré une erreur fatale et a interrompu l’exécution avant que la page ne s’affiche. Le serveur fonctionne, WordPress est installé, mais un morceau de code a demandé quelque chose d’impossible et le moteur s’est arrêté net.

Vous verrez l’une de ces 3 formulations, selon votre version et l’endroit où vous êtes :

- « Il y a eu une erreur critique sur ce site » sur la partie publique ;
- « Une erreur critique est survenue sur votre site » dans l’administration ;
- « Il y a eu une erreur critique sur ce site. En apprendre plus sur le débogage de WordPress » quand vous êtes connecté en administrateur.

La formulation exacte dépend de votre version et du contexte d’affichage. Elle ne dit rien de la cause, et le lien de débogage qu’elle propose ne prouve pas que vous êtes reconnu comme administrateur.

Ce message existe depuis WordPress 5.2, sortie en mai 2019. Avant cette version, la même situation produisait une page entièrement blanche, sans texte ni code d’erreur. Le changement n’est pas cosmétique : depuis 5.2, WordPress tente aussi de vous envoyer un e-mail et de mettre en pause l’extension fautive, ce que j’explique plus bas.

Attention à 2 voisins proches. Une **erreur 500** est un code de statut HTTP renvoyé par le serveur, qui peut survenir sans que WordPress soit en cause. Un **site inaccessible** relève en général du DNS, du certificat ou d’une panne côté hébergement, et le message vient alors du serveur ou du navigateur, pas de WordPress. L’erreur critique, elle, est un message produit par WordPress lui-même : le serveur répond, PHP démarre, puis s’arrête.

## Remettre le site en ligne : les 3 gestes des 15 premières minutes

Si votre site est hors ligne en ce moment, faites ces 3 choses dans cet ordre, avant tout le reste.

1. **Regardez la boîte mail de l’adresse d’administration du site.** WordPress a probablement envoyé un message intitulé « Votre site rencontre un problème technique ». Il contient un lien qui remet l’administration en état de marche. Vérifiez les indésirables.
2. **Notez ce que vous avez fait** dans l’heure qui a précédé. Une mise à jour d’extension, un changement de thème, une modification de code, une intervention de votre hébergeur. La cause est presque toujours dans cette liste.
3. **Ne restaurez pas encore de sauvegarde.** C’est le réflexe le plus courant et c’est aussi celui qui peut vous coûter le plus cher, pour la raison que j’explique en fin d’article.

Avec un accès au tableau de bord, même partiel, vous êtes dans le cas facile : désactivez la dernière extension mise à jour et rechargez la page publique.

Sans aucun accès, il faut passer par le FTP ou le gestionnaire de fichiers de votre hébergement. La marche à suivre est plus bas.

![Les 3 premiers gestes à faire face à une erreur critique WordPress](https://kentin-canelas.fr/wp-content/uploads/2026/08/02-erreur-critique-wordpress-premiers-gestes.webp)## Panne technique ou site compromis : trancher en 3 vérifications

Avant de dérouler des manipulations, déterminez à quoi vous avez affaire. Une extension qui plante et un site compromis produisent exactement le même message, mais ils n’appellent pas du tout le même traitement.

Voici les 3 vérifications que je fais en premier sur un dossier, dans cet ordre. Elles demandent un accès FTP, un accès à la base de données par phpMyAdmin ou par le panneau de votre hébergement et un accès à Search Console.

| Vérification | Où regarder | Signal de panne technique | Signal d’intrusion |
|---|---|---|---|
| Date de modification des fichiers | FTP, dossiers `wp-includes` et racine, trier par date | Rien n’a bougé, sauf le dossier de l’extension mise à jour | Des fichiers du cœur modifiés à une heure où personne ne travaillait |
| Comptes administrateurs | Base de données, table `wp\_users`, ou l’écran Comptes si accessible | La liste correspond à vos collaborateurs | Un compte que vous ne reconnaissez pas, souvent créé récemment |
| Search Console | Sécurité et actions manuelles, puis Couverture | Aucune alerte, nombre de pages stable | Alerte de sécurité, ou des centaines de pages indexées que vous n’avez jamais écrites |

**Un seul signal** de la colonne de droite suffit à changer de méthode. Les 3 ne se cumulent pas forcément : une intrusion récente peut n’avoir laissé qu’un fichier modifié, sans compte créé ni page indexée.

Pourquoi cet ordre ? Parce qu’il va du moins coûteux au plus lent. La date de modification se lit en 2 minutes par FTP. Search Console demande que le site soit déjà associé à votre compte, ce qui n’est pas toujours le cas dans l’urgence.

Un point de vocabulaire, parce qu’il revient dans toutes les discussions : une **porte dérobée** est un fichier laissé par un attaquant pour revenir plus tard, indépendamment de la faille d’origine. C’est elle qui explique qu’un site nettoyé trop vite se retrouve compromis une deuxième fois.

Si vos vérifications penchent vers l’intrusion, arrêtez les manipulations. Un site compromis se traite dans un ordre précis, avec une mise hors ligne, un inventaire, puis une remise en ligne contrôlée. J’ai détaillé la méthode sur ma page dédiée au [nettoyage de site WordPress piraté](/nettoyage-site-wordpress-pirate/). Cette étape s’appuie directement sur mon travail de [consultant SEO WordPress](/technos-cms/consultant-seo-wordpress/) : lire Search Console en profondeur et piloter une désindexation relèvent du référencement, pas seulement de l’administration système.

## Les 6 causes d’une erreur critique, et laquelle regarder en premier

Les causes sont connues et peu nombreuses. Ce qui manque en général, c’est l’ordre dans lequel les examiner et le signal qui permet de les distinguer sans tout essayer.

| Cause | Signal qui la trahit | Premier geste |
|---|---|---|
| Extension en conflit ou mal mise à jour | La panne suit immédiatement une mise à jour | Désactiver l’extension concernée par FTP |
| Thème mal codé ou non maintenu | La panne suit un changement de thème ou une mise à jour du thème | Renommer le dossier du thème pour forcer le thème par défaut |
| Version de PHP incompatible | La panne suit un changement de version côté hébergeur | Revenir à la version PHP précédente depuis l’hébergement |
| Limite mémoire PHP dépassée | Le journal mentionne « Allowed memory size exhausted » | Ajouter `WP\_MEMORY\_LIMIT` dans `wp-config.php`, ou relever la limite chez l’hébergeur |
| Fichiers du cœur corrompus | Un transfert ou une mise à jour interrompue | Réinstaller WordPress sans toucher à `wp-content` |
| Site compromis | Voir les 3 vérifications ci-dessus | Ne rien restaurer, isoler le site |

Sur les dossiers que je traite, l’extension arrive largement en tête, suivie de la limite mémoire. Je ne publie pas de pourcentage : je n’ai pas un volume de cas suffisant pour qu’un chiffre soit honnête, et un pourcentage inventé serait plus nuisible qu’utile.

La cause qui coûte le plus cher n’est pas la plus fréquente. C’est celle qu’on écarte trop vite.

## L’e-mail de débogage WordPress et ses 3 limites

Depuis la version 5.2, WordPress envoie un e-mail lorsqu’une erreur fatale survient, et met temporairement en pause le composant responsable, extension ou thème. Le message contient un lien vers le **mode de récupération**, qui rouvre l’administration même quand la partie publique est cassée. Il ne rattrape pas tout : si l’erreur vient d’un fichier chargé avant WordPress lui-même, comme un mu-plugin ou un drop-in de cache, le mode de récupération ne s’active pas.

C’est le mécanisme le plus utile de tout cet article, et c’est aussi celui qui bloque le plus de gens, pour 3 raisons rarement expliquées.

**Le lien expire au bout de 1 jour.** C’est la valeur par défaut, définie par le filtre `recovery\_mode\_email\_link\_ttl` ([documentation WordPress](https://developer.wordpress.org/reference/hooks/recovery_mode_email_link_ttl/)). Si vous découvrez la panne le lundi matin alors qu’elle date du samedi, le lien du premier e-mail ne fonctionne plus.

**Un seul e-mail est envoyé par tranche de 24 heures.** La limite est fixée par `recovery\_mode\_email\_rate\_limit` ([documentation WordPress](https://developer.wordpress.org/reference/hooks/recovery_mode_email_rate_limit/)). Recharger la page en boucle ne provoque pas de nouvel envoi.

**L’e-mail part vers l’adresse d’administration du site**, pas vers la vôtre. C’est le champ renseigné dans Réglages, puis Général. Sur un site repris d’un ancien prestataire, cette adresse est souvent une boîte qui n’existe plus. C’est la cause n°1 des « je n’ai jamais reçu l’e-mail » que l’on me signale.

Ces 3 limites ont une conséquence pratique : **vérifiez cette adresse d’administration maintenant, pendant que votre site fonctionne.** Une fois la panne survenue, il est trop tard pour la corriger depuis le tableau de bord.

Si le lien a expiré, tout n’est pas perdu. Le mode débogage vous donnera le nom du fichier fautif. Ajoutez ces 2 lignes dans `wp-config.php`, juste avant la ligne « That’s all, stop editing » :

``` define( 'WP\_DEBUG', true ); define( 'WP\_DEBUG\_LOG', true ); define( 'WP\_DEBUG\_DISPLAY', false ); ```

La troisième ligne n’est pas optionnelle. Sans elle, les erreurs PHP s’affichent à vos visiteurs en clair, avec les chemins de votre serveur.

Rechargez la page, puis ouvrez le fichier `wp-content/debug.log`. La dernière ligne nomme le fichier et le numéro de ligne à l’origine de l’arrêt, sans toujours désigner un responsable unique.

Remettez les 3 constantes à `false` dès le diagnostic terminé, et **supprimez le fichier `debug.log`**. La documentation WordPress le rappelle : un journal d’erreurs laissé dans un dossier public est une faille, il est lisible par n’importe qui à l’adresse `votresite.fr/wp-content/debug.log`.

![Arbre de décision distinguant une panne technique d’une intrusion sur un site WordPress](https://kentin-canelas.fr/wp-content/uploads/2026/08/03-erreur-critique-wordpress-panne-ou-intrusion.webp)## Désactiver les extensions sans accès au tableau de bord

Quand l’administration est inaccessible, la désactivation se fait par le fichier ou par la base de données. La méthode par FTP est la plus sûre : elle conserve tous les réglages de vos extensions.

1. Connectez-vous en FTP ou ouvrez le gestionnaire de fichiers de votre hébergement.
2. Allez dans `wp-content`.
3. Renommez le dossier `plugins` en `plugins-off`. Toutes les extensions sont désactivées d’un coup.
4. Rechargez votre site. S’il revient, la cause est bien une extension.
5. Renommez `plugins-off` en `plugins`. Les extensions restent désactivées.
6. Réactivez-les une par une depuis le tableau de bord, en rechargeant la page publique entre chaque. Celle qui casse le site est la coupable.

Cette procédure est documentée par WordPress ([documentation officielle](https://wordpress.org/documentation/article/faq-troubleshooting/)), qui décrit aussi la variante par phpMyAdmin quand le FTP n’est pas disponible.

Pour le thème, le principe est le même : renommez le dossier du thème actif dans `wp-content/themes`, et WordPress bascule automatiquement sur un thème par défaut s’il en trouve un. Gardez toujours un thème natif installé sur vos sites, c’est ce qui rend cette manipulation possible.

Une limite à connaître : si le site revient après désactivation de toutes les extensions mais casse à nouveau dès la réactivation de la première, vous n’avez probablement pas un conflit mais un problème de ressources serveur. Passez à la limite mémoire.

## Restaurer une sauvegarde : le réflexe qui peut réamorcer l’attaque

Restaurer une sauvegarde règle instantanément une panne technique. Sur un site compromis, cela peut remettre en ligne la porte dérobée en même temps que le site.

Le mécanisme est le suivant. Une intrusion se déroule en 2 temps : l’attaquant entre, dépose ses fichiers, puis attend. L’exploitation visible vient souvent plusieurs semaines plus tard : panne, pages indésirables, ou [redirection vers un site de publicité](/site-wordpress-redirige-vers-pub/). Vos sauvegardes de cette période contiennent donc déjà les fichiers déposés. Restaurer la veille de la panne restaure aussi ce qui a été déposé un mois plus tôt.

Sur un dossier de nettoyage portant sur 12 sites hébergés au même endroit, j’ai retiré **27 portes dérobées actives**. Sur ce dossier précis, aucune n’avait été remontée par les scanners installés. Un scanner travaille sur des signatures connues, et une porte dérobée sur mesure n’en a pas.

> **La règle que j’applique :** on ne restaure jamais une sauvegarde avant d’avoir tranché entre panne et intrusion. Sur une panne, la restauration est la bonne solution et la plus rapide. Sur une intrusion, elle fait perdre les traces nécessaires au diagnostic et réamorce le problème.

Si vous restaurez malgré tout, faites-le en conservant une copie de l’état actuel du site avant l’opération. C’est cette copie qui permettra de comprendre ce qui s’est passé, et elle ne coûte que quelques minutes.

Une remarque sur les sauvegardes elles-mêmes, qui vaut pour tous les sites que je reprends : une sauvegarde stockée sur le même hébergement que le site disparaît avec lui. Une sauvegarde qui n’a jamais été restaurée pour test est une sauvegarde dont personne ne sait si elle fonctionne. Ces 2 points font partie de ce que je vérifie dans un [forfait de maintenance](/maintenance-wordpress/), et ils expliquent la plupart des mauvaises surprises en situation d’urgence.

![Frise montrant qu’une sauvegarde antérieure à la panne contient déjà la porte dérobée](https://kentin-canelas.fr/wp-content/uploads/2026/08/04-erreur-critique-wordpress-sauvegarde-infectee.webp)![Dirigeant de PME contactant un prestataire après une panne WordPress prolongée](https://kentin-canelas.fr/wp-content/uploads/2026/08/05-erreur-critique-wordpress-passer-la-main.webp)## À quel moment arrêter de chercher soi-même

Il y a un moment où continuer coûte plus cher que déléguer. Voici les 4 situations où je recommande de passer la main, sans rapport avec la difficulté technique.

- **Un signal d’intrusion est confirmé.** Le nettoyage exige un inventaire complet, pas une suppression de fichiers au cas par cas.
- **Le site est marchand et hors ligne.** Chaque heure a un coût que vous connaissez mieux que moi. La règle de décision est simple : comparez ce coût horaire au prix d’une intervention.
- **Vous avez déjà restauré une sauvegarde** et la panne est revenue. C’est le scénario qui indique le plus souvent une compromission.
- **Vous n’avez pas les accès.** Sans FTP ni accès à l’hébergement, aucune des manipulations de cet article n’est réalisable.

Sur les autres cas, la séquence de cet article suffit dans la majorité des situations, et il n’y a aucune raison de payer pour une désactivation d’extension.

Si vous êtes dans l’un des 4 cas, envoyez-moi l’adresse de votre site via le [formulaire de contact](/contact/). Le formulaire prend moins de 2 minutes à remplir. Vous recevez un premier diagnostic sous 24 à 72 heures ouvrées, sans engagement, avec le périmètre constaté et un devis ferme si une intervention est justifiée.

Un [nettoyage de site WordPress piraté](/nettoyage-site-wordpress-pirate/) démarre à 290 euros HT, avec une garantie de re-intervention de 30 jours. Cette garantie repose sur une logique technique : une porte dérobée résiduelle non détectée se réactive dans la majorité des cas sous 30 jours. Au-delà, une nouvelle infection est presque toujours liée à une nouvelle cause, et relève donc d’un nouveau dossier. C’est un engagement de moyens renforcé, pas une garantie de résultat.

Pour ne plus revivre la situation plutôt que la régler une fois, regardez [ce que coûte la maintenance d’un site](/maintenance-site-internet-prix/), ou directement [mes tarifs](/tarifs/).

## Questions fréquentes

Mon site affiche une erreur critique, est-ce que j’ai été piraté ?Dans la majorité des cas, non : la cause la plus fréquente est une extension ou un thème qui plante après une mise à jour. Mais le message est identique dans les 2 situations, et c’est pour cela qu’il faut vérifier avant de manipuler. Les 3 vérifications décrites plus haut, date de modification des fichiers, comptes administrateurs et Search Console, prennent moins de 10 minutes et évitent de traiter une intrusion comme un bug.

Je n’ai pas reçu l’e-mail de WordPress, que faire ?3 causes possibles, dans l’ordre de fréquence. L’adresse d’administration renseignée dans Réglages puis Général n’est plus active, ce qui est courant sur un site repris d’un ancien prestataire. Le message est dans les indésirables. Ou vous avez dépassé la fenêtre : WordPress n’envoie qu’un e-mail par 24 heures et le lien reste valable 1 jour. Dans les 3 cas, passez par le mode débogage et le fichier `debug.log`, qui donnent la même information sans dépendre de l’e-mail.

L’erreur est apparue juste après une mise à jour, que faire ?Désactivez l’extension ou le thème mis à jour par FTP en renommant son dossier, puis rechargez le site. S’il revient, vous avez identifié la cause. Ne réactivez pas immédiatement : vérifiez d’abord si une version plus récente corrige le problème, et si votre version de PHP correspond à celle exigée par l’extension. Une mise à jour qui casse un site signale souvent un décalage entre la version de PHP du serveur et celle attendue par le code.

Combien de temps faut-il pour remettre un site en ligne ?Sur une panne technique dont la cause est identifiée, la remise en ligne prend de 15 minutes à 2 heures selon l’accès dont vous disposez. Sur un site compromis, l’ordre de grandeur n’a rien à voir : l’inventaire, le nettoyage et les contrôles de sortie représentent plusieurs heures de travail, et la disparition des effets côté moteurs de recherche prend ensuite plusieurs semaines. Aucun prestataire sérieux ne vous garantira un délai de retour dans Google, parce que ce délai dépend de la fréquence à laquelle Google recrawle votre site.

Puis-je perdre le contenu de mon site ?Une erreur critique n’efface rien par elle-même : vos articles, vos pages et vos médias restent en base de données et sur le serveur. La réserve : si le script qui a planté avait commencé une opération d’écriture, une migration ou une suppression, une partie des données peut avoir été modifiée avant l’arrêt. Le risque de perte vient des manipulations qui suivent, en particulier des restaurations faites dans l’urgence qui écrasent des données plus récentes. C’est la raison pour laquelle la première consigne de cet article est de ne rien restaurer avant d’avoir compris ce qui se passe.

Sources- WordPress Developer Resources, `recovery\_mode\_email\_link\_ttl`, durée de validité du lien de récupération : [developer.wordpress.org](https://developer.wordpress.org/reference/hooks/recovery_mode_email_link_ttl/)
- WordPress Developer Resources, `recovery\_mode\_email\_rate\_limit`, fréquence d’envoi de l’e-mail : [developer.wordpress.org](https://developer.wordpress.org/reference/hooks/recovery_mode_email_rate_limit/)
- Make WordPress Core, annonce du mode de récupération introduit en version 5.2, publié le 16 avril 2019 : [make.wordpress.org](https://make.wordpress.org/core/2019/04/16/fatal-error-recovery-mode-in-5-2/)
- Documentation WordPress, désactiver les extensions sans accès à l’administration, mise à jour du 3 juillet 2026 : [wordpress.org](https://wordpress.org/documentation/article/faq-troubleshooting/)

---

*Source : [kentin-canelas.fr](https://kentin-canelas.fr/erreur-critique-wordpress/)*