Passer de WooCommerce à PrestaShop : guide pratique de migration

Notes de version et chemins du back-office vérifiés avec PrestaShop 9 (et stables sur 1.7/8). Transparence : nous développons des modules PrestaShop chez mypresta.rocks ; les mécanismes de migration présentés ici sont neutres vis-à-vis des plateformes.

La plupart des guides de migration de WooCommerce vers PrestaShop sont en réalité deux articles sous un même titre : une moitié consacre son volume de mots à rouvrir le débat sur la question de savoir si vous devez migrer, et l’autre vous donne une checklist générique en sept étapes qui serait identique si vous quittiez Magento ou Shopify. Celui-ci ne fait ni l’un ni l’autre. Si vous avez déjà décidé que PrestaShop est votre destination, et si vous hésitez encore, la comparaison honnête se trouve dans PrestaShop vs WooCommerce, ce dont vous avez vraiment besoin, c’est de la partie que personne n’écrit : comment les données WooCommerce, structurées à la manière de WordPress, se transposent dans la base de données de PrestaShop, à quels endroits l’outil d’import risque de déformer silencieusement votre catalogue, et quelles redirections permettent à Google de continuer à vous envoyer du trafic dès le lendemain de la mise en ligne.

La difficulté de cette migration précise n’est pas « exporter ici, importer là ». Elle tient au fait que WooCommerce est un plugin greffé sur un CMS de blog : vos produits vivent donc sous forme d’articles WordPress, avec leurs vraies données dispersées dans la table wp_postmeta, tandis que PrestaShop est un moteur e-commerce conçu pour cet usage, avec un schéma normalisé (ps_product, ps_product_attribute, ps_category_product, et les tables associées). Tout ce qui rend ce passage délicat vient de la réconciliation de ces deux visions. Ce guide est donc organisé autour des quatre points où le décalage fait vraiment mal : déclinaisons, prix/taxe, URL et mots de passe clients.

Avant de toucher au bouton d’export : inventoriez ce que WordPress cache

Les données WooCommerce sont trompeuses, parce que l’administration WordPress vous présente une table de produits bien rangée, alors qu’en dessous, un seul « produit variable » correspond à une ligne post, plus une ligne post enfant par variation, plus des dizaines de lignes wp_postmeta (_price, _sale_price, _stock, _weight, _sku, taxonomies d’attributs, et tout ce que vos plugins ont ajouté). Avant d’exporter quoi que ce soit, notez ce que vous devez réellement déplacer, par opposition à ce que vous avez simplement accumulé :

• Produits, nom, description, description courte, prix, prix promotionnel, SKU, stock, poids, images, et le titre SEO/la méta-description (souvent stockés par Yoast dans _yoast_wpseo_title / _yoast_wpseo_metadesc, exportez-les, sinon vous perdez chaque balise méta rédigée à la main).
• Variations, la matrice taille/couleur. C’est le plus gros travail de transformation ; voir la section dédiée ci-dessous.
• Catégories, WooCommerce les appelle catégories de produits (une taxonomie WordPress), hiérarchiques, avec descriptions et images.
• Clients, comptes et adresses. L’historique des commandes est utile pour l’assistance client ; les mots de passe, eux, ne migrent pas proprement via l’import natif (voir plus bas).
• Pages CMS, politique de livraison, retours, conditions générales. Elles deviennent des pages CMS PrestaShop, et chacune conserve une URL que Google a indexée.
• La liste des URL elle-même, ouvrez Search Console → Performances → Pages et exportez chaque URL qui génère des impressions. Cet export est votre cahier des charges de redirection, pas un simple bonus.

Un mot sur la nécessité de migrer ou non l’historique des commandes : la plupart des boutiques conservent l’ancienne base WooCommerce en lecture seule comme archive et ne transfèrent que les comptes clients actifs. Recréer des milliers de commandes historiques dans la structure ps_orders de PrestaShop est minutieux et rarement rentable pour une boutique qui peut encore consulter l’ancien système.

Étape 1, Préparez une préproduction et choisissez la bonne version de PrestaShop

N’importez jamais directement en production. Installez un PrestaShop propre sur un sous-domaine (par exemple staging.yourstore.com) afin de lancer l’import, constater ce qui casse, vider la base, puis recommencer, et vous recommencerez plusieurs fois avant d’obtenir un résultat propre. L’installateur natif de PrestaShop, associé à une base jetable, transforme le cycle « réinitialiser et réessayer » en boucle de cinq minutes.

Pour une nouvelle installation en 2026, PrestaShop 9 est le choix par défaut (branche actuelle, meilleure trajectoire de support à long terme, PHP 8.1+). La seule vraie raison de partir plutôt sur 8.x serait un module indispensable qui n’est pas encore certifié pour la 9, vérifiez d’abord votre liste de modules présélectionnés. Quel que soit votre choix, les mécanismes de migration ci-dessous sont identiques ; l’outil d’import et la gestion des URL de PrestaShop sont restés stables sur 1.7, 8 et 9.

Étape 2, Exporter depuis WooCommerce sans perdre les métadonnées

WooCommerce fournit un export CSV intégré dans WooCommerce → Produits → Exporter. Il suffit pour les catalogues simples et, point essentiel, vous permet de cocher les colonnes à inclure, assurez-vous que le SKU, le stock, le poids et vos colonnes de métadonnées SEO sont sélectionnés. Pour les clients et les commandes, les exports équivalents se trouvent dans le menu WooCommerce, ou vous pouvez interroger directement wp_users / wp_usermeta si vous êtes à l’aise avec la base de données.

Pour les images produit, l’export fournit des URL d’images, pas les fichiers. Vous avez deux options : laisser les images sur l’ancien domaine jusqu’à sa mise hors service (pour que l’import PrestaShop les récupère en HTTP), ou télécharger tout wp-content/uploads et les réhéberger. La récupération HTTP est plus simple, mais elle ne fonctionne que tant que l’ancien site est encore en ligne, planifiez la bascule en conséquence.

Si votre catalogue s’appuie fortement sur des lots, des abonnements ou des plugins de champs personnalisés, le CSV natif manquera ces données, car elles vivent dans des clés méta propres à chaque plugin. À ce stade, un service de migration dédié (Cart2Cart, LitExtension) peut justifier son coût en lisant ces tables pour vous, mais pour un catalogue standard, des CSV construits à la main vous donnent beaucoup plus de contrôle sur la façon dont les données arrivent.

Étape 3, Les transformations qui comptent vraiment

Variations → déclinaisons (celle qui casse les imports)

C’est ici que la plupart des migrations faites en interne se bloquent. WooCommerce modélise un t-shirt comme un produit variable avec des variations, chaque variation étant un article enfant presque indépendant. PrestaShop modélise le même t-shirt comme un produit avec des attributs (Taille, Couleur) et des déclinaisons (Taille : M / Couleur : Bleu → son propre SKU, son impact sur le prix, son stock et son poids). Conceptuellement, les données sont les mêmes ; le format d’import ne l’est pas.

L’import CSV de PrestaShop gère les déclinaisons via un type d’import dédié Déclinaisons (Paramètres avancés → Import, puis choisissez « Déclinaisons » comme entité), où chaque ligne porte la référence du produit parent ainsi que le groupe d’attributs et la valeur (par exemple une colonne Attribute (Name:Type:Position) contenant Size:select:0 avec une Value de M) afin qu’une ligne corresponde à une déclinaison. Approche pratique : importez d’abord les produits parents avec leur prix de base et une déclinaison par défaut, puis lancez un second import Déclinaisons indexé par référence produit (SKU) pour rattacher la matrice taille/couleur avec le bon impact sur le prix et le bon stock par déclinaison. Essayer de tout faire entrer dans un seul CSV produit est le meilleur moyen d’obtenir des produits en double et du stock orphelin.

Prix et taxe, le bug silencieux de TVA décalée

WooCommerce stocke un prix normal et un prix promotionnel optionnel par produit. PrestaShop les sépare : le prix de base est porté par le produit, et les remises sont modélisées comme des prix spécifiques (ps_specific_price). Un prix promotionnel WooCommerce doit donc devenir une règle de prix spécifique, et non un prix de base réécrit, si vous voulez que PrestaShop affiche correctement le prix barré.

Le piège fiscal est celui qui coûte cher. WooCommerce peut stocker les prix TTC ou HT selon un réglage que la plupart des propriétaires ont oublié avoir modifié. Par défaut, l’import PrestaShop attend des prix hors taxe et applique ensuite la règle de taxe. Si vos prix WooCommerce étaient TTC et que vous les importez comme HT, chaque produit devient soudain plus cher du montant de votre taux de TVA, ou moins cher, si vous vous trompez dans l’autre sens. Vérifiez le réglage WooCommerce dans WooCommerce → Settings → Tax (« Prices entered with tax ») avant d’importer la moindre ligne, et configurez des règles de taxe correspondantes dans PrestaShop (International → Taxes / Tax Rules) afin que les calculs concordent.

Descriptions, supprimez les shortcodes

Les descriptions WooCommerce sont du contenu WordPress, ce qui signifie qu’elles peuvent contenir des shortcodes ([product_page id="123"], blocs de galerie, balisage de constructeur de pages) qui ne produisent rien dans PrestaShop et laissent de vilains crochets affichés tels quels sur la page. Exécutez une recherche-remplacement sur votre colonne de description avant l’import afin de supprimer les shortcodes et de convertir les commentaires de blocs Gutenberg en HTML simple.

Étape 4, Importer dans PrestaShop, dans le bon ordre

L’importateur de PrestaShop se trouve dans Paramètres avancés → Import et lit les CSV par type (Catégories, Produits, Déclinaisons, Clients, Adresses, etc.). L’ordre n’est pas facultatif, les produits référencent des catégories, les déclinaisons référencent des produits, donc pour tout catalogue dépassant quelques centaines de SKU :

• Les catégories d’abord. L’arborescence doit exister avant que les produits puissent y être affectés. Faites correspondre vos noms de catégories WooCommerce aux catégories PrestaShop dans un tableur ; les ID ne correspondront pas, et c’est normal, l’import s’appuie sur le nom/la référence.
• Les produits sans images. Importez d’abord le catalogue avec les colonnes d’images vides, vérifiez les quantités et les prix, puis traitez les images. Cela sépare les bugs de données des bugs de récupération d’images.
• Les déclinaisons. La matrice taille/couleur, indexée par SKU, dans un passage d’import séparé.
• Les images. PrestaShop récupère et régénère les miniatures à l’import, ce qui est lent pour les gros catalogues, lancez-le hors heures de pointe et, si le délai d’exécution expire, augmentez max_execution_time ou importez par lots.
• Les clients et les adresses en dernier, une fois la structure de la boutique stabilisée.

Laissez l’option « Forcer les ID » désactivée et laissez PrestaShop attribuer ses propres ID ; tenter de conserver les ID WooCommerce vous met en conflit avec l’importateur sans bénéfice réel. Gardez toutefois une colonne avec l’ID WooCommerce d’origine ou le slug, vous en aurez besoin pour les redirections à l’étape suivante.

Étape 5, Correspondance des URL et redirections 301 (l’étape où les migrations échouent)

C’est ce qui distingue une migration qui conserve son trafic Google d’une migration qui l’effondre pendant trois mois. WooCommerce et PrestaShop produisent des URL structurellement différentes :

Chaque ancienne URL indexée par Google doit faire l’objet d’une redirection 301 vers son nouvel équivalent. Ignorez cette étape et vous héritez de trois problèmes à la fois : des 404 pour les clients qui avaient enregistré un produit, une perte de popularité de lien depuis chaque site externe pointant vers vos anciennes URL, et des chutes de position précisément sur les pages qui vous apportaient du trafic gratuit. PrestaShop dispose de réglages natifs SEO & URLs (Paramètres de la boutique → Trafic & SEO) pour définir des modèles d’URL propres, et vous pouvez créer des redirections à la main, mais pour un catalogue d’une certaine taille, il vous faut une couche de gestion des redirections afin que la correspondance ancien→nouveau reste maintenable, au lieu de mille lignes de .htaccess que vous n’osez plus toucher. Construisez la table à partir de l’export Search Console récupéré à l’étape d’inventaire. Cette liste est l’ensemble des URL qui comptent vraiment, classées selon le trafic qu’elles génèrent.

Étape 6, Thème : il ne vous suit pas

Votre thème WooCommerce est spécifique à WordPress et ne peut pas être transféré ; les thèmes sont liés à leur plateforme. Trois pistes réalistes : utiliser tel quel le thème par défaut moderne de PrestaShop (Hummingbird) pour lancer le plus vite possible ; créer un thème enfant basé sur Hummingbird afin de respecter votre marque sans créer une copie divergente du cœur ; ou reconstruire votre apparence actuelle au pixel près si la reconnaissance par les clients est critique (un acheteur fidèle qui arrive sur un site radicalement différent peut parfois penser qu’il n’est pas au bon endroit). Quel que soit votre choix, c’est le bon moment pour ne pas recréer chaque extension que vous aviez. PrestaShop fait nativement ce que toute une pile d’extensions WooCommerce faisait auparavant, donc réajoutez les fonctionnalités avec discernement plutôt que par réflexe. Les modules dont une nouvelle boutique a réellement besoin au départ font l’objet d’un sujet à part : les modules que toute nouvelle boutique PrestaShop devrait installer en premier.

Étape 7, La passe de test avant lancement

Avant de basculer les DNS, parcourez chaque parcours visible par les clients sur la préproduction comme si vous étiez acheteur :

• Parcourez le catalogue, filtrez par catégorie, lancez une recherche, vérifiez que les déclinaisons affichent le bon prix et le bon stock.
• Ajoutez au panier, modifiez la quantité, supprimez un article, contrôlez les calculs du panier par rapport à l’ancienne boutique.
• Finalisez une commande à la fois comme invité et comme client inscrit.
• Effectuez une transaction réelle avec chaque moyen de paiement (carte, PayPal, virement bancaire) en mode test.
• Vérifiez que les e-mails de confirmation de commande et d’expédition partent réellement et reprennent votre marque, les modèles transactionnels de PrestaShop diffèrent de ceux de WooCommerce.
• Testez sur un vrai téléphone ; le mobile représente la majorité du trafic de la plupart des boutiques, et la mise en page différera de WordPress.
• Contrôlez ponctuellement les redirections depuis vos principales anciennes URL, collez-les dans un navigateur et confirmez une 301 propre, pas une 404.
• Réinstallez les outils d’analyse et de suivi, puis vérifiez que les événements sont bien enregistrés ; générez le sitemap et préparez sa soumission dans Search Console au moment de la mise en ligne.

Les quatre problèmes qui surviennent après le lancement

• Les mots de passe clients ne migrent pas proprement, communiquez-le. WooCommerce utilise le hachage de mots de passe de WordPress ; PrestaShop utilise le sien. Les mots de passe ne migrent pas proprement via l’import natif ; sans passerelle personnalisée, les clients doivent réinitialiser leur mot de passe. Chaque client existant devra utiliser « mot de passe oublié » lors de sa première connexion, donc envoyez un e-mail d’information au moment de la bascule pour l’expliquer. Le silence donne l’impression d’un compte piraté et fait grimper les tickets d’assistance.
• La taxe ne se réconcilie pas. Le décalage TTC/HT de l’étape 3 réapparaît ici si vous l’avez ignoré. Prenez dix produits et comparez le total final du panier, taxe comprise, avec l’ancienne boutique avant de passer en production.
• Les passerelles de paiement doivent être reconfigurées, pas réinscrites. Votre compte Stripe/PayPal fonctionne sur les deux plateformes, mais vous installez les modules de paiement PrestaShop et vous y collez à nouveau vos clés API. Le compte est conservé ; l’intégration, non.
• La délivrabilité des e-mails repart de zéro. Nouvelle plateforme, nouvelle configuration d’envoi, vérifiez que SPF/DKIM couvrent toujours votre domaine d’envoi et que la messagerie PrestaShop est configurée (SMTP, pas PHP mail, pour tout projet sérieux).

Questions fréquentes sur la migration depuis WooCommerce

Pourquoi cette migration est-elle plus difficile qu’un simple « exporter ici, importer là » ?

Parce que WooCommerce est un plugin greffé sur un CMS de blog : vos produits vivent donc sous forme d’articles WordPress, avec leurs vraies données dispersées dans la table wp_postmeta, tandis que PrestaShop est un moteur e-commerce conçu pour cet usage, avec un schéma normalisé (ps_product, ps_product_attribute, ps_category_product). Tout le travail consiste à réconcilier ces deux visions, et la difficulté se concentre sur quatre points : déclinaisons, prix/taxe, URL et mots de passe clients. Réglez correctement ces quatre sujets, et le reste devient mécanique.

Quel est ce bug de taxe « décalée de la TVA » dont tout le monde parle ?

WooCommerce peut stocker les prix TTC ou HT selon un réglage que la plupart des propriétaires ont oublié avoir modifié. Par défaut, l’import PrestaShop attend des prix hors taxe et applique ensuite la règle de taxe. Importez des prix TTC comme s’ils étaient HT, et chaque produit se retrouve soudain décalé de votre taux de TVA, plus cher, ou moins cher si vous vous trompez dans l’autre sens. Vérifiez le réglage dans WooCommerce → Settings → Tax (« Prices entered with tax ») avant d’importer la moindre ligne, configurez des règles de taxe correspondantes dans PrestaShop, puis prenez dix produits et comparez le total final du panier avec taxe à celui de l’ancienne boutique avant la mise en ligne.

Mes clients conservent-ils leurs mots de passe ?

Non. WooCommerce utilise le hachage de mots de passe de WordPress et PrestaShop utilise le sien ; sans passerelle personnalisée, les mots de passe ne migrent pas proprement via l’import natif. Les e-mails, noms, adresses et (si vous les transférez) historiques de commandes passent correctement, le secret de connexion, non. Chaque client existant devra utiliser « mot de passe oublié » lors de sa première connexion, donc envoyez un e-mail d’information au moment de la bascule pour l’expliquer. Le silence donne l’impression d’un compte piraté et fait grimper les tickets d’assistance.

Comment convertir les variations WooCommerce en déclinaisons PrestaShop ?

C’est ici que la plupart des migrations faites en interne se bloquent. Un produit variable WooCommerce (un article parent plus un article enfant par variation) devient un produit PrestaShop avec attributs et déclinaisons. L’approche fiable se fait en deux passages dans Paramètres avancés → Import : importez d’abord les produits parents avec leur prix de base et une déclinaison par défaut, puis lancez un import Déclinaisons séparé, indexé par référence produit (SKU), pour rattacher la matrice taille/couleur avec le bon impact prix par déclinaison et le bon stock. Essayer de tout faire entrer dans un seul CSV produit est le meilleur moyen d’obtenir des produits en double et du stock orphelin.

Vais-je perdre mes positions Google ?

Seulement si vous ignorez les redirections. WooCommerce et PrestaShop produisent des URL structurellement différentes : chaque ancienne URL indexée par Google doit donc faire une redirection 301 vers son nouvel équivalent. Construisez la table à partir de votre export Search Console Pages (cette liste est l’ensemble des URL qui comptent, classées par trafic), utilisez une couche de gestion des redirections plutôt que mille lignes fragiles de .htaccess, et contrôlez les redirections avant et après le lancement. Ignorez cette étape et vous héritez de 404, d’une perte de popularité de lien et de chutes de position précisément sur les pages qui vous apportaient du trafic gratuit.

Calendrier : prévoyez un mois, pas un week-end

Pour une boutique représentative, environ 500 produits avec déclinaisons et plusieurs milliers de clients, la migration technique (export, transformation, imports répétés en préproduction) représente réalistement 1 à 2 semaines de travail concentré. La correspondance des URL et la passe de test complète ajoutent une semaine. Prévoyez un mois complet du démarrage à la mise en ligne afin d’absorber les surprises que chaque vrai catalogue finit par révéler. La tentation d’aller vite est forte et toujours mauvaise : une migration ratée coûte bien plus en ventes perdues et en mois de récupération SEO que la semaine supplémentaire qu’elle aurait demandée. Les raisons qui poussent les boutiques à faire ce choix au départ, posséder sa pile technique au lieu de la louer, une plateforme pensée pour le commerce plutôt que pour le blog, sont abordées dans pourquoi nous avons choisi PrestaShop et pourquoi posséder son code compte ; ce guide explique comment y parvenir en conservant vos données et vos positions. Traitez correctement les quatre points de décalage, déclinaisons, taxe, URL, mots de passe, et le reste de la migration devient mécanique.

À lire ensuite

• PrestaShop vs WooCommerce, la comparaison honnête, si vous hésitez encore à migrer.
• Passer de Magento à PrestaShop, la même discipline de migration depuis une plateforme plus lourde.
• Les modules que toute nouvelle boutique devrait installer en premier. Ce qu’il faut ajouter avec discernement, au lieu de recréer chaque plugin WooCommerce.