Site WordPress piraté : que faire, étape par étape

Un avertissement rouge dans Chrome, une redirection vers un domaine inconnu et une interface d’administration où tout paraît normal. La marche à suivre en urgence sur WordPress : ce qu’il ne faut pas faire la première heure, où l’infection se cache vraiment et comment se débarrasser de l’avertissement Google.

Jeudi matin, un client vous appelle : à la place de votre boutique, Chrome lui affiche un avertissement rouge en plein écran. Vous ouvrez le site sur votre téléphone et, une seconde et demie plus tard, le navigateur vous éjecte vers un domaine inconnu, alors que sur l’ordinateur du bureau, où l’administration est ouverte depuis lundi, tout paraît normal. C’est à cela que ressemble le plus souvent un site WordPress piraté : non pas une page d’accueil défigurée et signée par son attaquant, mais un site qui montre un visage à son propriétaire et un autre à ses visiteurs — d’où ces premières heures passées à débattre de l’existence même du problème.

Les questions auxquelles ce guide répond arrivent presque toujours dans cet ordre : ce qu’il est permis et interdit de faire pendant la première heure, tant que personne ne sait jusqu’où l’attaquant est descendu ; où le code se cache réellement dans une installation WordPress, faute de quoi le nettoyage relève de la devinette ; et comment obtenir de Google la levée de l’avertissement sans ruiner votre deuxième tentative. Entre les deux se glisse l’étape que les propriétaires sautent le plus souvent — le renouvellement des identifiants, au bon moment et dans le bon ordre.

Tout ce qui doit être fait dans les heures qui viennent est ici, et vous n’aurez pas à chercher ailleurs en cours de route. Nous avons laissé de côté ce qui ne sert qu’une fois le site remis en ligne — stratégie de sauvegarde, durcissement, protection contre la fois suivante, identiques quelle que soit la plateforme — et nous renvoyons plus bas vers un guide distinct sur ces sujets. Le propos ici, c’est ce qui rend WordPress différent : son écosystème d’extensions, le dossier wp-content, les tables de la base de données où une infection survit à un nettoyage de fichiers, et les commandes qui promettent davantage qu’elles ne vérifient. Dans notre pratique, ce sont ces quatre points qui décident si un site est propre au bout d’une journée ou à la troisième tentative.

La première heure : ne supprimez rien

Le premier réflexe est presque toujours l’un des deux suivants : ouvrir le gestionnaire de fichiers de l’hébergeur, y repérer quelque chose d’étranger et le supprimer, ou appuyer sur le bouton qui restaure la sauvegarde de la veille. Nous vous demandons de ne faire ni l’un ni l’autre, et la raison est pratique, pas bureaucratique. La précipitation se comprend, puisque chaque heure passée sous un avertissement rouge vous coûte des visiteurs, mais c’est précisément dans la précipitation que se prennent les deux décisions qui font passer une remise en état de huit heures à une semaine, et toutes deux sont irréversibles.

Supprimez les fichiers infectés et vous supprimez du même geste la seule matière qui permettra ensuite d’établir le point d’entrée : les dates de modification des fichiers, le contenu des scripts téléversés par l’attaquant et les lignes du journal d’accès du serveur qui coïncident avec ces horaires. Sans le point d’entrée, un nettoyage supprime des symptômes et rien d’autre, et le prix de cette approche a été mesuré : dans une étude de Google et de l’université de Californie à Berkeley portant sur 760 935 cas de compromission entre juillet 2014 et juin 2015, 12 % des sites ont été piratés de nouveau en moins de 30 jours, parce que l’on avait traité les symptômes et non la cause (Li et coll., WWW 2016).

Le premier travail est donc une copie complète — tous les fichiers et toute la base de données en une seule passe, avant que le moindre octet ne soit touché, car la redirection visible ou la page d’accueil défigurée est rarement tout ce qui se joue : selon les chiffres de Sucuri, 49,21 % des sites infectés en 2023 hébergeaient au moins une porte dérobée (backdoor), et sur l’année son équipe en a retiré 21 062 (Sucuri, « 2023 Hacked Website & Malware Threat Report », juin 2024). Conservez cette copie ailleurs que sur le serveur lui-même, puisque c’est là que l’attaquant garde son accès.

Le coup de téléphone suivant est pour votre hébergeur, et pas par politesse : il détient les journaux d’accès que votre propre compte ne montre en général que sur quelques jours, et sur un serveur mutualisé il lui revient de vérifier si la même chose se produit chez les voisins. Si le site encaisse des paiements ou collecte des données personnelles, coupez-le maintenant ou passez-le en mode maintenance — chaque visiteur qui saisira ses coordonnées bancaires dans l’heure qui vient est un problème distinct que vous n’avez pas encore. Le mode maintenance coûte une journée de chiffre d’affaires ; un moment manqué coûte une lettre à vos clients.

Si wp-admin ne s’ouvre plus — cela arrive sur un site compromis —, le mode maintenance ne pourra pas être activé depuis l’interface, et il reste deux voies : une règle dans le .htaccess de la racine qui renvoie tout le monde, sauf votre adresse IP, vers une page statique annonçant une intervention technique, ou une demande à l’hébergeur, dans le même appel, de suspendre le compte pour un temps. La seconde option a l’air brutale, mais elle fonctionne même quand vous n’atteignez plus les fichiers.

La sauvegarde de la veille ressemble au chemin le plus court pour revenir en arrière, et c’est parfois le bon geste, mais seulement quand on sait quel jour l’attaquant est entré. Dans notre pratique, une infection se remarque bien plus tard qu’elle n’a commencé — le code se tait un moment, puis se met à servir des pages de spam ou des redirections —, ce qui veut dire que la porte dérobée est très probablement déjà dans la copie d’hier. La restaurer masque les symptômes deux heures durant et remet le site exactement dans l’état où il a été piraté, et c’est pourquoi nous démarrons une récupération de site piraté en général dans les heures qui suivent en commençant, même dans l’urgence, par une copie plutôt que par une suppression — y compris quand le client au téléphone nous demande simplement de tout nettoyer, vite.

Les signes qui trahissent un site WordPress piraté

Une redirection qui se déclenche pour le visiteur venu d’un résultat Google mais pas quand l’adresse est tapée dans la barre du navigateur n’est pas un dysfonctionnement, mais un choix délibéré de l’attaquant. Les règles de Google contre le spam classent les redirections parmi les contenus piratés, où un attaquant injecte du code qui « redirige certains utilisateurs vers des pages malveillantes ou de spam » (Google Search Central, consulté en août 2026), et c’est le mot « certains » qui égare le propriétaire. La vérification prend une minute : ouvrez le site en navigation privée, puis retrouvez-le dans les résultats Google et ouvrez-le depuis là, et refaites les deux essais sur un téléphone.

Le deuxième groupe de signes se situe du côté de l’administration et se laisse cerner bien plus précisément : wp-admin renvoie soudain une 404, le formulaire de connexion se recharge simplement après un mot de passe correct, la liste des utilisateurs contient un compte administrateur que personne dans votre équipe n’a créé, ou l’adresse du site sous Réglages → Général n’est plus la vôtre. Dans la base de données, ce dernier signe tient à deux lignes de la table wp_options — siteurl et home —, et c’est exactement pour cela que l’adresse affichée dans vos réglages et l’adresse où atterrit un visiteur peuvent différer.

Le troisième groupe vient de l’extérieur et fait le plus mal, parce que c’est quelqu’un d’autre qui vous apprend l’état de votre propre site : l’hébergeur suspend le compte sans préavis après qu’il en est sorti du spam, un problème de sécurité apparaît dans Search Console, ou la mention « Il est possible que ce site ait été piraté » se glisse à côté de votre lien dans les résultats, mention que Google affiche quand il estime qu’un attaquant a modifié des pages existantes ou ajouté des pages de spam (aide Google Search, consultée en août 2026). Google appose cette étiquette de sa propre initiative, et non sur plainte, et elle apparaît même lorsque le site vous paraît irréprochable.

Les noms ne relèvent pas ici de l’érudition, puisque c’est sur eux que vous chercherez une solution et que vous jugerez si un prestataire comprend votre cas : la documentation de Google en nomme trois — le gibberish hack, le Japanese keyword hack et le cloaked keywords and links hack, où les pages créées par l’attaquant montrent une chose au moteur de recherche et une autre au visiteur. Le fameux « pharma hack » du métier vient de l’éditeur de sécurité Sucuri (2020) et ne figure nulle part chez Google. La vérification, elle, est la même pour les trois : lancez une requête site: sur votre propre domaine, et les pages que personne dans votre entreprise n’a écrites vous sautent aux yeux. Dans la variante japonaise, ce sont des pages générées automatiquement, aux titres en japonais, dans des dossiers aux noms tirés au hasard sur votre domaine.

Et voici la mauvaise nouvelle : un scan propre ne prouve pas qu’un site est propre, car un scanner ne voit que ce que le serveur veut bien lui montrer, alors que le code de l’attaquant reconnaît souvent les scanners et les robots des moteurs, et le guide de Google sur les pages à mots-clés dissimulés prévient que le piratage est fréquemment masqué de façon que le propriétaire croie l’affaire close. Si le scan est propre mais que votre hébergeur se plaint du courrier sortant, croyez l’hébergeur. C’est là qu’un audit de sécurité de site web avec relecture manuelle des fichiers et des journaux prend toute sa valeur : un scanner répond à la question de savoir si le site contient quelque chose d’une liste de signatures connues, pas à celle de savoir si quelqu’un s’y trouve encore.

Où se situe vraiment le risque dans WordPress

Dans notre pratique, quand la cause finit par apparaître, ce n’est presque jamais le cœur de WordPress lui-même. Le rapport « State of WordPress Security in 2026 » de Patchstack recense 11 334 nouvelles vulnérabilités divulguées dans l’écosystème WordPress au cours de 2025 — 42 % de plus que l’année précédente —, et c’est la répartition de ce chiffre qui vous importe aujourd’hui : 91 % d’entre elles concernaient des extensions et 9 % des thèmes, tandis que dans le cœur de WordPress six failles seulement ont été signalées sur l’année entière, toutes de faible priorité. Presque chaque vulnérabilité nouvellement découverte se trouve donc non pas dans le WordPress que vous avez installé un jour, mais dans ce qu’on lui a greffé au fil des ans.

Chaque extension est une base de code distincte, écrite par un auteur distinct avec une discipline de mise à jour distincte — et assez souvent déjà abandonnée —, si bien qu’un site à quarante extensions n’est pas un site avec une question de sécurité mais un site avec quarante questions de sécurité indépendantes les unes des autres. Dans notre pratique, un site d’entreprise ordinaire vit très bien avec dix à quinze extensions, et les autres sont là en héritage de missions oubliées depuis longtemps : une galerie qu’on n’affiche plus, un formulaire remplacé par un autre, un carrousel dont la maquette actuelle ne veut plus. Quand nous reprenons un développement et une maintenance WordPress, réduire ce nombre est le premier chantier, pas le dernier.

Et voici l’erreur qui revient plus souvent que toutes les autres : l’extension devenue inutile est désactivée au lieu d’être supprimée. La désactivation dit à WordPress de ne plus la charger, mais les fichiers restent à leur place sur le serveur, une partie d’entre eux demeure joignable directement en HTTP, et le script d’un attaquant n’a besoin que du chemin. En juin 2021, Wordfence a documenté une faille zero-day activement exploitée dans Fancy Product Designer, une faille « exploitable dans certaines configurations même lorsque l’extension est désactivée », et a recommandé de la désinstaller plutôt que de l’éteindre. Si vous n’avez plus besoin d’une extension, sa place n’est pas en grisé dans la liste, elle est hors du serveur.

L’échelle explique pourquoi tout cela se produit automatiquement et sans le moindre motif personnel : selon W3Techs, au 5 août 2026, WordPress fait tourner 41,2 % de tous les sites web. Dans un écosystème de cette taille, chaque vulnérabilité d’extension rendue publique devient immédiatement exploitable contre un très grand nombre de sites bâtis à l’identique, si bien qu’il est plus rentable d’automatiser les attaques que de les viser — le script lit des numéros de version, pas des raisons sociales. Personne n’a choisi votre site en particulier, et c’est précisément pour cela qu’un petit site vitrine sans données clients ni paiements se fait pirater aussi tranquillement qu’une grosse boutique en ligne.

Où l’attaquant dissimule son code dans une installation WordPress

Le premier endroit que nous ouvrons est wp-content/uploads — un dossier qui, par nature, ne contient que des images, des PDF et des vidéos, et dans lequel aucun fichier PHP ne devrait jamais s’exécuter. Si un fichier en .php traîne là au milieu des photos produit de 2019, il n’est pas arrivé par hasard : c’est presque toujours soit un téléverseur avec lequel l’attaquant fait entrer les fichiers suivants sur le serveur, soit un webshell qui exécute des commandes avec les droits de votre serveur. Que le problème soit réel et non théorique se voit à ceci que Sucuri comme Wordfence proposent un réglage de durcissement qui coupe, par une règle .htaccess, le moteur PHP dans ce dossier précis.

Le deuxième endroit est wp-content/mu-plugins. Ce qui y est déposé s’active automatiquement, ne peut pas être désactivé depuis l’interface d’administration et — c’est ici le plus important — n’apparaît pas dans la liste ordinaire des extensions, de sorte qu’un propriétaire peut contempler pendant des mois un tableau de bord d’apparence saine ; en juillet 2025, Sucuri a décrit exactement ce cas de figure, avec une porte dérobée dans ce dossier. À côté, nous examinons toujours le .htaccess, à la racine comme dans les sous-dossiers, parce qu’une redirection qui ne se déclenche que pour les visiteurs venus d’un moteur de recherche ou seulement sur mobile y est le plus souvent inscrite — et c’est la raison pour laquelle votre site vous paraît parfaitement normal.

Le code s’écrit aussi dans les premières lignes de fichiers existants et parfaitement légitimes, le plus souvent en tête de wp-config.php et dans le functions.php du thème, et il n’a presque jamais l’air d’un code malveillant : c’est une longue ligne unique avec un appel à base64_decode, gzinflate ou eval, suivie de centaines de lignes vides pour que le fichier semble terminé dans l’éditeur. C’est pourquoi comparer les fichiers à un original sain vaut mieux que les lire : personne ne trouve cette ligne à l’œil, parce que personne ne fait défiler un fichier jusqu’à la neuf centième ligne.

Et puis il y a la base de données, où un scanner de fichiers ne regarde pas et où trois endroits sont à contrôler : les lignes siteurl et home de wp_options, que l’attaquant réécrit pour que vos pages chargent leurs ressources depuis un serveur étranger ; la table wp_users, où apparaît volontiers un compte administrateur au nom crédible ; et le contenu des publications dans wp_posts, où des liens dissimulés et des iframes se glissent au milieu de vieux articles que plus personne n’ouvre. Si les fichiers sont nettoyés mais que l’injection reste en base, l’infection revient le jour même. La ligne elle-même ne s’exécute pas : un petit chargeur logé dans le functions.php du thème ou dans mu-plugins la lit et la lance à chaque affichage, et ce duo restaure les fichiers supprimés plus vite que vous ne vérifiez le résultat. C’est pour cela que, dans une récupération de site piraté, fichiers et base de données sont chez nous un seul travail et non deux.

Comparer les fichiers à des originaux vérifiés

Le premier outil que nous prenons, une fois la copie complète des fichiers et de la base mise à l’abri, est wp core verify-checksums : la commande compare l’empreinte de chaque fichier aux sommes de contrôle publiées par WordPress.org et montre aussitôt lesquels ont été modifiés et lesquels n’ont rien à faire dans l’installation. L’ennui commence là où s’arrête sa portée : elle ne vérifie que wp-admin/, wp-includes/ et les fichiers wp-* de la racine, tandis que son code source laisse délibérément de côté l’ensemble de wp-content, donc les extensions, les thèmes et les fichiers téléversés (code source de la commande checksum de WP-CLI, consulté le 5 août 2026). Ce même code source exclut un fichier de la racine à part, wp-config.php, si bien que le fichier dont les premières lignes reçoivent le plus souvent du code injecté échappe au contrôle. Un résultat propre ne signifie pas un site propre.

Il existe une commande distincte, wp plugin verify-checksums, mais elle aussi ne compare les fichiers qu’aux sommes de contrôle du dépôt WordPress.org, de sorte qu’une extension commerciale achetée à son éditeur est purement et simplement ignorée ; pour les thèmes, la documentation de WP-CLI ne propose aucun équivalent (documentation WP-CLI, consultée le 5 août 2026). Ni les thèmes ni les extensions achetées hors du dépôt ne se prêtent donc à une vérification automatique, et wp core verify-checksums laisse de côté tout wp-content — la partie du code d’où sont sorties, sur les 11 334 vulnérabilités recensées par Patchstack pour 2025, toutes sauf les six du cœur. Sur les sites que nous reprenons, le thème est justement ce que personne n’a jamais contrôlé.

Les sommes de contrôle sont donc chez nous un point de départ et non une méthode : le cœur et les extensions, nous ne les soignons pas, nous les remplaçons — mêmes versions téléchargées depuis la source d’origine, dossiers réécrits en entier plutôt que fichier par fichier. De l’ancienne installation nous ne gardons que wp-content/uploads, et encore, après avoir vérifié qu’aucun fichier PHP ne se cache entre les images — pour la raison même qui rend utile la coupure du moteur PHP dans ce dossier. Le thème, nous le restaurons depuis la gestion de versions quand elle existe ; sinon nous partons de la copie de son éditeur et réappliquons les personnalisations une à une, parce que c’est le seul moyen de dire plus tard quelle ligne du site est de nous.

Trouver la mauvaise ligne et l’effacer paraît moins cher, et c’est précisément pour cela que c’est l’erreur la plus répétée : un attaquant laisse rarement une seule entrée, et une seule porte dérobée passée inaperçue rend inutile tout le reste du travail. Le code peut être réparti sur plusieurs fichiers, dissimulé derrière un appel base64 ou gzinflate, inscrit dans la table des options de la base ou déposé dans ce même dossier mu-plugins que l’administration n’affiche pas. Une recherche par signature trouve ce que vous connaissez déjà ; un remplacement intégral vous débarrasse aussi de ce que vous ne connaissez pas.

Il y a aussi du travail que nous ne faisons pas à ce stade : nous ne comptons pas sur une extension qui propose de « réparer » les fichiers infectés d’un clic, puisqu’elle travaille avec la même liste de signatures connues et, de surcroît, dans l’environnement même où l’attaquant garde son accès. Nous ne comparons pas non plus les fichiers à la main sur une vitrine ordinaire ou un blog, parce qu’une installation neuve avec le contenu réimporté demande moins d’heures que la comparaison ligne à ligne de deux arborescences, et le résultat se vérifie. La comparaison manuelle a sa place là où le thème ou une extension est unique et où il n’existe pas de gestion de versions ; comment tenir ses sauvegardes pour que ce choix existe seulement, nous l’avons décrit dans le guide général de récupération.

Clés, sessions et mots de passe : ce que chacun fait réellement

Les clés d’authentification et de salage du fichier wp-config.php ne chiffrent rien, quoi qu’en dise à peu près chaque tutoriel : WordPress s’en sert comme base de la clé avec laquelle la fonction wp_generate_auth_cookie() signe le cookie d’authentification en HMAC-SHA256, alors que le cookie lui-même est du texte en clair portant l’identifiant, une date d’expiration et un jeton de session (WordPress Developer Resources, consulté le 5 août 2026). Renouveler ces valeurs rend donc invérifiable toute signature émise auparavant, et le serveur rejette chaque cookie distribué jusque-là, même quand la session n’a pas formellement expiré.

La conséquence pratique est exactement celle dont on a besoin lors d’un piratage : la documentation officielle de WordPress présente le renouvellement des clés comme le moyen de déconnecter quiconque serait encore authentifié (WordPress.org, « FAQ My site was hacked », mis à jour le 26 juillet 2026), de sorte que si l’attaquant tient une session valide, elle prend fin à l’instant même. Tous les jetons nonce émis deviennent caducs en même temps que les sessions, et les formulaires en cours comme les tunnels de commande à mi-parcours se rompent à ce moment-là — nous choisissons donc l’heure du renouvellement délibérément, et non au hasard en plein après-midi de semaine.

Renouveler les clés et les sels ne change aucun mot de passe. WordPress construit les empreintes de mots de passe avec bcrypt et un sel aléatoire propre à chacune, sans rapport avec les constantes de wp-config.php (fonction wp_hash_password() ; bcrypt par défaut depuis WordPress 6.8), si bien qu’un attaquant qui connaît le mot de passe administrateur, ou qui a eu le temps de se créer un compte, se reconnecte simplement après le changement de clés. Les mots de passe se changent séparément et tous, y compris ceux que personne n’est censé connaître, et l’on parcourt en même temps la liste des utilisateurs à la recherche de comptes que personne dans votre équipe n’a créés.

La liste des accès ne s’arrête pas à WordPress : dans la même passe se changent le mot de passe du panneau de l’hébergeur, les identifiants FTP et SFTP, le mot de passe de l’utilisateur de la base de données ainsi que la ligne correspondante dans wp-config.php, et les clés SSH — qui ne se changent pas comme un mot de passe mais se régénèrent, l’ancienne clé publique étant retirée du fichier authorized_keys du serveur. Viennent enfin les clés d’API stockées sur le site — passerelle de paiement, service d’envoi de courriels, intégrations de livraison et de comptabilité —, car ce sont elles qui restent intactes le plus longtemps : personne ne les voit au quotidien.

Partez du principe que l’attaquant détient une copie complète de la base de données, parce que c’est l’étape la moins coûteuse de toute l’attaque : tout ce qui s’y trouvait — adresses électroniques des clients, historique des commandes, empreintes de mots de passe, clés inscrites dans les réglages des extensions — doit être considéré comme passé en d’autres mains. Si l’un de ces mots de passe a servi ailleurs, cet ailleurs est compromis lui aussi, et c’est en général là que la conversation quitte le site pour les boîtes aux lettres, la comptabilité et le compte de paiement de la boutique.

L’ordre compte autant que la liste : clés et mots de passe se changent une fois les portes dérobées retirées, faute de quoi l’attaquant relit les nouvelles valeurs directement dans wp-config.php ou intercepte tout simplement la connexion suivante. C’est précisément sur cet enchaînement — copie complète d’abord, puis la cause, puis le nettoyage, et les accès seulement en dernier — qu’une remise en état menée en interne cale ou se désorganise le plus souvent, et c’est pourquoi nous prenons cette étape à notre charge et remettons à la fin un rapport écrit de ce qui a été changé, quand et pourquoi.

Comment faire lever l’avertissement Google, et quoi faire ensuite

Le rapport sur les problèmes de sécurité de Google Search Console est le seul endroit où voir ce que Google a trouvé chez vous : il indique le type de menace et un échantillon des pages touchées. Le type de menace ne change pas ce que voit le visiteur : Chrome ne trie plus le titre de son avertissement selon qu’il a trouvé de l’hameçonnage, un logiciel malveillant ou un logiciel indésirable, mais affiche dans tous les cas le même écran rouge — intitulé « Site dangereux » — qui n’y laisse tout bonnement entrer personne, alors que la mention « Il est possible que ce site ait été piraté » évoquée plus haut n’est qu’une ligne de texte à côté du lien dans les résultats, que l’on peut ignorer d’un clic (page d’aide de Google Chrome sur les sites dangereux, consultée en août 2026). Les anciens titres, différents selon le type de menace, Chrome ne les utilise plus, même si une partie de la documentation de Google les affiche encore. Le premier bloque, la seconde avertit, et cela change le temps dont vous disposez réellement.

Avant d’appuyer sur « Demander un examen », il faut être certain que le site est réellement propre et pas seulement d’apparence propre dans votre navigateur. Le guide de Google sur les pages à mots-clés dissimulés prévient explicitement que les attaquants cherchent à donner l’impression qu’une page a déjà été supprimée ou corrigée ; chaque ancienne page de spam doit donc être contrôlée avec l’outil d’inspection d’URL, qui montre la vue de Googlebot et non la vôtre. La deuxième étape, celle que l’on saute le plus souvent, c’est la liste des propriétaires : dans le Japanese keyword hack, l’attaquant s’ajoute comme propriétaire validé de Search Console (documentation de Google sur web.dev), et tant qu’il n’en a pas été retiré, il en sait exactement autant que vous sur l’état du site.

Le bouton à chercher est « Demander un examen » dans le rapport sur les problèmes de sécurité, et non la demande de réexamen que Google réserve aux actions manuelles ; le texte de la demande gagne à dire trois choses : ce qui a été trouvé, comment l’attaquant est entré et ce qui a été fait concrètement pour y remédier. Nous ne promettons pas de délai, parce que Google n’en promet pas non plus : sa page de documentation sur l’ingénierie sociale indique que l’examen « peut prendre plusieurs jours », tandis que la page d’aide de Search Console sur les problèmes de sécurité parle de « plusieurs jours, voire plusieurs semaines » (les deux consultées en août 2026). Si quelqu’un vous annonce 24 ou 72 heures fermes, il répète un chiffre qui ne figure dans aucune source de Google.

La précipitation coûte plus cher ici que l’attente. Dans la même étude de Google et de Berkeley, 80 % des propriétaires ont obtenu que leur site soit déclaré propre dès la première tentative, mais les 20 % restants en ont demandé plusieurs, et le temps médian qu’ils ont passé à démêler le code laissé par l’attaquant a été d’une semaine entière. Les données datent de 2014-2015 et se lisent comme telles, mais l’arithmétique n’a pas bougé : une demande refusée signifie que l’avertissement reste un cycle de plus, et la deuxième fois vous n’êtes plus un primo-demandeur.

Une fois l’avertissement levé, le travail n’est pas fini, car les pages créées par l’attaquant restent dans l’index, et il ne faut pas les rediriger vers la page d’accueil : elles doivent renvoyer un code 404 ou 410 pour que Google les retire complètement, alors que l’outil de suppression de Search Console ne fait que les masquer temporairement. Le positionnement ne revient pas d’un coup d’interrupteur : les pages doivent être réindexées, au rythme de Google et non au vôtre. Comment se servir à ce stade des journaux et des sauvegardes pour que le point de départ soit meilleur la fois suivante, nous l’avons décrit dans un guide distinct sur la récupération des sites piratés.

Quand cesser de le faire soi-même, et combien cela coûte

Un propriétaire de site expérimenté fait une partie de ce qui précède lui-même, et nous le disons sans détour à ceux qui nous appellent avec Search Console ouverte et l’extension fautive déjà identifiée. Si l’infection se limite à une page d’accueil défigurée, si les journaux montrent quelle extension l’a laissée entrer, s’il n’y a pas d’administrateur inconnu dans la liste des utilisateurs et si vous disposez d’une sauvegarde de la veille que quelqu’un a réellement restaurée un jour dans un environnement de test, alors huit heures facturées vous achèteront un sommeil plus tranquille, pas un résultat plus rapide.

Il y a quatre situations où nous conseillons de s’arrêter, et la première est la réinfection après nettoyage : si le site est piraté une seconde fois, ce n’est pas une question de malchance mais la preuve que le point d’entrée est resté ouvert, et un troisième nettoyage dans le même environnement coûtera exactement ce qu’ont coûté les deux premiers. La deuxième est le moindre soupçon touchant des données clients ou des données de paiement, car au travail technique s’ajoutent alors des obligations envers la CNIL et des délais que la bonne volonté ne rallonge pas. La troisième est un site dont l’entreprise tire un revenu quotidien, et la quatrième, un simple manque de temps : le nettoyage n’a rien d’intellectuellement difficile, mais il est long, monotone et ne pardonne aucun fichier sauté.

Notre remise en état de sites piratés coûte 90 € de l’heure hors taxes, avec un minimum de huit heures de travail, payables d’avance. Nous démarrons en général dans les heures qui suivent la demande, et l’ensemble du processus, du début à la livraison, prend d’ordinaire de 8 à 72 heures ; l’écart entre huit et soixante-douze tient presque toujours à la profondeur à laquelle l’attaquant a eu le temps de s’installer et à l’ancienneté de la dernière copie saine. Le minimum n’est pas un chiffre commercial : une copie complète, la recherche de la cause dans les journaux, le nettoyage et la vérification entrent rarement dans moins que cela.

Le déroulé est celui décrit plus haut, à ceci près qu’il ne mange pas votre week-end. Avant de toucher à quoi que ce soit, nous prenons une copie complète des fichiers et de la base pour que l’incident reste enquêtable, et le site n’est isolé qu’ensuite ; il est alors débarrassé des logiciels malveillants et des portes dérobées, la base est contrôlée, les accès et les clés renouvelés, la cause de l’intrusion trouvée et refermée, la demande d’examen déposée auprès de Google et une supervision mise en place, et vous recevez à la fin un rapport écrit sur ce qui a été modifié. Si le site est hors service en ce moment ou si vous n’êtes pas sûr de ce que vous voyez, vous pouvez demander une vérification urgente de votre site : nous vous dirons s’il y a seulement matière à facturer.

Dans bien des cas, la vraie réponse n’est pourtant pas la remise en état mais ce qui vient après : si un site a accumulé vingt extensions dont personne ne se rappelle la raison d’être pour la moitié, le problème est la maintenance, et ce qui le résout, c’est un développement et une maintenance WordPress, pas un nouveau cycle de nettoyage dans six mois. L’heure la moins chère de toute cette histoire est celle qui a été dépensée avant : supprimer de wp-content/plugins une extension inutilisée au lieu de la désactiver, et garder une sauvegarde que quelqu’un a vraiment restaurée une fois en environnement de test, coûtent ensemble moins qu’une seule de nos journées de travail.