Site WordPress piraté : le guide ultime 2026

TL;DRPar Zelia Gutierrez. Article à jour en septembre 2026 : les délais légaux et les procédures Google citées ont été vérifiés à cette date.

📌 ⏱ À faire dans les 15 prochaines minutes#

1. Ne supprimez rien. Ni fichier, ni extension, ni compte.
2. Appelez votre hébergeur ou votre prestataire et dites : « Mon site est compromis. »
3. Demandez une copie complète du site, de la base de données et des journaux du serveur, en l'état.
4. Changez le mot de passe de votre compte chez l'hébergeur et de votre messagerie, depuis un autre appareil que d'habitude si possible.
5. Notez l'heure et ce que vous avez vu. Faites des captures d'écran.

Vous venez de découvrir un problème sur votre site. Ce n'est pas le moment de tout comprendre. C'est le moment de suivre les étapes ci-dessous, dans l'ordre. Chaque étape indique quand la faire. Les encadrés Pour le technicien s'adressent à la personne qui interviendra sur le serveur : transmettez-les-lui.

📌 Étape 1 : confirmer que le site est bien compromis#

Quand : immédiatement, 10 minutes.

Tous les dysfonctionnements ne sont pas des piratages. Une page blanche peut venir d'une mise à jour ratée. Un certificat expiré déclenche aussi un avertissement du navigateur. Vérifiez avant d'agir.

Signes d'un vrai piratage :

• Contenu inconnu : pages de pharmacie, de casino, textes en japonais ou en russe. Tapez site:votredomaine.fr dans Google pour voir les pages indexées.
• Redirections sélectives : le site fonctionne quand vous tapez l'adresse, mais redirige vers un site étranger quand on vient de Google, ou seulement sur mobile. Testez depuis votre téléphone, en 4G, via une recherche Google.
• Alerte dans la Search Console : un message dans le rapport Problèmes de sécurité.
• Avertissement du navigateur : page rouge plein écran avant l'accès au site.
• Mention « Ce site peut être piraté » sous votre résultat dans Google. Google l'affiche quand il estime qu'un pirate a modifié des pages ou ajouté des pages de spam.
• Signalement de l'hébergeur : suspension du compte ou email d'alerte.
• Pics de trafic anormaux vers des pages que vous n'avez pas créées.
• Emails sortants en masse : retours « message non distribué » que vous n'avez jamais envoyés, ou emails de votre domaine classés en spam chez vos clients.

Ce qui n'est probablement pas un piratage : une erreur 500 juste après une mise à jour, un certificat SSL expiré, un email de « chantage » affirmant que votre site est piraté sans aucune preuve. Ce dernier cas est une arnaque connue, décrite par Cybermalveillance.gouv.fr.

Vous pouvez aussi vérifier le statut de votre domaine sur l'outil public de navigation sécurisée de Google (Transparency Report).

📌 Étape 2 : ne pas détruire les preuves#

Quand : dans la première heure. Avant tout nettoyage.

Le réflexe naturel est de tout effacer. Résistez. Une copie du site dans son état compromis sert à trois choses :

1. Identifier la faille. Sans elle, vous nettoyez sans savoir par où l'attaquant est entré. Il reviendra par la même porte.
2. Dater l'intrusion. La date d'entrée vous dit quelle sauvegarde est saine et depuis combien de temps des données ont pu être consultées.
3. Établir si des données personnelles ont été touchées. C'est indispensable pour l'étape légale (étape 8). Sans journaux, vous ne pourrez ni prouver qu'aucune donnée n'a fuité, ni déposer une plainte étayée.

Cybermalveillance.gouv.fr recommande de conserver les journaux des serveurs et de réaliser des copies complètes avant toute restauration, pour les tenir à disposition des enquêteurs.

Ce qu'il faut conserver :

• tous les fichiers du site ;
• une exportation de la base de données ;
• les journaux du serveur web (qui a demandé quelle page, quand, depuis quelle adresse) ;
• les journaux FTP/SFTP et de connexion au panneau de l'hébergeur si disponibles ;
• vos captures d'écran et vos notes horodatées.

Stockez cette copie hors du serveur, sur un support que l'attaquant ne peut pas atteindre. Ne l'ouvrez pas sur votre poste de travail habituel : elle contient des fichiers malveillants.

Pour le technicien

# Archive des fichiers, en conservant dates et droits
tar -czpf /chemin/hors-webroot/site-compromis-$(date +%F-%H%M).tar.gz /chemin/du/site
# Export de la base
mysqldump --single-transaction -u UTILISATEUR -p NOM_BASE > base-compromise-$(date +%F-%H%M).sql
# Empreinte des archives, pour prouver qu'elles n'ont pas été modifiées ensuite
sha256sum site-compromis-*.tar.gz base-compromise-*.sql > empreintes.txt

Copiez aussi les journaux d'accès et d'erreurs du serveur web. Sur un serveur Debian ou Ubuntu avec la configuration par défaut, ils se trouvent dans /var/log/apache2/ ou /var/log/nginx/. Sur un hébergement mutualisé, ils se téléchargent depuis le panneau de l'hébergeur, souvent pour une durée limitée : récupérez-les tout de suite. Une empreinte de fichier (hash) est une signature calculée à partir du contenu : si un seul octet change, l'empreinte change.

📌 Étape 3 : limiter la casse#

Quand : dans la première heure.

Trois actions, dans cet ordre.

1. Mettre le site hors ligne ou en maintenance. Un site compromis peut infecter vos visiteurs, voler des données saisies dans un formulaire ou servir de relais à d'autres attaques. Google recommande de mettre le site hors ligne ou de renvoyer un code d'indisponibilité temporaire (503), qui indique aux moteurs de revenir plus tard sans désindexer vos pages.

2. Couper les accès inutiles. Désactivez les comptes FTP que vous n'utilisez pas. Demandez à votre hébergeur de restreindre l'accès à l'administration à votre seule adresse IP si c'est possible.

3. Suspendre les envois d'emails sortants. Si votre site envoie du spam, l'adresse de votre serveur finit sur des listes noires. Vos emails légitimes (factures, devis) ne parviendront plus. Demandez à votre hébergeur de bloquer l'envoi depuis le site.

L'arbitrage : couper tout de suite ou rester en ligne ?

En cas de doute, coupez. Quelques heures d'indisponibilité coûtent moins cher qu'une fuite de données clients.

Pour le technicien Préférez une page de maintenance servie par le serveur web avec un code 503, plutôt qu'une extension WordPress : le code PHP du site n'est plus exécuté et une porte dérobée (un accès caché laissé par l'attaquant) ne peut plus être appelée. N'éteignez pas brutalement la machine si une analyse de la mémoire est envisagée.

📌 Étape 4 : reprendre le contrôle des accès#

Quand : entre la première et la quatrième heure.

Changez tous les secrets. Pas seulement le mot de passe WordPress. Un seul secret oublié suffit à l'attaquant pour revenir.

Commencez par votre poste de travail. La documentation officielle WordPress le rappelle : l'infection vient parfois de l'ordinateur du propriétaire, où un logiciel espion capte les identifiants. Lancez une analyse antivirus complète, et changez les mots de passe depuis un appareil sain.

Liste des accès à réinitialiser :

1. Panneau de l'hébergeur et compte chez le registraire du nom de domaine.
2. Boîtes email associées au site, en priorité celle qui reçoit les réinitialisations de mot de passe.
3. Tous les comptes administrateurs WordPress, puis tous les autres comptes.
4. Base de données (le mot de passe est ensuite reporté dans le fichier de configuration wp-config.php).
5. FTP et SFTP, pour tous les utilisateurs.
6. Clés d'API : paiement, envoi d'emails, CRM, outils connectés.
7. Clés de sécurité WordPress. Ce sont des chaînes aléatoires stockées dans wp-config.php. Les remplacer invalide tous les jetons de session (les « badges » qui maintiennent un utilisateur connecté) : toute personne connectée, attaquant compris, est déconnectée.

Recherchez les comptes créés par l'attaquant. Dans Comptes > Tous les comptes, filtrez par rôle Administrateur. Un compte que vous ne reconnaissez pas, un nom générique, une adresse email inconnue : notez-le, faites une capture, puis supprimez-le. La date d'inscription du compte est un indice précieux pour dater l'intrusion.

Utilisez des mots de passe longs, uniques, générés par un gestionnaire de mots de passe. Activez la double authentification partout où c'est possible.

Pour le technicien

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp config shuffle-salts

Le générateur officiel de clés est à l'adresse https://api.wordpress.org/secret-key/1.1/salt/. Vérifiez aussi les comptes créés directement en base, qui n'apparaîtraient pas si une extension masque des utilisateurs dans l'interface.

📌 Étape 5 : trouver l'étendue de la compromission#

Quand : jour 1 à jour 3.

C'est l'étape la plus longue, et la plus importante. Retenez une règle : une compromission comporte presque toujours plusieurs portes dérobées. L'attaquant en dépose plusieurs, à plusieurs endroits, pour survivre à un premier nettoyage. Supprimer la plus visible ne règle rien.

Ce qu'on cherche :

• Fichiers modifiés récemment, en particulier autour de la date d'intrusion présumée.
• Fichiers PHP dans le dossier des médias (wp-content/uploads). Ce dossier ne doit contenir que des images et documents. Un fichier exécutable à cet endroit est presque toujours un webshell : un petit programme qui donne à l'attaquant une télécommande sur le serveur.
• Tâches planifiées inconnues. Une tâche planifiée est une action que le serveur ou WordPress exécute automatiquement à intervalles réguliers. Un attaquant s'en sert pour recréer ses fichiers après leur suppression.
• Entrées suspectes en base : options inconnues, scripts insérés dans des articles ou des widgets. On parle d'injection quand du contenu malveillant est glissé dans une page légitime.
• Fichiers de configuration du serveur web modifiés, notamment .htaccess. La documentation WordPress le désigne comme l'un des fichiers les plus souvent détournés. Il peut exister dans plusieurs sous-dossiers.
• Fichiers clés du thème : index.php, header.php, footer.php, functions.php. Modifiés, ils touchent toutes les pages du site.

📌 Ce que nous avons appris sur notre propre infrastructure#

En mai 2026, Websource a détecté deux vagues de compromission sur son hébergement mutualisé. Neuf fichiers malveillants ont été identifiés : des scripts PHP soumis à une obfuscation (un brouillage volontaire du code pour le rendre illisible) et déposés dans des répertoires accessibles publiquement.

Le premier traitement s'était limité à supprimer les fichiers détectés. La cause n'avait pas été corrigée. Un mois plus tard, une seconde vague est apparue.

Les difficultés rencontrées sont typiques :

• des fichiers dispersés dans plusieurs répertoires (médias, cache, thèmes) ;
• un brouillage qui rendait inefficaces les scanners fondés sur de simples signatures ;
• l'absence d'historique des versions sur les répertoires sensibles ;
• la difficulté à distinguer un fichier légitime d'un fichier injecté.

La seconde intervention a changé de méthode. Chaque fichier suspect a été mis en quarantaine dans un répertoire horodaté, hors de la zone publique du site, au lieu d'être supprimé. L'équipe a combiné un audit manuel et scripté, un suivi des versions des fichiers sensibles pour dater précisément chaque modification, un durcissement des droits et une rotation des accès FTP. Résultat : zéro fichier malveillant actif, et un passage d'une détection réactive à un scan périodique. Le détail est dans l'étude de cas.

La leçon pour vous : un seul fichier trouvé ne signifie pas un seul fichier présent.

Comment reconnaître un fichier suspect. Notre guide Comment détecter un webshell sur mon site détaille la méthode. Les signaux principaux :

• un fichier PHP dans un dossier de médias, de cache ou de fichiers temporaires ;
• un fichier appartenant à un utilisateur inattendu, par exemple root au lieu de l'utilisateur du site ;
• un fichier modifié récemment sans mise à jour ni déploiement correspondant ;
• un trafic sortant inhabituel ou une chute soudaine dans Google.

Pour examiner un fichier suspect, ouvrez-le dans un simple éditeur de texte, sans jamais l'exécuter ni l'appeler depuis un navigateur. Comparez l'ensemble avec une installation propre de WordPress de la même version.

Pour le technicien

# Intégrité du cœur et des extensions du dépôt officiel
wp core verify-checksums
wp plugin verify-checksums --all
# Fichiers PHP dans les médias
find wp-content/uploads -type f -name "*.php"
# Fichiers modifiés ces 30 derniers jours
find . -type f -mtime -30 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Tâches planifiées système et WordPress
crontab -l
wp cron event list
# Fonctions fréquemment détournées dans du code brouillé (repérage, pas preuve)
grep -rlE "eval\(|base64_decode\(|gzinflate\(" wp-content/

Ces trois fonctions sont celles ciblées dans notre audit ; elles ont aussi des usages légitimes. Mettez en quarantaine hors webroot, ne supprimez pas. Croisez les dates de modification avec les journaux d'accès pour retrouver la première requête suspecte.

📌 Étape 6 : nettoyer, ou reconstruire#

Quand : jour 2 à jour 4.

Soyons honnêtes sur ce qui fonctionne.

Fiable : remplacer par des versions officielles saines. Le cœur de WordPress (dossiers wp-admin et wp-includes), les thèmes et les extensions se téléchargent depuis leur source officielle. La documentation WordPress conseille de les remplacer par transfert de fichiers, pas via le bouton de réinstallation de l'administration : celui-ci écrase les fichiers existants mais laisse en place les fichiers ajoutés par l'attaquant. Réinstallez la même version, puis mettez à jour.

Peu fiable : nettoyer fichier par fichier. Le code brouillé est conçu pour ressembler à du code normal. Un seul fichier oublié, et tout recommence.

Ce qui reste à traiter à la main : le dossier des médias, le thème s'il est sur mesure, et la base de données.

Quand faut-il reconstruire entièrement ?

• vous ne pouvez pas dater l'intrusion avec certitude ;
• le thème ou des extensions ont été développés sur mesure et n'existent nulle part en version saine ;
• le site a été réinfecté après un premier nettoyage ;
• vous n'avez pas le temps ou les compétences pour une analyse complète.

Dans ces cas, repartez d'une sauvegarde antérieure à l'intrusion, sur un environnement neuf, puis réimportez uniquement le contenu vérifié.

Pourquoi restaurer sans avoir identifié la faille ne marche pas. Une sauvegarde saine contient aussi la faille qui a permis l'intrusion. Même extension obsolète, même mot de passe faible. Les attaques sont automatisées : des robots balaient Internet en continu. Le site restauré sera retrouvé et réinfecté, souvent en quelques jours.

🔒 Étape 7 : corriger la faille d'entrée#

Quand : avant toute remise en ligne.

Nettoyer sans corriger, c'est repeindre une porte restée ouverte. Les causes les plus fréquentes :

• Extension ou thème obsolète. C'est la cause la plus courante. Une faille publiée est exploitée en quelques heures. Exemple récent : la faille du cœur de WordPress CVE-2026-87902, corrigée en version 7.1.2.
• Extension abandonnée par son auteur : plus aucune correction ne sortira. Remplacez-la.
• Mot de passe faible ou réutilisé sur un autre service qui a fuité.
• Absence de double authentification.
• Version de PHP non maintenue. Elle ne reçoit plus de correctifs de sécurité.
• Droits de fichiers trop permissifs : le serveur peut modifier des fichiers qu'il devrait seulement lire.
• Compromission d'un autre site sur le même hébergement mutualisé.

🔒 Sur un mutualisé, la faille peut ne pas être chez vous#

Un hébergement mutualisé, c'est un serveur partagé entre de nombreux clients. Si l'isolation entre les comptes est insuffisante, un site piraté voisin peut servir de point d'entrée vers le vôtre. Autre cas fréquent : un seul compte d'hébergement contient plusieurs de vos sites, dont un vieux site oublié jamais mis à jour. Tous partagent alors les mêmes droits.

Conséquences pratiques :

• auditez tous les sites du même compte, pas seulement celui qui présente des symptômes ;
• demandez par écrit à votre hébergeur si d'autres comptes du serveur ont été touchés et comment les comptes sont isolés ;
• si la réponse est floue, envisagez un hébergement où votre site est isolé.

Pour le technicien Dans les journaux d'accès, cherchez la première requête qui a créé ou appelé un fichier suspect, à partir de la date de modification relevée à l'étape 5. Croisez avec les versions des extensions installées à cette date et les bulletins de sécurité correspondants.

⚖️ Étape 8 : les obligations légales#

Quand : dès que vous suspectez un accès à des données personnelles. Le délai court.

Cette section donne des repères. Elle ne constitue pas un conseil juridique. Pour votre situation précise, consultez un avocat ou votre délégué à la protection des données.

Êtes-vous concerné ? Oui si votre site stocke des données personnelles : comptes clients, commandes, formulaires de contact, inscriptions à une newsletter. Selon la CNIL, il y a violation dès qu'il y a perte de confidentialité, d'intégrité ou de disponibilité de ces données, qu'elle soit accidentelle ou illicite.

📌 Notifier la CNIL : 72 heures#

Si la violation présente un risque pour les droits et libertés des personnes, la notification doit intervenir dans les meilleurs délais et au plus tard 72 heures après que vous en avez eu connaissance (article 33 du RGPD).

• La notification se fait en ligne, sur le téléservice de la CNIL.
• Vous pouvez notifier en deux temps : une notification initiale dans les 72 heures, puis une notification complémentaire quand l'enquête a avancé.
• Si vous dépassez 72 heures, vous devez expliquer les raisons du retard.

N'attendez pas d'avoir toutes les réponses pour notifier. C'est précisément pour cela que la notification en deux temps existe.

🎯 Informer les personnes concernées#

Obligatoire lorsque la violation crée un risque élevé pour les personnes (article 34 du RGPD) : par exemple, des mots de passe, des coordonnées bancaires ou des données sensibles exposés. La communication doit intervenir au plus tôt et préciser la nature de la violation, ses conséquences probables, les coordonnées d'un contact et les mesures prises. En cas de doute, la CNIL indique qu'il faut la notifier : elle vous dira si l'information des personnes est nécessaire.

📌 Le registre des violations : toujours obligatoire#

Même sans notification, tout organisme doit documenter la violation dans un registre interne. Il contient : la nature de la violation, les catégories et le nombre approximatif de personnes et d'enregistrements concernés, les conséquences probables, les mesures prises, et, le cas échéant, la raison pour laquelle vous n'avez pas notifié. Vos notes horodatées de l'étape 2 en sont la base.

📌 Déposer plainte#

Le piratage d'un site est un délit (articles 323-1 et suivants du Code pénal). Vous pouvez déposer plainte au commissariat, à la gendarmerie, ou par écrit auprès du procureur de la République du tribunal judiciaire, en fournissant les preuves conservées à l'étape 2.

Pourquoi le faire, même sans espoir d'identifier l'auteur :

• votre assureur peut l'exiger pour une prise en charge ;
• cela documente votre bonne foi vis-à-vis de vos clients et de la CNIL ;
• cela alimente les enquêtes sur des campagnes qui touchent d'autres victimes.

📌 Se faire accompagner#

Le dispositif public Cybermalveillance.gouv.fr oriente les victimes, propose des fiches réflexes et référence des prestataires de proximité. Le service 17Cyber permet d'obtenir une assistance en ligne. L'association France Victimes accompagne gratuitement les victimes au 116 006.

📈 Étape 9 : faire lever l'alerte Google#

Quand : une fois le site propre et la faille corrigée. Pas avant.

1. Ouvrez la Search Console, rapport Problèmes de sécurité. Google y classe le problème : contenu piraté, logiciel malveillant ou ingénierie sociale (contenu qui pousse le visiteur à une action dangereuse). Des exemples d'adresses touchées sont souvent listés.
2. Corrigez tout, sur tout le site. Pas seulement les exemples affichés.
3. Cliquez sur Demander un examen. Décrivez précisément le problème, les mesures prises et le résultat obtenu.
4. Attendez. Google indique que le traitement peut prendre plusieurs jours, voire plusieurs semaines. Vous recevez un email à la réception, puis à la fin de l'examen.

Motifs de refus fréquents :

• une partie des pages est encore infectée, souvent celles qui ne s'affichent qu'aux robots de Google ou qu'aux visiteurs venant d'un moteur ;
• la faille n'est pas corrigée et le site est réinfecté pendant l'examen ;
• la description est vague (« le site est nettoyé »).

Ne renvoyez pas de demande avant d'avoir la réponse. Google précise que des demandes répétées sur un problème non résolu ralentissent le traitement suivant, et qu'un site peut être marqué comme récidiviste.

Pendant l'attente : vérifiez chaque jour le rapport, surveillez les journaux, gardez la maintenance si nécessaire, et informez vos clients par un autre canal (email, réseaux sociaux) que le site est en cours de remise en service. Supprimez de l'index les pages de spam créées par l'attaquant : elles doivent renvoyer une erreur 404 ou 410. L'outil Suppressions de la Search Console peut les masquer plus vite, mais Google précise que ce blocage ne dure qu'environ six mois : seule la réponse 404 ou 410 rend la suppression définitive. N'utilisez pas le fichier robots.txt pour cela.

Et le référencement ? Une fois l'alerte levée, le trafic revient en général progressivement. Surveillez dans la Search Console la désindexation des pages de spam et la réindexation de vos pages. Google ne publie aucun délai de retour du trafic : il dépend du nombre de pages de spam à désindexer et de l'ancienneté de l'alerte. Plus l'alerte est levée vite, moins la perte est durable.

📌 Étape 10 : remettre en ligne et surveiller#

Quand : après la correction de la faille. Surveillance renforcée pendant au moins 30 jours.

Avant de rouvrir, vérifiez :

• intégrité du cœur et des extensions confirmée ;
• aucun fichier PHP dans le dossier des médias ;
• aucun compte administrateur inconnu ;
• tous les secrets changés, une seconde fois après le nettoyage (la documentation WordPress le recommande) ;
• WordPress, thème, extensions et PHP à jour ;
• extensions inutilisées supprimées, pas seulement désactivées ;
• sauvegarde propre réalisée et stockée hors du serveur.

Les semaines suivantes, surveillez :

• les nouveaux fichiers et les modifications de fichiers ;
• les connexions à l'administration ;
• le rapport de la Search Console ;
• le volume d'emails sortants ;
• les résultats de site:votredomaine.fr.

Signes d'une réinfection : un fichier supprimé réapparaît, un compte inconnu revient, une redirection réapparaît sur mobile. Dans ce cas, la faille n'est pas corrigée ou une porte dérobée a été oubliée. Retournez à l'étape 5.

📌 Ce qu'il ne faut surtout pas faire#

• Restaurer une sauvegarde sans diagnostic. La faille revient avec elle.
• Se contenter d'une extension de nettoyage. Elle trouve ce qu'elle connaît. Le code brouillé lui échappe souvent, et elle ne corrige pas la faille.
• Supprimer les journaux ou les fichiers suspects. Vous perdez la date d'entrée, la faille et vos preuves.
• Réutiliser un mot de passe, même « modifié d'un chiffre ».
• Payer une rançon. Cybermalveillance.gouv.fr est clair : « Ne payez pas la rançon ». Vous n'êtes certain ni de récupérer vos données, ni qu'elles ne seront pas publiées ou réutilisées.
• Ignorer l'alerte en espérant qu'elle disparaisse. Elle ne disparaîtra pas sans demande d'examen.

📌 Combien de temps et combien ça coûte#

Les délais. Comptez le temps de l'intervention, puis celui de l'examen par Google, qui ne dépend pas de vous.

Les prix. Voici les tarifs affichés publiquement par des prestataires français, relevés le 28 septembre 2026 :

Ces prix concernent surtout un site vitrine avec une infection limitée. Pour une boutique en ligne, une base de données touchée, des réinfections ou des données personnelles exposées, le travail est sur devis et nettement plus long. Méfiez-vous d'une offre qui ne mentionne ni la recherche de la faille d'entrée ni un rapport écrit : c'est un nettoyage de surface.

Ce délai n'inclut pas l'examen par Google.

Réalisable seul : confirmer les symptômes, changer les mots de passe, supprimer les comptes inconnus, contacter l'hébergeur, déposer plainte, tenir le registre, déposer la demande d'examen.

Difficilement réalisable seul : l'analyse des journaux, la recherche exhaustive des portes dérobées, la datation de l'intrusion, l'évaluation de l'exposition des données personnelles. Ce sont précisément les étapes qui conditionnent la réussite du reste.

📌 Éviter la prochaine fois#

Pour sécuriser WordPress durablement, l'ANSSI a publié dix bonnes pratiques pour un CMS. Parmi elles : « Limiter au strict nécessaire l'utilisation d'extensions (plugins) et de thèmes », utiliser des extensions « activement maintenues », « Mettre en place l'authentification multifacteur pour les administrateurs », « Sauvegarder le contenu du site ainsi que la configuration du CMS », « Collecter, analyser et alerter sur les journaux du CMS » et appliquer « le principe du moindre privilège ». Concrètement :

1. Mises à jour du cœur, des thèmes, des extensions et de PHP, dès la publication des correctifs de sécurité.
2. Double authentification pour tous les comptes administrateurs.
3. Sauvegardes testées, conservées hors du serveur, avec plusieurs points de restauration. Une sauvegarde jamais restaurée n'est pas une sauvegarde.
4. Supervision : alertes sur les fichiers modifiés et scan régulier.
5. Limitation des accès : un compte par personne, droits minimaux, suppression des comptes des anciens prestataires.
6. Choix de l'hébergement : isolation entre les sites, version de PHP maintenue, journaux conservés et accessibles.

Vous pouvez assurer tout cela en interne si vous en avez le temps. Vous pouvez aussi le confier à un prestataire : c'est le principe de l'hébergement infogéré. Chez Websource, cela recouvre l'application régulière des correctifs de sécurité du système et des services (Apache, PHP, MySQL/MariaDB), la supervision des ressources et des sauvegardes, et le diagnostic en cas de faille détectée. C'est une option parmi d'autres ; l'essentiel est que quelqu'un soit clairement responsable de chacun de ces six points.

📌 Checklist complète du protocole#

Étape 1 : confirmer

• ☐ Symptômes relevés et capturés, avec l'heure
• ☐ Panne, certificat expiré ou arnaque par email écartés

Étape 2 : préserver les preuves

• ☐ Copie complète des fichiers
• ☐ Export de la base de données
• ☐ Journaux du serveur récupérés
• ☐ Copie stockée hors du serveur, empreintes calculées

Étape 3 : limiter la casse

• ☐ Site en maintenance (code 503) ou hors ligne
• ☐ Accès inutiles désactivés
• ☐ Envoi d'emails depuis le site suspendu

Étape 4 : reprendre les accès

• ☐ Poste de travail analysé
• ☐ Hébergeur, registraire, email changés
• ☐ Comptes WordPress, base, FTP/SFTP, clés d'API changés
• ☐ Clés de sécurité WordPress régénérées
• ☐ Comptes administrateurs inconnus documentés et supprimés

Étape 5 : mesurer l'étendue

• ☐ Intégrité du cœur et des extensions vérifiée
• ☐ Médias, fichiers récents, tâches planifiées, base, .htaccess contrôlés
• ☐ Fichiers suspects en quarantaine hors zone publique

Étape 6 : nettoyer ou reconstruire

• ☐ Décision prise et justifiée
• ☐ Cœur, thèmes, extensions remplacés par des versions officielles

Étape 7 : corriger la faille

• ☐ Porte d'entrée identifiée
• ☐ Correctif appliqué, autres sites du compte audités

Étape 8 : obligations légales

• ☐ Exposition des données personnelles évaluée
• ☐ CNIL notifiée sous 72 heures si nécessaire
• ☐ Personnes informées si risque élevé
• ☐ Registre des violations complété
• ☐ Plainte déposée

Étape 9 : alerte Google

• ☐ Rapport Problèmes de sécurité consulté
• ☐ Demande d'examen détaillée envoyée
• ☐ Pages de spam en 404 ou 410

Étape 10 : remise en ligne

• ☐ Vérifications avant réouverture faites
• ☐ Secrets changés une seconde fois
• ☐ Surveillance renforcée de 30 jours en place

📌 FAQ#

Comment savoir si mon site WordPress est piraté ? Recherchez des pages inconnues avec site:votredomaine.fr dans Google, testez le site depuis un mobile en venant d'une recherche Google, et consultez le rapport Problèmes de sécurité de la Search Console. Un compte administrateur inconnu, des emails envoyés en masse ou un avertissement rouge du navigateur sont des signes forts.

Faut-il restaurer une sauvegarde après un piratage ? Oui, mais seulement une sauvegarde antérieure à l'intrusion, et seulement après avoir identifié et corrigé la faille. Sinon, le site restauré contient la même faille et sera réinfecté, souvent en quelques jours. Conservez d'abord une copie du site compromis.

Combien de temps pour faire lever l'alerte Google ? Selon Google, l'examen d'une demande prend de plusieurs jours à plusieurs semaines. Le délai dépend surtout de la qualité du nettoyage : une demande envoyée alors que des pages sont encore infectées est refusée et ralentit la suivante.

Dois-je prévenir mes clients ? Si des données personnelles ont pu être consultées, vous devez notifier la CNIL sous 72 heures lorsque la violation présente un risque. Vous devez informer directement les personnes lorsque le risque est élevé, par exemple si des mots de passe ou des données bancaires sont exposés. Dans tous les cas, la violation doit être inscrite au registre interne.

Une extension de sécurité suffit-elle à nettoyer un site WordPress ? Non. Une extension détecte ce qu'elle connaît, et le code malveillant brouillé lui échappe souvent. Elle ne corrige pas la faille d'entrée. Elle est utile pour repérer et surveiller, pas pour garantir un nettoyage complet.

Mon hébergeur est-il responsable du piratage ? Cela dépend de la faille et de votre contrat. Si l'intrusion vient d'une extension non mise à jour, la responsabilité relève en général de celui qui gère le site. Sur un hébergement mutualisé mal isolé, la faille peut venir d'un autre compte : demandez par écrit à votre hébergeur ce qu'il a constaté.

✅ Conclusion#

Un site WordPress piraté se répare. Ce qui fait la différence, c'est l'ordre : preuves d'abord, accès ensuite, nettoyage après, faille corrigée avant la remise en ligne. Suivez les étapes, cochez la checklist, et ne restez pas seul si l'une d'elles vous dépasse.

Si vous êtes en pleine urgence et que vous avez besoin d'un avis ou d'une intervention, contactez-nous. Nous vous dirons d'abord ce que vous pouvez faire vous-même.

📚 Sources#

Toutes les sources ont été consultées le 28 septembre 2026.

• CNIL – Violations de données personnelles : les règles à suivre
• CNIL – Notifier une violation de données personnelles
• CNIL – Téléservice de notification
• Cybermalveillance.gouv.fr – Piratage d'un système informatique professionnel, que faire ?
• Cybermalveillance.gouv.fr – Défiguration de site Internet, que faire ?
• 17Cyber
• WordPress.org – FAQ My site was hacked
• WordPress Developer – Hardening WordPress
• WordPress.org – Générateur de clés de sécurité
• Aide Search Console – Rapport sur les problèmes de sécurité
• Aide Search Console – Pourquoi mon site apparaît-il comme dangereux ?
• web.dev (Google) – Help, I think I've been hacked
• Google Transparency Report – État d'un site (navigation sécurisée)
• ANSSI – Mise en œuvre sécurisée d'un CMS (Les Essentiels, 15/12/2023)
• Websource – Étude de cas : sécurité de l'hébergement
• ANSSI – Les Essentiels : Mise en œuvre sécurisée d'un CMS, V1.1 (PDF)
• Cybermalveillance.gouv.fr – Rançongiciels (ransomwares) : que faire ?
• Aide Search Console – Outil de suppression d'URL
• Aide Recherche Google – « Ce site peut être piraté »
• Websource – Comment détecter un webshell sur mon site (18/09/2026)
• Websource – WordPress : la faille CVE-2026-87902 (23/09/2026)
• Websource – Infogérance de serveurs
• Echappée Web – Réparation de site WordPress piraté (tarif)
• CODE 200 – Nettoyage de site WordPress piraté (tarif)
• Maintenance CMS WP – Site WordPress piraté (tarif)
• 2Cafés – Nettoyage site WordPress piraté
• Help Net Security – WordPress 7.1.2 fixes CVE-2026-87902