Migration PrestaShop 1.6 vers 9 : sauter deux générations en une seule bascule

Une boutique PrestaShop 1.6 peut passer directement en 9 : le prestataire installe une 9 vierge et y transfère les données, sans version intermédiaire. Seul le module officiel de mise à jour impose des étapes, parce qu’il ne propose que des versions compatibles avec le PHP du serveur. Au 14 octobre 2026, la cible est la 9.2, publiée le 30 septembre, et la 9 reste la seule branche qui tourne sur un PHP encore corrigé par php.net.

• Le module de mise à jour PrestaShop impose trois montées entre la 1.6 et la 9
• Une seule bascule vers PrestaShop 9 garde un seul chantier
• L’étape par PrestaShop 8 se justifie dans deux cas précis
• PrestaShop 9 change le socle, le thème par défaut et le serveur
• Le serveur d’une boutique PrestaShop 9 se réserve avant la migration
• Ce qu’il faut exiger du prestataire pour un passage de la 1.6 à la 9
• Chaque étape ajoutée à un passage de la 1.6 à la 9 ajoute sa série de tests au devis
• Trois erreurs de version ou de serveur font rater un passage de la 1.6 à PrestaShop 9
• Sources consultées
• Foire aux questions

Le module de mise à jour PrestaShop impose trois montées entre la 1.6 et la 9

Le dépôt du module, l’Update Assistant, décrit deux temps : la version 4.14.3 conduit une 1.6 en 1.7, puis la version courante mène la boutique vers sa cible. Sa documentation précise qu’il ne propose que des versions compatibles avec le PHP installé. Le tableau, tiré des prérequis de chaque branche et du calendrier de php.net, montre pourquoi le second temps se découpe en deux pour la 9.

Une 1.7.8 plafonne à PHP 7.4, la 9 commence à PHP 8.1 : aucun serveur ne les fait tourner toutes les deux. Par le module, la 1.6 monte en 1.7, puis en 8, puis en 9, avec un changement de PHP entre chaque montée ; cette chaîne se déduit des tableaux, le dépôt ne détaille pas la 8. Le README de l’assistant précise que l’option de désactivation des modules non natifs est ignorée pour une cible 9 : demandez au prestataire comment ces modules sont traités à ce passage.

Ces montées se jouent sur une copie de la boutique, jamais en production.

Une seule bascule vers PrestaShop 9 garde un seul chantier

La documentation de PrestaShop recommande la migration pour tout changement de version majeure : une boutique neuve, installée dans la version visée, reçoit les données de l’ancienne. Pour une 1.6, cette boutique neuve peut être une 9.2 dès le premier jour.

Le chantier compte alors une répétition et une bascule, sur un serveur réglé une fois. La méthode de reprise est détaillée pour la migration de la 1.6 vers la 8, mots de passe compris : d’après le code de PrestaShop, ceux des clients ne survivent qu’au transfert de la table en base, empreintes intactes, l’outil d’import les hachant une seconde fois. Le code de la 9.2 se comporte comme celui de la 8 sur ce point.

La chaîne de mises à jour garde un avantage : la base reste en place, avec les tables ajoutées par d’anciens modules. La bascule unique les transfère, ce qui oblige à les comprendre.

L’étape par PrestaShop 8 se justifie dans deux cas précis

Premier cas : un module indispensable existe pour la 8 et pas encore pour la 9. La page de chaque module, sur la place de marché de PrestaShop, affiche la plage de versions qu’il accepte. Un module de facturation ou de liaison avec un logiciel de gestion qui s’arrête à la 8 peut justifier l’étape, à condition d’écrire au contrat la date où l’auteur annonce sa version 9.

Second cas : une base que personne ne sait décrire. Des dizaines de tables ajoutées au fil des ans par des développements sans documentation se transfèrent mal ; la chaîne de mises à jour les laisse où elles sont.

Hors de ces deux cas, l’étape par la 8 coûte une migration supplémentaire. La branche 8.2 ne reçoit que des correctifs critiques et de sécurité depuis le 4 juillet 2025, sur un PHP 8.1 que php.net ne corrige plus depuis le 31 décembre 2025.

Décrire mon besoin →

PrestaShop 9 change le socle, le thème par défaut et le serveur

Publiée le 10 juin 2025, la 9.0 repose sur Symfony 6.4, la version à support long du cadre de développement, dont les correctifs de sécurité courent jusqu’en novembre 2027. Elle a introduit une API d’administration, une interface qui laisse d’autres logiciels lire et modifier la boutique, présentée à la sortie comme un chantier en cours.

La 9.1, sortie le 23 mars 2026, installe par défaut le thème Hummingbird 2.0, construit sur Bootstrap 5, à la place de Classic. Elle présente deux fonctions encore expérimentales : des expéditions scindées ou regroupées dans une commande, et des remises refondues autour de quatre types. La 9.2 apporte un module de commande en une page et des champs personnalisés natifs, les Extra Properties, que le marchand crée depuis le back-office : les champs que des modules 1.6 gardaient dans leurs tables peuvent y être recréés.

Pour une boutique venue de la 1.6, le thème pèse lourd dans l’arbitrage. Il se refait dans tous les cas ; le refaire sur Classic pour une étape en 8, puis sur Hummingbird en 9, revient à payer deux fois le même travail. Le cahier des charges graphique part de Hummingbird : voir la refonte du thème.

Le serveur d’une boutique PrestaShop 9 se réserve avant la migration

La documentation de la 9 recommande PHP 8.5 et 512 Mo de mémoire par script, avec MySQL 5.7 minimum ou MariaDB 10.2 minimum. php.net corrige PHP 8.3 jusqu’au 31 décembre 2027, 8.4 jusqu’au 31 décembre 2028 et 8.5 jusqu’au 31 décembre 2029. Demandez à l’hébergeur, par écrit, les versions de PHP et de MySQL ou MariaDB qu’il ouvre sur l’espace de la future boutique, et la valeur de « memory_limit », le réglage qui fixe cette mémoire.

Ce qu’il faut exiger du prestataire pour un passage de la 1.6 à la 9

Le premier livrable est l’arbitrage écrit : bascule unique ou chaîne de mises à jour, avec la raison, et la liste des modules qui le motivent. Le second nomme la version mineure livrée, la 9.2 ou une plus récente, et la version de PHP du serveur. Le troisième est la table des modules, complétée d’une colonne « publié pour la 9 », remplie depuis la page de chaque module.

La production ne bouge pas tant que la répétition n’est pas validée, quel que soit le chemin. Si la chaîne échoue sur la copie, à l’étape 1.7 ou 8, le changement de chemin se chiffre avant d’être lancé : faites écrire qui en supporte le coût. Après l’ouverture, la 1.6 reste intacte, prête pour un retour arrière.

Exigez aussi, avant la bascule, la liste des adresses de l’ancienne boutique et la correspondance de chacune avec la nouvelle. Les redirections qui en découlent relèvent du SEO de migration.

Chaque étape ajoutée à un passage de la 1.6 à la 9 ajoute sa série de tests au devis

Cinq facteurs pèsent, sans qu’aucun se chiffre d’avance : le nombre d’étapes retenues ; les modules sans version 9 ; le thème bâti sur Hummingbird ; les données propres aux modules ; les changements de PHP demandés à l’hébergeur. La bascule unique supprime les séries de tests intermédiaires et ne demande qu’une version de PHP à l’hébergeur, contre trois changements pour la chaîne ; la chaîne, elle, supprime le transfert des données.

Décrire mon besoin →

Trois erreurs de version ou de serveur font rater un passage de la 1.6 à PrestaShop 9

Livrer une 9.0 ou une 9.1 en octobre 2026. La documentation développeur l’écrit : sauf rares exceptions, la branche de correctifs d’une version mineure ferme à la sortie de la suivante. La 9.0 n’est plus corrigée depuis le 23 mars 2026, la 9.1 depuis le 30 septembre 2026.

Héberger la 9 sur PHP 8.2. La version figure dans la plage acceptée, mais php.net cesse de la corriger le 31 décembre 2026, moins de trois mois après la date de cette page.

S’arrêter en 8 « pour souffler » après une chaîne de mises à jour. La boutique ouvre alors sur une branche en support étendu, et la migration vers la 9 reste entière.

Dans le message du formulaire de cette page, reportez la version exacte de votre 1.6, les modules dont vous ne pouvez pas vous passer et la date d’ouverture souhaitée.

Sources consultées

• PrestaShop, « 1.6.1.x : what’s next », consulté le 14 octobre 2026.
• PrestaShop, documentations développeur 1.7, 8 et 9, « System requirements », tableaux de compatibilité PHP et prérequis, consulté le 14 octobre 2026.
• php.net, « Unsupported Branches » et « Supported Versions », consulté le 14 octobre 2026.
• PrestaShop, dépôt « autoupgrade », fichier README, consulté le 14 octobre 2026.
• PrestaShop, documentation développeur 9, « Keep PrestaShop up-to-date », « Update from the back office » et « Supported branches », consulté le 14 octobre 2026.
• PrestaShop, annonces « PrestaShop 9 is available », « PrestaShop 9.1 is available » et « PrestaShop 9.2 is available », consulté le 14 octobre 2026.
• PrestaShop, « PrestaShop 8.2.x is now in the extended support phase », consulté le 14 octobre 2026.
• PrestaShop, code source, « controllers/admin/AdminImportController.php » (versions 1.6.1.24 et 9.2.0) et « src/Core/Crypto/Hashing.php » (version 9.2.0), consulté le 14 octobre 2026.

Foire aux questions

La 9 est-elle assez éprouvée pour une boutique qui vend ?

La branche est sortie le 10 juin 2025, sa version 9.1 le 23 mars 2026 et la 9.2 le 30 septembre 2026. Le module de mise à jour signale, par un badge « Recommended », la version la plus testée compatible avec le PHP du serveur. Exigez cette version, ou une plus récente que l’éditeur a validée depuis.

Faut-il attendre PrestaShop 10 ?

L’éditeur n’a pas daté sa sortie. Il l’a seulement désignée comme la fin du support de la branche 8.2. Pendant l’attente, une boutique 1.6 reste sur PHP 7.1 au plus, sans correctif depuis le 1er décembre 2019, et sur un logiciel que l’éditeur ne maintient plus depuis le 30 juin 2019.

Un module compatible avec la 8 fonctionne-t-il en 9 ?

Pas d’office. La documentation de l’éditeur demande de tenir chaque module pour incompatible tant que sa compatibilité n’est pas prouvée, et de vérifier sa plage de versions avant de le réinstaller. La 9 change de socle avec Symfony 6.4 : seule la page du module, ou son auteur, dit s’il suit.

Les versions mineures suivantes de la 9 demandent-elles une nouvelle migration ?

Non. Une version mineure de la même branche se monte avec le module de mise à jour. La documentation de l’éditeur assure qu’au sein d’une version majeure, thème et modules continuent de fonctionner, sauf rare correctif critique qui imposerait un ajustement. Prévoyez ce passage au contrat de maintenance, avec un test sur une copie.