Un client vous signale un débit qu’il n’a pas fait. Ou Google affiche « site trompeur » à la place de votre boutique. Ou votre hébergeur vous coupe le serveur. Vous venez de comprendre que votre PrestaShop est piraté, et la première réaction est presque toujours la même : ouvrir le FTP et commencer à supprimer des fichiers au hasard.
Ne faites pas ça. Pas encore. L’ordre dans lequel vous agissez dans les prochaines heures compte plus que la vitesse. Une intervention désordonnée détruit les preuves, laisse la porte d’entrée ouverte, et vous condamne à recommencer dans trois jours.
Voici la procédure, dans l’ordre. Elle est écrite pour être suivie de haut en bas.
1. Ne supprimez rien tout de suite : sauvegardez l’état compromis
C’est contre-intuitif, et c’est pourtant le premier geste. Avant toute modification, faites une copie complète de la boutique dans son état infecté : les fichiers et la base de données.
Deux raisons. D’abord, ces fichiers vérolés sont vos preuves — pour comprendre l’attaque, pour votre assurance, et pour une éventuelle plainte. Ensuite, c’est votre filet : si vous cassez quelque chose en nettoyant, vous pourrez repartir de cette copie plutôt que de tout perdre.
Stockez cette sauvegarde hors du serveur, sur votre machine ou un disque externe. Et ne la restaurez jamais telle quelle : elle est infectée. Elle sert d’archive, pas de point de retour.
2. Coupez l’hémorragie : le paiement d’abord
Si l’attaque vise les cartes bancaires — et c’est le cas le plus fréquent en 2026 avec la vague de skimmers — chaque minute où la boutique reste en ligne, ce sont des numéros de cartes volés en temps réel.
Le réflexe n’est pas forcément de fermer toute la boutique. C’est de neutraliser le paiement : désactivez vos modules de paiement depuis le back-office, ou basculez la boutique en mode maintenance. Un client qui ne peut pas payer est frustré ; un client dont vous laissez voler la carte est un préjudice que vous devrez assumer.
Si vous avez le moindre doute sur l’ampleur, le mode maintenance complet est le choix prudent le temps du diagnostic.
3. Reprenez le contrôle des accès
Un attaquant qui est entré a presque toujours laissé de quoi revenir. Tant que vous n’avez pas fermé ces portes, changer votre mot de passe ne sert à rien.
Dans l’ordre :
- Supprimez les comptes administrateurs que vous ne reconnaissez pas. Ouvrez la liste des employés dans le back-office et vérifiez chaque compte. Un accès administrateur créé par l’attaquant est sa clé de secours.
- Changez tous les mots de passe : back-office, base de données, FTP et SSH, et le compte de votre hébergeur lui-même.
- Révoquez les clés SSH que vous ne reconnaissez pas.
- Vérifiez les tâches planifiées (cron), côté PrestaShop comme côté hébergeur. Une tâche qui télécharge et exécute du code distant réinstalle le malware toute seule, même après nettoyage.
4. Identifiez la porte d’entrée avant de nettoyer
C’est l’étape que la panique fait sauter, et c’est celle qui détermine tout le reste. Nettoyer sans savoir par où l’attaquant est passé, c’est colmater une fuite sans fermer le robinet.
La charge utile n’est d’ailleurs souvent pas dans les fichiers. Sur PrestaShop, elle est fréquemment injectée en base de données — dans les champs de configuration, dans une page CMS, ou dans un module désactivé mais toujours accroché à un hook. C’est ce qui explique qu’une boutique « nettoyée » se retrouve infectée quelques jours plus tard. J’ai détaillé les emplacements exacts et les requêtes SQL pour les inspecter dans un guide dédié : pourquoi votre PrestaShop se ré-infecte après nettoyage.
Et si l’attaque touche la page de paiement, elle a peut-être une particularité vicieuse : le skimmer 2026 se désactive quand vous êtes connecté au back-office. Vérifier votre boutique en tant qu’administrateur ne prouve donc rien — testez-la comme un client, en navigation privée.
Localiser l'infection avant de nettoyer
Genisoft Security Scanner inspecte les fichiers et la base de données, dé-obfusque les payloads cachés et vous remet un rapport avec les chemins et les empreintes SHA-256. C'est le diagnostic qui rend le nettoyage possible — il ne supprime rien lui-même. 100 % lecture seule.
5. Nettoyez, dans le bon ordre
Une fois la porte d’entrée identifiée et les accès repris, seulement là, vous nettoyez.
Neutralisez d’abord la persistance en base — désactivez les tâches cron suspectes avant de les supprimer. Puis comparez les fichiers du cœur avec l’archive officielle de votre version exacte, téléchargée depuis prestashop.com : toute différence non expliquée est suspecte. Les modules tiers, réinstallez-les depuis leur source d’origine plutôt que de les rafistoler — un module compromis rafistolé reste compromis.
Ne considérez pas le travail terminé le jour même. Une ré-infection se manifeste rarement dans l’heure. Reprenez vos vérifications à 48 heures, puis à une semaine. Tant que vous n’avez pas passé sept jours sans rechute, ce n’est pas fini.
6. Vos obligations légales : la CNIL sous 72 heures
C’est l’étape que la plupart des commerçants ignorent, et elle n’est pas optionnelle.
Si des données personnelles de vos clients ont été exposées — et des numéros de carte bancaire en font partie — vous êtes face à une violation de données personnelles au sens du RGPD. La loi vous impose de la notifier à la CNIL dans les 72 heures.
Trois précisions qui comptent :
- Le délai court à partir du moment où vous prenez connaissance de la violation, pas du jour de l’attaque. Et il court week-ends et jours fériés compris.
- Un piratage impliquant des données bancaires est considéré comme un risque élevé : dans ce cas, vous devez aussi informer les clients concernés.
- Le non-respect de cette obligation est un manquement sanctionnable, en théorie jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires. En pratique, la CNIL distingue nettement l’entreprise qui déclare de bonne foi de celle qui a caché l’incident.
Prévenez également votre prestataire de paiement : Stripe, PayPal et les autres ont des procédures pour ces situations, et peuvent vous accompagner. Ne restez pas seul avec l’incident.
7. Levez l’alerte Google « site trompeur »
Si Google a détecté le malware, votre boutique affiche probablement un avertissement rouge « site trompeur » dans Chrome, et vous avez disparu des résultats de recherche. C’est brutal pour le chiffre d’affaires, mais réparable.
Une fois la boutique réellement propre — pas avant, sous peine de rejet — ouvrez la Google Search Console, section Problèmes de sécurité, et demandez un examen. Google recontrôle votre site et lève l’avertissement s’il est effectivement nettoyé. Le délai est généralement de quelques jours. Demander l’examen sur un site encore infecté vous fait perdre ce temps et retarde la levée : assurez-vous d’abord que le nettoyage est complet.
Et après : ne pas y revenir
La cause d’entrée de la plupart des piratages PrestaShop n’a rien d’exotique : un module tiers laissé sans mise à jour, un thème abandonné, un accès administrateur trop faible. Une fois la crise passée, les gestes qui évitent la récidive sont connus :
mettre à jour vite, en priorité les modules tiers ; désinstaller — pas seulement désactiver — ce qui ne sert plus ; activer l’authentification à deux facteurs sur le back-office ; garder des sauvegardes hors-ligne testées ; et surveiller régulièrement ce qui tourne réellement sur la boutique, fichiers comme base de données.
Si vous êtes dépassé, c’est normal
Cette procédure suppose du temps, du sang-froid et un minimum d’aisance technique. Si l’un des trois vous manque au moment où votre gagne-pain est en jeu, déléguer n’est pas un aveu de faiblesse — c’est souvent le choix le plus rapide et le moins coûteux.
Vous pouvez confier le diagnostic à votre développeur habituel : le rapport du scanner lui donne tout ce qu’il faut. Ou faire appel à quelqu’un dont c’est le métier — j’interviens moi-même sur les boutiques PrestaShop compromises ou en panne. Dans tous les cas, la pire décision est l’immobilisme : une boutique piratée qui reste en ligne ne fait qu’aggraver le préjudice, heure après heure.
Pour aller plus loin :