PrestaShop 1.6 en 2026 : maintenir, mettre à jour ou refondre ?

Votre boutique tourne sous PrestaShop 1.6, elle vend, et tout le monde vous dit qu'il faut refondre. Vous avez sans doute reçu un devis, sans aucun moyen de juger si le montant est justifié ou si l'on vous vend une inquiétude. Cet article ne tranche pas à votre place : il rassemble ce qui est vérifiable (dates officielles, alertes de sécurité publiées, versions de PHP supportées) et sépare ce qui relève des faits de ce qui relève de votre situation.

Le versant référencement est traité à part, dans PrestaShop 1.6 et SEO : moderniser sans tout migrer. Ici, on parle de risque, de maintenance et d'argent.

« Plus maintenu » : ce que ça veut dire, à la date près

PrestaShop a annoncé la fin de la maintenance de la 1.6 au 30 juin 2019. Le communiqué est explicite sur ce qui s'arrêtait : ce travail de maintenance « consistait principalement à corriger les bugs critiques ou les vulnérabilités de sécurité ». Depuis cette date, votre cœur de boutique ne reçoit donc plus de correctif, sécurité comprise. Nous sommes en 2026 : cela fait plus de sept ans.

Il y a une seconde couche, plus souvent oubliée, et c'est celle qui vous rattrapera en premier : PHP. La 1.6 est contemporaine de PHP 5 et du tout début de PHP 7, et la documentation développeur de PrestaShop ne commence qu'à la 1.7, dont le plancher est PHP 7.1.3. Or PHP 7 tout entier est sorti du support : php.net ne liste plus que la branche 8.2 et les suivantes comme recevant encore des correctifs de sécurité.

Le point à retenir ne dépend pas du détail des versions : aucune des branches PHP qu'une 1.6 sait faire tourner n'est encore corrigée. Une boutique 1.6 fait donc tourner deux logiciels non maintenus superposés, et le second ne dépend pas de vous : le jour où votre hébergeur retire PHP 7 de son parc, la décision est prise sans vous.

« Plus maintenu » ne veut pas dire « cassé » : une 1.6 bien tenue encaisse des commandes tous les jours. La question n'est pas de savoir si elle fonctionne, mais quel risque vous portez et quel coût vous acceptez.

Le risque est dans vos modules

C'est le point le plus contre-intuitif, et il est documenté par PrestaShop lui-même.

Juillet 2022. PrestaShop publie une alerte pour une vague d'attaques en cours : injection SQL enchaînée avec le cache Smarty stocké en base, aboutissant à l'exécution de code et au vol de données de paiement. Les boutiques concernées sont celles en 1.6.0.10 et supérieur dès lors qu'elles sont exposées à une injection SQL. La phrase à retenir de l'alerte : les attaquants visent « les boutiques utilisant des logiciels ou des modules obsolètes, des modules tiers vulnérables, ou une vulnérabilité encore inconnue ». Le correctif, lui, a été publié sous la forme de la version 1.7.8.7, c'est-à-dire sur une branche maintenue. Pour une 1.6, il n'y en avait pas.

Janvier 2025. Nouvelle alerte officielle, même famille d'attaque : une injection dans la valeur de configuration PS_SHOP_NAME fait servir du JavaScript aux clients de la boutique pour capter leurs données. Et cette fois, l'alerte est catégorique sur l'origine : « cette vulnérabilité n'est pas dans le cœur de PrestaShop mais dans des modules tiers », des failles « dont beaucoup ont été corrigées il y a longtemps mais restent non corrigées dans certaines boutiques ».

Mettez les deux ensemble et vous obtenez la carte du risque, qui n'est pas celle qu'on imagine :

• la porte d'entrée est presque toujours un module, pas le cœur ;
• ce qui protège, c'est d'avoir appliqué les correctifs de ces modules ;
• sur une 1.6, les mises à jour de modules sont précisément ce que vous ne recevez plus.

Ce n'est donc pas « le cœur est vieux, donc je suis en danger ». C'est : « mes modules ne sont plus suivis, et c'est par eux qu'on entre ». La nuance compte, parce qu'elle désigne l'inventaire à faire.

Ce qui se met à jour sur une 1.6, et ce qui ne se met pas

Sur le cœur, il existe des correctifs communautaires publiés pour certaines failles précises de la 1.6, y compris pour la chaîne de 2022. Ils rendent service, et il faut savoir ce qu'on accepte en les posant : un correctif tiers sur un logiciel non maintenu, c'est vous qui en assumez la validité, le suivi et la compatibilité avec le reste. C'est un choix défendable pour gagner du temps, pas une stratégie de long terme.

Racheter les modules : la seule question qui vaille, éditeur par éditeur

C'est le poste qui fait basculer la plupart des devis, et celui sur lequel circule le plus d'approximations. Il n'y a pas de règle générale : cela dépend du module. Un module vendu comme compatible avec votre branche actuelle et avec la branche cible ne se rachète pas. Un module qui n'existe qu'en 1.6 impose d'acheter son équivalent sur la version d'arrivée, quand cet équivalent existe.

D'où une méthode plutôt qu'une estimation. Pour chaque module, quatre questions :

1. En ai-je encore besoin ? Le premier gain d'une refonte, c'est la liste des modules qu'on ne réinstalle pas. Un paquet de boutiques traînent des modules installés une fois, jamais retirés.
2. Est-il encore vendu ? Un module disparu du catalogue de son éditeur n'est pas un problème de budget mais un problème fonctionnel : il faut lui trouver un remplaçant, ou renoncer à la fonction.
3. Existe-t-il pour la version cible, chez le même éditeur ? Si oui, demandez-lui par écrit si votre licence couvre cette version. C'est la question à poser, et elle se pose à l'éditeur, pas à un forum.
4. Combien, et pour quoi ? Le prix d'achat, plus le temps de reparamétrage, qui est souvent le poste caché.

Cet inventaire n'a rien de glamour et c'est pourtant lui qui vous permet de juger un devis. Sans lui, vous comparez des montants ; avec lui, vous comparez des périmètres.

La refonte : chiffrer, pas estimer

L'ordre de grandeur, parce que le flou n'aide personne : une remise à niveau complète (thème refait, modules rachetés et reparamétrés, données reprises, redirections sécurisées, recette) se compte en milliers d'euros. C'est plusieurs semaines de travail qualifié, et un prestataire qui le chiffre à ce niveau fait son métier.

Deux choses à en tirer, et aucune n'est « repoussez la décision ». Beaucoup de boutiques n'ont pas besoin de tout : c'est l'inventaire qui le dit, et il coûte bien moins cher que la refonte qu'il permet parfois d'éviter. Et un chiffre ne veut rien dire sans son périmètre, d'où notre parti pris : nous regardons votre boutique et nous chiffrons gratuitement.

Ce qu'on peut dire dans un article, en revanche, c'est de quoi la facture est faite, et où elle se concentre :

• le thème, à refaire et non à porter ;
• les modules, selon l'inventaire ci-dessus ;
• les données : catalogue, clients, commandes, avec la reprise d'historique ;
• le référencement, avec son plan de redirections, ses URLs et ses balises. C'est le poste qui coûte le plus cher quand il est bâclé, et il a son propre article ;
• la recette et la formation, systématiquement sous-estimées.

Deux faits utiles pour lire un devis. D'abord, un passage de 1.6 vers une version moderne n'est pas une mise à jour mais une migration : c'est exactement pour cela que la question du rachat des modules se pose. Ensuite, la cible impose son socle, et la documentation officielle le dit version par version : PrestaShop 8 demande PHP 7.2.5 au minimum, PrestaShop 9 supprime la compatibilité en dessous de PHP 8.1, et la 9.1 ajoute PHP 8.5, désormais la version recommandée. Pour beaucoup de boutiques 1.6, cela veut dire changer d'hébergement en même temps : à prévoir dans le calendrier plutôt qu'à découvrir en cours de route.

Un devis de refonte élevé n'est donc pas un devis malhonnête. Ce qui manque au commerçant, ce n'est pas un prix plus bas, c'est l'inventaire qui lui permet de comprendre ce qu'il achète.

Trois décisions défendables

Il n'y a pas une bonne réponse, il y en a trois, et elles dépendent de votre situation :

Maintenir, si vous acceptez des conditions explicites : réduire le nombre de modules au strict nécessaire, savoir lesquels sont exposés, appliquer les mesures recommandées par les alertes officielles elles-mêmes (préfixe de base de données non standard, pare-feu applicatif, veille sur les avis de sécurité), sauvegarder pour de vrai, c'est-à-dire avoir déjà restauré une sauvegarde au moins une fois, et accepter que l'échéance PHP de votre hébergeur vous soit imposée.

Migrer, quand un signal bloquant apparaît : un module critique introuvable, un hébergeur qui retire PHP 7.1, un plafond de performance atteint, ou un coût de maintenance annuel qui dépasse l'amortissement d'une refonte.

Refondre, quand le problème de la boutique n'est pas sa version : parcours d'achat, catalogue, image, conversion. Là, la version n'est qu'un prétexte de calendrier, et c'est très bien, à condition de le dire.

Ce qui ne dépend d'aucune version : votre contenu

Le contenu (fiches différenciées, pages catégories, blog) se travaille à l'identique sur une 1.6 et sur une 9, et c'est lui qui construit le trafic. Inutile donc d'attendre la refonte pour agir. L'idée reçue coûteuse, c'est « ma boutique est trop vieille pour les outils modernes » : c'est un choix d'architecture des éditeurs, pas une fatalité technique.

Publium tourne sur une 1.6 sans y toucher. Le module est écrit pour fonctionner à l'identique de la 1.6.1 à la 9, contrainte assumée dès la première ligne, précisément parce que le parc 1.6 existe et mérite mieux que l'abandon. Le détail des versions est sur la page compatibilité. Une boutique de 2015 peut donc se refaire une beauté côté référencement dès cette semaine : un blog qui existe enfin, des fiches produit réécrites, des balises renseignées, un maillage interne, sans migration, sans modification du cœur, sans attendre le budget d'une refonte.

Et si vous refondez plus tard, ce travail ne repart pas de zéro. Les articles et les fiches réécrites sont conservés dans Publium, avec leur historique de versions, pas seulement dans la base de votre PrestaShop. Le jour où la boutique est refaite sur le même domaine, elle se ré-appaire et retrouve ses contenus, republiables vers la nouvelle version puisque le module la couvre aussi. Entre-temps, le texte reste récupérable depuis l'éditeur, en markdown comme en HTML.

L'argument « on verra le contenu après la refonte » se retourne donc : le contenu est justement la partie du travail qui survit à la refonte.

Questions fréquentes

Ma 1.6 va-t-elle cesser de fonctionner ? Non. Rien ne s'éteint à une date donnée. Ce qui se dégrade, c'est la sécurité et l'écosystème : de moins en moins de modules compatibles, et aucun correctif quand une faille sort.

Un correctif communautaire, est-ce sérieux ? Certains sont écrits par des développeurs très compétents et rendent un vrai service. Mais en les installant, vous devenez responsable de leur suivi. À réserver aux failles connues, en attendant une décision, pas à la place d'une décision.

Combien coûte une refonte ? Une remise à niveau complète se compte en milliers d'euros. Mais le montant qui vous concerne dépend de votre inventaire, et beaucoup de boutiques n'ont pas besoin de tout refaire.

Puis-je travailler mon référencement sans migrer ? Oui, et c'est même le meilleur ordre : le contenu ne dépend d'aucune version, et il reste acquis le jour où vous migrez. Publium fonctionne de la 1.6.1 à la 9.

Google me pénalise-t-il pour ma version de PrestaShop ? Non. Le classement ne dépend pas du numéro de version. Le sujet est traité dans l'article dédié au SEO d'une 1.6.