Migration PrestaShop vers Shopify Plus : audit modules et risques d’intégration

Table des matières :

1. Périmètre réel d’une migration PrestaShop vers Shopify Plus : les modules comme « surface d’attaque »
2. Construire un inventaire fiable : modules, overrides, hooks, schéma BDD, jobs
3. Cartographier les intégrations : paiements, logistique, ERP/CRM, marketing, data
4. Risques d’intégration spécifiques à Shopify Plus : modèle de données, API, checkout, limites SaaS
5. Remplacer la logique modules : stratégies Apps/Functions/middleware et critères de décision
6. Verrouiller la bascule : SEO, perf, RGPD, observabilité, rollback

Périmètre réel d’une migration PrestaShop vers Shopify Plus : les modules comme « surface d’attaque »

Une migration PrestaShop vers Shopify Plus échoue rarement sur l’export catalogue “de base”. Elle échoue sur ce que la boutique a réellement codé dans les modules, les overrides, les hooks, et les jobs qui tournent en dehors du parcours utilisateur. Sur PrestaShop (typiquement 1.7 → 8.x/9.x), beaucoup de logique métier est injectée via hookActionValidateOrder, actionProductUpdate, displayHeader, des overrides de Cart, Order, Carrier, ou des scripts cron.php planqués dans /modules/*/. En face, Shopify Plus impose un modèle SaaS : pas d’accès SQL, pas d’override PHP, pas de patch core. On passe d’un système “hackable” à un système “API-first”.

Le risque majeur n’est pas « une fonctionnalité manque », mais où se trouve la vérité. Sur PrestaShop, vous avez souvent plusieurs sources : règles de prix en base, module promo qui surcharge le calcul, module ERP qui écrase les stocks toutes les 10 minutes, module transport qui modifie l’adresse, module paiement qui détourne les statuts, etc. Avant même de parler Shopify, l’audit doit répondre à une question simple : quels composants écrivent dans la base PrestaShop et à quel moment ? Sans ça, vous migrez des données incohérentes et vous reproduisez les bugs côté Shopify.

Exemple concret (fréquent en France/Europe) : un ERP pousse les stocks par SKU toutes les 15 minutes, un module marketplace “réserve” des quantités à la création de commande, et un module de retours “réinjecte” du stock à la validation d’un RMA. Au quotidien, ça “tient” parce que les collisions sont rares et que l’équipe corrige à la main. Pendant une migration, vous augmentez brutalement la fréquence des écritures (exports, imports, resynchronisations), et vous révélez des incohérences : stocks négatifs, commandes acceptées puis annulées par manque, ou écarts entre stock “disponible” et stock “physique”.

Sur le plan technique, le point dur est que PrestaShop tolère (et même encourage historiquement) des extensions intrusives : overrides, modifications de templates, surcharges de contrôleurs, JS injecté via hook, etc. Ce “pouvoir” facilite l’accumulation de dette. Shopify Plus, lui, canalise la personnalisation : thème (Liquid), apps, webhooks, Admin API (REST/GraphQL), Shopify Functions pour certaines règles.

“Liquid is a template language created by Shopify.” — Shopify Dev Docs (Liquid)

Traduction opérationnelle : Liquid rend du HTML, mais ne remplace pas votre logique back-office/ERP. Toute règle “invisible” (priorisation de stocks multi-entrepôts, exclusion transporteur par famille produit, plafonnement de remise B2B, calcul d’écotaxe, arrondis spécifiques) doit être relocalisée : dans une app, dans Functions, dans un middleware, ou dans l’ERP/OMS.

Une bonne pratique d’audit (simple mais efficace) est de transformer “les modules” en zones de risque. Par exemple :

Zone	Symptôme typique	Risque en migration
Paiement & fraude	statuts détournés, callbacks non loggés	commandes “fantômes”, rapprochement impossible
Stock & prix	écritures concurrentes, imports sans idempotence	incohérences catalogue, erreurs de disponibilité
Transport	adresses normalisées, règles par code postal	erreurs de taux, étiquettes incorrectes
Tracking/Marketing	scripts injectés via hook, consentement approximatif	régression Core Web Vitals / non-conformité cookies

L’objectif n’est pas de “blâmer” PrestaShop : c’est d’éviter de reconstruire à l’identique une architecture implicite et fragile, alors que Shopify Plus vous oblige à rendre cette architecture explicite.

Construire un inventaire fiable : modules, overrides, hooks, schéma BDD, jobs

L’audit modules n’est pas une liste “Installé/Non installé” dans le back-office. Il faut produire un inventaire reproductible, versionné et diffable (même approche que pour un build reproductible). Si votre PrestaShop est en 8.1/9.1 sous PHP 8.2 (cas courant en 2026), partez d’un snapshot code + base. L’article Résiliation hébergement PrestaShop : sauvegarde complète et plan de migration donne une méthode de sauvegarde exploitable avant extraction et gel des changements.

Commencez par un export “source de vérité” côté base et filesystem, puis recoupez :

• Modules (base) :

  SELECT name, version, active, date_add, date_upd
  FROM ps_module
  ORDER BY active DESC, name;

• Hooks réellement utilisés (pour voir la surface d’exécution) :

  SELECT h.name AS hook, m.name AS module
  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;

• Overrides (filesystem) : inventaire de /override/ + diff avec le core (classes/, controllers/). Un override “ancien” peut survivre à plusieurs upgrades et casser silencieusement des comportements.
• Tâches planifiées : cherchez des cron.php, des endpoints “tokenisés”, ou des tables de modules type ps_cronjobs (si présent) ; corrélez avec votre crontab système.

Pour éviter un inventaire “théorique”, ajoutez un contrôle terrain : quels modules sont réellement exécutés sur un cycle de commande (ajout panier → paiement → création commande → expédition → retour) ? Beaucoup de boutiques ont des modules installés mais non actifs, et d’autres “actifs” mais jamais appelés, parce que le hook a changé ou que le thème n’affiche pas la zone.

Un complément utile (souvent oublié) : l’inventaire des tables créées par les modules et leur criticité. Dans une boutique mature, vous trouverez typiquement :

• des tables “cache” (recalculables),
• des tables “métier” (ex. mapping ERP ↔ PrestaShop, journaux d’échanges),
• des tables “configuration” (à migrer, mais pas au même titre que le catalogue).

Ensuite, produisez une fiche par module (même pour les modules “officiels”) avec au minimum : hooks utilisés, classes surchargées, tables créées, endpoints exposés, appels sortants, dépendances (composer, libs), et criticité. Pour rendre la fiche actionnable, une grille minimale fonctionne bien :

• Rôle (paiement / stock / marketing / SAV / SEO / BO…)
• Source de vérité touchée (prix, stock, statut commande, TVA, transport…)
• Écritures (tables et champs modifiés ; fréquence ; conditions)
• Entrées (webhook/callback, cron, import, action BO/FO)
• Sorties (API externes, emails, exports)
• Observabilité (logs, alertes, retry, idempotence)
• Conformité (données personnelles manipulées ? consentement ?)

Pour industrialiser l’analyse, n’hésitez pas à passer du statique : phpstan pour identifier les points d’entrée, rector pour détecter des patterns obsolètes, et du grep ciblé sur les hooks “sensibles” (commande, paiement, stock). Si vous cherchez à fiabiliser votre chaîne d’audit, vous pouvez reprendre des principes de CI décrits ici (même si vous migrez ensuite hors PrestaShop) : Intégration continue PrestaShop : build reproductible

Enfin, ajoutez une couche “réalité opérationnelle” : quelles pages BO/FO sont impactées, et quelles erreurs apparaissent en prod. Les migrations font remonter des comportements jamais observés car masqués par le cache, une erreur PHP silencieuse, ou une page partiellement rendue. Pour éviter les faux négatifs, instrumentez les anomalies de rendu et les pages blanches avant audit fonctionnel : Page vide : détection erreurs de rendu et Contenu de page vide : checklist d’audit

Cartographier les intégrations : paiements, logistique, ERP/CRM, marketing, data

Un audit modules sérieux doit sortir du code et produire une cartographie des flux. Dans 80% des boutiques matures, les modules sont des adaptateurs : ERP (stocks/prix), OMS, WMS, PIM, outil CRM, marketing automation, tracking server-side, marketplaces. En PrestaShop, ces flux sont fréquemment “best-effort” : scripts cron sans idempotence, import CSV incrémental, Webservice API sans stratégie de retry, et logs inexistants. Le résultat : la boutique “marche” tant que personne ne la change. Une migration, elle, change tout.

Méthode pragmatique : partez des événements métier et demandez « qui publie / qui consomme ». Exemple minimal :

• Commande créée : actionValidateOrder → ERP (création), OMS (fulfillment), outil d’email transactionnel, anti-fraude.
• Stock : ERP/WMS → PrestaShop (écrase ps_stock_available) + éventuelles règles par entrepôt.
• Prix : ERP/PIM → PrestaShop (prix de base) + modules de remise + règles spécifiques (B2B).
• Expédition : transporteur → PrestaShop (numéro de suivi, statut) + email client.

Ajoutez une couche “qualité de flux” : que se passe-t-il si l’ERP ne répond pas ? et que se passe-t-il si la même commande est envoyée deux fois ? Cette simple question distingue une intégration robuste (idempotente, traçable) d’un bricolage dangereux (doublons, trous de stock, statuts incohérents).

Chaque intégration doit être auditée sur : protocole (SOAP, REST, SFTP), authent (token statique vs OAuth), fréquence, volumétrie, et effets de bord. Exemple concret : si vous utilisez nShift/DeliveryCloud via API pour créer des envois, vous devez déjà savoir si la source est PrestaShop ou un OMS, et à quel moment l’étiquette est générée. La logique “colle” souvent à un module transporteur ; côté Shopify Plus, vous la refaites via app + webhooks ou via un service externe. Référence utile si vous avez du nShift : nShift DeliveryCloud API : intégration

Dans un contexte France/UE, la cartographie doit aussi intégrer des contraintes “hors code” qui finissent dans les modules :

• SCA / 3D Secure (selon PSP, pays, panier) : impact sur les statuts et les callbacks.
• TVA (B2C/B2B, intracommunautaire, règles de facturation) : où est calculée la TVA et où est générée la facture ?
• Transporteurs locaux (Colissimo, Mondial Relay, Chronopost, DPD…) : certaines règles de livraison sont parfois implémentées “dans le module”, pas dans un outil logistique.

Côté sécurité et conformité, ne considérez pas l’intégration comme “un câble”. Tout endpoint exposé par un module (callback paiement, tracking, cron tokenisé) est une porte d’entrée. Avant migration, faites un état des lieux de protection API et journalisation (WAF, SIEM, rotation logs), sinon vous embarquez les mêmes mauvaises pratiques côté Shopify (apps privées trop permissives, secrets en clair, webhooks non vérifiés). Voir : Sécurité PrestaShop : protéger l’API et journalisation et, pour l’angle e-commerce, Sécurité PrestaShop 2026 : risques majeurs

Risques d’intégration spécifiques à Shopify Plus : modèle de données, API, checkout, limites SaaS

Le premier piège est de sous-estimer l’écart de modèle entre PrestaShop (MySQL, schéma maîtrisable) et Shopify (objet API). Avec Shopify Plus, vous ne “migre(z)” pas une base : vous reconstruisez un référentiel via l’Admin API, avec des contraintes (throttling, coûts GraphQL, bulk operations). Shopify est explicite sur le contrôle de débit :

“The GraphQL Admin API uses a cost-based throttling system.” — Shopify Dev Docs (Rate limits)

Traduction : si vous poussez 300k produits/variants sans bulk + stratégie de backoff, vous vous auto-DDoS au niveau applicatif et vous rallongez la fenêtre de cutover. Concrètement, l’audit doit déjà produire : volumétrie catalogue, taux de changement quotidien (delta), et priorité de migration (top sellers d’abord, archive ensuite), sinon vous choisissez un “outil de migration” au hasard et vous subissez ses limites.

Deuxième piège : les règles checkout/paiement. PrestaShop permet (trop) : modules paiement qui modifient le panier, affichent des frais, réordonnent les étapes, ajoutent des champs, etc. Shopify Plus offre des possibilités réelles, mais structurées : Checkout Extensibility, UI extensions, Shopify Functions pour certaines règles (remises, livraison, paiement selon cas). Si votre boutique PrestaShop a 10 exceptions (frais de port dynamiques selon transport + contenu + code promo + groupe client), il faut les recoder proprement et vérifier la compatibilité fonctionnelle (parfois vous devez déplacer de la logique “checkout” vers de l’OMS).

Troisième piège : variants, attributs, multi-boutiques et SEO. PrestaShop gère les déclinaisons sans limite “philosophique” (la limite devient la perf), alors que Shopify impose des cadres (options/variants, limites selon configuration). Dans la configuration Shopify la plus courante, un produit est limité à 3 options et 100 variants : ne partez pas du principe que votre structure de déclinaisons migrera 1:1, surtout si vous avez des produits “matriciels” (taille * couleur * matière * longueur…). Stratégies typiques (à décider pendant l’audit, pas à la fin) :

• scinder en plusieurs produits (avec cohérence SEO/UX),
• créer des “collections” de variantes logiques,
• déplacer une dimension de variation en propriété non-variant (quand c’est acceptable pour l’achat).

Côté SEO, Shopify impose aussi ses patterns d’URL (ex. /products/, /collections/). Le risque n’est pas la perte d’indexation par magie : c’est l’absence de plan de redirections et de canonical cohérents. Sur ce sujet, Google est très clair :

“Use 301 redirects from the old URLs to the new URLs.” — Google Search Central (Site moves)

Enfin, n’oubliez pas les “petites” limites SaaS qui deviennent des gros sujets en migration : ordre de création des objets (produits/variants, images, métadonnées), synchronisation des statuts (paiement vs fulfillment), et gestion des erreurs (une API qui répond 429 doit déclencher un backoff, pas une boucle infinie).

Remplacer la logique modules : stratégies Apps/Functions/middleware et critères de décision

Une migration PrestaShop vers Shopify Plus “propre” consiste à reclassifier chaque module en capacité puis à décider : app du marketplace, app custom, Shopify Functions, middleware externe, ou abandon. Pour éviter les débats stériles, utilisez un scoring simple : criticité business (0–5) × complexité (0–5) × dette (0–5) × risque sécurité (0–5). Les modules paiement/logistique/stock montent vite : ils touchent à l’argent, au délai, à l’expérience client.

Pour rendre le scoring exploitable, fixez des critères observables (ex. “risque sécurité = 5 si endpoint public sans authent forte + données perso + absence de logs”). Exemple de grille (à adapter) :

Score	Indicateur pratique
Criticité 5	bloque la vente / expédition / facturation
Complexité 5	multi-sources, règles conditionnelles, dépendances externes
Dette 5	overrides, code non maintenu, logs absents, hacks template
Sécurité 5	callbacks publics, secrets en clair, pas de vérification de signature

Sur le plan architecture, le pattern qui marche est l’event-driven contrôlé : Shopify (webhooks) publie des événements (commande créée, paiement capturé, fulfillment), votre middleware transforme et pousse vers ERP/CRM/OMS, et vous maintenez l’idempotence (clé métier + storage). Si vous venez d’un monde PrestaShop “cron qui synchronise tout”, vous allez gagner en robustesse, mais seulement si vous imposez : retries exponentiels, DLQ (dead-letter), et traçabilité.

Checklist “middleware prêt pour la prod” (sans sur-ingénierie) :

• Idempotence : une clé stable par événement (ex. order_id + event_type + event_time ou ID d’événement) et un registre de traitement.
• Vérification des webhooks : validation de la signature (HMAC) et refus des payloads altérés.
• Gestion du débit : backoff sur 429 / erreurs réseau, et limitation côté workers.
• Journalisation utile : corrélation par commande (order number) + horodatage + payload minimal.
• Rejeu : capacité à rejouer un événement sans duplicat (essentiel en cutover).

Pour orchestrer des flux sans recoder un ESB entier, des workflows type n8n peuvent faire le job—à condition de monitorer et versionner les workflows. Vous avez une approche d’orchestration applicable ici : Automatisation PrestaShop : orchestrer commandes, stocks et prix via MCP (le principe est transposable même hors PrestaShop).

Cas concret (représentatif) : boutique PrestaShop 8.1, ~120k produits, ~35 modules actifs, 6 overrides, ERP qui pousse prix/stocks toutes les 15 min, transporteur via API, promotions complexes B2B. Le découpage efficace a été : 1) app custom pour synchronisation catalogue (bulk GraphQL + delta), 2) middleware pour commandes (webhooks + files), 3) Shopify Functions pour règles de remise simples, 4) abandon de 7 modules “confort BO” remplacés par process. Le gain n’est pas “Shopify fait mieux” : c’est la réduction des écritures concurrentes et l’observabilité. Mais le coût est réel : recoder proprement ce que PrestaShop permettait de bricoler.

Verrouiller la bascule : SEO, perf, RGPD, observabilité, rollback

La bascule n’est pas un “go live”, c’est une suite d’étapes : import initial, synchro delta, gel des changements, cutover DNS, vérification post-prod. Côté SEO, vous devez préparer un mapping URL exhaustif (produits, catégories, CMS, facettes si indexées) + redirections 301 + tests automatisés (status code, chain length, canonical, hreflang si applicable). La roadmap SEO PrestaShop du site donne une checklist d’audit (perf, contenu, popularité) réutilisable pour préparer un avant/après migration : Roadmap SEO PrestaShop

Pour éviter les oublis, fixez des livrables concrets avant le cutover (exemples) :

• un fichier de redirections (ancien → nouveau) avec statut attendu,
• une liste des pages “SEO sensibles” (top landing pages, top catégories, pages conseils),
• une vérification des balises (title/meta, canonicals, pagination si utilisée),
• un plan de monitoring (Search Console, logs, alertes 404, positions).

Côté performance, ne mélangez pas les causes. Sur PrestaShop, vous avez la main sur Varnish/Redis/OPcache ; sur Shopify, vous externalisez une partie et vous pilotez surtout le thème, les apps, le JS tiers. Votre audit doit donc inclure un inventaire des scripts (tag manager, pixels, chat, A/B testing) et un budget de perf (LCP/INP/CLS). Pour cadrer des objectifs mesurables et des méthodes, appuyez-vous sur : Core Web Vitals : actions concrètes et DevTools : méthodes pour mesurer et optimiser

Point d’attention très “e-commerce” : beaucoup de régressions Shopify viennent moins du thème que de l’empilement d’apps et de tags marketing. L’audit doit trancher : quels scripts sont indispensables (mesure conversion), lesquels sont optionnels (widgets, recommandations), et lesquels doivent passer en server-side ou être conditionnés au consentement.

Côté RGPD, la migration est un moment où l’on duplique, exporte, réimporte—donc où l’on crée des fuites si le process est artisanal. Validez : base légale des traitements, conservation, anonymisation/effacement, export DSR, et surtout la gestion des consentements (cookies + opt-ins). Une checklist structurée existe ici : Audit RGPD PrestaShop : 88 points de contrôle

Enfin, documentez un plan de rollback : si paiement ou stock est instable, quelles DNS, quelles redirections, quels flux ERP sont stoppés, et comment vous rejouez les commandes prises pendant l’incident. Sans rollback, vous n’avez pas une migration, vous avez un pari. Un bon rollback n’est pas forcément “retourner sur PrestaShop 72h” : c’est souvent un plan réaliste pour (1) figer la prise de commande, (2) stabiliser les flux (paiement/stock), (3) rejouer proprement les événements, et (4) relancer avec traçabilité.