« Je voudrais juste passer en 1.7. » C’est une des demandes que je reçois le plus souvent sur PrestaShop, et c’est aussi celle où mon premier réflexe est de poser une question en retour : pourquoi la 1.7 ?
Dans la plupart des cas, la réponse est : parce que c’est la version suivante. C’est logique, et pourtant c’est rarement le bon objectif en 2026. Non pas parce que la 1.7 serait mauvaise — elle a été une excellente version — mais parce que le travail à fournir pour y arriver est presque le même que pour atteindre PrestaShop 9, qui sera encore maintenue dans plusieurs années.
Cet article détaille ce qui casse réellement entre 1.6 et 1.7, pourquoi ce saut est le plus coûteux de l’histoire de PrestaShop, et comment arbitrer.
Réponse rapide
Entre PrestaShop 1.6 et 1.7, la rupture est architecturale : le back-office passe à Symfony, le système de thèmes est entièrement nouveau, et les modules doivent être adaptés. Concrètement, votre thème 1.6 et la plupart de vos modules ne fonctionneront pas en 1.7, et les fichiers du dossier override/ doivent être réécrits ou abandonnés. L’effort porte donc sur le thème, les modules et la recette — pas sur la version cible elle-même. C’est pourquoi, à travail quasi identique, il est presque toujours plus rentable de viser PrestaShop 8 ou 9 plutôt que de s’arrêter à une 1.7 déjà en fin de parcours.
Ce qui change vraiment entre 1.6 et 1.7
Le back-office passe à Symfony
La 1.7 a amorcé la réécriture du back-office sur le framework Symfony. Deux mondes cohabitent alors : l’ancien système de contrôleurs, et le nouveau. Pour vous, utilisateur, la différence est visuelle. Pour un module qui greffait du code dans l’administration, c’est un changement de fondations.
Le système de thèmes est neuf
Les thèmes 1.7 ont une structure de dossiers différente, de nouveaux points d’accroche, un autre mécanisme d’héritage et une gestion des assets repensée. Un thème 1.6, même fortement personnalisé, ne se « convertit » pas : il se reconstruit. C’est le poste de travail le plus lourd de la migration, et le plus visible pour vos clients.
Les modules doivent être adaptés
Un module 1.6 déclare ses compatibilités, s’accroche à des hooks qui ont parfois disparu, et utilise des classes qui ont changé. Certains éditeurs ont publié une version 1.7 ; d’autres ont abandonné le produit. Pour chaque module, trois issues : la version 1.7 existe et on l’achète, une alternative maintenue existe et on bascule, ou la fonction doit être redéveloppée.
Les overrides sont à reprendre
Le dossier override/ est l’endroit où dix ans de bricolages se sont accumulés, souvent sans documentation. Ces fichiers surchargent des classes du cœur qui ont changé. Ils ne peuvent pas être copiés : il faut comprendre ce que chacun faisait, et décider s’il a encore une raison d’être.
Les URLs peuvent bouger
Selon votre configuration de 1.6 et le paramétrage de la nouvelle installation, la forme des adresses de catégories et de produits peut changer. Sans plan de redirections, c’est le référencement qui paie l’addition.
Pourquoi viser 8 ou 9 plutôt que 1.7
Faites le compte de ce qu’il faut produire pour arriver en 1.7 : un thème neuf, des modules repris un par un, des overrides réécrits, des données vérifiées, une recette complète, un plan de redirections. Maintenant, faites le compte pour arriver en 9 : exactement la même liste.
La différence de coût entre les deux cibles est marginale — quelques ajustements de compatibilité. La différence de durée de vie, elle, ne l’est pas du tout :
- Une boutique qui arrive en 1.7 aujourd’hui atterrit sur une branche dont le cycle est derrière elle. Vous rouvrirez le chantier dans un délai court.
- Une boutique qui arrive en PrestaShop 9 (socle Symfony 6.4, PHP 8.1 minimum) démarre sur la branche en cours. Les modules que vous achetez aujourd’hui y sont maintenus.
- Entre les deux, PrestaShop 8 reste un compromis raisonnable quand un module critique de votre activité n’existe pas encore en 9 — mais c’est une étape, pas une destination.
Le seul cas où s’arrêter en 1.7 se défend : un module indispensable, propriétaire et non remplaçable, qui n’existe qu’en 1.7. Dans cette situation, on le vérifie noir sur blanc avant de décider — et on planifie la suite.
Le détail de la méthode selon votre point de départ est sur les pages 1.6 vers 9 et 1.7 vers 9.
Mise à jour ou migration : la question du vocabulaire
Les deux mots désignent deux chantiers très différents, et la confusion coûte cher.
Une mise à jour conserve l’installation existante et fait évoluer le cœur sur place. C’est ce que fait l’outil officiel entre deux versions proches — par exemple d’une 8.1 vers une 8.2. Rapide, réversible avec une sauvegarde.
Une migration installe une version neuve à côté, y transfère les données, reconstruit le thème et remplace les modules. L’ancienne boutique continue de vendre pendant ce temps. C’est plus long, mais c’est la seule approche tenable quand l’écart de versions implique une rupture d’architecture.
De 1.6 vers 1.7 ou 9, vous êtes dans le second cas, quel que soit l’outil employé. Un outil qui vous promet le contraire vous promet surtout une base de données à moitié convertie — et une restauration de sauvegarde en catastrophe.
L’ordre dans lequel procéder
- Inventaire des modules, avec pour chacun : à quoi il sert réellement aujourd’hui, existe-t-il en version compatible, et que se passe-t-il si on le supprime. Ce document seul élimine souvent un tiers de la liste.
- Inventaire des overrides et des modifications de thème. Chaque fichier, son rôle, et la décision : reprendre, remplacer, abandonner.
- Inventaire des URLs indexées, avec leur trafic, exporté avant toute manipulation.
- Installation neuve de la version cible sur un sous-domaine de travail.
- Migration des données, puis contrôle par échantillons : produits à déclinaisons multiples, produits en promotion, commandes avec avoir, clients avec plusieurs adresses. Ce sont ces cas-là qui révèlent les erreurs, pas la fiche produit la plus simple.
- Thème reconstruit, mobile d’abord.
- Modules installés et paramétrés, un par un, avec un test entre chaque.
- Redirections 301 et recette complète : parcours d’achat, paiement réel, emails, exports.
- Bascule à un creux d’activité, puis surveillance des 404, de l’indexation et des paiements.
Si cette liste vous paraît longue : c’est précisément pour cela qu’il vaut mieux ne la dérouler qu’une seule fois, vers la bonne cible.
Les pièges que je rencontre le plus souvent
Le thème « presque compatible ». Un thème 1.6 qui s’installe en 1.7 sans message d’erreur n’est pas un thème compatible : c’est un thème qui affichera correctement la page d’accueil et cassera le tunnel de commande sur mobile. Testez le parcours complet, pas la vitrine.
Les modules de paiement. Ils doivent être réinstallés et reconfigurés avec les identifiants de votre compte, jamais copiés. Et la recette doit inclure un vrai paiement, puis un remboursement.
Les déclinaisons et les règles de prix. C’est là que les erreurs de migration se cachent : un prix d’attribut qui ne suit pas, une règle de réduction qui s’applique deux fois. Contrôlez un échantillon de produits complexes avant la bascule, pas après.
Les emails transactionnels. Modèles perdus, expéditeur mal configuré, messages qui partent en spam : le client ne reçoit plus sa confirmation de commande, et vous l’apprenez par un appel mécontent. Voir aussi ce que je fais côté dépannage sur ce sujet précis.
Le fichier .htaccess et les redirections. Une règle oubliée, et ce sont des milliers de pages qui renvoient une erreur. L’inventaire d’URLs sert exactement à le vérifier avant la mise en ligne.
Checklist
- Vérifier si un module critique impose réellement de s’arrêter en 1.7
- Lister les modules, leur usage réel et leur disponibilité en version cible
- Documenter chaque fichier du dossier
override/avant de migrer - Exporter les URLs indexées et leur trafic
- Installer la version cible à côté, jamais à la place
- Contrôler la migration sur des produits complexes, pas sur les plus simples
- Réinstaller et reconfigurer les modules de paiement, puis tester un vrai paiement
- Préparer les redirections 301 avant la bascule
- Surveiller 404, indexation et conversion après la mise en ligne
Questions fréquentes
L’outil de mise à jour officiel peut-il faire le 1.6 vers 1.7 ?
Il peut faire évoluer le cœur, mais il ne reconstruit ni votre thème ni vos modules — et c’est là que se trouve l’essentiel du travail. Sur une boutique réelle, chargée de modules et d’overrides, une exécution sans préparation produit le plus souvent un back-office inaccessible ou des données incohérentes. L’outil n’est pas en cause : il n’a jamais eu vocation à franchir une rupture d’architecture.
Puis-je garder mon thème 1.6 en le retouchant ?
Non. La structure des thèmes 1.7 est différente, et les points d’accroche ne correspondent plus. Ce qui se conserve, c’est votre identité visuelle — couleurs, typographies, mise en page, ton — reconstruite sur un thème moderne. Au passage, vous récupérez une base mobile et une vitesse que la 1.6 ne permettait pas.
Combien de temps la boutique est-elle arrêtée ?
Quelques minutes à une heure au moment de la bascule. Tout le reste se déroule en parallèle, sur une installation séparée : votre boutique actuelle continue de vendre jusqu’au dernier instant.
Et si je ne migre pas du tout ?
Une 1.6 fonctionnera encore un temps. Le risque n’est pas qu’elle s’arrête d’elle-même, mais qu’un élément extérieur bouge : version de PHP retirée par l’hébergeur, module de paiement abandonné, faille exploitée. À ce moment-là, vous migrez dans l’urgence, c’est-à-dire au plus mauvais moment et au plus mauvais prix.
Faut-il en profiter pour changer de plateforme ?
C’est le bon moment pour se poser la question, puisque le chantier est ouvert de toute façon. Si votre activité repose sur des spécificités PrestaShop — multiboutique, tarifs par groupe, transporteurs particuliers, liaison ERP —, restez. Sinon, comparez honnêtement avec WooCommerce ou Shopify avant de décider.