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, peut-être plusieurs, et vous n'avez 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 les décisions qui reposent sur des faits de celles qui reposent sur 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 — de 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 — 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é.

C'est le point à retenir, et il a l'avantage de ne pas dépendre 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.

Précision utile, parce qu'elle change le ton de toute la discussion : « 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 — elle fonctionne. La question est le risque que vous portez et le coût que vous acceptez.

Le risque réel n'est pas où on le croit : il 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

| Couche | Peut-on la mettre à jour ? | |---|---| | Cœur PrestaShop | Non. Fin de maintenance en juin 2019, aucun correctif officiel depuis. | | PHP | Non, au-delà de 7.1 : la branche 1.6.1.x n'y est pas compatible. | | Modules payants | Au cas par cas, selon l'éditeur — voir la section suivante. | | Modules gratuits / faits maison | Oui, mais c'est vous (ou votre prestataire) qui devenez le mainteneur. | | Thème | Oui — c'est votre code. Mais l'architecture de thème 1.6 ne se transpose pas telle quelle sur les branches suivantes. | | Le contenu | Oui, toujours, et sans dépendre d'aucune version. |

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 c'est aussi celui sur lequel circule le plus d'approximations. La réponse honnête est qu'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 installé, quatre questions, dans cet ordre :

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

Disons d'abord 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 normal : c'est plusieurs semaines de travail qualifié, et un prestataire qui le chiffre à ce niveau fait son métier correctement.

Deux choses à en tirer, et aucune n'est « repoussez la décision ». La première, c'est que 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. La seconde, c'est qu'un chiffre ne veut rien dire sans son périmètre — d'où notre parti pris : nous regardons votre boutique et nous chiffrons gratuitement, avant que vous n'ayez à décider quoi que ce soit.

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 : plan de redirections, URLs, balises — c'est ce poste qui coûte le plus cher quand il est bâclé, et le sujet 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.

Et une remarque qui nous tient à cœur : un devis de refonte élevé n'est pas un devis malhonnête. Refaire un thème, reprendre un catalogue et sécuriser des redirections, c'est du travail long et qualifié, et les prestataires qui le chiffrent correctement ont raison de le faire. 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

C'est le point qui évite d'attendre la refonte pour agir. 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. 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 — c'est une 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. C'est la conséquence la plus utile de l'architecture, et elle mérite d'être dite : 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 lisible et récupérable depuis l'éditeur, en markdown comme en HTML.

Autrement dit, l'argument « on verra le contenu après la refonte » se retourne : le contenu est justement la partie du travail qui survit à la refonte. Commencer par lui, c'est investir dans la seule chose que la migration ne vous fera pas refaire.

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 ? L'ordre de grandeur d'une remise à niveau complète se compte en milliers d'euros, et c'est justifié par le travail que ça représente. Mais le montant qui vous concerne dépend de votre inventaire — et beaucoup de boutiques n'ont pas besoin de tout refaire. C'est exactement ce que nous regardons, gratuitement, avant de conseiller quoi que ce soit.

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.