Maintenance d’une boutique PrestaShop 1.6 ou 1.7 en 2026

Votre boutique tourne encore en PrestaShop 1.6 ou 1.7. Les commandes arrivent, les paiements passent, le thème payé il y a des années tient toujours. Elle marche, personne ne le conteste. Reste à savoir ce qu’elle vous coûte à garder, et pour combien de temps.

Sur la maintenance PrestaShop 1.6 et 1.7, on vous dit soit de migrer tout de suite, soit que rien ne presse. La réponse dépend de votre version exacte et de votre hébergeur. Cette page donne l’état exact des deux branches au 26/09/2026, les risques sourcés, ce que coûte une maintenance, et quand arrêter.

Où en sont PrestaShop 1.6 et 1.7 en 2026

Trouver votre version en 30 secondes

Dans le back-office, ouvrez Paramètres avancés > Informations. La page affiche la version de PrestaShop et celle de PHP : c’est le couple qui compte. Cherchez votre ligne ci-dessous.

La frise ci-dessous remet ces dates dans l’ordre : la branche perd ses correctifs, puis son PHP perd les siens.

<a href="https://cyberial.fr/maintenance-prestashop-1-6-1-7/"><img src="https://cyberial.fr/wp-content/uploads/prestashop-1-6-1-7-dates-fin-de-support-2026.png" alt="PrestaShop 1.6 et 1.7 en 2026 : les dates qui comptent" /></a><p>Source : <a href="https://cyberial.fr/maintenance-prestashop-1-6-1-7/">Maintenance PrestaShop 1.6 et 1.7 en 2026</a> - CYBERIAL</p>

En pratique, une 1.6 tourne au mieux sur un PHP sans correctif depuis près de 7 ans, une 1.7.8 depuis près de 4 ans. Le jour de la fin du support, rien ne casse. Ensuite, chaque avis publié allonge la liste.

Les failles qui ne seront plus corrigées pour vous

Depuis le 10/06/2025, fin de vie de PrestaShop 1.7, les correctifs du cœur ne sortent plus qu’en 8.2 et en 9. Le 18/08/2026 encore, la 8.2.8 et la 9.1.5 en ont corrigé cinq d’un coup (annonce officielle). Il n’y aura pas de 1.7.8.12. Celles qui touchent une 1.6 ou une 1.7 :

• CVE-2022-31181, critique (9.8), juillet 2022 : une injection SQL enchaînée à une exécution de code via le cache Smarty, exploitée en masse pour poser des skimmers. 1.7 : corrigée en 1.7.8.7. 1.6 : aucun correctif ; seul contournement, supprimer les lignes 40 à 43 de config/smarty.config.inc.php, celles du cache Smarty en base (avis GitHub, annonce PrestaShop).
• CVE-2026-44212, critique (9.3), mai 2026 : un script glissé dans le champ e-mail du formulaire de contact s’exécute dans la vue SAV du back-office, jusqu’à sa prise de contrôle. Corrigée en 8.2.6 et 9.1.1 (avis GitHub), ni en 1.6 ni en 1.7 : d’après notre lecture du code, la ligne en cause est présente dans la 1.6.1.24 comme dans la 1.7.8.11.
• CVE-2025-51586, gravité moyenne, septembre 2025 : la réinitialisation du mot de passe du back-office laisse deviner les e-mails des employés, et PrestaShop a observé des sondages automatisés (annonce). Touche la 1.7 (et la 8 avant la 8.2.3) ; le code vulnérable est toujours là dans la 1.7.8.11 (avis GitHub).
• ps_facetedsearch, CVE-2026-54159, note maximale (10.0), juin 2026 : exécution de code sans authentification dans le module de recherche à facettes. La version corrigée, 4.0.4, exige la 1.7.7 ; de la 1.7.0 à la 1.7.6, il faut patcher une ligne à la main dans src/Filters/Block.php. La 1.6 n’est pas concernée, elle utilise blocklayered (avis GitHub).
• productcomments, 11/09/2026 : injection SQL dans le back-office (il faut un compte connecté), corrigée en 8.0.1, une version qui exige la 1.7.8 (avis GitHub).
• Les modules tiers : Friends of Presta signale environ 45 avis de modules « activement utilisés » pour déployer des skimmers de cartes bancaires. Exemple : jmsblog, sans version corrigée de son auteur (avis Friends of Presta). Pour certains modules, la 1.6 reste sans correctif de l’éditeur.

Un <script> inconnu dans _partials/head.tpl (fichier des thèmes 1.7 et suivants) figure parmi les indices donnés par PrestaShop dans son alerte de sécurité du début 2026. Si vous en trouvez un, lisez d’abord notre guide boutique PrestaShop piratée.

PHP 7.1 / 7.4 et hébergeur : le risque qui fait tomber une 1.6 ou 1.7 du jour au lendemain

Une faille se contourne souvent à la main. Un changement de PHP chez l’hébergeur tombe à une date que vous ne choisissez pas. Une 1.6 ou une 1.7.0 à 1.7.4 ne dépasse pas PHP 7.1, une 1.7.5 ou 1.7.6 s’arrête à 7.2, une 1.7.7 à 7.3, et PrestaShop 1.7 s’arrête à PHP 7.4 (en 1.7.8). Sur une 1.6, les correctifs de compatibilité avec PHP 7.1 ont continué jusqu’à la 1.6.1.20 : une 1.6 plus ancienne peut casser en 7.1. Testez tout changement de PHP sur une copie.

Le jour où l’hébergeur retire la version dont elle a besoin, la boutique affiche en général une erreur 500 ou une page blanche. Ne basculez pas non plus en PHP 8 pour prendre de l’avance : aucune 1.6 ni 1.7 ne l’accepte.

IONOS fait payer le temps gagné : 15,62 € HT par mois pour rester en 7.4, soit 187,44 € HT par an. Des correctifs payants existent aussi pour les PHP en fin de vie, comme TuxCare ou l’alt-php « hardened » de CloudLinux qu’utilise o2switch. Ils corrigent PHP et rien d’autre : le cœur et les modules n’en profitent pas.

Votre hébergeur retire PHP 7 ? CYBERIAL héberge aussi des boutiques en 1.7 et 1.6 sur d’autres serveurs, avec des configurations adaptées à chaque version. L’hébergement est une option du forfait maintenance : dès 30 € HT/mois en plus des 69 € HT. Le transfert de la boutique vers nos serveurs est alors gratuit (migration d’hébergement, dans la même version). Détail sur la page hébergement PrestaShop.

Paiement : les modules qui décrochent

Le troisième risque avance plus lentement : votre module de paiement cesse de sortir des versions pour votre branche, en général sans annonce.

• PrestaShop Checkout : la v5 couvre les 1.7, 8 et 9. La branche pour la 1.6 est marquée « deprecated », dernier commit le 23/01/2025 (dépôt officiel).
• PayPal, module officiel de 202 ecommerce : la branche 6.x exige la 1.7. La branche 3.x, pour la 1.5 et la 1.6, a corrigé une injection SQL critique en 3.16.4 (CVE-2023-28843, mars 2023) ; sa dernière version reste la 3.18.1 du 02/08/2024. Aucune annonce d’arrêt, c’est un constat (dépôt).
• Mollie : la version pour la 1.6 est figée depuis la 4.5.4 du 18/07/2023 ; la v5 (1.7.0 à 1.7.5), depuis la 5.4.3 du 10/03/2025. La v6 part de la 1.7.6 (dépôt).
• PayPlug : la 5.1.0 du 12/08/2026 exige la 1.7, et il n’existe aucune branche 1.6 (dépôt).
• Stripe : l’ancien module stripe_official de 202 ecommerce est archivé, son développement arrêté depuis le 09/01/2023 (dépôt).

Côté PCI-DSS, la contrainte s’est plutôt allégée. Si le paiement se fait par redirection ou dans un iframe (SAQ A), le PCI SSC a retiré le 30/01/2025 les exigences sur les scripts de la page de paiement, remplacées par une condition : le site ne doit pas être exposé aux attaques par script (annonce du PCI SSC). Sur un cœur sans correctif, c’est ce point qu’il faut pouvoir défendre.

Ce qu’une maintenance 1.6 / 1.7 sérieuse doit faire

Nous tenons dix points sur une vieille branche ; le tableau dit ce qu’ils donnent selon la version.

Votre hébergeur s’occupe du serveur, pas de la boutique : le cœur, les modules et le thème restent à votre charge. La faille ps_facetedsearch de juin 2026, par exemple, se corrige dans la boutique : module en 4.0.4, ou patch manuel sous la 1.7.7.

Sécuriser une PrestaShop 1.6 : ce que nous faisons

Sur une 1.6, nous ne promettons aucun correctif du cœur. Nous fermons ce qui peut l’être :

• le contournement de CVE-2022-31181, s’il n’a jamais été appliqué ;
• les fichiers à risque retirés : dossier install/, copies de PHPUnit laissées par d’anciens modules (CVE-2017-9841, exécution de code à distance), modules désactivés mais jamais supprimés ;
• les modules à leur dernière version compatible, et les patchs de Friends of Presta quand l’éditeur n’en publie pas ;
• PHP 7.1, le plus haut que la 1.6 accepte, et les mêmes sauvegardes, la même surveillance et, sur nos serveurs, le même scan nocturne que sur une 1.7.

Notre avis : ce durcissement sert à gagner les quelques mois nécessaires pour préparer la reconstruction.

À vérifier vous-même cette semaine

• 1.6 : dans config/smarty.config.inc.php, le bloc de 4 lignes qui commence par if (Configuration::get('PS_SMARTY_CACHING_TYPE') == 'mysql') et finit par } supprimé (lignes 40 à 43 en 1.6.1.24 ; gardez une copie du fichier avant) ; aucun dossier install/ ni copie de phpunit sur le serveur ; PayPal, si vous l’utilisez, en 3.18.1 ; date de retrait de PHP 7.1 demandée à l’hébergeur.
• 1.7.0 à 1.7.6 : la ligne de src/Filters/Block.php patchée (ps_facetedsearch), puis passage en 1.7.8.11, sur une copie et en PHP 7.1.3 au moins. Dans l’Update Assistant, choisissez « Archive locale » avec le zip et le xml de la 1.7.8.11 (page GitHub de la version) : sinon, il peut proposer une 8, qui peut casser le thème et des modules.
• 1.7.7 et 1.7.8 : ps_facetedsearch en 4.0.4 ou plus ; en 1.7.7, passage en 1.7.8.11 avec l’Update Assistant, d’abord sur une copie, en « Archive locale » ; en 1.7.8, productcomments en 8.0.1.

Erreur « StartTag: invalid element name » dans country_module_list.xml (1.6 et 1.7)

En 1.6 et jusqu’à la 1.7.6, ce message peut s’afficher en haut de presque toutes les pages du back-office : en anglais en 1.6, même sur un back-office en français (« Error found : StartTag: invalid element name in country_module_list.xml file. »), en français en 1.7 (« Erreur : StartTag: invalid element name dans le fichier country_module_list.xml. »), souvent avec la même ligne pour must_have_module_list.xml. Il a disparu en 1.7.7. La boutique vend toujours : seules les listes venues d’Addons sont touchées (modules recommandés, catalogue de la page Modules et, en 1.6, mises à jour annoncées dans cette page).

La cause, lue dans le code de la 1.6.1.24 et de la 1.7.6.9 : PrestaShop télécharge ces listes depuis Addons et les garde 24 heures dans config/xml/, sous les noms default_country_modules_list.xml et must_have_modules_list.xml (country_module_list.xml n’existe que dans le message). S’il a reçu autre chose que du XML, il l’affiche en erreur à chaque page, puis réessaie au bout de 24 heures : si Addons répond bien d’ici là, le message disparaît seul.

Pour ne pas attendre : téléchargez une copie du dossier config/xml/ sur votre ordinateur, puis, par FTP, renommez ces deux fichiers en ajoutant .old à la fin et rechargez une page du back-office. PrestaShop les télécharge à nouveau. Vérifiez par FTP qu’ils sont revenus et ne pèsent pas 0 octet. Pour revenir en arrière, supprimez les fichiers recréés et redonnez leur nom aux deux .old.

Où s’arrêter : si l’erreur revient, si les fichiers pèsent 0 octet ou si le back-office ralentit (chaque page attend alors Addons plusieurs secondes), votre serveur n’obtient pas de réponse correcte d’Addons. Demandez à votre hébergeur s’il peut joindre https://api.addons.prestashop.com en sortie, en joignant le début d’un .old ouvert dans un éditeur de texte : il montre ce que le serveur a reçu. Passez aussi une commande test si votre module de paiement appelle un service extérieur. Remettre les .old ne rend que l’état d’avant, jusqu’au téléchargement suivant. Pour cette erreur, ne modifiez pas le code de PrestaShop.

Combien coûte « garder » une 1.6 ou une 1.7

Même sans facture de maintenance, une vieille branche se paie : surcoût d’hébergeur, ou incident. Montants relevés ou estimés, avec leurs limites :

Pourquoi un tel écart ? L’offre à 350 € comprend un serveur et un pare-feu applicatif. Notre forfait entretient la boutique sans la refaire ; l’hébergement chez nous s’y ajoute en option, dès 30 € HT/mois. La migration de version se chiffre à part (voir plus bas).

La dernière ligne du tableau pèse le plus lourd. Une boutique piratée et fermée ne vend plus, et 60 % des acheteurs en ligne français disent qu’ils cesseraient d’acheter chez un marchand victime d’une cyberattaque (Akamai/YouGov, 2022). Si un code espion vole les cartes de vos clients, la pénalité de Visa démarre à 5 000 $ par incident et peut monter à 100 000 $ (Visa, 2026), sans compter l’enquête, le nettoyage et l’information des clients. Si c’est déjà arrivé, commencez par notre procédure de nettoyage d’une boutique PrestaShop piratée.

Quand arrêter : les 5 signaux, et vers quoi aller

Si la migration est prévue dans six mois, la maintenance sert de pont et s’arrête le jour de la bascule. Pour fixer ce jour, surveillez cinq signaux :

1. votre hébergeur annonce la fin de PHP 7, ou commence à la facturer ;
2. votre module de paiement ne sort plus de version pour votre branche ;
3. la boutique a été piratée, ou le scan d’intégrité s’allume ;
4. un correctif de module exige une version plus récente que la vôtre ;
5. un projet, comme la facturation électronique ou un nouveau module, demande une version récente.

Depuis une 1.7, nous visons la 9.1 en passant par la 8.2, en un seul chantier. Depuis une 1.6, c’est une reconstruction, car le thème 1.6 ne fonctionne pas en 1.7 ni au-delà ; nous en proposons une version rapide, accélérée par l’IA et vérifiée à la main. Migration standard : 269 € HT de la 1.7 à la 8, 469 € HT de la 1.6 à la 8 (votre thème 1.6 n’étant pas repris), 69 € HT de la 8 à la 9 ; hors standard, sur devis. Payée une fois, son prix est déduit si vous passez ensuite à la maintenance. Planifiez la bascule en saison creuse, en janvier-février, pas avant les fêtes.

Deux projets tiers prolongent la 1.6 : thirty bees, fork de la 1.6.1.11 compatible PHP 7.4 à 8.3 et avec presque tous les modules 1.6, et PhenixSuite, continuation communautaire gratuite. Ils règlent la question de PHP, mais les modules, paiement en tête, ne sortent plus de version pour autant. L’Update Assistant officiel ne part plus que d’une 1.7 : sa branche 4.14, qui passait de la 1.6 à la 1.7, n’est plus maintenue.

Pour choisir la cible, lisez PrestaShop 8 ou 9 : quelle version viser. Pour le chantier, voyez migration PrestaShop 1.6 ou 1.7.

Questions fréquentes sur la maintenance PrestaShop 1.6 et 1.7

Garder votre boutique le temps de planifier la suite

Indiquez l’adresse de la boutique et sa version : 1.6, 1.7, ou « je ne sais pas ». Nous vous rappelons pour cadrer la maintenance de votre PrestaShop 1.6 ou 1.7 : ce qui peut être tenu, à quel coût, et dans quel ordre préparer la migration. Le forfait : 69 € HT par mois, sans engagement, dépannage offert.

Boutique en panne : 09 72 03 59 17, réponse en moins d’une heure, 7j/7, 8 h-22 h.