Profiter du piratage pour refondre le site : mauvaise idée

Pourquoi le mélange est tentant le jour J

Le site est moche, le thème date de 2018, l'agence a disparu, et maintenant il est pirate. L'idée « autant tout refaire » paraît économique. Elle l'est sur le papier. En pratique, vous empilez un projet de plusieurs semaines sur un incident qui se mesure en jours — et vous ne saurez plus si la redirection mobile vient encore du shell ou du nouveau builder.

La refonte a un critère de succès : le nouveau design est en ligne, les contenus migrés. Le nettoyage en a un autre : plus personne d'autre que vous n'écrit sur le serveur. Quand les deux critères se mélangent, on livre souvent le premier et on oublie le second.

Dans les dossiers que nous reprenons, le site « neuf » a déjà renvoyé vers une pharmacie à J+4. Le constructeur était joli. Le mu-plugin de l'ancien compte était toujours là. Voir le guide des premiers gestes : on constate et on copie avant de reconstruire.

Ce que la refonte cache pendant qu'on « en profite »

Changer de thème pendant l'infection jette parfois le fichier visible — et laisse la cron, l'utilisateur FTP, le voisin de dossier. Réinstaller WordPress « à neuf » sur le même panel recopie souvent `wp-content` sale, ou la base déjà injectée. Vous avez l'impression d'avancer parce que la home a changé.

Les journaux et les dates de modification, eux, se noient dans le bruit d'une migration Elementor. Quand il faudra dater une éventuelle fuite, vous aurez un chantier de refonte, pas un état des lieux.

L'attaquant, lui, n'est pas gêné par un nouveau logo. Il revient par le même mot de passe de panel, le même add-on abandonné, le même `.env` à la racine. La refonte n'est pas une fermeture.

• Le nouveau thème n'efface pas un cron système.
• Le nouvel hébergeur n'efface pas une sauvegarde Updraft déjà infectée si vous la restaurez.
• Le nouveau nom de dossier n'efface pas un utilisateur admin fantôme.

Deux définitions de « c'est fini »

Fin du nettoyage : le site légitime répond, les URL de phishing sont mortes (404/410, pas un 200 de maintenance), les accès sont tournés, le test mobile et l'inspection Search Console collent à ce que vous voyez. C'est mesurable en heures et en jours.

Fin de la refonte : maquettes validées, contenus repris, redirections 301 des anciennes URL, formulaires testés, emails transactionnels. C'est mesurable en semaines. Coller les deux dans un seul jalon (« on ouvre le nouveau site propre ») produit un ouverture tardive avec des portes encore ouvertes — ou une ouverture rapide avec un site à moitié migré.

Si Chrome affiche encore « site trompeur », aucun lancement de nouveau thème ne sert. Traitez la blacklist sur le domaine actuel, propre, avant de parler de design.

L'ordre qui tient : propre, puis neuf

On ferme l'entrée sur le site actuel. On remet ce site en ligne, même avec son vieux thème. Les clients retrouvent une vitrine qui ne les ment pas. Ensuite seulement, on bascule une refonte depuis une copie saine — pas depuis le zip du jour de l'attaque.

La copie hors serveur prise le jour J reste la référence. La refonte s'alimente des contenus légitimes, pas de l'archive cPanel de la suspension. Restaurer « la dernière sauvegarde » pour servir de base au nouveau site ramène souvent le payload, comme dans sauvegarde Updraft déjà infectée.

Si vous changez d'hébergeur, vous migrez un site déjà nettoyé. Copier le compte sale « pour avancer la refonte ailleurs » brûle parfois le nouveau panel en 24 heures. L'ordre est le même que pour changer d'hébergeur encore infecté.

Exceptions étroites : cœur mort, thème nulled

Trois cas rapprochent les deux projets, sans les fusionner. Un PrestaShop 1.6 dont le cœur n'est plus patchable : le plan de montée de version fait partie de la fermeture, mais c'est une migration technique, pas une refonte graphique. Voir PrestaShop 1.6 / 1.7 obsolète.

Un thème « premium gratuit » déjà truffé : on le remplace par un thème officiel, le plus simple possible, pour refermer. Ce n'est pas l'occasion de tout redessiner. On change le tuyau, pas le magasin.

Un site dont le code métier n'existe plus que dans la tête d'un freelance introuvable : là, reconstruire peut être le seul chemin. On le dit. On le chiffre à part. On ne le déguise pas en « nettoyage complet ».

Ce que ça change pour Google et les clients

Une refonte change les URL, les titres, les temps de chargement. Google doit tout réapprendre. Si vous lui demandez ça pendant qu'un générateur de spam tourne encore, vous mélangez deux chocs d'indexation. Les positions mettent plus longtemps à revenir que l'alerte rouge à disparaître.

Vos clients, eux, veulent savoir si le site est sûr, pas si le slider a changé. Un bandeau ou un mail factuel (« incident traité, site de nouveau le nôtre ») suffit. Une page « bientôt notre nouveau site » pendant que Chrome bloque donne l'impression inverse.

Changer de nom de domaine « pour le nouveau site » le jour du piratage ajoute une quatrième horloge. C'est rarement la solution : nouveau domaine après piratage.

Deux devis, deux prestataires possibles

Le nettoyeur et l'agence de refonte n'ont pas le même métier. Les faire jouer le même rôle produit des trous : l'agence « réinstalle », le nettoyeur « refait la home ». Un devis de nettoyage lisible exclut la refonte. Un devis de refonte exclut la chasse au webshell.

Vous pouvez garder la même équipe pour les deux, à condition que les jalons et les prix soient séparés. Sinon le moins urgent (le dégradé du header) mange le plus urgent (le checkout).

Les accès aussi se séparent. Le graphiste n'a pas besoin du panel le jour de l'incident. Le nettoyeur n'a pas besoin de Figma. Voir quels accès demander.

Décider ce soir, sans tout reconstruire

Ce soir : copie hors serveur, mots de passe de panel, ticket hébergeur, test visiteur. Pas de nouveau thème. Pas de nouveau builder. Pas de « je profite pour passer en Gutenberg ». Si une URL de phishing est en ligne, on la tue, on ne la « range » pas dans la future arborescence.

Demain : nettoyage ou délégation. La semaine suivante, si le site est stable : brief de refonte sur une base que vous savez propre. Cet écart de quelques jours n'est pas du luxe. C'est ce qui évite de reconstruire sur du sable.

Si le vieux site est vraiment inutilisable (rançon, fichiers chiffrés), on restaure un point propre, on referme, puis on parle de neuf. Restaurer et refondre dans le même geste, c'est le scénario où plus personne ne sait ce qui a été emporté.