PrestaShop 1.6 n'est plus maintenu depuis plusieurs années et de nombreuses boutiques tournent encore dessus, souvent par crainte du chantier de migration vers 1.7. Ce passage n'est pourtant pas optionnel à moyen terme : il conditionne la sécurité, la compatibilité des moyens de paiement et la capacité à faire évoluer le site. Voici ce qui change réellement entre les deux versions, les points de rupture les plus fréquents et une méthode pour migrer sans casser ce qui fonctionne.
Pourquoi la version 1.6 devient un point de blocage
PrestaShop 1.6 a connu sa dernière mise à jour mineure il y a plusieurs années. Le projet se concentre désormais sur les branches 1.7 et 8, documentées sur la page officielle des versions supportées (devdocs.prestashop-project.org). Rester en 1.6 signifie :
- aucune correction de faille de sécurité sur le cœur du logiciel ;
- des modules de paiement progressivement retirés de l'Addons Marketplace faute de compatibilité PCI-DSS récente ;
- une impossibilité de bénéficier des outils de front-office basés sur Symfony, utilisés par la majorité des thèmes et modules récents.
Le cumul de ces facteurs explique pourquoi un diagnostic technique préalable est indispensable avant d'entamer le chantier : il permet de savoir si la boutique peut viser 1.7 directement, ou s'il est plus pertinent de cibler une version 8 plus récente, selon l'état des modules et du thème.
Quels symptômes indiquent qu'il est temps de migrer ?
Certains signaux ne trompent pas : des modules de paiement qui refusent de s'installer, un prestataire qui refuse d'intervenir sur l'ancienne version, des alertes de sécurité répétées côté hébergeur, ou tout simplement l'impossibilité de recruter un développeur formé sur une base aussi ancienne. Ces signaux justifient de lancer un audit avant que la situation ne devienne urgente.
Ce qui change réellement entre 1.6 et 1.7
La migration 1.6 vers 1.7 n'est pas une mise à jour incrémentale comme celles qui existent entre deux versions mineures de la même branche majeure. Elle touche l'architecture logicielle elle-même.
Le passage à Symfony pour le back-office
PrestaShop 1.7 introduit le framework Symfony pour une partie croissante du back-office, en complément du moteur historique Smarty encore utilisé côté front. Cette cohabitation a des conséquences concrètes : les modules développés uniquement pour 1.6 ne fonctionnent généralement pas tels quels sur 1.7, et nécessitent une adaptation de leur code, documentée dans le guide officiel des développeurs de modules (devdocs.prestashop-project.org).
Un thème entièrement à revoir
Le système de thème change de structure : les templates Smarty évoluent, le responsive design devient natif, et la plupart des thèmes 1.6 ne sont pas compatibles en l'état. Concrètement, cela signifie qu'une boutique avec un thème sur mesure doit prévoir soit une adaptation du thème existant par un développeur qui maîtrise les deux architectures, soit une refonte graphique complète calée sur le nouveau socle technique.
La base de données et les données existantes
La structure de certaines tables évolue entre les deux versions. PrestaShop fournit un outil de migration qui gère une partie de la conversion, mais les modules tiers, les champs personnalisés et les données ajoutées par des développements spécifiques ne sont pas toujours repris automatiquement. Un inventaire précis des données à migrer (produits, clients, commandes, avis, programmes de fidélité) est un préalable technique, pas une option.
La migration vers 1.7 ne doit jamais être lancée directement sur le site en production. Elle s'effectue sur un environnement de préproduction identique, avec une copie complète de la base de données et des fichiers, afin de valider chaque étape avant bascule réelle.
Quels sont les risques concrets d'une migration mal cadrée
Perte de fonctionnalités ou de modules
Le risque le plus fréquent est la disparition silencieuse d'une fonctionnalité utilisée au quotidien : un module de gestion des stocks spécifique, une passerelle de paiement locale, un connecteur de marketplace. Si ce module n'a pas d'équivalent compatible 1.7, il faut soit en trouver un de remplacement, soit faire développer une adaptation sur mesure, ce qui a un coût et un délai à anticiper en amont du projet.
Dégradation du référencement naturel
Un changement de structure d'URL, de thème ou d'arborescence sans plan de redirection peut faire chuter le trafic organique de manière durable. Il est indispensable de cartographier les URLs existantes, de vérifier leur conservation ou leur redirection en 301, et de surveiller l'indexation après bascule via Google Search Console.
Interruption de service en période d'activité
Une migration lancée sans fenêtre de maintenance claire, en pleine période de vente, expose à une indisponibilité du site au pire moment. La bascule doit être planifiée hors pic d'activité, avec un plan de retour arrière testé au préalable.
Méthode recommandée pour sécuriser la migration
Étape 1 : l'audit technique complet
Avant tout devis, un audit doit lister : la version exacte de PrestaShop et de PHP, l'inventaire des modules installés et leur compatibilité 1.7, l'état du thème (sur mesure ou commercial), le volume de données (produits, commandes, clients), et les intégrations tierces (ERP, comptabilité, marketplace, logistique). Cet inventaire conditionne le devis et le délai réalistes du prestataire.
Étape 2 : l'environnement de test
La migration s'effectue d'abord sur un clone du site, avec une copie récente de la base de données. C'est sur cet environnement que l'on valide le fonctionnement des modules, l'affichage du thème, le tunnel de commande complet et les moyens de paiement, sans aucun impact sur la boutique en ligne réelle.
Étape 3 : la recette fonctionnelle
Une recette documentée doit vérifier, au minimum : la création de compte client, l'ajout au panier, le passage de commande avec chaque moyen de paiement actif, l'envoi des e-mails transactionnels, l'export vers la comptabilité ou l'ERP si existant, et l'affichage sur mobile. Chaque anomalie détectée à ce stade coûte infiniment moins cher qu'une anomalie découverte après bascule en production.
Étape 4 : la bascule et le suivi post-migration
La bascule finale s'effectue idéalement en dehors des heures d'ouverture commerciale, avec une sauvegarde complète juste avant. Les jours suivants, un suivi rapproché du trafic, du taux de conversion et des éventuelles erreurs techniques (logs serveur, erreurs 404) permet de détecter rapidement tout dysfonctionnement résiduel.
Faut-il viser 1.7 ou une version plus récente directement
Selon l'ancienneté du thème et des modules, il peut être plus pertinent de cibler directement une version 8, elle-même basée sur une architecture proche de 1.7 mais bénéficiant d'un support actif plus long. Ce choix dépend du diagnostic technique initial : un prestataire compétent doit être en mesure d'argumenter la version cible la plus adaptée, plutôt que de proposer systématiquement la migration la plus simple pour lui.
Aller plus loin
Pour aller plus loin, un diagnostic de maintenance permet de vérifier l'état de sécurité actuel de la boutique avant d'engager un chantier de migration, et un comparatif de performance aide à mesurer les gains attendus après bascule sur une architecture plus récente.