# Sécuriser sa boutique après un piratage : ce qui doit changer

> Un site nettoyé mais remis en ligne exactement comme avant retombe souvent dans le même état en quelques mois, parce que rien n’a changé dans la façon dont il est maintenu. L’ordre des opérations juste après l’incident compte, mais il referme seulement l’incident. Voici ce qui doit ensuite devenir une habitude, pas une action ponctuelle.

- Source canonique : [https://allaux.fr/securite/se-proteger-apres-un-nettoyage](https://allaux.fr/securite/se-proteger-apres-un-nettoyage)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Une politique de mise à jour régulière, une revue des accès et des mots de passe, la suppression des modules inutilisés, des sauvegardes testées et pas seulement programmées, un suivi des failles publiées sur ce qui est installé, et une surveillance en place : ce sont ces six habitudes, pas le nettoyage lui-même, qui réduisent fortement le risque de récidive.

## Avant les habitudes : l’ordre des premières opérations

Cette page suppose le nettoyage fait. S’il ne l’est pas encore, l’ordre compte autant que les opérations elles-mêmes : remettre une boutique piratée en ligne sans avoir traité la cause revient à laisser la porte ouverte, et l’infection revient en général en quelques jours.

Isoler la boutique : maintenance ou coupure temporaire, pour limiter la propagation et l’exposition des visiteurs pendant l’intervention.

Changer tous les mots de passe : administration du CMS, FTP/SFTP, base de données, panneau d’hébergement. Un seul accès laissé inchangé suffit à réinfecter le site après nettoyage.

Supprimer les comptes administrateurs inconnus : un compte créé par l’attaquant est l’une des portes dérobées les plus fréquentes, et il se retire avant même le nettoyage des fichiers.

Comparer les fichiers à une installation propre de la même version : les fichiers modifiés ou ajoutés sont la trace la plus directe d’une infection.

Vérifier la base de données : du code malveillant s’injecte aussi dans des champs de configuration ou de contenu, pas seulement dans les fichiers.

Mettre à jour l’ensemble des composants : la faille exploitée provient très souvent d’un composant obsolète.

Remettre en ligne, puis surveiller les journaux et l’activité des jours suivants, pour vérifier qu’aucune porte dérobée n’a été oubliée.

Cette séquence referme l’incident. Elle ne change rien à ce qui l’a rendu possible : c’est l’objet du reste de cette page.

| Valeur | Description |
|---|---|
| 39,1 % | des applications CMS compromises tournaient sur une version obsolète au moment de l’infection |
| 13,97 % | des sites compromis avaient au moins une extension ou un thème vulnérable au moment de la remédiation |

Source : Sucuri, Hacked Website & Malware Threat Report 2023

## Six habitudes structurelles

1. **Une politique de mise à jour, pas des mises à jour au coup par coup** — CMS, thème et modules ou extensions doivent être vérifiés à intervalle régulier, pas seulement quand un problème apparaît. Le rapport Sucuri cité plus haut montre qu’une version obsolète était impliquée dans plus d’un tiers des compromissions étudiées : c’est une corrélation constatée, pas une cause démontrée, mais elle suffit à en faire une priorité.
2. **Suivre les avis de sécurité de ce qui est installé** — Une faille publiée dans un module ou une extension laisse une fenêtre avant son exploitation réelle. Savoir où suivre ces publications selon le CMS utilisé change la donne pour agir avant d’être concerné.
3. **Supprimer ce qui n’est plus utilisé** — Un module désactivé mais toujours présent sur le serveur reste une porte d’entrée potentielle : la désactivation dans l’administration n’empêche pas l’exécution d’un fichier PHP appelé directement depuis son chemin.
4. **Revoir régulièrement les accès et les mots de passe** — Comptes administrateur créés « pour dépanner » et jamais supprimés, accès FTP donné à un ancien prestataire, mot de passe réutilisé ailleurs : une revue périodique de qui a accès à quoi referme des portes ouvertes sans qu’on s’en souvienne.
5. **Tester une sauvegarde, pas seulement la programmer** — Une sauvegarde qui existe mais n’a jamais été restaurée pour de vrai peut être incomplète, corrompue, ou sauvegarder l’infection elle-même sans le savoir. La tester périodiquement sur un environnement séparé est la seule façon de savoir qu’elle sera utilisable le jour où elle servira.
6. **Ajouter une surveillance ou un pare-feu applicatif** — Un pare-feu applicatif filtre une partie du trafic malveillant avant qu’il n’atteigne le CMS, et une surveillance de l’intégrité des fichiers signale une modification suspecte rapidement plutôt que des semaines plus tard. Aucun des deux ne remplace la mise à jour, mais les deux réduisent la fenêtre d’exposition.

## Ce qui complète cette démarche

- **Suivre les failles publiées sur ce que vous utilisez** — WPScan, avis officiels PrestaShop, NVD : où et comment surveiller ce qui vous concerne réellement. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))
- **Maintenance suivie plutôt que ponctuelle** — Mises à jour, sauvegardes testées et surveillance pris en charge en continu. ([/services/maintenance](/services/maintenance))
- **Les modules et extensions abandonnés** — Le premier vecteur réel d’intrusion, avant le mot de passe faible ou le serveur mal configuré. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Nettoyer un site infecté** — La méthode de nettoyage elle-même, et pourquoi restaurer une sauvegarde ne suffit pas toujours. ([/securite/nettoyer-un-site-infecte](/securite/nettoyer-un-site-infecte))
- **Faut-il prévenir les clients et la CNIL ?** — Ce que le règlement impose quand des données personnelles ont pu être exposées. ([/securite/dois-je-prevenir-mes-clients-et-la-cnil](/securite/dois-je-prevenir-mes-clients-et-la-cnil))

## FAQ

### Une sauvegarde suffit-elle si je ne la teste jamais ?

Non. Une sauvegarde jamais restaurée pour de vrai peut être incomplète ou corrompue sans que personne ne le sache, jusqu’au jour où elle est censée servir. La tester régulièrement fait partie de la sauvegarde elle-même, pas d’une étape optionnelle.

### Faut-il supprimer un module même s’il fonctionne encore ?

Oui, s’il n’est plus utilisé ou plus maintenu par son éditeur. Le risque ne dépend pas de si le module fonctionne encore, mais de si des correctifs de sécurité continuent d’être publiés pour lui.

### À quelle fréquence dois-je vérifier les mises à jour disponibles ?

De façon régulière, sans qu’un chiffre unique convienne à toutes les situations. Un déclencheur fiable est chaque avis de sécurité publié concernant un composant installé, ce qui suppose de suivre ces publications plutôt que d’attendre une alerte de l’hébergeur.

### Un pare-feu applicatif remplace-t-il les mises à jour ?

Non, il les complète. Il filtre une partie des tentatives d’exploitation, mais une faille non corrigée reste une faille : un pare-feu applicatif réduit l’exposition, il ne la supprime pas.

### Dois-je changer mes mots de passe même si rien d’anormal n’a été observé récemment ?

Oui, périodiquement, et systématiquement après tout accès partagé avec un tiers, un prestataire ou un ancien collaborateur qui n’a plus besoin d’y accéder.

### Google ou le navigateur avertit encore les visiteurs après le nettoyage, que faire ?

Une fois le nettoyage confirmé, une demande de réexamen se soumet depuis Google Search Console. Le délai de retrait de l’avertissement dépend ensuite du traitement de la demande. Tant que la faille d’origine n’est pas refermée, un nouveau signalement reste possible dans les jours qui suivent : c’est une raison de plus pour traiter la cause avant de demander le réexamen.