La modélisation des données Shopify Plus commence par le socle de données Shopify, puis ajoute le sens opérationnel d’entreprise lié à la structure d’organisation, au B2B, à Markets, aux multiples boutiques, aux intégrations, aux permissions et à la propriété des processus. Products, variantes, collections, Customers, Orders, pages, Blog Posts, redirections, metafields et applications restent centraux. La différence au niveau Plus tient au fait qu’un grand nombre de ces enregistrements portent davantage de sens métier que dans une migration Shopify mono-boutique.
Cette distinction est importante, car les plateformes sources d’entreprise stockent souvent la logique e-commerce dans des structures qui ne se traduisent pas proprement en enregistrements Shopify ordinaires. Une source Magento ou Adobe Commerce peut utiliser groupes Customer, websites, stores, store views, attributs Product, règles de prix, shared catalogs, comptes B2B et données appartenant à des extensions. Une Custom Platform peut utiliser des tables propriétaires, identifiants ERP, règles personnalisées de parcours de commande, permissions acheteur fondées sur des rôles ou catalogues régionaux. Shopify Plus peut prendre en charge de nombreux résultats d’entreprise, mais la planification doit décider si chaque structure source doit devenir des données Shopify, une configuration Shopify Plus, une configuration d’application, une mise en correspondance directe de champs, une conception de données cible, un travail d’intégration ou un processus repensé.
Shopify Plus utilise les données Shopify avec une gouvernance d’entreprise
Shopify Plus n’est pas une plateforme de données distincte de Shopify. Le modèle principal reste fondé sur les concepts Shopify : les Products contiennent des variantes, les collections regroupent les Products, Customers et Orders conservent l’historique acheteur et transactionnel, pages et Blog Posts portent le contenu, les redirections soutiennent la continuité du trafic, et metafields ou metaobjects étendent l’information structurée. La planification doit donc préserver le modèle Shopify plutôt que d’inventer un modèle d’entreprise personnalisé à l’intérieur de Shopify Plus.
La couche d’entreprise change la manière dont ce modèle est gouverné. Un Product peut devoir soutenir plusieurs Markets, plusieurs boutiques, une disponibilité B2B, la continuité des SKU ERP, des metafields personnalisés ou un merchandising géré par application. Un Customer doit parfois être distingué d’un compte Company, d’un rôle acheteur, d’une location, de conditions de paiement ou d’une structure commerciale régionale. Une boutique peut être une seule store utilisant Markets ou l’une de plusieurs expansion stores au sein d’une organisation. Ces choix ne sont pas cosmétiques : ils définissent l’utilisation des données migrées après le lancement.
| Domaine de données | Sens Shopify principal | Sens de migration Shopify Plus |
|---|---|---|
| Products et variantes | Structure de catalogue vendable. | Logique SKU d’entreprise, disponibilité B2B, merchandising propre aux Markets, références ERP et gouvernance des données Product. |
| Collections | Regroupement de Products pour navigation et merchandising. | Décisions de segmentation par région, marque, canal, B2B ou campagne. |
| Customers | Profils acheteur et historique d’Orders. | Acheteurs D2C, contacts B2B, relations Company, rôles acheteur et propriété du compte. |
| Orders | Contexte historique de transaction. | Support, rapprochement, revue des Orders B2B, conditions de paiement, éléments de traitement des commandes et valeur de référence pour les intégrations. |
| Metafields et metaobjects | Extensions structurées de données personnalisées. | Enrichissement Product, modèles de contenu, identifiants d’intégration, attributs B2B et contexte opérationnel d’entreprise. |
| Boutiques et organisation | Environnements d’administration et de boutique. | Plusieurs boutiques, gouvernance, permissions, sécurité, facturation et responsabilité opérationnelle. |
La migration ne doit pas aplatir ces différences en simple transfert d’enregistrements. Elle doit définir le sens cible de chaque structure source critique pour l’entreprise.
Products, variantes et sens du catalogue d’entreprise
Products et variantes Shopify restent le premier niveau d’examen du catalogue. Les Products source avec tailles, couleurs, unités, bundles, kits, options configurables, choix d’abonnement ou SKU pilotés par ERP doivent être interprétés par rapport à la structure Product/variante de Shopify. Shopify Plus ne supprime pas ces décisions ; il en augmente les enjeux, car les données du catalogue peuvent soutenir davantage de marques, Markets, Catalogs B2B, boutiques et systèmes externes.
Un catalogue D2C simple peut être migré vers Products et variantes avec peu d’interprétation supplémentaire. Un catalogue d’entreprise exige souvent une classification plus fine. Les attributs source peuvent être du contenu descriptif, des spécifications recherchables, des options définissant les variantes, des entrées de filtre, des identifiants ERP, des marqueurs d’éligibilité B2B, des valeurs propres à certains Markets ou une logique appartenant à des applications. Traiter tous les attributs comme de simples descriptions peut affaiblir merchandising, recherche et intégrations.
| Modèle de catalogue source | Question de planification Shopify Plus |
|---|---|
| Product configurable avec de nombreux attributs source | Quels attributs définissent les variantes Shopify, lesquels deviennent des metafields et lesquels doivent rester externes ? |
| Visibilité Product contrôlée par groupe Customer source | La visibilité doit-elle être gérée par B2B catalogs, séparation de boutique, règle applicative ou autre conception de données ? |
| Noms ou descriptions Product régionaux | La cible doit-elle utiliser Markets/localisation, boutiques distinctes, processus de traduction ou reconstruction de contenu ? |
| SKU ou identifiant Product ERP | L’identifiant doit-il être conservé comme SKU, metafield, donnée d’application ou référence d’intégration ? |
| Bundle, kit, abonnement ou ensemble configurable | Doit-il utiliser une configuration Shopify ou applicative, une refonte côté cible ou une configuration manuelle ? |
| Enrichissement Product d’entreprise | Les données structurées doivent-elles devenir des metafields, metaobjects, données d’application ou éléments de configuration thème/contenu ? |
La migration Product est la plus solide lorsque chaque champ source possède un objectif cible clair. Le but n’est pas de forcer chaque champ d’entreprise dans le modèle Product natif de Shopify, mais de préserver l’information qui doit rester utilisable dans le modèle opérationnel Shopify Plus.
Collections, navigation et segmentation des boutiques
Les collections ne sont pas équivalentes aux Categories de toutes les plateformes sources. Certaines plateformes utilisent les Categories comme hiérarchie de base de données, navigation, pages de merchandising, pages d’atterrissage SEO, groupes de production de rapports ou structures de contrôle d’accès. Les collections Shopify peuvent soutenir le regroupement Product et le merchandising, mais le plan doit décider si chaque regroupement source devient une collection Shopify, un élément de navigation, une page, une cible de redirection, une expérience propre à un Market, une règle de B2B catalog ou une structure historique exclue.
Shopify Plus ajoute des questions de segmentation. Un marchand peut exploiter des boutiques séparées par marque ou région. Un autre peut utiliser une seule boutique avec Markets et du contenu localisé. Un marchand B2B peut avoir besoin d’une disponibilité Product par Company ou Catalog plutôt que par simple collection publique. Ces choix cible influencent la manière de représenter le sens des Categories et collections.
| Sens du regroupement source | Interprétation Shopify Plus plus adaptée |
|---|---|
| Parcours public de navigation Customer | Collection Shopify, navigation et revue de la boutique. |
| Page d’atterrissage SEO | Décision concernant collection, page, redirection, métadonnées ou reconstruction de contenu. |
| Regroupement de boutique régional | Planification Markets/localisation ou expansion store. |
| Regroupement réservé au B2B | B2B catalog, règle applicative ou conception de boutique distincte. |
| Groupe de production de rapports interne | Metafield, tag, donnée d’application ou exclusion de la boutique publique. |
| Ancienne Category non utilisée | Exclusion volontaire, traitement d’archive ou destination de redirection. |
La différence clé est le sens. Une même Category source peut avoir plusieurs fonctions. La planification Shopify Plus doit préserver celles qui restent importantes après le lancement, pas seulement les noms de Category.
Les B2B Companies ne sont pas des Customers ordinaires
Le B2B constitue l’une des différences de modèle de données les plus importantes de Shopify Plus. Dans une migration Shopify ordinaire, les Customers représentent généralement des profils acheteur avec coordonnées et historique d’Orders. Dans Shopify Plus B2B, un acheteur professionnel peut devoir exister à l’intérieur d’une structure Company. La Company est l’organisation parente ; les Company Locations portent le contexte d’achat propre à un site, comme adresses, informations fiscales, Catalogs, conditions de paiement et contacts assignés. Un profil Customer peut être relié à une ou plusieurs Company Locations : l’identité de l’acheteur et le contexte du compte d’entreprise ne doivent donc pas être aplatis en un seul tag Customer.
Une plateforme source peut représenter le B2B de nombreuses manières : groupes Customer, comptes Company, processus de devis, hiérarchies de comptes, Catalogs contractuels, shared catalogs, acheteurs exonérés de taxes, relations avec commerciaux, identifiants de compte ERP, permissions d’approbation ou champs personnalisés. Ces éléments ne doivent pas être migrés aveuglément comme tags ou notes Customer ordinaires, sauf si ce résultat correspond réellement au sens cible voulu.
| Structure B2B source | Question cible Shopify Plus |
|---|---|
| Groupe Customer | S’agit-il d’un segment, d’un attribut Company, d’un contexte de prix, d’une règle Catalog ou d’un libellé historique ? |
| Compte Company | Doit-il devenir une Shopify B2B Company avec Company Locations ou utiliser une autre structure de compte définie ? |
| Rôle ou permission acheteur | Quel contact Customer appartient à quelle Company Location et quel rôle d’achat doit être conservé ? |
| Tarification contractuelle | Les prix sont-ils gérés par B2B catalogs, une application de prix ou un système de tarification externe ? |
| Identifiant de compte ERP | Doit-il utiliser le Company ID, Company Location ID, un metafield ou une référence appartenant à l’intégration ? |
| Processus de devis ou d’approbation | Relève-t-il d’une configuration Shopify, d’un processus applicatif ou d’un fonctionnement source non pris en charge ? |
Cette séparation évite une erreur majeure : compter les enregistrements Customer comme migrés tout en perdant l’architecture commerciale qui les rendait utilisables pour le B2B.
Markets, localisation et structures multi-boutiques
Les marchands Shopify Plus proviennent souvent de plateformes utilisant websites, store views, locales, régions, marques, domaines ou catalogues propres à certains Markets. Ces structures doivent être interprétées avec soin, car Shopify Plus peut soutenir la vente internationale via Markets et peut aussi utiliser plusieurs boutiques ou expansion stores. Le bon modèle cible dépend de la gouvernance, de la propriété des contenus, des équipes opérationnelles, de la disponibilité Product, des devises, de la fiscalité, de l’expédition et de la stratégie régionale de marque.
Une store view source n’est pas nécessairement équivalente à un Shopify Market. Un domaine régional ne nécessite pas forcément une boutique Shopify Plus distincte. Une version linguistique peut relever de la traduction/localisation plutôt que d’un arbre de contenu migré séparé. Un website source peut représenter une marque, une géographie, un canal ou simplement un ancien choix d’implémentation qui ne doit pas être copié mécaniquement.
| Structure source | Interprétation Shopify Plus possible |
|---|---|
| Store view ou vue linguistique | Configuration de localisation et de traduction, ou boutique distincte si la gouvernance l’exige. |
| Domaine propre à un pays | Market, stratégie de domaine, plan de redirection ou décision d’expansion store. |
| Catalogue régional | Règles de disponibilité Product, configuration Markets, B2B catalog, logique applicative ou boutique distincte. |
| Site source multi-marques | Expansion store, boutique séparée, collections ou architecture de contenu propre à la marque. |
| CMS Pages localisées | Pages, Blog Posts, traductions, metaobjects, redirections ou reconstruction manuelle du contenu. |
| Tarification régionale | Prix Markets, prix B2B catalog, configuration applicative ou logique d’un système externe. |
La question de modèle de données ne porte donc pas uniquement sur la destination des enregistrements. Elle porte sur la structure opérationnelle cible que ces enregistrements doivent soutenir.
Metafields, metaobjects et gouvernance des données personnalisées
Metafields et metaobjects sont des outils importants pour les migrations Shopify Plus, mais ils ne doivent pas devenir un dépôt pour chaque champ source. Les metafields étendent des ressources Shopify existantes telles que Products, Customers, variantes, Orders ou autres objets. Les metaobjects créent des objets structurés comportant plusieurs champs, qui peuvent être référencés par des metafields, utilisés dans les thèmes ou gérés comme entrées de contenu/données.
Pour Shopify Plus, la planification des données personnalisées doit être plus disciplinée, car les plateformes sources d’entreprise comportent souvent de grands volumes d’attributs, spécifications, champs personnalisés, identifiants ERP, indicateurs Market, libellés B2B, contenus merchandising et enregistrements appartenant à des applications. Certains champs sont utiles au contenu visible par le Customer. D’autres sont nécessaires aux intégrations. Certains sont historiques ou obsolètes. Certains nécessitent des définitions, règles de données ou une configuration de thème. Certains ne doivent pas être migrés du tout.
| Type de données personnalisées | Chemin de traitement possible |
|---|---|
| Spécifications Product | Metafields Product, metafields de catégorie, metaobjects ou données d’application. |
| Blocs de contenu riches et réutilisables | Metaobjects, pages, Blog Posts, sections de thème ou reconstruction manuelle du contenu. |
| Identifiants ERP/CRM/PIM | Metafields, champs appartenant aux applications, identifiant externe natif ou référence d’intégration. |
| Contexte de compte B2B | Configuration Company et Company Location, metafields Customer ou données appartenant à une application. |
| Données d’extension source | Migration via application, mise en correspondance d’intégration, archivage ou refonte lorsqu’aucune destination native n’existe. |
| Champs historiques de production de rapports | Exclusion, archivage, metafield ou décision de production de rapports externe. |
Le meilleur modèle Shopify Plus n’est pas celui qui migre le plus grand nombre de champs personnalisés. C’est celui où chaque champ possède un propriétaire cible, un fonctionnement d’affichage, une règle de qualité des données et un objectif métier clairement définis.
Contexte des Orders, paiements, traitement des commandes et processus
La migration des Orders vers Shopify Plus doit préserver le sens historique, sans laisser croire que chaque processus source est recréé. Les Orders source peuvent contenir libellés de paiement, méthodes d’expédition, remises, contexte fiscal, statuts de traitement, expéditions partielles, remboursements, devis, factures, références de bons de commande, identifiants ERP ou données de commerciaux. Une partie de ce contexte peut rester lisible comme historique d’Order. Une autre relève de la configuration Shopify, d’applications, d’intégrations externes ou d’un processus cible repensé.
Cette distinction est plus importante pour les marchands Plus, car les Orders historiques peuvent soutenir le service client, la revue de comptes B2B, le réapprovisionnement wholesale, le rapprochement financier, la correspondance ERP et l’analyse du traitement des commandes. Ils ne configurent toutefois ni le parcours de commande Shopify actif, ni les fournisseurs de paiement, la logique fiscale, le routage du traitement des commandes, les processus de bons de commande ou les conditions de paiement B2B.
| Contexte d’Order source | Interprétation pour la migration Shopify Plus |
|---|---|
| Référence de paiement | Contexte historique, pas configuration de paiement active. |
| Mode de traitement des commandes | Lisibilité historique plus revue de la configuration cible du traitement. |
| Remboursement ou annulation | Contexte historique pour support et rapprochement. |
| Numéro de bon de commande | Contexte d’Order B2B, metafield ou donnée d’application, ou référence de système externe. |
| Identifiant Order ERP | Identifiant externe natif, metafield, champ applicatif ou référence d’intégration. |
| Historique de devis ou d’approbation | Note historique, processus applicatif, configuration B2B ou fonctionnement personnalisé non pris en charge. |
Une migration Shopify Plus fiable doit rendre l’historique des Orders utile sans confondre cet historique avec la configuration opérationnelle active.
Applications, intégrations et données des systèmes externes
Les marchands Shopify Plus dépendent souvent d’ERP, PIM, OMS, CRM, abonnements, fidélité, avis, fiscalité, expédition, fraude, analyse des données, marketplaces, personnalisation et systèmes d’automatisation. Certaines valeurs source sont des données e-commerce natives ; d’autres appartiennent à ces systèmes et n’apparaissent dans la plateforme source que parce qu’une extension ou intégration les y a copiées.
La décision de traduction du modèle doit identifier le système de référence qui perdure. Un PIM peut rester autoritaire pour l’enrichissement. Un ERP peut continuer de posséder identifiants de compte, SKU, stock ou Order. Une plateforme d’abonnement peut posséder les contrats et calendriers de facturation. Une application de fidélité peut posséder les soldes et historiques de niveau. Stocker des copies dans Shopify Plus ne transfère pas la propriété ni ne recrée le processus.
| Dépendance | Question de modèle de données |
|---|---|
| ERP | Quels identifiants Product, Customer, Company, Company Location, Order et stock doivent rester stables ? |
| PIM | Quels attributs deviennent des champs Shopify, metafields ou metaobjects et lesquels restent sous responsabilité du PIM ? |
| OMS ou système de traitement des commandes | Quelles valeurs d’Order et de traitement des commandes constituent un contexte historique et lesquelles restent opérationnelles dans le système connecté ? |
| CRM | Quels champs Customer appartiennent à Shopify Plus et lesquels restent des données de relation dans le CRM ? |
| Application d’abonnement | Quels enregistrements et identifiants doivent être transférés via l’application plutôt que représentés comme Orders ordinaires ? |
| Application de fidélité ou d’avis | Quels soldes, adhésions, avis et clés inter-systèmes possèdent une destination prise en charge ? |
Une valeur critique ne doit pas être transférée uniquement parce qu’un champ existe. Elle doit avoir un responsable identifié, un identifiant stable, une représentation Shopify Plus définie lorsque nécessaire et un consommateur qui perdure. Lorsque ces conditions ne sont pas réunies, il peut être préférable d’archiver la valeur, repenser le processus ou la conserver dans le système externe plutôt que de créer une nouvelle copie non gouvernée.
Conclusion
Les différences du modèle de données Shopify Plus ne concernent pas seulement les champs Shopify. Elles concernent le sens d’entreprise attaché aux données Shopify. Products, variantes, collections, Customers, Orders, pages, Blog Posts, redirections, metafields, metaobjects, applications et structures d’organisation doivent être interprétés à travers le B2B, Markets, la gouvernance multi-boutiques, les intégrations externes et les responsabilités opérationnelles.
Un modèle Shopify Plus cohérent distingue les données Shopify ordinaires des structures opérationnelles propres à Plus. Il identifie ce qui doit migrer, ce qui doit être configuré dans Shopify Plus, ce qui appartient aux applications ou intégrations, ce qui nécessite une mise en correspondance directe ou une restructuration des données et ce qui relève de l’implémentation des applications ou intégrations. Cette distinction empêche la boutique cible de devenir une copie superficielle de la plateforme source au lieu d’un environnement Shopify d’entreprise réellement utilisable.
Questions fréquentes
Les différences de modèle de données Shopify Plus sont-elles distinctes de celles de Shopify ?
Elles sont liées, mais pas séparées. Shopify Plus utilise le socle de données Shopify, mais les migrations Plus attachent généralement davantage de sens d’entreprise aux mêmes enregistrements via B2B, Markets, plusieurs boutiques, données personnalisées, intégrations, permissions et gouvernance des processus.
Les groupes Customer B2B source doivent-ils devenir des tags Customer Shopify ?
Pas automatiquement. Un groupe Customer source peut représenter une tarification, une structure Company, un accès acheteur, un statut fiscal, une segmentation ou un libellé historique. Le sens cible doit être examiné avant de décider s’il relève des B2B Companies, Catalogs, segments Customer, metafields, applications ou d’une décision cible volontaire.
Les metafields peuvent-ils résoudre tous les besoins de données personnalisées Shopify Plus ?
Non. Les metafields étendent une ressource Shopify existante ; les metaobjects modélisent des enregistrements structurés réutilisables. Aucun des deux ne recrée un processus applicatif, une relation ERP, un modèle de permission B2B ou un système externe autoritaire. Utilisez-les uniquement lorsque le propriétaire cible et le consommateur des données sont définis.
Comment interpréter des données source multi-boutiques pour Shopify Plus ?
Elles doivent être mises en correspondance avec la structure opérationnelle cible prévue. Elles peuvent devenir une boutique Shopify Plus avec Markets, plusieurs boutiques, des expansion stores, du contenu localisé, des B2B catalogs ou une combinaison de configuration cible et de périmètre de migration.
Quelles relations Shopify Plus exigent l’interprétation la plus rigoureuse ?
Les B2B Companies et Company Locations, la propriété par Market ou boutique, le contexte de Catalog et de prix, ainsi que les identifiants de systèmes externes exigent la correspondance relationnelle la plus claire. Un enregistrement peut exister dans Shopify Plus tout en étant rattaché au mauvais acheteur, emplacement, boutique en ligne, Catalog ou système de référence.
Comment préserver les relations B2B Company et Company Location dans Shopify Plus ?
Traitez une Company, ses locations, acheteurs assignés, Catalogs, conditions de paiement, contexte fiscal et identifiants de compte externes comme des enregistrements liés plutôt que comme des tags Customer. La correspondance doit maintenir chaque acheteur sur le bon site d’achat et préserver les identifiants nécessaires aux systèmes back-office qui continuent de fonctionner.