Migration PrestaShop 8 vers 9 : ce qui change, et ce qu’il faut tester avant de passer

L’Update Assistant, le module de mise à jour de l’éditeur, conduit une boutique de la 8 à la 9 en gardant ses données, ses modules compatibles et son thème, même si la documentation recommande une boutique neuve pour une version majeure. Le passage s’appuie sur PHP 8.1, la seule version que les deux branches acceptent. La 9 change le socle technique, le back-office et les conditions faites aux modules. Au 14 octobre 2026, la question du moment se tranche sur deux faits : PHP 8.1 n’a plus de correctif depuis le 31 décembre 2025, et vos modules critiques existent, ou non, en version 9.

• Rester en PrestaShop 8 se justifie par un module précis
• Le tableau des écarts entre PrestaShop 8 et PrestaShop 9 tient en sept repères
• PHP 8.1 sert de pont, puis monte une fois la boutique en 9
• Quatre ruptures de PrestaShop 9 touchent les modules écrits pour la 8
• Quatre pages de la boutique se vérifient avec le thème en place
• Les tests avant la bascule suivent l’argent, puis les écrans du back-office
• Un changement simultané de PHP et de PrestaShop ou un chiffrement SSL des e-mails fait échouer le passage à la 9
• Le prix du passage à PrestaShop 9 monte avec les modules sans version 9
• Sources consultées
• Foire aux questions

Rester en PrestaShop 8 se justifie par un module précis

La branche 8.2 reçoit encore des correctifs critiques et de sécurité. L’éditeur l’a placée en support étendu le 4 juillet 2025, jusqu’à la sortie de PrestaShop 10, qui n’a pas de date. Le langage qui la fait tourner, lui, n’est plus corrigé : PrestaShop 8 n’accepte rien au-delà de PHP 8.1, et php.net a cessé de le corriger le 31 décembre 2025.

La 9.0 est sortie le 10 juin 2025, la 9.1 le 23 mars 2026, la 9.2 le 30 septembre 2026. Seize mois et deux versions mineures ont passé depuis la 9.0.

Une raison d’attendre tient en une ligne : tel module de paiement, de transport ou de liaison avec l’ERP n’existe pas encore pour la 9. Écrivez-la avec une date de réexamen. D’ici là, la boutique en 8.2 se tient à jour de ses correctifs : c’est l’objet des mises à jour de sécurité et de modules.

Le tableau des écarts entre PrestaShop 8 et PrestaShop 9 tient en sept repères

Les exigences et les réglages par défaut des deux branches diffèrent sur sept points, d’après la documentation développeur et les annonces de l’éditeur.

S’y ajoute une API d’administration, interface qui permet à un logiciel externe de lire et modifier la boutique. L’éditeur la présentait à la sortie de la 9.0 comme un chantier en cours.

PHP 8.1 sert de pont, puis monte une fois la boutique en 9

L’ordre se déduit des prérequis. La mise à jour vers la 9 se fait sur PHP 8.1, puisque la 8 n’en accepte pas d’autre au-dessus. PHP monte ensuite, la documentation de la 9 recommandant la 8.5.

Reste la version visée. L’éditeur décrit la mise à jour par le module de la 9.0.x ou de la 9.1.x vers la 9.2 ; ses annonces ne disent pas si une 8.x rejoint la 9.2 d’un seul passage. L’écran de l’outil, sur la copie, indique la version qu’il propose : prévoyez un arrêt possible en 9.0 ou en 9.1.

La montée de PHP a sa mission : monter la version de PHP sans arrêter la boutique. Visez au moins PHP 8.3, corrigé pour la sécurité jusqu’au 31 décembre 2027 : PHP 8.2 perdra ses correctifs le 31 décembre 2026.

Décrire mon besoin →

Quatre ruptures de PrestaShop 9 touchent les modules écrits pour la 8

Le guide des ruptures de la 9.0, publié pour les développeurs, en liste des dizaines. Quatre concernent directement un marchand.

Un module ne peut plus être appelé par l’adresse directe d’un de ses fichiers « .php » : il passe par un contrôleur, la porte d’entrée standard des modules. Scénario : un module de paiement dont le service de paiement confirme l’encaissement en appelant un fichier « .php » de ce type doit changer cette adresse de notification, et la mettre aussi à jour dans le compte du prestataire de paiement.

L’ancienne page produit du back-office disparaît, avec dix-huit crochets, ces points d’accroche où un module se branche. Un module qui ajoutait un champ ou un onglet à la fiche produit doit passer par la nouvelle page.

La connexion au back-office passe sous Symfony, le cadre de développement de PrestaShop, et sept crochets de l’ancienne page de connexion sont retirés. Un module de double authentification se vérifie en premier.

Trois bibliothèques, ces briques de code toutes faites, quittent le cœur : Guzzle (appels à des services web), SwiftMailer (envoi d’e-mails) et Tactician (enchaînement de commandes internes). Un module qui s’en servait sans les embarquer doit les apporter lui-même, ou passer aux outils de Symfony qui les remplacent.

Trois fonctions partent aussi : la livraison d’une même commande à plusieurs adresses, les restes de la gestion avancée des stocks et les images haute définition. Une boutique qui s’en servait prévoit leur remplacement avant la bascule.

Quatre pages de la boutique se vérifient avec le thème en place

La mise à jour garde votre thème. Hummingbird, construit sur la bibliothèque de mise en page Bootstrap 5, ne remplace Classic que dans les installations neuves depuis la 9.1.

La 9 change pourtant la façon dont le cœur transmet ses données au thème sur les pages des catégories, des fabricants, des fournisseurs et des magasins. Exemple du guide : l’image d’un fabricant devient un ensemble de tailles, lu par « image.medium.url », au lieu d’une simple adresse. Un thème qui lit encore l’ancienne variable risque d’afficher des logos de marques cassés.

La fonction de traduction des gabarits, « trans() », n’échappe plus le texte, c’est-à-dire qu’elle ne neutralise plus les caractères spéciaux. Le thème le fait lui-même, sans quoi une traduction contenant un guillemet peut casser l’affichage.

Décrire mon besoin →

Les tests avant la bascule suivent l’argent, puis les écrans du back-office

L’éditeur recommande de tester la mise à jour sur une préproduction, copie de la boutique invisible des clients, après sauvegarde des fichiers et de la base. Faites-y passer, dans cet ordre :

• une commande payée avec chaque moyen de paiement, jusqu’au statut « Paiement accepté » ;
• l’e-mail de confirmation, reçu dans une vraie boîte de messagerie ;
• la modification d’une fiche produit portant les champs de vos modules ;
• la connexion au back-office avec le compte de chaque employé ;
• les pages des catégories, des marques et des magasins, sur mobile ;
• les exports et les tâches planifiées des modules (stocks, flux des places de marché, factures).

Une commande qui reste en attente alors que l’argent est encaissé trahit une notification qui n’arrive plus. Exigez le compte rendu de ces tests et la liste des modules avec leur version pour la 9. Faites écrire qui restaure la boutique depuis la sauvegarde, sans facturation supplémentaire, si un paiement échoue après la mise en production.

Un changement simultané de PHP et de PrestaShop ou un chiffrement SSL des e-mails fait échouer le passage à la 9

Changer PHP et PrestaShop le même soir mêle deux causes possibles à chaque panne. Séparez les deux opérations de quelques jours d’activité normale, et gardez PHP 8.1 pendant la mise à jour.

Laisser l’envoi des e-mails réglé sur SSL dans Paramètres avancés > E-mail peut empêcher l’envoi des confirmations de commande, la 9 ne proposant plus que TLS ou aucun chiffrement. Passez le réglage sur TLS avant la bascule, avec le port indiqué par votre fournisseur de messagerie.

Le prix du passage à PrestaShop 9 monte avec les modules sans version 9

Cinq réglages font bouger le prix : le nombre de modules non natifs et la part de ceux qui n’ont pas de version 9 ; les modules qui enrichissent la fiche produit ou la connexion ; les moyens de paiement à retester ; les adaptations du thème sur les quatre pages concernées ; la montée de PHP qui suit.

Dans le message du formulaire de cette page, reportez votre version complète de PrestaShop, celle de PHP et la liste de vos modules de paiement.

Sources consultées

• PrestaShop, documentation développeur de PrestaShop 8, « System requirements », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, « System requirements », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, section « Core updates », pages « Notable changes in PrestaShop 9.0.x » et « Notable changes in PrestaShop 9.2.x », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, « Keep PrestaShop up-to-date » et « Supported branches », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, chapitres « Webservice API » et « Admin API », consulté le 14 octobre 2026.
• PrestaShop, « 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.
• php.net, « Supported Versions » et « Unsupported Branches », consulté le 14 octobre 2026.

Foire aux questions

Faut-il adopter Hummingbird en passant en PrestaShop 9 ?

Non. La mise à jour garde votre thème, et Hummingbird ne s’installe d’office que sur une boutique neuve. L’adopter revient à changer de thème, avec ses propres tests de pages et de modules. Mieux vaut le traiter comme un chantier distinct, la refonte du thème, une fois la boutique stable en 9.

La commande en une page de la 9.2 change-t-elle la mise à jour ?

La 9.2 intègre une commande sur une seule page. La documentation développeur la présente comme un changement majeur pour les modules et les thèmes qui interviennent dans le parcours de commande. Un module de paiement ou de transport se teste aussi avec ce nouveau parcours.

L’API d’administration remplace-t-elle le webservice ?

Les pages lues n’annoncent aucun remplacement : la documentation développeur de la 9 garde un chapitre « Webservice API » à côté du chapitre « Admin API ». L’API d’administration, nouvelle, s’appuie sur API Platform et une authentification OAuth, par jeton. Un connecteur existant (ERP, logiciel de caisse, place de marché) qui utilise le webservice se reteste en 9 ; sa réécriture reste un chantier à part.

Jusqu’à quand la 9.2 sera-t-elle corrigée ?

Jusqu’à la sortie de la 9.3, sauf rare exception : d’après la page « Supported branches », la branche d’une version mineure se ferme à la sortie de la suivante. Passer de la 9.2 à la 9.3 relève ensuite de l’entretien courant de la boutique.