Le 23 avril 2024, en clôturant le chantier de migration d’une boutique PrestaShop vers WooCommerce et Elementor, le constat était sans appel : 60 % du temps facturé sur ce projet n’avait rien à voir avec la mise en page Elementor elle-même, mais avec le mapping manuel des catégories et des attributs produit entre les deux systèmes. Ce cas revient sur ce déséquilibre, rarement anticipé correctement au moment du chiffrage initial.
Ce cas ne traite pas de la migration depuis Shopify, dont la structure de données et les contraintes d’export suivent une tout autre logique : il se concentre sur les spécificités du passage PrestaShop vers WooCommerce, sur un catalogue de taille moyenne comportant plusieurs centaines de références avec déclinaisons.
Le contexte du projet
Le client exploitait une boutique PrestaShop avec un catalogue de vêtements techniques, structuré en catégories croisées (par sport et par type de produit) et des déclinaisons de taille et de couleur gérées via le système de combinaisons natif de PrestaShop. L’objectif était de reconstruire l’ensemble sous WooCommerce, avec un habillage entièrement réalisé dans Elementor via le Theme Builder pour les archives et fiches produit.
Le premier écueil : les catégories croisées
PrestaShop autorise nativement un produit à appartenir à plusieurs catégories dans une arborescence, avec une catégorie par défaut distincte des catégories secondaires. WooCommerce fonctionne différemment : les catégories produit forment une taxonomie à plat, sans distinction structurelle stricte entre catégorie principale et secondaire au niveau de la base de données, cette hiérarchie devant être recréée manuellement en s’appuyant sur les attributs de taxonomie WordPress. Il a fallu redéfinir, pour chaque produit du catalogue, une catégorie principale explicite, information qui n’était pas directement exploitable telle quelle depuis l’export PrestaShop.

Le second écueil : les déclinaisons et attributs
PrestaShop gère les déclinaisons via un système de combinaisons où chaque variante (taille, couleur) peut avoir son propre stock et son propre prix. WooCommerce utilise un système d’attributs globaux associés à des variations de produit, avec une logique de configuration différente dans l’interface d’administration. La correspondance n’est jamais automatique :
- Les attributs PrestaShop nommés localement (« Taille EU », « Couleur ») ont dû être recréés comme attributs globaux WooCommerce, avec vérification de la cohérence des valeurs entre les deux systèmes.
- Certaines combinaisons PrestaShop obsolètes, laissées en base sans être réellement en vente, ont nécessité un tri manuel avant import pour ne pas polluer le nouveau catalogue.
- Les images spécifiques à chaque déclinaison de couleur ont dû être réassociées une par une, l’export ne conservant pas toujours ce lien de façon exploitable directement.
Le temps réellement consacré à la mise en page Elementor
Une fois le catalogue proprement importé dans WooCommerce, la construction des gabarits d’archive et de fiche produit dans le Theme Builder d’Elementor Pro a représenté une part modeste du temps total du projet, le Loop Grid et les widgets WooCommerce natifs couvrant rapidement l’essentiel des besoins d’affichage. La fiche produit a repris la structure standard proposée par le widget Elementor dédié aux variations WooCommerce, avec un ajustement mineur des marges pour correspondre à la charte graphique du client, ce qui a représenté à peine quelques jours de travail sur l’ensemble du projet.
Ce qu’on retient pour le chiffrage des prochains projets
Le point qu’on intègre désormais systématiquement dans nos devis de migration PrestaShop : demander un export du catalogue en amont du chiffrage, pour évaluer concrètement le volume d’attributs et de catégories croisées avant de s’engager sur un forfait, plutôt que d’estimer ce poste à la louche.
En résumé
Une migration PrestaShop vers WooCommerce et Elementor se révèle rarement équilibrée entre mise en page et structuration des données : le mapping des catégories croisées et des attributs de déclinaison absorbe souvent la majorité du temps de travail, un point à intégrer dès le chiffrage pour éviter les mauvaises surprises en cours de projet.