# Nettoyer un site infecté : la méthode, et pourquoi restaurer ne suffit pas toujours

> Réinstaller une sauvegarde paraît être le raccourci le plus rapide, mais cette rapidité n’a de valeur que si la sauvegarde est réellement saine. Voici comment choisir entre nettoyage manuel ciblé et restauration, et pourquoi une infection ancienne rend ce choix plus difficile qu’il n’y paraît.

- Source canonique : [https://allaux.fr/securite/nettoyer-un-site-infecte](https://allaux.fr/securite/nettoyer-un-site-infecte)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Le choix dépend d’abord d’une question : depuis quand l’infection est-elle active, et une sauvegarde antérieure à cette date existe-t-elle avec certitude ? Sans réponse claire, un nettoyage manuel ciblé des fichiers et de la base reste plus fiable qu’une restauration qui peut simplement réinstaller le problème avec un temps de retard.

## Deux approches, une question à trancher avant tout

La restauration d’une sauvegarde remet le site dans l’état exact où il se trouvait à une date donnée. C’est rapide, mais cela n’est valable que si cette date précède le tout début de l’infection, pas seulement le moment où le problème a été remarqué : ce sont deux dates presque toujours différentes.

Le nettoyage manuel ciblé consiste à identifier précisément le code injecté, les comptes ou les accès ajoutés par l’attaquant, puis à les retirer sans repartir de zéro. Il demande davantage de temps d’investigation, mais il ne dépend pas de l’existence d’une sauvegarde saine.

Les deux approches ne s’opposent pas toujours : une sauvegarde ancienne et fiable peut servir de référence pour comparer les fichiers, même sans être utilisée telle quelle pour la remise en ligne.

## Un exemple documenté du décalage entre faille et découverte

En 2014, Sucuri a documenté la campagne connue sous le nom de SoakSoak, liée à une faille dans l’extension Slider Revolution pour WordPress. Le correctif avait été publié par l’éditeur dès février 2014, mais l’exploitation massive de cette faille n’a été observée qu’entre septembre et décembre de la même année, notamment via des thèmes qui embarquaient une copie obsolète de l’extension à l’insu du propriétaire du site.

Ce cas illustre un point simple : le moment où une infection est remarquée ne dit rien sur le moment où elle a réellement commencé. Une sauvegarde vieille de plusieurs semaines, voire de plusieurs mois, peut donc déjà contenir un code malveillant resté silencieux jusqu’à son activation.

## Le piège de la restauration partielle

> Une infection peut se loger à la fois dans les fichiers, avec du code injecté ou un fichier ajouté, et dans la base de données, dans des champs de contenu ou de configuration selon le CMS. Restaurer uniquement les fichiers, ou uniquement la base, en pensant avoir traité le problème, est une des erreurs les plus fréquentes : la partie non restaurée peut suffire à réinjecter l’infection dans l’autre dès la remise en ligne.

## Un endroit que la simple comparaison de fichiers ne couvre pas

Sous PrestaShop, comparer les fichiers du cœur à une installation propre de la même version repère les fichiers du cœur modifiés. Mais le système d’override, qui permet légitimement d’étendre une classe ou un contrôleur sans toucher au fichier d’origine, ne fait pas partie de cette comparaison automatique : un fichier placé dans override/ est censé contenir du code personnalisé, un override malveillant s’y fond donc sans déclencher d’écart évident. Ce dossier mérite une relecture ligne à ligne, pas seulement une comparaison automatisée.

## La méthode pas à pas, étape par étape

- **Vérifier si le site est encore compromis** — Les contrôles qui disent si l’infection est réellement partie, avant de considérer le nettoyage terminé. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Avant le nettoyage, les deux premières heures** — L’ordre exact des premières actions si la compromission vient d’être confirmée. ([/securite/que-faire-dans-les-deux-heures](/securite/que-faire-dans-les-deux-heures))
- **Après le nettoyage, ce qui doit changer** — Les habitudes structurelles qui évitent une récidive à court terme. ([/securite/se-proteger-apres-un-nettoyage](/securite/se-proteger-apres-un-nettoyage))

## FAQ

### Une sauvegarde vieille de plusieurs mois est-elle automatiquement fiable ?

Non. Elle n’est fiable que si elle précède le tout début de l’infection, ce qui est rarement connu avec certitude. L’ancienneté d’une sauvegarde donne une indication, pas une garantie.

### Faut-il restaurer les fichiers ou la base en premier ?

Aucun des deux isolément ne suffit. Une infection qui touche les deux ne disparaît pas si un seul côté est traité : les fichiers et la base doivent être vérifiés et, si besoin, restaurés ensemble.

### Comment savoir depuis quand mon site est infecté ?

Les dates de modification des fichiers donnent une première piste, à prendre avec précaution car elles peuvent être modifiées, tout comme l’historique des sauvegardes disponibles, les journaux d’accès s’ils ont été conservés, et le moment où les premiers symptômes ont été signalés par des clients ou par Google.

### Le nettoyage manuel demande-t-il de savoir coder ?

Oui, pour distinguer avec certitude du code légitime d’un code injecté, en particulier dans un dossier comme override/ où du code personnalisé est attendu. C’est pour cette raison que cette étape revient souvent à un développeur plutôt qu’à un outil de nettoyage automatique seul.

### Un scanner de nettoyage automatique peut-il remplacer un nettoyage manuel ?

Il peut retirer les signatures de malware déjà connues, mais il rate souvent le code sur mesure ou un override légitime détourné à des fins malveillantes. Utile en complément, pas en remplacement d’une vérification manuelle.