Quand un site WordPress a été compromis, la désinfection n’est pas seulement une question de “nettoyer le code”. Le vrai nerf de la guerre, c’est aussi la disponibilité après restauration: est-ce que le site répond, est-ce que les pages chargent correctement, est-ce que les visiteurs ne tombent pas sur https://gardewp.fr/ des erreurs intermittentes, et est-ce que le risque de récidive est réellement sous contrôle.
Sur le terrain, on voit souvent une séquence “désinfection d’abord, vérification ensuite”. Le problème, c’est que cette approche oublie que la restauration peut casser des dépendances, modifier des droits, laisser des services de cache dans un état incohérent, ou rendre le site lent au moment exact où vous avez besoin qu’il soit fiable. Le résultat ressemble à un faux retour à la normale: le malware a disparu, mais le site n’est pas pleinement utilisable.
Ci-dessous, je pose une méthode pragmatique pour vérifier la disponibilité après restauration, avec des points d’attention concrets issus de cas réels: redirections, délais DNS, chemins de mise en maintenance, problèmes de permaliens, mémoire PHP, et cohérence base de données.
Ce qui peut “passer” la désinfection, tout en cassant la disponibilité
Une restauration peut sembler correcte en surface. Vous voyez la page d’accueil, éventuellement quelques formulaires, et vous pourriez conclure trop vite. Pourtant, la disponibilité dépend d’un ensemble de couches qui ne se valent pas.
Le piège le plus fréquent, c’est la base de données. Si la désinfection a consisté à réimporter un dump, mais que certains paramètres restent corrompus, vous pouvez obtenir des symptômes subtils: erreurs 500 seulement sur certaines URLs, pages qui se chargent après plusieurs secondes puis finissent par échouer, ou problèmes d’authentification qui empêchent le back-office de fonctionner alors que le front reste accessible.
Autre point, très courant dans les restaurations de WordPress: les droits et propriétaires des fichiers, surtout après extraction d’une archive ou changement de méthode de déploiement. Sur un serveur Linux, “ça marche” peut durer une demi-heure, puis une opération planifiée échoue, puis un plugin tentera d’écrire un fichier (log, cache, transients), et là, ça casse. Le site devient instable, et l’instabilité ressemble souvent à une attaque, alors qu’elle vient d’un détail de permissions.
Enfin, il y a tout ce qui n’est pas strictement “WordPress”, mais qui conditionne la disponibilité: reverse proxy, CDN, WAF, règles de firewall, caches locaux et caches distribués. Si vous avez activé des mesures de blocage pendant la désinfection, vous devez vérifier qu’elles n’empêchent pas l’accès normal. On a déjà vu des whitelists trop agressives, qui bloquent certains pays ou certains chemins, puis qui ne sont détectées que par des volumes réels de trafic.
Comprendre la cible: “disponible” ne veut pas dire “sain”
Avant de tester, il faut clarifier ce que vous entendez par disponibilité. Pour un site WordPress, je sépare mentalement trois notions:
1) Le site répond (HTTP codes cohérents, pas de timeouts). 2) Le site répond correctement (pages rendues, CSS et scripts, formulaires, redirections). 3) Le site reste répondant dans le temps (stabilité sur quelques minutes, pas juste un instant de validation).
Après désinfection WordPress, vous pouvez atteindre (1) sans atteindre (2) ou (3). Par exemple, un backend inaccessible ne bloque pas forcément le front, mais c’est un problème majeur: les mises à jour, les sauvegardes et la configuration de sécurité ne pourront pas se faire. À l’inverse, le front peut sembler bon, mais le détail du permis d’accès aux fichiers uploads, ou un cron bloqué, peut déclencher une panne latente.
Ce point de vue évite un piège fréquent: se concentrer sur “l’URL du malware” et oublier les chemins normaux, comme wp-admin, wp-login.php, les flux, les endpoints REST, ou les pages de paiement.
Avant les tests: valider l’environnement de restauration
La vérification après restauration commence avant d’ouvrir le navigateur. Elle commence par l’état du déploiement.
Si vous avez restauré depuis une sauvegarde, vous voulez être sûr que la restauration a bien remis ce que l’attaque avait modifié, sans réintroduire des morceaux inutiles. Sur WordPress, une restauration “binaire” (tout le répertoire) est parfois nécessaire, mais parfois non, notamment si vous aviez pu nettoyer finement. Dans ce cas, vous devez contrôler la cohérence: le code des fichiers correspond-il à la version supposée, et la base de données correspond-elle à ce code?
Concrètement, je regarde toujours:
- la version WordPress affichée dans le back-office quand c’est possible la présence d’extensions “cachées” dans les dossiers la structure des tables et surtout les champs d’options susceptibles d’avoir été modifiés les erreurs serveur dans les logs au moment où le site reçoit des requêtes
Sans entrer dans des procédures dangereuses, l’idée est simple: si votre restauration a été “assez bonne” pour la suppression, mais pas assez bonne pour la cohérence, les tests de disponibilité vont révéler des symptômes, pas des certitudes.
Vérification technique côté HTTP: codes, délais, cohérence des redirections
Le premier test de disponibilité, c’est l’observation du trafic HTTP. Sur un site compromis, il est fréquent que des redirections changent, parfois de manière conditionnelle.
Par exemple, on rencontre des règles qui redirigent seulement certains user-agents, ou seulement certaines sessions. Après restauration, ces règles peuvent rester actives si elles sont portées par un élément externe à WordPress: une règle Nginx, un script dans .htaccess, un mécanisme du CDN, ou une règle de firewall.
Au lieu de vous contenter d’un “le site s’affiche”, vérifiez plusieurs points, sur des URLs différentes:
- la page d’accueil une page interne “classique” (un article ou une page) une URL wp-admin ou wp-login (même si vous n’y accédez pas) une URL qui déclenche souvent du rendu de templates (catégorie, recherche si applicable)
Le but n’est pas de faire une expérimentation massive, mais d’observer le comportement. Un signe fréquent après restauration: des codes 301 en boucle ou des chaînes de redirections incohérentes. Cela peut venir de permaliens mal reconstruits ou d’un décalage entre HTTP et HTTPS. Si vous avez restauré un environnement qui n’a pas les mêmes paramètres de SSL ou de site_url, WordPress peut tenter de corriger en redirigeant, et l’infrastructure peut corriger aussi. Résultat: la boucle.
Autre signe: un site qui répond, mais très lentement. Après désinfection WordPress, on a parfois “nettoyé” le code, mais laissé des tables ou options qui déclenchent des requêtes coûteuses. Sans dire que c’est systématique, c’est un classique de réapparition de latence, parce que la restauration ne purge pas toujours les traces dans les données.
Je garde un réflexe: observer le temps de réponse et l’erreur serveur associée. Une latence qui dépasse plusieurs secondes sur des pages simples est un signal d’alarme, même si vous ne voyez pas d’erreur explicite côté navigateur.
Vérifier les ressources: CSS, scripts, et cohérence avec le cache
La disponibilité perçue par l’utilisateur ne se limite pas au HTML. Si le navigateur reçoit du code, mais que les ressources bloquent ou chargent en 404, le site est “en ligne”, mais inutilisable.
Après restauration, j’ai vu des cas où les chemins vers les assets devenaient incohérents, surtout quand un thème a été partiellement restauré. Il peut aussi y avoir une différence entre l’emplacement physique des fichiers et l’URL annoncée. Typiquement, un thème enfant ou un plugin peut s’appuyer sur des assets dans des dossiers spécifiques. S’ils manquent, ou si les droits empêchent l’accès, vous aurez des pages blanches ou un layout cassé.
Le cache complique tout. Si vous utilisez un plugin de cache, un mécanisme de reverse proxy, ou un CDN, la restauration peut invalider une partie des contenus mais pas tout. Vous pouvez vous retrouver avec:
- du HTML “propre” servi par WordPress, mais des assets “anciens” servis par le cache des pages mises en cache avant désinfection qui contiennent encore des redirections ou des scripts modifiés une expiration de cache qui ne colle pas à votre fenêtre de restauration
À ce stade, la bonne pratique est de coordonner vos tests avec l’état du cache. Dans l’idéal, vous mettez temporairement en clair l’environnement pour tester sans interférences. Dans le réel, vous pouvez au moins purger le cache des endpoints importants et vérifier si le comportement change.
Contrôler les chemins d’authentification et l’accès au back-office
Un site peut être “disponible” pour les visiteurs, tout en étant mort pour l’administration. Et si vous êtes en pleine désinfection WordPress, vous avez besoin d’un back-office sain, ne serait-ce que pour vérifier qu’il n’y a pas d’actions persistantes, reconfigurer les plugins, et mettre à jour.
Après restauration, je teste au minimum:
- wp-admin (et, selon le site, wp-login.php) la page de profil ou d’options si l’accès est possible les pages qui déclenchent une capacité à écrire (comme certaines configurations de plugins)
Pourquoi? Parce qu’un problème de droits ou d’écritures se manifeste souvent dans ces opérations. Par exemple, un plugin de sécurité ou un plugin de formulaire peut tenter d’écrire dans /wp-content/uploads, ou de mettre à jour des transients. Si l’écriture échoue, vous verrez des erreurs qui ne ressemblent pas toujours à une panne totale, mais à des fonctionnalités qui ne répondent pas.
Edge case fréquent: vous pouvez vous connecter, mais le tableau de bord charge avec des erreurs de scripts, ou certaines options ne se sauvegardent pas. Cela mérite d’être résolu immédiatement, car vous aurez l’impression d’avoir “désinfecté”, alors que les outils de correction ne fonctionneront pas dans la durée.
Permaliens, thèmes, et erreurs 404 ou 500 “uniquement sur certaines pages”
Les permaliens sont un point de bascule classique après restauration. Si la structure “%postname%” ou “/%category%/%postname%/” n’est pas cohérente avec la configuration enregistrée, vous pouvez obtenir des 404 uniquement sur certains chemins, alors que le reste fonctionne.
Dans un cas concret, il m’est arrivé de voir un site qui affichait correctement l’accueil et les pages statiques, mais qui donnait une 404 sur tous les articles. Le code était sain, la base contenait bien les publications, mais la partie “réécriture” côté serveur et côté options WordPress ne concordait pas. Tant que je ne testais pas un article en direct, je n’avais aucune alerte.
Une autre variante concerne les erreurs 500 sur certaines pages. Si vous avez un problème de compatibilité de thème ou de plugin avec la version de WordPress restaurée, vous aurez des pages qui cassent au moment du rendu. Le front peut afficher un aperçu, puis planter à la génération complète. Le navigateur vous dira “site inaccessible” ou “erreur serveur”. Derrière, les logs montrent la vraie raison.
Je recommande de tester au moins une page d’article, une page catégorie, et une page qui utilise des fonctionnalités typiques du site (formulaire, recherche, contenu dynamique). C’est souvent là que les incohérences ressortent.
Vérification fonctionnelle rapide: formulaires, recherche, paiements, flux
La disponibilité ne veut pas seulement dire “le site charge”. Une entreprise qui reçoit des demandes via formulaires mesure la disponibilité en taux de succès. Après restauration, vérifiez donc des endpoints représentatifs de l’activité.
Pour un site e-commerce ou une page de demande de devis, un bug peut se limiter à l’action du formulaire, pas à l’apparence du site. Un script manquant, un endpoint REST qui répond mal, ou un blocage de CORS peut suffire.
Je pense aussi aux flux RSS et aux pages dépendantes du cron. Par exemple, si vos exports ou vos publications programmées reposent sur des événements planifiés, vous pouvez avoir un site “en ligne”, mais un contenu qui ne se met pas à jour.
Le bon sens n’est pas suffisant ici, car l’attaque peut avoir modifié des templates pour dévier des formulaires vers une destination frauduleuse. Après désinfection WordPress, vous ne voulez pas seulement vérifier que le malware a disparu, vous voulez vérifier que le comportement des formulaires et des redirections est redevenu normal.
Examiner les journaux: ce que vous cherchez vraiment après restauration
Les logs, ce n’est pas “pour faire joli”. C’est l’outil qui vous évite de baser votre décision sur une impression.
Après restauration, j’essaie de repérer:
- des erreurs récurrentes (codes 4xx ou 5xx répétés sur les mêmes endpoints) des tentatives d’accès anormales qui continuent malgré la désinfection des messages qui indiquent un problème de permissions (uploads non écrits, cache non écrit, erreurs de fichiers) des erreurs PHP liées à des plugins, thèmes ou appels à des fonctions absentes
Un point important: la désinfection peut enlever le code malveillant, mais des requêtes malveillantes peuvent continuer. Vous devez distinguer les “attaques persistantes” (requêtes externes) des “pannes internes” (erreurs dues à la restauration). Les logs aident à faire cette séparation.
Si vous voyez des erreurs PHP dues à un plugin, ce n’est pas forcément une attaque, mais ça peut empêcher le site de rester disponible. Le correctif est alors côté compatibilité et configuration, pas côté suppression de fichier.
Gérer la fenêtre de stabilisation: tests, puis surveillance
Une erreur fréquente consiste à vérifier pendant deux minutes, puis à relâcher. Sur un WordPress, l’instabilité peut apparaître au bout de 10 à 30 minutes, le temps que certains caches se remplissent, que certains événements planifiés s’exécutent, ou que certains pages déclenchent des chemins jamais vus lors du test initial.
Je traite donc la disponibilité après restauration comme un petit cycle:
1) Tests de base immédiatement après restauration (HTML, redirections, ressources). 2) Tests fonctionnels sur endpoints clés (login, formulaires, recherche, pages d’activité). 3) Surveillance sur une fenêtre raisonnable (souvent quelques heures pour un site à trafic réel, sinon au moins une à deux heures si le trafic est faible).
La durée exacte dépend du contexte. Un site à volume élevé peut nécessiter une surveillance plus longue simplement parce que plus de requêtes vont “forcer” plus de scénarios. Un petit site vit surtout au rythme de ses visiteurs.
Si vous avez la possibilité d’observer les métriques serveur (taux d’erreurs, latence, utilisation mémoire), vous pouvez détecter un problème avant que les utilisateurs ne le signalent.
Ce faire de faux signaux: maintenance, caches, et sécurité trop stricte
Parfois, le site “ne répond plus”, mais la cause n’est pas le malware ni la restauration. C’est un mécanisme de mise en maintenance, un plugin de sécurité, ou une règle trop stricte.
J’ai déjà vu des restaurations qui laissent un site en mode maintenance car un fichier a été remis ou oublié pendant le déploiement. Dans d’autres cas, un plugin de sécurité ajoute des règles de blocage temporaires qui bloquent aussi des requêtes légitimes (par exemple des sessions administrateurs, des webhooks, ou des appels de services externes). Le symptôme peut ressembler à une panne, alors que c’est un “refus”.
Voici les contrôles qui reviennent le plus souvent après restauration, quand la disponibilité est douteuse:
Vérifier si WordPress est en maintenance (et qui y a accès). Purger ou ajuster le cache applicatif et le cache CDN, puis retester. Contrôler l’état des règles WAF ou firewall, au moins pour les endpoints sensibles. Tester HTTP et HTTPS pour détecter les boucles de redirection. Lire les logs au moment précis où l’erreur apparaît.Cette liste est volontairement courte, parce que l’objectif est d’éviter de partir dans 15 pistes en parallèle. L’enjeu est de remonter à la cause sans perdre de temps.
Seuils pratiques: quand passer de “ça marche” à “on doit corriger maintenant”
Il faut aussi savoir quand s’arrêter. Après désinfection WordPress, vous ne voulez pas corriger chaque micro-détail au moment où le site n’a pas encore été stabilisé.
J’utilise des seuils pragmatiques, basés sur l’impact. Si un site reçoit du trafic, je considère comme “à corriger immédiatement” tout ce qui empêche l’accès à l’administration, toute erreur 500 répétée, et tout symptôme sur un parcours de conversion (formulaire, paiement, demande de devis).
Si le site est surtout vitrine, des erreurs sur une page précise peuvent être tolérées le temps de l’investigation, mais pas trop longtemps. Une page 404 isolée peut attendre une journée, alors qu’un back-office inutilisable doit être traité dans la même fenêtre de maintenance.
La difficulté, c’est que l’attaque peut avoir laissé des traces dans plusieurs endroits. Si vous corrigez un problème de disponibilité sans résoudre l’origine, la récidive peut arriver très vite.
Exemple de situation: “le front est revenu, mais wp-admin affiche une erreur”
Prenons un scénario typique, pour illustrer la logique de vérification.
Après restauration, le site public s’affiche. Les pages statiques fonctionnent. Les articles aussi. Puis vous essayez wp-admin et vous tombez sur une erreur d’autorisation ou un écran qui ne charge plus.
Il y a plusieurs causes probables, mais la plus fréquente, c’est un décalage de droits et un fichier non accessible par l’utilisateur serveur. Un plugin de sécurité peut aussi s’attendre à des fichiers spécifiques qui n’ont pas été restaurés au bon endroit, ou à un état de configuration qui a été supprimé. Enfin, une différence de version de WordPress peut entraîner un problème de compatibilité sur certains écrans du back-office.
Dans tous les cas, je ne me contente pas de “réparer le thème”. Je traite la disponibilité de l’administration comme une priorité, parce que c’est elle qui permet ensuite de vérifier l’absence de persistance.
Le correctif consiste généralement à restaurer la cohérence des fichiers et de la base, puis à réexécuter quelques vérifications ciblées sur les actions d’écriture et la sauvegarde des options.
Rester lucide sur la récidive: disponibilité et sécurité doivent avancer ensemble
Vérifier la disponibilité après restauration ne remplace pas une démarche de sécurité. Un site peut être stable tout en ayant une faille encore exploitable. Et inversement, un site peut être sécurisé mais inutilisable.
L’approche la plus saine consiste à traiter les deux axes de façon simultanée:
- disponibilité: le site répond correctement et reste utilisable sécurité: la désinfection a bien supprimé les persistances, et les vecteurs d’entrée ont été fermés ou réduits
Dans la pratique, vous devrez peut-être choisir un ordre. Si le site est en production et que le trafic repart, vous priorisez l’accès au front et au back-office. Ensuite, vous approfondissez la partie sécurité, parce qu’à ce moment là, vous avez un site stable où vous pouvez analyser les logs et vérifier les comportements.
Plan de validation “terrain” après désinfection WordPress
Je termine avec un plan simple, qui correspond à la manière dont je valide une restauration quand je suis responsable de la remise en ligne.
L’idée: vous validez d’abord les fondations, puis vous testez les parcours, puis vous surveillez.
- d’abord, disponibilité HTTP, absence d’erreurs grossières, redirections cohérentes ensuite, rendu des pages et chargement des ressources puis, accès à l’administration, sauvegarde des options, tests de formulaires enfin, surveillance courte pour détecter l’instabilité et les erreurs qui apparaissent après exécution de tâches planifiées
Si quelque chose bloque, vous corrigez avant d’élargir les tests. Ce n’est pas juste une question de méthode, c’est une question de temps. Corriger un problème de redirection au début évite de perdre une heure à chercher une cause plus profonde pendant que le cache masque les effets réels.
Ce que j’attends d’une restauration “réussie”
Une restauration qui réussit, c’est celle où vous pouvez répondre sans hésiter à trois questions:
- le site répond aux visiteurs, de façon stable l’administration fonctionne, au moins pour les actions essentielles les symptômes d’attaque ne reviennent pas, ou ne reviennent pas dans un délai court
Si vous avez l’impression que “c’est revenu”, mais que vous sentez une fragilité dans le comportement, c’est probablement le cas. Après désinfection WordPress, la disponibilité est un état à construire, pas un bouton vert.
Et c’est précisément pour ça que vérifier la disponibilité après restauration est une étape à part entière, pas une formalité de fin de chantier.