La planification du modèle de données VTEX doit commencer par une question de traduction : quels enregistrements de la boutique source deviendront des structures e-commerce VTEX réellement utilisables, et lesquels relèvent d’un autre domaine VTEX, de l’implémentation storefront, d’une intégration ou d’un système externe ? VTEX est un environnement e-commerce modulaire ; la signification des données est donc répartie entre Catalog, SKUs, spécifications, tarification, promotions, checkout, Orders, logistique, sellers, contexte marketplace, Master Data, recherche, implémentation storefront et systèmes externes.
Cette architecture diffère de celle des plateformes où Products, Customers, Orders, pages et URLs peuvent être examinés presque comme des enregistrements isolés. Une option Product de la source peut devenir un SKU, une spécification, un choix du storefront, un champ personnalisé ou une exigence de reconstruction. Un champ Customer source peut relever d’un profil classique, de Master Data, du B2B, d’une identité gouvernée par un CRM ou de métadonnées d’intégration. Un Order source peut conserver une valeur historique utile au support sans pour autant configurer le checkout, les paiements, le traitement logistique, la marketplace ou la logistique de VTEX.
Le meilleur périmètre de migration vers VTEX n’est donc pas celui qui transfère le plus de données. C’est celui qui préserve la signification utile des données tout en séparant les enregistrements migrés de la configuration VTEX, de l’implémentation frontend, de la responsabilité des intégrations, des mappings structurés ou traitements cibles dédiés, et des besoins de restructuration conçus pour la cible.
La signification des données VTEX est répartie entre plusieurs services e-commerce
Chaque donnée doit être interprétée à travers le domaine VTEX qui en sera responsable après migration. Les données du Catalog peuvent influencer l’affichage Product, la recherche, les prix, les promotions, la disponibilité des SKUs, la logistique et le fonctionnement marketplace. L’historique des Orders peut être utile au service client et au reporting, mais le traitement actif dépend du checkout, des paiements, du traitement logistique, de la logistique et de la configuration opérationnelle. Les données Customer peuvent sembler simples jusqu’à ce que Master Data, segmentation, contexte B2B, identifiants CRM ou formulaires personnalisés imposent des décisions séparées.
Ce modèle distribué change la manière de revoir la migration. Un champ qui ressemblait à un attribut Product ordinaire dans la boutique source peut devenir une spécification VTEX. Une variante source peut nécessiter une structure au niveau SKU. Un prix de canal peut relever de règles tarifaires ou de tables de prix plutôt que du Product lui-même. Une référence seller marketplace peut ne pas constituer une donnée catalogue ordinaire. Une page de contenu peut demander une implémentation storefront ou un plan de redirection plutôt qu’une migration un-à-un.
| Enregistrement ou fonctionnement source | Question d’interprétation dans VTEX | Implication pour la migration |
|---|---|---|
| Option Product ou variante | Définit-elle un SKU vendable, une spécification Product ou un comportement de sélection dans le storefront ? | La relation Product-SKU-spécification doit être explicite dans le périmètre. |
| Attribut ou champ personnalisé | Sert-il au filtrage, au détail Product, aux opérations, à une intégration ou à un processus Customer ? | Le mapping dépend de l’usage métier, pas seulement de la similarité des noms de champs. |
| Prix de canal ou promotion | S’agit-il d’un prix de base, d’une table de prix, d’une condition de canal, d’un coupon ou d’une règle promotionnelle active ? | Le fonctionnement commercial actif doit être séparé des données tarifaires historiques. |
| Champ Customer supplémentaire | S’agit-il d’une donnée de profil, de Master Data, d’un contexte B2B, de métadonnées CRM ou d’informations détenues par une intégration ? | Certaines valeurs peuvent nécessiter un mapping/filtrage borné, une restructuration dédiée ou un traitement dans un système externe. |
| Statut Order ou note de traitement logistique | S’agit-il d’un contexte historique de support ou d’un fonctionnement OMS/logistique actif ? | La migration des Orders ne doit pas être confondue avec la configuration du processus cible. |
VTEX impose donc un mapping fondé d’abord sur le sens. Chaque domaine de données doit avoir un propriétaire futur et une finalité déclarés ; cette responsabilité détermine si un champ appartient aux enregistrements migrés, à la configuration VTEX, à l’implémentation storefront, aux données d’intégration, à un modèle cible restructuré ou à une exclusion volontaire.
La traduction du catalogue commence par les relations Category, Brand, Product, SKU et spécification
Le VTEX Catalog n’est pas une table Product plate. Sa structure centrale relie Categories, Brands, Products, SKUs et spécifications. Le Product représente la définition commerciale générale, tandis que chaque SKU correspond à la variation ou unité physique achetable et stockée. Des groupes de spécifications liés aux Categories définissent les propriétés applicables aux Products et aux SKUs, avec possibilité d’héritage dans la hiérarchie des Categories.
| Structure source | Interprétation VTEX | Conséquence relationnelle |
|---|---|---|
| Product parent avec variantes enfants | Product avec un ou plusieurs SKUs | Lorsque c’est pertinent, identité vendable, images, stock et lignes d’Order appartiennent au niveau SKU. |
| Attribut Product | Spécification Product | Préserver le sens du champ et de la valeur liés à la Category plutôt que copier du texte libre. |
| Attribut de variante tel que taille ou tension | Spécification SKU | Le conserver sur le SKU qui représente la variation physique. |
| Marque ou fabricant | Relation Brand | Ne pas aplatir la valeur si navigation ou découverte dépendent de l’entité Brand. |
| Arborescence de Categories | Classification Catalog | Le placement en Category détermine l’héritage des spécifications et l’organisation Product. |
| Ensemble d’images Product | Relation média SKU | VTEX associe la disponibilité vendable et les images aux SKUs actifs. |
| Bundle, kit ou assemblage configurable | Kit, attachment, assembly option, service ou logique externe | Déterminer la structure VTEX qui possède réellement la relation de composant et de tarification. |
Une migration peut préserver chaque nom Product source tout en produisant un catalogue VTEX faible si SKUs, spécifications, images, Categories et Brands ne décrivent plus le même article vendable.
Spécifications, attachments et assembly options conservent des significations distinctes
Les spécifications VTEX sont des propriétés structurées associées aux Categories et appliquées aux Products ou SKUs. Elles peuvent alimenter navigation, comparaison, sélection, intégration ou affichage. Leur finalité est donc aussi importante que leur valeur. Un champ « couleur » utilisé pour filtrer n’est pas nécessairement équivalent à une simple note texte libre ; une taille qui distingue les SKUs n’est pas la même chose qu’une dimension descriptive au niveau Product.
VTEX sépare aussi les spécifications des structures de personnalisation facultatives. Les attachments recueillent des informations liées à un SKU. Les assembly options peuvent représenter des combinaisons plus complexes, quantités, articles additionnels, coûts et relations de stock. Les kits regroupent des SKUs vendus ensemble, tandis que certains extras payants peuvent relever de services associés au SKU. Ces concepts ne doivent pas être aplatis dans une seule colonne « option ».
| Signification source | Concept cible VTEX | Distinction essentielle |
|---|---|---|
| Caractéristique descriptive | Spécification Product | Décrit le Product générique. |
| Caractéristique définissant une variation | Spécification SKU | Distingue l’unité vendable. |
| Information fournie par l’acheteur | Attachment | Ajoute une information au SKU sans nécessairement créer un autre SKU. |
| Composant ou combinaison configurable | Assembly option | Représente articles supplémentaires, quantités, coûts ou relations de stock. |
| Groupe d’unités vendables | Kit | Préserve une composition de SKUs vendus ensemble. |
| Extra payant associé à un article | Relation de service SKU | Maintient l’extra séparé de l’identité du SKU de base. |
Le modèle cible doit préserver la structure qui pilote l’identité Product, le choix de l’acheteur, le stock et l’interprétation des lignes d’Order, pas simplement les libellés et valeurs.
Tarification, promotions, trade policies et offres constituent des couches commerciales distinctes
Un export source peut placer prix, prix promotionnel, canal, marketplace et disponibilité à côté du Product. VTEX répartit ces significations entre Catalog, Pricing, Promotions, trade policies, logistique, stock et offres seller. Un même SKU peut donc participer à plusieurs contextes commerciaux sans devenir plusieurs Products.
| Enregistrement commercial | Signification VTEX | Conséquence de responsabilité |
|---|---|---|
| Prix de base ou catalogue | Relation de prix pour un SKU | Le prix n’est pas un attribut permanent du Product. |
| Résultat de promotion ou coupon | Ajustement commercial piloté par une règle | Les remises historiques sur les Orders sont distinctes des règles promotionnelles actives. |
| Trade policy | Contexte de canal de vente | Détermine où Products ou SKUs sont disponibles et peut relier des conditions commerciales. |
| Stock et logistique | Disponibilité et promesse de traitement | Le sens du stock et de la livraison est détenu hors de l’enregistrement descriptif du Catalog. |
| Offre seller | Offre commerciale d’un seller pour un article catalogue | Identité marketplace et propriété seller restent distinctes de la définition Product. |
| Assortiment propre à un canal | Disponibilité Product selon trade policy ou seller | Préserver la relation plutôt que dupliquer le Product. |
Ce modèle en couches est particulièrement important lorsque la boutique source utilise des catalogues régionaux, des listes de prix B2B, des offres marketplace ou une tarification pilotée par ERP. La migration doit conserver les identifiants reliant le SKU à ses prix, canaux, sellers, stocks et enregistrements logistiques.
Customers, enregistrements B2B et Master Data exigent une identité explicite
Dans VTEX, les données liées aux Customers peuvent couvrir profils acheteurs, adresses, structures d’organisation B2B, identifiants CRM, consentements, formulaires personnalisés et documents Master Data. Master Data est une base native de type clé-document destinée à stocker, rechercher, étendre et personnaliser des données ; un enregistrement personnalisé peut donc représenter un véritable objet opérationnel plutôt qu’un simple champ Customer supplémentaire.
| Enregistrement source | Propriétaire VTEX possible | Question d’identité |
|---|---|---|
| Profil acheteur | Customer ou donnée de profil | Quel e-mail, document ou identifiant externe représente la personne ? |
| Adresse | Enregistrement d’adresse lié au Customer | S’agit-il d’une donnée de compte réutilisable, d’un instantané Order ou des deux ? |
| Entreprise, organisation, rôle acheteur ou centre de coûts | Domaine B2B ou modèle de données personnalisé | Quelles relations contrôlent accès, approbation, catalogue ou contexte tarifaire ? |
| Valeur de fidélité, CRM ou qualification | Master Data ou CRM externe | Quel système la met à jour et quelle clé la relie au Customer ? |
| Soumission de formulaire personnalisé | Document Master Data | S’agit-il d’un attribut Customer, d’un enregistrement de workflow ou d’une entité indépendante ? |
| Consentement marketing | Relation Customer ou système marketing | Préserver finalité, horodatage, source et portée juridique lorsque nécessaire. |
La décision essentielle consiste à conserver une identité stable et à éviter d’aplatir des objets B2B ou opérationnels en champs Customer arbitraires.
Les Orders conservent l’historique e-commerce à travers plusieurs domaines opérationnels
Un Order VTEX peut relier SKUs, sellers, prix, remises, paiements, informations de livraison, adresses, statuts, données Customer et références externes. Cet historique est utile pour le service client, le reporting et la traçabilité. Il ne configure toutefois pas le fonctionnement actif du checkout, des paiements, du traitement logistique ou de la logistique.
| Valeur liée à l’Order | Signification historique | Domaine actif séparé |
|---|---|---|
| Ligne SKU et seller | Ce qui a été acheté et auprès de qui | Le Catalog et les offres seller actuels peuvent évoluer ensuite. |
| Prix et remise | Instantané commercial | Les règles Pricing et Promotions actives sont séparées. |
| Référence de transaction de paiement | Trace du traitement du paiement | Configuration actuelle de passerelle et antifraude séparée. |
| Mode d’expédition, SLA et adresse | Promesse de livraison historique | Logistique, docks, entrepôts, transporteurs et points de retrait sont séparés. |
| Statut et données de traitement | État OMS passé | Les nouveaux Orders peuvent suivre un flux opérationnel différent. |
| ID Order externe | Lignée inter-systèmes | À conserver si ERP, marketplace, service client ou reporting l’utilisent encore. |
La frontière pertinente est donc le modèle relationnel : quelles valeurs historiques doivent rester attachées à l’Order et quels domaines actifs possèdent le fonctionnement futur.
Catalogues marketplace, sellers et offres exigent des responsabilités séparées
VTEX peut agir comme marketplace, comme seller ou comme composant d’un réseau de marketplaces connectées. Les données marketplace dépassent donc Products et Orders : elles peuvent inclure identités seller, SKUs seller, correspondances catalogue, offres, prix, stock, commissions, responsabilité du traitement, mappings Product/Category et références de listings externes.
| Couche marketplace | Signification | Relation à préserver |
|---|---|---|
| Product et SKU canoniques | Identité de catalogue partagée | Les offres seller doivent référencer l’article catalogue prévu. |
| Seller | Propriétaire commercial et opérationnel | Garder l’identité seller distincte de Brand, fournisseur ou fabricant. |
| Offre | Contexte de prix, stock et traitement propre au seller | Ne pas fusionner toutes les offres dans la définition Product. |
| Mapping catalogue | Relation entre structures Product/Category externes et VTEX | Préserver la clé de mapping lorsque le connecteur continue à fonctionner. |
| Origine marketplace d’un Order | Historique canal et seller | À conserver lorsque support, règlement ou reporting en dépendent. |
| Référence de commission ou règlement | Contexte financier marketplace | La conserver dans le système responsable du règlement plutôt que la forcer dans des champs Order ordinaires. |
Une migration vers VTEX doit définir si chaque enregistrement marketplace source devient une relation catalogue VTEX, une offre seller, un enregistrement de connecteur externe, un attribut historique d’Order ou un objet conservé dans un système externe.
Storefront, CMS Pages, Blog Posts, recherche et URLs doivent rester séparés du transfert des données cœur
L’implémentation storefront VTEX peut comprendre frontend headless, composants CMS, recherche, merchandising, redirections et continuité SEO. Un Product peut être migré dans VTEX alors que l’expérience storefront reste incomplète. Une CMS Page peut conserver une forte valeur de contenu sans avoir d’équivalent un-à-un dans l’implémentation storefront cible. Les Blog Posts peuvent être importants pour le trafic organique, mais leur traitement dépend du périmètre et de la configuration plateforme.
Pour planifier le modèle de données, contenus et URLs doivent être évalués selon leur rôle métier et non leur seul type d’enregistrement. Une URL Category source peut être un chemin catalogue, une landing page de recherche, une page de merchandising ou un actif SEO. Une page de contenu peut être une page de politique, un guide d’achat, une landing page de campagne ou un layout personnalisé. Une règle de recherche peut appartenir à la plateforme, à une application ou à une implémentation dédiée.
| Actif source | Question de planification VTEX |
|---|---|
| URL Product | Faut-il la rediriger, conserver une équivalence ou la reconstruire via le routage storefront ? |
| Page Category ou collection | Relève-t-elle de l’organisation catalogue, de la navigation, de l’expérience de recherche, du contenu SEO ou du merchandising ? |
| CMS Page | Doit-elle migrer comme contenu, être recréée dans le storefront, être redirigée ou retirée ? |
| Blog Post | Relève-t-il du périmètre de migration, du SEO, de la stratégie de contenu ou d’une décision CMS séparée ? |
| Logique de recherche/filtrage | Est-elle pilotée par les spécifications, la configuration de recherche, une application ou une implémentation personnalisée ? |
Cette séparation évite de déclarer les données Catalog complètes alors que découverte client, contenu et relations URL restent non résolus.
Les systèmes externes et données personnalisées déterminent le véritable périmètre de migration
Les migrations VTEX impliquent souvent ERP, CRM, PIM, OMS, WMS, middleware marketplace, fournisseurs de paiement, systèmes de fidélité, fiscalité, analytique, outils de service client et applications storefront personnalisées. Ces systèmes peuvent posséder identifiants Product, prix, stocks, attributs Customer, références Order, données seller, informations de traitement ou enregistrements personnalisés.
Le périmètre de migration doit identifier la responsabilité des systèmes. Si un ERP va écraser une valeur source, celle-ci n’est pertinente que comme état initial, référence historique ou clé de rapprochement. Si un identifiant externe doit continuer à relier Orders, Customers ou Products entre systèmes, sa conservation peut être critique. Si un enregistrement personnalisé soutient un workflow que VTEX ne représente pas nativement comme donnée e-commerce standard, un mapping ou une restructuration dédiée peut être nécessaire.
| Type de données externe ou personnalisée | Décision de périmètre |
|---|---|
| ID Product ou Order ERP | À conserver si nécessaire au rapprochement ou à la synchronisation. |
| Ensemble d’attributs PIM | Mapper uniquement les valeurs nécessaires au Catalog VTEX, aux spécifications ou à la recherche. |
| Identifiant Customer CRM | À conserver si les workflows de service client ou marketing en dépendent. |
| Référence WMS ou de traitement | Déterminer si elle relève de l’historique, de la configuration d’intégration ou d’un traitement personnalisé. |
| Données d’application ou middleware | Vérifier le comportement pris en charge avant de supposer leur transférabilité. |
Un mapping ou filtrage borné peut aider lorsqu’il s’agit de filtrage, de mapping ou de configuration pris en charge. Une restructuration conçue spécifiquement pour la cible doit être envisagée lorsque le besoin concerne des données non prises en charge, des enregistrements personnalisés, une transformation sur mesure, une gestion de plateforme source personnalisée ou un ajustement de logique de migration dépassant le comportement standard pris en charge.
Les frontières de responsabilité définissent le périmètre de migration VTEX
Le périmètre VTEX est déterminé par les responsabilités et les relations, pas par le volume d’enregistrements. Un petit catalogue peut être structurellement complexe s’il dépend d’héritage de spécifications, d’assembly options, de plusieurs trade policies, de sellers, de documents Master Data ou d’identifiants externes. Un catalogue volumineux peut être relativement simple si Products, SKUs, Categories, Brands et spécifications suivent un modèle cohérent.
| Modèle source | Question centrale | Conséquence sur le périmètre |
|---|---|---|
| Product avec plusieurs variations achetables | Quel objet source devient le SKU VTEX ? | Préserver Product parent, identité SKU, spécifications, images et références de stock. |
| Assortiment régional ou B2B | Quelles relations de trade policy, prix et accès s’appliquent ? | Garder le contexte commercial séparé de l’identité Product. |
| Tables Customer ou workflow personnalisées | L’enregistrement est-il un profil, document Master Data, entité B2B ou objet d’un système externe ? | Modéliser l’entité et sa relation durable plutôt qu’ajouter des champs Customer arbitraires. |
| Catalogue marketplace | VTEX est-il marketplace, seller ou les deux ? | Séparer les enregistrements catalogue canoniques des offres seller et des clés de mapping. |
| Contenu storefront headless ou personnalisé | Quel CMS, application ou dépôt possède le contenu ? | Ne pas traiter l’implémentation storefront comme une donnée Catalog ordinaire. |
| Intégration ERP/PIM/WMS/OMS | Quel système fait autorité pour chaque valeur ? | Conserver identifiants inter-systèmes et règles de responsabilité sans dupliquer les modèles externes. |
Cette frontière maintient la cohérence du modèle VTEX à travers les domaines Catalog, commerciaux, Customer, marketplace, contenu et opérations.
Conclusion
VTEX distribue la signification e-commerce entre plusieurs domaines liés. Categories, Brands, Products, SKUs et spécifications forment le Catalog ; Pricing, Promotions, trade policies, stock, logistique et offres seller ajoutent le contexte commercial ; les enregistrements Customer et B2B peuvent s’étendre dans Master Data ; les Orders conservent des relations historiques avec Checkout, Payments, OMS et traitement logistique ; le contenu storefront et les systèmes externes conservent leur propre responsabilité.
Le modèle de migration doit donc préserver les clés et relations plutôt qu’aplatir chaque valeur dans Products, Customers ou Orders. Une responsabilité claire entre les domaines VTEX permet à un Product de rester découvrable, à un SKU de rester vendable, à un Order de rester compréhensible, à une offre seller de rester attribuable et à une intégration externe de continuer à référencer le bon enregistrement.
Questions fréquentes
Pourquoi les SKUs sont-ils si importants lors d’une migration VTEX ?
Les SKUs pilotent souvent les versions vendables, les prix, le stock, la disponibilité, la logistique et les choix du storefront. Si les options Product de la source ne sont pas traduites en structures SKU et spécifications VTEX utilisables, les Products peuvent migrer tout en échouant aux attentes commerciales ou opérationnelles.
Tous les attributs source deviennent-ils des spécifications VTEX ?
Non. Les attributs source doivent être examinés selon leur finalité. Certains deviennent des spécifications, certains définissent des SKUs, d’autres appartiennent au contenu ou aux intégrations, et certains doivent être exclus s’ils ne servent plus l’exploitation cible.
Les promotions et règles tarifaires source peuvent-elles migrer comme champs Product ?
Généralement non. Promotions, coupons, tables de prix, conditions de canal et logique tarifaire externe doivent être examinés séparément des prix Product de base. Certaines valeurs peuvent être conservées comme références, tandis que le fonctionnement commercial actif peut nécessiter une configuration VTEX ou une intégration.
Les Orders historiques équivalent-ils à la configuration OMS de VTEX ?
Non. Les Orders historiques conservent le contexte d’achats passés lorsque cela est pris en charge. Le traitement actif des Orders appartient aux configurations actuelles de Checkout, Payments, OMS, Logistics, stock et sellers.
Quand les données VTEX nécessitent-elles un modèle d’entité séparé ?
Un modèle d’entité séparé est nécessaire lorsqu’un enregistrement source ne peut pas devenir un enregistrement Catalog, Customer, Master Data, Order, CMS, seller ou système externe sans perdre son identité ou ses relations. Il faut définir le propriétaire de l’entité, sa clé et ses liens avant d’attribuer les champs individuels.
Comment les trade policies et les relations SKU influencent-elles la migration VTEX ?
Le Product porte la signification descriptive commune, tandis que les SKUs représentent les variations vendables et que les trade policies peuvent modifier assortiment, prix, logistique ou contexte commercial. Le mapping doit préserver ces relations afin qu’un enregistrement ne soit pas considéré comme complet simplement parce que l’enveloppe Product existe.