Faut‑il vraiment mettre à jour PrestaShop ?

La question se pose toujours au même moment : un module ne fonctionne plus, ou l’hébergeur annonce la fin d’une version de PHP. Et la réponse honnête n’est pas « oui, toujours ». Une montée de version PrestaShop mal préparée peut coûter plusieurs jours de boutique à l’arrêt.

Qu’est‑ce que je risque vraiment à ne pas mettre à jour ?

Il faut distinguer deux choses que l’on confond souvent : les correctifs de sécurité et les montées de version.

Un correctif de sécurité répare une faille connue et publiée. Tant qu’il n’est pas appliqué, la faille est documentée publiquement, et les robots qui la cherchent passent sur votre boutique plusieurs fois par jour. Ce n’est pas une hypothèse : c’est mesurable dans les journaux du serveur.

Une montée de version, elle, apporte des fonctions. Elle est rarement urgente, et elle est toujours risquée.

Un correctif de sécurité s’applique vite. Une montée de version se prépare.

Comment savoir si ma boutique est exposée ?

Trois vérifications, dans cet ordre :

• La version du cœur. Elle s’affiche en bas du back‑office. Comparez‑la aux versions publiées : si vous avez plus de deux versions de retard sur la branche, des failles connues vous concernent.
• Les modules. C’est par eux que passent la majorité des attaques réelles, pas par le cœur. Un module abandonné par son éditeur ne recevra jamais de correctif.
• La version de PHP. Une version qui n’est plus supportée ne reçoit plus aucun correctif, quelle que soit la propreté de votre PrestaShop.

Pourquoi une montée de version casse‑t‑elle si souvent la boutique ?

Parce que ce n’est pas PrestaShop qui casse : ce sont les modules et le thème. Une boutique en production porte facilement quarante modules, dont plusieurs achetés il y a des années. Le jour où le cœur change, chacun d’eux doit suivre, et certains éditeurs ont disparu depuis longtemps.

S’ajoute ce que presque personne ne prévoit : les surcharges. Le code ajouté au fil du temps pour modifier un comportement standard est écrasé, ou entre en conflit. Il ne provoque pas toujours une erreur visible : parfois, c’est simplement le calcul des frais de port qui devient faux.

Quelle est la bonne méthode ?

Celle qui ne touche jamais la boutique en production avant d’être certaine du résultat :

• Copier la boutique entière, fichiers et base, sur un environnement séparé.
• Monter la version sur cette copie, et noter chaque anomalie.
• Recetter le tunnel de commande de bout en bout, avec un vrai paiement de 1 €. C’est l’étape que l’on saute, et c’est celle qui coûte cher.
• Vérifier les frais de port sur chaque transporteur et chaque zone. Un tarif qui bascule ne déclenche aucune alerte : on s’en aperçoit sur la marge, trois semaines plus tard.
• Basculer, avec la sauvegarde prête et le chemin de retour écrit à l’avance.

Et si mon prestataire refuse d’intervenir ?

C’est fréquent, et c’est souvent contractuel plutôt que technique : beaucoup de contrats de maintenance incluent les correctifs de sécurité mais excluent explicitement les montées de version du cœur. Relisez l’article correspondant avant d’engager la discussion : vous saurez si vous demandez un dû ou une prestation supplémentaire.

Sur le même sujet : Fiches produit en double : d’où viennent‑elles ? · Faut‑il traduire sa boutique en plusieurs langues ?