PrestaShop 1.6 ou 1.7 non maintenu : le risque n'est plus théorique

Ce que « ça marche encore » veut dire

La boutique encaisse, le thème est connu des équipes, le module de transport est « le seul qui parle à notre transitaire ». Tout ça est vrai. Ça ne dit pas que le cœur reçoit encore des correctifs de sécurité. Une faille documentée n'a pas besoin que votre boutique soit célèbre. Les bots la testent en volume.

PrestaShop 1.6 est hors support depuis longtemps. La 1.7 l'est devenue pour les branches anciennes. « On est en 1.7.8 » n'est plus un argument de 2022. Vérifiez la branche exacte et la date de fin de vie, pas le slogan de l'agence.

Rester, c'est acceptable comme risque assumé — chiffré, écrit, avec une date de sortie. Rester « en attendant » sans date, c'est le scénario du prochain incident. Nous le voyons plus souvent que les mises à jour réussies du premier coup.

Nettoyer un cœur que plus personne ne patche

On compare aux zips de la version installée, on retire les ajouts, on ferme les employés fantômes, on tourne les secrets. Le site peut redevenir propre. Il ne redevient pas maintenu. La même entrée publique reste ouverte demain matin.

C'est pour ça que le plan de montée fait partie de la clôture, pas d'un « plus tard si on a le budget ». Le plus tard arrive après le deuxième skimmer. Voir PrestaShop piraté pour l'ordre boutique (tunnel, employés, modules).

Réinstaller un 1.6 « vierge » et recoller `modules` et `override` ramène souvent la porte. Le geste « cœur neuf, extensions vieilles » est un théâtre.

La montée de version n'est pas une refonte

Passer 1.6 → 8 (ou 1.7 → 8/9) est une migration technique : données, modules compatibles, thème à recoller ou à remplacer par un thème supporté. Ce n'est pas l'occasion de tout redessiner. Mélanger les deux, c'est le piège déjà décrit pour WordPress : refonte et nettoyage.

Deux projets, deux devis, deux fins. Fin sécurité : plus d'entrée connue, accès tournés. Fin migration : catalogue et commandes intacts sur un cœur supporté. La seconde peut suivre la première de quelques semaines. Elle ne la remplace pas le soir J.

Un prestataire qui vend « on vous refait la boutique, comme ça plus de 1.6 » sans phase de nettoyage copie souvent le sale vers le neuf.

Modules : le second musée

Le cœur n'est qu'une pièce. Les modules 1.6 non portés, les overrides, le thème enfant maison : c'est là que vivent les skimmers et les backdoors. Un module Stripe « trouvé » plutôt qu'Addons est un cas à part. Stripe officiel vs nulled.

Listez ce qui n'a plus de fiche Addons, plus de mainteneur, plus de compatibilité 8. Ces modules ne montent pas. Ils se remplacent ou ils s'abandonnent (la fonction avec). Les garder « désactivés » sur le disque d'un 1.6 encore en ligne n'est pas une stratégie.

Le webservice et les clés : relisez après incident. Clés webservice.

• Modules hors Addons / sans update.
• Overrides dans `/override` non documentés.
• Thème dont l'éditeur a fermé.

Boutique, PCI, et le discours aux clients

Si le checkout a pu être touché, le prestataire de paiement et, selon les cas, les clients, s'informent avec des dates. Un cœur obsolète n'est pas une preuve de vol de cartes. C'est un contexte qui rend le vol plus facile. Le constat dit ce qui a été vu. Fuite / obligations, informer la banque.

Ne promettez pas « on est en 1.7 donc PCI ». PCI n'est pas un numéro de CMS. Ne promettez pas non plus que la montée de version « efface » un incident déjà passé.

Une page « paiement sécurisé » pendant que le 1.6 reste ouvert est un discours marketing, pas une fermeture. Mentions paiement.

Migrer après, pas pendant le feu

Pendant l'incident : copie, tunnel isolé si besoin, nettoyage, accès, listes. La boutique peut rester en 1.6 propre quelques semaines si le risque est écrit et le filet (WAF, surveillance) posé. Pendant, on ne « profite pas » pour changer de thème et de transporteur.

La migration se fait depuis une copie saine, sur un préprod, avec un plan de bascule. Restaurer la dernière sauvegarde 1.6 sale comme base de 8, c'est emporter le shell. Sauvegarde déjà infectée — le principe vaut hors WordPress.

Même compte d'hébergement qu'un WordPress vitrine : inspectez les deux. WP + Presta sur le même panel.

Ce que le devis doit séparer

Ligne 1 : nettoyage et constat (fichiers, base, employés, modules, éventuellement blacklist). Ligne 2 : lot de migration chiffré, avec les modules à remplacer. Ligne 3 : ce qui n'est pas inclus (nouvelle identité graphique, nouvelles features). Un devis lisible tient ces colonnes.

Un forfait unique « remise à niveau PrestaShop » mélange les horloges et les responsabilités. Quand ça casse, plus personne ne sait si c'est le malware ou le migrateur.

Nous nettoyons. Nous pouvons dire si une 1.6 est tenable quinze jours. Nous ne vendons pas une refonte 8 déguisée en antivirus.

Décider le niveau de risque, par écrit

Trois issues honnêtes. On migre à court terme (semaines). On ferme la boutique le temps de reconstruire. On reste, avec un écrit : pas de correctifs cœur, surface connue, surveillance renforcée, date de réexamen. La quatrième — rester sans écrit — n'est pas une issue. C'est un oubli.

Pour une TPE, le coût de la migration fait peur. Le coût d'un skimmer et d'une semaine Ads coupée aussi. Posez les deux chiffres. Décidez. Créer un compte pour le nettoyage n'implique pas la migration chez nous.

L'assureur et le prestataire de paiement comprennent un plan daté. Ils comprennent mal « on verra après Noël » en août, puis en janvier, puis encore.