PrestaShop 1.7 → PrestaShop 9
PrestaShop 1.7 vers 9, sans mauvaise surprise en production.
De la 1.7 à la 9, la mise à jour passe par le module officiel — Update Assistant, l’ancien 1-Click Upgrade. L’outil fait sa part. Ce qu’il ne fait pas : vérifier que vos modules, votre thème et vos overrides survivront. C’est ce travail d’audit, de préproduction et de contrôle que je prends en charge.
- Six boutiques PrestaShop suivies depuis 2022
- Toujours en préproduction d’abord
- Plan de retour arrière écrit et testé
Pourquoi, et quand
Pourquoi quitter la 1.7, et à quel moment le faire
La branche 1.7 n’est plus celle sur laquelle PrestaShop concentre ses efforts : les correctifs, les évolutions et les nouveaux modules visent les versions 8 et 9. Rester en 1.7, c’est aussi rester sur des versions de PHP qui sortent du support, avec ce que cela implique côté sécurité et côté hébergeur. PrestaShop 9 apporte un socle Symfony 6.4, PHP 8.1 et supérieur, un back-office largement modernisé et une nouvelle API d’administration.
Contrairement au passage de la 1.6 à la 9, vous n’avez pas à reconstruire la boutique : l’architecture des thèmes et des modules est restée dans la même famille depuis la 1.7. Vos données restent en place, votre thème peut souvent être adapté, une bonne partie de vos modules a une version compatible.
Le bon moment : une période commerciale calme, après avoir vérifié que vos modules indispensables existent pour la 9. Le mauvais moment : à trois semaines d’un temps fort, ou le jour où l’hébergeur retire votre version de PHP. Si un module critique n’est pas encore disponible pour la 9, s’arrêter provisoirement en version 8 est une option parfaitement défendable.
Vue d’ensemble
Le trajet de la 1.7 à la 9
Tout est d’abord réalisé sur une copie. La production n’est touchée qu’une fois le scénario déroulé sans erreur.
- AuditModules, thème, overrides, PHP
- PréproductionCopie fidèle fichiers + base
- NettoyageModules inutiles, overrides
- PalierDernière 1.7, puis 8 si besoin
- Mise à jour vers 9Update Assistant, PHP 8.1+
- CorrectionsThème, modules, erreurs
- RecetteParcours d’achat, back-office
- ProductionSauvegarde, mise à jour, contrôles
Étape 1
L’audit de compatibilité : ce que je vérifie avant de toucher à quoi que ce soit
Le module de mise à jour met à jour le cœur de PrestaShop. Tout ce qui a été ajouté autour reste sous votre responsabilité.
| Élément | Ce que je contrôle | Décisions possibles |
|---|---|---|
| Version exacte | Version mineure de la 1.7, historique des mises à jour précédentes, état de la base | Passage préalable à la dernière version de la branche 1.7. |
| PHP et serveur | Version de PHP actuelle, versions proposées par l’hébergeur, extensions, limites mémoire et temps d’exécution, version de MySQL ou MariaDB | Changement de version de PHP au bon moment du trajet, voire changement d’offre d’hébergement. |
| Modules | Pour chaque module actif : éditeur, version installée, existence d’une version annoncée compatible PrestaShop 9 et PHP 8.1+ | Mettre à jour, remplacer, réécrire, ou supprimer s’il ne sert plus. |
| Modules natifs | Modules fournis avec PrestaShop, parfois très en retard | Mise à jour avant la montée de version. |
| Thème | Thème Classic, thème enfant, thème du marché ou sur mesure ; templates surchargés, modules embarqués | Adapter le thème, obtenir la version compatible auprès de l’éditeur, ou repartir d’une base officielle (Classic ou Hummingbird). |
| Overrides | Contenu du dossier override/ : classes et contrôleurs surchargés, et par quel module | Supprimer, ou remplacer par un hook dans un module propre. Un override de contrôleur du back-office a peu de chances de survivre : ces pages ont été migrées vers Symfony. |
| Modifications du cœur | Comparaison des fichiers du cœur avec la version d’origine | Tout ce qui a été modifié directement sera écrasé : on le sort dans un module. |
| Connexions externes | Webservice, ERP, logistique, marketplaces, flux | Tests dédiés après mise à jour, clés et droits vérifiés. |
À l’issue de l’audit, vous recevez la liste des points bloquants, le trajet de versions recommandé et un devis sur un périmètre écrit.
Trajet de versions
Pourquoi passer par paliers
Le module de mise à jour sait enchaîner les scripts de migration de base de données d’une version à l’autre. La difficulté est ailleurs : PHP. Une 1.7 tourne sur d’anciennes versions de PHP ; PrestaShop 9 exige PHP 8.1 au minimum. Selon votre version mineure, il n’existe généralement pas de version de PHP sur laquelle la boutique de départ et la boutique d’arrivée fonctionnent toutes les deux correctement.
D’où le trajet que j’applique le plus souvent : mise à niveau vers la dernière version de la branche 1.7, passage en PrestaShop 8 — qui accepte à la fois des versions de PHP compatibles avec la 1.7 et PHP 8.1 —, changement de version de PHP, puis mise à jour vers la 9. Chaque palier est une étape testable : si quelque chose casse, on sait à quel moment et pourquoi.
Deux précisions pratiques. Le module de mise à jour doit lui-même être à jour avant de commencer. Et sur une boutique volumineuse, je le lance en ligne de commande plutôt que depuis le navigateur : pas de délai d’expiration, et un journal complet de ce qui s’est passé.
Données et fonctionnalités
Ce que devient chaque élément de la boutique pendant la mise à jour
Vos données ne sont pas déplacées : la base est transformée en place. Cela ne dispense pas de contrôler chaque famille de données après coup.
| Élément | Ce qui se passe | Ce que je contrôle ensuite |
|---|---|---|
| Produits et déclinaisons | Conservés ; la structure des tables est ajustée par les scripts de mise à jour | Prix, taxes, stocks par déclinaison, prix spécifiques, produits désactivés, comparaison des volumes avant et après. |
| Catégories | Conservées | Arborescence, menus, navigation à facettes réindexée. |
| Clients et comptes | Conservés, mots de passe compris | Connexion avec des comptes existants, groupes, adresses, espace client. |
| Commandes | Conservées avec factures, avoirs et états | Numérotation des factures, génération des PDF, états personnalisés, emails liés aux états. |
| Images et médias | Fichiers inchangés | Régénération des miniatures si le thème change, formats d’image. |
| URLs | Identifiants et routes conservés | Exploration complète avant et après : toute URL qui change reçoit une redirection 301. |
| Métadonnées SEO | Conservées | Title, meta description, canoniques, hreflang, robots.txt, sitemap XML régénéré. |
| Données structurées | Dépendent du thème et des modules | Balisage Product, Offer et fil d’Ariane testé sur le thème mis à jour. |
| Tracking | Dépend des modules et du thème | GA4, Tag Manager, Meta Pixel, Google Ads : événements e-commerce vérifiés sur une commande de test. Flux Merchant Center contrôlé. |
| Paiement | Modules à mettre à jour vers leur version compatible | Paiement en mode test puis en réel, retour de notification, création de la commande, remboursement. |
| Livraison | Transporteurs conservés | Tarifs par tranches et par zones, points relais, génération d’étiquettes, suivi. |
| Emails | Modèles du cœur mis à jour ; vos personnalisations peuvent être écrasées | Sauvegarde des modèles personnalisés, réintégration, tests d’envoi et de délivrabilité. |
Méthode
De la préproduction à la production
- 01
Audit de compatibilité
Modules, thème, overrides, PHP, hébergement. Vous savez avant de commencer ce qui passera, ce qui devra être remplacé et ce que cela représente.
- 02
Préproduction fidèle
Copie intégrale des fichiers et de la base sur un environnement identique à la production, protégé par mot de passe et non indexable. Emails sortants neutralisés et modules de paiement en mode test, pour ne jamais écrire à un vrai client.
- 03
Nettoyage
Désinstallation des modules inutilisés, suppression des overrides morts, mise à jour des modules conservés. Moins il y a de code tiers au moment de la mise à jour, moins il y a de surprises.
- 04
Mise à jour par paliers
Dernière 1.7, version 8, changement de PHP, version 9. Journaux lus et erreurs corrigées à chaque étape. Le déroulé exact est consigné : c’est lui qui sera rejoué en production.
- 05
Corrections
Adaptation du thème, remplacement des modules incompatibles, réécriture des overrides en modules, traitement des dépréciations PHP 8.
- 06
Recette
Parcours d’achat complet sur mobile et ordinateur, chaque moyen de paiement, chaque transporteur, codes promo, emails, factures, back-office, connexions externes. Vous validez de votre côté avec une liste de scénarios.
- 07
Mise à jour de la production
À une heure creuse, boutique en maintenance : sauvegarde complète, déroulé rejoué, contrôles, commande réelle, réouverture. Les modifications faites en préproduction (thème, modules) sont déployées en même temps.
- 08
Contrôle après migration
Surveillance des journaux d’erreurs, des 404, de la Search Console, des conversions et des emails dans les jours et semaines qui suivent.
Filet de sécurité
Le plan de retour arrière
Le module de mise à jour propose sa propre sauvegarde et une fonction de restauration. Je ne m’appuie jamais dessus seule : sur une grosse base, une sauvegarde faite en PHP peut être incomplète sans que rien ne le signale. Avant toute intervention en production, je réalise une sauvegarde indépendante — export de la base avec mysqldump, archive des fichiers, ou instantané du serveur quand l’hébergeur le permet — et je vérifie qu’elle se restaure.
Le plan de retour arrière est écrit à l’avance : qui décide, sur quels critères, en combien de temps, et ce qu’on fait des commandes éventuellement passées entre-temps. La règle est simple : si les contrôles ne sont pas tous verts à la fin de la fenêtre prévue, on restaure, on analyse au calme et on replanifie. Une mise à jour reportée n’a jamais fait perdre de chiffre d’affaires ; une boutique bancale en production, si.
Erreurs courantes
Ce qui transforme une mise à jour en panne
- Cliquer sur « Mettre à jour » directement en production, sans copie ni sauvegarde testée.
- Changer la version de PHP chez l’hébergeur avant la mise à jour : la 1.7 tombe en erreur 500.
- Laisser actifs pendant la mise à jour des modules dont personne ne connaît l’origine.
- Ignorer le dossier
override/: une classe surchargée incompatible suffit à produire une page blanche. - Oublier que les modèles d’emails et certains fichiers personnalisés sont écrasés par la mise à jour.
- Tester uniquement la page d’accueil, et découvrir trois jours plus tard que les notifications de paiement n’arrivent plus.
- Conserver un thème du marché abandonné par son éditeur en espérant qu’il « passe ».
- Laisser la préproduction envoyer de vrais emails aux clients, ou être indexée par Google.
- Ne pas vider
var/cacheaprès l’opération et diagnostiquer des erreurs qui n’existent plus.
Si vous lisez cette page parce que la mise à jour a déjà mal tourné, passez directement par le dépannage : ne relancez rien avant qu’on ait regardé les journaux.
PrestaShop au quotidien
Depuis 2022, j’assure la maintenance, le développement et les évolutions techniques des six boutiques PrestaShop d’Aliénor de Bazard : modules personnalisés, landing pages, intégrations fournisseurs, APIs transporteurs.
Parler de ma mise à jour PrestaShop 1.7 → 9
Indiquez votre version exacte (en bas du back-office), votre version de PHP si vous la connaissez, votre thème et les modules auxquels vous tenez. Je vous réponds personnellement.
- Aucun accès à fournir à ce stade
- Un avis franc : 9 tout de suite, palier en 8, ou autre trajectoire
- Devis après audit de compatibilité, sur un périmètre écrit
Pour en parler de vive voix : réservez un créneau.
Questions fréquentes sur le passage de PrestaShop 1.7 à 9
Combien coûte une mise à jour de PrestaShop 1.7 vers 9 ?
À partir de 600 € TTC. L’écart entre deux boutiques est considérable : une 1.7 proche du standard, avec un thème Classic et des modules maintenus, n’a rien à voir avec une boutique chargée d’overrides et de modules abandonnés. Le montant final est fixé dans un devis ferme, après audit de compatibilité. L’audit peut prendre la forme d’un diagnostic e-commerce, au forfait de 150 €.
Peut-on passer directement de la 1.7 à la 9 ?
Tout dépend de votre version mineure et de votre version de PHP. En pratique, la contrainte PHP impose le plus souvent un palier par PrestaShop 8, et je préfère de toute façon des étapes testables à un grand saut. Le trajet exact est défini à l’audit, puis validé en préproduction.
Mon thème 1.7 fonctionnera-t-il sous PrestaShop 9 ?
Pas forcément tel quel. Le système de thèmes est de la même famille, mais les templates du cœur et certains modules natifs ont évolué. Un thème enfant de Classic s’adapte généralement bien ; un thème du marché dépend de son éditeur. C’est un des premiers points tranchés en préproduction.
Que deviennent mes modules ?
Chacun est vérifié : version compatible à installer, équivalent à trouver, réécriture, ou suppression. Les modules maison et les overrides sont relus pour PHP 8.1+ et pour les changements du cœur. Je ne fais confiance à une mention « compatible » qu’après l’avoir testée sur votre préproduction.
Y a-t-il un risque pour mon référencement ?
Bien moindre que lors d’un changement de plateforme : identifiants, URLs et métadonnées restent en place. Les risques réels viennent du thème (balisage, vitesse, contenu masqué) et d’éventuelles routes modifiées. Je compare une exploration complète du site avant et après, et je redirige en 301 ce qui a bougé. Voir aussi SEO e-commerce.
Combien de temps la boutique sera-t-elle fermée ?
Uniquement pendant la fenêtre de mise à jour de la production, planifiée à une heure creuse. Sa durée est connue à l’avance, puisque le même déroulé a déjà été chronométré en préproduction.
Puis-je faire la mise à jour moi-même ?
Sur une boutique simple, avec une vraie préproduction et une sauvegarde que vous savez restaurer, c’est faisable. Le module est bien conçu. Ce qui pose problème n’est pas le clic, c’est tout ce qui l’entoure : compatibilité, overrides, PHP, contrôles. Si vous bloquez en route, je peux reprendre à partir de votre préproduction.
Et si ma boutique est encore en 1.6 ?
Le cas est différent : il n’y a pas de mise à jour fiable, il faut une migration de données vers une installation neuve. Tout est expliqué sur la page PrestaShop 1.6 vers 9.
Une mise à jour réussie est une mise à jour déjà faite une fois.
Audit de compatibilité, préproduction, paliers, retour arrière prévu. Parlons de votre boutique et du trajet le plus sûr vers PrestaShop 9.