PrestaShop 1.7 vs Prestashop 8 : faut-il migrer et comment anticiper PrestaShop 9 ?

Cet article recommandait, au printemps 2025, de passer de PrestaShop 1.7 à 8 en attendant que la 9 se stabilise. Ce conseil ne tient plus. PrestaShop 9.2.0 est sortie le 30 septembre 2026, la branche 9 en est à sa troisième version mineure, et la branche 8 a un problème que personne ne met en avant : elle ne fonctionne pas au-delà de PHP 8.1, une version qui ne reçoit plus de correctifs de sécurité depuis le 31 décembre 2025.

Si vous êtes encore en 1.7 aujourd’hui, la vraie question n’est donc plus « 8 ou pas ». C’est « 8 ou directement 9 », et la réponse tient dans un fichier du core.

Le fichier qui tranche : install_version.php

Chaque version de PrestaShop déclare la plage de PHP qu’elle accepte dans install-dev/install_version.php. Relevé sur les tags officiels :

// 1.7.8.11
define('_PS_INSTALL_MINIMUM_PHP_VERSION_', '7.1.3');
define('_PS_INSTALL_MAXIMUM_PHP_VERSION_', '7.4');

// 8.2.8 (18 août 2026, dernière de la branche 8)
define('_PS_INSTALL_MINIMUM_PHP_VERSION_', '7.2.5');
define('_PS_INSTALL_MAXIMUM_PHP_VERSION_', '8.1');

// 9.0.0
define('_PS_INSTALL_MINIMUM_PHP_VERSION_', '8.1');
define('_PS_INSTALL_MAXIMUM_PHP_VERSION_', '8.4');

// 9.2.0 (30 septembre 2026)
define('_PS_INSTALL_MINIMUM_PHP_VERSION_', '8.1');
define('_PS_INSTALL_MAXIMUM_PHP_VERSION_', '8.5');

Mis bout à bout avec le calendrier de PHP :

PrestaShop 1.7 est donc en fin de vie à double titre : la branche s’est arrêtée à la 1.7.8.11, et le PHP qu’elle accepte n’est plus maintenu. Une boutique migrée de 1.7 vers 8 en octobre 2026 passe d’un PHP abandonné depuis près de quatre ans à un PHP abandonné depuis neuf mois. C’est un progrès, mais c’est un projet complet (audit, modules, thème, recette) pour arriver sur une base déjà hors support, avec une deuxième migration à prévoir derrière.

Où en est votre boutique : trois commandes

Avant de parler de cible, on vérifie le point de départ. Trois commandes suffisent, en SSH sur le serveur :

# Version exacte de PrestaShop
grep -n "const VERSION" app/AppKernel.php

# Version de PHP réellement utilisée par le site (pas celle du terminal)
php -r 'echo PHP_VERSION, PHP_EOL;'

# Surcharges du core : chaque fichier ici est un point de rupture potentiel
find override -name '*.php' ! -name 'index.php' | sort

Attention à la deuxième : le PHP de la ligne de commande n’est pas toujours celui de PHP-FPM. Sur un mutualisé, un phpinfo() temporaire (retiré tout de suite) reste la seule source fiable.

Puis, côté base, la liste des modules actifs avec leur version :

SELECT name, version
FROM ps_module
WHERE active = 1
ORDER BY name;

C’est cette liste qui fait le budget d’une migration, pas la version du core. Chaque module tiers se range dans l’une de trois cases : une version compatible 9 existe, un équivalent existe, ou il faut le réécrire (ou s’en passer).

8 ou 9 : notre règle en 2026

Visez la 9 dans presque tous les cas. Le coût d’une migration vient de l’audit et de la mise à niveau des modules, du thème et des surcharges. Faire ce travail pour la 8, puis le refaire pour la 9, revient à payer deux fois la partie la plus chère.

La 8 garde un sens dans un cas précis : un module dont vous ne pouvez pas vous passer n’a pas de version compatible 9, et sa réécriture ne peut pas être financée tout de suite. La 8.2 est alors une étape, à condition de l’assumer comme telle : un hébergement en PHP 8.1 hors support, et une date de sortie déjà fixée.

Rester en 1.7 n’est plus une option. PHP 7.4 ne reçoit plus rien depuis 2022, et les modules de paiement sont les premiers à abandonner les anciennes versions.

Le module de mise à jour fait moins que ce qu’on croit

Le module officiel 1-Click Upgrade (autoupgrade, version 7.6.6 au 29 septembre 2026) prend en charge toute boutique à partir de 1.7, vers la 8 ou la 9. Son README le précise d’ailleurs : depuis une 1.6, il faut d’abord passer en 1.7 avec l’ancienne branche 4.14 du module, puis relancer la dernière version.

Ce qu’il fait : remplacer les fichiers du core et jouer les scripts de mise à jour de la base. Ce qu’il ne fait pas :

• mettre à jour vos modules tiers ;
• adapter votre thème (un thème écrit pour la 1.7 demande presque toujours des retouches en 9) ;
• réécrire vos surcharges, qui peuvent viser des classes ou des signatures qui ont changé ;
• vous prévenir des incompatibilités silencieuses, celles qui ne produisent aucune erreur à l’écran.

C’est pour ça qu’on ne lance jamais la mise à jour en production. On la rejoue sur une copie, autant de fois qu’il le faut, jusqu’à ce que la procédure soit entièrement scriptée.

Les pannes qui ne disent rien

Les problèmes qui coûtent cher dans une migration sont ceux qui ne cassent rien visiblement : la boutique s’affiche, les commandes passent, et pourtant quelque chose ne marche plus.

Les mots de passe clients. Les comptes créés avant le passage à bcrypt gardent un ancien hash qui dépend de la constante _COOKIE_KEY_ de la boutique d’origine, alors que bcrypt l’ignore. Si la clé n’est pas reprise, ces clients-là ne peuvent plus se connecter, et aucun log ne le signale. On a raconté ce cas en détail dans cookie_key et migration PrestaShop : les secrets que les modules oublient.

Les surcharges figées. Une surcharge remplace la méthode entière du core. Si elle a été écrite en copiant le code de la 1.7, elle continue d’exécuter ce code-là après la migration : les corrections apportées à cette méthode en 8 et en 9 ne s’appliquent jamais, et rien ne le signale. On relit donc chaque fichier de override/ contre la méthode d’origine de la version cible, et on compare les montants de commandes test avant et après.

Les données reprises à la main. Quand le core est trop ancien pour une mise à jour en place, on installe une 9 neuve et on reprend les données par script. C’est ce qu’on a fait pour Micro Mobility, passé de PrestaShop 1.6 à 9 avec treize ans de commandes et de clients repris : le script et ses pièges sont dans Reprise de données PrestaShop 1.6 vers 9.

La procédure qu’on applique

1. Copie de la production sur une préproduction identique (même version de PHP, même configuration serveur), jamais sur un poste de développement.
2. Inventaire : version, PHP, surcharges, modules actifs, modifications de tables natives. Chaque module tiers reçoit une décision : mis à jour, remplacé ou retiré.
3. Première mise à jour à blanc sur la préproduction. On note chaque correction manuelle.
4. Script de bascule : toutes les corrections notées deviennent des commandes rejouables. Une action faite à la main en recette est une action oubliée le jour de la mise en production.
5. Recette fonctionnelle : parcours d’achat complet sur chaque moyen de paiement, connexion de comptes clients existants, comparaison des totaux de commandes, vérification des e-mails transactionnels.
6. Recette SEO : les URL des produits, catégories et pages CMS doivent répondre 200 ou rediriger en 301 vers leur équivalent exact. On compare le plan du site avant et après, adresse par adresse.
7. Bascule en heure creuse, avec une sauvegarde complète stockée hors du serveur et un retour arrière testé.

La checklist de mise en ligne PrestaShop détaille les contrôles du jour J.

Ce qu’on a mesuré sur une vraie migration

Sur Micro Mobility (PrestaShop 1.6 vers 9, aujourd’hui en PHP 8.5), la page d’accueil mobile s’affiche quatre fois plus vite, et le temps de réponse serveur médian est passé de 538 à 371 ms. Le projet a été mené en 163 tickets par quatre développeurs. Le détail est sur la fiche projet Micro Mobility.

Ce gain ne vient pas du numéro de version. Il vient du fait qu’une migration oblige à refaire l’inventaire : modules inutiles retirés, surcharges réécrites, hébergement remis à plat.

Questions fréquentes

Si votre boutique est encore en 1.7 et que vous voulez savoir ce que coûterait le passage en 9, c’est la première chose qu’on chiffre quand on vous aide à faire migrer votre boutique vers PrestaShop 9.