PrestaShop 1.7 ou 8 : pourquoi passer à PrestaShop 9, et comment migrer sans perdre la boutique

La faille PHP2Shell se corrige dans PHP, et notre article sur PHP2Shell dit comment. Celui-ci part de là où il s’arrête : préparer le passage à PrestaShop 9, seule version qui tourne sur un PHP encore maintenu par ses auteurs.

L’essentiel en cinq points

• Aucune version de PrestaShop antérieure à la 9 n’accepte un PHP encore maintenu par php.net. PrestaShop 9.0 accepte PHP 8.1 à 8.4 ; 9.1 et 9.2 vont jusqu’à 8.5.
• La migration n’est pas le correctif de PHP2Shell. L’urgence était un PHP réparé pour la version en place ; le passage à la 9 se prépare, sans précipitation.
• Le chemin dépend de votre point de départ. De la 8, on passe à la 9 sur PHP 8.1. De la 1.7, aucune version de PHP n’est commune avec la 9 : il faut une étape par PrestaShop 8.
• Ce qui casse, ce sont les modules, le thème et les surcharges, rarement les données. Le module de paiement passe en premier.
• Le Black Friday tombe le 27 novembre. Préparez la copie maintenant ; basculez après, pas pendant.

Pourquoi migrer maintenant, et pourquoi pas dans la précipitation

Le projet PHP maintient chaque branche quatre ans. Au 30 octobre 2026, quatre branches sont suivies : 8.2 jusqu’au 31 décembre 2026, 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. Toutes les autres sont en fin de vie : PHP 8.1 depuis le 31 décembre 2025, dernière version 8.1.34 ; PHP 8.0 depuis le 26 novembre 2023 ; PHP 7.4 depuis le 28 novembre 2022, dernière version 7.4.33.

Une boutique PrestaShop 8 tourne donc, au mieux, sur PHP 8.1. Le 21 octobre, PHP a publié 8.2.35, 8.3.36, 8.4.27 et 8.5.12 ; pour 7.4, 8.0 et 8.1, il n’a publié que des reports minimaux du correctif dans son dépôt de code, sans nouvelle version, écrit PrestaShop dans son communiqué. Une boutique PrestaShop 8 ou 1.7 n’a été protégée que si son hébergeur a recompilé ce PHP. Ce sera vrai de chaque faille de PHP à venir, et rien ne garantit que les reports continueront.

PrestaShop lui-même ne suit plus ces versions. La branche 1.7 n’est plus maintenue depuis la sortie de PrestaShop 9.0, le 10 juin 2025, comme annoncé dès 2023 ; son dernier correctif, 1.7.8.11, date du 2 janvier 2024. La branche 8.2 est en support étendu : elle ne reçoit que des correctifs critiques ou de sécurité, jusqu’à la sortie de PrestaShop 10.0. La dernière, 8.2.8, a corrigé cinq failles le 18 août 2026, dont trois classées hautes, et l’annonce conclut : commencez à planifier votre migration.

Planifier ne veut pas dire se précipiter. PrestaShop l’écrit noir sur blanc à propos de PHP2Shell : la mise à jour majeure « n’est pas un correctif d’urgence », et une boutique ne doit pas la bâcler pour répondre à la faille. L’ordre est donc fixe : d’abord un PHP réparé pour la version en place, ensuite une migration préparée sur une copie, à une date choisie. Casser le tunnel de commande la semaine du Black Friday, c’est perdre les meilleures journées de l’année.

Quelle version de PHP pour quelle version de PrestaShop ?

PrestaShop publie une table de compatibilité par branche : 1.6 et 1.7, 8, 9.0 et 9.1 ; la 9.2 indique ses prérequis dans son annonce du 30 septembre 2026. Ce sont ces tables qui décident, pas l’hébergeur : un PHP absent de la colonne n’est pas pris en charge, même s’il semble fonctionner.

PrestaShop et PHP, version par version

Trois lectures de ce tableau comptent pour la suite. La première : PHP 8.1 est la seule version commune à PrestaShop 8 et à PrestaShop 9. C’est par elle que passe une mise à jour sur place. La deuxième : entre PrestaShop 1.7.8, qui s’arrête à 7.4, et PrestaShop 9, qui commence à 8.1, il n’y a aucune version en commun. La troisième : sur PrestaShop 9, visez PHP 8.4 ou 8.5. PHP 8.2 n’aura plus de correctifs dans deux mois, et 8.3 n’en aura plus fin 2027.

Pour lire votre version de PHP, ouvrez Paramètres avancés, puis Informations, dans le back-office de PrestaShop. Le numéro ne suffit pas toujours à dire si ce PHP est réparé : la méthode de vérification est dans l’article sur PHP2Shell.

Le chemin selon votre version de départ

L’outil officiel s’appelle « Update Assistant » en anglais, ou module autoupgrade, l’ancien « 1-Click Upgrade ». Selon sa documentation sur GitHub, il met à jour toute boutique à partir de la 1.7, et le canal en ligne propose « la version la plus récente compatible avec la version de PHP de votre serveur ». Autrement dit, l’assistant ne vous proposera jamais PrestaShop 9 tant que le serveur tourne en PHP 7.4. C’est ce qui fixe les étapes.

Depuis PrestaShop 8

1. Sur une copie de préproduction (voir plus bas), vérifiez que la boutique tourne en PHP 8.1 ; si elle est encore en 7.x, passez-la en 8.1 d’abord, puisque PrestaShop 8 l’accepte et la recommande, et testez.
2. Installez la dernière version de l’assistant (7.6.6 au 30 octobre) : comme le dit sa documentation citée plus haut, il propose la version la plus récente compatible avec le PHP du serveur.
3. Mettez à jour vers PrestaShop 9.2.
4. Passez ensuite PHP en 8.4 ou en 8.5, une fois les modules confirmés pour cette version.

Depuis PrestaShop 1.7

Il faut deux sauts, parce que les deux versions n’ont aucun PHP en commun. D’abord la dernière PrestaShop 8.2, sur un PHP que la 1.7.8 et la 8 acceptent toutes deux, de 7.2.5 à 7.4 ; puis PHP 8.1 ; puis PrestaShop 9.2 ; enfin PHP 8.4 ou 8.5. Chaque saut repasse par la vérification des modules. Avant la 1.7.5 (versions 1.7.0 à 1.7.4), comptez une étape de plus : ces versions s’arrêtent à PHP 7.1, que PrestaShop 8 n’accepte pas.

Sur une 1.7 très modifiée, ce parcours en quatre temps devient long, et c’est souvent là que la migration des données, décrite plus bas, prend l’avantage.

Depuis PrestaShop 1.6

Le module autoupgrade actuel ne part que de la 1.7. Pour une 1.6, sa documentation renvoie à l’ancienne version 4.14.3, qui mène à la 1.7, avant de reprendre le parcours ci-dessus. Mais la documentation de PrestaShop prévient qu’un thème 1.6 ne fonctionne pas sur la 1.7 et les suivantes : le thème est à refaire de toute façon. Une boutique 1.6 a presque toujours intérêt à migrer ses données vers une installation neuve.

Mise à jour sur place ou migration des données ?

PrestaShop distingue deux procédés. La mise à jour garde la boutique telle qu’elle est et transforme ses fichiers et sa base. La migration installe une boutique neuve en version 9 et y transfère les données. Pour un changement de version majeure, la documentation recommande la migration, parce qu’une version majeure « introduit des changements importants » qui peuvent rendre le thème et les modules incompatibles.

La procédure de migration suit trois temps : extraire, transformer, charger. L’export se fait depuis le back-office, bouton par bouton (produits, clients, adresses, commandes, catégories, stocks…), ou depuis phpMyAdmin pour obtenir toutes les colonnes. Certaines tables ne se reprennent pas : celles des droits (access, module_access), la configuration, les devises, les langues et les menus du back-office (tab, tab_lang). Le système de droits a été revu : ils se reconfigurent à la main.

Choisir selon votre boutique

Une 8.x au thème et aux modules annoncés compatibles se met à jour sur place ; une 1.7 très modifiée ou une 1.6 se migre.

Dans les deux cas, les adresses des pages doivent rester les mêmes. Une migration change facilement le format des URL de produits, et chaque adresse perdue est une page que Google doit réapprendre. Gardez le même schéma d’URL et posez des redirections 301 pour celles qui changent : la méthode est dans notre guide pour migrer un site sans perdre son référencement.

L’inventaire, avant de toucher à quoi que ce soit

Une mise à jour majeure échoue rarement sur les données. Elle échoue sur ce que la boutique a reçu en plus du cœur de PrestaShop. Le conseil de PrestaShop tient en une phrase : tenez un module pour incompatible tant que le contraire n’est pas prouvé. Relevez donc :

• Les versions exactes de PrestaShop et de PHP, dans Paramètres avancés, puis Informations.
• Chaque module non natif : son nom, sa version, son auteur, où il a été acheté, et si l’éditeur annonce la compatibilité avec la 9. En ligne de commande, l’assistant fait ce contrôle avec update:check-modules (documentation).
• Le thème : son éditeur, sa version, et s’il est un thème enfant de Classic. Une mise à jour garde votre thème ; elle ne le convertit pas. Depuis la 9.1, les installations neuves partent de Hummingbird (2.0 en 9.1, 2.1 en 9.2), construit sur Bootstrap 5 : un thème écrit pour Classic ne s’y transpose pas.
• Les surcharges, rangées dans le dossier override, et tout fichier du cœur modifié à la main. C’est là que dorment les pannes.
• Les modèles d’e-mails personnalisés, les traductions modifiées et les tâches planifiées (synchronisation de stock, flux de prix, relances).
• Les licences des modules payants, et le compte sur lequel elles ont été achetées.

Ce dernier point est celui qu’on découvre trop tard. En Tunisie, beaucoup de boutiques ont été livrées par une agence ou un freelance qui ne répond plus, avec des modules achetés sur son propre compte. Sans ce compte, pas de téléchargement de la version compatible avec la 9. Récupérez les accès, ou les factures, avant de planifier quoi que ce soit.

Profitez-en pour retirer ce qui ne sert plus. Konnect et Paymee ne sont plus en activité : si leur module dort encore dans votre boutique, désinstallez-le au lieu de le porter vers la 9. Même chose pour les modules de test, de promotion terminée, ou installés pour essayer une idée.

Une copie de préproduction, jamais la boutique qui vend

Les annonces de PrestaShop 9.1 et 9.2 le répètent : sauvegardez, puis testez la mise à jour sur un environnement de préproduction avant de la passer sur la boutique en ligne. Concrètement :

1. Sauvegardez les fichiers et la base, et sortez la copie du serveur. L’assistant sait sauvegarder, mais il range ses archives dans le dossier d’administration de la boutique, sur le même serveur ; PrestaShop recommande de ne jamais laisser une sauvegarde là où elle pourrait être exposée publiquement.
2. Créez la copie sur un sous-domaine, avec sa propre base de données, et protégez-la par mot de passe pour que ni Google ni vos clients ne la trouvent.
3. Coupez ce qui sort de la copie : dans Paramètres avancés, puis E-mail, réglez-la pour qu’elle n’envoie aucun e-mail. Mettez les modules de paiement en mode test et désactivez les tâches planifiées qui écrivent chez un tiers.
4. Répétez la mise à jour une première fois pour apprendre, puis une seconde sur une copie fraîche, en chronométrant. Le jour de la bascule, vous saurez combien de temps la boutique restera en maintenance.

PrestaShop 9 demande plus de mémoire que la 8 : sa documentation conseille un memory_limit d’au moins 512M, contre 256M pour la 8. Une mise à jour lancée depuis le navigateur peut aussi buter sur la durée maximale d’exécution. C’est pour cela que l’assistant existe en ligne de commande : il y échappe, selon sa documentation, aux limites de memory_limit et de max_execution_time du serveur web.

Sur nos packs e-commerce, la deuxième base de données incluse dès START sert précisément à cette copie, et l’accès SSH, activé sur demande, permet de lancer l’assistant en ligne de commande. Vous sauvegardez et restaurez vous-même la boutique depuis Plesk ; pour une copie quotidienne conservée hors du serveur, il existe l’option de sauvegarde externalisée.

L’assistant de mise à jour : les options qui piègent

L’assistant déroule cinq étapes : choix de la version, options, sauvegarde, mise à jour, contrôles. Les options ont des valeurs par défaut raisonnables pour une boutique standard, et dangereuses pour une boutique personnalisée (documentation de l’interface) :

• Désactiver les modules non natifs : oui par défaut. C’est prudent, mais il faudra les réactiver un par un, en testant entre chaque.
• Régénérer les modèles d’e-mails : oui par défaut. Si vos e-mails de commande ont été personnalisés, cette option les remplace par ceux d’origine. Copiez-les avant.
• Désactiver toutes les surcharges : non par défaut dans l’interface. L’activer évite des conflits pendant la mise à jour, mais ce que faisaient les surcharges cesse de fonctionner.
• Les modules incompatibles sont désinstallés. Depuis la version 7.6.0, l’assistant compare les modules à la version visée et désinstalle ceux qui ne sont pas compatibles (annonce de la 9.1).

Ce dernier point mérite qu’on s’y arrête. Si l’assistant juge votre module de paiement incompatible, il le retire. Selon la façon dont le module est écrit, ses réglages peuvent partir avec lui : identifiants du marchand, clés, adresses de notification. Relevez-les avant de lancer quoi que ce soit, et gardez-les hors du ticket ou du courriel.

Deux pièges encore. On ne met pas à jour depuis une bêta ou une version candidate : PrestaShop demande alors une installation neuve. Et après la mise à jour, la boutique reste en maintenance : il faut se reconnecter au back-office, réactiver les modules, passer une commande d’essai, puis seulement sortir du mode maintenance. Si des images manquent, régénérez les miniatures dans Apparence, puis Paramètres des images.

Le changement de version de PHP vient après, quand la boutique tourne en 9.2. Sur nos packs, il se fait dans les réglages d’hébergement du domaine, dans Plesk, où toutes les versions de PHP sont disponibles, de la plus ancienne à la plus récente. Changez, testez le tunnel de commande, et revenez en arrière au premier doute : un changement de PHP se défait en une minute.

ClicToPay, Flouci, GPG, e-Dinar : retester l’encaissement de bout en bout

Le module de paiement est la pièce la plus sensible d’une boutique tunisienne, et la moins standard. Le choix d’une passerelle, les contrats et les pièges d’intégration sont dans notre guide du paiement en ligne en Tunisie ; ici, seulement ce que la migration change.

• Demandez la compatibilité par écrit. Flouci et GPG fournissent leurs propres modules PrestaShop : c’est à eux de dire si leur version actuelle fonctionne sur la 9.2. Pour ClicToPay, les modules sont l’œuvre de tiers ; adressez-vous à leur auteur.
• Gardez la commande en quatre étapes au début. La 9.2 intègre une commande sur une seule page, que l’on peut activer ou non depuis le back-office ; PrestaShop demande aux auteurs de modules de paiement de vérifier qu’ils fonctionnent dans ce parcours (annonce de la 9.2). Tant que votre prestataire ne l’a pas confirmé, restez sur l’ancien parcours.
• Testez tous les cas sur la copie, en mode test : paiement accepté, refusé, abandonné, et notification reçue alors que le client a fermé son navigateur. Vérifiez le montant : en millimes pour le dinar chez ClicToPay et Flouci.
• Surveillez l’adresse de notification. Sur la copie, elle doit viser la copie ; après la bascule, à nouveau la boutique. Une notification qui part vers la préproduction laisse des commandes payées en attente.

Après la bascule, passez une vraie commande de faible montant avec chaque moyen de paiement, et rapprochez-la de la transaction dans l’espace du prestataire. Le réglage du cache, qui peut figer une page de commande, est traité dans notre guide pour configurer PrestaShop, le paiement et le cache.

Quand basculer : le calendrier d’une boutique tunisienne

Trois dates encadrent l’hiver. Le Black Friday tombe le vendredi 27 novembre 2026. PHP 8.2 cesse de recevoir des correctifs le 31 décembre 2026, ce qui concerne les boutiques déjà passées en PrestaShop 9 sur cette version. Les soldes d’hiver, enfin : en 2026, le ministère du Commerce avait annoncé leur ouverture le 29 janvier, pour huit semaines (African Manager, 9 janvier 2026) ; la date de 2027 n’est pas encore connue.

Le calendrier qui en découle tient en quatre temps :

1. D’ici la mi-novembre : inventaire, copie de préproduction, première répétition. Rien ne change encore sur la boutique en ligne.
2. De la mi-novembre au lendemain du Black Friday : gel. Aucune mise à jour, aucun nouveau module. Si votre boutique attend du monde, voyez plutôt comment tenir la charge du Black Friday.
3. Début décembre : seconde répétition, puis la bascule, un matin de semaine, à l’heure la plus creuse de vos statistiques. Pas un vendredi soir.
4. Avant les soldes : deux à trois semaines de marche normale, pour que les défauts apparaissent avant l’affluence. Si la migration n’est pas prête mi-janvier, attendez la fin des soldes, avec les protections décrites ci-dessous.

Si vous ne pouvez pas migrer tout de suite

Une boutique 1.7 ou 8 peut tenir quelques mois, à condition de ne rien laisser au hasard :

• Un PHP réparé pour votre version. Plesk, cPanel et CloudLinux ont reconstruit leurs PHP 7.4 et 8.1 pour PHP2Shell ; obtenez de votre hébergeur une confirmation écrite, et vérifiez-la avec la méthode décrite dans le même article.
• La dernière version de votre branche. En PrestaShop 8, c’est la 8.2.8 : elle corrige notamment une injection SQL dans les filtres des listes du back-office et l’usurpation de l’adresse IP par l’en-tête X-Forwarded-For (annonce de la 8.2.8). En 1.7, il n’y a rien après la 1.7.8.11.
• Moins de portes ouvertes. Désinstallez les modules inutiles plutôt que de les désactiver, supprimez les comptes d’employés qui ne servent plus, et limitez l’accès au back-office.
• Un pare-feu applicatif, qui filtre les requêtes avant PHP. Nos packs e-commerce incluent Imunify360 et son pare-feu applicatif. Il fait gagner du temps ; il ne remplace ni le PHP réparé ni la mise à jour, PrestaShop le rappelle.

Le mode maintenance de PrestaShop ne protège pas d’une faille de PHP : PHP traite la requête avant la boutique. Si le doute est sérieux, la seule coupure utile est une page statique servie sans PHP, comme expliqué dans la partie faut-il couper son site.

Fixez-vous une date limite. Une protection provisoire qui dure deux ans n’est plus provisoire : c’est une boutique qui attend sa prochaine faille.

Les contrôles après la bascule

Le jour même, avant de sortir du mode maintenance, puis le lendemain matin :

• Connexion au back-office avec chaque profil d’employé, et droits de chacun.
• Modules réactivés un par un ; ceux que l’assistant a désinstallés, réinstallés et reconfigurés.
• Création d’un compte client, commande avec chaque transporteur et chaque moyen de paiement, retour du paiement et changement d’état de la commande.
• E-mails de confirmation et d’expédition, avec leur mise en forme.
• Factures : numérotation qui continue, TVA, mentions légales.
• Recherche du catalogue : reconstruisez l’index dans Paramètres de la boutique, puis Rechercher.
• Miniatures, déclinaisons, prix spécifiques et règles de panier.
• Tâches planifiées, flux vers les comparateurs et synchronisation de stock.
• Journaux : Paramètres avancés, puis Logs, et le journal d’erreurs PHP.
• Dans Search Console, les erreurs 404 de la semaine qui suit, et le plan du site soumis à nouveau.

Gardez la sauvegarde d’avant la bascule tant que la boutique n’a pas tourné plusieurs semaines sans incident. Une commande mal enregistrée se remarque parfois au premier rapprochement comptable, pas le jour même.

Ce que nous faisons, et ce qui reste à vous

Passer par un hébergeur local ne change rien aux règles de PrestaShop, mais change la manière d’y travailler : notre support répond par livechat et par ticket, 7j/7, en français et en tunisien. Voici le partage des rôles :

• Si la boutique est ailleurs : notre migration gratuite déplace la boutique telle quelle de votre hébergeur actuel vers nos serveurs : fichiers, base et e-mails. C’est un déménagement, ni un changement de CMS ni une mise à jour de version : nos techniciens testent la copie sur la version de PHP la plus récente qui la fait tourner et vous disent ce qui coince, et comme toutes les versions de PHP sont disponibles, une 1.7 peut garder la sienne le temps de préparer la suite ; le passage à PrestaShop 9, ses modules et son thème restent de votre côté, ou de celui de votre agence.
• Sur nos packs e-commerce : PHP est maintenu par nous, la deuxième base de données accueille la préproduction et le SSH sur demande permet l’assistant en ligne de commande.
• Sur un serveur VPS, PHP vous revient, sauf si vous confiez l’administration du serveur à notre équipe, qui pose les correctifs du système et des services ; la compatibilité de la boutique avec une nouvelle version de PHP reste à confirmer par vous ou votre développeur.

Une restauration faite par notre équipe est sur devis, sauf si l’incident vient de chez nous. Raison de plus pour tenir vos propres sauvegardes avant chaque étape.

Sources

Pages consultées le 30 octobre 2026.

• PrestaShop DevDocs — prérequis système de PrestaShop 9, de PrestaShop 8 et de PrestaShop 1.6 et 1.7.
• PrestaShop DevDocs — Keep PrestaShop up-to-date (mise à jour ou migration), procédure de migration, assistant depuis le back-office, assistant en ligne de commande, contrôles après mise à jour, sauvegarde.
• PrestaShop — module Update Assistant (autoupgrade) sur GitHub, branches, prérequis et canaux de mise à jour.
• PrestaShop, blog du projet — PrestaShop 9 est disponible (10 juin 2025), PrestaShop 9.1 (23 mars 2026), PrestaShop 9.1.5 et PrestaShop 8.2.8 (18 août 2026), PrestaShop 9.2 (30 septembre 2026), Critical PHP security updates (21 octobre 2026).
• PrestaShop, blog du projet — PrestaShop 1.7.8 en support étendu (5 janvier 2023), PrestaShop 1.7.8.11 (2 janvier 2024), PrestaShop 8.2.x en support étendu (4 juillet 2025) ; cycle de publication et de support.
• PHP — branches maintenues et branches en fin de vie.
• African Manager — Les soldes d’hiver démarrent le 29 janvier 2026 (9 janvier 2026).