Ne pas répéter un nettoyage dont le périmètre reste inconnu
Après une intervention autorisée, un propriétaire reçoit un nouveau signalement concernant une page de spam ou un fichier déjà retiré. Un ancien affichage, une copie restaurée ou un traitement encore actif peuvent expliquer le constat. Reprenez les relevés disponibles et identifiez la bonne installation avant de décider d’un nouveau nettoyage.
Préparez avec le propriétaire et l’hébergeur un inventaire de référence, un dossier de suivi et des critères de reprise. Le relevé doit permettre de distinguer un ancien signalement, une écriture réellement observée et une cause encore à établir.
Prévenez le propriétaire et l’hébergeur. Si les visiteurs sont exposés à une page frauduleuse, une redirection ou un téléchargement dangereux, demandez un confinement immédiat adapté. La conservation des traces doit accompagner la réduction du risque ; elle ne doit pas servir à maintenir une page dangereuse ouverte en attendant une enquête parfaite.
Construire une chronologie avec les états réellement observés
Notez l’URL ou le chemin concerné, la date de découverte, l’heure du retrait et celle du retour, avec les fuseaux. Décrivez précisément le premier nettoyage : fichiers remplacés, contenus retirés, restauration, accès fermés et composants mis à jour. Une mention générale « site nettoyé » ne permet pas de savoir ce qui a été traité.
Conservez les rapports et les copies privées disponibles avant de recommencer. Une personne autorisée peut comparer l’élément ancien et celui qui revient, notamment leur contenu ou leur empreinte. Le même nom ne prouve pas que les données sont identiques ; une date de modification ne désigne pas nécessairement l’auteur de l’écriture.
Relevez aussi les opérations normales proches de la réapparition : import, déploiement, restauration, synchronisation ou tâche planifiée. Ce rapprochement fournit une piste, pas une preuve contre l’outil nommé. Ne relancez pas ces opérations sur le site actif uniquement pour voir si le spam revient.
Relevez la version de WordPress, le type d’hébergement et les accès disponibles, sans supposer que tous les écrans ou journaux existent dans votre offre.
Choisir entre ancien affichage, mécanisme persistant et accès restant
La première approche vérifie ce qui réapparaît exactement. Un ancien résultat de recherche ou une page en cache peut montrer une version retirée sans qu’un nouveau contenu ait été écrit dans WordPress. Il faut comparer l’affichage et l’état actuel de la bonne installation.
La deuxième recherche un mécanisme persistant : composant, tâche ou contenu qui n’a pas été couvert par l’intervention initiale. Elle convient lorsque le nouvel élément est bien présent dans les fichiers ou la base, alors que l’entrée supposée a été traitée.
La troisième examine un accès ou une source de réintroduction : compte, hébergement, intégration, sauvegarde ou chaîne de déploiement. Elle devient essentielle si la modification revient après une ouverture ou un traitement précis. Ces pistes peuvent se combiner. Ne déclarez pas un accès innocent parce qu’un fichier a été supprimé, ni une intrusion nouvelle parce qu’un moteur affiche encore un ancien titre.
Approche 1 : comparer l’affichage et la bonne installation
Confirmez d’abord le domaine, le serveur et l’environnement qui ont été nettoyés. Une ancienne copie encore reliée au domaine ou un sous-site oublié peut expliquer un résultat différent. Demandez au prestataire de rapprocher le chemin de l’intervention et l’installation réellement servie, sans déplacer des fichiers pour essayer.
Si le signalement provient déjà de Google, consultez l’état indexé de l’adresse signalée dans la propriété Search Console autorisée. Rapprochez sa date du constat déjà consigné par le mainteneur. L’état indexé correspond à la dernière version connue par le moteur et peut être antérieur au nettoyage.
Consultez le relevé du cache disponible dans le tableau de bord de votre prestataire et rapprochez-le de l’inventaire de référence. Si le relevé montre une copie antérieure, demandez une invalidation ciblée de la page déjà identifiée. Une nouvelle écriture documentée à la source appelle l’examen des traitements et des accès autorisés.
Confirmer une nouvelle écriture sans exécuter le fichier suspect
Une personne autorisée peut vérifier la présence du contenu dans la bonne base ou du fichier au chemin concerné. Pour une page, relevez son identifiant et son état plutôt que de conclure à partir d’un extrait de moteur. Pour un fichier, conservez les informations et une copie protégée selon la procédure d’incident.
N’ouvrez pas un fichier PHP suspect dans le navigateur et ne le lancez pas pour voir ce qu’il fait. Ne chargez pas non plus une archive entière dans un site de test connecté à la production. L’analyse doit être conduite dans un environnement séparé, préparé pour cette tâche.
Comparez les éléments avant et après avec le mainteneur. Un fichier déjà présent peut avoir été seulement renommé, restauré ou rendu visible autrement. Lorsque la nouvelle écriture est établie, cherchez ce qui pouvait l’effectuer à cette heure. Une empreinte différente confirme une différence de contenu, sans identifier à elle seule son origine.
Contenir le site avec une responsabilité et un périmètre clairs
Ouvrez un ticket privé depuis le compte client connu de l’hébergeur. Fournissez la chronologie et demandez une préservation de l’état ainsi qu’un confinement adapté. Le responsable doit préciser ce qui est limité : accès administratif, écriture, intégration ou diffusion publique. Une simple page de maintenance ne garantit pas l’arrêt des mécanismes internes.
Sur une boutique, indiquez les commandes et paiements récents à préserver. Sur un hébergement partagé, précisez les autres sites présents dans le compte. Ne stoppez pas vous-même un serveur ou une file commune dont vous ne connaissez pas les usages. Le prestataire doit choisir une action proportionnée et réversible.
Définissez également qui peut autoriser la reprise et quels contrôles sont attendus avant réouverture. Une disparition provisoire du spam n’est pas ce critère à elle seule. Gardez les traces des mesures et de leurs horaires afin de comprendre si la récidive continue alors que certains accès sont réellement fermés.
Approche 2 : revoir ce que le premier nettoyage a réellement couvert
Reprenez le rapport initial avec le prestataire. Le cœur WordPress, les thèmes, les extensions, les médias, la base et la configuration ne sont pas un seul ensemble interchangeable. Remplacer certains fichiers du programme ne retire pas nécessairement des contenus en base ou une modification présente ailleurs.
Utilisez les résultats d’intégrité déjà consignés par le mainteneur. Demandez les versions comparées, le périmètre du contrôle et les exceptions. Pour un fichier déjà signalé, restez sur l’élément identifié dans le relevé privé. Un écart doit être interprété avec le responsable qui connaît le déploiement.
Faites consigner le périmètre contrôlé et les exceptions. N’exécutez pas une série de commandes dans une installation suspecte sans environnement préparé par le mainteneur. Une vérification d’intégrité est un outil de comparaison, pas une attestation que la base, les accès d’hébergement et toutes les intégrations sont sains.
Examiner les composants moins visibles et les sources externes
La liste habituelle des extensions ne représente pas forcément tout le code chargé. Les extensions obligatoires, ou mu-plugins, sont activées automatiquement dans l’installation. Leur présence peut être parfaitement légitime, notamment sur un hébergement géré. Les désigner comme inconnues ne suffit pas à conclure qu’elles sont malveillantes.
Demandez au mainteneur de rapprocher ces composants des outils de l’hébergeur, des développements convenus et des versions attendues. Il doit vérifier leur provenance et leur portée avant une correction. Ne supprimez pas le répertoire des composants obligatoires pour obtenir une liste plus courte.
Examinez également les imports, outils éditoriaux, espaces de stockage et services tiers qui peuvent réinjecter du contenu. Une ancienne copie utilisée comme source peut remettre en place ce qui vient d’être retiré. Pour chaque trajet, identifiez le responsable, les données envoyées et les accès utilisés. Une intégration reconnue mérite elle aussi d’être vérifiée si elle correspond à l’heure du retour.
Rapprocher la récidive des tâches sans vider les files
Une tâche planifiée peut créer des données ou rappeler un service externe. WordPress possède WP-Cron, dont le déclenchement dépend normalement de l’activité du site ; l’hébergement peut aussi utiliser son propre ordonnanceur. La réapparition à un intervalle similaire fournit une piste, sans prouver quel système l’a produite.
Faites relever le nom de la tâche, le composant qui l’enregistre et les horaires disponibles. Le mainteneur doit comparer ces informations aux journaux et aux nouvelles écritures. Une tâche portant un nom technique ou inconnu n’est pas nécessairement hostile. Certaines synchronisations légitimes peuvent aussi relancer un import contenant un contenu indésirable.
Ne videz pas toutes les tâches et ne cliquez pas sur Exécuter pour tester une hypothèse en production. Une file peut gérer des paiements, des notifications ou des stocks. Si un mécanisme est identifié, préparez sa suspension ciblée avec son responsable, sa sauvegarde et ses conséquences métier. Gardez les éléments utiles avant de modifier son calendrier.
Évaluer une restauration sans réintroduire le problème
Une sauvegarde plus ancienne peut fournir une base de reprise, mais son ancienneté ne prouve pas qu’elle précède toute compromission. Faites examiner plusieurs points disponibles et rapprochez leur date de la chronologie. Une copie déjà modifiée peut remettre les mêmes composants ou comptes en place.
Préparez une restauration dans un environnement isolé, avec base distincte et effets externes neutralisés. Paiements, courriels, synchronisations et déploiements vers la production doivent rester désactivés pour cette analyse. La copie doit permettre de vérifier le contenu et les versions sans contacter les services réels par erreur.
Avant tout remplacement de production, identifiez les données récentes à conserver : commandes, comptes, articles et opérations métier. Leur réconciliation dépend du site et ne se réduit pas à recopier quelques lignes SQL. Conservez l’état actuel pour l’enquête et la récupération. Si la cause est une source qui réinjecte les données, restaurer sans corriger cette source ne suffit pas.
Approche 3 : fermer les accès et les sources de réintroduction
Le propriétaire et l’hébergeur doivent revoir les accès capables d’écrire : comptes WordPress, compte client, transferts de fichiers, outils de déploiement et intégrations. Vérifiez les identités attendues, les changements récents et les autorisations encore nécessaires. Un utilisateur connu peut avoir perdu le contrôle de son compte.
Depuis un appareil fiable, organisez la fermeture ou la rotation des accès concernés, avec leurs dépendances. Changer seulement le mot de passe de votre profil ne traite pas nécessairement les autres comptes, les sessions ou les outils d’accès. Le responsable doit savoir ce qui a été révoqué et ce qui reste actif.
Ne créez pas des administrateurs supplémentaires pour essayer de reprendre le contrôle et ne transformez pas un compte suspect en compte principal. Préservez son identité et ses contenus utiles au dossier. Si les modifications continuent malgré le blocage de certains accès, ce constat réduit le champ de recherche ; il demande une analyse des autres trajets, pas une simple répétition de la même rotation.
Corriger la cause avant de remettre la chaîne de production en service
L’intervention finale doit expliquer la faiblesse ou le mécanisme identifié : composant vulnérable, accès compromis, source de données altérée ou procédure de déploiement incorrecte, selon les preuves. Une mise à jour peut être nécessaire, mais il faut vérifier qu’elle répond bien au problème et qu’elle ne remet pas une copie indésirable.
Faites obtenir les versions de remplacement depuis les sources officielles du composant, avec préservation des personnalisations nécessaires. Les fichiers, la base et les réglages doivent correspondre à un ensemble cohérent. Une réinstallation partielle du cœur n’efface pas automatiquement un contenu de spam enregistré ailleurs.
Contrôlez aussi les sources qui pourront être utilisées plus tard : archives de déploiement, sauvegardes sélectionnées et stockage externe. Elles doivent être identifiées avant d’être réintroduites. Si la cause n’a pas été déterminée, dites-le dans le dossier et faites choisir une reprise encadrée par le responsable. La seule disparition de l’élément visible ne justifie pas de déclarer le site définitivement nettoyé.
Adapter la recherche à WordPress.com et au réseau multisite
Sur WordPress.com, utilisez le compte du propriétaire reconnu et le support. Consultez les événements disponibles dans le journal d’activité et faites confirmer les possibilités de restauration du site. Notez la période effectivement couverte par le journal et les éléments que le prestataire doit encore vérifier.
Ne transposez pas une procédure de suppression de fichiers dans une zone gérée. Les composants fournis par la plateforme et les intégrations installées doivent être distingués. Si une fonction nécessaire n’est pas accessible, transmettez les éléments au support plutôt que de remplacer les outils de sécurité.
En multisite, les utilisateurs et certains composants sont partagés. Un sous-site intact peut dépendre du même code qu’un sous-site affecté. Le responsable du réseau doit examiner cette portée et les autres sites concernés avant une remise en service collective. Une correction locale ou une sauvegarde d’un seul sous-site ne prouve pas que tout le réseau a été traité.
Comparer les inventaires et décider si la reprise peut continuer
Le site fictif de la Maison des Saules a retiré une page et un fichier signalés. L’équipe prépare trois relevés datés dans son dossier privé. Le premier décrit les éléments connus avant le retrait. Le deuxième fixe l’état observé après le nettoyage. Le troisième reprend le même périmètre après l’échéance à laquelle le problème revenait. Utilisez le même fuseau ou convertissez les heures en UTC. Indiquez le site et l’environnement sur chaque relevé.
Sur WordPress.com, appuyez-vous sur le journal et les options de restauration disponibles pour le site. Sur un hébergement indépendant, demandez au prestataire les relevés du site et des opérations qu’il gère. La fiche de suivi distingue la présence d’un élément, l’origine d’une écriture et la décision du propriétaire.
- Préparez la référence après nettoyage depuis l’inventaire du propriétaire ou les relevés transmis par l’hébergeur. Pour une page, notez son identifiant dans l’administration et son état. Pour un fichier déjà signalé, demandez au mainteneur son identifiant ou son chemin connu dans le relevé privé et, si disponible, son empreinte. Indiquez ce que le relevé couvre et ce qui manque. Une absence est interprétable dans le périmètre effectivement couvert.
- Comparez avec le relevé suivant. Classez les éléments ajoutés, disparus ou modifiés. Dans l’exercice, les entrées fictives PAGE‑72 et FICHIER‑19 sont présentes avant le retrait, absentes de la référence et présentes au contrôle suivant. Un article de travail enregistré entre les deux relevés apparaît aussi. Le journal éditorial confirme sa publication attendue. Les deux autres entrées sont signalées au responsable comme une réapparition observée. Un horaire voisin dans le journal de synchronisation donne une piste à l’hébergeur. Il faut un événement qui relie le traitement à l’écriture avant d’attribuer la cause.
- Si seul un ancien titre reste visible dans un rapport déjà reçu et que les deux inventaires comparables ne montrent aucun retour, consignez « aucune nouvelle écriture observée dans le périmètre vérifié ». Précisez la date du rapport et les éventuelles lacunes du relevé. Si les inventaires concernent des environnements différents ou que la période du journal manque, classez le résultat comme indéterminé et demandez le relevé complémentaire par le canal de support habituel.
- Préparez la reprise sur une copie locale isolée, avec des données fictives et les courriels, paiements et synchronisations neutralisés. Comparez l’inventaire de la sauvegarde candidate avec la référence et les éléments signalés. Dans l’exercice, écartez la sauvegarde qui contient PAGE‑72 et FICHIER‑19. Vérifiez que la copie restaurée conserve la page témoin et que le plan de reprise préserve le contenu légitime créé après la sauvegarde. Pour un site réel, le responsable doit aussi valider la cohérence entre les fichiers, la base et les données récentes à réconcilier.
- Donnez au propriétaire un critère de reprise par fonction. Le résultat doit associer la correction documentée, le fonctionnement attendu sur la copie et un relevé à l’échéance pertinente. Si la cause reste incertaine, le responsable peut décider d’une reprise limitée et surveillée en maintenant le confinement nécessaire. Si un élément revient, si un contrôle reste impossible ou si une fonction utile échoue, suspendez l’étape de reprise concernée. Conservez les relevés et la dernière sauvegarde de référence privée. Transmettez au support les horaires, le périmètre, les identifiants utiles et la prochaine décision attendue.
Transmettre une conclusion précise et conserver la possibilité d’enquêter
Le rapport de résolution doit dire ce qui était ancien, ce qui a été réellement recréé, le mécanisme identifié et les accès traités. Notez les versions retenues, les sauvegardes utilisées, les données récentes préservées et les contrôles effectués. Distinguez la vérification documentaire d’un composant et les essais réellement réalisés sur votre site.
Si des données personnelles semblent exposées, informez le responsable de leur protection pour évaluation. Ne publiez pas de fichier suspect, de base exportée ou de jeton pour prouver le problème. Utilisez le canal privé prévu avec le prestataire et limitez les pièces jointes aux besoins de l’analyse.
Pour prévenir une nouvelle réintroduction, documentez les sources de déploiement, les responsables des intégrations et les tâches indispensables. Gardez des sauvegardes distinctes et vérifiez les mécanismes de reprise. Lorsqu’une cause reste incertaine, conservez cette réserve : le bon suivi doit pouvoir expliquer ce qui est maîtrisé et ce qui demande encore une investigation.
