Votre boutique tourne encore en PrestaShop 1.6 : ce que ça veut dire
La maintenance de PrestaShop 1.6 s'est arrêtée le 30 juin 2019. Depuis, plus de correctifs, et plus de correctifs de sécurité. Votre boutique, elle, fonctionne toujours : elle affiche, elle vend, elle encaisse. C'est précisément ce qui rend le sujet si facile à repousser.
Alors autant être précis sur ce que « fin de support » veut dire, et sur ce que ça ne veut pas dire. Parce que les deux se disent beaucoup, et rarement dans le bon ordre.
Ce que ça ne veut pas dire
Votre boutique ne va pas s'éteindre à une date. Il n'y a pas de compte à rebours, pas de licence qui expire, pas de serveur PrestaShop qui coupe quoi que ce soit. Une 1.6 bien réglée peut vendre pendant des années.
Ce n'est donc pas une urgence au sens où quelqu'un chercherait à vous vendre une urgence. C'est un risque qui grandit tout seul, et dont le coût de réparation augmente avec le temps.
Ce que ça veut dire, dans l'ordre où ça arrive
1. PHP, et c'est presque toujours par là que ça commence
PrestaShop 1.6 s'arrête à PHP 7.1, dont le support a pris fin en décembre 2019. Votre hébergeur, lui, avance : il retire les vieilles versions, parce qu'elles deviennent son propre risque. Le jour où il retire celle dont votre boutique a besoin, vous ne perdez pas une fonctionnalité : vous obtenez une page blanche, ou une erreur 500, sur toute la boutique.
Ce jour-là arrive avec un préavis, sous forme de mail, souvent lu en diagonale. Un mail de votre hébergeur au sujet de PHP est le signal le plus fiable qui existe pour déclencher un projet de migration.
2. Les modules de paiement
Ce sont eux qui lâchent en premier, et pour une raison qui ne dépend ni de vous ni de PrestaShop : les banques et les prestataires de paiement font évoluer leurs normes et leurs interfaces. Quand un éditeur cesse de publier une version 1.6 de son module, votre tunnel de commande devient un compte à rebours silencieux.
Une boutique qui n'encaisse plus n'est pas une boutique en panne partielle. C'est une boutique à l'arrêt, qui a l'air de fonctionner.
3. Les failles publiées
Chaque correctif de sécurité publié pour PrestaShop 8 ou 9 est aussi une description publique du problème corrigé. Sur une version encore maintenue, on applique le patch. Sur une 1.6, la faille reste ouverte, et elle est maintenant documentée. C'est la différence entre « personne n'a cherché » et « tout le monde peut lire ».
Le résultat, quand ça tourne mal, n'a rien de spectaculaire : du code injecté dans les pages, des redirections invisibles pour vous et bien visibles pour Google, parfois un formulaire de paiement détourné. On s'en aperçoit par une alerte de navigateur ou une chute de trafic, rarement en premier.
4. Les extensions abandonnées
Transporteurs, comparateurs, outils d'emailing, connecteurs comptables : chaque éditeur arrête un jour de maintenir ses versions 1.6. Vous ne le voyez pas passer ; vous le découvrez le jour où l'interface d'en face change et où le module ne suit pas.
5. Et surtout : le jour où quelque chose casse, il n'y a plus de correctif
C'est le vrai sujet. Sur une version maintenue, un problème sérieux est un problème partagé par des milliers de boutiques : quelqu'un le corrige. Sur une 1.6, c'est votre problème, et il se répare au tarif du développement sur mesure — dans l'urgence, ce qui est le pire moment pour tout.
Si la migration ne rentre pas dans ce trimestre
Ça arrive, et c'est une décision légitime. Elle se prend alors les yeux ouverts, avec ces mesures — toutes utiles, aucune ne remplaçant la migration :
- Des sauvegardes vérifiées et stockées ailleurs que sur le serveur, et restaurées au moins une fois pour de vrai. Une sauvegarde jamais restaurée n'est pas une sauvegarde.
- Le ménage dans les comptes employés : les personnes parties n'ont plus rien à faire là, et les mots de passe partagés non plus.
- La suppression des modules inutilisés. Un module désactivé reste du code présent sur le serveur.
- Le retrait des fichiers d'installation et des sauvegardes accessibles publiquement, qui traînent plus souvent qu'on ne croit.
- Une adresse de back-office qui n'est pas celle par défaut, et le HTTPS partout.
- Une réponse écrite à une seule question : combien de temps faudrait-il pour remonter cette boutique si le serveur disparaissait ce soir ? Si personne ne sait, c'est le premier chantier.
Verrouiller d'abord, migrer ensuite. Ce n'est pas une alternative à la migration, c'est ce qui vous permet de la préparer sans travailler dans l'urgence — et de ne pas la subir un vendredi soir.
Puis migrer, et vers quoi
Depuis une 1.6, la cible raisonnable est PrestaShop 9, qui accepte PHP jusqu'à la version 8.4 et vous laisse plusieurs années de marge côté serveur. PrestaShop 8 reste un palier acceptable si un module indispensable l'exige, mais il s'arrête à PHP 8.2 — dont le support de sécurité se termine fin 2026.
Le chemin, lui, n'a rien d'automatique : le passage en 1.7 rend le thème 1.6 inutilisable et les modules 1.6 non installables. C'est tout le sujet de cet article.
Faire le point sur ma boutique 1.6
Questions fréquentes
PrestaShop 1.6 est-il encore sécurisé ?
Non, au sens où plus aucun correctif de sécurité n'est publié pour cette branche : sa maintenance s'est arrêtée le 30 juin 2019. Chaque faille corrigée depuis dans les versions récentes est aussi une faille décrite publiquement, et elle reste ouverte sur une 1.6. On peut réduire le risque — sauvegardes, comptes, modules inutiles, accès — on ne peut pas le supprimer.
Ma boutique 1.6 peut-elle continuer à fonctionner ?
Oui, tant que l'hébergeur propose encore la version de PHP qu'elle exige et que les modules de paiement acceptent de fonctionner. Rien ne s'éteint à une date. Ce qui change, c'est qu'au premier problème sérieux, il n'existe plus de correctif : la réparation devient du développement sur mesure, dans l'urgence.
Quelle version de PHP pour PrestaShop 1.6 ?
PrestaShop 1.6.1 accepte PHP de 5.2 à 7.1 au maximum. Au-delà, il faut modifier des fichiers du cœur, ce qui est exactement ce qu'il ne faut pas faire. Or PHP 7.1 n'est plus maintenu depuis décembre 2019 : c'est le point qui déclenche la plupart des migrations, quand l'hébergeur annonce le retrait de cette version.
Mon hébergeur veut supprimer PHP 7.1, que faire ?
Ne pas chercher une dérogation, elle ne fera que déplacer la date. C'est le moment de lancer le projet : faire l'inventaire de la boutique, choisir la cible, et planifier. Si le préavis est trop court, la solution d'attente est un hébergement qui propose encore l'ancienne version, le temps de migrer — en sachant que vous payez alors pour rester sur un serveur que son propre fournisseur considère comme un risque.
Peut-on sécuriser une 1.6 sans migrer ?
On peut réduire la surface : sauvegardes testées et stockées hors du serveur, comptes employés obsolètes supprimés, modules inutilisés retirés, fichiers d'installation nettoyés, back-office déplacé de son adresse par défaut, HTTPS partout. C'est utile et ça se fait vite. Mais aucune de ces mesures ne corrige une faille dans le code : elles achètent du temps, elles ne remplacent pas la migration.
Vers quelle version migrer depuis une 1.6 ?
PrestaShop 9 dans la majorité des cas : c'est la branche courante, elle accepte PHP jusqu'à 8.4 et laisse plusieurs années de marge. PrestaShop 8.2 reste un palier valable si un module indispensable n'est pas encore compatible, mais il plafonne à PHP 8.2, dont le support de sécurité s'arrête fin 2026 — ce qui reviendrait à migrer pour se retrouver bientôt dans la même situation.