Si VTEX est retenu comme plateforme cible, la préparation doit transformer le modèle e-commerce d’entreprise en un ensemble d’éléments vérifiables, répartis par domaine et par responsable, avant toute exécution de migration. Catalog, Pricing, Promotions, Trade Policies, Inventory, Logistics, Checkout, Payments, OMS, Master Data, sellers, relations marketplace et contenu storefront sont liés mais gouvernés séparément.
Pour chaque domaine important, consignez l’action, le responsable, les éléments de validation et la condition de préparation. Cela évite qu’un export Product soit pris pour un VTEX Catalog complet, ou que des Orders historiques soient confondus avec la configuration actuelle de la logistique et du processus de commande.
Définir le modèle opérationnel VTEX et la responsabilité de chaque domaine
Préparez une cartographie concise indiquant quels domaines VTEX et quels systèmes externes possèdent chaque relation commerciale.
| Domaine de préparation | Décision à consigner | Responsable | Élément attestant la préparation |
|---|---|---|---|
| Catalog | Categories, Brands, Products, SKUs, spécifications, attachments, kits et assembly options | Responsable Catalog | Cartographie des relations Catalog |
| Contexte commercial | Prix, Promotions, Trade Policies, sellers, offres et assortiment par canal | Responsable commercial | Matrice SKU/canal/prix/responsabilité |
| Customer et B2B | Profils Customer, adresses, organisations, rôles, centres de coûts et entités Master Data | Responsable Customer/B2B | Schéma d’identité et d’entités |
| Orders et opérations | Checkout, Payments, OMS, Logistics, stock, entrepôts, docks, transporteurs et sellers | Responsable opérations | Cartographie des domaines Order et logistique |
| Storefront | CMS, recherche, navigation, routes, contenu et propriété du frontend headless | Responsable expérience digitale | Cartographie des responsabilités storefront |
| Systèmes externes | ERP, PIM, WMS, CRM, marketplace, fiscalité, comptabilité et middleware | Responsable technique | Registre des dépendances et systèmes de référence |
La cartographie doit indiquer où chaque valeur fait autorité et quel identifiant la relie aux autres domaines.
Préparer les accès, exports, sauvegardes et éléments de la boutique source
Rassemblez :
- les accès administrateur de la source et les accès VTEX nécessaires ;
- des exports datés des Products, SKUs, Categories, Brands, prix, promotions, Customers, Orders et contenus ;
- des archives base de données, médias ou applications lorsqu’elles existent ;
- les groupes de spécifications, spécifications Product, spécifications SKU et valeurs contrôlées ;
- les rapports Trade Policy, seller, canal, entrepôt, dock, transporteur et stock ;
- des exemples d’entités Customer, B2B et Master Data ;
- les identifiants des catalogues marketplace et sellers ;
- les inventaires CMS, recherche, navigation, URLs, métadonnées et redirections ;
- les inventaires d’applications, API, middleware, intégrations et systèmes externes ;
- des captures d’écran ou rapports expliquant les fonctionnements source importants.
| Élément | Pourquoi il est nécessaire | Condition de préparation |
|---|---|---|
| Dictionnaire Catalog | Explique le sens Product/SKU/spécification | Chaque champ prioritaire possède un responsable et une valeur représentative. |
| Matrice canaux et sellers | Protège le périmètre Trade Policy et marketplace | Chaque relation seller/canal est documentée. |
| Inventaire Master Data | Identifie les entités personnalisées hors des enregistrements Customer ordinaires | Chaque entité importante possède schéma, clé et responsable. |
| Registre des intégrations | Protège la continuité inter-systèmes | Chaque identifiant durable est relié à la bonne entité VTEX ou externe. |
| Inventaire routes/contenus | Sépare l’implémentation storefront des données Catalog | Les routes et contenus prioritaires possèdent un responsable cible. |
L’absence d’un export API ou une transformation middleware non documentée doit rester visible comme élément de préparation non résolu.
Préparer Categories, Products, SKUs et spécifications
Sélectionnez des enregistrements représentatifs qui exposent toute la hiérarchie VTEX : Category, Brand, Product, SKU, groupe de spécifications, spécification Product et spécification SKU.
Incluez :
- des Products simples avec un seul SKU ;
- des Products avec plusieurs SKUs ;
- des Products dont les valeurs SKU définissent taille, couleur, modèle, tension, région ou conditionnement ;
- des groupes de spécifications propres à certaines Categories et des champs hérités ;
- des Products avec Brands, médias, contenus liés ou identifiants PIM externes ;
- attachments, services, kits, bundles ou fonctionnement d’assembly options ;
- des Products fournis par plusieurs sellers ou canaux.
| Fonctionnement source | Décision de préparation VTEX | Élément requis |
|---|---|---|
| La valeur distingue l’unité vendable | Définir la spécification SKU et la relation SKU | IDs Product/SKU, valeurs, images, stock et clés externes |
| La valeur décrit le Product générique | Définir la spécification Product | Category, groupe de spécifications, type de champ et valeurs |
| Le Customer fournit une information | Définir un attachment ou un autre responsable applicatif | Définition de la saisie et exemple d’Order historique |
| Le Product contient des composants ou articles facultatifs | Définir kit, assembly option, service ou responsable externe | Liste de composants, quantité, prix, stock et fonctionnement Order |
| Le catalogue provient d’un PIM | Préserver identifiants PIM et VTEX | Système de référence et clé de synchronisation |
Normalisez les noms de spécifications en doublon, les valeurs incohérentes, les SKUs orphelins, les Categories manquantes et les Products obsolètes avant la mise en correspondance finale. Le Catalog est prêt lorsque chaque grande famille Product dispose d’un plan pour Category, Brand, Product, SKU, spécification et identifiant externe.
Préparer trade policies, prix, sellers et contexte commercial
Les Trade Policies peuvent relier Catalog, tarification, Promotions, stock, logistique, paramètres de paiement et canaux de vente. Sellers et offres marketplace ajoutent encore une couche de responsabilité.
| Enregistrement commercial | Action de préparation | Élément attestant la préparation |
|---|---|---|
| Trade Policy | Définir canal de vente, disponibilité Catalog, règles commerciales et opérations liées | Matrice Trade Policy |
| Prix | Identifier SKU, devise, table de prix, contexte Customer/canal et système de référence | Exemples de prix SKU représentatifs |
| Promotion | Consigner conditions, périmètre, dates et Products/Customers concernés | Inventaire des promotions prioritaires |
| Seller | Définir identité seller, Products, offres, responsabilité de traitement et IDs externes | Matrice de responsabilité seller |
| Offre marketplace | Séparer l’identité Catalog canonique du prix, stock et traitement propres au seller | Exemple de correspondance Product/SKU/seller |
| Assortiment B2B | Définir relations organisation, Trade Policy, Catalog, prix et accès | Scénario acheteur B2B représentatif |
Ne traitez pas les prix de canal source ni les enregistrements seller comme des champs Product ordinaires. La préparation est suffisante lorsque chaque SKU prioritaire possède un propriétaire de prix, un périmètre Trade Policy, une relation seller et une autorité de stock déclarés.
Préparer Customers, enregistrements B2B et Master Data
Les données liées aux Customers peuvent inclure profils classiques, adresses, organisations, rôles acheteurs, centres de coûts, contexte d’approbation, formulaires personnalisés, consentement, fidélité, IDs CRM et documents Master Data.
Préparez :
- Customers enregistrés, invités, adresses multiples, identités en doublon et IDs externes ;
- organisations B2B, utilisateurs, rôles, centres de coûts et contexte commercial ;
- entités Customer et processus personnalisés stockées hors des profils standard ;
- schémas, champs, clés, références et consommateurs Master Data ;
- décisions de consentement, confidentialité et conservation ;
- identifiants CRM, ERP, fidélité, marketplace et support.
| Enregistrement source | Responsable | Élément requis | Condition de préparation |
|---|---|---|---|
| Identité Customer | Opérations Customer | Exemples de doublons et d’invités | Règles d’identité et de fusion documentées |
| Organisation B2B | Responsable B2B | Matrice organisation/utilisateur/rôle/centre de coûts | Relations entreprise avec propriétaire cible défini |
| Document Master Data | Responsable du processus métier | Schéma d’entité et exemple de référence | Clé, relation parent et consommateur futur connus |
| Consentement ou champ sensible | Responsable juridique/données | Liste de champs approuvée | Finalité et base de conservation documentées |
| Clé externe | Responsable intégration | Exemple de recherche CRM/ERP/marketplace | Clé attachée au bon niveau d’entité |
Master Data ne doit pas devenir un réceptacle pour des champs source mal définis. Chaque document personnalisé exige une entité métier nommée, une clé, une relation et un responsable futur.
Préparer les Orders historiques et leurs références opérationnelles
Sélectionnez des Orders révélant identité Customer, seller, Trade Policy, lignes SKU, prix, Promotions, taxes, références de paiement, expédition, traitement, statut et IDs externes.
Incluez :
- Orders ordinaires, annulés, remboursés et partiellement traités ;
- Orders de chaque seller, Trade Policy, devise et canal important ;
- Orders marketplace ;
- Orders avec plusieurs expéditions ou transporteurs ;
- Orders contenant kits, attachments, services ou données personnalisées ;
- Orders reliés à ERP, comptabilité, WMS, marketplace ou outils de support.
| Domaine historique | Élément | Condition de préparation |
|---|---|---|
| Lignes Product/SKU | Dossier d’Order représentatif | SKU acheté, seller, quantité, prix et données personnalisées sont expliqués |
| Contexte de paiement | Exemples de méthode, transaction et statut | Références historiques et frontières des données sensibles sont documentées |
| Contexte logistique | Exemples de mode d’expédition, SLA, transporteur, entrepôt, dock, suivi et traitement | Relation historique compréhensible sans configurer la logistique active |
| Ajustements | Promotions, taxes, remboursements, annulations et modifications manuelles | Totaux historiques explicables |
| Lignée externe | IDs ERP, marketplace ou comptabilité | Clés de rapprochement conservées au bon niveau Order |
Les Orders historiques sont des traces du commerce passé. La configuration actuelle de Checkout, Payments, OMS, Logistics, transporteurs et entrepôts reste séparée des enregistrements Order migrés.
Préparer stock, logistique, contenu storefront et URLs
La préparation du stock doit identifier quel système possède quantité et disponibilité, quels entrepôts ou sellers fournissent chaque SKU et comment Trade Policy et contexte logistique pertinents sont représentés.
Pour le storefront, collectez :
- contenu Product et Category ;
- CMS Pages, landing pages, Blog Posts, guides et contenus de campagne ;
- exemples de recherche, facettes, navigation et filtres ;
- URLs prioritaires Product, Category, Brand, campagne et contenu ;
- métadonnées, relations canoniques et redirections ;
- responsabilité du frontend headless ou du CMS ;
- inventaires médias et liens internes.
| Domaine | Question de préparation | Élément attestant la préparation |
|---|---|---|
| Stock | Quel système, entrepôt, seller ou flux possède chaque quantité SKU ? | Matrice SKU/système de référence |
| Logistique | Quelles relations entrepôt, dock, transporteur, SLA, retrait ou traitement comptent ? | Cartographie logistique représentative |
| Recherche et facettes | Quelles spécifications et Categories soutiennent la découverte ? | Exemples contrôlés de champs et filtres |
| Contenu | Quel CMS VTEX, CMS externe ou dépôt frontend possède l’enregistrement ? | Inventaire des responsabilités de contenu |
| URLs | Quelle route ou redirection préserve chaque chemin source prioritaire ? | Registre URL source/destination |
Le domaine est prêt lorsque Catalog, stock, logistique, contenu et routes possèdent des responsables distincts au lieu d’être traités comme un seul export storefront.
Inventorier applications, API et systèmes externes
Créez un registre de dépendances pour chaque application, API, flux middleware, intégration personnalisée, webhook et plateforme externe qui crée ou modifie Catalog, Customer, Order, prix, seller, stock, logistique ou contenu.
Pour chaque dépendance, consignez :
- finalité métier ;
- domaine VTEX et enregistrements concernés ;
- système de référence externe ;
- IDs et clés de référence ;
- disponibilité API ou export ;
- responsables métier et technique ;
- décision de maintien, remplacement ou retrait ;
- données nécessaires avant de configurer le processus cible.
Les dépendances prioritaires comprennent ERP, PIM, WMS, OMS, CRM, comptabilité, fiscalité, fraude, recherche, marketplace, fidélité, abonnement, personnalisation, analytique et systèmes de contenu.
Le registre est prêt lorsque chaque valeur importante possède un responsable faisant autorité et une clé durable. Un champ middleware sans ses entités source et destination ne constitue pas un élément suffisant.
Sélectionner des échantillons représentatifs pour le test de migration
| Échantillon | Objectif de préparation |
|---|---|
| Product avec plusieurs SKUs | Exposer relations Product/SKU/spécifications/médias |
| Category avec spécifications héritées | Exposer hiérarchie Catalog et responsabilité des champs |
| SKU utilisé dans plusieurs Trade Policies | Exposer contexte prix, canal, stock et logistique |
| Product marketplace et offre seller | Exposer Catalog canonique versus responsabilité seller |
| Customer ou organisation B2B | Exposer identité, rôle, centre de coûts et contexte commercial |
| Document Master Data | Exposer entité personnalisée, clé, référence et responsable |
| Order historique complexe | Exposer seller, SKU, promotion, paiement, traitement et IDs externes |
| Contenu ou route headless | Exposer responsabilité frontend, CMS, SEO et redirection |
Pour chaque échantillon, consignez l’ID source, l’URL source lorsque pertinente, la raison métier, le domaine VTEX prévu, les identifiants externes, les exclusions connues et le responsable de validation.
Finaliser le contrôle de préparation VTEX
| Question de préparation | Élément requis | Condition de validation |
|---|---|---|
| Les accès et archives source sont-ils récupérables ? | Registre d’accès et exports/sauvegardes datés | Les enregistrements requis peuvent être inspectés indépendamment de la boutique source active. |
| La responsabilité des domaines est-elle documentée ? | Cartographie domaines VTEX/systèmes externes | Chaque grande famille d’enregistrements possède un responsable. |
| Les structures Catalog et SKU sont-elles prêtes ? | Matrice Product/SKU/spécifications | Chaque grand modèle Product possède une représentation VTEX définie. |
| Trade Policies, sellers et prix sont-ils attribués ? | Matrice de responsabilité commerciale | Les cas représentatifs de canal et seller sont complets. |
| Les entités Customer et Master Data sont-elles définies ? | Schémas d’identité et d’entités | Clés, relations et consommateurs sont documentés. |
| Les Orders et références opérationnelles sont-ils expliqués ? | Dossier d’Orders historiques | Les transactions passées restent compréhensibles. |
| Applications et systèmes externes sont-ils inventoriés ? | Registre des dépendances | Chaque dépendance critique possède un responsable futur. |
| Les échantillons représentatifs sont-ils sélectionnés ? | Registre d’échantillons | Complexité Catalog, commerciale, Customer, Order et storefront couverte. |
| Les points non résolus sont-ils contrôlés ? | Journal de décision | Chaque point ouvert possède un responsable et une échéance. |
La préparation est complète lorsqu’aucune décision critique concernant Catalog, SKU, Trade Policy, seller, Customer, Master Data, Order, stock, route ou intégration ne dépend d’une hypothèse non documentée.
Conclusion
Préparer VTEX revient à constituer un ensemble d’éléments d’entreprise répartis par domaine et par responsable. Categories, Products, SKUs, spécifications, Trade Policies, sellers, prix, Customers, Master Data, Orders, logistique, contenu et intégrations doivent chacun avoir un responsable déclaré et des enregistrements représentatifs.
Lorsque ces décisions sont préparées avant le test représentatif, l’échantillon peut refléter l’architecture VTEX visée au lieu de traiter un ensemble d’enregistrements importés comme une opération e-commerce complète.
Questions fréquentes
Quel document de préparation VTEX faut-il créer en premier ?
Commencez par la cartographie des responsabilités pour Catalog, contexte commercial, Customers, Orders, opérations, storefront et systèmes externes. Elle détermine quels éléments et quels responsables sont nécessaires.
Pourquoi Products et SKUs doivent-ils être préparés séparément ?
Le Product représente la définition commerciale générale, tandis que chaque SKU représente une variation vendable. Spécifications, images, stock, prix, offres seller et lignes d’Order peuvent dépendre de cette relation SKU.
Que faut-il préparer pour les Trade Policies ?
Documentez le canal de vente, la disponibilité SKU, le contexte tarifaire, les Promotions, le stock, la logistique, les relations de paiement, les sellers et systèmes externes associés à chaque Trade Policy prioritaire.
Comment préparer Master Data ?
Définissez chaque entité, schéma, clé durable, relations parent, consommateurs, exigences de confidentialité et responsable cible. Master Data ne doit pas servir d’emplacement générique pour des champs non définis.
Comment préparer les Orders historiques pour VTEX ?
Fournissez des Orders représentatifs avec lignes SKU, sellers, prix, Promotions, taxes, références de paiement, contexte d’expédition, traitement, statuts et IDs externes. Gardez ces éléments séparés de la configuration opérationnelle actuelle.
Quand la préparation VTEX est-elle complète ?
Elle l’est lorsque responsabilités de domaine, structures Catalog, relations commerciales, entités Customer/Master Data, Orders, contenus, routes, intégrations, échantillons et décisions non résolues sont tous documentés avec des responsables identifiés.