Urgence WordPress piraté : comment gérer les sauvegardes avant et après l’attaque

Un site WordPress piraté est rarement un simple incident technique. C’est du stress, parfois une chute brutale de chiffre d’affaires, une perte de confiance des clients, et souvent la sensation désagréable de ne plus contrôler son propre outil. Dans cette urgence WordPress piraté, un élément fait la différence entre une crise gérable en quelques heures et une catastrophe qui s’étale sur des semaines : la qualité et la gestion de vos sauvegardes, avant et après l’attaque.

Je vois souvent deux profils de propriétaires de sites. Ceux qui découvrent l’existence des sauvegardes le jour du piratage, et ceux qui en ont, mais tellement anciennes, incomplètes ou corrompues qu’elles sont presque inutiles. L’objectif ici est clair : comprendre comment préparer des sauvegardes solides avant un incident, comment les utiliser correctement pendant la crise, et ce qu’il faut mettre en place une fois le site remis en état pour ne plus revivre la même galère.

Comprendre l’enjeu des sauvegardes dans un piratage

Lorsqu’un site WordPress est compromis, les dégâts sont rarement limités à un seul fichier. Un attaquant peut :

modifier des fichiers du cœur de WordPress, injecter du code malveillant dans des thèmes et extensions, ajouter des comptes administrateurs cachés, altérer la base de données (contenu, options, redirections, liens cachés), toucher à des fichiers de configuration ou au .htaccess.

Sans sauvegarde fiable, vous êtes obligé de nettoyer “à la main” chaque couche, souvent sans certitude d’avoir tout trouvé. C’est faisable, mais long, risqué, et rarement rentable sur un petit ou moyen site.

Avec des sauvegardes bien pensées, vous disposez d’un filet de sécurité. Vous pouvez comparer l’état avant et après l’attaque, restaurer rapidement, puis analyser les différences pour comprendre par https://gardewp.fr/site-wordpress-pirate/ où l’intrusion est passée. En revanche, une mauvaise sauvegarde peut ralentir l’intervention ou réintroduire le code malveillant si elle a été créée après la compromission.

La vraie question n’est pas “avez-vous une sauvegarde”, mais “quelle est sa qualité, sa fraîcheur et son isolation par rapport au site piraté”.

Avant l’attaque : construire une stratégie de sauvegarde réaliste

Un plan de sauvegarde n’a de valeur que s’il reflète votre réalité : fréquence des mises à jour de contenu, trafic, chiffre d’affaires généré, contraintes techniques de votre hébergement. Copier un “plan type” trouvé sur un forum sans l’adapter conduit souvent à de mauvaises surprises.

Que faut-il sauvegarder exactement ?

Beaucoup d’utilisateurs pensent que “sauvegarder WordPress” consiste à copier la base de données. C’est incomplet. À l’inverse, certains dupliquent tout l’espace d’hébergement sans discernement, ce qui prend de la place et rend les restaurations moins précises.

Pour un WordPress classique, trois blocs sont vraiment critiques :

La base de données (tables wp_ ou préfixe personnalisé)

Elle contient les articles, pages, utilisateurs, réglages, menus, widgets, parfois des logs d’extension, des formulaires, des transients. En général, perdre la base, c’est perdre le site, même si les fichiers sont intacts.

Le dossier wp-content

C’est là que vivent vos thèmes, extensions, fichiers téléversés (images, PDF, vidéos, etc). Sans ce dossier, vous aurez encore votre contenu texte, mais plus le design, ni les médias, ni certaines fonctionnalités.

Les fichiers de configuration essentiels

Notamment wp-config.php (accès à la base, clés de sécurité, certains réglages) et parfois .htaccess ou des fichiers Nginx si vous avez une configuration personnalisée.

Les fichiers du cœur de WordPress, en revanche, sont moins critiques, car ils peuvent être retéléchargés depuis wordpress.org. Les inclure dans les sauvegardes ne fait pas de mal, mais ce n’est pas ce qui doit être prioritaire.

Fréquence et rotation : trouver le bon équilibre

Une boutique en ligne avec 50 commandes par jour n’a pas les mêmes besoins qu’un site vitrine mis à jour une fois par trimestre. Pourtant, je rencontre souvent des boutiques qui sauvegardent une fois par semaine et des petits blogs qui sauvegardent toutes les heures par défaut, simplement parce qu’un plugin l’a proposé.

Quelques repères pratiques :

Site vitrine peu modifié : une sauvegarde hebdomadaire, complétée par une sauvegarde manuelle avant chaque grosse modification (changement de thème, ajout d’extension, mise à jour majeure), est souvent suffisante. Blog ou média mis à jour régulièrement : sauvegarde quotidienne de la base de données, et hebdomadaire des fichiers wp-content. Boutique WooCommerce ou site transactionnel : base de données sauvegardée plusieurs fois par jour, voire toutes les heures, selon le volume de commandes et la criticité, et sauvegarde des fichiers au moins une fois par jour.

La rotation, c’est à dire le nombre de versions conservées, compte autant que la fréquence. Sur un site sujet à des piratages silencieux, il n’est pas rare de découvrir l’attaque plusieurs semaines après le début des injections. Si vous ne gardez que 7 jours d’historique, toutes vos sauvegardes risquent d’être contaminées.

Tant que votre volume disque le permet, viser entre 15 et 30 jours de rétention sur des sauvegardes quotidiennes offre généralement une marge raisonnable pour réagir.

Où stocker les sauvegardes pour ne pas les perdre avec le site

Le pire scénario est de découvrir que les sauvegardes ont été stockées dans le même répertoire que le site piraté, voire sous un répertoire accessible en HTTP, ce qui laisse à l’attaquant la possibilité de :

les supprimer, les télécharger, ou les utiliser comme point d’entrée.

La règle est simple : une sauvegarde utile est une sauvegarde qui vit ailleurs. Idéalement, vous combinez plusieurs emplacements :

une sauvegarde automatique sur un stockage externe (S3, Backblaze B2, Google Cloud Storage, etc), une sauvegarde sur un espace distinct chez le même hébergeur, non accessible en HTTP, et pour les sites critiques, une copie régulière sur un support totalement déconnecté (chiffre d’affaires très dépendant du site, contraintes légales, etc).

De nombreux hébergeurs intègrent leurs propres sauvegardes quotidiennes. C’est une bonne base, mais il est dangereux de s’y reposer entièrement. En cas de problème généralisé côté hébergeur, ou de piratage à l’échelle d’un compte, ces sauvegardes peuvent être affectées ou inaccessibles.

Jour de crise : que faire de vos sauvegardes quand le site est piraté

Le moment où vous réalisez “mon site a été piraté” n’est pas idéal pour improviser une méthode. Le cœur du problème, et ce que je vois le plus dans les interventions d’urgence WordPress piraté, c’est l’empressement à tout restaurer immédiatement, sans réflexion.

Première étape : geler la situation

Avant de toucher aux sauvegardes, il faut cesser d’ajouter du bruit dans le système. Cela consiste généralement à :

Bloquer temporairement l’accès au site aux visiteurs, par exemple avec une maintenance au niveau du serveur, un firewall applicatif, ou un simple index de maintenance statique. L’idée n’est pas de cacher le problème, mais d’éviter que des visiteurs soient infectés ou redirigés vers du phishing. Changer immédiatement les mots de passe les plus sensibles : accès au compte d’hébergement, FTP/SFTP/SSH, panel de gestion de la base de données, comptes administrateurs WordPress. Si l’attaquant a un accès direct au panel, il pourra neutraliser vos tentatives de restauration. Si possible, prendre une “photo” actuelle du site piraté, avant nettoyage. Cette étape est très négligée. Pourtant, disposer d’un dump de base de données et d’une copie des fichiers infectés permet ensuite d’identifier le vecteur d’attaque et de comprendre depuis quand le site est compromis.

Cette dernière étape se heurte souvent à une crainte : “si je sauvegarde maintenant, je sauvegarde le piratage”. C’est vrai, mais cette copie ne sera pas utilisée pour restaurer le site. Elle sert uniquement à l’analyse, à froid, après la remise en service.

Deuxième étape : choisir le bon point de restauration

Parmi toutes vos sauvegardes disponibles, toutes ne sont pas utilisables. Vous cherchez un instant suffisamment récent pour éviter de perdre trop de données, mais suffisamment ancien pour être avant l’intrusion.

Des indices permettent de vous adapter :

date des premiers symptômes détectés (redirections, alertes de sécurité, mails d’antivirus, baisse anormale de trafic), logs serveur (si disponibles) pour repérer des requêtes suspectes, des téléversements de fichiers, des accès à wp-admin ou xmlrpc.php depuis des IP inhabituelles, fichiers modifiés récemment, repérés via le FTP ou un outil de diff.

Sur des sites bien suivis, l’incident est souvent situé dans une fenêtre de 24 à 72 heures. Sur des sites peu surveillés, j’ai déjà trouvé des infections actives depuis plus de six mois, avec des sauvegardes toutes contaminées. Dans ce cas, vos sauvegardes ne résolvent pas tout et il faudra combiner restauration et nettoyage manuel.

Restaurer un site WordPress piraté sans tout casser

Mettre en production une restauration mal préparée peut faire plus de dégâts que l’attaque initiale : perte de commandes en cours, de comptes client créés entre temps, d’articles rédigés, etc. Pourtant, dans une situation d’urgence WordPress piraté, l’impatience conduit souvent à cliquer sur “Restaurer” sans vérifier les conséquences.

L’idéal : restaurer d’abord sur un environnement de test

Dès que possible, créez un clone du site à partir de la sauvegarde que vous comptez utiliser, sur un sous-domaine ou un environnement de staging. Cela permet de :

scanner la sauvegarde avec plusieurs outils de sécurité WordPress, vérifier manuellement certains fichiers critiques (wp-config.php, fonctions du thème, extensions peu connues), comparer la base de données à celle du site piraté pour repérer les différences suspectes (comptes utilisateurs, URLs ajoutées, options).

De nombreux hébergeurs modernes facilitent la création d’un staging. Sinon, un simple clonage dans un sous-dossier avec une nouvelle base de données fait l’affaire, à condition d’adapter l’URL dans la base pour que le staging n’interfère pas avec la production.

Ce détour ajoute parfois quelques heures de travail, mais il évite de remettre en ligne une sauvegarde déjà infectée, ce qui est trop souvent le cas avec des malwares discrets.

La restauration partielle : utile, mais délicate

Parfois, restaurer “tout le site” n’est pas souhaitable. Par exemple, une boutique reçoit des commandes pendant plusieurs jours après la date à laquelle la sauvegarde ciblée a été créée. Rétablir l’intégralité de la base reviendrait à supprimer ces commandes.

Une méthode fréquente consiste alors à restaurer uniquement :

les fichiers wp-content (ou certains sous-dossiers) depuis la sauvegarde, mais à garder la base actuelle, en la nettoyant manuellement.

Cette approche fonctionne, à condition de bien comprendre les dépendances :

certaines extensions stockent des règles ou des scripts dans la base de données, pas dans les fichiers, les comptes administrateurs frauduleux ajoutés par l’attaquant se trouvent dans la base, certaines infections insèrent des iframes ou des liens dans les contenus d’articles.

À l’inverse, il est parfois plus judicieux de restaurer la base de données depuis la sauvegarde, mais de régénérer les fichiers du cœur WordPress et des extensions manuellement, depuis des sources propres.

L’outil le plus sous-estimé ici reste le diff. Comparer l’arborescence et le contenu de deux versions d’un même site, même de façon rudimentaire, permet de repérer ce que l’attaquant a réellement touché, et de restaurer de manière plus ciblée.

Étapes pratiques de restauration avec un minimum de risques

Voici une séquence éprouvée pour limiter les mauvaises surprises lors d’une restauration complète depuis une sauvegarde, tout en restant pragmatique :

Geler le site en production (maintenance côté serveur, pas simplement un plugin). Sauvegarder l’état actuel du site, même infecté, fichiers et base. Vérifier l’intégrité de la sauvegarde choisie (taille cohérente, base exportable, fichiers lisibles). Si possible, la tester sur un staging, analyser les traces de malware, mettre à jour les mots de passe et supprimer les comptes douteux. Une fois confiant sur la propreté : restaurer en production, forcer immédiatement une mise à jour vers la dernière version sécurisée de WordPress, des thèmes et des extensions, puis changer à nouveau les mots de passe critiques.

Cette approche limite les chances de réinfection par une ancienne faille tout en permettant de revenir à un état propre rapidement.

Après le piratage : renforcer la stratégie de sauvegardes

Une fois le site revenu en ligne, tout le monde veut tourner la page. Pourtant, c’est le meilleur moment pour corriger ce qui n’allait pas dans votre dispositif de sauvegarde, tant que les événements sont frais dans votre mémoire.

Tirer les leçons de l’incident

Commencez par vous poser quelques questions très simples, mais rarement documentées :

combien de temps a-t-il fallu pour récupérer un site fonctionnel à partir des sauvegardes ? des données ont-elles été perdues, et à quelle échelle (commentaires, commandes, articles) ? avez-vous passé plus de temps à chercher la bonne sauvegarde qu’à l’exploiter ? quelqu’un d’autre que vous saurait-il reproduire la procédure en votre absence ?

Si vos réponses montrent des zones floues, il faut ajuster. Sur beaucoup de sites, ce travail de retour d’expérience révèle que le problème n’était pas strictement technique, mais organisationnel : procédures non écrites, dépendance à une seule personne, méconnaissance des sauvegardes fournies par l’hébergeur.

Automatiser tout ce qui peut l’être, sans perdre le contrôle

Les plugins de sauvegarde WordPress offrent parfois tellement d’options qu’on coche des cases au hasard. L’objectif n’est pas l’automatisation à tout prix, mais une automatisation compréhensible.

Une configuration saine ressemble souvent à ceci :

une sauvegarde complète hebdomadaire (base + wp-content), envoyée vers un stockage externe, des sauvegardes incrémentales ou différentielles quotidiennes, centrées sur la base, une notification par mail en cas d’échec de sauvegarde, des tests de restauration réguliers, au moins tous les quelques mois, sur un environnement séparé.

Beaucoup de sites disposent de “sauvegardes automatiques” qui n’ont jamais été testées. Le jour du piratage, on découvre des archives corrompues, ou des processus bloqués depuis des semaines. Tester la restauration sur un petit site de test vaut infiniment mieux que découvrir ces problèmes en pleine crise.

Penser sauvegardes et sécurité ensemble

Une stratégie de sauvegarde efficace ne remplace pas la sécurité de base, mais les deux se renforcent. Certaines bonnes pratiques améliorent simultanément les deux aspects :

mettre à jour régulièrement WordPress, les extensions et les thèmes limite les failles, mais réduit aussi les incompatibilités quand on restaure sur une version récente, limiter le nombre de comptes administrateurs, et leur attribuer des mots de passe robustes, simplifie le contrôle après restauration, séparer les environnements (production, préproduction, test) évite d’écraser un site par erreur en manipulant les sauvegardes, désactiver et supprimer les extensions inutilisées réduit la surface d’attaque et les données à sauvegarder.

Après un incident, il est souvent utile de revoir l’inventaire des extensions et thèmes. Certains sont abandonnés par leurs développeurs, plus mis à jour, parfois retirés du répertoire officiel. Continuer à les garder en production, même après un nettoyage complet, prépare le terrain pour la prochaine compromission.

Cas particuliers et pièges fréquents autour des sauvegardes

Les situations réelles débordent souvent des schémas simples. Voici quelques cas concrets qui reviennent régulièrement lors d’interventions d’urgence WordPress piraté.

Sauvegardes faites par le développeur… introuvables après

Un scénario fréquent : un prestataire a monté le site, mis en place ses propres scripts de sauvegarde, puis a disparu. Le propriétaire du site n’a aucune idée d’où partent ni où atterrissent ces backups. Le jour du piratage, tout le monde remonte les mails, sans trouver de trace exploitable.

Pour éviter cela, imposez une règle claire : la documentation de la stratégie de sauvegarde doit figurer dans un document partagé, accessible au propriétaire du site, et idéalement décrit dans le contrat. On y note l’emplacement, la fréquence, la méthode d’accès, et le nom des personnes habilitées à intervenire. Sans ce minimum, la technique la plus sophistiquée perd tout son sens.

Sauvegardes locales sur un ordinateur personnel

Certains gèrent les sauvegardes à l’ancienne, en téléchargeant régulièrement des archives sur leur ordinateur. L’intention est bonne, mais plusieurs problèmes se posent :

risque de perte du PC (vol, panne, disque dur défectueux), absence de chiffrement des sauvegardes contenant des données sensibles, absence de rotation : on écrase les anciennes sauvegardes, ou on en crée tellement qu’on ne sait plus laquelle est utilisable.

Si vous optez pour cette voie, combinez-la impérativement avec au moins un stockage distant. Et n’oubliez pas que si votre machine est compromise, les backups peuvent l’être aussi.

Sauvegardes après infection silencieuse

Certaines infections se contentent d’ajouter du spam SEO ou des backdoors très discrètes dans des fichiers rarement ouvert à l’œil nu. Dès lors, pendant des semaines, tous les backups enregistrent des fichiers “légèrement modifiés”, sans que personne n’y prête attention.

Dans ces cas, même avec 30 jours de rétention, il est possible que toutes les sauvegardes contiennent déjà le code malveillant. La seule solution est alors de :

réinstaller entièrement WordPress depuis la source officielle, réinstaller toutes les extensions et thèmes depuis leurs sources officielles, importer uniquement le nécessaire depuis la base : contenu, utilisateurs légitimes, commandes, réglages essentiels, et contrôler rigoureusement chaque import.

C’est long, mais pour un site qui a une vraie valeur commerciale ou d’image, c’est parfois la seule manière de repartir sur des fondations saines.

Transformer une urgence en avantage pour la suite

Un piratage WordPress met sous pression, mais force aussi à regarder en face des zones que l’on repousse souvent au lendemain : qualité des sauvegardes, documentation des procédures, dépendance à certains prestataires, manque de test des restaurations.

Une bonne stratégie de sauvegarde n’empêche pas l’attaque, mais elle change radicalement la nature de la crise. Au lieu de se demander s’il est encore possible de sauver des mois de travail, vous passez sur des questions plus maîtrisables : quelle est la dernière version saine, comment limiter la perte de données, et comment sécuriser davantage la mise en production.

Si votre site n’est pas encore passé par cette phase désagréable, le meilleur moment pour revoir vos sauvegardes est maintenant, tant que vous avez le temps de tester calmement. Si vous êtes déjà en plein incident, traitez vos sauvegardes avec autant de soin que le nettoyage lui-même. Elles sont souvent la seule raison pour laquelle un piratage ne tourne pas à la catastrophe durable.