Site WordPress piraté : que faire dans les 24 premières heures (guide d’urgence)

Si ton site WordPress est piraté, fais exactement ceci, dans cet ordre : ne supprime rien, exporte une copie complète de l’état infecté (fichiers et base de données), change tous les mots de passe (hébergeur, FTP, base de données, administrateurs WordPress, email), coupe l’accès public si le site redirige tes visiteurs ou si Google affiche un avertissement, puis préviens ton hébergeur. Le nettoyage vient après, jamais avant. Ce guide suit les 24 premières heures dans l’ordre réel des opérations : reconnaître le piratage, sécuriser les accès, localiser l’infection, nettoyer, durcir, puis demander à Google de lever l’alerte.

Je suis Ayoub Fattami, développeur web freelance à Marrakech, et le site piraté est l’appel que je reçois le plus souvent un dimanche soir. Presque toujours la même scène : un client a vu quelque chose de bizarre, le propriétaire du site panique, et la première chose qu’il a envie de faire est de tout supprimer. Ce guide existe pour que tu ne fasses pas ça.

Comment être sûr que ton site WordPress a été piraté ?

Un site WordPress piraté montre presque toujours au moins un de ces huit symptômes. Un seul suffit pour déclencher la procédure de ce guide : tu ne perds rien à traiter une fausse alerte, tu perds beaucoup à ignorer une vraie.

1. Le site redirige vers un autre site. Paris sportifs, pharmacie, rencontres, casino, fausses mises à jour de navigateur. La redirection est souvent conditionnelle : elle ne se déclenche que sur mobile, ou seulement quand le visiteur arrive depuis Google. Toi, depuis ton ordinateur, tu ne vois rien.
2. Des pages en japonais ou en pharma apparaissent dans Google. Tape site:tondomaine.ma dans Google. Si tu vois des centaines de pages que tu n’as jamais créées, avec des titres en japonais, en russe ou vantant des médicaments, c’est du spam SEO injecté. On l’appelle le « Japanese keyword hack ».
3. Un administrateur inconnu existe dans Utilisateurs. Un compte avec un nom générique (wp-admin, support, backup) ou une adresse email étrangère, avec le rôle Administrateur.
4. Des fichiers ont été modifiés à une date récente alors que tu n’as rien touché. Le gestionnaire de fichiers de ton hébergeur ou un client FTP trié par date le montre en quelques secondes.
5. Google affiche « Ce site peut être piraté » ou « Site dangereux », ou la Search Console t’a envoyé un message dans la rubrique Problèmes de sécurité. Le navigateur peut aussi bloquer l’accès avec un écran rouge (Google Safe Browsing).
6. Des emails partent depuis ton site. Ton hébergeur te signale un envoi massif, ton domaine est placé en liste noire, ou tes propres emails professionnels arrivent en spam chez tes clients.
7. Une lenteur soudaine et inexpliquée. Le serveur est occupé à envoyer du spam, à miner de la cryptomonnaie ou à attaquer d’autres sites. Ton hébergeur peut suspendre le compte pour surconsommation.
8. Des pop-ups, des publicités ou des liens que tu n’as jamais placés s’affichent sur tes pages, parfois uniquement pour certains visiteurs.

Ce qui n’est généralement pas un piratage : un écran blanc après une mise à jour, une erreur 500, un site bloqué en mode maintenance. Ces pannes sont couvertes dans mon guide sur les 15 bugs WordPress les plus courants et leurs solutions. Si ton problème ressemble à ça, commence par là.

Les 4 réflexes qui aggravent tout

Avant de faire quoi que ce soit, voici les quatre décisions que je vois prendre sous le coup de la panique, et qui transforment un incident d’une journée en cauchemar de plusieurs semaines.

Supprimer le site. Tu perds tes contenus, tes commandes, tes preuves, et tu n’as toujours pas compris comment l’attaquant est entré. Un site supprimé puis réinstallé avec les mêmes mots de passe, les mêmes extensions et la même faille sera réinfecté.

Réinstaller WordPress par-dessus sans nettoyer la base de données. C’est le piège le plus fréquent. Tu remplaces les fichiers, le site a l’air propre, et trois jours plus tard la redirection revient. Le code malveillant était dans la table wp_options, dans un article, ou dans une tâche planifiée qui retélécharge la porte dérobée.

Payer une « rançon ». Certains piratages affichent un message réclamant un paiement en cryptomonnaie pour « restaurer » le site. Ne paie jamais. Tes fichiers sont chez ton hébergeur, tes sauvegardes aussi ; l’attaquant n’a rien que tu ne puisses récupérer autrement, et rien ne garantit qu’il te rende quoi que ce soit.

Restaurer une sauvegarde déjà infectée. Beaucoup de piratages restent silencieux plusieurs semaines avant de se manifester. Si ta sauvegarde date de la semaine dernière et que l’intrusion remonte à un mois, tu restaures le problème avec.

Un client m’a contacté après avoir restauré trois fois la même sauvegarde en une semaine. Chaque fois, le site redevenait propre pendant deux jours, puis les pages de spam réapparaissaient. La porte dérobée était dans la sauvegarde elle-même, dans un fichier du dossier uploads que personne ne pensait à regarder.

Heure 0 : figer la scène sans rien casser

Pendant la première heure, ton objectif n’est pas de nettoyer. C’est de conserver une copie exacte de l’état infecté, de limiter les dégâts pour tes visiteurs et de prévenir les bonnes personnes. Tout ce que tu supprimes maintenant, tu ne pourras plus l’analyser.

Sauvegarder l’état infecté

Exporte le site complet tel qu’il est, sans le nettoyer. Depuis hPanel (Hostinger) ou cPanel, le gestionnaire de fichiers permet de compresser tout le dossier public_html en une archive ; télécharge-la et nomme-la clairement, par exemple infecte-2026-09-03.zip. Exporte ensuite la base de données depuis phpMyAdmin (onglet Exporter, format SQL). Garde ces deux fichiers à l’écart de ton site, sur ton ordinateur ou un disque externe, et ne les restaure jamais.

Cette copie sert à trois choses : comprendre plus tard comment l’attaquant est entré, retrouver un contenu que tu aurais perdu pendant le nettoyage, et constituer une preuve si tu dois documenter l’incident.

Couper l’accès public si nécessaire

Si le site redirige tes visiteurs, affiche un contenu dangereux ou envoie du spam, mets-le hors ligne. La méthode la plus simple : demander à ton hébergeur de suspendre l’affichage, ou remplacer temporairement le fichier .htaccess (après l’avoir sauvegardé) par un fichier qui n’autorise que ton adresse IP. Une page « site en maintenance » vaut mille fois mieux qu’une redirection vers un site de paris sous ton nom.

Si le site se contente d’avoir un administrateur inconnu ou quelques fichiers modifiés, sans effet visible pour les visiteurs, tu peux le laisser en ligne le temps de sécuriser les accès.

Prévenir l’hébergeur

Ouvre un ticket immédiatement. Explique les symptômes, demande les journaux d’accès (access logs) et de connexion FTP des derniers jours, et demande s’il héberge d’autres sites sur le même compte. Sur un hébergement mutualisé, un site infecté contamine souvent ses voisins dans le même espace. L’hébergeur peut aussi confirmer si l’intrusion vient de son côté ou du tien, ce qui change complètement la suite.

Heure 1 : sécuriser tous les accès, dans le bon ordre

Tant que l’attaquant possède un identifiant valide, nettoyer ne sert à rien : il revient le soir même. Cette heure consiste à changer chaque mot de passe qui touche au site, en partant du plus haut niveau vers le plus bas, et à invalider toutes les sessions ouvertes.

1. Le compte hébergeur (hPanel, cPanel, espace client). C’est la clé de tout le reste. Nouveau mot de passe long et unique, double authentification activée dès maintenant si elle existe.
2. Les comptes FTP / SFTP. Change le mot de passe, ou mieux : supprime les comptes existants et recrées-en un seul. Beaucoup de piratages commencent par un mot de passe FTP volé sur l’ordinateur du propriétaire. Lance un antivirus à jour sur ta machine avant de saisir les nouveaux mots de passe.
3. La base de données. Change le mot de passe de l’utilisateur MySQL depuis le panneau de l’hébergeur, puis reporte-le dans wp-config.php (ligne DB_PASSWORD). Sans ça, le site affichera « Erreur d’établissement de connexion à la base de données » : c’est normal, corrige la ligne et ça repart.
4. Tous les administrateurs WordPress. Chaque compte, pas seulement le tien. Regarde en même temps la liste des utilisateurs : note les comptes inconnus, tu les supprimeras à l’étape de nettoyage.
5. Les clés de sécurité WordPress. Dans wp-config.php, remplace le bloc AUTH_KEY, SECURE_AUTH_KEY, etc. par de nouvelles valeurs générées sur la page officielle des clés secrètes de WordPress.org. Cela déconnecte instantanément toutes les sessions ouvertes, y compris celles de l’attaquant.
6. L’adresse email liée au site. Si l’attaquant contrôle la boîte email de l’administrateur, il peut réinitialiser tous les mots de passe que tu viens de changer. Change ce mot de passe aussi, et vérifie qu’aucune règle de transfert automatique n’a été ajoutée dans la messagerie.

Note quelque part les nouveaux identifiants, dans un gestionnaire de mots de passe et pas dans un fichier texte sur le bureau. Et pas de réutilisation : le mot de passe de l’hébergeur ne doit pas être celui de WordPress.

Un point d’honnêteté avant d’aller plus loin. Si ton site encaisse des paiements, gère des comptes clients ou stocke des données personnelles, arrête-toi ici et contacte un professionnel. Les étapes suivantes demandent d’ouvrir des fichiers PHP, de fouiller une base de données et de prendre des décisions irréversibles. Sur une boutique en production, une erreur coûte plus cher que l’intervention. Mon service de dépannage WordPress d’urgence couvre exactement ce cas : envoie-moi l’URL et les symptômes sur WhatsApp, je te réponds rapidement et le diagnostic est gratuit. Si tu tiens un site vitrine ou un blog et que tu es à l’aise avec FTP et phpMyAdmin, continue.

Heures 2 à 6 : localiser l’infection

Un piratage WordPress n’est presque jamais à un seul endroit. L’attaquant place une porte dérobée (backdoor) à plusieurs emplacements pour survivre à un nettoyage partiel. Ton travail pendant ces heures est de dresser la liste complète de ce qui a été touché, avant de nettoyer quoi que ce soit.

Commencer par les fichiers modifiés récemment

Trie tous les fichiers par date de modification, dans le gestionnaire de fichiers ou en SSH avec find . -type f -mtime -30 (fichiers modifiés dans les 30 derniers jours). Tout fichier modifié à une date où tu n’as rien fait est suspect. Note-les tous. Les attaquants savent parfois falsifier les dates, donc l’absence de fichier récent ne prouve rien, mais leur présence est un excellent point de départ.

Vérifier le cœur de WordPress

Les fichiers de wp-admin et wp-includes ne doivent contenir que ce que WordPress.org distribue. Si tu as accès à WP-CLI en SSH, la commande wp core verify-checksums compare chaque fichier à l’original et liste ceux qui diffèrent ou qui sont en trop. Sans SSH, télécharge la même version de WordPress depuis wordpress.org et compare les dossiers avec un outil de comparaison. Un fichier PHP présent dans wp-includes qui n’existe pas dans l’archive officielle est une porte dérobée, presque à coup sûr.

Le thème

Ouvre functions.php, header.php et footer.php du thème actif. Un bloc de code commençant par eval(, base64_decode(, gzinflate(, str_rot13( ou une longue chaîne de caractères illisible est du code malveillant dans l’immense majorité des cas. Regarde aussi les thèmes inactifs : ils s’exécutent moins, mais un fichier PHP appelé directement par son URL fonctionne même dans un thème désactivé.

Les extensions

Compare la liste des dossiers dans wp-content/plugins avec la liste des extensions visibles dans le tableau de bord. Un dossier qui n’apparaît pas dans l’administration, ou une extension au nom générique que tu ne te souviens pas avoir installée, est suspect. Vérifie surtout toute extension ou tout thème obtenu ailleurs que sur wordpress.org ou chez son éditeur officiel. Les versions « nulled » (piratées) sont l’un des vecteurs d’infection les plus fréquents que je rencontre.

Le dossier uploads

Le dossier wp-content/uploads ne doit contenir que des médias : images, PDF, vidéos. Aucun fichier .php n’a de raison légitime de s’y trouver. Cherche-les tous avec find wp-content/uploads -name "*.php" ou via la recherche du gestionnaire de fichiers. Regarde aussi les fichiers avec une double extension (image.jpg.php) ou un fichier .htaccess dans un sous-dossier d’uploads qui autoriserait l’exécution de PHP.

wp-config.php et .htaccess

Dans wp-config.php, une ligne include ou require pointant vers un fichier inhabituel, souvent placée tout en haut ou tout en bas, charge la porte dérobée à chaque visite. Dans .htaccess, cherche des règles RewriteRule ou RewriteCond qui redirigent selon l’agent utilisateur (HTTP_USER_AGENT) ou le référent (HTTP_REFERER) : c’est la signature classique de la redirection conditionnelle mobile ou Google.

La base de données

Ouvre phpMyAdmin et vérifie dans l’ordre : la table wp_options, lignes siteurl et home (elles doivent pointer vers ton domaine et rien d’autre) ; la ligne active_plugins (une extension activée que tu ne vois pas dans l’administration) ; les tables wp_posts et wp_postmeta, en cherchant <script, <iframe, eval( et base64 ; enfin wp_users et wp_usermeta, pour repérer un utilisateur dont le rôle est administrateur sans que tu l’aies créé. La fonction Rechercher de phpMyAdmin permet de scanner toutes les tables d’un coup.

Les utilisateurs fantômes

Un attaquant crée souvent un compte administrateur qui n’apparaît pas dans la liste du tableau de bord, en jouant sur les métadonnées. La table wp_users de la base de données dit la vérité : chaque ligne est un compte réel. Compare-la avec ce que l’administration t’affiche.

Les tâches cron

WordPress possède son propre système de tâches planifiées, stocké dans la ligne cron de wp_options. Une tâche au nom inconnu qui s’exécute toutes les heures peut retélécharger l’infection après chaque nettoyage. Vérifie aussi les tâches cron côté serveur, dans le panneau de ton hébergeur : un piratage qui s’installe là survit à une réinstallation complète de WordPress.

Des scanners comme Wordfence, Sucuri SiteCheck ou VirusTotal (pour un fichier précis) accélèrent cette phase et repèrent les signatures connues. Ils ne remplacent pas la vérification manuelle : un scanner ne connaît pas ton site, toi si.

Le tableau de diagnostic

Type d’infection	Où chercher en priorité	Comment nettoyer
Redirection vers un autre site	.htaccess, functions.php du thème, wp_options (siteurl, home), wp_posts	Régénérer .htaccess, remplacer le thème par une copie officielle, corriger les URL, supprimer les scripts injectés
Pages spam en japonais / pharma	Fichiers PHP inconnus à la racine et dans wp-includes, sitemaps étrangers, wp_posts	Réinstaller le cœur, supprimer les fichiers en trop, supprimer les faux articles, demander la suppression des URL dans la Search Console
Porte dérobée (backdoor)	wp-content/uploads (fichiers .php), thèmes inactifs, extensions inconnues, wp-config.php	Supprimer tout PHP dans uploads, supprimer thèmes et extensions inutilisés, réécrire wp-config.php à la main
Administrateur inconnu	Table wp_users et wp_usermeta	Supprimer le compte en base, changer tous les mots de passe, régénérer les clés de sécurité
Envoi de spam depuis le site	Fichiers PHP récents, tâches cron, logs de l’hébergeur	Supprimer les scripts d’envoi, nettoyer les cron, demander le retrait des listes noires
Réinfection après nettoyage	Tâches cron WordPress et serveur, extension nulled, deuxième site sur le même hébergement	Nettoyer les cron, remplacer l’extension par une licence légitime, isoler ou nettoyer les autres sites
Pop-ups et publicités injectées	wp_posts, wp_options (widgets, personnalisation), footer.php	Supprimer les balises <script> et <iframe> étrangères, remplacer le thème

Le cas typique que je traite : une boutique de produits artisanaux dont les visiteurs venant de Google, sur téléphone, atterrissaient sur un site de paris. Le propriétaire ne voyait rien depuis son ordinateur. C’est un client qui l’a prévenu par WhatsApp, un peu gêné, en demandant si le site avait changé d’activité. La redirection était dans le .htaccess, avec une condition sur l’agent utilisateur ; la porte dérobée qui la recréait était dans un fichier PHP du dossier uploads, nommé comme une image.

Heures 6 à 12 : nettoyer le site

Il y a deux façons de nettoyer un site WordPress infecté : restaurer une sauvegarde saine, ou remplacer chaque fichier par sa version officielle. La bonne méthode dépend d’une seule question : es-tu certain de la date de l’infection ? Si oui, restaure. Si non, nettoie par remplacement.

Option A : restaurer une sauvegarde saine

Elle n’est valable que si la sauvegarde est antérieure à l’intrusion, avec certitude (les fichiers modifiés et les logs de l’hébergeur t’ont donné cette date), si elle contient les fichiers et la base de données, et si tu acceptes de perdre ce qui a été publié depuis. Restaure, puis immédiatement : change de nouveau tous les mots de passe (la sauvegarde contient les anciens), applique toutes les mises à jour, supprime les comptes inconnus, et relance un scan complet. La sauvegarde a remis le site en état ; elle n’a pas fermé la porte par laquelle l’attaquant est entré.

Option B : nettoyer par remplacement

C’est la méthode que je préfère, parce qu’elle ne demande pas de reconnaître du code malveillant : on ne cherche pas l’aiguille, on change la botte de foin.

1. Réinstaller le cœur. Télécharge la dernière version sur wordpress.org. Supprime entièrement les dossiers wp-admin et wp-includes du site, puis remplace-les par ceux de l’archive. À la racine, remplace tous les fichiers wp-*.php, index.php et xmlrpc.php par les originaux, sauf wp-config.php que tu conserves après l’avoir relu ligne par ligne. Tout fichier de la racine qui n’existe pas dans l’archive officielle doit disparaître.
2. Remplacer chaque extension. Note la liste des extensions actives. Supprime le dossier wp-content/plugins entier, puis réinstalle chaque extension depuis le répertoire officiel de WordPress.org ou depuis le compte client de l’éditeur pour les extensions payantes. Les réglages sont conservés dans la base de données, tu ne perds rien. Une extension que tu ne peux pas obtenir d’une source officielle ne revient pas.
3. Remplacer le thème. Même principe : supprime le thème et réinstalle-le depuis sa source officielle. Si tu as fait des modifications directement dans le thème (mauvaise pratique, mais fréquente), récupère-les depuis ta copie infectée en relisant chaque ligne. Supprime tous les thèmes inutilisés, sauf un thème par défaut de WordPress pour le dépannage.
4. Nettoyer uploads. Supprime tous les fichiers .php et tout .htaccess trouvés dans wp-content/uploads. Vérifie les fichiers à double extension.
5. Nettoyer la base de données. Supprime les utilisateurs inconnus, les faux articles et pages, les scripts injectés dans les contenus légitimes (rechercher-remplacer prudent, table par table), la ligne cron si elle contient des tâches inconnues (WordPress la régénère), et corrige siteurl et home.
6. Réécrire .htaccess et wp-config.php. Repars du .htaccess standard de WordPress, puis enregistre tes permaliens dans Réglages > Permaliens pour le régénérer. Vérifie wp-config.php : identifiants de base de données, nouvelles clés de sécurité, aucune ligne include étrangère.
7. Vérifier. Relance le scan. Ouvre le site en navigation privée, depuis un téléphone en 4G, et en simulant Google avec curl -A "Googlebot" https://tondomaine.ma. Si tout est identique, le nettoyage tient.

Un restaurant de Marrakech m’avait appelé pour un site qu’il avait déjà fait « nettoyer » deux fois. Le thème premium venait d’un site de partage gratuit ; il contenait, dans un fichier au nom parfaitement anodin, un code qui recréait un administrateur toutes les nuits. Tant que le thème restait, chaque nettoyage tenait une semaine. On l’a remplacé par une licence légitime, et l’infection s’est arrêtée là.

Heures 12 à 24 : durcir WordPress pour que ça ne recommence pas

Un site nettoyé mais non durci est réinfecté par le même chemin dans les jours qui suivent. Cette dernière tranche de la journée ferme les portes une par une, en commençant par celle que l’attaquant a utilisée si tu l’as identifiée.

• Mettre tout à jour. Cœur de WordPress, extensions, thèmes, et version de PHP dans le panneau de l’hébergeur (une version supportée, 8.2 ou plus récente). Les failles connues d’une extension non mise à jour sont exploitées automatiquement par des robots, quelques jours après leur publication.
• Supprimer ce qui ne sert pas. Chaque extension inactive, chaque thème inutilisé, chaque compte utilisateur oublié est une surface d’attaque de plus. Moins il y a de code, moins il y a de failles.
• Activer la double authentification (2FA) sur tous les comptes administrateurs et sur le compte hébergeur. C’est la mesure qui rend un mot de passe volé inutile.
• Limiter les tentatives de connexion. Un blocage après quelques échecs stoppe les attaques par force brute. Renomme aussi le compte admin s’il existe encore.
• Corriger les permissions des fichiers. Dossiers en 755, fichiers en 644, et wp-config.php en 600 ou 440 selon l’hébergeur. Jamais de 777, même « temporairement ».
• Interdire l’édition de fichiers depuis l’administration avec define('DISALLOW_FILE_EDIT', true); dans wp-config.php. Un attaquant qui obtient un compte administrateur ne peut plus injecter de PHP depuis l’éditeur de thème.
• Régénérer les clés de sécurité si ce n’est pas déjà fait à l’heure 1.
• Désactiver XML-RPC si aucune application ne l’utilise : c’est une porte historique pour les attaques par force brute.
• Activer un pare-feu applicatif (WAF), chez ton hébergeur ou via un service tiers, pour filtrer les requêtes malveillantes avant qu’elles n’atteignent WordPress.
• Mettre en place une surveillance des fichiers : une alerte par email dès qu’un fichier est modifié en dehors d’une mise à jour. C’est ce qui aurait transformé un piratage découvert par un client en un piratage découvert dans l’heure.

WordPress.org publie un guide officiel de renforcement de la sécurité, en anglais, qui détaille chacun de ces points. Il vaut la peine d’être lu une fois le site remis sur pied.

Après 24 heures : Google, surveillance et clients

Le site est propre et durci. Reste à convaincre Google de retirer l’avertissement, à nettoyer les traces dans les résultats de recherche, à surveiller pendant les semaines qui suivent, et à informer les personnes concernées si des données ont été exposées.

Demander la révision à Google

Ouvre la Search Console, rubrique Sécurité et actions manuelles > Problèmes de sécurité. Google y décrit ce qu’il a détecté avec des exemples d’URL. Une fois le nettoyage vérifié, clique sur Demander un examen et décris précisément ce que tu as fait : cause identifiée, fichiers remplacés, base nettoyée, mesures de durcissement. La procédure officielle de demande de révision est documentée par Google Search Central. Le délai varie selon le type de problème ; une demande faite sur un site encore infecté est refusée, et chaque refus allonge le processus.

Nettoyer les résultats de recherche

Si des pages de spam ont été indexées, elles doivent renvoyer une erreur 404 ou 410 (elles n’existent plus, c’est le cas si tu as supprimé les faux articles). Utilise ensuite l’outil Suppressions de la Search Console pour accélérer leur retrait. Vérifie aussi que le site n’apparaît plus dans le rapport Safe Browsing de Google, et que ton domaine n’est plus dans les listes noires d’envoi d’emails.

Surveiller pendant 30 jours

Pendant un mois, fais un scan quotidien, regarde les fichiers modifiés chaque matin, surveille la liste des utilisateurs et les tâches planifiées. Une réinfection dans les premiers jours signifie qu’une porte dérobée a échappé au nettoyage : reprends le diagnostic à la section des heures 2 à 6, en ciblant les tâches cron et les autres sites du même hébergement. Ajoute un service de surveillance de disponibilité qui te prévient si le site tombe ou change brutalement.

Prévenir les clients si des données ont été touchées

Si le site stocke des comptes clients, des commandes, des réponses de formulaires, et que tu ne peux pas exclure qu’elles aient été lues ou copiées, informe les personnes concernées. Un message clair vaut mieux qu’un silence découvert plus tard : explique ce qui s’est passé, quelles données étaient concernées, ce que tu as fait, et ce qu’elles doivent faire (changer leur mot de passe, se méfier d’emails inhabituels). La section sur la loi 09-08, plus bas, précise le cadre marocain.

Nettoyer soi-même ou faire appel à un professionnel ?

Nettoyer un WordPress piraté soi-même est tout à fait faisable pour un site vitrine ou un blog, avec une sauvegarde fiable et quelques heures devant soi. Cela devient déraisonnable dès que le site fait vivre une activité ou détient des données de clients. Voici les quatre critères que je fais examiner honnêtement avant de conseiller l’un ou l’autre.

La compétence. Es-tu à l’aise avec un client FTP, phpMyAdmin et la lecture d’un fichier PHP ? Pas expert : à l’aise. Si ouvrir wp-config.php te fait peur, tu risques de casser plus que de réparer.

Le temps. Un nettoyage sérieux occupe une journée complète, parfois deux, avec de la concentration. Si tu dois le faire par bouts de vingt minutes entre deux clients, l’infection gagnera à l’usure.

Un site e-commerce en production. Chaque heure hors ligne coûte des ventes, et chaque erreur sur la base de données peut coûter des commandes. Sur une boutique WooCommerce, je déconseille l’auto-nettoyage sauf si tu as déjà de l’expérience.

Les données clients. Dès que des données personnelles sont en jeu, l’enjeu dépasse le site : il devient juridique et réputationnel. Un professionnel documente l’incident, ce qui compte si tu dois répondre à un client ou à la CNDP.

Ce que le professionnel doit te fournir, quel que soit son prix : la cause probable de l’intrusion, la liste de ce qui a été nettoyé, les mesures de durcissement appliquées, et une sauvegarde saine datée d’après l’intervention. Sans ce rapport, tu as payé pour un nettoyage que tu ne peux ni vérifier ni prolonger.

Site piraté et données personnelles : tes obligations au Maroc

Au Maroc, la loi n°09-08 relative à la protection des personnes physiques à l’égard du traitement des données à caractère personnel impose au responsable du traitement, donc au propriétaire du site, une obligation de sécurité : il doit prendre les mesures techniques et organisationnelles appropriées pour protéger les données contre l’accès non autorisé, la perte ou l’altération. Un site WordPress non mis à jour depuis un an, sans sauvegarde et avec un mot de passe partagé, se défend difficilement sur ce terrain.

Ce que je peux affirmer avec certitude : cette obligation de sécurité existe, la CNDP est l’autorité qui veille à son respect, et les traitements de données personnelles (comptes clients, newsletter, formulaires de contact avec fichier client) sont en principe soumis à une déclaration ou une autorisation préalable auprès d’elle.

Ce que je formule avec prudence : à ma connaissance, la loi 09-08 dans sa version actuelle ne fixe pas de délai chiffré de notification d’une violation de données comparable aux 72 heures du RGPD européen. Une réforme du texte est en discussion depuis plusieurs années. En l’absence de délai légal précis, la conduite que je recommande est celle qu’exigerait toute autorité : documenter l’incident (date, symptômes, données concernées, mesures prises, en conservant la copie infectée), informer rapidement les personnes concernées si leurs données ont pu être exposées, et se rapprocher de la CNDP pour l’en informer. Si tes clients incluent des résidents de l’Union européenne, le RGPD s’applique en plus, avec son délai de 72 heures pour notifier l’autorité compétente.

Point rassurant sur les paiements : une boutique marocaine qui passe par une passerelle de paiement (CMI ou un prestataire agréé) ne stocke pas les numéros de carte sur WordPress. Les données exposées en cas de piratage sont alors les noms, adresses, téléphones, emails et historiques de commande, ce qui reste des données personnelles au sens de la loi, mais pas des données bancaires.

Comment éviter le prochain piratage : la checklist post-incident

La grande majorité des sites que je nettoie ont été piratés pour l’une de ces raisons : une extension ou un thème non mis à jour depuis des mois, une extension nulled, un mot de passe réutilisé, un site abandonné mais toujours en ligne. La prévention tient donc en une routine et trois décisions.

La routine mensuelle

• Mises à jour du cœur, des extensions et des thèmes, après un test sur une copie de staging si le site est critique.
• Revue des utilisateurs : suppression des comptes inutiles, vérification des rôles.
• Vérification que les sauvegardes automatiques tournent et qu’une restauration test fonctionne (au moins une fois par trimestre).
• Lecture du rapport du scanner de sécurité et du journal des connexions.

Des sauvegardes 3-2-1

Trois copies de tes données (le site en production et deux sauvegardes), sur deux supports différents (le serveur de l’hébergeur et un stockage externe type cloud ou disque), dont une hors site, c’est-à-dire pas chez le même hébergeur. Une sauvegarde qui n’existe que dans le compte hébergeur disparaît avec lui en cas de suspension ou de compromission du compte. Conserve plusieurs générations (quotidienne, hebdomadaire, mensuelle) pour pouvoir remonter avant une infection silencieuse.

Un hébergeur qui fait sa part

Un bon hébergeur propose des sauvegardes quotidiennes conservées plusieurs semaines, une isolation entre les sites d’un même compte, un pare-feu, des versions de PHP à jour, et un support capable de fournir des logs en urgence. Ces critères pèsent autant que le prix dans mon comparatif des hébergeurs web au Maroc, précisément parce qu’ils changent tout le jour où quelque chose tourne mal.

Fermer proprement les sites abandonnés

Un site que tu n’utilises plus mais qui reste en ligne, sans mise à jour, est une cible facile et une menace pour les autres sites du même hébergement. Si tu ne comptes plus le maintenir, supprime-le correctement : mon guide pour supprimer un site web sur Hostinger détaille les étapes, y compris la sauvegarde préalable et le nettoyage des DNS.

Ce que tu dois faire maintenant

Si tu lis ce guide parce que ton site est infecté en ce moment : remonte à l’Heure 0, exporte la copie infectée, puis change tous les mots de passe dans l’ordre indiqué. Ces deux étapes te protègent quoi qu’il arrive ensuite. Si le site encaisse des paiements ou détient des données clients, ne va pas plus loin seul.

Les cinq points à retenir :

• Ne supprime rien et ne réinstalle rien avant d’avoir sauvegardé l’état infecté et sécurisé tous les accès.
• L’infection est à plusieurs endroits : fichiers, base de données, utilisateurs, tâches cron. Un nettoyage partiel ne tient pas.
• Remplace, ne répare pas : cœur, extensions et thème réinstallés depuis leurs sources officielles.
• Durcis le jour même : mises à jour, 2FA, permissions, comptes inutiles supprimés, clés régénérées.
• Documente et informe si des données personnelles ont pu être exposées ; la loi 09-08 t’y oblige indirectement, et tes clients te le pardonneront plus facilement qu’un silence.

Si tu préfères qu’un développeur s’en charge, contacte-moi pour un diagnostic gratuit de ton site WordPress piraté : décris les symptômes, envoie l’URL, et je te dis honnêtement ce que ça implique avant toute intervention.