Migration PrestaShop vers Shopify : méthode, SEO et option headless

Une migration PrestaShop vers Shopify échoue rarement sur l'import du catalogue. Elle échoue sur ce qui l'entoure : des redirections incomplètes, un tracking qui ne compte plus les achats, un ERP resté branché sur l'ancienne base, des commandes passées entre l'import initial et la bascule. Copier des données prend quelques jours. Assurer la continuité du chiffre d'affaires, du référencement et des opérations, c'est le vrai chantier.

Une boutique en production est un système vivant. Des flux y entrent : stocks, prix, fiches produits. Des flux en sortent : commandes vers la logistique, événements vers l'analytics, écritures vers la comptabilité. Chacun devra être re-raccordé, testé, réconcilié. Un programme de données, d'opérations et de continuité, pas une copie.

Ce guide déroule la méthode : prérequis, choix du pipeline (CSV, application ou API), continuité des paiements et des intégrations, plan SEO, mesure, répétition et rollback. Avec un détour assumé par la question qui précède tout : storefront standard, headless, ou pas de migration du tout.

Avant une migration PrestaShop vers Shopify : la checklist de prérequis

Tout commence par un inventaire : ce que la boutique contient, ce qui s'y connecte, ce que vous acceptez de perdre. Voici ce qu'on établit avant d'écrire la moindre ligne de script :

• Compter le catalogue : produits, déclinaisons, catégories, marques, caractéristiques, images. Le webservice PrestaShop expose tout cela en API CRUD (produits, combinations, stocks) ; un dump SQL fait aussi l'affaire.
• Repérer les produits à plus de 3 options : Shopify limite un produit à 3 options (taille, couleur, matière par exemple). Au-delà, il faut scinder le produit ou déporter des attributs en metafields.
• Auditer les médias : formats, poids, images orphelines. Shopify accepte jusqu'à 250 images par produit et les re-télécharge à l'import depuis des URL publiques.
• Nettoyer la base clients : emails invalides, doublons (Shopify saute les doublons d'email ou de téléphone à l'import), et surtout consentements marketing à reporter fidèlement dans les colonnes dédiées.
• Trancher la profondeur d'historique de commandes à reprendre, et désigner qui fera foi ensuite : Shopify ou l'ERP.
• Lister les modules PrestaShop actifs et classer chacun : fonction native Shopify, app équivalente, développement, ou abandon assumé.
• Cartographier les intégrations : ERP, PIM, WMS, CRM, comptabilité, flux marketplaces, emailing.
• Construire l'inventaire d'URL : crawl complet, top pages Search Console, pages recevant des backlinks.
• Geler un instantané daté (base + médias) qui servira de source aux répétitions, puis fixer critères de go/no-go, fenêtre de bascule et plan de retour arrière.

Si votre chantier est en réalité une mise à niveau plutôt qu'un changement de plateforme, on a documenté ce cas dans notre guide de migration PrestaShop 1.7 vers 8.2. Rester sur un PrestaShop bien maintenu est parfois la meilleure décision du lot.

CSV, application ou API : trois pipelines possibles

Trois voies existent pour déplacer les données, classées par la documentation Shopify de la moins à la plus technique : les fichiers CSV natifs, une application de migration, ou un pipeline sur mesure via les API.

Le CSV natif couvre les produits et les clients, pas les commandes. Le fichier clients est plafonné à 15 Mo, l'encodage doit être UTF-8, et les metafields de variantes ne passent pas. Les commandes historiques exigent une application de migration ou l'API Admin (ressources Order et Transaction). Pour un petit catalogue sans historique, le CSV suffit.

Les applications de migration (type Cart2Cart ou Matrixify) automatisent l'extraction et le chargement. Rapides, mais leur mapping est standardisé : vérifiez ce qu'elles font des déclinaisons complexes, du multi-langue et des metafields avant de leur confier la boutique.

Le pipeline API se justifie dès que le catalogue est complexe ou que la boutique continue de vendre pendant le projet : extraction via le webservice PrestaShop, transformation (déclinaisons vers variants, caractéristiques vers metafields, mapping d'URL), chargement via l'API Admin GraphQL. Son avantage décisif : il est rejouable. On peut relancer l'import sur données fraîches autant de fois que nécessaire, y compris pour la passe delta du jour J. Un import manuel, non.

L'ordre d'import n'est pas négociable : produits d'abord, clients ensuite, commandes en dernier. Une commande référence des produits et un client ; importée avant eux, elle devient orpheline.

flowchart LR
  subgraph PS["PrestaShop en production"]
    DB[("Base MySQL")]
    WS["Webservice REST"]
    MED["Medias"]
  end
  subgraph ETL["Pipeline rejouable"]
    EX["Extraction"]
    TR["Transformation et mapping"]
    CT["Comptages et controles"]
  end
  subgraph SH["Shopify"]
    PR["1. Produits"]
    CL["2. Clients"]
    CO["3. Commandes historiques"]
    RD["Redirections 301"]
  end
  DB --> EX
  WS --> EX
  MED --> EX
  EX --> TR --> CT
  CT --> PR
  CT --> CL
  CT --> CO
  CT --> RD
  PS -. "ventes entre l'import initial et la bascule" .-> DL["Passe delta"]
  DL --> CL
  DL --> CO
  SH --> INT["ERP, WMS, CRM, emailing"]

Un mot sur les mots de passe : ils ne migrent jamais. Ils sont hachés hors de Shopify, qui ne peut pas les réutiliser. Deux issues : inviter les clients à recréer un accès, ou activer les comptes clients Shopify à connexion par code envoyé par email. Dans les deux cas, la communication client se prépare avant la bascule, pas après.

Paiements, livraison, taxes, ERP : la continuité opérationnelle

Un catalogue migré ne vend rien si l'encaissement et la logistique ne suivent pas. Le PSP se choisit à nouveau (Shopify Payments ou fournisseur tiers), les moyens de paiement français se reconfigurent un à un, et chaque brique se re-raccorde par app ou webhook : zones de livraison, tarifs transporteurs, TVA et guichet OSS, facturation conforme, flux ERP, PIM, WMS et CRM. On a déjà décrit ce que coûte un module de paiement mal rebranché après une migration PrestaShop ; côté Shopify, le soin exigé est le même.

Attention aux identifiants : les IDs produits et variantes changent de monde. Tout connecteur qui référençait des IDs PrestaShop doit être re-mappé. La documentation du CSV produits prévient d'ailleurs que modifier les valeurs d'options d'un produit régénère les IDs de variantes, ce qui casse les dépendances tierces.

PrestaShop ou Shopify, standard ou headless : le tableau de décision

Le storefront standard (thème Liquid) couvre la grande majorité des boutiques ; le headless répond à des besoins d'expérience ou d'écosystème précis. Côté outillage, Shopify fournit Hydrogen, framework React basé sur Remix, Oxygen, son hébergement edge, la Storefront API pour le catalogue et le panier, et la Customer Account API pour l'espace client. Le checkout, lui, reste hébergé par Shopify dans tous les cas : le front construit un panier puis redirige vers son checkoutUrl.

Rester sur PrestaShop est rationnel dans au moins trois cas : des surcouches serveur profondes que le modèle d'apps Shopify ne reproduit pas, une exigence d'hébergement des données chez un prestataire de votre choix (PrestaShop auto-hébergé est la seule option du tableau qui la satisfait pleinement, en France si besoin), ou un coût de re-développement des modules métier supérieur aux gains attendus. Une migration doit se justifier par des gains nets ; la lassitude n'en est pas un.

Pourquoi le headless ne devrait jamais être le choix par défaut

Le headless est d'abord un transfert de responsabilité. En standard, Shopify porte le rendu, la disponibilité du front, l'essentiel du SEO technique, et les apps s'intègrent au thème. En headless, tout cela revient à votre équipe : performance, accessibilité, données structurées, previews, chaque app à re-brancher une à une. Même robots.txt et sitemap.xml deviennent des routes de votre application Hydrogen.

L'argument performance, seul, ne tient pas. Un thème Liquid discipliné (images propres, apps limitées, scripts maîtrisés) atteint de bons Core Web Vitals ; un front React mal tenu fait pire que le thème qu'il remplace. La performance est un résultat de discipline, pas une propriété de l'architecture.

Chez Platane, on a fait ce choix en connaissance de cause pour le festival Le Ouaille Note : boutique de merchandising Shopify headless intégrée à un site événementiel Gatsby, pour une navigation sans rupture entre le programme et la boutique. Le besoin tenait en une phrase, le headless était la bonne réponse, et toutes les places de l'édition se sont vendues.

SEO et tracking : garder le trafic et la mesure

Inventaire d'URL et redirections 301

Shopify impose sa structure d'URL : /products/, /collections/, /pages/. Vos URL PrestaShop ne survivront pas telles quelles ; chaque URL de l'inventaire doit être redirigée en 301 vers son équivalent réel, produit vers produit, catégorie vers collection, page CMS vers page. Google est explicite : rediriger en masse vers la page d'accueil peut être traité comme un soft 404, et les redirections doivent rester en place au moins un an.

Les redirections natives Shopify s'importent par CSV, avec un plafond de 100 000 entrées (20 millions sur le plan Plus) :

Redirect from,Redirect to
/12-robes-lin,/collections/robes-lin
/robe-lin-bleue.html,/products/robe-lin-bleue
/content/4-livraison,/pages/livraison

Une URL sans équivalent réel mérite un 404 propre, pas un faux 301. Et personne ne peut garantir zéro perte : Google annonce plusieurs semaines de recrawl pour un site de taille moyenne. Un plan propre raccourcit la turbulence, il ne la supprime pas.

Canonicals, hreflang, robots et sitemap

Sur le storefront standard, Shopify génère canonicals auto-référentes, sitemap.xml et robots.txt, personnalisable via le template robots.txt.liquid. Une redirection créée s'applique automatiquement aux sous-dossiers de langue et de marché, mais les hreflang se vérifient après bascule, surtout si votre PrestaShop était multilingue : Google demande des annotations mises à jour vers les nouvelles URL. Les données structurées produit dépendent du thème, ou de votre front en headless : à re-valider au Rich Results Test. Soumettez le nouveau sitemap en Search Console dès la bascule ; on a déjà raconté ce que coûtent un robots.txt et un sitemap négligés pendant une migration.

Événements d'achat et déduplication

Une migration Shopify remet la mesure à zéro : pixels, événements serveur et bandeau de consentement se réinstallent (customer events côté standard, votre code côté headless), avec un outil d'analytics qui peut être européen ou auto-hébergé, type Matomo ou Umami, plutôt qu'un défaut américain. Le point critique est l'événement d'achat. S'il part à la fois du navigateur et d'un canal serveur, chaque commande doit porter un identifiant de transaction unique pour être dédupliquée : une commande de test doit produire exactement un achat mesuré. Les premiers jours, réconciliez chaque matin les commandes Shopify avec les transactions vues par l'analytics ; l'écart doit s'expliquer (consentements refusés, bloqueurs), pas se subir.

Réussir sa migration PrestaShop vers Shopify : répétition, delta et rollback

Une bascule se traite comme un déploiement : répétée, mesurée, réversible. La répétition d'abord : migration à blanc complète sur une boutique de test, chronométrée, avec comptages source contre cible (produits, déclinaisons, clients, commandes, montants cumulés par exercice) et contrôle manuel d'un échantillon.

Le delta ensuite. Entre l'import initial et le jour J, la boutique continue de vendre : commandes, clients, stocks et prix bougent. Tout ce qui a été créé ou modifié depuis l'instantané initial doit être rejoué dans la fenêtre de bascule. C'est la raison d'être du pipeline rejouable.

Le go/no-go se décide sur des critères écrits à l'avance : écarts de comptage sous un seuil convenu, échantillon de redirections testé, commande réelle encaissée puis retrouvée dans l'analytics et dans l'ERP. Si un critère échoue, on reporte. Un report coûte moins cher qu'une semaine de ventes mal comptées.

Le rollback, enfin. PrestaShop reste gelé et accessible pendant la période d'observation, avec un TTL DNS court. Si retour arrière il y a, les commandes encaissées sur Shopify doivent être réinjectées dans l'ancienne base ou dans l'ERP, et les stocks recalés ligne à ligne. Un rollback sans réconciliation fabrique des ventes fantômes et des stocks faux des deux côtés.

Le piège qu'on voit en pratique : la bascule sans delta

Le symptôme : quelques jours après la mise en ligne, le service client reçoit des appels de clients dont la commande récente n'apparaît plus dans leur espace, des stocks affichés sont faux, et des relances marketing partent vers des acheteurs de la veille.

Le diagnostic : l'import initial a été fait plusieurs semaines avant la bascule, pendant que PrestaShop continuait de vendre. Personne n'a rejoué l'intervalle : les commandes et mouvements de stock entre l'instantané et le jour J n'existent que dans l'ancienne base. Variante fréquente du même piège, côté mesure : l'événement d'achat envoyé deux fois sans déduplication, et un chiffre d'affaires analytics gonflé qui fausse les décisions d'acquisition.

La correction : re-geler un instantané, scripter une passe delta (créations et modifications depuis l'instantané), l'exécuter dans la fenêtre de bascule, puis réconcilier par numéro de commande et par comptage de stock avant de rouvrir le marketing. Quelques jours de travail avec un pipeline rejouable ; plusieurs semaines de crise quand tout a été fait à la main.

Questions fréquentes

Q : Peut-on migrer les mots de passe clients de PrestaShop vers Shopify ?

R : Non. Les mots de passe sont hachés hors de Shopify et ne peuvent pas être importés. Les clients devront recréer un accès, ou se connecter via les comptes Shopify à code envoyé par email.

Q : Peut-on conserver ses URL PrestaShop sur Shopify ?

R : Non. Shopify impose sa structure (/products/, /collections/, /pages/). La continuité SEO passe par un mapping 301 URL par URL, vers l'équivalent réel de chaque page.

Q : Combien de temps dure une migration PrestaShop vers Shopify ?

R : La copie des données se compte en jours. Le gros du délai tient à l'audit, au mapping, aux répétitions et au re-raccordement des paiements, du tracking et de l'ERP. Méfiez-vous d'un délai garanti avant tout audit.

Q : Faut-il Shopify Plus pour passer en headless ?

R : Non. Hydrogen, Oxygen, la Storefront API et la Customer Account API sont accessibles sans Plus. Plus joue surtout sur les plafonds (20 millions de redirections contre 100 000) et sur la personnalisation avancée du checkout.

Décider sur pièces, pas sur promesses

Une migration PrestaShop vers Shopify réussie est une migration répétée : un pipeline rejouable, un mapping 301 exhaustif, une mesure vérifiée commande par commande, un delta exécuté au bon moment et un rollback qu'on espère ne jamais utiliser. Si l'audit initial conclut que PrestaShop reste le bon outil, ou que le headless ne se justifie pas, ce sont des conclusions valables. Le succès se mesure en continuité de chiffre d'affaires, de trafic et de données.

L'agence Platane (https://platane.io) conçoit, migre et héberge des plateformes e-commerce et des applications web sur mesure, en storefront standard comme en headless, avec cette même exigence de continuité appliquée au SEO, au tracking et aux intégrations.