PrestaShop 1.6 a été la version la plus installée de l'histoire du logiciel, mais elle n'est plus maintenue par PrestaShop SA depuis la fin de son cycle de support officiel. Pour les marchands qui l'exploitent encore, la question n'est plus de savoir s'il faut migrer vers une version 8, mais comment le faire sans tout casser ni tout reconstruire inutilement. Entre changement de moteur de thème, nouvelle structure de base de données et écosystème de modules largement renouvelé, la migration 1.6 vers 8 ressemble davantage à un projet qu'à une simple mise à jour. Cet article détaille ce qui peut être conservé, ce qui doit être refait, et comment cadrer ce chantier sans dérapage budgétaire.

Pourquoi PrestaShop 1.6 pose un problème de fond en 2024

La fin de maintenance d'une version signifie l'arrêt des correctifs de sécurité officiels. Une boutique qui tourne encore sous PrestaShop 1.6 expose ses données clients, ses paiements et son référencement à des risques croissants : failles non corrigées, modules tiers abandonnés par leurs éditeurs, incompatibilité progressive avec les versions récentes de PHP et MySQL. Les hébergeurs eux-mêmes finissent par imposer des montées de version de PHP que PrestaShop 1.6 ne supporte plus correctement au-delà de PHP 7.1, selon la documentation officielle de compatibilité (developers.prestashop-project.org).

À cela s'ajoute un enjeu commercial : les modules de paiement, de marketplace ou de connecteurs ERP sont progressivement développés uniquement pour les versions 1.7 et 8. Rester sur 1.6 revient à se couper peu à peu de l'écosystème de solutions disponibles.

Quelle différence technique entre 1.6 et 8 ?

PrestaShop 8 repose sur le framework Symfony pour la quasi-totalité du back-office, alors que PrestaShop 1.6 utilisait une architecture propriétaire plus ancienne. Le thème front-office a également changé de moteur avec l'arrivée de 1.7, qui a introduit Smarty combiné à une structure de templates réorganisée. Concrètement, aucun module ni thème conçu pour 1.6 ne fonctionne nativement sur PrestaShop 8 : chaque composant doit être réinstallé dans une version compatible, ou redéveloppé.

Faut-il refaire toute la boutique pour migrer ?

La réponse dépend de trois éléments : l'état du thème actuel, le nombre de modules spécifiques développés sur mesure, et le volume de données historiques (commandes, clients, avis). Il existe trois scénarios types.

Scénario 1 : migration avec thème générique ou peu personnalisé

Si la boutique utilise un thème proche du thème par défaut ou un thème du marché peu modifié, la migration peut s'appuyer sur un nouveau thème PrestaShop 8 directement compatible, avec reprise du contenu (textes, images, catégories) sans reconstruction complète du design. C'est le scénario le plus économique.

Scénario 2 : thème fortement personnalisé ou développé sur mesure

Si le thème 1.6 a été largement modifié par un développeur (templates Smarty retouchés, CSS spécifique, modules de personnalisation front), une reprise à l'identique sur PrestaShop 8 n'est techniquement pas possible. Il faut recréer le thème sur la nouvelle architecture, ce qui équivaut de fait à une refonte du design, même si l'arborescence et les contenus sont conservés.

Scénario 3 : boutique avec développements spécifiques métier

Modules sur mesure, connecteurs ERP ou CRM, règles de tarification complexes : ces développements doivent être audités un par un. Certains peuvent être adaptés, d'autres doivent être réécrits selon les nouvelles API de PrestaShop 8. C'est souvent ce poste, plus que le thème, qui détermine le budget réel du projet.

Une migration 1.6 vers 8 ne se limite jamais à un export-import de base de données. La structure des tables a évolué entre les deux versions majeures : un script de migration dédié, testé sur un environnement de préproduction, est indispensable avant toute bascule en production.

Comment cadrer le projet sans se tromper de budget

Étape 1 : l'audit technique préalable

Avant tout chiffrage, un audit doit lister les modules installés, leur usage réel (certains sont souvent obsolètes ou inutilisés), les personnalisations du thème, et le volume de données à reprendre. Cet audit évite de payer pour recréer des fonctionnalités qui ne sont en réalité plus utilisées.

Étape 2 : la préproduction

La migration doit être testée sur une copie de la boutique, avec un nom de domaine temporaire, avant toute mise en ligne. Cette étape permet de vérifier le passage des commandes historiques, des comptes clients, du catalogue produit avec ses déclinaisons, et des redirections SEO des anciennes URLs vers les nouvelles.

Étape 3 : les redirections 301 et le SEO

PrestaShop 8 génère des URLs différentes de PrestaShop 1.6 par défaut, notamment sur la structure des fiches produit et des catégories. Sans plan de redirection 301 complet, une partie du référencement acquis sur plusieurs années peut être perdue en quelques semaines après la mise en ligne.

Étape 4 : la bascule et la surveillance post-migration

Après mise en ligne, un suivi rapproché du taux de conversion, du temps de chargement et des erreurs 404 permet de détecter rapidement les anomalies issues de la migration, avant qu'elles n'affectent durablement le chiffre d'affaires.

PHP 7.1 max
Compatibilité maximale de PrestaShop 1.6 (documentation officielle)
Symfony
Framework du back-office PrestaShop 8
3 scénarios
Niveaux de refonte possibles selon l'état du thème

Que devient le référencement pendant la migration ?

Le risque SEO est souvent sous-estimé par les marchands pressés de changer de version. Une migration mal préparée peut générer une chute de trafic organique si les URLs changent sans redirection, si les balises meta ne sont pas reprises, ou si le temps de chargement se dégrade sur le nouveau thème. À l'inverse, une migration bien cadrée est une occasion de corriger des problèmes techniques hérités de 1.6 : structure de titres, maillage interne, vitesse d'affichage mobile.

Combien de temps dure une migration 1.6 vers 8 ?

La durée varie fortement selon le scénario retenu : une migration avec thème peu modifié et peu de développements spécifiques peut se cadrer en quelques semaines, tandis qu'une boutique avec de nombreux modules sur mesure et un catalogue volumineux nécessite plusieurs mois de travail, audit compris. Le facteur déterminant n'est pas la taille de la boutique mais la complexité de ses personnalisations.

Faut-il profiter de la migration pour revoir l'expérience d'achat ?

Techniquement, la migration impose déjà de refaire le thème dans de nombreux cas. Il est alors pertinent de se poser la question de l'expérience d'achat elle-même : tunnel de commande, affichage mobile, mise en avant des produits. Profiter de la refonte technique obligatoire pour revoir ces éléments évite de payer deux fois pour deux chantiers distincts à quelques mois d'intervalle.

À l'inverse, vouloir migrer « a minima » sans aucune refonte de thème sur une boutique dont le design date de plusieurs années conduit souvent à un résultat fonctionnel mais daté, qui ne tire pas parti des apports de PrestaShop 8 en matière d'ergonomie back-office et de gestion des stocks ou des promotions.

Avant de lancer ce type de projet, un diagnostic de l'existant permet de clarifier le périmètre réel : nombre de modules à migrer, état du thème, volume de données. C'est ce diagnostic qui permet ensuite de comparer des devis de prestataires sur un périmètre comparable, plutôt que sur des hypothèses différentes.

Un besoin sur votre boutique ?

Être mis en relation avec un spécialiste de PrestaShop

Mise en relation gratuite · sans engagement · rien n'est transmis sans votre accord