Un WordPress “en maintenance”, ça peut être une simple intention légitime de l’administrateur, mais ça peut aussi être le résultat d’un nettoyage mal contrôlé après une intrusion. Et dans les deux cas, la priorité reste la même: sortir du mode maintenance sans laisser derrière soi une faille, un fichier modifié ou une tâche automatisée qui relancera la saleté au prochain trafic.
J’ai vu des sites rester en maintenance pendant des jours après une “suppression de virus” effectuée à la hâte. Le plus fréquent n’est pas que le malware soit encore https://gardewp.fr/ actif, c’est que la maintenance est devenue un état permanent parce que le déclencheur n’a jamais été désactivé, ou parce que le site ne peut plus charger WordPress correctement. Dans ce guide, je vais te donner une méthode pragmatique pour comprendre ce qui se passe, reprendre la main, puis terminer l’assainissement proprement.
D’abord, vérifier de quel “maintenance” on parle
Avant de supprimer quoi que ce soit, il faut distinguer le mode maintenance affiché normalement par WordPress, d’un masquage imposé par le serveur, par un plugin, ou par une réécriture de trafic.
Sur un WordPress, le mode maintenance standard passe par un fichier nommé maintenance situé dans le répertoire racine de l’installation (le dossier où se trouvent typiquement wp-admin, wp-content, wp-includes). Quand ce fichier existe, WordPress affiche la page de maintenance, au lieu de charger le site.
Mais certains sites, après une compromission, affichent “maintenance” alors que WordPress n’est même plus capable de rendre correctement les pages. Dans ces cas, le problème peut venir de:
- une redirection au niveau serveur (Nginx, Apache, règles dans .htaccess), un plugin qui force un état de maintenance, une base de données partiellement corrompue ou bloquée, des fichiers système remplacés ou altérés.
J’ai déjà rencontré des configurations où l’attaquant n’a pas seulement défiguré des pages, il a aussi “stabilisé” la situation en empêchant le site de redevenir normal, ce qui rend la récupération plus longue.
Les indices les plus utiles (avant d’agir)
Voici les signaux qui orientent rapidement le diagnostic. Ils ne remplacent pas l’analyse des fichiers, mais ils permettent de gagner du temps quand le site est déjà instable.
- La page affiche “Mainteneance” très tôt, sans contenu WordPress, et le navigateur ne charge pas vraiment de ressources du site. Le fichier maintenance existe à la racine WordPress. Un plugin de maintenance (ou un mode “coming soon”) est activé, souvent caché derrière un écran d’admin inaccessible. Les requêtes renvoient des erreurs 403, 404 anormales, ou une redirection répétée vers une URL de maintenance. Tu as un changement récent: mise à jour, installation d’un plugin, hébergement déplacé, ou intervention manuelle de nettoyage.
Si tu reconnais plusieurs de ces points, tu peux avancer avec une approche plus ciblée.
Si la maintenance vient de WordPress, le levier est souvent simple
La première vérification, quand tu suspectes une infection WordPress, consiste à regarder la racine du site. Si tu as accès via un gestionnaire de fichiers, ou mieux, via un accès FTP ou SSH, cherche la présence du fichier maintenance.
Cas A: le fichier maintenance existe
Si le fichier maintenance est présent, le mode maintenance est généralement déclenché par WordPress. Si tu es en train d’assainir un site compromis, ce fichier peut avoir été créé pendant une étape de réparation, ou laissé par une intervention qui n’a jamais fini.
Le bon réflexe consiste à:
- vérifier que WordPress fonctionne au minimum (accès à wp-admin sans erreurs catastrophiques), supprimer le fichier maintenance, tester l’affichage.
Évite de supprimer “au hasard” si tu n’as aucun autre point de contrôle. Une suppression immédiate peut remettre en ligne un site encore cassé, par exemple si la base de données n’est pas saine ou si des fichiers critiques ont été remplacés.
Cas B: pas de fichier maintenance, mais toujours “maintenance”
Dans ce cas, on est probablement face à autre chose que le mécanisme natif. Un plugin peut afficher une page “maintenance”, ou le serveur peut forcer une page. Et si tu as des traces d’injection, il faut traiter la maintenance comme un symptôme, pas comme la cause.
Pour trancher, regarde les éléments suivants dans l’environnement.
Identifier la couche qui force l’écran de maintenance
Si la maintenance ne vient pas de maintenance à la racine, il faut remonter d’une couche.
Vérifier les règles de redirection
Sur Apache, le fichier .htaccess à la racine joue un rôle central. Une compromission peut ajouter des règles qui interceptent toutes les requêtes et les renvoient vers une page statique de maintenance.
Sur Nginx, ce n’est pas .htaccess, mais c’est au niveau configuration serveur. Si tu as accès au panneau d’hébergement, regarde les “redirections”, “URL rewriting”, ou les directives appliquées au répertoire.
Même quand la page semble “maintenance”, ce n’est parfois qu’un leurre: une redirection qui cache le vrai problème.
Vérifier le thème et surtout les plugins
Les plugins sont souvent la clé, parce qu’une injection peut modifier des fichiers de plugin, et des plugins de maintenance peuvent être installés, activés ou modifiés.
Si tu as accès à l’interface d’administration, c’est rapide: vérifie dans “Extensions” si un plugin “maintenance”, “coming soon” ou un module étrange est activé.
Si l’accès à wp-admin est bloqué, tu peux désactiver proprement les plugins en déplaçant le dossier plugins ou en renommant https://gardewp.fr/nettoyage-malware-wordpress/ des sous-dossiers, mais fais-le avec méthode. Renommer tout le dossier plugins peut casser plus que nécessaire si le site dépend d’un plugin essentiel. Une approche plus prudente consiste à désactiver en lot les extensions récemment ajoutées ou suspectes, puis vérifier.
Assainir proprement avant de “réouvrir” le site
Tu l’as peut-être déjà fait, mais je le redirige parce que c’est le point qui évite les retours de flamme. En cas de compromission, supprimer un ou deux fichiers visibles ne suffit pas. Il faut:
1) récupérer un état sain de WordPress (core et thèmes), 2) neutraliser le vecteur d’accès (comptes, clés, permissions), 3) nettoyer ce qui est modifié (fichiers et éventuellement base), 4) corriger ce qui a permis l’entrée (MFA, mises à jour, plugins, droits).
Quand le site est en maintenance, il faut réussir une étape supplémentaire: remettre en ligne sans réintroduire la cause.
Le bon ordre d’action quand le site est instable
En pratique, je fais dans cet ordre, sauf contrainte d’urgence:
- Mettre le site hors ligne proprement si nécessaire, ou rester en maintenance, mais documenter l’état. Faire une sauvegarde complète (fichiers + base de données) même si tu penses que c’est déjà compromis. Une sauvegarde sert aussi à comparer. Remplacer le core WordPress et les thèmes par des versions fiables. Nettoyer le dossier wp-content en inspectant les fichiers modifiés et les emplacements atypiques. Vérifier les comptes utilisateurs, les rôles, les clés d’accès, et la configuration. Revenir sur la maintenance, en supprimant uniquement les déclencheurs réellement identifiés.
Tu peux accélérer certaines étapes si tu as déjà des preuves solides, mais ce séquençage évite de “réparer” sur un socle cassé.
Remplacer le core et les thèmes, même si ça “semble” inutile
Quand un site a été atteint, le core est rarement la seule cible, mais il peut être modifié. Et si c’est le cas, chaque tentative de désinfection devient fragile.
Le remplacement par des fichiers WordPress officiels, et des thèmes provenant des sources originales, donne un socle propre. Ensuite seulement, tu inspectes ce qui reste dans wp-content (plugins, uploads, thèmes personnalisés).
La nuance importante: si ton thème est custom et que tu le remplaces, tu risques de perdre des modifications. Il vaut mieux distinguer un thème enfant, une surcouche, et les fichiers réellement customisés.
Vérifier les points d’accès, pas seulement les pages
Une infection WordPress ne se limite presque jamais à une page “déformée”. Souvent, le vrai danger se trouve dans:
- des comptes admin créés et cachés, des mots de passe réinitialisés sans que tu t’en rendes compte, des jetons d’authentification persistants, des scripts déclenchés par des événements (cron) ou par des chargements d’assets.
Quand tu es en maintenance, tu as tendance à te focaliser sur l’affichage. Moi, je préfère regarder le mécanisme d’accès. Si le vecteur reste actif, tu remettras le site en ligne et l’intrusion reviendra.
Inspecter les fichiers suspects dans wp-content
Sans rentrer dans du “hacker les fichiers” au hasard, il y a des signaux qui reviennent souvent dans des intrusions:
- fichiers PHP au comportement bizarre dans des dossiers non habituels, tailles de fichiers anormalement différentes par rapport à la normale, fichiers ajoutés récemment, scripts qui exécutent du code basé sur des paramètres d’URL, user-agent, ou en temps réel.
L’astuce pratique est de comparer les fichiers modifiés récemment, et de les rapprocher de ce qui a été déployé. Si tu as une trace de mise à jour ou un contrat, tu peux corréler. Sans trace, tu peux au moins identifier ce qui a changé “après coup”.
Je ne peux pas te donner une liste universelle de “noms de fichiers malveillants”, parce qu’ils varient énormément. Le plus fiable, c’est une méthode d’inspection plus froide: date de modification, contenu, logique, emplacement.
Quand tu dois enlever virus WordPress avec l’accès admin bloqué
Si wp-admin est indisponible ou que l’écran de maintenance empêche d’entrer, tu as encore des options.
Désactiver les plugins sans passer par l’interface
Si tu suspectes un plugin modifié ou un plugin de maintenance injecté, désactiver côté serveur est souvent la solution la plus directe. Tu peux:
- renommer wp-content/plugins pour neutraliser l’ensemble, ou désactiver un plugin ciblé en renommant son dossier.
L’objectif est de retrouver un WordPress qui charge, même avec moins de fonctionnalités. Une fois l’accès restauré, tu peux reprendre un nettoyage plugin par plugin, en gardant une preuve à chaque étape.
Le compromis est clair: tu perds temporairement des fonctions du site (galeries, SEO, formulaires), mais tu regagnes la capacité de diagnostiquer.
Vérifier les fichiers de configuration
Le fichier wp-config.php contient des éléments essentiels. Une compromission peut le modifier légèrement, par exemple via des variables qui chargent un fichier supplémentaire, ou via des lignes ajoutées en fin de fichier.
Quand je vois un comportement étrange, je regarde:
- si wp-config.php correspond à ce que vous utilisez d’habitude, si des lignes inhabituelles ont été injectées, si des constantes liées à la connexion base sont cohérentes.
Si tu as un backup “avant incident”, c’est encore mieux, tu compares.
Retrouver l’accès, puis remettre le site hors maintenance
Une fois que tu as neutralisé ce qui pouvait causer le comportement, tu peux enlever le mode maintenance et laisser WordPress redevenir visible.
Mais il y a un piège courant: tu supprimes le fichier maintenance, le site s’affiche, et tu crois que c’est réglé. Alors qu’en réalité, une partie des fichiers ou une extension mal nettoyée continue de faire des erreurs en arrière-plan.
Tester le site de manière “utile”, pas seulement le chargement
Quand tu enlèves la maintenance, teste:
- la page d’accueil, une page standard (un article ou une page de contenu), wp-admin si possible, les formulaires qui déclenchent du code (contact, inscription), le chargement des ressources.
Si une partie ne charge pas, tu peux être face à un JS cassé par un thème modifié, ou à un PHP fatal error causé par un plugin incomplet.
Je recommande de consulter les logs (erreurs PHP, logs serveur). Même si la page semble normale, un fatal error répété peut confirmer qu’il reste un fichier mal nettoyé.
Les raisons typiques pour lesquelles “maintenance” revient
Si tu rebascules en maintenance après l’avoir retiré, ce n’est pas forcément un malware qui “recrée” le fichier. Il peut y avoir aussi:
- une extension qui active un mode maintenance automatiquement en cas d’erreur, un plugin de cache ou de sécurité qui “fige” l’état, un script planifié qui échoue et laisse WordPress en maintenance, une base de données encore instable, ce qui empêche WordPress de terminer le chargement correctement.
C’est pour ça que les tests doivent couvrir plus qu’une simple visualisation.
Une méthode de triage si tu dois agir vite
Quand le site est en maintenance et que tu as peu de temps, tu peux faire un triage ordonné pour éviter de perdre la journée.
Voici une approche qui tient sur une demi-heure à une heure, selon ton niveau d’accès.
Sauvegarder (au moins une copie des fichiers et un export base si possible). Vérifier la présence du fichier maintenance à la racine. Inspecter .htaccess et les règles de redirection éventuelles. Désactiver temporairement les plugins si wp-admin est inaccessible. Remettre en ligne seulement après que WordPress charge sans erreurs majeures.Cette séquence te donne un filet de sécurité. Tu ne “nettoies” pas en aveugle, tu réduis le risque de réinfection immédiate.
Après désinfection: renforcer, sinon tu recommences au même endroit
Une fois le site à nouveau accessible, la question n’est plus “comment enlever virus WordPress”, mais “comment éviter que ça revienne”.
Le point clé, c’est que la compromission a presque toujours une cause, et souvent multiple, qui combine des éléments humains et techniques: mot de passe faible, absence de mises à jour, plugin abandonné, permissions trop permissives, thème chargé avec des scripts tiers, formulaires non protégés, etc.
Si tu as eu des comptes compromis, change les mots de passe, active la double authentification pour les comptes administrateurs, et révoque les sessions si WordPress ou ton hébergement le permet.
Contrôles à faire quand tout fonctionne à nouveau
Voici les contrôles concrets que je fais après une remise en ligne, pour vérifier que la maintenance ne cache pas un nouveau souci.
- Revoir la liste des utilisateurs WordPress, rôles compris, et supprimer tout compte non attendu. Rechercher des plugins nouveaux ou modifiés récemment, surtout ceux que personne ne reconnaît. Replacer les fichiers wp-content/uploads dans leur logique normale, sans supprimer de contenus utiles, mais en examinant les scripts PHP inattendus. Vérifier les tâches planifiées (cron) et les intégrations externes qui exécutent du code. Contrôler les fichiers clés (y compris wp-config.php, thèmes custom, et .htaccess) avec une copie de référence si tu en as une.
Cette étape est ce qui transforme une “désinfection” en “récupération durable”.
Cas particuliers: quand la maintenance protège le site, mais que le nettoyage n’est pas terminé
Il arrive qu’on laisse le site en maintenance volontairement, par sécurité. Dans ce cas, le message “maintenance” n’est pas un échec. C’est une barrière.
Le vrai travail, c’est d’avoir une date de sortie réaliste. Si tu enlèves la maintenance trop tôt, tu exposes des zones encore vulnérables, et tu perds la fenêtre de correction.
Je me souviens d’un site e-commerce où on avait nettoyé le front, mais où un plugin SEO injectait encore des requêtes “invisibles” vers l’extérieur. Le site semblait propre une heure, puis des comportements bizarres revenaient. La maintenance, maintenue le temps de vérifier les requêtes et les déclencheurs, a évité de refaire le tour dans l’urgence.
Comment savoir si c’est vraiment fini
Sans promesse magique, tu peux te baser sur des indicateurs fiables:
- le site reste accessible sans repasser en maintenance, les erreurs serveur diminuent ou disparaissent, wp-admin fonctionne normalement, les plugins suspects ont été supprimés ou remis à une version saine, les comptes et rôles ont été maîtrisés, les fichiers modifiés ont été comparés ou remplacés selon un plan.
Il y a aussi une approche “observabilité”: surveiller pendant quelques jours après la remise en ligne, regarder les pics de 404, les erreurs 403, les tentatives de connexion inhabituelles, et les logs d’exécution.
Le détail qui fait la différence, c’est la durée de vérification. Un nettoyage “à l’instant T” n’est pas suffisant, mais une surveillance courte et ciblée peut confirmer que la cause a été neutralisée.
En résumé opérationnel, si ton site est bloqué en maintenance après une suspicion de virus
Si tu veux une règle de décision simple, sans te noyer dans les options:
- Si c’est la maintenance WordPress standard, tu as souvent un fichier maintenance en cause, mais ne le supprime qu’après avoir vérifié que WordPress charge correctement. Si ce n’est pas le fichier, regarde d’abord la redirection (serveur, .htaccess) et les plugins. Mets de l’ordre dans wp-content, remplace core et thèmes non custom, corrige les accès, puis seulement ensuite retire la maintenance. Ensuite, sécurise, parce que “enlever virus WordPress” n’a de valeur que si tu empêches le prochain incident.
Si tu me dis ton contexte, par exemple ton hébergeur (ou si tu as accès SSH), si tu vois le fichier maintenance, et si wp-admin s’ouvre ou non, je peux t’aider à choisir l’option la plus probable, étape par étape, sans te faire perdre du temps.