Passer de PrestaShop 1.6 ou 1.7 à la 9 n'est pas une mise à jour : c'est une reconstruction de la boutique, avec reprise des données. Voici ce que cela implique réellement, dit sans enrobage.
Pourquoi ce n'est pas un bouton
Entre la 1.6 et la 9, à peu près tout ce qui compte a changé : le schéma de la base, le format des mots de passe (md5 en 1.6, bcrypt ensuite), le moteur de templates du back-office, le système de traduction, le cycle de vie des hooks. Un export/import SQL ne suffit pas — il produit une boutique qui démarre et dont plus aucun client ne peut se connecter.
Concrètement, une migration remappe des identifiants entre deux bases qui ne numérotent pas les mêmes choses de la même façon : taxes, transporteurs, catégories, états de commande, groupes de clients, langues, devises. C'est ce remappage qui prend du temps, pas la copie des fichiers.
Ce qui se migre, et ce qui se refait
Ce qui se migre
- Le catalogue : produits, déclinaisons, images, caractéristiques, fournisseurs, fabricants.
- Les clients et leurs adresses, avec rehachage des mots de passe — personne n'a besoin d'en redemander un.
- L'historique des commandes, des avoirs, des paniers abandonnés et des messages du service client.
- Les règles panier, les bons de réduction, les pages CMS.
- Les URL et les redirections SEO : c'est le point le plus sensible, et celui qu'on traite en premier.
Ce qui se refait
- Le thème. Un thème 1.6 ne se convertit pas. Sur la 9, la base saine est Hummingbird, décliné en thème enfant.
- Les modules tiers. Chacun doit exister en version compatible 9, ou être remplacé, ou être réécrit. C'est le premier inventaire à faire, avant même de parler de calendrier.
- Les surcharges accumulées dans
override/: on les reprend une par une et, le plus souvent, on les remplace par un hook propre.
Comment nous procédons
- Inventaire. On liste les modules, les surcharges, les développements maison, le volume du catalogue et des commandes. À la fin de cette étape, vous savez ce qui va coûter cher et pourquoi.
- Boutique cible. Une PrestaShop 9 neuve, sur un environnement séparé, avec sa propre base. Jamais un écrasement de la production.
- Migration à blanc. Une première passe complète des données, pour mesurer la durée réelle et découvrir les écarts. C'est là que les surprises sortent, pas le jour J.
- Recette. Vous testez sur la cible, avec vos vraies données : commandes, comptes clients, facturation, transporteurs, paiements en mode test.
- Bascule. Boutique d'origine en maintenance, dernière passe des données créées entre-temps, bascule DNS, vérification des redirections. Le retour arrière reste possible tant que la bascule n'est pas confirmée.
- Surveillance. Les jours qui suivent : journaux d'erreur, 404, pages d'indexation, premiers paiements réels.
Les pièges qu'on rencontre à chaque fois
- Le délai serveur. Sur un hébergement mutualisé, le serveur web coupe une requête au bout de soixante secondes. Une passe de migration dépasse largement ce délai, et l'échec peut passer pour un succès si personne ne regarde les compteurs. On règle ces délais avant de lancer quoi que ce soit.
- Les URL. Une migration qui casse les URL de produit coûte plus cher en trafic perdu qu'en développement. Le plan de redirections se prépare avant la bascule, pas après.
- Les modules payants. Certains éditeurs facturent la version 9 comme un nouvel achat. À budgéter dès l'inventaire.
- Les mails transactionnels. Les gabarits changent de format ; les mails personnalisés sont à reprendre.
- Le multiboutique. Il multiplie les cas de test, pas seulement les données.
Combien de temps
Le facteur déterminant n'est pas la taille du catalogue, c'est le nombre de modules tiers et de surcharges. Une boutique standard avec une dizaine de modules du marché n'a rien à voir avec une boutique portant six ans de développements spécifiques. C'est exactement ce que l'inventaire sert à trancher — et c'est pour cela que nous ne donnons pas de forfait avant de l'avoir fait.
Faut-il migrer maintenant ?
Si votre boutique tourne en 1.6, la question n'est plus commerciale mais technique : les versions de PHP qu'elle exige ne reçoivent plus de correctifs de sécurité. Si vous êtes en 1.7.8 ou en 8, vous avez le temps de préparer la migration correctement — c'est le bon moment pour faire l'inventaire, pas pour lancer les travaux dans l'urgence.
Décrivez-nous votre boutique — version actuelle, hébergeur, liste de vos modules — et nous vous répondons sur ce qui est simple et ce qui ne l'est pas. Nous écrire