Votre fichier est importé.
Shopify affiche les produits.
Les clients apparaissent dans le back-office.
À première vue, tout va bien.
Pourtant, plusieurs jours plus tard, les anomalies commencent à apparaître.
Une variante possède le mauvais SKU.
Une image manque sur certaines références.
Un client existe deux fois.
Des stocks sont incorrects.
Une commande historique n’est associée à aucun client.
Quelques catégories ne correspondent plus à la nouvelle organisation.
Voilà pourquoi il existe une différence fondamentale entre :
importer des données
et
réussir une migration de données.
Sur une petite boutique, une erreur peut parfois être corrigée manuellement.
Sur plusieurs milliers ou plusieurs dizaines de milliers de références, ce raisonnement ne tient plus.
La qualité d’une migration Shopify repose alors sur quatre opérations :
extraire → transformer → importer → contrôler.
Et le quatrième mot est probablement le plus important.
Deux plateformes e-commerce peuvent contenir exactement les mêmes informations tout en les organisant différemment.
Prenons un produit simple :
T-shirt Classic
Il peut avoir :
L’ancienne plateforme possède son propre modèle.
Shopify possède le sien.
La migration ne consiste donc pas seulement à déplacer :
« T-shirt Classic »
Elle doit reconstituer correctement toutes les relations qui permettent à ce produit de fonctionner.
C’est ce qu’on appelle le mapping des données.
Avant toute transformation, nous voulons connaître les volumes.
Combien avez-vous de :
Il faut établir une situation de référence.
Par exemple :
| Donnée | Source |
| Produits | 8 420 |
| Variantes | 17 860 |
| Clients | 31 250 |
| Commandes historiques | 42 110 |
| Catégories | 184 |
Ces chiffres seront très utiles après l’import.
Pourquoi ?
Parce qu’ils permettront de poser une question simple :
Avons-nous retrouvé ce que nous avions au départ ?
💡 Conseil Refresh
Avant toute migration importante, conservez les exports sources d’origine.
Ils constituent votre photographie de référence.
Ne travaillez pas uniquement sur des fichiers transformés dont vous ne pourriez plus retracer l’origine.
Le mapping consiste à décider où chaque information doit aller.
Exemple simplifié :
| Ancienne donnée | Destination Shopify |
| Nom produit | Title |
| Référence | SKU |
| Description longue | Description |
| Prix TTC | Price selon configuration |
| Catégorie | Collection ou logique de collection |
| Couleur | Option |
| Taille | Option |
| Champ matière | Métachamp / information produit selon architecture |
Le nom exact des champs n’est pas le sujet principal.
Le vrai sujet est :
Quelle information source doit alimenter quelle information Shopify ?
Cette étape est particulièrement importante lorsque l’ancienne plateforme possède :
Sans mapping préalable, on commence souvent à improviser pendant l’import.
Et l’improvisation devient très coûteuse lorsqu’elle concerne plusieurs milliers de lignes.
Une migration n’est pas une photocopieuse.
Si votre base actuelle contient :
les importer dans Shopify ne les rendra pas meilleurs.
Vous déplacerez simplement le problème.
Il faut donc distinguer :
export brut
et
fichier prêt pour migration.
Entre les deux se trouve une phase de transformation.
Elle peut servir à :
Les CSV Shopify doivent notamment respecter son format attendu et être encodés correctement en UTF-8. Shopify limite actuellement les fichiers CSV de produits et de clients à 15 Mo par fichier ; les imports volumineux doivent donc parfois être découpés.
Ici, l’ordre n’est pas un simple choix d’organisation.
Il influence les relations entre les données.
Shopify recommande actuellement :
1. Produits
↓
2. Clients
↓
3. Commandes historiques
L’objectif est que les commandes puissent être reliées aux produits et aux clients déjà présents dans la nouvelle boutique.
Imaginez l’inverse.
Vous importez une commande contenant le produit A alors que le produit A n’existe pas encore correctement dans Shopify.
Vous compliquez immédiatement le rapprochement.
📌 À retenir
Une migration de données possède des dépendances.
La question n’est pas seulement :
« Qu’est-ce qu’on importe ? »
mais également :
« Dans quel ordre faut-il le faire pour préserver les relations entre les informations ? »
Les produits constituent généralement la première grande masse de données transférée.
Shopify permet notamment l’import de produits à partir de fichiers CSV et recommande, pour les migrations importantes réalisées par un partenaire, de commencer par tester un sous-ensemble avant l’import à grande échelle.
Mais un produit contient plusieurs niveaux d’information.
Il faut définir les identifiants qui permettront de reconnaître les mêmes éléments avant et après migration.
Le SKU est souvent particulièrement important.
Par exemple :
TSHIRT-BLACK-M
doit rester identifiable comme la même référence commerciale.
Cette cohérence devient fondamentale lorsque les produits sont ensuite connectés à :
Une référence qui change sans raison peut casser bien plus que la fiche produit.
Une variante est une source classique d’erreurs.
Prenons :
T-shirt / Noir / M
Il faut s’assurer qu’après migration il possède toujours :
Et attention aux modifications réalisées après import.
Shopify précise actuellement que certaines modifications des valeurs d’options via CSV peuvent recréer des identifiants de variantes. Cela peut perturber des dépendances tierces utilisant précisément ces identifiants.
⚠️ Erreur fréquente
Faire plusieurs gros imports successifs sur un catalogue de production sans comprendre le comportement de remplacement des données.
Une correction massive doit être préparée et testée exactement comme un premier import.
Un CSV ne transporte pas physiquement une image.
Il transporte notamment son emplacement afin que l’image puisse être récupérée au moment de l’import.
Shopify précise ainsi que les CSV produits utilisent des URLs pour les images.
Avant de couper l’ancien environnement, il faut donc s’assurer que :
Sur un gros catalogue, la vérification doit être structurée.
Une ancienne catégorie ne devient pas automatiquement une collection Shopify parfaite.
Vous pouvez décider de :
Il faut donc différencier :
migration des données produit
et
reconstruction de l’architecture commerciale du catalogue.
Votre ancienne plateforme peut contenir des informations spécifiques :
Toutes ne correspondent pas nécessairement à une colonne standard.
Il faut alors décider si elles deviennent :
C’est exactement le rôle du mapping.
Le stock paraît simple :
Mais il devient plus complexe dès qu’il existe plusieurs emplacements.
Pour une boutique Shopify ne disposant que d’un seul emplacement, le CSV produit peut actuellement contenir la quantité de stock.
Pour plusieurs emplacements, Shopify prévoit une gestion spécifique du stock, notamment via son CSV de stock ou ses outils/API dédiés.
Cela signifie qu’un catalogue multi-entrepôts doit être préparé avec beaucoup plus de précision.
Il faut savoir :
🧠 Le point de vue Refresh
Sur une boutique en activité, le stock n’est pas une donnée statique.
C’est une donnée qui peut changer pendant que vous êtes en train de la migrer.
La stratégie d’import doit donc prendre en compte le moment où la donnée est extraite, pas seulement sa valeur.
Shopify permet actuellement l’import de profils clients par CSV, applications de migration ou API.
Mais là encore, le nombre de lignes importées ne suffit pas comme contrôle.
Les bases clients contiennent fréquemment :
Shopify précise actuellement que les doublons d’adresse email ou de numéro de téléphone peuvent être ignorés ou affecter l’import selon les données présentes.
Avant migration, il faut donc définir :
Qu’est-ce qui identifie réellement un client unique ?
Il faut vérifier la reprise des informations réellement utiles :
Une donnée peut être présente dans le fichier tout en étant inutilisable si elle n’est pas placée au bon endroit.
Le consentement marketing mérite une vigilance particulière.
Votre ancienne base peut contenir :
Il ne faut pas transformer automatiquement chaque adresse email importée en abonné marketing.
La migration technique doit respecter la nature du consentement déjà enregistré.
Les mots de passe sont un cas particulier.
Shopify précise qu’ils ne peuvent pas être migrés depuis une autre boutique au moyen d’un CSV, car ils sont chiffrés en dehors de Shopify. Le parcours d’accès au compte doit donc être prévu dans la migration.
Le client existe.
Son ancien mot de passe n’est pas pour autant une donnée que vous pouvez simplement copier.
C’est un point souvent mal compris.
Le fichier client et l’historique de commandes sont deux sujets différents.
Shopify précise actuellement que les colonnes telles que Total Spent et Total Orders ne permettent pas d’importer artificiellement dans un profil client le chiffre d’affaires ou le nombre de commandes réalisés sur une autre plateforme.
Les données de commandes ne sont pas importées via le CSV client.
Autrement dit :
profil client importé ≠ historique commercial recréé.
Pour retrouver l’historique d’achat dans Shopify, il faut travailler sur la migration des commandes elles-mêmes.
Les commandes sont plus complexes que les produits ou les clients.
Une commande peut contenir :
Shopify prévoit actuellement la migration en masse de commandes historiques via des applications de migration ou ses API de commandes et transactions.
C’est précisément pour cela que les commandes viennent après produits et clients.
Les relations existent déjà.
Il devient possible de reconstituer un historique plus cohérent.
Un détail opérationnel peut créer une belle surprise.
Shopify indique que l’import de commandes historiques peut déclencher les notifications de nouvelle commande destinées aux employés configurés pour les recevoir.
Sur un gros historique, votre équipe pourrait donc recevoir une avalanche de notifications.
Shopify recommande de désactiver temporairement ces notifications lorsqu’on souhaite éviter ce comportement puis de les réactiver après l’import.
C’est exactement le genre de détail qui ne se voit pas dans un fichier CSV.
Mais qui fait partie d’une migration correctement préparée.
Pas nécessairement.
C’est une décision métier.
Il faut se demander pourquoi vous souhaitez cet historique.
Pour :
Vous pouvez conserver une archive de l’ancienne plateforme tout en important dans Shopify uniquement la période utile.
Sur sa checklist Shopify Plus actuelle, Shopify recommande au minimum de conserver dans Shopify les commandes encore susceptibles d’être concernées par une période de retour ou d’échange, et évoque une profondeur historique plus importante comme bonne pratique.
La bonne décision dépend néanmoins de votre activité.
Il n’existe pas une méthode universellement meilleure.
Adapté lorsque :
Pertinente lorsqu’une application sait déjà établir les correspondances entre la plateforme de départ et Shopify.
Cela peut accélérer le travail.
Mais cela ne supprime pas la nécessité de contrôler le résultat.
Pertinente lorsque :
Shopify présente actuellement ces différentes approches dans sa propre méthodologie de migration.
La méthode doit donc être choisie après l’analyse des données.
Pas avant.
Supposons que vous ayez 25 000 produits.
Vous préparez le fichier.
Vous lancez immédiatement les 25 000.
Puis vous découvrez que :
Vous venez de transformer une petite erreur de mapping en erreur industrielle.
Shopify recommande d’ailleurs explicitement aux partenaires réalisant une migration importante de tester d’abord un petit sous-ensemble dans une boutique de développement.
La logique est simple :
Test 1
20 à 50 produits représentatifs.
Pas uniquement les plus simples.
Inclure :
Validation
Si le modèle fonctionne :
Import massif
Puis nouvelle validation.
💡 Conseil Refresh
Le meilleur échantillon n’est pas aléatoire.
Il doit volontairement inclure les cas qui ont le plus de chances de casser la migration.
Sur un projet comportant plus de 30 000 références, vérifier les produits un par un n’était évidemment pas une option.
Le projet devait changer d’échelle.
La question n’était plus :
« Est-ce que le produit que je regarde est correct ? »
mais :
« Comment démontrer que l’ensemble du catalogue est cohérent ? »
Il faut alors raisonner par contrôles.
Avant :
30 000+ références.
Après :
retrouve-t-on le volume attendu ?
Les références sources existent-elles toutes dans la destination ?
Y a-t-il :
Un produit possédant 12 variantes avant migration en possède-t-il toujours 12 ?
Les produits possédant plusieurs médias les ont-ils conservés ?
Comparer :
Plutôt que regarder tout ce qui fonctionne, il devient plus efficace de produire des listes :
SKU source absent de Shopify
prix source ≠ prix Shopify
nombre de variantes source ≠ destination
image manquante
stock incohérent
C’est cette logique qui transforme une migration massive en processus contrôlable.
Une migration réussie à :
99,5 %
semble excellente.
Mais sur 30 000 références :
0,5 % = 150 références.
150 références incorrectes peuvent représenter :
C’est pourquoi nous préférons parler de :
nature des anomalies
plutôt que simplement de :
taux de réussite global.
🧠 Le point de vue Refresh
Sur un gros catalogue, l’automatisation n’est pas uniquement utile pour migrer les données.
Elle est surtout indispensable pour chercher automatiquement les différences.
Nous utilisons plusieurs niveaux de contrôle.
Comparer :
Vérifier les relations :
Comparer :
Ouvrir la boutique.
Chercher les produits.
Tester les filtres.
Ajouter une variante au panier.
Ajouter une variante au panier.
Contrôler un historique.
Même lorsque les contrôles automatisés sont bons, sélectionner des cas représentatifs permet de vérifier la réalité visuelle.
📌 À retenir
La meilleure stratégie combine :
contrôle automatisé + comparaison quantitative + tests fonctionnels + vérification humaine.
Voici un problème très concret.
Lundi, vous exportez vos clients.
Votre ancienne boutique reste ouverte.
Mardi, 40 nouveaux clients s’inscrivent.
Mercredi, 65 commandes supplémentaires sont passées.
Vendredi, vous basculez vers Shopify.
Si vous utilisez uniquement l’export de lundi :
vous avez déjà perdu plusieurs jours d’évolution.
Il faut donc prévoir une reprise différentielle ou une synchronisation finale des données qui ont changé entre :
l’export initial
et
la bascule réelle.
Selon le projet, cela peut concerner :
Nous approfondirons cette question dans l’article suivant :
Peut-on migrer vers Shopify sans interrompre les ventes ?
Car à ce stade, la migration des données rejoint directement la continuité de l’activité commerciale.
On découvre les incompatibilités après plusieurs milliers de lignes.
En cas de problème, il devient impossible de revenir à la donnée d’origine.
20 000 produits peuvent être présents avec 5 000 variantes incorrectes.
Un client existe mais ses commandes ne lui sont pas associées.
Les cas difficiles restent invisibles jusqu’à l’import massif.
Ils évoluent pendant la migration.
L’import des clients ne recrée pas automatiquement leurs anciennes commandes.
Surtout sur les emails, téléphones ou références produits.
Cela signifie que le système a terminé le traitement.
Pas que toutes les données sont commercialement correctes.
Tant que la nouvelle base n’est pas validée, l’ancienne peut rester une source extrêmement utile de comparaison.
Produits
Stocks
Clients
Commandes
Contrôles globaux
Shopify permet de transférer de grandes quantités de données.
Mais la difficulté d’une migration e-commerce n’est pas simplement de réussir à faire entrer ces données dans Shopify.
Elle est de s’assurer qu’elles ont toujours le même sens après le transfert.
Un produit doit rester lié à ses variantes.
Une variante doit conserver son SKU.
Un client doit rester identifiable.
Une commande doit retrouver les bonnes relations.
Un stock doit être cohérent au moment où la boutique ouvre.
Sur quelques centaines de références, une partie de ce travail peut encore être contrôlée manuellement.
Sur plusieurs milliers ou plusieurs dizaines de milliers, il faut changer de méthode.
Chez Refresh, nous raisonnons alors en quatre étapes :
extraire
→ conserver une source fiable ;
transformer
→ adapter les données au modèle Shopify ;
importer
→ respecter l’ordre et la méthode adaptée ;
contrôler
→ comparer systématiquement la source et la destination.
Parce qu’entre :
« Shopify a accepté mon fichier »
et
« ma migration de données est fiable »
il existe parfois plusieurs milliers de vérifications.
Et c’est précisément là que se joue la qualité du projet.
Shopify recommande actuellement d’importer d’abord les produits, puis les clients et enfin les commandes historiques afin que les commandes puissent être correctement associées aux produits et aux clients.
Oui. Shopify permet l’import de produits via un fichier CSV respectant son format. Pour les volumes ou modèles de données plus complexes, une application de migration ou une solution basée sur API peut être préférable.
Shopify indique actuellement une limite de 15 Mo pour les fichiers CSV de produits et les CSV clients. Un import plus volumineux peut donc nécessiter plusieurs fichiers ou une autre méthode de migration.
Non. Le CSV client sert au profil client. Les informations de commandes historiques nécessitent une méthode distincte. Les commandes doivent être migrées séparément.
Non. Les champs correspondant aux anciennes dépenses ou au nombre de commandes ne recréent pas l’historique provenant d’une autre plateforme. Pour retrouver l’historique commercial, il faut migrer les commandes concernées.
Ils ne peuvent pas être migrés depuis une autre plateforme avec le CSV client Shopify. Le parcours de connexion ou de création d’accès doit donc être anticipé.
La quantité du CSV produit est adaptée au cas d’un seul emplacement. Pour plusieurs emplacements, la stratégie de migration doit tenir compte des outils spécifiques de gestion de stock Shopify et de la source qui restera maître du stock.
Il faut combiner des contrôles de volumes, SKU, variantes, prix, images et stocks avec une analyse automatisée des écarts, des tests fonctionnels et un échantillonnage manuel.
Le véritable enjeu n’est pas uniquement de les importer dans Shopify.
Il est de pouvoir démontrer que les produits, variantes, clients, commandes et stocks présents après migration correspondent réellement à ce que vous aviez avant.
Chez Refresh, nous commençons par cartographier les données, leurs relations et les contrôles nécessaires avant de choisir la méthode de migration.
Parce qu’un gros volume de données ne demande pas seulement un outil d’import plus puissant.
Il demande surtout une méthode de validation plus fiable.
| Terme | Définition |
| Mapping de données | Correspondance entre les informations de la plateforme source et les champs du système de destination. |
| Source de vérité | Système ou fichier considéré comme référence pour vérifier l’exactitude d’une donnée. |
| CSV | Fichier tabulaire utilisé notamment pour importer et exporter des données en masse. |
| SKU | Référence permettant d’identifier précisément un produit ou une variante. |
| Variante | Version d’un produit correspondant à une combinaison d’options comme une taille ou une couleur. |
| Métachamp | Champ permettant de stocker une information supplémentaire structurée dans Shopify. |
| Intégrité des données | Conservation de la cohérence et des relations entre les informations pendant une migration. |
| Rapprochement | Comparaison entre données source et données destination afin de détecter des différences. |
| Reprise différentielle | Transfert final des données créées ou modifiées entre l’import initial et la bascule. |
| Échantillonnage | Contrôle approfondi d’un ensemble représentatif de données plutôt que de chaque élément individuellement. |
