La première fois que j'ai eu affaire à un site WordPress piraté, le site n'avait l'air de rien. Pas de page d'accueil défigurée, pas de revendication, pas de ralentissement. C'est une alerte de Google qui m'a mis la puce à l'oreille : des adresses que je n'avais jamais écrites apparaissaient dans l'index. Une requête site:mondomaine.fr a suffi à les faire sortir par dizaines — des pages fabriquées automatiquement autour de mots-clés porteurs, farcies de liens douteux. Du spamdexing classique : l'attaquant ne casse rien, il se sert de l'autorité d'un domaine qui n'est pas le sien.
La suite a été instructive. Le trafic a d'abord grimpé de façon absurde, porté par ces pages parasites, puis Google a corrigé l'anomalie et le site est resté marqué comme compromis. Il a fallu nettoyer, puis demander un réexamen pour récupérer sa place. Depuis, je déroule toujours le même ordre : constat, mise hors ligne, sauvegarde de preuve, nettoyage, réinstallation propre, rotation des secrets, réexamen. Avec une étape souvent oubliée et pourtant obligatoire : le volet RGPD.
Pourquoi WordPress concentre autant d'incidents
Ce n'est pas une question de qualité, mais de surface d'exposition. Au 11 septembre 2026, WordPress équipe 40,3 % de l'ensemble des sites web et 58,8 % de ceux dont le CMS est identifié, selon le relevé quotidien de W3Techs (top 10 millions de sites). Les attaques y sont automatisées : elles cherchent des failles connues, pas votre entreprise. Dans son rapport State of WordPress Security publié le 25 février 2026 et portant sur 2025, Patchstack recense 11 334 nouvelles vulnérabilités dans l'écosystème, dont 91 % dans des extensions, contre 6 dans le cœur de WordPress, toutes de priorité basse. Le risque vient donc de ce qu'on ajoute et de ce qu'on oublie de mettre à jour. Le rapport d'activité 2025 de Cybermalveillance.gouv.fr, publié le 26 mars 2026, place d'ailleurs le piratage de compte en tête des menaces déclarées par les professionnels en France (+45 % en un an).
1. Constater : qualifier ce qu'on voit avant d'agir
Un « piratage » ne veut rien dire tant qu'on n'a pas décrit les symptômes. La documentation WordPress parle d'indicateurs de compromission : site signalé par un moteur, compte suspendu par l'hébergeur, avertissement d'antivirus chez les visiteurs, administrateurs créés sans vous, redirections inattendues, pages inconnues indexées. Notez ce que vous voyez, à quelle heure, et ce qui a changé récemment.
Deux vérifications donnent déjà beaucoup : le rapport « Problèmes de sécurité » de la Search Console, et une recherche site: sur votre domaine. Ce constat écrit devient votre rapport d'incident : il servira pour l'hébergeur, pour l'assurance, et pour le registre RGPD. Si vous préférez déléguer, c'est l'objet de ma prestation de remise en état d'un site piraté.
2. Couper l'exposition
Tant que le site sert du spam ou du code malveillant, chaque heure aggrave la situation : réputation du domaine, adresse IP placée sur liste noire, courriels sortants bloqués. Mettez le site hors ligne avec un vrai code de réponse 503, qui signale aux moteurs une indisponibilité temporaire. Quelques jours n'entament pas durablement le référencement, alors qu'un site infecté laissé en ligne, si.
Prévenez l'hébergeur dans la foulée : en mutualisé, plusieurs installations partagent le même compte et se réinfectent mutuellement, et lui seul détient certains journaux d'accès.
3. Faire une sauvegarde de preuve avant de nettoyer
Avant de supprimer quoi que ce soit, prenez une copie complète de l'existant, y compris infecté : fichiers, base de données, et surtout les journaux (accès HTTP, SFTP, panneau d'hébergement, connexions à l'administration). Stockez-la hors du serveur et ne l'exécutez jamais.
Cette archive sert à trois choses : retrouver un contenu légitime effacé par erreur, documenter l'intrusion si vous déposez plainte, et comprendre par où l'accès a eu lieu. La documentation WordPress consacrée aux sites compromis, mise à jour le 26 juillet 2026, recommande explicitement ce cliché intermédiaire avant toute remédiation.
4. Nettoyer : remplacer plutôt que réparer
Corriger un fichier infecté ligne par ligne est une perte de temps. La bonne logique : remplacer tout ce qui l'est par une version officielle, inspecter seulement le reste.
| Élément | Traitement | Pourquoi |
|---|---|---|
| Cœur de WordPress | Remplacement intégral par l'archive officielle de la même version, déposée en SFTP | Les installateurs internes écrasent l'existant mais laissent les fichiers ajoutés |
| Extensions et thèmes | Réinstallation depuis la source officielle, suppression de tout ce qui n'est pas utilisé | 91 % des vulnérabilités recensées en 2025 par Patchstack visent des extensions |
| Dossier des médias | Inspection : un fichier exécutable n'a rien à y faire | Dossier accessible en écriture, cible fréquente |
| Fichier .htaccess | Comparaison avec une version saine, à la racine et dans les sous-dossiers | Fichier le plus souvent modifié, à l'origine des redirections |
| Base de données | Revue des comptes, des options chargées automatiquement et des tâches planifiées | Un nettoyage limité aux fichiers laisse le mécanisme de réinfection intact |
Le fichier wp-config.php se conserve, mais se relit ligne par ligne : il ne doit rien contenir d'autre que vos identifiants de base de données. Un scanner applicatif (Wordfence, Sucuri Scanner, Quttera) repère les fichiers modifiés en les comparant aux versions officielles, mais il ne dit pas comment l'attaquant est entré : c'est un détecteur, pas une preuve de propreté.
5. Repartir d'une installation propre quand le doute persiste
Si le site a été compromis plusieurs fois, si le point d'entrée reste introuvable, ou si l'installation traîne des extensions abandonnées depuis des années, la reconstruction coûte moins cher que le nettoyage. Je monte alors une installation neuve sur un hébergement sain, j'y réimporte le contenu vérifié, et je réinstalle les extensions une par une depuis leur source officielle. L'ancienne n'est éteinte qu'une fois la nouvelle validée, URL par URL.
6. Faire tourner tous les secrets
Un nettoyage sans rotation des identifiants ne sert à rien : l'accès reste ouvert. Changez dans la même séquence les mots de passe de tous les comptes de l'administration WordPress, les accès SFTP, le panneau d'hébergement, l'utilisateur de la base de données, les identifiants SMTP et les clés d'API des services connectés.
Ajoutez deux gestes propres à WordPress. La régénération des clés de sécurité de wp-config.php, via le générateur officiel de WordPress.org, qui invalide toutes les sessions ouvertes. Puis la revue des comptes, mots de passe d'application compris — ces jetons survivent à un changement de mot de passe. Supprimez tout compte que vous ne pouvez pas rattacher à une personne identifiée.
C'est précisément là que l'incident raconté en introduction trouvait son origine : un compte de démonstration, jamais supprimé, avec un mot de passe trivial. C'est presque toujours ce genre de détail.
7. RGPD : le compteur de 72 heures démarre au constat
Un site piraté n'est pas qu'un problème technique. Dès lors que des données personnelles ont pu être consultées, modifiées ou détruites — comptes clients, commandes, messages de formulaires, adresses de newsletter — vous êtes face à une violation de données au sens du RGPD.
La règle, rappelée par la CNIL sur sa page dédiée à la notification, tient en trois points. L'article 33 impose au responsable de traitement de notifier la violation à la CNIL dans les meilleurs délais, si possible sous 72 heures après en avoir pris connaissance, sauf si elle est peu susceptible d'engendrer un risque pour les personnes ; la notification passe par le téléservice de la CNIL et peut être faite en deux temps. L'article 34 impose d'informer directement les personnes concernées lorsque le risque pour leurs droits et libertés est élevé, par exemple un vol de mots de passe. Enfin, toute violation doit être consignée dans un registre interne, même non notifiée : nature de l'incident, personnes touchées, conséquences probables, mesures prises.
Deux précisions. Le délai court dès que vous avez connaissance de l'incident, pas à la fin du nettoyage : ne retardez pas la notification. Et si vous êtes prestataire plutôt que responsable de traitement, votre obligation est d'alerter sans délai le client, à qui revient la déclaration.
8. Faire lever l'alerte dans la Search Console
Le site remis en ligne, il reste à convaincre Google. Ouvrez le rapport « Problèmes de sécurité », déroulez la description pour obtenir la liste des URL touchées, vérifiez que chacune est corrigée, puis lancez la demande de réexamen en décrivant ce que vous avez fait : point d'entrée identifié, éléments remplacés, identifiants renouvelés. L'aide Google est explicite : corriger quelques pages ne suffit pas, l'intégralité du site doit être assainie, et le traitement prend généralement de plusieurs jours à plusieurs semaines. N'envoyez pas plusieurs demandes en parallèle.
Traitez aussi les pages parasites déjà indexées : elles doivent renvoyer un code 404 ou 410, et non rediriger vers l'accueil. Ce suivi relève du contrôle de l'indexation à mener les semaines suivantes.
Prévenir la prochaine fois
- Mises à jour automatiques activées pour le cœur, les extensions et les thèmes. La dernière version stable est WordPress 7.1, publiée le 19 août 2026 ; seule la branche la plus récente est activement maintenue.
- Version de PHP supportée. Au 11 septembre 2026, php.net indique que PHP 8.4 et 8.5 bénéficient d'un support actif, que 8.2 et 8.3 ne reçoivent plus que des correctifs de sécurité, et que 8.0 et 8.1 sont en fin de vie.
- Moins d'extensions, mieux choisies. Supprimez celles que vous n'utilisez pas — désactivée ne veut pas dire inoffensive — et écartez celles qui ne sont plus maintenues.
- Comptes au strict nécessaire : un compte par personne, rôle minimal, double authentification pour les administrateurs, suppression immédiate des accès temporaires.
- Sauvegardes externalisées et testées. Une sauvegarde stockée sur le serveur compromis ne vaut rien ; restaurez-la une fois par an.
- Surveillance : contrôle d'intégrité des fichiers, alertes Search Console envoyées sur une adresse réellement relevée, et suivi du trafic. Un pic inexpliqué sur des pages inconnues est un signal d'alerte : c'est le rôle du pilotage de la mesure webmarketing de le faire remonter vite.
Aucune de ces mesures ne rend un site inviolable. Elles réduisent la surface d'attaque et raccourcissent le délai entre l'intrusion et sa détection. C'est ce délai qui fait la différence entre une soirée de travail et plusieurs semaines de réparation.
Questions fréquentes
Comment savoir si mon site WordPress est vraiment piraté ?
Plusieurs signaux font consensus : des pages que vous n'avez jamais publiées apparaissent dans une recherche site:votredomaine.fr, la Search Console affiche une alerte dans son rapport « Problèmes de sécurité », l'hébergeur suspend le compte, des visiteurs signalent des redirections ou des avertissements d'antivirus, ou des comptes administrateurs sont créés sans votre intervention. Un seul de ces indices suffit à justifier une vérification complète. Notez par écrit ce que vous observez et à quelle heure avant toute manipulation.
Faut-il mettre le site hors ligne pendant le nettoyage ?
Oui, dès que le site diffuse du contenu indésirable ou du code malveillant. Utilisez un mode maintenance qui renvoie un code de réponse 503, lequel signale aux moteurs une indisponibilité temporaire. Quelques heures ou quelques jours d'indisponibilité pèsent beaucoup moins lourd qu'un site infecté laissé accessible, qui risque la mise en liste noire du domaine et de l'adresse IP.
Dans quel cas faut-il notifier la CNIL après un piratage ?
Dès qu'un incident a pu exposer, modifier ou détruire des données personnelles et qu'il présente un risque pour les personnes concernées, l'article 33 du RGPD impose une notification à la CNIL dans les meilleurs délais, si possible sous 72 heures après en avoir pris connaissance. La déclaration se fait par le téléservice de la CNIL et peut être complétée ensuite si l'analyse n'est pas terminée. Lorsque le risque est élevé, l'article 34 oblige en plus à informer directement les personnes concernées.
Combien de temps Google met-il à lever une alerte de sécurité ?
L'aide Google indique que le traitement d'une demande de réexamen prend généralement de plusieurs jours à plusieurs semaines. Le délai dépend de la qualité du nettoyage : s'il reste des éléments compromis, la demande est rejetée et il faut recommencer. Envoyer plusieurs demandes en parallèle ne l'accélère pas et brouille le suivi.
Un plugin de sécurité suffit-il à protéger un site WordPress ?
Non. Une extension de sécurité détecte des fichiers modifiés, filtre une partie du trafic et alerte, mais elle ne corrige ni une extension obsolète, ni un mot de passe faible, ni un compte administrateur oublié. Sur l'année 2025, Patchstack a recensé 11 334 vulnérabilités dans l'écosystème WordPress, dont 91 % dans des extensions : mettre à jour et réduire le nombre d'extensions installées restent les mesures les plus efficaces.
Mon référencement se remet-il d'un piratage ?
Dans la plupart des cas oui, à condition que le nettoyage soit complet et que les pages parasites indexées renvoient un code 404 ou 410. La récupération est progressive : elle suit la levée de l'alerte de sécurité, puis la réexploration des pages légitimes par les moteurs. Le suivi de l'indexation dans les semaines qui suivent permet de vérifier que les pages frauduleuses disparaissent et que les vôtres reviennent.