PrestaShop 1.6 → PrestaShop 9
PrestaShop 1.6 vers 9 : ce n’est pas une mise à jour, c’est une migration.
Il n’existe pas de bouton fiable pour passer de la 1.6 à la 9. Le thème et les modules 1.6 sont incompatibles. La bonne méthode : une installation neuve de PrestaShop 9, vos données migrées et contrôlées, un thème reconstruit, des modules remplacés ou réécrits — et vos URLs, votre SEO et vos comptes clients conservés.
- Six boutiques PrestaShop suivies depuis 2022
- Installation neuve, données migrées et vérifiées
- Votre 1.6 reste en ligne jusqu’à la bascule
Pourquoi maintenant
Ce que vous risquez en restant sous PrestaShop 1.6
Une 1.6 qui tourne donne une impression de stabilité. En réalité, elle vieillit en silence, et chaque année rend la sortie plus délicate.
- La branche 1.6 n’est plus maintenue : plus aucun correctif de sécurité officiel pour le cœur.
- Elle repose sur d’anciennes versions de PHP, elles-mêmes en fin de vie. Les hébergeurs les retirent, ou les facturent en option « support étendu ».
- Les failles connues du cœur et de modules anciens sont exploitées par des robots : injection de code dans les fichiers, vol de données de paiement, envoi de spam.
- Les prestataires de paiement et les transporteurs font évoluer leurs API ; leurs modules 1.6 ne suivent plus.
- Les éditeurs de modules ont cessé de publier pour la 1.6 : chaque besoin nouveau devient un développement spécifique sur une base condamnée.
- Le thème 1.6 date d’avant les exigences actuelles de performance mobile et de Core Web Vitals.
- Les développeurs qui acceptent d’intervenir sur une 1.6 se font rares, et c’est compréhensible.
- En cas d’incident grave, vous devrez migrer dans l’urgence, c’est-à-dire dans les pires conditions.
Je ne dis pas que votre boutique va tomber demain. Je dis qu’une migration préparée coûte toujours moins qu’une migration subie.
Le point technique
Pourquoi il n’existe pas de mise à jour directe de 1.6 vers 9
Entre la 1.6 et la 9, PrestaShop a changé d’architecture. La 1.7 a introduit Symfony dans le back-office et un nouveau système de thèmes ; la 8 puis la 9 ont poursuivi ce mouvement. PrestaShop 9 repose sur Symfony 6.4 et exige PHP 8.1 au minimum.
Le thème
Un thème 1.6 ne fonctionne pas sur une version ultérieure : structure des fichiers, templates, gestion des assets, tout a changé. Il faut repartir d’un thème actuel — Classic ou Hummingbird, les thèmes officiels, ou un thème sur mesure — et y reconstruire votre identité visuelle.
Les modules
Les modules 1.6 s’appuient sur des hooks, des contrôleurs et des méthodes qui ont été modifiés ou supprimés. Certains ont une version actuelle chez leur éditeur : on la réinstalle et on reprend la configuration. D’autres n’existent plus : on cherche un équivalent, ou on réécrit la fonction. Quant aux overrides, ils ciblent des classes qui ont profondément évolué : aucun ne se reporte tel quel.
Les données
C’est la bonne nouvelle : le modèle de données est resté proche. Produits, déclinaisons, catégories, clients, adresses, commandes existent toujours dans des tables comparables, avec des colonnes ajoutées, déplacées ou supprimées au fil des versions. On peut donc migrer les données vers une base PrestaShop 9 neuve, à condition de traiter ces écarts table par table.
Enchaîner les mises à jour automatiques 1.6 → 1.7 → 8 → 9 sur la boutique existante est théoriquement imaginable, mais vous transportez alors dans la 9 des années de résidus : tables orphelines, configurations de modules disparus, fichiers obsolètes. Et le thème comme les modules sont à refaire de toute façon. L’installation neuve est plus propre, plus prévisible et plus facile à tester.
Vue d’ensemble
Le trajet de la 1.6 à la 9
La boutique 1.6 continue de vendre pendant tout le projet. Rien n’est modifié dessus avant la bascule.
- AuditDonnées, modules, overrides, SEO
- PrestaShop 9 neufPréproduction, PHP 8.1+
- Migration des donnéesCatalogue, clients, commandes
- ThèmeHummingbird, Classic ou sur mesure
- ModulesRemplacés, réécrits ou supprimés
- URLs et SEOSchéma conservé, 301 au besoin
- RecetteParcours d’achat complet
- BasculeImport final, DNS, contrôles
Étape 1
L’audit de votre 1.6
Une 1.6 en production depuis des années a une histoire : plusieurs prestataires, des modules installés puis abandonnés, des modifications faites directement dans les fichiers du cœur parce que « c’était plus rapide ». L’audit sert à retrouver tout cela avant de chiffrer quoi que ce soit.
Je compare les fichiers du cœur à la version d’origine pour repérer les modifications directes, je liste le contenu du dossier override/, je relève pour chaque module sa fonction réelle et son usage effectif. Cas fréquent : sur une quarantaine de modules installés, une bonne partie ne sert plus à rien. Autant de choses à ne pas migrer.
Je vérifie aussi l’intégrité des données : produits sans catégorie par défaut, déclinaisons orphelines, images référencées mais absentes du disque, comptes clients en double. Migrer une base sale donne une base sale, en plus récent.
Données
Ce qui est migré, et comment
Règle de base : je conserve les identifiants (id_product, id_category, id_customer, id_order). C’est ce qui permet de garder les URLs et de faire correspondre les données avec vos outils externes.
| Donnée | Traitement | Point d’attention |
|---|---|---|
| Produits | Migrés avec identifiants, références, prix, taxes, textes par langue | Colonnes ajoutées depuis la 1.6 à renseigner avec des valeurs cohérentes ; règles de taxes à recontrôler. |
| Déclinaisons | Attributs, groupes, combinaisons, impacts de prix, stock par déclinaison | Le stock est contrôlé produit par produit sur un échantillon, et en volume total. |
| Catégories | Arborescence complète, descriptions, images | Régénération de l’arbre des catégories après import. |
| Marques, fournisseurs, caractéristiques | Migrés | Pages marques à conserver si elles ont du trafic. |
| Clients, adresses, groupes | Migrés avec identifiants | Mots de passe : voir la section dédiée ci-dessous. |
| Commandes | Commandes, lignes, états, paiements, factures, avoirs | Numérotation des factures poursuivie sans trou ni doublon ; états personnalisés recréés. |
| Prix spécifiques, règles panier | Migrés puis vérifiés | Les promotions expirées depuis longtemps peuvent être laissées de côté. |
| Images et médias | Copie du dossier img/, régénération des miniatures au format du nouveau thème | Occasion de passer à des formats d’image modernes. |
| Pages CMS | Migrées | Le HTML ancien est nettoyé (styles inline, balises obsolètes). |
| Métadonnées SEO | Title, meta description, URL simplifiée de chaque fiche, par langue | Aucune régénération automatique : on garde ce qui est positionné. |
L’import est scripté et rejouable : on le lance une première fois pour construire la préproduction, puis une dernière fois à la bascule pour récupérer les commandes et les clients arrivés entre-temps.
Comptes clients
Les mots de passe clients : ce qui est possible, exactement
PrestaShop 1.6 enregistre les mots de passe sous forme d’empreinte calculée à partir du mot de passe et d’une clé propre à votre boutique, la constante _COOKIE_KEY_, définie dans config/settings.inc.php. Les versions récentes utilisent un algorithme de hachage moderne, mais elles savent encore reconnaître l’ancien format : lorsqu’un client se connecte avec une empreinte héritée, PrestaShop la vérifie avec la clé, puis réenregistre le mot de passe au format actuel.
Conséquence pratique : pour que vos clients gardent leur mot de passe, il faut reporter la clé d’origine dans la nouvelle installation (paramètre cookie_key de app/config/parameters.php) et migrer les empreintes telles quelles. Cela se fait au tout début du projet, car changer cette clé invalide les mots de passe créés entre-temps sur la nouvelle boutique, à commencer par ceux des employés du back-office.
Je teste systématiquement ce point en préproduction avec de vrais comptes. Si, pour une raison propre à votre base, la reprise n’est pas possible, le plan B est connu : email d’annonce et réinitialisation à la première connexion. Dans tous les cas, personne — ni vous, ni moi — ne peut lire les mots de passe : on ne transporte que des empreintes.
Reconstruction
Thème, modules, SEO, paiement : ce qui est refait
Thème
Base Classic ou Hummingbird adaptée à votre charte, ou thème sur mesure. Je déconseille les thèmes « tout-en-un » surchargés de modules embarqués : vous retrouveriez la dette technique que vous quittez.
Modules et équivalents
Pour chaque fonction : natif dans PrestaShop 9, version actuelle du même module, module équivalent, ou développement. Les overrides sont remplacés par des hooks et des modules propres chaque fois que c’est possible.
URLs et redirections 301
Identifiants conservés, schéma des routes reproduit dans Trafic et SEO. Attention : le format par défaut des URLs produits diffère entre la 1.6 et les versions récentes. Tout ce qui change quand même reçoit une redirection 301 directe.
Données structurées
Le balisage Product, Offer et fil d’Ariane est vérifié sur le nouveau thème avec l’outil de test des résultats enrichis. Canoniques, hreflang et sitemap contrôlés pour chaque langue.
Paiement et livraison
Modules de paiement en version actuelle, nouvelles clés, URLs de notification mises à jour, tests en mode test puis en réel. Transporteurs, tranches, zones et points relais reconfigurés et vérifiés commande par commande.
Emails et tracking
Modèles d’emails reconstruits sur le format actuel, envoi SMTP authentifié (SPF, DKIM, DMARC). GA4, Tag Manager, Meta Pixel, Google Ads et flux Merchant Center reposés et testés, avec les mêmes identifiants produits.
Méthode
Préproduction, tests, bascule, contrôle
- 01
Audit et périmètre
Inventaire complet, décisions module par module, choix du thème, devis sur un périmètre écrit.
- 02
Préproduction PrestaShop 9
Installation neuve sur un hébergement en PHP 8.1 ou supérieur, protégée par mot de passe, non indexable. La clé
cookie_keyest reportée dès ce stade. - 03
Premier import
Migration des données, régénération des images, de l’arbre des catégories et de l’index de recherche. Comparaison des volumes et contrôle d’échantillons.
- 04
Thème et modules
Reconstruction du front, installation et configuration des modules, réécriture des fonctions spécifiques.
- 05
SEO et tracking
Routes, métadonnées, redirections, données structurées, sitemap, balises de suivi, flux produits.
- 06
Recette
Commandes de test avec chaque moyen de paiement et chaque transporteur, connexion avec d’anciens comptes, emails, factures, mobile, back-office. Vous testez de votre côté avec une liste de scénarios.
- 07
Bascule
Heure creuse, 1.6 en maintenance, import final, changement DNS ou de répertoire, commande réelle de contrôle. La 1.6 reste intacte : le retour arrière est possible à tout moment.
- 08
Contrôle après migration
Suivi des 404, de la Search Console, des conversions, des emails et des journaux d’erreurs pendant les semaines qui suivent. Puis, si vous le souhaitez, maintenance pour ne plus jamais accumuler un tel retard.
Erreurs courantes
Ce qui fait dérailler une migration 1.6 → 9
- Lancer le module de mise à jour sur la 1.6 en production « pour voir ». Sans sauvegarde testée, c’est la panne assurée.
- Acheter un thème avant l’audit, puis découvrir qu’il impose ses propres modules.
- Vouloir retrouver les quarante modules d’origine au lieu de repartir des besoins.
- Renuméroter les produits ou les catégories, et casser toutes les URLs d’un coup.
- Oublier de reporter la clé
_COOKIE_KEY_: tous les clients doivent alors réinitialiser leur mot de passe. - Négliger la continuité de la numérotation des factures.
- Garder l’ancien hébergement en vieille version de PHP pour la nouvelle boutique.
- Mettre en ligne sans avoir testé un paiement réel et un email de confirmation.
- Supprimer la 1.6 dès le lendemain de la bascule.
Alternatives
Puisqu’il faut tout reconstruire, faut-il rester sur PrestaShop ?
La question est légitime : thème et modules sont à refaire dans tous les cas. C’est le moment de vérifier que PrestaShop reste la bonne plateforme pour vous.
PrestaShop 9
Logique si votre équipe maîtrise le back-office, si vous utilisez le multiboutique, des groupes de clients, des règles de prix fines ou des connexions ERP déjà construites autour de PrestaShop.
Mon expertise PrestaShopPartirVers Shopify
Pertinent si vous ne voulez plus gérer d’hébergement, de mises à jour ni de sécurité, et que votre catalogue entre dans le modèle Shopify.
Migration PrestaShop → ShopifyPartirVers WooCommerce
Pertinent si le contenu est au cœur de votre stratégie, ou si votre site tourne déjà sous WordPress.
Migration PrestaShop → WooCommercePrestaShop 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, intégrations fournisseurs, APIs transporteurs.
Parler de ma migration PrestaShop 1.6 → 9
Indiquez la version exacte de votre boutique (visible en bas du back-office), la taille du catalogue, les langues et les modules qui vous semblent indispensables. Je vous réponds personnellement.
- Aucun accès à fournir à ce stade
- Un avis franc sur la meilleure trajectoire : PrestaShop 9, Shopify ou WooCommerce
- Devis après audit, 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.6 à 9
Combien coûte une migration PrestaShop 1.6 vers 9 ?
À partir de 700 € TTC. Le montant final dépend surtout du thème (base officielle adaptée ou sur mesure), du nombre de modules à remplacer ou à réécrire, des développements spécifiques et du volume de données : je le fixe dans un devis ferme, après audit. L’audit peut prendre la forme d’un diagnostic e-commerce, au forfait de 150 €.
Le module de mise à jour en un clic ne peut-il pas faire le travail ?
Non, pas de manière fiable entre la 1.6 et la 9. Même lorsqu’une mise à jour automatique aboutit techniquement, elle ne convertit ni le thème ni les modules, et elle conserve tous les résidus accumulés dans la base. Le module de mise à jour est en revanche le bon outil pour passer de la 1.7 à la 9.
Mes URLs vont-elles changer ?
L’objectif est qu’elles ne changent pas. En conservant les identifiants et en reproduisant le schéma des routes, la plupart des URLs restent identiques. Celles qui doivent changer reçoivent une redirection 301 vers leur équivalent exact, jamais vers la page d’accueil.
Mes clients devront-ils recréer un compte ?
Non. Comptes, adresses et historique de commandes sont migrés. Pour les mots de passe, la reprise est possible en reportant la clé d’origine de la boutique dans la nouvelle installation ; je le valide en préproduction avant de vous le confirmer.
Combien de temps la boutique sera-t-elle indisponible ?
La 1.6 reste en ligne pendant tout le projet. La seule interruption est la fenêtre de bascule, planifiée à une heure creuse, le temps de l’import final et du changement de DNS.
Faut-il changer d’hébergement ?
Souvent, oui. PrestaShop 9 exige PHP 8.1 au minimum et un serveur correctement dimensionné. Beaucoup de 1.6 tournent sur des offres anciennes qui ne proposent pas ces versions, ou mal. Je vérifie ce point à l’audit et je vous indique ce qu’il faut, sans vous vendre d’hébergement.
Peut-on passer par PrestaShop 8 plutôt que la 9 ?
C’est envisageable si un module indispensable n’est pas encore disponible pour la 9. Le travail de migration est comparable, et passer ensuite de la 8 à la 9 est une vraie mise à jour, bien plus légère. L’audit tranche selon la disponibilité réelle de vos modules.
Ma 1.6 a été piratée. Peut-on migrer quand même ?
Oui, mais on commence par stabiliser la situation : nettoyage, changement des accès, vérification de la base. Seules les données sont migrées, pas les fichiers, ce qui limite le risque de transporter du code malveillant ; la base est néanmoins inspectée avant import.
Sortez de la 1.6 avant d’y être forcé.
Un audit, un périmètre écrit, une préproduction, une bascule contrôlée. Parlons de votre boutique et de la trajectoire la plus raisonnable.