Quand on voit apparaître l’erreur “critical error” sur WordPress, on ressent un mélange très particulier entre urgence et incertitude. Urgence parce que le site peut devenir inutilisable, incertitude parce que cette phrase est volontairement vague. Elle ne dit pas quel fichier est cassé, ni quelle extension fautive, ni si le problème ressemble à une simple incompatibilité ou à une tentative de compromission.
Dans les cas de désinfection WordPress, ce message arrive souvent après un changement récent: mise à jour, ajout d’extension, modification d’un thème, ou découverte de comportement suspect côté hébergement. Même si “critical error” peut venir d’une panne PHP ou d’une erreur de syntaxe, sa proximité avec les incidents de sécurité impose une approche méthodique. L’objectif n’est pas seulement de remettre la page en ligne, c’est de comprendre pourquoi WordPress affiche cette erreur et d’éviter que ça se reproduise.
Ce que cache réellement l’erreur “critical error”
WordPress affiche “critical error” quand il rencontre une situation où il ne peut pas continuer correctement l’exécution du code. Dans la pratique, les causes se rangent souvent dans trois catégories:
1) Un plugin ou un thème tente d’appeler une fonction PHP indisponible, ou échoue au chargement. 2) Un fichier PHP a été modifié de manière incorrecte, volontaire ou non, ce qui produit une fatal error en production. 3) L’exécution est interrompue par un problème plus global, par exemple une limite de mémoire, un serveur trop restrictif, ou une configuration PHP incompatible.
Ce qui rend le cas délicat, c’est que “critical error” ne donne pas la fatal error exacte. Il faut donc obtenir des informations côté serveur, dans les logs, et isoler la cause avec un minimum d’essais destructifs.
Sur un site compromis, une modification de fichier peut aussi entraîner “critical error”. Un attaquant injecte parfois du code dans un thème, un plugin, ou directement dans des fichiers WordPress “cibles”. Parfois le code s’exécute uniquement dans certaines conditions, ce qui rend l’incident plus difficile à repérer. D’autres fois, le code cassé provoque immédiatement l’erreur fatale, et WordPress se protège en affichant le message minimal.
Première étape: vérifier si c’est une simple panne ou un incident
Avant de vous lancer dans la désinfection WordPress à l’aveugle, prenez dix minutes pour regarder les signaux. Si vous observez plusieurs symptômes, vous devez traiter l’incident comme un compromis jusqu’à preuve du contraire.
Voici les éléments qui orientent fortement vers une piste sécurité:
- des fichiers PHP récemment modifiés (dates étrangement récentes dans le répertoire wp-content, ou dans un thème dont vous n’avez rien touché) une hausse brutale du trafic, des requêtes en rafale sur des URLs inhabituelles, ou des tentatives d’accès répétées des redirections invisibles, des articles ou pages créés sans votre action des utilisateurs administrateurs ajoutés, ou des changements de mots de passe “étrangement” après une fenêtre de maintenance des emails de sécurité, alertes de votre hébergeur, ou alertes dans une console anti-malware
Si aucun de ces signaux n’apparaît, une incompatibilité logicielle reste plausible. Par exemple, un plugin qui utilise une fonction PHP supprimée, ou un thème qui attend une version de PHP différente, peut suffire à déclencher “critical error”.
Le point important: même si vous penchez pour l’incompatibilité, l’erreur peut aussi masquer une modification malveillante. La différence, c’est votre niveau de prudence sur la suite. Dans le doute, vous travaillez comme si le site était compromis, au moins au début.
Récupérer l’information qui manque: logs et erreurs PHP
WordPress n’affiche pas toujours l’erreur fatale réelle, mais le serveur, lui, la connaît. C’est là que la résolution devient plus rationnelle.
Cherchez d’abord:
- les logs d’erreurs PHP sur votre hébergement (souvent via le panneau de contrôle, ou via un fichier error_log) les logs liés à PHP-FPM ou au système, selon votre infrastructure les traces WordPress, si elles sont activées (WP DEBUG, WPDEBUG_LOG), mais sans forcer en production tant que vous n’avez pas un accès maîtrisé
Sur beaucoup de configurations, vous pouvez activer temporairement le mode debug avec prudence, soit via wp-config.php, soit via des options côté hébergement. L’idée n’est pas de laisser l’information visible à tout le monde. Vous cherchez juste la fatal error dans un fichier de log interne. Ensuite, vous désactivez.
Quand vous avez enfin le nom du fichier en cause et la ligne de l’erreur, vous gagnez un levier majeur: vous pouvez isoler le plugin ou le thème fautif, ou confirmer qu’un fichier a été altéré.
Si vous n’avez pas accès aux logs, ou si vous n’arrivez pas à les retrouver, l’approche d’isolation reste possible, mais plus lente: désactiver les plugins un par un, ou revenir temporairement à une version saine. En incident de désinfection WordPress, je préfère toujours avoir au moins un indice des logs. Cela évite de supprimer à tort un composant innocent.
Isoler la cause en désactivant plugins et thème
La stratégie la plus efficace consiste à réduire le site à un état minimal fonctionnel. WordPress est modulaire, donc on peut désactiver les briques jusqu’à retrouver celle qui déclenche “critical error”.
Dans la majorité des cas, le coupable est un plugin récent, ou un thème qui modifie le comportement de WordPress au moment du chargement. Les erreurs apparaissent souvent après une mise à jour. Parfois le plugin se met en échec au niveau d’un hook, et WordPress stoppe net.
Une approche pratique consiste à désactiver tout le parc avant de réactiver progressivement. Vous pouvez faire cela via:
- le wp-admin, si vous y accédez encore ou via l’accès FTP/SFTP à wp-content, en renommant le dossier des plugins ou en utilisant un fichier mu-plugins ou un mu-disablement, selon l’environnement (moins fréquent) ou via une commande si vous êtes à l’aise avec WP-CLI
Je vais vous donner deux garde-fous qui évitent les erreurs fréquentes. D’abord, renommer plutôt que supprimer. Vous gardez une copie des dossiers pour revenir en arrière. Ensuite, quand vous réactivez, faites-le une extension à la fois, ou par lots très limités, pour réduire le temps de recherche si l’erreur revient.
Checklist courte pour l’isolation (sans trop casser):
- Vérifier les logs pour identifier le fichier ou le plugin mentionné dans la fatal error Renommer temporairement le dossier plugins pour mettre WordPress dans un mode sans extensions Revenir à la base en désactivant aussi le thème actif si l’erreur persiste, en forçant un thème par défaut (si possible) Réactiver uniquement ce qui était en place juste avant l’apparition de l’erreur Documenter chaque changement (heure, action, résultat) pour accélérer le diagnostic
Si l’erreur disparaît après désactivation de tous les plugins, vous avez un scénario favorable: vous pouvez retrouver le coupable. Si elle persiste même avec tous les plugins désactivés, c’est probablement un thème, un fichier WordPress modifié, ou un problème de configuration PHP ou du serveur.
Quand “critical error” suit une mise à jour: incompatibilité ou code altéré
Dans les heures qui suivent une mise à jour, on suppose souvent une incompatibilité. Cette hypothèse est crédible, surtout si vous avez:
- mis à jour WordPress mis à jour PHP mis à jour un plugin de cache, un plugin de sécurité, ou un constructeur de pages changé de thème
Une incompatibilité peut provoquer des appels à des classes ou des méthodes absentes, ou des erreurs de type sur des versions PHP plus récentes. Par exemple, un code écrit pour une version antérieure peut planter si le serveur est passé sur une autre branche.
Mais en désinfection WordPress, il faut faire attention à la causalité apparente. Un attaquant peut rester en place et provoquer un incident à la première ouverture de session, à la première mise à jour, ou après la modification d’un fichier. Il peut aussi profiter d’une chaîne d’exploitation via une extension vulnérable, puis altérer des fichiers. Dans ce cas, la mise à jour a pu simplement déclencher l’exécution d’un morceau de code déjà présent.
Mon réflexe lors d’un incident “critical error” est donc simple: je regarde ce qui a changé. Si votre historique de maintenance montre une mise à jour logique juste avant l’incident, c’est un indice. Si, en parallèle, les fichiers PHP du thème ou d’un plugin ont des dates modifiées incohérentes avec votre planning, j’incline vers la compromission.
Repérer les modifications suspectes dans wp-content
La majorité des compromissions WordPress touchent wp-content, car c’est là que vivent thèmes et plugins. Le diagnostic le plus utile consiste à comparer un état attendu à un état réel. Sans outil de comparaison, vous pouvez au minimum vérifier:
- les fichiers PHP récemment modifiés les ajouts dans des fichiers qui ne sont normalement jamais édités (comme un fichier de bootstrap d’un thème) la présence de chaînes étranges dans le code, notamment du base64, de l’obfuscation, des appels à des fonctions d’exécution, ou des patterns qui ressemblent à du chargement dynamique
Soyez prudent, car tous les patterns ne signifient pas une attaque, et certains plugins légitimes font des choses “bizarres” pour des raisons techniques. Le bon indicateur n’est pas une seule ligne isolée, c’est le contexte: un fichier qu’on ne vous a jamais demandé d’éditer, modifié récemment, avec des comportements qui ne correspondent pas à l’usage normal.
Si vous avez un accès à une version saine du site, idéalement un snapshot d’avant incident, la comparaison est très efficace. Sinon, un scan fichier par fichier à la recherche d’une signature d’injection ou d’obfuscation, combiné aux logs, suffit souvent à cibler ce qui est vraiment en cause.
En désinfection WordPress, je conseille de commencer par les composants les plus exposés: plugins récemment ajoutés, thèmes custom, plugins de sécurité et de redirection. Ensuite seulement les fichiers plus “centraux”.
Réparer sans empirer: la tentation de “supprimer le plugin” trop vite
Quand WordPress affiche “critical error”, la tentation est de supprimer le plugin qui semble provoquer l’erreur. C’est souvent correct, mais il y a un piège.
Si le plugin a été altéré ou si un attaquant y a caché du code, supprimer le dossier peut masquer un indicateur. Cela peut aussi casser des dépendances et vous empêcher de revenir à une configuration saine pendant que vous analysez.
La stratégie que je préfère dans un cas de désinfection WordPress est de sauvegarder avant toute action. Si vous devez retirer un plugin pour remettre le site en ligne, faites-le en renommant le dossier, pas en supprimant définitivement. Gardez une copie. De cette façon, si vous devez ensuite analyser le code suspect, vous avez le matériau.
Autre point: les fichiers médias, les images et les contenus ne sont pas forcément la source. Les compromis sont souvent “dans le code”, pas dans la base de données. Cela dit, il existe des attaques qui ajoutent du contenu dans la base (pages, utilisateurs, options). Donc restaurer le code ne suffit pas toujours. D’où l’intérêt d’une approche en deux passes: stabiliser le site, puis vérifier l’intégrité.
La base de données: vérifier utilisateurs, options, et cron
“Critical error” vient souvent d’un fichier, mais l’incident de sécurité peut être plus large. Dans beaucoup de cas, les attaquants profitent de leur accès pour:
- ajouter un utilisateur administrateur modifier des options pour injecter du JavaScript côté front manipuler des événements planifiés (WP-Cron) afin d’exécuter des actions en différé ajouter des redirections ou des règles dans des champs de configuration
Si vous avez déjà isolé un plugin ou thème fautif, vous pouvez ensuite revenir vers la base de données. Sans entrer dans des opérations trop risquées, l’idée est de repérer ce qui ne colle pas à votre historique.
Un point concret: regardez les utilisateurs. Les administrateurs ajoutés récemment, avec un nom d’utilisateur étrange, ou des timestamps incohérents sont de très bons indices. Si vous utilisez un mot de passe unique pour l’administration, les comptes compromis laissent souvent aussi des traces au niveau de la date de création.
Ensuite, vérifiez les options et les champs qui stockent des scripts d’injection ou des URL de redirection. Selon la configuration, un attaquant peut stocker du contenu dans des options “custom”, ou dans des métadonnées gérées par un plugin. C’est pour ça que stabiliser le site ne signifie pas nettoyer automatiquement.
Enfin, WP-Cron. Même si WordPress n’affiche pas “critical error” à cause de cron, un cron malveillant peut maintenir l’infection. Il peut exécuter des scripts ou re-pousser de petites modifications, et vous donner l’impression que la désinfection “ne tient pas”. C’est frustrant, et pourtant c’est assez courant.
Déployer une désinfection WordPress fiable: approche en trois couches
Pour résoudre le problème et sécuriser durablement, je recommande de penser en couches, pas en geste unique.
Première couche: stopper le crash. L’objectif est de faire disparaître “critical error”, même temporairement, pour retrouver un accès au site ou au moins à l’administration.
Deuxième couche: enlever la cause. Là, vous ciblez le fichier ou le composant qui provoque le crash, tout en éliminant les traces d’injection. Si un plugin a été modifié de façon suspecte, il ne suffit pas toujours de le “désactiver”. Il faut souvent le réinstaller proprement, ou le remplacer.
Troisième couche: vérifier que l’attaque n’a pas laissé de persistance. C’est là que la base de données, les comptes, et les tâches planifiées jouent un rôle. Une désinfection WordPress “propre” vise la persistance, sinon l’infection revient.
Cela implique parfois des compromis. Par exemple, vous pouvez remettre le site en ligne très vite en désactivant un plugin mal en point, mais vous n’aurez pas le bon résultat tant que vous n’aurez pas remplacé le fichier et inspecté la base. À l’inverse, si vous essayez de tout nettoyer à froid sans remettre le site en état, vous risquez de vous battre avec l’interface jusqu’à perdre du temps.
Ce que je fais quand je dois agir vite (sans sacrifier la sécurité)
Si l’accès admin est impossible et que vous devez restaurer une plateforme publique rapidement, l’option “maintenance” est préférable à la laisser exposée. Vous pouvez basculer en maintenance via votre panneau d’hébergement, ou utiliser un fichier en place si votre stratégie le permet. L’idée est de limiter l’impact SEO et de réduire les visiteurs qui tomberont sur un écran cassé.
Une fois en maintenance, vous isolez la cause via l’accès fichiers. Ensuite, vous rétablissez progressivement: d’abord le noyau fonctionnel, puis les composants, puis la base validée.
Plan d’action pragmatique (ordre logique, sans héroïsme):
- Sauvegarder une copie des fichiers en cause et prendre un dump ou une copie de la base Isoler le composant responsable du crash (plugins puis thème, en utilisant un mode sans extensions) Remplacer les fichiers suspects par des versions officielles, ou par une version saine de sauvegarde Vérifier comptes, options et cron pour éliminer la persistance Reconfigurer les mots de passe et limiter les accès, puis réactiver les plugins un par un
Après la désinfection: éviter la récidive
Résoudre “critical error” une fois ne suffit pas si la cause racine reste présente. En désinfection WordPress, j’observe souvent une récidive pour une raison simple: on nettoie, mais on ne corrige pas la faille d’origine.
Quelques exemples concrets:
- un plugin vulnérable n’a jamais été remplacé, uniquement désactivé un mot de passe administrateur faible a permis l’accès l’hébergement a gardé des réglages permissifs (droits d’écriture trop larges) des identifiants FTP partagés ont circulé des fichiers ont été modifiés par un script externe non documenté
Vous n’avez pas besoin de tout refaire, mais vous devez rendre le site difficile à recontaminer. Cela passe par:
- mettre à jour WordPress, thèmes et plugins, mais seulement après avoir compris l’origine de l’incident supprimer les plugins inutiles, surtout ceux qui n’ont pas été maintenus durcir l’accès admin, réduire le nombre de comptes, activer une méthode de protection à la connexion si votre environnement le permet surveiller les fichiers récemment modifiés et les alertes d’hébergement
Je recommande aussi de contrôler le comportement après réactivation: vérifiez rapidement l’interface, les pages clés, les formulaires, et le backend. Une infection peut être “silencieuse”: elle ne provoque pas le crash au moment où vous la cherchez. Elle peut se déclencher plus tard, ou sur une page spécifique.
Cas particuliers qui piègent souvent
“critical error” sans logs exploitables
Parfois les logs sont vides ou trop génériques. Dans ce cas, l’isolation par renommage devient l’outil principal. Gardez en tête que désactiver des plugins peut aussi changer l’ordre de chargement et masquer temporairement l’erreur réelle. Si l’erreur disparaît, vous devez ensuite revenir prudemment pour localiser précisément.
Un thème enfant qui est modifié
Un thème enfant peut être le vrai point d’injection, même si le thème parent est propre. Les modifications se cachent parfois dans le thème enfant, et l’erreur apparaît au chargement. Regardez l’historique de modifications de ces fichiers précis, pas seulement le dossier complet.
Une limite mémoire qui ressemble à une fatal error
WordPress peut aussi échouer si la mémoire PHP est insuffisante, surtout avec certains plugins de cache, de traduction, ou de sauvegarde. Là, “critical error” ne vient pas d’un code malveillant, mais d’un manque de ressources. Pour distinguer, les logs PHP sont déterminants. Si la fatal error mentionne une mémoire épuisée, votre plan d’action change: vous augmentez la mémoire et vous regardez le plugin consommateur.
Un serveur qui a changé après migration
Vous migrez, vous remplacez PHP, vous changez de version, et d’un coup des erreurs apparaissent. Sur ce type d’événement, la désinfection doit rester la même en esprit (surveiller fichiers et base), mais le diagnostic de crash doit intégrer la compatibilité PHP. Parfois c’est simplement un plugin incompatible avec une version PHP plus récente.
Exemple d’un scénario réel, typique et frustrant
Imaginons un site de vitrine où “critical error” apparaît le matin. Le propriétaire dit n’avoir rien changé, sauf une mise à jour nocturne côté hébergement. En vérifiant le panneau, on voit que la version PHP a changé de branche. En parallèle, dans wp-content/plugins, un plugin de sécurité affiche une date de modification récente, mais pas dans le calendrier du site.
Le premier réflexe est de désactiver tous les plugins. L’erreur disparaît. Puis on réactive en testant un plugin à la fois, et un seul déclenche à nouveau l’écran critique. Les logs mentionnent un fichier PHP dans cette extension. À ce stade, on pourrait “supprimer” et passer à autre chose. Mais en désinfection WordPress, on commence par sauvegarder le dossier en cause, on compare au code attendu, et on constate des ajouts obfusqués.
On remplace l’extension par une version officielle, on change tous les mots de passe, puis on inspecte les utilisateurs et les options. On trouve un compte admin ajouté quelques jours plus tôt, et une option de redirection injectée via un champ stocké par le plugin. Après suppression de l’utilisateur suspect, nettoyage des options et remplacement propre des fichiers, WordPress fonctionne de nouveau sans afficher “critical error”. La partie la plus importante est ensuite l’anti-récidive: vérifier que la mise à jour du serveur n’a pas rouvert une surface vulnérable, corriger l’accès et appliquer une politique de mises à jour planifiées.
Ce schéma montre la difficulté: ce n’est pas “juste” un crash. Le crash est souvent le symptôme, la compromission ou l’incompatibilité la cause.
Désinfection WordPress et retour à la normale: quoi vérifier avant de rouvrir au public
Avant de considérer la situation réglée, faites un contrôle minimal, mais réel. Il ne faut pas seulement recharger la homepage. Un incident peut toucher des zones spécifiques, par exemple:
- le formulaire de contact les pages de paiement l’édition d’articles le chargement des scripts en front certaines pages d’archive
Vérifiez aussi la cohérence fonctionnelle: les plugins utiles fonctionnent-ils, les rôles utilisateur correspondent-ils à ce que vous avez prévu, et les pages créées récemment sont-elles légitimes.
Si vous aviez activé une maintenance, vous la coupez une fois les éléments stables. Ensuite, surveillez sur 24 à 72 heures. L’objectif est de repérer un comportement “retardé”, une tâche cron malveillante qui réinjecte du code, ou un plugin qui échoue uniquement sur certaines pages.
Quand demander de l’aide
Il existe un seuil au-delà duquel bricoler coûte plus cher que de s’appuyer sur quelqu’un qui a l’habitude. Si vous:
- n’avez aucun accès aux logs ne savez pas comparer un fichier suspect à une version connue saine suspectez une compromission profonde (redirections, comptes multiples, persistance) devez absolument remettre le site en ligne sans délai et sans risque
Un accompagnement est souvent rentable. Une désinfection WordPress bien menée évite des cycles de “ça remarche”, puis “ça revient”, qui font perdre plusieurs jours.
Questions fréquentes, réponses rapides
L’erreur “critical error” veut dire que le site est piraté ?
Non. Elle peut être déclenchée par un plugin ou un thème cassé, ou par un problème de compatibilité PHP. En revanche, dès qu’il y a des signaux de modification suspecte, vous devez traiter l’incident comme une compromission jusqu’à preuve du contraire.Puis-je corriger sans sauvegarde ?
Vous pouvez parfois récupérer vite via désactivation, mais pour la désinfection WordPress, avoir une copie est un vrai filet de sécurité, surtout si vous devez analyser du source de l'article code ou restaurer un état antérieur.Quel est le meilleur premier geste ?
Isoler la cause via désactivation de plugins, tout en récupérant les logs PHP pour comprendre la fatal error exacte. C’est le combo le plus rentable.Combien de temps ça prend ?
Un cas simple peut se régler en moins d’une heure. Un incident avec persistance et nettoyage base de données peut demander plusieurs heures à un ou deux jours, selon votre accès et la complexité des traces.Résoudre l’erreur “critical error” sur WordPress, c’est souvent une enquête en deux dimensions: réparer ce qui empêche le site de fonctionner, puis vérifier ce qui a créé l’anomalie. En adoptant une méthode, en s’appuyant sur les logs et en traitant la désinfection WordPress comme un processus en couches, vous évitez les fausses restaurations et vous diminuez nettement le risque de récidive.