Montée de version PrestaShop : méthode et pièges

Une boutique PrestaShop qui n'a pas été mise à jour depuis des années n'est pas seulement démodée. Elle tourne sur une version de PHP qui ne reçoit plus de correctifs, avec des modules non maintenus et des solutions de paiement qui vont finir par la refuser. Voici comment préparer, exécuter et vérifier une montée de version sans perdre ni données ni positions.

Pourquoi rester sur une vieille version est un risque réel

Le premier risque est la sécurité. Un logiciel de e-commerce manipule des données personnelles et des transactions. Les branches anciennes ne reçoivent plus de correctifs, et les failles publiées sont exploitées par des robots qui balaient le web en permanence. Vous n'êtes pas ciblé personnellement, vous êtes trouvé automatiquement.

Le deuxième risque est PHP. Une vieille boutique tourne sur une version de PHP qui n'est plus maintenue. Or les hébergeurs finissent toujours par retirer les anciennes versions de leurs serveurs. Le jour où cela arrive, la boutique ne redémarre pas, et vous découvrez le problème un matin. Au moment où nous écrivons ces lignes, seules les branches PHP 8.2 et suivantes reçoivent encore des correctifs de sécurité, la branche 8.2 uniquement jusqu'à la fin de 2026 selon le calendrier officiel publié par le projet PHP. Tout ce qui est antérieur est en fin de vie.

Le troisième risque est le paiement. Les prestataires de paiement font évoluer leurs interfaces et leurs exigences de sécurité. Leurs modules récents ne s'installent pas sur des versions anciennes de PrestaShop, et leurs modules anciens finissent par être coupés. Une boutique qui ne peut plus encaisser n'est plus une boutique.

Le quatrième risque est humain. Plus l'écart de version est grand, plus la montée coûte cher et plus il devient difficile de trouver quelqu'un qui accepte d'y toucher. Le coût de l'attente est réel, même s'il n'apparaît sur aucune facture.

Où en sont les versions

Le paysage actuel se lit simplement. La branche 9 est la génération courante, la branche 8 est encore suivie côté sécurité, et tout ce qui est antérieur relève de l'héritage.

Retenez surtout un point de méthode : la version de PrestaShop et la version de PHP forment un couple. Monter l'une sans l'autre casse le site. C'est la cause numéro un des montées de version ratées.

Les sauts de version et leurs pièges

De 1.6 vers 8 ou 9

Ce n'est pas une montée de version, c'est une reconstruction. Le socle technique a changé en profondeur, le thème par défaut n'a plus rien à voir, et vos modules 1.6 ne fonctionneront pas. Traitez le projet comme une refonte, avec reprise des données et plan de redirections, et non comme une simple mise à jour.

De 1.7 vers 8

C'est le saut le plus courant et le plus raisonnable. Techniquement, la branche 8 est la suite directe de la 1.7. Les pièges sont ailleurs : les surcharges de fichiers cœur faites par un ancien développeur, les modules abandonnés, et un thème sur mesure qui n'a jamais été prévu pour évoluer.

De 8 vers 9

Le saut demande de la préparation, en particulier côté serveur. La branche 9 exige une version de PHP récente et un socle technique plus moderne. Les modules doivent être déclarés compatibles par leurs éditeurs, et le thème doit être vérifié. Ne lancez jamais cette montée sans avoir la liste des modules critiques et leur statut de compatibilité.

Modules et thème, le vrai coût de la montée

Le cœur de PrestaShop se met à jour correctement. Ce qui coûte, c'est tout ce qui a été ajouté autour.

• Les modules payants. Une licence achetée il y a six ans ne donne pas droit à la version compatible d'aujourd'hui. Prévoyez un budget de renouvellement, éditeur par éditeur.
• Les modules abandonnés. Si l'éditeur a disparu, il faut trouver un remplaçant et migrer les données que le module stockait, ce qui n'est jamais automatique.
• Les surcharges et les modifications du cœur. Elles ne survivent pas à une mise à jour. Il faut les inventorier avant, comprendre à quoi elles servent, et les réécrire proprement.
• Le thème. Un thème sur mesure ancien demande souvent plus de travail que le reste du projet réuni. Comparez honnêtement le coût de son adaptation avec celui d'un thème récent personnalisé.
• Les traductions personnalisées. Elles se perdent facilement, exportez-les avant.

Faites cet inventaire au tout début. Il détermine le budget et il révèle parfois que la montée de version n'est pas la bonne réponse, et qu'une refonte propre coûterait moins cher.

La méthode, étape par étape

Une montée de version se prépare comme une opération, pas comme un clic.

• Faire une sauvegarde complète, fichiers et base de données, et vérifier qu'elle se restaure réellement. Une sauvegarde non testée n'est pas une sauvegarde.
• Monter une copie exacte de la boutique dans un environnement de test isolé, non accessible aux moteurs de recherche. C'est le seul endroit où travailler.
• Vérifier le socle serveur : version de PHP, extensions nécessaires, version de la base de données, limite de mémoire par script. La documentation officielle donne les prérequis précis pour chaque branche.
• Utiliser le module officiel de mise à jour, aujourd'hui appelé assistant de mise à jour et connu techniquement sous le nom autoupgrade, anciennement 1-Click Upgrade. Ne bricolez pas un remplacement de fichiers à la main.
• Exécuter la montée sur la copie, relever chaque erreur, corriger, recommencer depuis une copie fraîche. Une montée réussie du premier coup sur un site ancien est l'exception.
• Réinstaller ou remplacer les modules dans leur version compatible, remonter les surcharges réécrites, adapter le thème.
• Faire recetter la boutique par quelqu'un qui la connaît métier, pas seulement par un développeur.
• Planifier la bascule sur un créneau à faible trafic, avec une procédure de retour arrière écrite à l'avance.

La vérification après la montée

C'est l'étape que l'on saute quand on est fatigué, et c'est celle qui coûte le plus cher. Voici la liste minimale.

• Un parcours d'achat complet, du produit au paiement réel, sur chaque moyen de paiement actif.
• Les emails transactionnels : confirmation de commande, expédition, création de compte, réinitialisation de mot de passe.
• Les calculs de TVA, les frais de port, les seuils de livraison gratuite, les codes promo.
• La génération des factures et la continuité de la numérotation.
• L'export comptable et les flux vers votre gestion commerciale.
• Les stocks et la synchronisation avec vos autres canaux de vente.
• Le fichier robots, les balises d'indexation et le sitemap. Une préproduction bloquée aux robots qui passe en production sans qu'on lève le blocage, c'est un site qui disparaît des résultats.
• Les temps de chargement, avant et après, sur les pages qui comptent.
• Les erreurs serveur dans les journaux, pendant les quarante-huit heures qui suivent.

Conserver les URL, le point non négociable

Bonne nouvelle : une montée de version n'impose pas de changer vos adresses. C'est même l'un des avantages majeurs par rapport à un changement de plateforme. Encore faut-il y veiller.

• Notez la configuration exacte de vos formats d'URL avant la montée, et vérifiez qu'elle est identique après.
• Contrôlez que la réécriture d'URL est bien réactivée et que le fichier de configuration du serveur a été régénéré.
• Si un module de référencement gérait vos formats d'adresses et qu'il n'existe plus, vous risquez un changement massif d'URL sans l'avoir décidé. Vérifiez ce point en priorité sur la copie de test.
• Si un changement d'URL est inévitable, alors il faut un plan de redirections permanentes, comme pour une refonte. Notre guide sur la refonte sans perte de référencement détaille la méthode.
• Comparez la liste des URL avant et après, par un crawl des deux versions. C'est la seule preuve objective que rien n'a bougé.

Combien de temps, et avec qui

Une montée de version simple, sur une boutique récente avec peu de modules et un thème standard, se traite en quelques jours de travail effectif, étalés sur une à deux semaines pour laisser du temps aux tests. Une boutique ancienne, avec un thème sur mesure, des surcharges et une quinzaine de modules, demande plusieurs semaines et un budget de renouvellement de licences.

Le facteur décisif n'est presque jamais la taille du catalogue. Ce sont les modules, les surcharges et l'état du thème. Un audit d'une journée sur ces trois points donne un chiffrage fiable, alors qu'un devis établi sans cet audit est une estimation au doigt mouillé.

Si vous hésitez entre monter de version et repartir sur une base neuve, prenez le temps de lire notre guide sur le bon moment pour refaire son site. Et si vous voulez qu'on regarde l'état réel de votre boutique avant de décider,écrivez-nous.