EloshonChanger de plateforme e-commerce, ce n'est pas juste déplacer quelques produits d'une boutique à une autre. Chaque plateforme — Shopify, WooCommerce, PrestaShop, Wix, BigCommerce, Shopware — organise différemment les variantes, les attributs, les catégories, les prix, les stocks, les images, les clients et les commandes.
Et c'est là le piège : une migration peut sembler avoir fonctionné, alors qu'elle a silencieusement laissé une partie du catalogue en chemin. Pas d'erreur, pas de message d'alerte. Juste des produits incomplets, des filtres cassés, ou des variantes qui ont disparu sans que personne ne s'en aperçoive avant plusieurs semaines.
Ce guide explique pourquoi ça arrive, comment l'éviter, et comment Eloshon Converter a été conçu spécifiquement pour ce problème : ne jamais perdre une donnée sans le dire.
Pourquoi une migration e-commerce perd des données
Si vous n'avez jamais géré de boutique en ligne, voici le principe de base : un catalogue produit se transporte généralement sous forme de fichier CSV (un tableau de données, un peu comme un fichier Excel simplifié) que l'on exporte d'une plateforme puis que l'on importe dans une autre.
Le problème, c'est que ce fichier n'est qu'un tableau à plat. Il ne dit rien sur la façon dont chaque plateforme comprend les données qu'il contient. Prenons un exemple concret.
Un t-shirt existe en 3 couleurs et 4 tailles. Sur WooCommerce, ces informations sont enregistrées comme des « attributs » liés à des colonnes techniques du type attribute_pa_color. Sur Shopify, la même notion s'appelle une « option de variante », avec une limite technique stricte : 3 options et 100 variantes par produit (2048 sur les catalogues les plus récents via une API dédiée, mais toujours avec une limite). Sur Shopware, un produit ne peut être rattaché qu'au niveau de catégorie le plus bas — s'il est rattaché à une catégorie intermédiaire, il devient invisible en boutique sans qu'aucune erreur ne s'affiche.
Un simple mapping « colonne source → colonne destination » ne peut pas deviner ces règles. Il ne peut pas non plus deviner que renommer une valeur d'option sur Shopify (par exemple transformer « Taille : XL » en « Taille : X-Large ») fait traiter la variante comme entièrement nouvelle par la plateforme — avec suppression silencieuse de l'ancienne variante et de son stock, même si la référence (SKU) n'a pas changé. Ce n'est pas une hypothèse : c'est un cas documenté et remonté plusieurs fois sur la communauté officielle Shopify, sur des catalogues de plus de 1 500 références.
D'autres pièges reviennent constamment, tous documentés sur les forums d'aide des plateformes elles-mêmes :
- Des collections dynamiques (basées sur des règles automatiques) qui redeviennent des catégories figées une fois migrées — la donnée existe toujours, mais son comportement a changé sans que personne ne le décide explicitement.
- Des noms d'attributs non rédigés en anglais (accents, caractères arabes ou asiatiques) qui cassent le rapprochement automatique des variantes.
- Des catégories imbriquées sur plus de 8 niveaux qui remontent brutalement à la racine sur BigCommerce.
- Une devise source différente de l'euro qui fait échouer silencieusement tout un import sur Shopware — l'outil annonce un succès, mais zéro produit n'a été réellement créé.
- Des fichiers fournisseurs externes (comme un export BigBuy) rejetés pour un simple problème d'en-tête de colonne ou de guillemets mal échappés — ou pire, acceptés avec des prix multipliés par erreur de conversion.
Aucun de ces cas n'est une fatalité. Mais aucun n'est non plus détectable par un simple copier-coller de colonnes. Il faut comprendre ce que chaque donnée représente, pas seulement comment elle est nommée.
La méthode Eloshon Converter : convertir, préserver, signaler
C'est le principe central d'Eloshon Converter : face à chaque donnée rencontrée dans un catalogue, l'outil ne se contente jamais de la copier aveuglément ou de la faire disparaître. Il suit toujours l'un de ces trois chemins.
| Chemin | Ce qui se passe | Exemple |
|---|---|---|
| Convertie | Un équivalent direct existe dans la plateforme cible | Un prix, un SKU, une image principale |
| Préservée | Pas d'équivalent direct, mais la donnée est conservée sous une autre forme exploitable (souvent un metafield) | Une caractéristique technique sans champ dédié (garantie, matière, classe énergétique) |
| Signalée | Aucune conversion fiable n'est possible, l'utilisateur est prévenu plutôt que la donnée ne disparaisse | Plusieurs colonnes qui semblent toutes désigner la couleur d'un produit |
Concrètement : si un fichier WooCommerce contient à la fois Color, attribute_pa_color et option_1, un convertisseur classique appliquera une règle fixe, quitte à se tromper sur un catalogue mal nettoyé. Eloshon Converter identifie que plusieurs colonnes se disputent la même information de variante et pose la question plutôt que de deviner : « Quelle colonne représente vraiment la couleur ? »
C'est la différence entre une migration qui paraît avoir marché et une migration dont on sait exactement ce qui a été transféré, transformé, ou laissé de côté.
Ce qu'Eloshon Converter prend en charge
- Produits et variantes — y compris les combinaisons complexes (couleur + contenance sur un même produit, un cas très fréquent en cosmétique et qui pose justement question sur les forums Shopify quand on migre depuis PrestaShop).
- Prix, stocks et paliers de quantité — en distinguant prix HT, prix TTC, prix promotionnel et prix par palier, plutôt que de tout réduire à une seule colonne
price. - Images — en conservant, quand c'est possible, l'association entre une image précise et une variante (couleur, déclinaison), et pas seulement une galerie générique.
- Catégories et hiérarchies, y compris les cas où la plateforme source accepte des rattachements que la cible refuse, ou où la cible limite la profondeur (BigCommerce).
- Identifiants produit — EAN, GTIN, UPC, ISBN — un champ que plusieurs outils de migration n'incluent pas par défaut, ce qui oblige souvent à une configuration manuelle après coup.
- Traductions et boutiques multilingues.
- Métadonnées et champs personnalisés.
- Commandes et clients, avec deux points d'attention particuliers.
Le consentement marketing n'est pas transférable par défaut
Un client qui a accepté de recevoir des emails marketing sur la boutique source n'a pas automatiquement donné ce consentement pour la nouvelle boutique. La présence d'un champ « consentement : oui » dans le fichier source ne suffit pas à justifier sa réutilisation dans un nouveau contexte. Eloshon Converter traite ce champ comme une donnée à part, qui demande une décision explicite plutôt qu'une simple recopie.
La numérotation des commandes et de la facturation
Un exemple réel et documenté : sur BigCommerce, les numéros de commande sont incrémentaux, et le numéro d'origine ne peut techniquement pas être préservé lors d'une migration — un point qui touche directement aux obligations comptables de numérotation des factures. Pour une entreprise soumise à des obligations de séquence de facturation, une migration ne doit jamais réécrire arbitrairement cette séquence, ni créer de trous ou de doublons. Eloshon Converter distingue explicitement la reprise de l'historique de commandes de la logique de numérotation des nouvelles factures, en tenant compte des obligations applicables à l'entreprise selon sa juridiction.
Pourquoi Shopify, WooCommerce, PrestaShop, Wix, BigCommerce et Shopware ne se comparent pas colonne à colonne
Chaque plateforme a ses propres règles internes, souvent invisibles tant qu'on ne les a pas heurtées :
| Plateforme | Contrainte technique concrète |
|---|---|
| Shopify | 3 options et 100 variantes par produit en natif (jusqu'à 2048 via une API dédiée, plafond quotidien de création à surveiller sur les gros catalogues) |
| WooCommerce | Attributs globaux, attributs locaux et champs personnalisés (ACF) coexistent sans hiérarchie stricte ; les clés de variation doivent être « sluggifiées » exactement au format attendu, sinon le frontend ne reconnaît plus les variantes |
| PrestaShop | Combinaisons de déclinaisons (couleur + contenance sur une même fiche) et champ EAN/GTIN souvent absent des migrations par défaut |
| Wix | Mots de passe clients jamais transférables (comme partout ailleurs), galerie limitée à 19 images par produit en import |
| BigCommerce | Profondeur de catégories limitée à 8 niveaux, numérotation de commande incrémentale non réécrivable |
| Shopware | Rattachement produit obligatoire au niveau de catégorie le plus bas, sensibilité à la devise et aux caractères spéciaux lors de l'import |
Aucune de ces contraintes n'est un défaut de la plateforme cible — ce sont juste des règles différentes. Le problème apparaît quand on les ignore.
Cas concrets par sens de migration
WooCommerce → Shopify. Le fichier source contient des taxonomies et attributs (pa_heel-height, pa_brand, product_cat). Sans mapping explicite vers les metafields Shopify, ces informations n'atterrissent nulle part d'exploitable — elles sont là, mais invisibles pour les filtres produit. Eloshon Converter identifie ces relations avant l'export plutôt qu'après coup.
Shopify → WooCommerce. Les collections « intelligentes » de Shopify (basées sur des règles automatiques, par exemple « tous les produits tagués été ») deviennent des catégories figées sur WooCommerce. La donnée est bien là, mais son comportement dynamique disparaît — un exemple typique du cas « préservée mais transformée ».
PrestaShop → Shopify. Cas réel documenté sur un catalogue de 900 références en cosmétique : les produits combinent des déclinaisons de couleur et de contenance sur une même fiche. Le champ EAN, souvent absent des migrations standards, doit être explicitement demandé. Sans redirections 301 (les règles qui redirigent automatiquement une ancienne URL vers la nouvelle), un cas réel a montré une perte de trafic continue et difficile à diagnostiquer plusieurs mois après la migration.
Wix → Shopify ou WooCommerce. Les intégrations ERP/CRM/transporteur, souvent limitées côté Wix, doivent être reconstruites plutôt que migrées telles quelles. Les images d'articles de blog suivent rarement le texte.
BigCommerce → Shopify ou WooCommerce. Les options produit complexes (catalogue B2B avec dizaines de milliers de références) ne se mappent pas 1:1 sur les 3 options natives de Shopify — un cas réel documenté a nécessité une restructuration complète d'un produit passant de 5 options et 1708 variantes à un modèle compatible.
Shopware → Shopify ou WooCommerce. Les rattachements de catégories lus dans Shopware sont recréés selon les règles de la plateforme cible. Un produit qui ne peut pas être rattaché est signalé dans le rapport, au lieu de disparaître du front sans message.
Pas d'export propre ? Eloshon Scraper prend le relais
Toutes les migrations ne partent pas d'un export propre. Un concurrent, un fournisseur, ou une ancienne boutique sans accès administrateur ne fournissent souvent aucun fichier exploitable — seulement un site public à consulter page par page.
Eloshon Scraper transforme ces informations publiques en données structurées, qu'Eloshon Converter peut ensuite adapter à la plateforme de destination :
C'est exactement le type de problème que rencontrent les entreprises qui travaillent avec des flux fournisseurs externes (dropshipping, grossistes) : un export CSV reçu tel quel peut être rejeté pour un simple souci d'en-tête de colonne, ou pire, importé avec des prix mal convertis sans que personne ne le remarque avant que les clients ne s'en plaignent. Le duo Scraper + Converter couvre ce cas de bout en bout : extraire, structurer, contrôler, convertir.
À noter : les enseignes ou sites cités en exemple dans ce contexte ne sont ni clientes ni partenaires d'Eloshon — ce sont des illustrations des possibilités techniques du scraping. L'usage des données récupérées doit toujours respecter les conditions d'accès du site concerné et la réglementation applicable.
Pour qui
E-commerçants qui changent de plateforme, reprennent un catalogue existant, ou préparent un nouveau canal de vente.
Agences e-commerce qui gèrent des migrations clients, nettoient des catalogues hétérogènes, ou traitent des fichiers venant de sources multiples sans documentation.
Pourquoi pas juste un mapping CSV
Deux fichiers peuvent tous les deux contenir les colonnes name, price, sku, category tout en représentant des modèles commerciaux complètement différents. Le CSV n'est qu'un format de transport — la vraie question est : que signifie chaque donnée, et avec quoi est-elle liée ?
C'est cette couche de compréhension, pas juste de correspondance, qui permet à Eloshon Converter de traiter correctement les variantes, les attributs, les catégories, les prix, les images, les stocks, les traductions et les commandes — sans jamais faire disparaître une information sans le dire.
En résumé
Une migration e-commerce réussie ne se mesure pas au nombre de lignes arrivées dans le fichier de destination. Elle se mesure à la capacité de répondre à des questions précises : quelles variantes ont été reconnues, quelles images ont gardé leurs relations, quelles données n'avaient pas d'équivalent, et lesquelles nécessitent une décision humaine.
Eloshon Converter — et Eloshon Scraper pour les cas sans export propre — ont été conçus pour que ces questions aient toujours une réponse, plutôt que de rester cachées derrière un bouton « Importer ».
Pour le déroulé pratique d'une migration — export, format intermédiaire, directions prises en charge, redirections 301 — voir aussi Comment migrer une boutique Shopify, WooCommerce, Wix, BigCommerce ou PrestaShop ?