Migration PrestaShop vers Shopify : méthode d’audit, mapping et staging

Table des matières :

1. Audit de l’existant PrestaShop : périmètre réel, dépendances et points de rupture
2. Extraction et qualification des données : SQL, Webservice, médias et contrôles d’intégrité
3. Mapping PrestaShop → Shopify : règles de transformation et limites structurelles
4. Staging Shopify : importer en bulk, valider, itérer (malgré l’absence de “vrai” staging)
5. SEO, URLs et redirections : préserver l’indexation pendant la migration
6. Runbook de cutover : freeze, migration finale, tests bout-en-bout et rollback

Audit de l’existant PrestaShop : périmètre réel, dépendances et points de rupture

Contexte de référence pour les exemples : PrestaShop 8.1.x / 9.1.x (boutiques typiques en 2026), PHP 8.2 côté front/back, MySQL 8.0 (ou MariaDB 10.6+). Objectif : cadrer une migration PrestaShop vers Shopify en évitant l’erreur classique “on exporte des produits et on verra après”. Shopify est une plateforme SaaS avec un modèle de données et des contraintes (variants, taxes, promos, checkout) qui rendent certains usages PrestaShop non transposables sans refonte.

Commencez par un inventaire fonctionnel appuyé sur des artefacts techniques. Côté PrestaShop, on ne regarde pas seulement la liste des modules installés : il faut relever les overrides (override/), les hooks réellement utilisés (ex : actionValidateOrder, displayHeader, hooks de prix), les CRON (import prix/stocks, relances, flux marketplaces) et les points d’intégration (ERP/WMS/CRM, PIM, moteur de recherche, tracking). Le but est d’identifier les “sources de vérité” : le stock est-il piloté par PrestaShop ou par un ERP ? Les prix viennent-ils d’un ERP ou d’un module de pricing ? Sans ça, le mapping Shopify sera incohérent.

Pour rendre l’audit exploitable, formalisez-le en livrables simples (et relisibles par des équipes métier) :

• Inventaire des flux (entrée/sortie) : ERP → PrestaShop (prix/stock), PrestaShop → marketplace (flux produits), WMS → PrestaShop (tracking transport), etc.
• Inventaire des personnalisations : overrides, modules maison, scripts CRON, jobs CI/CD, templates, hooks critiques.
• Matrice “fonction → dépendance → risque” : ce qui casse si le module disparaît, ce qui impacte le checkout, ce qui impacte la conformité.
• Décisions de “non-reprise” : fonctionnalités ou contenus qu’on ne migre pas (ex : vieilles pages CMS, règles promo obsolètes) pour réduire le bruit.

Sur l’audit modules, ne restez pas au niveau “nom + version”. Documentez les rôles : paiement, livraison, marketing, SEO, B2B, personnalisation catalogue. Beaucoup de fonctionnalités “standards” dans PrestaShop (règles panier complexes, cadeaux, restrictions par groupe, multi-boutique) demandent des équivalents Shopify via apps ou développement. L’article interne Migration PrestaShop vers Shopify Plus : audit modules et risques d’intégration cadre bien cette phase : la valeur n’est pas dans la liste, mais dans l’impact sur le checkout, l’API et la maintenance.

Ajoutez une couche “risque” : conformité (RGPD), sécurité (tokens API, surfaces d’attaque), et exploitation (monitoring, runbook). La migration est aussi un changement de périmètre d’hébergement : vous n’aurez plus la main sur Apache/Nginx, PHP-FPM, Varnish, Redis… mais vous aurez d’autres risques (dépendance à des apps, quotas API, limitations checkout). Si vous devez clôturer un serveur PrestaShop, l’article Résiliation hébergement PrestaShop : sauvegarde complète et plan de migration est un bon garde-fou pour ne pas perdre les dumps, médias et secrets.

Pour donner un peu de “terrain” (notamment en France/UE), intégrez dès l’audit des points de friction fréquents :

• TVA et affichage TTC/HT : qui est responsable du calcul (boutique vs ERP) ? quels arrondis (au produit, à la ligne, au total) ?
• Mentions légales / CGV / cookies : pages CMS à reprendre, bannières consentement, trace des consentements (si vous la conservez).
• Éco-participation / DEEE / consignes (selon secteur) : dans PrestaShop, c’est parfois “dissimulé” via un champ, un module, ou une surcharge de prix ; sur Shopify, il faudra décider où porter l’information (metafields, lignes séparées, apps).
• B2B : rôles de groupes clients, prix spécifiques, TVA intracommunautaire, modes de paiement (virement, paiement à échéance). Plus le B2B est central, plus le “re-design” est probable.

Extraction et qualification des données : SQL, Webservice, médias et contrôles d’intégrité

Avant de parler mapping, vous devez décider comment extraire. En pratique, sur PrestaShop, vous avez trois approches :

• Export “back-office” (souvent incomplet, peu fiable sur gros volumes, et rarement idempotent).
• Webservice PrestaShop (REST), utile pour une extraction structurée mais limité en débit/coverage.
• Extraction SQL (la plus contrôlable pour catalogue + historiques) avec scripts de validation.

Sur un catalogue sérieux (10k+ produits, déclinaisons, multi-langue), l’extraction SQL est généralement la base, avec un export fichiers pour les images.

Une bonne pratique est d’ajouter une étape “qualification” avant même le nettoyage : vous mesurez le niveau de dette data, puis vous décidez quoi corriger avant import Shopify vs après (dans Shopify) vs jamais. Exemples de KPI simples à sortir dès l’extraction :

• % de SKUs dupliqués (Shopify exige des identifiants cohérents si vous automatisez).
• % de variantes sans EAN/GTIN (si vous diffusez sur marketplaces ou Google Shopping).
• % de produits sans image ou avec images manquantes (fichiers orphelins).
• Nb de produits au-delà de 100 déclinaisons (risque structurel Shopify).
• Nb de catégories vides / profondeur max (utile pour prévoir collections et navigation).

Exemple minimal de contrôle d’intégrité côté base : vérifier que vos déclinaisons (combinaisons) sont “attachées” à un produit actif et qu’elles ont un stock cohérent. Sur PrestaShop 8/9, la vérité stock dépend de la configuration (advanced stock / stock table). Un check typique (à adapter selon votre stack stock) :

-- Produits actifs sans déclinaison mais avec attributs (incohérence fréquente)
SELECT p.id_product
FROM ps_product p
LEFT JOIN ps_product_attribute pa ON pa.id_product = p.id_product
LEFT JOIN ps_product_attribute_combination pac ON pac.id_product_attribute = pa.id_product_attribute
WHERE p.active = 1
GROUP BY p.id_product
HAVING COUNT(pa.id_product_attribute) > 0 AND COUNT(pac.id_attribute) = 0;

Ajoutez ensuite des contrôles “métier” qui évitent les imports bancals côté Shopify :

• Unicité SKU (au niveau variant) : indispensable si vous synchronisez stock/prix.
• Poids / dimensions : requis pour certains modes de livraison calculés.
• Prix : repérer prix à 0, prix négatifs, prix spécifiques incohérents, devises.
• Langues : taux de champs vides par langue (description, meta title, alt).

L’enjeu n’est pas “faire du SQL”, c’est de sortir des données importables et explicables. Shopify peut refuser des lignes, limiter des champs, ou produire des résultats inattendus si la structure source est ambiguë (variants sans option, images non accessibles, etc.). Dans une migration PrestaShop vers Shopify, vous gagnez du temps si vous imposez une étape de data cleansing : normalisation des EAN/GTIN, SKU uniques, suppression des caractères non UTF-8, dédoublonnage des URLs d’images, et consolidation des attributs.

Traitez les médias comme un chantier à part entière. PrestaShop stocke les images produit dans une arborescence par id, avec des formats dérivés (thumbnails) régénérables. Shopify attend des URLs accessibles ou des uploads via API. Prévoyez : (1) un export des originaux, (2) une stratégie de renommage stable (hash ou SKU), (3) un serveur temporaire (ou stockage objet) pour servir les images pendant l’import. Ne migrez pas les miniatures : regénérez côté Shopify via ses transformations.

Mini-scenario réaliste : une boutique a 40 000 images, mais 8–10% des fichiers référencés en base n’existent plus (nettoyages historiques, CDN mal configuré, restauration partielle). Si vous lancez l’import Shopify “tel quel”, vous aurez des produits sans image sans comprendre lesquels. Mieux : produire un rapport “id_product → image manquante”, corriger (restaurer ou supprimer la référence), puis importer.

Et si votre PrestaShop souffre déjà d’incohérences de fichiers, exécutez une maintenance avant export (voir Base de données PrestaShop : routine de maintenance et nettoyage automatisé pour la logique “nettoyage/contrôle” côté data).

Sur les données “personnelles” (clients, adresses, commandes), appliquez un filtre RGPD dès l’extraction : minimisation, conservation, base légale, et traçabilité. Un transfert vers Shopify implique un nouveau sous-traitant et souvent un nouveau modèle de consentement (emails, SMS, tracking). Pour cadrer les points de contrôle, gardez sous la main Audit RGPD PrestaShop : 88 points de contrôle pour boutiques, notamment sur la conservation des commandes et les exports destinés à un tiers.

Mapping PrestaShop → Shopify : règles de transformation et limites structurelles

Le mapping n’est pas une table statique : c’est un ensemble de règles (transformations, priorités, exceptions). Exemple : dans PrestaShop, un produit peut avoir une combinaison sans impact sur le prix (juste une option), tandis que dans Shopify, une déclinaison est un variant et s’inscrit dans un cadre strict (options/variants). Un point structurant à valider tôt : Shopify limite un produit à 100 variants. Si votre PrestaShop génère des combinaisons “matricielles” (taille × couleur × matière × pack) au-delà de 100, vous devrez casser le modèle (produits séparés, bundles, ou logique via apps).

Un mapping pragmatique pour le catalogue ressemble souvent à ceci :

PrestaShop	Shopify	Remarques techniques
Produit (ps_product)	Product	active, visibility, vendor/type à requalifier
Déclinaison (ps_product_attribute)	Variant	Options max, SKU unique, poids/stock par variant
Attributs / groupes (ps_attribute, ps_attribute_group)	Product options	Max 3 options, sinon bascule en metafields
Features (ps_feature, ps_feature_value)	Metafields	Modèle flexible, requête par API, pas “natif” pour filtres sans app
Catégories	Collections (smart/manual)	Smart collection via règles (tags, type)
Règles panier (ps_cart_rule)	Discount codes / Automatic discounts	Pas de correspondance 1:1, surtout sur cadeaux/conditions complexes

Pour éviter un mapping “théorique”, complétez ce tableau par des règles explicites. Exemple (catalogue) :

• Catégories → Collections : “catégorie principale = collection manuelle”, “catégories marketing = smart collections basées sur tags”, “catégories profondes (niveau 4+) : ne pas répliquer en navigation”.
• Marques : PrestaShop “manufacturer” → Shopify “vendor” (et décider si vous créez une collection par vendor).
• Déclinaisons : si la combinaison correspond à un choix non achetable (ex : “packaging” ou “notice”), ne pas en faire un variant ; porter l’info en metafield.
• Références : SKU = référence interne, barcode = EAN (quand disponible), et règles de fallback (ex : utiliser SKU si pas d’EAN, mais documenter l’impact sur flux externes).

Les features PrestaShop sont un cas typique : en Shopify, la donnée “structurée” se gère souvent via metafields. Shopify décrit les metafields comme des champs personnalisés pour stocker des données supplémentaires (doc dev : Shopify Dev – Metafields). En clair : vous mappez “matière”, “diamètre”, “compatibilité”, “EAN fournisseur”, etc., en metafields typés (string, number, list), au lieu de forcer ça dans les tags. Le gain : structure et intégrité. Le coût : il faut prévoir la consommation (thème, apps de filtres, search).

Point “geo” très concret (France/UE) : si vous vendez en TTC et devez afficher des informations réglementaires (ex : éco-contribution, composition, allergènes selon secteurs), le mapping doit aussi préciser où ces informations apparaissent (fiche produit, panier, facture) et qui en est responsable (donnée PIM/ERP vs saisie boutique). C’est typiquement une décision “produit + légal + technique”, pas un simple champ à migrer.

Pour les promotions, soyez brutalement réaliste : PrestaShop est très permissif (règles panier combinables, restrictions par groupe, cadeaux, transport offert conditionné, cumul multi-règles). Shopify gère des discounts, mais la logique complexe implique souvent du re-design (et parfois des apps). Prenez le temps de lister vos règles panier actuelles et de les classer : “à reproduire strictement”, “à simplifier”, “à abandonner”. Pour cadrer les tests sur le tunnel et les règles de pricing, réutilisez la logique de checklists (même si elle est orientée PrestaShop) de Contrôle PrestaShop post-modification : checklist tunnel de commande et règles panier : l’idée est de formaliser des scénarios reproductibles.

Staging Shopify : importer en bulk, valider, itérer (malgré l’absence de “vrai” staging)

Shopify n’offre pas un staging “comme sur un CMS auto-hébergé” : vous ne déployez pas une copie de prod sur un serveur. Les patterns réalistes sont : (1) une boutique de développement (ou un second store) pour les imports et les tests, (2) des thèmes non publiés avec prévisualisation, (3) une boutique protégée par mot de passe pendant la phase de recette. Si vous devez tester des intégrations (ERP, PSP, shipping), prévoir un environnement de test côté prestataires est obligatoire, sinon vous ferez de la recette en production.

Pour l’import, privilégiez des mécanismes bulk et idempotents plutôt que des imports manuels. Côté API, Shopify propose des Bulk Operations (asynchrones) pour traiter de gros volumes (doc officielle : Shopify Dev – Bulk Operations). Concrètement : vous préparez un payload (souvent via GraphQL), vous lancez un job, vous récupérez un fichier résultat, puis vous rejouez en cas d’erreur. C’est exactement ce qu’il faut pour importer 20k produits/variants sans exploser les limites de rate limiting.

Pratique : découpez vos imports en “lots” qui ont un sens métier, pas uniquement technique. Exemple de séquence itérative (qui facilite la recette) :

• Lot 1 : 50 produits “top ventes” + leurs variantes + images
• Lot 2 : reste du catalogue actif
• Lot 3 : collections + navigation
• Lot 4 : contenus (pages, blog si concerné)
• Lot 5 : redirections + SEO (meta, canonical stratégie)
• Lot 6 : clients / commandes (si vous migrez)

La validation doit être pensée comme un diff entre “source PrestaShop” et “cible Shopify”, pas comme une exploration à la main. Définissez des métriques : nombre de produits actifs, nombre de variants, taux de produits sans image, top 50 des SKUs en CA, taux de produits sans description, distribution des tags. Pour rendre ça actionnable, une grille de contrôle simple peut suffire :

Contrôle	Source	Cible	Seuil d’alerte
Produits actifs	ps_product.active=1	produits publiés	écart > 0,5%
Variants	ps_product_attribute	variants Shopify	écart > 0,5%
Produits sans image	jointure image	produits sans media	> 1%
SKUs dupliqués	agrégat SKU	agrégat SKU	> 0
Prix à 0	agrégat	agrégat	> 0 (à qualifier)

Une recette technique solide inclut : (1) vérification des prix TTC/HT selon votre stratégie taxe, (2) cohérence stock, (3) recherche (synonymes, stop words), (4) rendu front (templates, JSON-LD, performance). Sur ce dernier point, Shopify ne vous “sauvera” pas des mauvais choix front : continuez à mesurer et optimiser CWV ; les actions restent proches de ce que vous faites déjà (voir Core Web Vitals : actions concrètes pour améliorer LCP, INP et CLS).

Dernier point : la synchro “delta” avant cutover. Entre T0 (premier import) et Tcut (bascule), votre PrestaShop continue de vivre (commandes, stocks, prix). Vous avez deux stratégies : geler longtemps (souvent intenable) ou synchroniser incrémentalement. Techniquement, vous pouvez extraire des deltas via date_upd sur les tables principales (produit, stock, prix spécifiques), et rejouer des mises à jour sur Shopify via API.

Un point souvent oublié : le delta médias. Si vos équipes ajoutent/retouchent des images pendant la période de transition, prévoyez une règle (freeze médias à partir de T-? ou synchronisation) sinon vous aurez des écarts visuels difficiles à rattraper.

Si vous avez déjà de l’orchestration côté PrestaShop, capitalisez dessus (dans la même logique que Automatisation PrestaShop : orchestrer commandes, stocks et prix via MCP : séparation des flux, idempotence, logs).

SEO, URLs et redirections : préserver l’indexation pendant la migration

Le SEO d’une migration PrestaShop vers Shopify se joue sur deux axes : (1) préservation des signaux (URLs, contenu, maillage, canonicals), (2) éviter les régressions (pages introuvables, facettes indexées, duplications). Shopify impose sa logique d’URLs (/products/handle, /collections/handle), alors que PrestaShop peut avoir des structures plus flexibles (routes Symfony, legacy). Pour comprendre ce que vous migrez (et surtout ce que Google a indexé), partez de la mécanique interne PrestaShop : Génération d’URL PrestaShop : Link, routes Symfony et legacylink.

Avant de produire une table de redirections, clarifiez la “stratégie d’URL” cible :

• souhaitez-vous rapprocher les handles Shopify des anciens slugs (quand c’est possible) ?
• quelles pages ne doivent pas être réindexées (pages de recherche interne, paramètres) ?
• quels contenus doivent être consolidés (ex : 5 anciennes catégories qui deviennent 2 collections) ?

Sur les redirections, ne “devinez” pas : générez une table source → cible depuis les URLs réellement crawlées (logs, Search Console, sitemap). Google recommande d’utiliser des redirections permanentes (301) lors d’un changement d’URL (Google Search Central : Site move with URL changes). Techniquement, ça implique : (1) liste exhaustive des anciennes URLs, (2) mapping vers les nouvelles URLs Shopify, (3) validation des codes HTTP (301, pas 302), (4) absence de chaînes et boucles.

Attention : Shopify ne vous donne pas un contrôle serveur type Nginx. Les redirections se gèrent via l’admin (ou API) avec des “URL redirects” (ou des apps). Pour cadrer les contraintes et la mise en place, utilisez l’API/admin Shopify pour les imports massifs de redirections si nécessaire.

Pour des milliers d’URLs, l’API est généralement nécessaire. Prévoyez aussi la gestion des paramètres et facettes : si votre PrestaShop indexait des combinaisons/filtres (souvent une mauvaise idée), profitez de la migration pour nettoyer (noindex sur facettes, consolidation des pages quasi-duplicats, limitation des filtres crawlables).

Pour une méthodo SEO plus globale (audit + priorisation), recoupez avec SEO PrestaShop : roadmap 3 mois audit, contenu, performance et popularité : même si la cible change, la logique d’audit technique et de contenus reste la même.

Enfin, n’oubliez pas le tracking et la conformité : pixels, conversions, consentement. Sur Shopify, beaucoup d’intégrations marketing passent par des apps et des webhooks, donc plus de dépendances externes. Du point de vue sécurité, traitez les tokens Admin API, clés d’apps, webhooks, endpoints, comme des secrets d’infra (rotation, stockage chiffré, audit). Pour cadrer ce volet, vous pouvez réutiliser les réflexes de Sécurité PrestaShop : protéger API backoffice, WAF et journalisation SIEM : l’objet diffère, mais la discipline (journalisation, contrôle d’accès, durcissement) est la même.

Runbook de cutover : freeze, migration finale, tests bout-en-bout et rollback

Le cutover n’est pas “changer des DNS”. C’est une séquence orchestrée avec fenêtres, responsabilités, critères Go/No-Go et plan de retour arrière. Pré-requis minimaux : dumps DB + médias, export des configs critiques (transporteurs, taxes, modules), accès DNS, accès Search Console, et un log centralisé pour observer 404/500 post-bascule.

Ajoutez aussi des pré-requis souvent décisifs en pratique :

• Plan de communication (interne + support client) : période de maintenance, impacts comptes clients, FAQ.
• Inventaire des emails transactionnels : expéditeur, SPF/DKIM/DMARC, modèles, tests de délivrabilité.
• Validation paiement & livraison “pays réels” : notamment si vous avez des règles France métropolitaine vs DOM-TOM vs Europe.
• Critères Go/No-Go mesurables : ex “taux d’erreurs checkout < X% sur 20 tests”, “0 redirection en boucle”, “top 50 SKU OK (prix/stock/images)”.

Si vous avez une CI/CD pour le thème (ou pour vos scripts d’import), elle doit être figée/taguée pour éviter des déploiements non maîtrisés ; la logique de build reproductible décrite dans Intégration continue PrestaShop : BuildKit, GitHub Actions et build reproductible se transpose bien au thème Shopify (versionnage, artefacts, rollback).

Une séquence de cutover réaliste (à adapter) :

1. T-72h : abaisser TTL DNS, geler les changements structurels (catégories, règles panier), lancer un delta quotidien.
2. T-24h : importer delta catalogue + stock, vérifier top produits, valider paiements/livraisons en sandbox.
3. T-2h : freeze commandes sur PrestaShop (maintenance contrôlée), exporter delta final (commandes incluses si vous les migrez), exécuter import final.
4. T0 : bascule DNS, activation Shopify, push des redirections, soumission sitemap.
5. T+2h / T+24h : monitoring 404, conversion, latences, erreurs checkout.

Le point qui casse souvent : la migration des clients et des commandes. Les mots de passe ne se “migrent” généralement pas tels quels (hash + politique sécurité), donc vous devez prévoir un mécanisme de réactivation (invitation à activer le compte / reset). Les commandes historiques peuvent être importées partiellement pour l’accès au compte client, mais les statuts financiers, transactions et contraintes de conformité varient : définissez ce que vous importez (au minimum : numéro, date, lignes, total, email) et ce que vous archivez (ex : export PDF/CSV consultable en interne). L’objectif est d’éviter la fausse promesse “tout sera identique”.

Pour limiter les surprises support, préparez un “kit bascule” orienté client :

• email “Votre compte a évolué” (reset + explications)
• page d’aide “Où retrouver mes commandes ?”
• procédure SAV : comment retrouver une commande PrestaShop (lecture seule) vs Shopify

Après bascule, appliquez une discipline de vérification proche de ce que vous faites après un changement majeur sur PrestaShop : tests E2E du tunnel, règles de prix, emails transactionnels, et retours transporteurs. Pour varier la grille de scénarios sans repartir de zéro, appuyez-vous sur la checklist de contrôle du tunnel et des règles panier (même si l’implémentation est Shopify) : l’intérêt est la méthode de tests reproductibles.

Enfin, gardez un rollback crédible : conserver PrestaShop en lecture seule (au moins quelques jours), ne pas résilier l’hébergement trop tôt, et documenter précisément les changements irréversibles (DNS, emails, flux ERP) — c’est généralement ce qui fait la différence entre une migration “tendue” et une migration contrôlée. Une règle simple : si vous ne pouvez pas expliquer en 2 minutes comment revenir en arrière (et ce que vous perdez en le faisant), le cutover n’est pas prêt.