# Site WordPress piraté : le retour de vacances qui tourne au cauchemar (et comment nettoyer + sécuriser son site)

- Link: https://helenesiroux.com/2026/09/10/site-wordpress-pirate-comment-nettoyer/
- Published: 2026-09-10T18:30:56+02:00
- Author: Hélène Siroux

Retour de vacances. Le soleil, la déconnexion, les mails qui s’accumulent tranquillement
pendant deux semaines… et puis ce message d’une cliente, un peu paniqué : « Mon 
site ne s’affiche plus, il n’y a qu’une page blanche ! Je peux pas non plus me connecter
à l’admin. »

C’est exactement la situation que j’ai eue à traiter récemment : un site WordPress
piraté. Comme ce cas résume assez bien les pièges classiques (et les bons réflexes)
autour de la sécurité WordPress, je me suis dit que ça valait la peine d’en faire
un article. Je vous explique comment on diagnostique ce genre de panne, et surtout,
je vous donne des pistes concrètes afin de ne jamais s’y retrouver soi-même.

## Le symptôme : une page blanche, et rien d’autre

Le site en question affichait une page totalement vide. Pas de message d’erreur,
pas de logo, rien. En faisant un clic droit puis « Afficher le code source » (Ctrl
+U), même topo : une poignée de lignes vides, aucune trace de code HTML.

Dans l’immense majorité des cas, deux éléments peuvent être en cause :

 1. Une erreur PHP fatale (un plugin ou un thème incompatible, une mise à jour qui 
    s’est mal passée, un dépassement de mémoire) ;
 2. Un fichier corrompu ou modifié — volontairement ou non.

Sans accès aux outils techniques (hébergeur, FTP), impossible de trancher entre 
les deux à l’œil nu. C’est là que commence le vrai travail de diagnostic.

## Étape 1 : activer le mode debug

Le premier réflexe face à un écran blanc WordPress, c’est d’aller chercher l’information
à la source : les logs. Deux options complémentaires :

 * **Le mode debug de WordPress**, activable directement dans le fichier `wp-config.
   php` en ajoutant quelques lignes de configuration. Il permet, une fois activé,
   de consulter un fichier `debug.log` qui note noir sur blanc chaque erreur PHP
   rencontrée par le site.
 * **Le journal d’erreurs de l’hébergeur**, indépendant de WordPress. Chez la plupart
   des hébergeurs, on trouve une interface dédiée dans l’espace client, ou un dossier
   de logs bruts accessible en FTP. L’avantage : ce journal capture les erreurs 
   même quand WordPress plante _avant_ d’avoir eu le temps de lire sa propre configuration.

Sur ce dossier client, fait notable : même en activant le debug, **rien ne s’affichait**.
Signal qui, avec l’expérience, met la puce à l’oreille — quand absolument rien ne
remonte, même pas un message d’erreur basique, il y a de fortes chances que le problème
ne soit pas « juste » un bug de plugin.

## Étape 2 : remonter la piste jusqu’au fichier suspect

En creusant dans les logs serveur, aucune trace d’erreur PHP classique pour ce site.
Ce qui, combiné à la page totalement vide, pointait vers une hypothèse plus préoccupante:
et si le fichier `index.php` lui-même, celui qui sert de porte d’entrée à tout site
WordPress, n’était plus le fichier d’origine ?

Vérification faite : bingo. Le contenu du fichier n’avait plus rien à voir avec 
un `index.php` WordPress standard. À la place, du code fortement obfusqué (des variables
au nom étrange, des fragments de texte encodés, une syntaxe volontairement difficile
à lire). Autrement dit : **du code malveillant avait été injecté directement dans
un fichier cœur du site.**

Ce n’était donc pas un bug. C’était un piratage. Et un piratage qui a touché plusieurs
fichiers du coeur de WordPress.

## Piratage WordPress : comprendre pourquoi (sans se tromper de coupable)

Face à ce genre de découverte, la première réaction est souvent de chercher un responsable
immédiat. Dans ce dossier, le webmaster en charge du site a d’ailleurs expliqué 
à la cliente que le piratage était dû à l’absence de mises à jour depuis plusieurs
semaines. Une explication simple, mais un peu trop expéditive. Un site qui n’a pas
été mis à jour depuis quelques semaines n’est pas condamné pour autant. Ce qui compte,
c’est quelle mise à jour manquait, et si elle corrigeait une faille de sécurité 
connue.

Dans ce dossier, deux autres pistes méritaient d’être creusées en parallèle :

 * **Un dossier `.git` exposé publiquement** sur le serveur. Quand un site est déployé
   via Git sans exclure ce dossier de la partie visible en ligne, il peut potentiellement
   révéler des informations sensibles à qui sait où chercher. Heureusement bloqué
   par la configuration serveur ici, mais un signe qu’il faut vérifier systématiquement.
 * **Un hébergement mutualisé partagé avec un autre site.** Sur certaines offres,
   plusieurs sites d’un même compte client se partagent une partie des ressources
   serveur. Si l’un des sites du compte est mal sécurisé ou subit une attaque, l’autre
   peut, dans certains cas, être exposé par ricochet.

La leçon à retenir : un piratage a rarement une seule cause simple. C’est souvent
une combinaison de petites négligences qui, ensemble, ouvrent une brèche.

## Comment nettoyer un site WordPress piraté sans sauvegarde saine

Autre point essentiel révélé par ce cas : les sauvegardes automatiques de l’hébergeur
ne remontaient qu’à 7 jours, et il n’existait aucune sauvegarde externe (via un 
plugin dédié couplé à un stockage cloud, par exemple). Résultat : impossible de 
simplement « revenir en arrière » à une version saine antérieure à l’infection, 
puisque l’infection était antérieure à 7 jours.

Dans ce cas de figure, la remise en état passe obligatoirement par un nettoyage 
manuel complet :

 * Remplacement intégral des fichiers cœur de WordPress par des fichiers d’origine
   téléchargés depuis la source officielle ;
 * Remplacement du thème et de tous les plugins par des versions saines ;
 * Recherche de fichiers PHP suspects dans les dossiers qui ne devraient jamais 
   en contenir (comme le dossier des médias) ;
 * Vérification de la base de données à la recherche de comptes administrateurs 
   inconnus ou de code injecté dans le contenu ;
 * Changement de tous les mots de passe et régénération des clés de sécurité une
   fois le ménage terminé.

C’est un travail long, minutieux, et qui laisse peu de place à l’approximation :
oublier une seule porte dérobée cachée, et le site est réinfecté en quelques jours.

Un nettoyage et une sécurisation du site à la fois longs et coûteux qui auraient
pu être évités si le site avait été [sécurisé dès sa création](https://helenesiroux.com/creation-web/).

## Sécurité WordPress : ce qu’il faut retenir pour éviter d’en arriver là

Ce cas illustre bien pourquoi la sécurité d’un site WordPress ne se résume pas à«
cliquer sur mettre à jour » une fois de temps en temps. La sécurité site WordPress
se construit en amont, pas dans l’urgence. Voici les réflexes que je recommande 
à tous mes clients :

**1. Des sauvegardes automatiques ET externalisées.** Ne comptez jamais uniquement
sur les sauvegardes de votre hébergeur, aussi bonnes soient-elles. Un plugin de 
sauvegarde qui envoie une copie régulière vers un espace de stockage externe (Google
Drive, par exemple) est la meilleure assurance contre un piratage : en cas de souci,
on restaure une version saine en quelques minutes au lieu de nettoyer pendant des
heures.

**2. Des mises à jour régulières, cœur, thème et plugins.** Pas besoin de le faire
tous les jours, mais un suivi mensuel minimum, avec une attention particulière aux
mises à jour de sécurité signalées comme critiques.

**3. Des plugins de sécurité actifs.** Des solutions comme Wordfence permettent 
de surveiller les fichiers du site, de détecter les modifications suspectes et de
bloquer une partie des tentatives d’intrusion avant même qu’elles n’aboutissent.
Deux réglages complémentaires à ne pas négliger : **changer l’URL de connexion par
défaut** (`/wp-admin` ou `/wp-login.php` étant les premières cibles de tout bot 
d’attaque automatisé) pour la remplacer par une adresse personnalisée, et **configurer
les en-têtes de sécurité HTTP** (Content-Security-Policy, X-Frame-Options, X-Content-
Type-Options…) qui compliquent l’exploitation de certaines failles côté navigateur.

**4. Une vérification de ce qui est exposé publiquement.** Dossiers techniques (`.
git`, fichiers de configuration, journaux) ne devraient jamais être accessibles 
depuis un navigateur.

**5. Une vigilance sur les sites voisins en cas d’hébergement mutualisé.** Si plusieurs
sites partagent un même compte d’hébergement, la sécurité de l’un dépend en partie
de celle des autres.

## Besoin d’y voir clair sur la sécurité de votre site ?

Un site WordPress qui tourne sans accroc, ce n’est pas un coup de chance : c’est
le résultat d’une maintenance régulière et d’une vigilance de tous les instants.
Si vous n’avez pas la certitude que votre site est correctement sauvegardé, à jour
et protégé contre ce genre de scénario, mieux vaut vérifier maintenant plutôt qu’après
un retour de vacances stressant.

Je propose un [accompagnement de maintenance et de sécurisation pour les sites WordPress (et PrestaShop)](https://helenesiroux.com/maintenance-web/)
des indépendants et petites entreprises : mise en place de sauvegardes externalisées,
suivi des mises à jour, installation et configuration d’un plugin de sécurité, et
intervention rapide en cas de problème.

**[Contactez-moi](https://helenesiroux.com/contact/) pour faire un point sur la 
sécurité de votre site — mieux vaut prévenir qu’avoir à nettoyer un site piraté 
sans sauvegarde saine.**