Rester sur PrestaShop 1.6 ou 1.7 : quels risques et comment les évaluer

« Si ça marche, n'y touche pas » est un bon conseil pour presque tout, sauf pour un logiciel exposé à Internet et qui encaisse par carte. Une boutique sous PrestaShop 1.6 ou 1.7 peut vendre chaque jour sans la moindre erreur visible et, en même temps, accumuler des risques qui ne se remarquent qu'au moment où ils éclatent.

Il ne s'agit pas de faire peur. Il s'agit de comprendre ce que signifie être hors support, pour que la décision de rester ou de migrer vous appartienne et repose sur des faits.

Ce que « hors support » signifie en pratique

Le cœur ne reçoit plus de correctifs

La branche 1.6 s'est arrêtée à la 1.6.1.24 et la branche 1.7 à la 1.7.8.11. Lorsqu'une nouvelle vulnérabilité est découverte dans le cœur, le correctif est publié pour les branches maintenues. Pour la vôtre, au mieux, quelqu'un écrit un correctif non officiel ; au pire, il n'y a rien.

Et même si vous êtes en 1.7, de quelle 1.7 s'agit-il ? Beaucoup de boutiques sont encore en 1.7.6 ou en 1.7.7, sans les corrections ultérieures de cette même branche, qui comprenaient des correctifs de sécurité.

Les modules prennent du retard

Les développeurs de modules concentrent leur travail sur les versions actuelles. Avec le temps, voici ce qui se passe :

• Les nouvelles versions des modules ne sont plus compatibles avec votre boutique.
• Lorsqu'une faille de sécurité est publiée dans un module, la version corrigée exige un PrestaShop plus récent.
• Certains auteurs abandonnent leurs modules et personne ne les revoit plus.
• Les passerelles de paiement modifient leurs API et leurs exigences, et les anciens modules cessent de fonctionner ou perdent des fonctions.

En pratique, c'est le plus grand risque. Les campagnes massives contre PrestaShop exploitent généralement des vulnérabilités dans les modules, et une boutique qui ne peut pas installer la version corrigée reste exposée indéfiniment.

Un PHP hors support

PrestaShop 1.7.8 va au maximum jusqu'à PHP 7.4, et les versions antérieures encore moins loin. PHP 7.4 ne reçoit plus de correctifs de sécurité depuis des années. Cela signifie que le langage même sur lequel tourne votre boutique présente des failles connues qui ne seront pas corrigées.

De plus, les hébergeurs retirent les anciennes versions de PHP de leurs serveurs. Un jour, le prestataire annonce qu'il va monter de version, ou la monte directement, et la boutique cesse de fonctionner. Migrer dans l'urgence pour cette raison est la pire façon de migrer.

Comment évaluer votre risque

Toutes les anciennes boutiques ne présentent pas le même risque. Ces questions vous aident à vous situer :

Une boutique avec un gros chiffre d'affaires, beaucoup de modules tiers et aucune surveillance est celle qui a le plus à perdre et le plus de chances d'être attaquée avec succès.

Ce que l'on peut faire en attendant

Si la migration ne peut pas être immédiate, certaines mesures réduisent le risque :

• Passez à la dernière version de votre branche : la 1.7.8.11 si vous êtes en 1.7. C'est beaucoup moins de travail qu'une migration et cela ferme des failles connues.
• Montez PHP à la version la plus haute que supporte votre PrestaShop, en testant d'abord sur une copie.
• Inventoriez les modules et retirez ceux que vous n'utilisez pas, y compris les dossiers des modules désinstallés.
• Mettez à jour les modules qui ont une version compatible, surtout ceux qui ont des contrôleurs publics.
• Bloquez l'exécution directe de PHP dans modules/ et dans les dossiers de données.
• Activez la surveillance des fichiers, des employés et de la configuration des paiements, pour être vite informé si quelque chose se passe.
• Des sauvegardes quotidiennes, hors du serveur et testées.

Tout cela fait gagner du temps. Cela ne transforme pas une boutique hors support en boutique supportée. Et plus cela dure, plus la sortie coûte cher : chaque année qui passe creuse l'écart entre votre version et l'actuelle, ajoute des modules sans équivalent direct et des données à transférer. Les migrations les plus simples que nous réalisons sont celles de boutiques qui ont sauté le pas quand elles pouvaient encore choisir le moment, pas de celles qui ont attendu que quelque chose cesse de fonctionner.

Comment planifier la sortie

1. Choisissez la destination. Aujourd'hui, le plus raisonnable est de passer directement à PrestaShop 9, sans étape intermédiaire par la 8, sauf si un module indispensable n'existe pas encore pour la 9.
2. Inventoriez des fonctions, pas des modules. Listez ce que fait la boutique (facturation, livraisons, ERP, paiements, SEO) et, pour chaque élément, quel module s'en charge aujourd'hui et lequel le fera en 9. Souvent, une bonne partie s'avère superflue.
3. Estimez le travail sur le thème. Un thème 1.6 ne sert à rien en 9, et un thème 1.7 fonctionne rarement tel quel. C'est le poste le plus important de nombreuses migrations.
4. Choisissez le moment. Évitez les grosses campagnes de votre secteur. Une migration bien planifiée demande des semaines de tests, pas des jours.
5. Faites une répétition complète sur une copie avant le jour de la bascule.

L'avantage de planifier à l'avance, c'est que c'est vous qui fixez le calendrier. Si vous attendez que l'hébergeur retire PHP 7.4 ou qu'un incident survienne, quelqu'un d'autre le fixera.

Comment le résoudre dans PrestaShop

Chez Rekire, nous travaillons tous les jours avec des boutiques en 1.6, 1.7, 8 et 9, et avec nos forfaits d'heures de support nous réalisons exactement ce travail : un audit de la version, du PHP et des modules de votre boutique avec une évaluation du risque, la mise à jour vers la dernière version de votre branche si vous voulez gagner du temps, et le plan de migration vers PrestaShop 9 avec son inventaire des fonctions, des modules de remplacement et du travail sur le thème. Les heures sont décomptées selon le travail réel, et vous pouvez commencer par l'audit et décider ensuite.