Migration PrestaShop vers Shopify : mapping modules, overrides et intégrations

Table des matières :

Inventaire technique côté PrestaShop : modules, hooks, overrides, dépendances
Mapper les modules : natif Shopify, app du store, ou développement sur mesure
Overrides PrestaShop : comment les traduire dans l’écosystème Shopify (sans accès au core)
Intégrations : passer d’un Webservice PrestaShop à l’Admin API Shopify (et survivre aux quotas)
Mapping des données : produits, variantes, clients, commandes, et champs “fantômes”
SEO, URLs, et bascule : le mapping le plus sous-estimé (et le plus violent)
Plan de cutover, tests de non-régression, monitoring post-migration

La migration PrestaShop vers Shopify échoue rarement sur l’export produits. Elle échoue sur le fonctionnel implicite : modules empilés, overrides hérités, intégrations « faites maison » et micro-règles métier injectées dans des hooks. Si vous ne mappez pas précisément ces couches, vous vous retrouvez avec une boutique Shopify “OK visuellement” mais incapable de tenir vos process (prix, stock, TVA, transport, ERP, retours, etc.).

Inventaire technique côté PrestaShop : modules, hooks, overrides, dépendances

Commencez par figer un périmètre et une version. En 2026, on rencontre encore du PrestaShop 1.7.x, mais beaucoup de parcs ont migré vers 8.1/8.2 et certains vers 9.1/9.2. Les méthodes d’audit ci-dessous sont identiques, mais les points d’attention diffèrent (ex. Symfony back-office plus présent, Admin API en 9.x). Idéalement, faites l’inventaire sur un staging cloné (DB + fichiers) et passez le front en lecture seule le temps de la collecte, sinon vous allez courir après les changements.

L’objectif n’est pas de lister “des modules”, mais de produire un mapping : besoin métier → implémentation PrestaShop → stratégie Shopify. Avant même MySQL, documentez aussi ce qui n’apparaît pas dans ps_module mais conditionne le comportement :

Thème + surcouches : thème parent/enfant, versions, overrides de templates, JS custom, bundles front.
Crons : imports (catalogue/stock), relances panier, feed marketplaces, purge cache, tâches anti-fraude.
Configuration : multi-boutique, multi-devise, règles de taxes, transporteurs, zones.
Dépendances & infra : Redis/ElasticSearch, Varnish, CDN, jobs supervisord, workers, services tiers (ex. moteur de recherche).
Conformité et données (point souvent “hors technique” mais bloquant) : bannière consentement, tags marketing, collecte d’opt-in, conservation des logs et exports (RGPD).

Pour lister les modules et leur état, vous pouvez déjà extraire une base fiable depuis MySQL :

SELECT name, version, active
FROM ps_module
ORDER BY active DESC, name ASC;

SELECT hm.id_hook, h.name AS hook_name, m.name AS module_name
FROM ps_hook_module hm
JOIN ps_hook h ON h.id_hook = hm.id_hook
JOIN ps_module m ON m.id_module = hm.id_module
ORDER BY h.name, m.name;

Corrélez ensuite avec les symptômes perf/erreurs. Un module “actif” mais greffé sur 12 hooks critiques (header, displayTop, actionDispatcher, actionFrontControllerSetMedia…) peut avoir un coût runtime non négligeable. Un moyen simple de rendre l’audit actionnable consiste à compléter votre inventaire par 3 colonnes, même manuellement :

Criticité métier (bloque la vente / impacte le panier / confort),
Surface technique (hooks front, override core, cron, dépendances),
Cible Shopify (natif / app / sur-mesure / supprimé).

Si vous avez besoin d’une méthode reproductible pour objectiver le coût hooks/SQL, appuyez-vous sur votre propre instrumentation et sur une démarche type (voir : Optimisation PrestaShop : réduire les requêtes SQL et les hooks et Audit performance PrestaShop : méthode reproductible et preuves terrain). Même si vous migrez vers Shopify (SaaS), cet audit sert à déduire quelles logiques “cachées” existent et devront être reportées.

Enfin, inventory overrides = priorité haute. Listez override/ (classes/controllers) + éventuels overrides templates dans votre thème + surcharges via modules. Dans les contextes 8.x/9.x, l’audit doit aussi inclure les routes/back-office Symfony et les services. Un point de départ propre côté PrestaShop existe déjà : Migration PrestaShop : checklist d’audit thème, modules, hooks et overrides. Ne sautez pas cette étape : Shopify ne vous laissera pas “patcher le core” a posteriori.

Astuce opérationnelle : quand vous trouvez un override, ne vous contentez pas de lister le fichier. Notez le symptôme corrigé (ex. “TVA recalculée sur adresse de livraison”, “frais de port offerts si produit X”), le déclencheur (hook / controller / méthode), et les données utilisées (tables custom, champs ajoutés). C’est exactement ce qui vous manquera au moment de reconstruire la logique sur Shopify.

Mapper les modules : natif Shopify, app du store, ou développement sur mesure

En PrestaShop, beaucoup de “modules” encapsulent des responsabilités très différentes : UI + règles métier + jobs cron + intégrations. En Shopify, vous allez éclater cette logique entre : thème (Liquid), Apps (custom app ou public app), extensions (Theme App Extensions, UI extensions), Shopify Functions (pour discounts / delivery / payment customizations selon éligibilité), et webhooks + back-end externe. La question n’est pas « quel app remplace mon module », mais « quel point d’extension Shopify couvre ma contrainte ».

Classez vos modules PrestaShop dans une matrice de décision. Exemple concret (cas réel agence) : boutique 35 modules actifs, dont 9 “invisibles” (tracking, SEO, cache, sécurité), 8 liés au checkout, 6 à l’import/catalogue, 4 à l’ERP, 3 à la recherche, 5 “marketing”. Après tri, seuls 14 modules avaient une valeur métier propre ; le reste était de l’infrastructure ou du contournement de limites du core. Ce tri réduit l’effort Shopify : ce qui était du cache/serveur (Redis, OPcache, 503…) disparaît, mais ce qui était du checkout/process doit être reconstruit proprement.

Pour éviter de tout basculer “par habitude”, utilisez une grille simple (suffisante dans 80% des cas) :

Question	Si “oui”	Conséquence fréquente
Impacte le checkout/paiement ?	Forte contrainte Shopify	Préférer natif + paramétrage ; sur-mesure seulement si B2B/contrat clair
Porte une règle de prix/TVA spécifique (France/UE) ?	Risque fiscal/UX	Spécifier précisément les cas (B2C, B2B, intracom, DOM) avant de choisir app vs Functions
Gère une donnée “source de vérité” (ERP/PIM) ?	Intégration prioritaire	Définir owner de la donnée + stratégie d’idempotence/retours d’erreurs
Est un module “infrastructure” (cache, perf, sécurité serveur) ?	Souvent inutile en SaaS	Supprimer et remplacer par configuration Shopify + bonnes pratiques front
Est purement marketing (popup, bandeau, tracking) ?	Multiples options	Attention à la performance front et au consentement (CMP)

Voici un mapping typique (à adapter, ce n’est pas une vérité universelle) :

Besoin couvert par module PrestaShop	Equivalent Shopify (stratégie)	Pièges fréquents
Paiement (PSPAY, Stripe, etc.)	Passerelle native/app + réglages Shopify Payments si éligible	Frais, pays supportés, 3DS/PSD2, remboursements partiels et split, matching des statuts
Transporteur + règles avancées	Shipping profiles + apps transporteurs + (parfois) Functions delivery	Les règles “si panier contient X alors” finissent en logique externe + cache
Règles promo complexes	Shopify Discounts + Functions (si compatible) + app	Incompatibilités avec certains scénarios (empilement, exclusions)
Recherche + facettes	Shopify Search & Discovery + app search externe si volumétrie	Synonymes, facettes avancées, scoring, latence, multi-lang
Avis produits	App avis (Judge.me, Yotpo, etc.) + import dataset	Modération, schémas SEO, conflits theme app extensions

Le point dur habituel : votre module PrestaShop “catalogue” gère attributs, combinaisons, personnalisation, champs supplémentaires, et parfois de la tarification. Shopify impose des contraintes structurantes sur la modélisation produit. Shopify documente clairement : « You can create up to 100 variants for a product. » (Shopify Help Center, limite variants). Si votre PrestaShop a des produits à 300 combinaisons (tailles/couleurs/matières), vous devez refondre : découpage produit, réduction axes, ou bascule d’une dimension en metafields / custom options gérées par app. Ce n’est pas une “option technique”, c’est un choix de modèle de données.

Mini-scenario (très fréquent en France) : un e-commerçant textile a 6 tailles × 12 couleurs × 6 longueurs = 432 déclinaisons sur PrestaShop, car l’entrepôt (WMS) attend un SKU par combinaison. Sur Shopify, vous devrez soit :

réduire le nombre d’axes “options” (max 3 options, 100 variants) en gardant uniquement ce qui déclenche un SKU,
transformer une dimension en sélection “informative” (metafield + logique d’affichage) sans impact stock,
ou découper en plusieurs produits (ex. 1 produit par longueur) pour rester sous les 100 variants, en acceptant les impacts SEO (plus de pages) et merchandising.

Overrides PrestaShop : comment les traduire dans l’écosystème Shopify (sans accès au core)

Un override PrestaShop, c’est une modification de comportement à l’exécution (classes legacy, controllers, parfois surcharge Twig/Smarty). C’est pratique, mais ça finit vite en dette : incompatibilités, conflits entre overrides, comportements non documentés. Vous avez probablement déjà vécu ce cycle ; si vous voulez cadrer proprement la dette override avant même la migration, la méthode décrite dans Module PrestaShop sans override : méthode de cadrage, tests et delivery du code est transposable… sauf que sur Shopify, vous n’aurez juste pas ce levier.

Sur Shopify, la logique est inversée : pas d’override du core, uniquement des extension points. Donc le mapping d’un override dépend de ce qu’il modifie.

Concrètement, traitez chaque override comme une spécification fonctionnelle cachée. Une méthode efficace consiste à produire, pour chaque override, une fiche courte :

Objectif métier (en une phrase),
Entrées / conditions (ex. pays de livraison, type client, montant),
Sorties (prix final, frais de port, statut commande, email),
Risque (impact légal/fiscal, impact conversion, impact logistique),
Cible Shopify (natif / Functions / app / workflow webhook + back-end).

Ensuite seulement, mappez :

Override pricing/cart (ex. surcharge Cart::getOrderTotal, ajustement TVA, remise conditionnelle) → à revoir via Discounts/Functions quand possible, sinon via app + recalcul côté back-end (avec limites) ; évitez de “réécrire le checkout” si vous n’avez pas de contrainte B2B forte.
Point d’attention UE : si votre override “corrige” des cas TVA (B2B intracom, exonérations, DOM, etc.), vous devez les formaliser en règles testables avant migration.
Override checkout / order validation → Shopify limite fortement le checkout (Checkout Extensibility). Les workflows “à la validation commande” se font via webhooks (order/create, order/paid…) + traitements asynchrones.
Exemple : ajout automatique d’un tag commande “à contrôler” si adresse ≠ pays de facturation, puis création d’un ticket support.
Override front controller / routing / redirections → Shopify gère une partie via la configuration (Redirects) et le reste via edge (CDN) ou app proxy ; attention aux redirections dynamiques.
Exemple : anciennes URLs produits avec ID (/123-produit.html) à rediriger vers /products/handle.

Pour gérer une migration progressive (très utile quand une intégration ERP est critique), le pattern “strangler” est souvent plus réaliste que le big-bang. Martin Fowler décrit le Strangler Fig pattern ainsi : « incrementally develop a new system around the edges of the old system, letting it grow until the old system is strangled » (MartinFowler.com). Appliqué ici : vous pouvez laisser PrestaShop assurer certaines fonctions back-office (ex. PIM/ERP) le temps que Shopify prenne le front, à condition d’avoir une synchronisation stock/prix fiable (voir section intégrations).
Ressource (lien externe unique) : Martin Fowler – StranglerFigApplication

Intégrations : passer d’un Webservice PrestaShop à l’Admin API Shopify (et survivre aux quotas)

Beaucoup de boutiques PrestaShop “tiennent” grâce à des intégrations : ERP (Odoo, SAP…), PIM, WMS, marketplaces, CRM, outil email, anti-fraude. La migration vers Shopify ne supprime pas ces besoins ; elle change la topologie : Shopify devient la source d’événements (webhooks) et un consommateur/émetteur API (Admin API). Le schéma robuste en 2026 reste : webhooks → queue → workers idempotents. Évitez les traitements synchrones sur réception webhook.

Un piège classique lors du passage PrestaShop → Shopify : sous-estimer le volume d’événements réels. Exemple : une simple mise à jour de commande peut déclencher plusieurs événements (paiement, fulfillment, modification d’adresse, remboursement). D’où l’importance d’une couche “queue” + worker :

Queue : absorbe les pics (soldes, opérations TV, drops).
Worker idempotent : si l’événement est rejoué (ou reçu en double), le résultat reste correct.
DLQ / dead-letter : isole les cas impossibles à traiter automatiquement (SKU inconnu, variante supprimée, etc.).

Côté limites API, Shopify impose des quotas et renvoie des 429. Le sujet n’est pas “faire moins d’appels” (même si c’est utile), mais d’implémenter retry/backoff, d’être idempotent et de batcher (GraphQL aide beaucoup). Pour cadrer proprement les 429, headers de throttling et stratégies de backoff, la logique est la même que n’importe quelle API moderne (voir : API Rate Limits : comprendre les quotas, headers de limite et erreurs 429). La différence Shopify : la limite peut être cost-based (GraphQL) et vous devez monitorer votre budget de requêtes.

Pour rendre l’intégration testable, documentez (au minimum) :

les topics webhook consommés (commandes, produits, clients, stocks),
l’action métier associée (création facture ERP, réservation stock WMS, envoi transporteur),
le statut de la commande attendu (ex. “paid” vs “fulfilled”),
le champ de corrélation (id Shopify, order number, SKU, barcode),
le SLA (temps max avant cohérence stock/prix).

Exemple de sélection de webhooks “socle” côté Shopify (à adapter) :

Domaine	Webhook	Pourquoi il est critique
Commandes	`orders/create`, `orders/paid`	Déclenchement ERP/facturation, anti-fraude, préparation
Logistique	`fulfillments/create`, `fulfillments/update`	Synchronisation WMS/transporteur, statut client
Catalogue	`products/create`, `products/update`	PIM → Shopify et Shopify → outils annexes
Stocks	`inventory_levels/update`	Cohérence disponibilité, évite la survente
Remboursements	`refunds/create`	Comptabilité, support, retours

Sécurité : ne traitez jamais un webhook Shopify sans vérifier la signature HMAC. Shopify documente ce contrôle (header X-Shopify-Hmac-Sha256 basé sur le secret de l’app). Exemple minimal en PHP (à adapter, et à tester) :

$hmacHeader = $_SERVER['HTTP_X_SHOPIFY_HMAC_SHA256'] ?? '';
$payload = file_get_contents('php://input');
$calculated = base64_encode(hash_hmac('sha256', $payload, $shopifySecret, true));
if (!hash_equals($hmacHeader, $calculated)) {
  http_response_code(401);
  exit('Invalid HMAC');
}

Si vous venez d’un connecteur type Odoo/Webservice, transposez vos bonnes pratiques (signature, rotation secrets, replay protection, DLQ). Vous avez déjà des patterns concrets côté PrestaShop : Connecteur PrestaShop Odoo : configuration Webservice, webhooks signés et sécurité et, plus général : Intégration API : synchronisation bidirectionnelle et automatisation pour forte volumétrie. Le code change, pas les invariants.

Dernier point “terrain” : en France/UE, les intégrations manipulent vite des données personnelles (adresses, emails, numéros). Profitez de la migration pour vérifier la minimisation (ne pas pousser plus que nécessaire) et la traçabilité (qui consomme quoi, où sont stockées les données), car la nouvelle architecture (apps + webhooks + workers) multiplie mécaniquement les endroits où une donnée peut transiter.

Mapping des données : produits, variantes, clients, commandes, et champs “fantômes”

Le mapping modules/overrides est inutile si votre modèle de données casse en route. PrestaShop a : produits + déclinaisons (combinations), attributs/groupes, features, personnalisations, prix spécifiques, multi-lang, multi-boutique. Shopify a : produits + variants (limités), options (3), metafields, markets (selon setup), et un modèle de taxes/paiement qui dépend de la région. Avant d’écrire un seul script d’import, faites une cartographie des champs et marquez ceux qui proviennent de modules (souvent stockés dans des tables custom).

Une table de mapping “socle” (exemple) permet déjà de repérer les zones à risque :

Donnée PrestaShop	Où c’est stocké (souvent)	Cible Shopify (fréquente)	Risque principal
Référence / SKU déclinaison	`ps_product_attribute`, `ps_product_attribute_combination`	Variant SKU	Collision SKU, règles internes WMS
EAN/UPC	champs produit/déclinaison	Barcode	Perte si pas normalisé / longueur
Prix spécifiques	`ps_specific_price`	Price lists / discounts / logique app	Règles complexes difficiles à reproduire
Attributs (couleur/taille)	groupes + attributs	Options + variants	Limites 3 options / 100 variants
Features (caractéristiques)	`ps_feature_*`	Metafields + affichage thème	Filtrage/facettes à reconstruire
Champs module “fantôme”	tables `ps_mod_*`	Metafields ou base externe	Oubli au moment des exports
Multi-lang	tables `_lang`	Traductions Shopify + Markets	Cohérence hreflang/SEO

Cas fréquent : un module PrestaShop crée des tables ps_moduleX_* et injecte des champs en front via hook ; ces champs n’existent plus en Shopify par défaut. La stratégie “Shopify-native” consiste à les porter en metafields (produits, variants, customers, orders) et à les rendre exploitables via thème/apps. La stratégie “intégration” consiste à garder la vérité dans un PIM/ERP et à n’exposer dans Shopify que le strict nécessaire. Dans les deux cas, vous devez définir le owner de la donnée : Shopify, ERP, PIM, ou une base applicative de votre custom app.

Mots de passe clients : en pratique, vous ne pouvez pas “migrer” un mot de passe PrestaShop vers Shopify tel quel (hash non compatible). Anticipez un parcours de réactivation (emails, “activer le compte”, réinitialisation), et un support renforcé la première semaine.
Commandes historiques : importer un historique complet n’a pas toujours de valeur opérationnelle ; parfois, l’historique doit rester dans un data warehouse/ERP plutôt que dans Shopify. Ce choix a un impact sur le support (SAV) et sur l’anti-fraude.

Si vous gardez PrestaShop en lecture seule (archives) derrière auth, vous évitez un import risqué. Là encore, le pattern “strangler” est souvent plus rationnel qu’un import à tout prix.

Enfin, dans un contexte France/UE, la donnée “TVA” n’est pas qu’un pourcentage : elle dépend du pays, du type de client (B2C/B2B), du type de produit et des règles que vous aviez parfois encodées via modules/overrides. Avant migration, capturez des cas de test TVA (5 à 10 scénarios réels suffisent) et exigez que Shopify + intégrations reproduisent le résultat attendu.

SEO, URLs, et bascule : le mapping le plus sous-estimé (et le plus violent)

Shopify impose des structures d’URL (ex. /products/{handle}, /collections/{handle}), là où PrestaShop laisse plus de flexibilité (catégories imbriquées, IDs, suffixes…). Donc le SEO se joue dans la matrice de redirections et dans la cohérence canonical/hreflang. Google résume la règle sans ambiguïté : « Use 301 redirects to indicate that a URL has moved permanently. » (Google Search Central, documentation sur les redirections). En pratique : exportez toutes les URLs indexables PrestaShop (produits, catégories, CMS, images critiques si besoin), mappez-les vers la nouvelle cible Shopify, et versionnez cette matrice comme un artefact de livraison.

Pour collecter les URLs à rediriger sans rater les “vraies” pages actives, combinez généralement :

Sitemap(s) PrestaShop (et ceux générés par modules SEO),
Logs (top pages sur 30/90 jours : pages produit, filtres, pages campagne),
Exports back-office (catalogue + catégories),
Search Console (pages les plus vues/cliquer, erreurs, pages indexées).

Ne vous limitez pas aux URLs “propres” : incluez les patterns de pagination, anciennes URLs réécrites, et URLs générées par modules SEO. Si vous avez du multiboutique PrestaShop, le risque contenu dupliqué/hreflang est multiplié ; lisez votre existant et vos corrections précédentes (voir : Référencement PrestaShop : optimiser fiches produits, catégories, canonical et hreflang). Même si vous quittez PrestaShop, ces règles restent vraies : canonical propre, hreflang cohérent, et pages indexables contrôlées.

Astuce pratique : pour Shopify, vous finissez souvent avec un fichier CSV de redirections (ancienne URL → nouvelle URL). Ajoutez une colonne “type” (produit/catégorie/cms) et une colonne “priorité” (trafic/CA), puis testez d’abord le top 50 pages. C’est là que se trouve l’essentiel du risque business.

La bascule DNS/HTTPS est rarement le problème sur Shopify, mais votre infra amont (domaines, emails transactionnels, sous-domaines API, tracking) peut l’être. Ne sous-estimez pas les TTL, les validations, et la cohérence des enregistrements ; si vous voulez une checklist DNS/HTTPS pragmatique côté e-commerce, elle existe déjà (voir : PrestaShop Lightsail : DNS, nom de domaine et HTTPS Let’s Encrypt) — le contexte change, mais les pièges DNS restent les mêmes.

Dernier point SEO “mécanique” : les handles Shopify (slugs) supportent mal les changements tardifs. Si votre stratégie inclut des URLs proches de l’existant (ex. conserver des segments), verrouillez vos règles de génération (accents, stop-words, translitération) avant d’importer 10 000 produits.

Plan de cutover, tests de non-régression, monitoring post-migration

Un plan de cutover sérieux inclut des tests orientés métier, pas uniquement des tests de pages. Exemple de batterie minimale : création compte, reset password, ajout panier, code promo, calcul frais de port (plusieurs zones), paiement (success/failure), remboursement partiel, email transactionnel, création retour (si existant), synchro ERP (stock décrémenté), et flux de tracking (GA4, server-side si utilisé). Pour chaque test, notez l’équivalent PrestaShop (module/hook/override) : c’est votre preuve que le mapping est complet.

Pour rendre la recette exploitable (et pas “un doc qui finit oublié”), structurez-la comme une checklist exécutable :

Pré-prod : import catalogue, import clients (ou stratégie de réactivation), configuration taxes/transport/paiement, installation apps, paramétrage consentement.
Jeu de données de test : 3 produits simples + 3 produits variantes + 1 produit “complexe” (le plus à risque), 2 codes promo, 2 transporteurs, 2 pays (FR + UE), 1 client B2C + 1 client B2B.
Scénarios de commande : panier standard, panier avec remise, panier avec livraison offerte, paiement KO, remboursement partiel, annulation.
Contrôles post-commande : emails, tags, statuts, export ERP, stock, facture si applicable.

Côté monitoring, vous perdez une partie de la visibilité “serveur” (pas de logs Apache/PHP-FPM, pas de slow query MySQL), mais vous gagnez en stabilité plateforme. Ce qui doit être monitoré devient : latence des endpoints de votre custom app, backlog queue, taux d’échec webhooks, taux 429, et santé des intégrations (ERP/WMS). Transposez vos KPI e-commerce (paiement, erreurs checkout, temps de réponse) et vos alertes (voir : Monitoring PrestaShop : KPI e-commerce, paiements et prévention des erreurs 503). Le nom change, la discipline reste.

Business : taux de conversion, taux d’abandon checkout, panier moyen, CA par canal.
Paiement : taux d’échec par méthode, temps de capture, écarts remboursements.
Logistique : délai de fulfillment, taux de rupture, taux de commandes en exception.
Intégrations : backlog queue, erreurs webhooks, temps de traitement, taux de retry, 429/min.
SEO : 404, soft-404, pages exclues, anomalies hreflang/canonical, trafic pages top.

Enfin, ne “fermez” pas PrestaShop trop vite. Gardez une archive complète (DB + media + code) et un mode consultation interne pendant quelques semaines, le temps que les litiges SAV et anomalies de données remontent. Ce n’est pas de la nostalgie : c’est un filet de sécurité pour vérifier un prix, une facture, une configuration de transport, ou un comportement historique issu d’un override. Si vous avez des intégrations critiques, documentez aussi les fallbacks (mode dégradé) et les points de bascule : c’est ce qui vous évitera de bricoler en prod à J+2.