Upgrade PrestaShop version : guide vers PrestaShop 9

Sommaire

• Quelle version de PrestaShop 9 choisir ?
• Quels prérequis serveur vérifier avant l’upgrade ?
• Comment valider les modules, le thème et les intégrations ?
• Comment sauvegarder et préparer le retour arrière ?
• Comment réaliser la mise à jour sans perturber les ventes ?
• Foire aux questions

Mettre à niveau une boutique PrestaShop touche à tout : le serveur, les modules, le thème, les paiements et le référencement. Pour réussir l’upgrade de votre version PrestaShop, vous devez choisir la bonne cible, vérifier les prérequis, sauvegarder et tester avant la mise en ligne.

Quelle version de PrestaShop 9 choisir ?

La version la plus récente n’est pas forcément celle qui convient à votre boutique. Le bon choix tient compte du statut officiel de la version et de ce que votre environnement accepte réellement. Il dépend aussi de la méthode : une mise à niveau directe ou une nouvelle installation.

Version publiée ou version recommandée ?

PrestaShop 9.2.0 est stable depuis le 30 septembre 2026. Pourtant, la page française des versions présente encore la 9.1 comme recommandée et la 9.2 comme Release Candidate, c’est-à-dire une préversion de test. Avant de fixer la version de PrestaShop visée, vérifiez donc son statut actuel. Trois repères restent à distinguer :

• La dernière version publiée : la plus récente, sans garantie qu’elle convienne à votre configuration.
• La version recommandée : celle que l’éditeur conseille pour une boutique en production.
• La version réellement possible : celle que votre hébergement, votre thème et vos modules supportent.

Une Release Candidate sert aux tests, jamais à une boutique commerciale. Si vous êtes déjà en 9.0 ou 9.1, vérifiez que Update Assistant propose bien la 9.2. Selon la FAQ officielle, une version publiée peut ne pas apparaître tant qu’elle n’est pas recommandée, que des tests sont en cours ou que votre PHP ne remplit pas les prérequis.

Quand privilégier une nouvelle installation ?

Passer de PrestaShop 8 à 9 peut imposer d’adapter ou de remplacer le thème, les modules et les personnalisations. Ce qui fonctionne en version 8 ne prouve rien pour la version 9. Depuis la 1.7, la documentation officielle ne décrit aucun passage direct vers la 9, et leurs plages PHP ne se recoupent pas. Depuis la 1.6, une nouvelle installation mérite d’être étudiée.

Un thème abandonné, des modules critiques absents sur la cible ou de nombreuses modifications spécifiques plaident aussi pour une nouvelle installation avec transfert contrôlé des données. Si un seul module bloque le passage à la 9, une version 8.x peut servir d’étape intermédiaire. Vérifiez alors la maintenance et la sécurité de sa version exacte.

Que change le choix de la méthode ?

Une migration PrestaShop vers une nouvelle installation demande son propre plan : transfert des données, rapprochement des commandes, rétablissement des intégrations. Certaines configurations sont à reconstituer. Les comptes employés, groupes ou permissions peuvent aussi devoir être recréés si leur structure a changé.

Pour nos migrations de PrestaShop 1.7 vers 8, nous commençons chez Webapic par auditer les modules et les personnalisations, puis nous planifions l’opération. Notre service de migration de version PrestaShop met ensuite à jour le cœur, transfère produits, clients et commandes, adapte les composants et teste la boutique. Cette démarche porte sur la version 8 ; un passage vers la 9 se cadre au cas par cas.

Quels prérequis serveur vérifier avant l’upgrade ?

Un serveur inadapté peut faire échouer l’opération avant même la première étape. Trois points comptent : la version PHP, la base de données et la capacité du serveur. S’y ajoutent quelques réglages d’hébergement souvent oubliés.

Quelle version PHP correspond à la cible ?

PrestaShop 9.0 accepte PHP 8.1 à 8.4, et sa documentation technique recommande PHP 8.4. Pour la 9.1, elle recommande PHP 8.5. Vérifiez les exigences exactes de la 9.2 avant de reprendre ce choix.

Côté PrestaShop 8, la matrice publiée couvre PHP 7.2.5 à 8.1, avec PHP 8.1 recommandé. Dans nos projets, nous travaillons notamment avec PHP 8.0 et 8.1 sur cette version. Dans tous les cas, la version PHP retenue doit aussi convenir à vos modules critiques de paiement, de livraison et de facturation.

Base de données et capacité du serveur

Pour PrestaShop 8 et 9.0, les minima SQL publiés sont MySQL 5.7 ou MariaDB 10.2. Les exigences de la 9.1 et de la 9.2 se vérifient séparément. Côté serveur web, ces versions demandent Apache 2.4 ou plus, et Nginx reste possible.

La mémoire PHP recommandée par script atteint au moins 256 Mo pour PrestaShop 8. Elle monte à 512 Mo minimum pour les versions 9.0, 9.1 et 9.2. Ces minima ne garantissent ni la compatibilité des modules tiers ni la performance d’un gros catalogue.

Quels contrôles effectuer sur l’hébergement ?

Relevez d’abord les versions de PrestaShop, PHP, MySQL ou MariaDB et du serveur web. Le back-office les affiche sous « Paramètres avancés → Informations ». Contrôlez ensuite ces réglages :

• Extensions et droits : extensions PHP requises et droits d’accès aux fichiers.
• Limites d’exécution : memory_limit et max_execution_time.
• Capacité : taille maximale des imports et espace disque disponible.
• Services annexes : tâches planifiées, e-mails, certificat HTTPS, DNS et accès à la base.

Si vous lancez Update Assistant en ligne de commande, comparez la version PHP de la console à celle du site web. Les deux peuvent différer sur un même serveur.

Pensez aussi à la durée de vie de votre PHP. Selon le calendrier officiel, une branche reçoit 2 ans de support actif, puis 2 ans de correctifs de sécurité critiques. Le support de sécurité s’arrête le 31 décembre 2026 pour PHP 8.2 et le 31 décembre 2027 pour PHP 8.3. Il prend fin le 31 décembre 2028 pour PHP 8.4. Pour PHP 8.5, la date est le 31 décembre 2029.

Comment valider les modules, le thème et les intégrations ?

PrestaShop 9 est une version majeure. Une partie de vos modules et de votre thème devra probablement être mise à jour. Seuls des tests réels sur une copie de la boutique confirment que vos parcours fonctionnent.

Vérifier chaque module critique

Dressez un inventaire de chaque module : version installée, éditeur, dépendances, versions de PrestaShop et de PHP prises en charge, état de maintenance et résultat en préproduction. La compatibilité annoncée par l’éditeur reste un point de départ. Elle ne remplace pas un test de vos parcours réels.

• Contrôle préalable : vérifiez la version exacte prise en charge et les dépendances, puis contactez le développeur en cas de doute.
• Mise à jour progressive : mettez les modules à jour un par un, après sauvegarde de leur configuration et de leurs fichiers.
• Code modifié : une mise à jour peut écraser des modifications faites directement dans le code d’un module.

Update Assistant propose par défaut de désactiver les modules non natifs pendant l’opération. Cette désactivation ne les rend pas compatibles. Après l’upgrade de chaque module, testez sa réactivation et ses fonctions.

Tester le thème et le parcours d’achat

Recensez séparément les personnalisations du thème, les overrides (fichiers qui remplacent le comportement natif) et les modifications du cœur. La recette couvre ensuite les fiches produits, les déclinaisons, le panier, le tunnel de commande, l’affichage mobile, les hooks et les fichiers modifiés.

Le thème Hummingbird n’est pas le thème par défaut de PrestaShop 9.0. Sa version 2.0 le devient avec la 9.1. Elle utilise Bootstrap 5.3 et du JavaScript sans jQuery : vos scripts, styles ou mises en page conçus pour Classic peuvent demander une adaptation, voire justifier une refonte de votre boutique PrestaShop.

PrestaShop 9.2 introduit un tunnel de commande natif sur une seule page. Testez vos modules de paiement et de transport sur ce parcours précis, même s’ils s’installent sans erreur.

Contrôler paiements, livraisons et connecteurs

Les flux qui touchent l’argent et la logistique méritent les tests les plus complets. Chaque catégorie a ses propres points de contrôle :

• Paiement : acceptation, refus, notifications serveur, retours vers la boutique, remboursements, paiements différés et statuts de commande.
• Livraison : tarifs par zone et poids, restrictions, points relais, étiquettes, suivi, retours et statuts.
• Fonctions commerciales : promotions, filtres, flux produits, exports comptables, consentement aux cookies et e-mails transactionnels.
• Connecteurs de gestion : authentification, API et synchronisation des commandes et des stocks.

Un changement d’intégration chez votre prestataire de paiement reste un chantier distinct de la mise à jour du cœur. La nouvelle Admin API de PrestaShop 9 facilite les intégrations, mais ses points d’accès sont encore en développement. Son authentification diffère de l’ancien Webservice : validez votre connecteur existant avant tout remplacement.

Comment sauvegarder et préparer le retour arrière ?

Une sauvegarde n’a de valeur que si elle se restaure. Préparez donc ce que vous conservez, la preuve que la restauration fonctionne et les règles de décision en cas d’incident.

Que faut-il conserver ?

Le backup préalable couvre la base de données : commandes, clients, produits, stocks, configurations et règles de prix. Il inclut aussi les fichiers de la boutique : cœur, modules, thème, images, documents et personnalisations. Update Assistant propose trois options : sauvegarde complète, sauvegarde sans images, ou aucune sauvegarde. Les deux dernières supposent une copie fiable des éléments exclus.

Update Assistant range ses sauvegardes dans autoupgrade/backup, sous le dossier d’administration. Ce dossier reste sur votre serveur. Conservez donc une autre copie hors de la boutique et du serveur de production, avec des accès limités.

Comment prouver qu’une restauration fonctionne ?

Restaurez la sauvegarde sur une préproduction. Vérifiez ensuite le back-office, les images, les commandes, les comptes clients, les modules et la configuration. Notez la durée réelle de restauration et les écarts constatés.

Des fichiers et une base copiés à des moments différents forment un état incohérent. Partez d’une copie représentative du même état de la boutique. En cas de retour arrière, restaurez ensemble fichiers, base et configuration : restaurer une seule partie peut rendre la boutique inutilisable.

Que risque-t-on après la reprise des ventes ?

Une restauration faite après la reprise des ventes peut effacer commandes, paiements, remboursements et mouvements de stock survenus depuis la sauvegarde. Rapprochez-les avant toute remise en service. Fixez aussi à l’avance un seuil d’arrêt et une heure limite de décision : commandes inaccessibles, paiement en échec, expédition bloquée. En cas d’erreur SQL ou de back-office inaccessible, analysez les journaux avant d’agir, comme le fait notre dépannage de boutiques PrestaShop, qui commence par un audit technique.

Comment réaliser la mise à jour sans perturber les ventes ?

L’opération se joue en trois temps : une répétition sur une copie, une recette complète, puis une bascule surveillée. Chaque étape a ses contrôles propres.

Répéter l’opération en préproduction

La première tentative pour mettre à jour une boutique existante se fait sur une copie représentative. Elle reproduit PHP, SQL, extensions, modules, fichiers, données et configuration de la production. Isolez-y les paiements réels, les e-mails clients, les étiquettes, les synchronisations et les tâches planifiées. Fixez ensuite la version cible, les modules concernés, les adaptations et le créneau, puis gelez tout autre changement.

• Choisir la cible et les options : Update Assistant, anciennement « 1-Click Upgrade », commence par la version visée et l’examen des options.
• Sauvegarder puis exécuter : la version 7.6.6 du module prend en charge PrestaShop 9.2.
• Contrôler : depuis la version 7, l’outil vérifie les prérequis et produit des journaux et rapports d’erreur détaillés.

Après l’essai de mise à jour de PrestaShop, examinez les journaux, les erreurs PHP, les migrations SQL, les modules désactivés ou désinstallés et les personnalisations. La recette fonctionnelle vient ensuite. L’interface en ligne de commande convient aux équipes qui maîtrisent droits, chemins, PHP de la console et journaux.

Quels tests valident la boutique ?

La recette commerciale vérifie une commande complète avec compte et en invité, le panier, les déclinaisons et les promotions. Côté paiement, reprenez les essais listés plus haut : une notification répétée ne doit pas créer deux commandes.

La recette opérationnelle couvre les frais de livraison, les taxes, les factures PDF, les e-mails de commande et de réinitialisation, les stocks et les synchronisations. Certains cas demandent une attention particulière :

• Opérations en cours : commandes en cours, paiements en attente, remboursements, expéditions partielles et paniers actifs au basculement.
• Multiboutique et multilingue : prix, taxes, devises, domaines et permissions de chaque contexte.
• Boutique B2B : tarifs contractuels et conditions de paiement propres à chaque client.
• Gros catalogue : volumes, mémoire, index et durée des traitements.

Comparez la performance avant et après dans des conditions proches. Les changements d’URL, de rendu et de thème de PrestaShop 9 imposent aussi de contrôler les pages, les balises canoniques, les balises hreflang, les données structurées et le sitemap.

Comment basculer et surveiller la production ?

Avant le déploiement, sauvegardez la production et appliquez le gel convenu des commandes. Ne levez le mode maintenance qu’après contrôle du back-office, du front-office et d’une commande de test dans un environnement de paiement adapté. Les e-mails, stocks, expéditions et journaux font aussi partie de ce contrôle. Si les URL changent, établissez avant la bascule la correspondance entre anciennes et nouvelles pages équivalentes.

Google Search Central recommande de tester le nouveau site, d’utiliser si possible des redirections permanentes 301 ou 308 et de surveiller l’indexation. Celle-ci peut prendre plusieurs semaines pour une petite ou moyenne boutique. Vérifiez que la production n’est pas restée en noindex. Surveillez ensuite transactions, erreurs HTTP, tâches planifiées et flux produits immédiatement, à 24 heures et à 7 jours.

Vos copies de test contiennent des données personnelles : protégez-les et supprimez-les dès qu’elles ne servent plus. Selon la CNIL, une violation à risque se notifie avec une notification initiale dans les 72 heures lorsque c’est possible. Vos CGV destinées aux consommateurs doivent toujours préciser produits, prix, paiement, livraison et médiation, selon Entreprendre.Service-Public.fr. Aucune obligation générale n’impose d’acheter une prestation de migration.

Foire aux questions