Migrer vers Shopify revient à traduire les données et leurs relations dans un modèle e-commerce hébergé où Products, variantes, collections, menus, Customers, Orders, contenus, metafields, metaobjects, applications et intégrations ont des rôles clairement définis. Les structures de la plateforme source correspondent rarement une à une à celles de Shopify. Une Category source peut devenir une collection, une entrée de menu, une page, un filtre, une redirection ou une classification interne ; un champ personnalisé peut devenir un champ natif, un metafield, une référence vers un metaobject, une valeur gérée par une application ou être volontairement exclu.
La cible doit préserver le sens métier nécessaire après le lancement, et non reproduire la structure accidentelle créée au fil des années par les contournements de la plateforme source. Cela exige de traduire les relations : Product vers variante, collection vers parcours de découverte, Customer vers Order, contenu vers destination URL et identifiant externe vers le système qui continue à l’utiliser.
Pourquoi les différences de modèle de données sont importantes
Shopify est une plateforme cible SaaS hébergée qui impose ses propres structures pour le catalogue, la boutique en ligne, les Customers, les Orders, les contenus et la configuration. Ce modèle peut simplifier l’exploitation de la boutique cible, mais il signifie aussi que la plateforme source ne doit pas être copiée mécaniquement.
Une plateforme source peut utiliser des Categories, attributs de base de données, extensions, modules, champs personnalisés, types de Product spécifiques, logique multi-boutiques ou données propres au thème afin de produire un résultat métier. Shopify peut représenter le même objectif au moyen de Products, options, variantes, collections, catégorie de Product, type de Product, tags, metafields, metaobjects, applications, thèmes, Markets, redirections d’URL ou d’une configuration distincte dans la boutique cible.
L’objectif n’est pas l’identité structurelle, mais l’utilisabilité de la boutique cible. Un bon modèle Shopify préserve le sens commercial et opérationnel qui compte réellement : les clients choisissent les bons Products, parcourent les bons regroupements, lisent les bons contenus, accèdent aux informations utiles sur leur compte et leurs Orders, suivent les URL importantes et disposent des fonctions prises en charge par les applications lorsqu’elles font partie du périmètre attendu au lancement.
| Sens dans la plateforme source | Destination Shopify possible | Question de planification |
|---|---|---|
| Différence entre Products achetables | Option de Product, variante, SKU, prix, stock, média ou comportement pris en charge par une application | La différence correspond-elle à un véritable choix d’achat ou uniquement à une information descriptive ? |
| Category ou rayon | Collection, menu, filtre, catégorie de Product, type de Product, tag, page ou redirection | La structure aide-t-elle le client à découvrir les Products ou sert-elle uniquement à une organisation héritée ? |
| Champ personnalisé | Champ natif, metafield, metaobject, champ d’application, référence d’intégration ou exclusion volontaire | Qui utilisera la valeur après le lancement et où doit-elle être affichée ou traitée ? |
| Données d’une extension, d’un module ou d’une application | Configuration d’une application Shopify, metafields, plan d’intégration, configuration manuelle ou travail applicatif séparé | La donnée reste-t-elle utile sans le comportement qui l’exploitait dans la source ? |
| Structure internationale ou multi-boutiques | Markets, domaines, langues, devises, catalogues, redirections ou planification de boutiques distinctes | Quelles différences régionales doivent rester visibles et utilisables après le lancement ? |
| URL sensible pour le SEO | Handle Shopify, route, redirection, chemin de collection, page, Blog Post ou décision de nettoyage | Quels chemins source méritent une redirection et une vérification de destination prioritaires ? |
Différences de structure du catalogue et des Products
La planification du catalogue Shopify part de la relation entre Products, options, variantes, catégorie de Product, type de Product, tags, metafields, médias et stock. Les boutiques sources utilisent souvent des structures plus diverses, en particulier lorsqu’elles proviennent de plateformes auto-hébergées, très dépendantes des extensions ou fortement personnalisées.
Un Product doit représenter l’article vendu. Les options doivent représenter les dimensions de choix visibles par le client, comme la taille, la couleur, la matière, le conditionnement, la finition ou la configuration. Les variantes représentent les combinaisons achetables créées à partir de ces options. Cette logique est simple lorsque la source sépare déjà les vrais choix d’achat des informations descriptives. Elle devient plus délicate lorsque la plateforme source utilise des Products configurables, Products groupés, options personnalisées, bundles, kits, champs de personnalisation, suppléments facultatifs ou logique d’extension.
Les différences entre Products doivent être classées selon leur fonction commerciale :
- véritables choix d’achat visibles par le client ;
- différences de SKU, stock, prix, code-barres, traitement des commandes ou fiscalité ;
- spécifications de Product ou informations de compatibilité ;
- images ou ordre des médias propres à une variante ;
- saisies de personnalisation ou comportement d’option personnalisée ;
- logique de bundle, kit, abonnement ou supplément ;
- identifiants opérationnels utilisés par un ERP, une marketplace, un système de traitement des commandes, une solution d’analyse ou de production de rapports ;
- champs obsolètes ou résidus d’extension qui ne doivent pas encombrer Shopify.
Toutes les options de la source ne doivent pas devenir des variantes Shopify. Certaines valeurs sont mieux gérées comme contenu de Product, metafields, metaobjects, tags, configuration d’application, affichage du thème, données d’intégration ou dans un parcours clairement défini de conception applicative ou de données. Le test pratique consiste à vérifier si la structure Shopify retenue préserve à la fois la clarté de l’achat et l’utilité opérationnelle.
La catégorie de Product et le type de Product Shopify doivent eux aussi rester distincts. La catégorie de Product rattache le Product à la taxonomie standard de Shopify et peut influencer les attributs, canaux de vente, taxes, découverte et organisation du catalogue. Le type de Product est un champ organisationnel personnalisé. Les tags et metafields peuvent compléter l’organisation, le filtrage ou l’affichage, mais ils ne doivent pas devenir un dépôt pour chaque attribut de la source.
Différences entre Categories, collections, navigation et structure de la boutique en ligne
Les Categories source cumulent souvent plusieurs fonctions : hiérarchie, navigation, pages d’atterrissage, filtrage des Products, groupes de merchandising, chemins SEO, classification interne, campagnes ou habitudes de navigation des clients. Les collections Shopify peuvent préserver une partie de ce sens, mais elles ne remplacent pas systématiquement les Categories une à une.
Une Category source peut devenir :
| Fonction de la Category source | Traitement Shopify à envisager |
|---|---|
| Groupe de Products visible par les clients | Collection, élément de menu, groupe de filtres ou page d’atterrissage |
| Page d’atterrissage SEO | Collection avec contenu, page, destination de redirection ou décision de nettoyage |
| Classification interne | Type de Product, tag, metafield ou aucune structure visible par les clients |
| Contexte de filtre ou de navigation à facettes | Configuration de recherche et découverte, tags, metafields, attributs de catégorie de Product ou filtrage pris en charge par une application |
| Groupe de campagne ou saisonnier | Collection manuelle, collection automatisée, page, placement dans un menu ou redirection archivée |
| Taxonomie historique profonde | Modèle de collections simplifié avec redirections pour les chemins prioritaires |
Le plan de collections doit être évalué selon la capacité des clients à trouver les Products, et non selon le nombre de Categories conservées. Les clients doivent continuer à retrouver les bons Products au moyen des collections, menus, recherches, filtres, recommandations et pages d’atterrissage prioritaires. Une structure Shopify comportant moins de collections peut être meilleure qu’une hiérarchie héritée lorsqu’elle apporte une navigation plus claire et un merchandising plus propre.
Le comportement du thème compte également. La disposition des collections, les cartes Product, la profondeur des menus, les filtres, badges, recommandations et affichages personnalisés peuvent dépendre du thème sélectionné et de la configuration des applications. Migrer les données de Category ou de collection ne recrée donc pas automatiquement l’expérience complète de navigation de la boutique en ligne.
Différences concernant les Customers, les comptes et les Orders
La migration des Customers et des Orders doit être évaluée selon l’utilité après migration. Une fiche Customer peut exister dans Shopify alors que l’expérience de compte, les attentes liées aux mots de passe, le contexte de fidélité, la logique de groupe de Customers, les procédures d’assistance ou un fonctionnement de type B2B diffèrent de ceux de la plateforme source.
Les données Customer doivent être séparées selon leur sens pratique :
- profil et coordonnées ;
- adresses de facturation et de livraison ;
- tags, notes et signaux de segmentation ;
- état marketing et attentes de communication ;
- association avec l’historique des Orders ;
- fidélité, récompenses, adhésions, statut de gros ou informations de niveau de compte ;
- identifiants propres au Customer utilisés par des systèmes externes ;
- attentes concernant mot de passe, connexion ou activation.
La fiche Customer et le compte client constituent deux domaines de planification différents. La migration peut préserver un contexte Customer utile, mais le retour d’un client existant peut nécessiter une communication, une activation de compte, une configuration de la boutique cible, une revue des applications ou une préparation des procédures d’assistance.
Les Orders doivent eux aussi être considérés comme un contexte opérationnel, pas seulement comme des archives. Une migration utile des Orders dépend généralement des lignes, de l’association au Customer, des totaux, taxes, frais de livraison, remises, état du paiement, état de traitement, notes, numéros de référence source et informations nécessaires au service client. Certains comportements liés aux Orders dans la source peuvent provenir de systèmes de paiement, outils de traitement des commandes, factures, abonnements, extensions de fidélité, solutions antifraude ou systèmes externes. Ces comportements doivent être distingués des enregistrements Order eux-mêmes.
L’objectif pratique est d’obtenir dans Shopify un historique des Orders utile au service client, aux références opérationnelles, aux vérifications d’analyse et à la confiance des clients lorsqu’ils peuvent consulter leur historique. Il ne faut pas supposer que le comportement exact du système source sera reproduit s’il n’a pas de destination Shopify clairement définie.
Différences concernant les contenus, les URL et le SEO
La migration du contenu vers Shopify peut concerner les CMS Pages, Blog Posts, descriptions de Product, descriptions de collection, médias, liens internes, métadonnées, handles, menus et redirections. Le sens de ces contenus dépasse largement le transfert de texte. Ils peuvent soutenir la confiance, la conformité aux politiques, les informations de livraison et de retour, les guides de taille, le SEO, les campagnes, les conseils d’achat, l’éducation des clients ou la crédibilité de la marque.
Les contenus doivent être examinés selon leur fonction :
| Zone de contenu ou d’URL | Implication dans le modèle Shopify |
|---|---|
| CMS Pages | Peuvent exiger migration de page, placement dans la navigation, vérification des liens internes, revue des médias et décisions de métadonnées. |
| Blog Posts | Peuvent exiger structure de blog, chemins d’article, médias, métadonnées, attentes concernant auteur/date et vérification des liens internes. |
| Descriptions de Product et de collection | Doivent soutenir la logique de vente de la boutique cible et le rendu du thème, et pas seulement conserver l’ancien texte. |
| URL de Categories source | Peuvent nécessiter une destination de collection, une page, une redirection ou une décision de nettoyage. |
| URL de Products | Nécessitent une revue des handles et une planification des redirections pour les chemins prioritaires. |
| URL filtrées, de recherche ou avec paramètres | Nécessitent une revue particulière car elles peuvent ne pas se comporter comme des chemins ordinaires de Product, collection, page ou Blog Post. |
| URL internationales ou localisées | Nécessitent une planification des marchés, langues, domaines, sous-répertoires et redirections lorsque la vente régionale compte. |
La structure des URL Shopify est contrôlée par son modèle de boutique en ligne. Les chemins exacts de la source peuvent donc ne pas être conservés, notamment pour les Products, collections, CMS Pages, Blog Posts, routes filtrées et chemins personnalisés. La planification des redirections fait ainsi partie de la traduction du modèle de données, et pas seulement d’une tâche SEO de fin de projet.
Les URL prioritaires portent une identité de route que le modèle cible doit préserver délibérément. Il s’agit généralement des URL bénéficiant de trafic organique, de campagnes payantes, de backlinks, de favoris clients, de Products à fort chiffre d’affaires, de Categories importantes, de pages de politique, de Blog Posts et de pages d’atterrissage régionales. Chaque chemin prioritaire doit donc disposer d’une destination Shopify explicite et d’une relation de redirection définie.
Différences concernant les applications, extensions, intégrations et données personnalisées
Les boutiques Shopify dépendent souvent d’applications, de thèmes et d’intégrations. C’est normal, mais le fonctionnement assuré par une application ne doit pas être confondu avec des données migrées ordinaires. Une extension de la plateforme source peut stocker des données qui ne gardent leur sens que si une application, un thème ou une intégration Shopify peut les utiliser.
Les zones sensibles aux applications ou aux intégrations comprennent notamment :
- avis et notes de Products ;
- abonnements, bundles, kits, suppléments facultatifs ou logique de personnalisation ;
- fidélité, récompenses, adhésions et niveaux de Customers ;
- recherche avancée, filtrage, recommandations ou règles de merchandising ;
- vente en gros, comportements de type B2B, prix propres aux Customers ou contenus à accès restreint ;
- identifiants ERP, traitement des commandes, marketplace, PIM, CRM, analyse, comptabilité ou assistance ;
- règles de livraison, logique d’expédition, hypothèses fiscales, factures et contexte lié aux paiements ;
- affichages personnalisés de la boutique en ligne pilotés par du code de thème ou des blocs d’application.
Pour chaque dépendance, le plan de migration doit identifier le résultat métier recherché, les données source concernées, la destination Shopify et le comportement attendu après le lancement. Certaines données peuvent être migrées dans des metafields ou metaobjects. D’autres peuvent nécessiter un import d’application, une configuration manuelle, une mise en correspondance explicite des relations entre champs, une configuration dans la cible, un travail d’intégration ou une restructuration des données. Certaines peuvent ne pas mériter d’être conservées.
Les metafields et metaobjects sont utiles lorsque les informations personnalisées ont un objectif dans la cible. Les metafields peuvent étendre des ressources Shopify comme Products, Customers et Orders. Les metaobjects peuvent représenter des contenus structurés comprenant plusieurs champs et entrées réutilisables. Ni l’un ni l’autre ne recrée automatiquement la logique métier de la source. Une valeur peut être présente dans Shopify tout en restant invisible, inutilisée ou sans sens opérationnel tant qu’un thème, une application, une automatisation ou une intégration ne l’exploite pas.
Influence des différences de modèle de données sur le périmètre de migration
Les décisions concernant le modèle de données Shopify doivent rendre le périmètre de migration plus précis. L’objectif n’est pas de reproduire chaque champ source. Il est d’identifier les significations qui doivent rester utiles dans Shopify et d’attribuer chacune au bon propriétaire dans la cible.
Un périmètre pratique sépare quatre résultats :
| Résultat de traduction | Signification dans Shopify |
|---|---|
| Enregistrement Shopify natif | Le sens source correspond à un Product, une variante, un Customer, un Order, un enregistrement lié aux collections, une CMS Page, un Blog Post, une redirection ou une autre destination native prise en charge. |
| Configuration Shopify ou responsabilité de la boutique en ligne | L’enregistrement peut exister, mais son utilité dépend des collections, menus, paramètres Search & Discovery, sections de thème, Markets, comptes clients ou d’une autre configuration de la boutique cible. |
| Propriété de données personnalisées structurées | Le sens source appartient à un metafield défini, un metafield de catégorie, un metaobject, un champ géré par une application ou une référence d’intégration dont le consommateur est connu. |
| Exclure, archiver ou repenser | La valeur source est obsolète, dupliquée, dépend d’une logique d’extension retirée ou n’a plus d’utilité pour la boutique en ligne ou les opérations. |
Cette séparation évite une fausse impression de complétude. Une collection peut exister sans préserver l’ancien parcours de découverte. Un metafield peut contenir la bonne valeur sans être utilisé par le thème, une application ou une intégration. Un Customer peut exister sans reproduire le modèle de connexion de la source. Un Order peut conserver des détails historiques sans recréer le fonctionnement actuel des paiements, du traitement des commandes ou des abonnements.
Le principal artefact de planification doit être une carte de traduction des données. Pour chaque signification importante de la source, elle doit indiquer la destination Shopify, la relation à conserver, le système ou l’équipe qui l’utilisera et toute configuration nécessaire dans la boutique cible pour la rendre utile. Cette carte donne une base stable aux décisions ultérieures sans confondre transfert d’enregistrements, configuration de la boutique, comportement applicatif et propriété d’un système externe.
Matrice de traduction des relations Shopify
La traduction vers Shopify devient plus claire lorsque chaque signification de la source est attribuée à un enregistrement cible, une configuration cible, une application connectée ou une exclusion délibérée. La matrice suivante maintient cette décision séparée de la simple disponibilité d’un champ.
| Sens source | Question de représentation dans Shopify | Signification requise dans la cible |
|---|---|---|
| Famille de Products achetables | Quelles données appartiennent au Product, à ses variantes, médias, éléments de stock et emplacements ? | Chaque combinaison vendable possède le bon SKU, prix, valeurs d’option, image et relation de stock. |
| Hiérarchie de navigation | Quelles Categories source deviennent des collections, menus, filtres, pages, redirections ou seulement une organisation interne ? | Les parcours de découverte prioritaires conduisent les acheteurs vers le bon ensemble de Products sans destinations dupliquées ou orphelines. |
| Enrichissement structuré | La valeur doit-elle devenir un champ natif, metafield, référence de metaobject, tag, valeur de taxonomie ou attribut d’un système externe ? | La valeur est visible ou consommable par le thème, l’application, l’automatisation ou l’intégration qui en a besoin. |
| Identité du Customer | Quelles valeurs appartiennent au profil Customer, aux adresses, tags, notes, état marketing, contexte B2B ou uniquement à l’historique des Orders ? | Les équipes peuvent identifier l’acheteur et interpréter son historique sans inventer un comportement de compte non pris en charge. |
| Transaction historique | Quels détails d’Order, paiement, traitement, remboursement, remise, taxe et référence externe restent utiles ? | Le service client et les contrôles de rapprochement peuvent comprendre la transaction sans traiter l’historique comme une configuration active. |
| Contenu et valeur des URL | Quelles pages, Blog Posts, handles, médias, métadonnées, menus et redirections ont besoin d’une destination Shopify ? | Les URL prioritaires aboutissent volontairement à une destination et les contenus importants restent accessibles. |
| État d’une application ou intégration | Quel système possède les données après le lancement et quel identifiant inter-systèmes permet de les relier ? | Le propriétaire durable peut retrouver et utiliser l’enregistrement migré sans créer plusieurs sources de vérité concurrentes. |
Un modèle de données Shopify doit être évalué à travers les relations plutôt qu’à travers les nombres d’enregistrements. Un nombre de variantes peut être identique alors que les valeurs d’option représentent les mauvaises dimensions d’achat ; un metafield peut exister sans être utilisé par le thème ou une application ; un Customer peut être présent sans que ses Orders historiques soient associés comme prévu ; une collection peut être créée alors que les menus pointent encore vers des chemins obsolètes. La carte de traduction doit donc documenter à la fois l’enregistrement cible et la relation qui lui donne son sens métier.
Des exemples représentatifs renforcent cette carte. Une famille de Products complexe peut montrer comment options, variantes, médias, stock et identifiants sont reliés. Une Category importante peut illustrer comment collections, menus, filtres et redirections se partagent les responsabilités. Un Customer disposant de plusieurs Orders peut montrer comment identité et historique transactionnel restent connectés. Un identifiant appartenant à une application peut montrer quel système continue à posséder la valeur après le lancement.
Conclusion
Les différences de modèle de données Shopify sont importantes parce que Shopify traduit le sens de la plateforme source dans son propre modèle hébergé. Products, variantes, collections, catégorie de Product, type de Product, tags, metafields, metaobjects, Customers, Orders, CMS Pages, Blog Posts, applications, thèmes, Markets, redirections et intégrations ont chacun un rôle précis dans la plateforme cible.
Une migration Shopify fiable ne cherche pas à préserver exactement chaque structure source. Elle préserve le sens métier qui doit continuer à exister après le lancement. Lorsque la logique du catalogue, le sens des collections, le contexte des Customers et Orders, les contenus, URL, champs personnalisés, comportements pris en charge par les applications et identifiants d’intégration sont traduits de manière délibérée, la boutique Shopify devient plus simple à exploiter et à gouverner.
Questions fréquentes
Les collections Shopify sont-elles équivalentes aux Categories source ?
Non. Les collections Shopify peuvent remplacer certaines fonctions des Categories source, mais celles-ci peuvent aussi représenter la navigation, des filtres, des pages d’atterrissage, une valeur SEO, un regroupement interne ou des règles de merchandising. Les parcours de navigation prioritaires doivent être traduits dans un modèle de découverte Shopify plutôt que copiés un à un.
Chaque champ personnalisé de la source doit-il devenir un metafield Shopify ?
Non. Les metafields sont utiles lorsqu’un champ possède un objectif clair dans la cible. Les champs obsolètes, doublons, résidus d’extension ou valeurs sans utilité pour la boutique en ligne, les opérations, une intégration ou l’analyse peuvent rendre la boutique cible plus difficile à maintenir.
Les applications Shopify migrent-elles automatiquement depuis la plateforme source ?
Non. Les applications, extensions, modules et comportements de thème ne sont pas des enregistrements migrés ordinaires. Le plan doit identifier quels comportements source nécessitent une configuration d’application Shopify, une configuration de la boutique cible, une mise en correspondance directe de champs, un travail d’intégration ou une restructuration des données côté cible.
Shopify peut-il préserver exactement la même expérience de compte client que la plateforme source ?
Les fiches Customer et l’expérience de compte doivent être planifiées séparément. Les Customers migrés peuvent conserver un profil utile et le contexte de leur historique d’Orders, mais la connexion, l’activation, les attentes liées au mot de passe, le contexte de fidélité et la communication client peuvent nécessiter une planification spécifique dans la boutique cible.
Comment répartir les metafields et les metaobjects Shopify ?
Utilisez un metafield lorsqu’une donnée personnalisée étend une ressource Shopify précise, par exemple un Product, une variante, un Customer ou un Order. Utilisez un metaobject lorsque l’information constitue un objet structuré réutilisable contenant plusieurs champs, par exemple un bloc de spécifications, un profil d’auteur, une fiche d’ingrédient, un guide de tailles ou une histoire de marque. Dans les deux cas, définissez qui consomme la donnée et comment elle est affichée ou utilisée dans la boutique cible.
Comment conserver les identifiants des systèmes externes dans Shopify ?
Conservez un identifiant externe uniquement lorsqu’un ERP, PIM, CRM, système de traitement des commandes, marketplace ou processus de production de rapports actif en dépend encore. Stockez-le sur la ressource Shopify ou l’enregistrement d’intégration attendu par le système qui continue à l’utiliser ; l’unicité, le format et la méthode de recherche doivent rester cohérents avec ce système. Un identifiant devenu inutile ne doit pas être transformé en métadonnée permanente de la boutique en ligne.