Migration PrestaShop : la checklist complète pour changer de plateforme sans interrompre les ventes

Vous ne migrez pas un CMS. Vous déplacez un commerce qui encaisse, prépare, expédie, rembourse et répond à des clients tous les jours. La différence est là : une migration peut être techniquement réussie et commercialement désastreuse.

La bonne question n’est donc pas « combien de produits faut-il importer ? ». C’est : quelles conditions doivent être réunies pour que la boutique continue de vendre pendant et après le changement de plateforme ?

Voici la checklist que nous utilisons pour cadrer la décision avant d’écrire une ligne de code.

1. Fixer les critères de go/no-go avant le planning

Un projet sans critères d’arrêt finit presque toujours par être mis en ligne « parce que la date est prise ». Définissez les seuils de validation avant de commencer.

Zone	Critère de go-live
Catalogue	100 % des produits vendables importés, variantes et attributs compris
Prix	règles de prix, promotions et taxes contrôlées sur un échantillon représentatif
Stock	rapprochement entre ERP, entrepôt et boutique sans écart inexpliqué
Commande	parcours complet testé du paiement à l’expédition
SEO	redirections préparées et pages stratégiques vérifiées
SAV	historiques, avoirs et informations client accessibles
Équipe	utilisateurs formés et procédure d’incident écrite

Si un critère critique n’est pas satisfait, la réponse doit être « non », même si la campagne marketing est déjà prévue.

2. Cartographier ce que PrestaShop fait vraiment chez vous

Deux boutiques PrestaShop identiques en façade peuvent avoir des fonctionnements totalement différents. L’une utilise le stock natif. L’autre reçoit les quantités d’un ERP toutes les dix minutes. Une troisième réserve le stock dans un WMS au paiement.

Listez les flux, pas seulement les modules :

qui crée et enrichit le produit ;
où vit le prix de référence ;
quel système fait foi pour le stock ;
qui reçoit la commande ;
où se produit le changement de statut ;
qui génère le numéro de suivi ;
comment les remboursements et avoirs sont traités ;
quels outils consomment les données clients.

Cette cartographie évite l’erreur classique : reproduire une interface sans reproduire le commerce.

3. Nettoyer le catalogue avant de l’importer

Une migration n’est pas une photocopieuse. Importer dix ans de doublons, de déclinaisons mortes et de catégories temporaires crée une nouvelle plateforme déjà encombrée.

Séparez les données en quatre groupes :

produits actifs et vendables ;
produits inactifs à conserver pour l’historique ;
produits à fusionner ou corriger ;
données à archiver hors de la boutique.

Contrôlez aussi les unités, EAN, SKU, règles de taxes, poids, dimensions, images, textes SEO et liaisons entre variantes. Sur un gros catalogue, l’exhaustivité se mesure avec des rapports, pas à l’œil.

Pour aller plus loin, voyez quel CMS choisir pour un gros catalogue.

4. Traiter le SEO comme un flux de données

Le SEO ne se « vérifie » pas la veille du lancement. Il faut extraire les URLs existantes, leur trafic, leurs liens entrants, leurs balises et leur statut d’indexation.

Construisez un fichier de redirection avec :

ancienne URL ;
nouvelle URL ;
type de page ;
priorité commerciale ;
trafic organique ;
code HTTP attendu ;
responsable de validation.

Chaque ancienne URL utile doit avoir une destination précise. Une redirection massive vers la page d’accueil est un abandon, pas un plan SEO.

Le plan complet est détaillé dans notre guide de migration SEO.

5. Répéter les commandes qui font mal

Le « happy path » ne suffit pas. Testez les situations qui déclenchent des tickets SAV :

paiement accepté puis commande refusée ;
produit épuisé entre panier et paiement ;
commande multi-colis ;
changement d’adresse après paiement ;
remboursement partiel ;
avoir ;
commande B2B avec tarif spécifique ;
annulation après envoi à l’entrepôt ;
numéro de suivi reçu en retard.

Chaque scénario doit produire le bon état dans la boutique, l’ERP, l’entrepôt et les emails client.

6. Organiser la bascule et le retour arrière

Une bascule sérieuse comporte cinq horaires : gel des données, dernier export, dernier rapprochement, ouverture du nouveau site et fin de surveillance renforcée.

Décidez aussi ce qui déclenche un rollback. Par exemple :

paiements non enregistrés ;
commandes non transmises à l’entrepôt ;
stock incohérent sur une famille critique ;
taux d’erreur serveur supérieur au seuil ;
redirections principales absentes.

Un retour arrière préparé coûte quelques heures. Un retour arrière improvisé peut coûter plusieurs jours de commandes.

Ce qu’on voit sur le terrain

PrestaShop fonctionne très bien chez de nombreux marchands, notamment lorsque l’équipe maîtrise ses développements et ses intégrations. Le signal de migration n’est pas « PrestaShop est mauvais ». C’est l’écart entre ce que le commerce exige et ce que l’organisation peut encore maintenir sereinement.

Les vraies fragilités apparaissent souvent entre les systèmes : statuts mis à jour manuellement, tracking saisi après coup, règles de stock implicites, dépendance à une seule personne ou à une agence.

Cloud Vapor a déjà été migré vers BOLDY. La migration d’e-fumeur est en phase finale. Cette expérience nous a appris à traiter le connecteur entrepôt comme une partie du produit, pas comme une intégration secondaire.

La checklist de la dernière semaine

catalogue rapproché par nombre, statut et valeur ;
commandes tests passées avec chaque moyen de paiement ;
stocks comparés avec la source de vérité ;
statuts et tracking testés de bout en bout ;
redirections chargées et vérifiées ;
analytics et consentement contrôlés ;
emails transactionnels relus ;
support informé des scénarios probables ;
procédure d’incident accessible ;
décision go/no-go documentée.

FAQ

Peut-on migrer sans arrêter les ventes ?

Oui, si les données qui évoluent pendant le projet sont resynchronisées au moment de la bascule et si le gel final reste court. La réponse dépend surtout des flux de commandes et de stock.

Faut-il migrer toutes les anciennes commandes ?

Pas forcément dans le nouveau moteur transactionnel, mais le SAV doit pouvoir les retrouver. Le bon choix dépend de la durée de garantie, des retours, des avoirs et des obligations comptables.

Combien de temps faut-il prévoir ?

La durée dépend moins du nombre de pages que du nombre de flux et de règles métier. Un projet cadré peut viser un planning court, mais la date ne doit jamais remplacer les critères de go/no-go.

Qui doit valider la mise en ligne ?

Le responsable métier doit porter le go/no-go, avec des preuves fournies par les équipes technique, e-commerce, finance et logistique.

Vous voulez savoir si votre migration est réellement prête ? Réservez un diagnostic de 30 minutes : nous passons vos flux et vos critères de go-live en revue, sans présentation commerciale générique.