Migrer PrestaShop sans interrompre les ventes
Une migration PrestaShop bien conduite ne coupe pas la boutique. La vraie difficulté n’est pas technique au sens du code : c’est l’écart de données qui se creuse entre le moment où vous préparez la nouvelle version et le moment où vous basculez dessus.
Travailler sur une copie, jamais sur le site live
La règle de départ est simple : je fais une copie complète de la boutique, fichiers et base de données, sur un environnement de test distinct. Toute la préparation, tous les tests, toutes les corrections se font sur cette copie. Le site en production continue de tourner normalement pendant ce temps, sans qu’aucune modification n’y soit apportée. Ça élimine le principal risque d’une migration mal préparée, qui est de casser la boutique en direct pendant qu’on cherche encore la bonne configuration.
Cette séparation permet aussi de prendre le temps nécessaire. Une migration peut demander plusieurs jours de vérifications, de corrections de modules ou d’ajustements de thème. Rien de tout ça n’a besoin d’affecter les visiteurs et les commandes en cours pendant que le travail avance.
Le vrai risque : l’écart de données à la bascule
Une fois la copie faite, la boutique de production continue de vivre : de nouvelles commandes arrivent, de nouveaux comptes clients se créent, le stock bouge. Entre l’instant où la copie a été prise et l’instant où la nouvelle version est mise en ligne, un décalage se crée forcément. C’est ce décalage, et non la migration elle-même, qui pose le vrai problème : si on l’ignore, la boutique bascule sur une base de données qui ne contient pas les commandes passées entre-temps.
Deux approches permettent de le gérer. La première consiste à figer les commandes juste avant la bascule finale : une fenêtre courte, annoncée à l’avance, pendant laquelle le tunnel de commande est temporairement désactivé le temps de basculer. La seconde consiste à rejouer un différentiel des commandes et comptes créés pendant la phase de test final, pour les réinjecter dans la nouvelle base avant l’ouverture au public. Le choix dépend du volume de commandes quotidien et de la tolérance à une courte pause du tunnel de commande.
Comment je prépare la bascule
-
Copie complète en environnement de test
Fichiers et base de données dupliqués sur un environnement séparé, sans aucune intervention sur le site en production.
-
Migration et vérifications sur la copie
Toute la migration de version, l’adaptation du thème et le remplacement des modules incompatibles se font sur cette copie, à mon rythme, sans pression de coupure.
-
Test complet du tunnel de commande
Avant d’ouvrir au public, je vérifie l’ajout au panier, le passage en caisse, le paiement en mode test si le moyen de paiement le permet, et la réception effective du mail de confirmation.
-
Choix d’un créneau à faible trafic
La bascule finale se programme sur un créneau où le volume de commandes est le plus bas, pour réduire au minimum le nombre de commandes concernées par l’écart de données.
-
Bascule et vérification en conditions réelles
Le site d’origine reste accessible en lecture ou en secours le temps de confirmer que la nouvelle version fonctionne correctement, avant de couper définitivement l’ancienne version.
Pour aller plus loin
-
Checklist avant migration
Tout ce qu’il faut vérifier et préparer avant de lancer une migration PrestaShop.
-
Modules incompatibles
Comment identifier et remplacer les modules qui ne migrent pas vers la nouvelle version.
-
Migration 1.7 vers 8
Le détail de ce qui change concrètement entre PrestaShop 1.7 et 8.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.