Présentation de VTEX

VTEX est une plateforme e-commerce cloud conçue pour les opérations d’entreprise, l’extensibilité, la coexistence de plusieurs modèles commerciaux et l’interconnexion de services e-commerce spécialisés. Son architecture couvre notamment le Catalog, la tarification, les promotions, le checkout, les Orders, la logistique, les paiements, la recherche, Master Data, les fonctions marketplace, les capacités B2B, le développement de storefronts et l’infrastructure applicative. Une implémentation VTEX peut fonctionner comme boutique directe au consommateur, environnement multimarque, marketplace, seller connecté à des marketplaces externes, canal B2B, ou combiner plusieurs de ces modèles.

Cette amplitude distingue fortement VTEX des plateformes où l’activité e-commerce est concentrée dans une seule base catalogue et un seul storefront. La disponibilité d’un Product peut dépendre de l’activation du SKU, du stock, du prix, de la trade policy, de la relation avec le seller, de la logistique et de la configuration du storefront. Un Product peut exister dans le Catalog tout en restant indisponible si l’une de ces couches connectées est incomplète. Une offre marketplace peut apparaître sous un Product tout en appartenant à un autre seller. Un storefront headless peut présenter les données e-commerce VTEX sans partager la même couche d’implémentation que l’environnement d’administration.

Migrer vers VTEX ne consiste donc pas uniquement à transférer des Products, Customers et Orders. Il faut reconstruire les relations commerciales à travers des services modulaires. Le compte cible doit exprimer quels articles existent, quels SKUs sont vendables, qui les fournit, où le stock est détenu, quels prix s’appliquent, quels canaux peuvent les vendre, comment le checkout détermine le traitement logistique et quel storefront ou quelle application consomme les données résultantes.

VTEX comme architecture e-commerce cloud

VTEX fournit une plateforme cloud gérée plutôt qu’un logiciel auto-hébergé. Les services essentiels, l’infrastructure de plateforme et les API e-commerce fonctionnent dans l’environnement VTEX, tandis que les marchands et partenaires d’implémentation configurent les règles métier, intègrent les systèmes externes, construisent les storefronts et étendent les capacités à travers les modèles d’application et d’API pris en charge.

La plateforme est volontairement modulaire. Les enregistrements du Catalog ne déterminent pas à eux seuls l’expérience client. Tarification, promotions, stock, logistique, sellers, trade policies, checkout, recherche et rendu du storefront apportent chacun une partie distincte du résultat final. Cette modularité favorise l’échelle entreprise et la coexistence de plusieurs modèles opérationnels, mais elle augmente aussi la dépendance à la justesse des relations entre services.

La documentation de présentation de VTEX met l’accent sur l’infrastructure cloud, la sécurité, la confidentialité des données, la composabilité, l’extensibilité, l’architecture des boutiques et l’expérience développeur. Ces sujets ne sont pas périphériques : ils définissent la gouvernance de l’environnement cible et la répartition des responsabilités entre les équipes du projet de migration.

Architecture du catalogue : Categories, Products et SKUs

Le VTEX Catalog commence par les Categories et les marques, puis définit les Products et les SKUs. Un Product représente la définition commerciale générale d’un article, tandis qu’un SKU correspond à la variation achetable précise qui porte le stock et que l’acheteur sélectionne. Chaque Product appartient à une Category et à une marque, et chaque Product doit posséder au moins un SKU.

Les spécifications jouent également un rôle structurel important. VTEX associe des groupes de spécifications aux Categories, et ces groupes peuvent être hérités par les niveaux inférieurs de la hiérarchie. Les spécifications Product décrivent des caractéristiques au niveau du Product, tandis que les spécifications SKU différencient les variations achetables. Les attributs de la boutique source ne peuvent donc pas être mappés correctement sans déterminer s’ils classent le Product, définissent un SKU, servent au filtrage ou ne constituent que du contenu descriptif.

VTEX exige davantage que la simple création des enregistrements Product et SKU. Categories, marques, groupes de spécifications, spécifications, images, activation des SKUs, prix, stock et disponibilité par canal de vente doivent fonctionner ensemble avant qu’un article soit réellement vendable. C’est pourquoi une comparaison fondée uniquement sur le nombre d’enregistrements peut surestimer la complétude d’une migration. L’unité pertinente est la relation commerciale active, pas une ligne Product isolée.

Attachments, assembly options, services et kits étendent encore le modèle Product. Les attachments peuvent recueillir des informations facultatives associées à un SKU. Les assembly options prennent en charge des combinaisons plus complexes, des quantités, des articles supplémentaires, des coûts et des relations de stock. Les services peuvent représenter des ajouts payants tels que l’emballage cadeau ou des garanties. Les kits regroupent des SKUs vendus ensemble. Chaque structure possède une signification opérationnelle différente et ne doit pas être aplatie dans un champ générique d’options.

Trade policies, comptes et contexte de canal

VTEX utilise les trade policies pour définir le contexte commercial selon les canaux. Une trade policy peut influencer la disponibilité d’un Product et d’autres conditions de vente pour un canal ou une opération donnés. Les comptes d’entreprise peuvent également regrouper plusieurs boutiques, marques, pays, unités métier ou storefronts dont les catalogues se chevauchent sans fonctionner de manière identique.

Ce modèle dépendant du canal est important pendant la migration, car les boutiques sources expriment souvent les différences de marché ou de canal de manière moins explicite. Une plateforme source peut utiliser des sites distincts, des listes de prix, des groupes de Customers, des entrepôts, des sous-domaines ou des champs personnalisés pour représenter ce que VTEX exprime à travers les trade policies et la configuration du compte. La conception cible doit déterminer si ces distinctions doivent rester séparées, être consolidées ou devenir une configuration propre à certains canaux.

Un Product actif dans une trade policy n’est pas nécessairement destiné à une autre. Prix, logistique, sellers, promotions et fonctionnement du checkout peuvent également varier selon le contexte commercial. Migrer un seul enregistrement Product global sans préserver ces distinctions peut provoquer une exposition excessive, un assortiment incomplet ou un fonctionnement commercial incorrect.

Sellers, marketplaces et propriété des offres

VTEX prend en charge aussi bien le modèle marketplace que le modèle seller. Un compte VTEX peut agir comme marketplace recevant des offres de sellers externes, ou comme seller dont le catalogue et les offres sont distribués à des marketplaces externes. L’intégration catalogue peut donc couvrir bien plus que la propriété des Products.

Dans un contexte marketplace, la marketplace peut posséder la présentation commune du Product tandis que les sellers possèdent les offres, notamment le prix, le stock, les conditions de traitement logistique et les identifiants propres au seller. Des mappings Product et Category peuvent relier des taxonomies de catalogue différentes entre les parties de la marketplace. Un même Product peut avoir plusieurs offres seller, chacune avec sa propre disponibilité commerciale.

Ce modèle opérationnel distingue nettement VTEX d’une plateforme à marchand unique. Une migration qui ignore les relations entre sellers et offres peut préserver les Products visibles tout en perdant la structure de propriété qui permet à la marketplace de fonctionner.

Tarification, stock, logistique et vendabilité

VTEX sépare l’identité principale du Catalog des services qui rendent un SKU commercialement disponible. Les prix sont gérés à travers les structures de tarification. Le stock est associé à la logistique et aux emplacements de traitement. Les politiques d’expédition, docks, entrepôts, transporteurs et conditions de livraison influencent la capacité du checkout à déterminer une option de traitement viable. Les promotions peuvent modifier le résultat commercial indépendamment du prix de base.

La vendabilité est donc définie par plusieurs couches. Un SKU peut exister, comporter des images et des spécifications, mais rester indisponible faute de prix valide, de stock, de trade policy applicable, d’offre seller ou de parcours de traitement logistique. À l’inverse, le même SKU peut être vendu à des prix ou selon des conditions logistiques différentes suivant le canal.

Les plateformes sources regroupent souvent ces couches dans un nombre réduit de champs. Une table Product peut contenir à la fois le stock et le prix. Une extension d’entrepôt peut porter le détail par emplacement. Un module d’expédition peut calculer la livraison indépendamment. VTEX exige que ces concepts soient placés dans les services qui en sont responsables. La migration doit donc préserver la relation entre l’identité de l’article et son exécution commerciale.

Customers, Master Data, checkout et Orders

L’identité Customer dans VTEX peut couvrir des comptes, adresses, profils, informations organisationnelles, consentements, champs personnalisés et données stockées dans Master Data ou dans des systèmes Customer connectés. Les implémentations B2B peuvent ajouter des organisations, centres de coûts, rôles, permissions, contextes tarifaires et logiques d’approbation. Ces structures ne correspondent pas à une simple liste d’utilisateurs enregistrés.

Le checkout orchestre le processus d’achat actif à travers les articles, sellers, prix, stocks, logistique, paiements, promotions et contexte Customer. Les Orders enregistrent le résultat des transactions terminées et prennent en charge le traitement opérationnel. L’historique des Orders peut conserver un contexte utile pour le service client et le reporting, mais il ne configure pas le fonctionnement du checkout dans le compte cible.

Cette différence est importante : une migration peut transférer correctement les noms, adresses et totaux d’Orders tout en laissant incomplets les permissions organisationnelles, les données de profil personnalisées, la configuration des paiements, la logistique, le routage marketplace ou les intégrations du checkout. La modularité de VTEX rend ces frontières explicites.

Storefronts, VTEX IO et composabilité

VTEX prend en charge plusieurs approches pour les storefronts et les applications. VTEX IO fournit un environnement cloud de développement et d’applications, tandis que Store Framework et d’autres options de storefront peuvent consommer les services e-commerce VTEX. Les implémentations headless peuvent utiliser des frontends personnalisés qui interagissent avec les API et services de la plateforme.

Un storefront n’est donc pas simplement un thème attaché à des Products migrés. Il constitue une couche d’implémentation qui détermine la navigation, la présentation des Products, la recherche, le contenu, l’expérience de compte, l’analytique et l’intégration au checkout. Les thèmes, templates, widgets et scripts de la boutique source ne deviennent pas automatiquement des composants du storefront VTEX.

La composabilité et l’extensibilité permettent aux équipes d’ajouter des applications et intégrations sans modifier le cœur d’un logiciel auto-hébergé. Cette flexibilité architecturale distribue cependant la responsabilité entre configuration de plateforme, applications, systèmes externes et code frontend. Une vue d’ensemble de la migration doit donc reconnaître que la préparation du storefront et la préparation des données sont liées mais distinctes.

Intégrations et propriété des systèmes d’entreprise

VTEX fonctionne fréquemment aux côtés d’ERP, PIM, OMS, WMS, CRM, marketplaces, systèmes fiscaux, paiements, moteurs de recherche et outils d’analytique. La documentation officielle du Catalog décrit explicitement des flux d’intégration back-office pour la création et la mise à jour des données Catalog. Dans de nombreuses implémentations, VTEX n’est pas le système de référence unique pour les Products, prix, stocks, Customers ou Orders.

Cela crée l’une des questions déterminantes d’une migration VTEX : quel système sera responsable de chaque enregistrement après le lancement ? Une valeur migrée peut être écrasée par un flux ERP. Le stock importé pendant la migration peut devenir sans importance dès que la synchronisation WMS commence. Les descriptions Product peuvent être gérées dans un PIM, tandis que les offres marketplace proviennent de connecteurs seller. Les données Customer peuvent être enrichies ou gouvernées dans un CRM.

L’architecture orientée API et extensible de la plateforme facilite ces intégrations, mais elle ne supprime pas les décisions de gouvernance des données. La migration doit établir des identifiants stables et une responsabilité claire avant que les flux automatisés ne commencent à mettre à jour l’environnement cible.

VTEX dans l’écosystème des plateformes

VTEX se situe plus près des plateformes e-commerce composables et orientées entreprise que des solutions de création de boutiques hébergées d’entrée de gamme. La plateforme fournit une fondation cloud gérée tout en exposant des services spécialisés, des API, des relations marketplace, des options de développement de storefront et des contrôles opérationnels d’entreprise.

Par rapport à des plateformes SaaS plus simples, VTEX répartit davantage le cycle e-commerce entre des services gouvernés indépendamment. Par rapport aux plateformes Open-Source auto-hébergées, elle réduit la responsabilité directe sur l’infrastructure et le code du cœur tout en mettant l’accent sur la configuration, les API, les applications et les systèmes connectés. Par rapport à une stack composable entièrement personnalisée, elle fournit une plateforme e-commerce intégrée plutôt que d’exiger la sélection et l’assemblage indépendants de chaque service.

L’incidence sur la migration découle de cette position. VTEX peut représenter des catalogues, canaux, sellers, marketplaces, structures B2B et intégrations complexes, mais l’architecture cible doit être intentionnelle. Products et Orders ne sont qu’une partie du modèle opérationnel : le contexte commercial, les relations entre services et la propriété des systèmes déterminent si la plateforme sera réellement exploitable.

Conclusion

VTEX est une plateforme e-commerce cloud modulaire dont l’identité couvre le Catalog, les SKUs, les spécifications, la tarification, les promotions, le stock, la logistique, les trade policies, les sellers, les marketplaces, le checkout, les Orders, Master Data, les storefronts, les applications et les intégrations. La plateforme prend en charge des modèles opérationnels d’entreprise complexes précisément parce que ces sujets sont représentés comme des couches distinctes mais interconnectées.

L’orientation essentielle pour la migration consiste à reconstruire délibérément ces relations. Les Products doivent être traduits dans la hiérarchie Product-SKU de VTEX. Les spécifications doivent conserver la bonne signification au niveau Product ou SKU. La vendabilité doit relier prix, stock, seller, logistique et contexte de canal. Les enregistrements Customer et Order doivent rester distincts du fonctionnement actif du checkout et du B2B. Les storefronts et intégrations d’entreprise doivent s’appuyer sur des identifiants stables et une responsabilité système claire. Cette architecture constitue la base de tous les articles suivants du hub VTEX.

Questions fréquentes

Quelle est la différence entre un Product et un SKU dans VTEX ?

Un Product est la définition générale d’un article, tandis qu’un SKU est la variation achetable précise qui porte le stock et que l’acheteur sélectionne. Chaque Product VTEX doit posséder au moins un SKU.

Pourquoi les spécifications sont-elles importantes dans VTEX ?

Les spécifications décrivent des caractéristiques de Product ou de SKU et sont organisées à travers des groupes liés aux Categories. Elles peuvent servir à la variation, au filtrage, à la classification et à la présentation dans le storefront. Les attributs source doivent donc être mappés selon leur rôle réel.

Que représente une trade policy ?

Une trade policy établit le contexte commercial d’un canal ou d’une opération. Elle peut influencer la disponibilité des Products et d’autres conditions de vente, ce qui permet à un même compte de prendre en charge différents marchés ou canaux.

Comment VTEX gère-t-il les sellers marketplace ?

VTEX peut relier les offres seller à des Products et SKUs partagés. Les sellers peuvent posséder le prix, le stock et le contexte de traitement logistique, tandis que la marketplace gouverne la présentation du catalogue et l’orchestration des transactions.

La migration des Products les rend-elle immédiatement vendables dans VTEX ?

Pas nécessairement. Un SKU peut aussi avoir besoin de spécifications valides, d’images, d’une activation, d’un prix, d’un stock, d’un contexte seller, d’une disponibilité via la bonne trade policy et d’une configuration logistique avant de pouvoir être acheté.

Un storefront VTEX fait-il partie des données migrées ?

Un storefront constitue une couche d’implémentation séparée. Les enregistrements Product et de contenu peuvent alimenter l’expérience, mais les thèmes et le code frontend de la boutique source doivent être réimplémentés dans l’architecture storefront VTEX retenue.