Le sens habituel des migrations, ces dernières années, va de PrestaShop vers WooCommerce ou Shopify. Celui-ci prend le chemin inverse — et quand il est demandé, c’est rarement par effet de mode. C’est parce que la boutique a grossi, que le catalogue s’est compliqué, et que WordPress commence à être employé pour ce qu’il n’a jamais été : un progiciel de commerce.
Cet article dit franchement quand ce changement se justifie, quand il ne se justifie pas, et ce qu’il faut prévoir si vous le faites. Y compris la question que tout le monde oublie jusqu’au dernier moment : que devient le blog ?
Réponse rapide
Migrer de WooCommerce vers PrestaShop se justifie quand le catalogue devient complexe (déclinaisons nombreuses, tarifs par groupe de clients, multiboutique, gestion fine des transporteurs et des stocks) et que WooCommerce ne tient plus qu’à force d’extensions payantes empilées. Techniquement, produits, déclinaisons, catégories, clients et commandes se migrent ; les mots de passe clients, eux, ne se transfèrent pas (algorithmes différents) : prévoyez une réinitialisation annoncée. Les URLs changent de forme, donc un plan de redirections 301 complet est obligatoire. Dernier point, souvent découvert trop tard : PrestaShop n’a pas de véritable moteur de blog — si votre contenu éditorial vous apporte du trafic, décidez de son sort avant la bascule.
Les cas où PrestaShop reprend l’avantage
Un catalogue à déclinaisons nombreuses
PrestaShop a été conçu dès l’origine autour des attributs et des combinaisons, avec gestion des stocks, des prix et des images par déclinaison. WooCommerce sait le faire, mais au-delà de quelques centaines de variations, l’administration devient pénible et les performances se dégradent.
Du B2B, ou des tarifs par type de client
Groupes de clients, prix spécifiques, remises par quantité, affichage hors taxes, conditions de règlement : c’est natif dans PrestaShop. Sous WooCommerce, chacune de ces fonctions est une extension — donc une dépendance, un abonnement et un risque de conflit de plus.
Plusieurs boutiques à administrer ensemble
Le multiboutique de PrestaShop permet de partager un catalogue entre plusieurs vitrines, avec leurs propres prix, transporteurs et contenus, depuis un seul back-office. C’est l’une des rares fonctions qui n’a pas d’équivalent simple ailleurs.
Une logistique exigeante
Transporteurs multiples avec règles de poids et de zone, préparation de commandes, états personnalisés, liaison avec un ERP : PrestaShop expose un modèle de commande plus structuré, plus facile à brancher sur un système d’information existant.
Une boutique devenue un empilement d’extensions
C’est le symptôme le plus parlant. Quand vingt extensions payantes assurent ce qui serait natif ailleurs, chaque mise à jour devient un risque et chaque bug une enquête. Le coût d’abonnement finit par dépasser celui d’une plateforme complète.
Les cas où il ne faut surtout pas migrer
Je préfère le dire avant de chiffrer quoi que ce soit, parce que ces situations sont fréquentes :
- Votre problème est la lenteur. Une boutique WooCommerce lente est presque toujours lente pour des raisons identifiables : constructeur de page lourd, hébergement mutualisé saturé, images non optimisées, extensions qui chargent sur toutes les pages. Changer de plateforme pour cela, c’est déménager parce qu’une ampoule a grillé. Voir WooCommerce lent.
- Votre catalogue est simple et le contenu éditorial porte votre référencement. Vous perdriez votre meilleur atout.
- Vous êtes seul à administrer la boutique et vous maîtrisez WordPress. Le back-office PrestaShop est plus riche, donc plus exigeant.
- Vous espérez un gain de référencement. Aucune plateforme n’est intrinsèquement mieux référencée qu’une autre. Ce qui compte, c’est la structure, la vitesse et le contenu — et une migration mal menée fait perdre des positions, jamais l’inverse.
Si vous hésitez entre les deux plateformes dans l’absolu, l’article PrestaShop ou WooCommerce compare les deux sans parti pris. Et si le doute porte sur votre boutique en particulier, le diagnostic e-commerce tranche la question avant que vous n’engagiez un budget de migration.
Ce qui se migre, et ce qui ne se migre pas
Ce qui se migre bien
- Produits simples et variables : titres, descriptions, références, prix, poids, images. Les produits variables de WooCommerce deviennent des produits à déclinaisons, ce qui suppose de créer d’abord les attributs et leurs valeurs côté PrestaShop, puis de reconstituer chaque combinaison.
- Catégories, y compris leur arborescence.
- Clients : nom, adresses, téléphone, historique.
- Commandes : lignes, montants, états — moyennant une correspondance entre les statuts des deux plateformes, qui ne portent ni les mêmes noms ni exactement le même sens.
Ce qui ne se migre pas
- Les mots de passe. Les deux plateformes ne chiffrent pas de la même façon. Vos clients devront définir un nouveau mot de passe à leur première connexion. Cela s’annonce par un email, le jour de la bascule, et cela se prépare : mal géré, c’est une vague de comptes abandonnés.
- Les extensions. Aucune ne survit. Chaque fonction est reprise par un module PrestaShop, un développement spécifique, ou abandonnée.
- Le thème. Il se reconstruit, en reprenant votre identité visuelle.
- Les champs personnalisés ajoutés par une extension : il faut d’abord savoir où ils sont stockés, puis décider de leur destination côté PrestaShop. C’est souvent le poste le plus imprévisible.
Le point aveugle : que devient le blog ?
C’est la question qui arrive toujours trop tard, et elle peut coûter la moitié de votre trafic.
WooCommerce vit dans WordPress, donc votre blog est natif, bien structuré et bien référencé. PrestaShop, lui, n’a pas de véritable moteur de contenu : les pages CMS existent, mais sans catégories, sans flux, sans commentaires ni gestion d’auteurs. Les modules de blog du marché comblent partiellement le vide, avec des résultats inégaux.
Trois issues, à décider avant la migration :
- Garder WordPress pour le blog, sur le même domaine dans un sous-dossier (par exemple
/blog/), avec PrestaShop à la racine. Les URLs ne bougent pas, le référencement est préservé, et vous gardez l’outil de rédaction que vous connaissez. C’est la solution que je recommande presque toujours. Elle demande une configuration serveur soignée et une cohérence visuelle entre les deux. - Migrer les articles vers un module de blog PrestaShop, avec redirection de chaque ancienne URL. Plus simple à administrer, mais vous perdez des fonctions et vous dépendez du module.
- Abandonner le blog en redirigeant les articles vers les catégories produits correspondantes. À ne faire que si le contenu n’apporte réellement rien — vérifiez-le dans vos statistiques, pas à l’intuition.
Quelle que soit l’option, inventoriez d’abord les articles qui génèrent du trafic et des ventes. C’est cette liste, et non le nombre d’articles, qui doit guider la décision.
Les URLs et le référencement
Les deux plateformes ne construisent pas leurs adresses de la même façon. WooCommerce place ses fiches sous un préfixe de type /produit/ et ses catégories sous /categorie-produit/. PrestaShop compose ses URLs autour de l’identifiant du produit, avec une structure paramétrable qui inclut souvent la catégorie et se termine par .html.
Autrement dit : aucune URL ne survit telle quelle. Il faut donc une table de correspondance, ligne à ligne, de chaque ancienne adresse vers la nouvelle. Produits, catégories, pages, articles, et jusqu’aux URL paginées ou filtrées qui reçoivent du trafic.
La méthode qui fonctionne :
- Exporter toutes les URLs connues : plan de site, statistiques, et surtout l’outil de recherche Google, qui connaît des adresses que vous avez oubliées.
- Construire la table de correspondance pendant la migration, en conservant l’identifiant WooCommerce de chaque produit dans un champ de la nouvelle base. C’est ce qui rend le travail automatisable au lieu d’être fait à la main sur des milliers de lignes.
- Mettre en place les redirections 301 au moment exact de la bascule.
- Surveiller les erreurs 404 les semaines suivantes : il en reste toujours, et ce sont elles qui coûtent du trafic.
La méthode complète, valable quelle que soit la plateforme de départ, est détaillée dans migrer sans perdre son SEO.
Le déroulé d’un projet type
- Inventaire : extensions et leur usage réel, champs personnalisés, volume du catalogue, intégrations, contenu éditorial et son trafic.
- Décision sur le blog, avant toute chose.
- Installation de PrestaShop 9 sur un sous-domaine de travail, pendant que la boutique WooCommerce continue de vendre.
- Modélisation du catalogue : attributs, déclinaisons, groupes de clients, règles de taxes et de transport. C’est l’étape qui demande le plus de réflexion, et celle qu’il ne faut pas précipiter — un modèle bancal se paie pendant des années.
- Reprise des données, puis contrôle par échantillons sur les cas complexes : produits à nombreuses déclinaisons, produits en promotion, commandes avec remboursement partiel, clients à plusieurs adresses.
- Thème reconstruit, mobile d’abord.
- Modules et intégrations, un par un, avec un test entre chaque.
- Table de redirections et recette complète : parcours d’achat, paiement réel, emails transactionnels, exports comptables.
- Bascule à un creux d’activité, avec email d’information aux clients sur la réinitialisation du mot de passe.
- Surveillance : 404, indexation, conversion, journaux de paiement.
Les points de départ tarifaires sont publiés sur la page tarifs, et l’estimateur donne un ordre de grandeur selon votre catalogue.
Checklist
- Vérifier que le problème n’est pas simplement la performance ou l’hébergement
- Lister les extensions WooCommerce et leur usage réel
- Repérer les champs personnalisés et savoir où ils sont stockés
- Décider du sort du blog avant la migration, pas après
- Exporter toutes les URLs connues et leur trafic
- Modéliser attributs, déclinaisons et groupes de clients avant d’importer
- Prévoir l’email d’information sur la réinitialisation des mots de passe
- Contrôler la reprise sur les produits et commandes les plus complexes
- Poser les redirections 301 au moment de la bascule
- Surveiller 404, indexation et conversion pendant un mois
Questions fréquentes
Mes clients devront-ils vraiment recréer leur mot de passe ?
Oui. Les deux plateformes ne stockent pas les mots de passe de la même manière, et aucune ne conserve le mot de passe en clair — c’est une bonne chose pour la sécurité. La procédure standard consiste à migrer les comptes, puis à envoyer un email invitant chaque client à définir un nouveau mot de passe. Bien annoncé, cela se passe sans heurt.
Peut-on garder le même domaine ?
Oui, et c’est fortement recommandé : changer de plateforme et de domaine en même temps multiplie les risques pour le référencement. La migration se prépare sur un sous-domaine de travail, puis bascule sur le domaine définitif.
Combien de temps dure la migration ?
Plusieurs semaines pour une boutique réelle. L’installation prend une heure ; c’est la modélisation du catalogue, la reprise des données, le thème et la recette qui occupent le calendrier. Méfiez-vous des promesses de migration automatique en quelques jours : l’import brut est la partie facile, la vérification est la vraie charge.
Et mes avis clients ?
S’ils sont gérés par une plateforme externe, ils suivent sans difficulté une fois le module équivalent installé. S’ils sont stockés dans WordPress par une extension, ils se migrent au cas par cas — il faut d’abord identifier où ils sont écrits en base. À vérifier au moment de l’inventaire, car c’est un actif commercial qu’on ne veut pas perdre.
Puis-je migrer progressivement, catégorie par catégorie ?
Non, pas pour la bascule elle-même : deux boutiques actives sur le même domaine créent des doublons pour les moteurs et des ruptures de stock pour vous. En revanche, le travail est progressif : la nouvelle boutique se construit et se teste pendant que l’ancienne vend. Seule la mise en ligne est un instant unique.