La planification du modèle de données BigCommerce doit commencer par le sens des données, et non par leur nombre. Les produits, catégories, clients, commandes, CMS Pages, Blog Posts, redirections et champs associés peuvent porter des noms familiers, mais BigCommerce représente le commerce au moyen de structures organisées de catalogue, de tarification, de canaux, de clientèle, de contenu et d’intégration qui peuvent fonctionner différemment de celles de la plateforme source.
Une boutique source peut sembler complète après migration tout en étant commercialement incorrecte. Les choix de produits peuvent être affectés à la mauvaise structure. Les chemins de catégories peuvent exister sans préserver la découverte. Les fiches clients peuvent être présentes sans le contexte tarifaire qui leur donnait leur valeur. Des redirections peuvent fonctionner tout en envoyant les clients vers des destinations peu pertinentes. Des champs personnalisés et metafields peuvent être présents mais déconnectés de l’application, de l’ERP, de la recherche, du merchandising ou du fonctionnement de la vitrine qu’ils alimentaient auparavant.
La planification la plus sûre consiste donc à traduire la signification des enregistrements de la source dans le modèle BigCommerce avant de considérer le périmètre comme définitif.
Pourquoi le sens des données dans BigCommerce mérite une revue spécifique
BigCommerce est une plateforme cible SaaS hébergée avec des structures commerciales définies. Cette structuration peut simplifier la gouvernance après migration, mais elle impose également des décisions de représentation plus explicites. Une plateforme source peut avoir laissé se chevaucher les options de produits, champs de personnalisation, groupes de clients, règles de prix, pages d’atterrissage et fonctionnements détenus par des applications. BigCommerce oblige généralement à distinguer plus clairement ces significations.
La question centrale n’est pas de savoir si un enregistrement source possède une destination dans BigCommerce. Il faut vérifier si cette destination préserve l’usage métier de l’enregistrement.
| Domaine BigCommerce | Signification à confirmer pendant la migration |
|---|---|
| Choix de produits | Déterminer si le choix de la source doit devenir une variante, une option de variante, un modifier, un champ personnalisé, un metafield, une configuration d’application ou une autre structure cible définie. |
| Structure des catégories | Vérifier si les catégories de la source préservent l’organisation du catalogue, la navigation, le merchandising et la découverte sensible au SEO. |
| Contexte tarifaire | Vérifier si les prix de base, règles dégressives, listes de prix, logique de groupes de clients et références tarifaires externes restent pertinentes. |
| Périmètre des canaux | Vérifier si les produits, catégories, prix, contenus et URL appartiennent au bon contexte de vitrine ou de canal. |
| Enregistrements clients et commandes | Vérifier si l’identité client, le contexte du compte, l’appartenance à un groupe, l’historique de commandes et leur utilité pour le service restent exploitables. |
| Contenus et chemins | Vérifier si les CMS Pages, Blog Posts, redirections et destinations de pages préservent l’intention du client. |
| Données personnalisées et d’applications | Déterminer si les champs personnalisés, metafields, enregistrements détenus par des applications et identifiants externes nécessitent un mapping ou filtrage direct, une restructuration des données ou une configuration de la boutique cible. |
Cette revue évite une approbation superficielle. Le marchand ne doit pas seulement demander : « L’enregistrement a-t-il été transféré ? » Il doit demander : « BigCommerce détient-il maintenant cet enregistrement dans la structure qui soutient la vente, le service, la tarification, la découverte et la continuité des intégrations ? »
Structure produit : produits, variantes, options et modifiers
La structure produit de BigCommerce exige une interprétation attentive car les plateformes source utilisent les choix de produits de manière différente. Certaines boutiques utilisent des variantes pour chaque choix sélectionnable. D’autres s’appuient sur des champs d’options personnalisés, des plugins, des applications, des configurateurs, des systèmes de bundles ou la logique du thème. BigCommerce distingue plusieurs concepts de choix de produits, et cette séparation influence les stocks, les prix, le traitement des commandes, l’affichage dans la vitrine et le reporting.
Une variante produit représente généralement une version vendable d’un produit. La taille, la couleur, le matériau, le conditionnement, le modèle, la finition ou l’unité peuvent relever de la structure des variantes lorsque le choix influence le SKU, le stock, l’image, le poids, le prix, la disponibilité ou le traitement des commandes. Les options de variantes décrivent les dimensions sélectionnables qui produisent ces combinaisons.
Les modifiers ont une autre fonction. Ils peuvent représenter un choix visible par le client qui modifie l’expérience d’achat sans nécessairement créer un produit distinct suivi en stock. Il peut s’agir d’un texte de personnalisation, d’une gravure, d’un message cadeau, d’options produit supplémentaires, d’un champ de téléversement, d’une garantie ou d’une personnalisation sans stock. Si les options de la source sont placées dans la mauvaise structure, la page produit peut sembler complète alors que le fonctionnement opérationnel est incorrect.
| Choix produit dans la source | Question d’interprétation pour BigCommerce | Sens perdu en cas de mauvaise interprétation |
|---|---|---|
| Taille ou couleur avec SKU et stock | Doit-elle devenir une variante et une option de variante ? | Le sens du stock et de la ligne de commande peut être affaibli. |
| Gravure ou message cadeau | Est-ce plutôt un modifier ou un champ personnalisé ? | La saisie de l’acheteur peut être transformée à tort en option suivie en stock. |
| Sélection de bundle ou kit | Est-elle prise en charge, détenue par une application ou pilotée par une logique personnalisée ? | Les attentes de prix, traitement des commandes et stock peuvent être rompues. |
| Champ de garantie ou de compatibilité | S’agit-il d’une information d’affichage, de métadonnées produit ou d’un fonctionnement d’application ? | Un contexte commercial important peut rester sous forme de texte tout en perdant sa fonction. |
| Champ de téléversement ou processus de personnalisation | Faut-il une configuration d’application côté cible ou une restructuration des données ? | Le produit peut être migré tout en perdant le parcours d’achat d’origine. |
Les données produit doivent être échantillonnées à travers les vrais modèles du catalogue. Un produit simple, un produit riche en variantes, un produit riche en modifiers, un produit en bundle et un produit comportant des données personnalisées sont plus révélateurs qu’un simple nombre de produits.
Champs personnalisés, metafields et métadonnées produit
Les champs personnalisés et les metafields BigCommerce ont des rôles différents et ne doivent pas être utilisés comme des conteneurs interchangeables. Les champs personnalisés d’un Product peuvent contenir des informations supplémentaires destinées à être utilisées dans la vitrine. Les metafields sont des données programmatiques clé-valeur attachées à des ressources telles que Products, variantes, Categories et marques. Ils sont utiles aux applications et intégrations et ne sont pas automatiquement présentés comme du contenu ordinaire dans la vitrine ou l’interface d’administration.
Cette distinction compte pendant la migration. Un attribut source peut sembler être une simple « donnée personnalisée » alors qu’il remplit une fonction très différente :
| Usage de la donnée source | Question sur la destination BigCommerce |
|---|---|
| Spécification visible par le client | Doit-elle devenir un champ Product, un champ personnalisé, un contenu de page structuré ou une autre valeur visible dans la vitrine ? |
| Choix vendable | Définit-elle une variante, une option de variante ou un modifier plutôt qu’une métadonnée descriptive ? |
| Entrée de recherche ou de filtrage | Quelle structure BigCommerce ou quelle application l’utilisera réellement pour la découverte ? |
| Référence opérationnelle interne | Doit-elle rester cachée dans un metafield ou dans le système externe qui continue à la détenir ? |
| Clé ERP, PIM ou comptable | Quelle ressource possède l’identifiant et comment le système connecté le retrouvera-t-il ? |
| Fonctionnement détenu par une application | L’application cible prend-elle en charge l’importation, ou le processus doit-il être repensé ? |
Le champ cible doit être choisi en fonction de l’usage, de la visibilité et de la propriété. Placer tous les attributs source dans les champs personnalisés Product peut exposer des données internes ou rendre la vitrine difficile à gérer. Tout placer dans des metafields peut préserver des valeurs qu’aucun administrateur, thème ou application ne saura utiliser. Un mapping rigoureux enregistre le consommateur prévu, la relation avec la ressource et le fait que la valeur reste orientée client, opérationnelle, détenue par une intégration ou exclue.
Catégories, arborescences, navigation et découverte
La migration des catégories vers BigCommerce ne doit pas être traitée comme un simple transfert de dossiers. Les catégories, arborescences, affectations de produits, logique de menus, découverte dans la vitrine et chemins sensibles au SEO peuvent tous influencer la navigation du client. Une catégorie source peut avoir cumulé plusieurs rôles : organisation administrative, page d’atterrissage publique, collection de merchandising, regroupement de campagne, entrée de menu, filtre de recherche ou page SEO.
La planification BigCommerce doit distinguer ces rôles. Une catégorie peut devoir devenir une catégorie BigCommerce. Une relation de menu peut relever d’une configuration de vitrine côté cible. Une page d’atterrissage à forte valeur peut nécessiter la préservation de son contenu ou une stratégie de redirection. Une structure de type collection peut exiger un mapping, une reconstruction manuelle, le support d’une application ou une exclusion.
| Structure source | Question de planification BigCommerce |
|---|---|
| Catégorie de produits | Doit-elle devenir une catégorie BigCommerce ou une entrée de l’arborescence de catégories ? |
| Collection ou groupe dynamique | S’agit-il d’une catégorie, d’une règle de merchandising, d’un besoin de configuration de vitrine ou de l’équivalent d’une application ? |
| Menu de navigation | Relève-t-il des données du catalogue ou de la configuration du thème/de la vitrine ? |
| Page d’atterrissage SEO | Doit-elle être migrée comme contenu, contexte de catégorie, destination de redirection ou page reconstruite ? |
| Catégorie de campagne ou temporaire | Doit-elle être migrée, retirée, redirigée ou exclue ? |
Pour les marchands utilisant plusieurs vitrines ou des canaux, la signification d’une catégorie dépend également de l’endroit où les produits doivent apparaître. Une catégorie utile dans une vitrine peut devenir confuse dans une autre. Les affectations de produits, noms, chemins et destinations de redirection doivent donc être examinés dans le contexte de vente concerné.
Prix, groupes de clients et listes de prix
La tarification fait partie des différences les plus importantes du modèle de données BigCommerce car elle peut exister à plusieurs niveaux. Une boutique source peut avoir des prix de base, prix promotionnels, tarifs dégressifs, prix par groupe de clients, paliers de gros, prix régionaux, prix négociés par acheteur, comportements de listes de prix, règles gérées par une application ou systèmes de tarification externes.
La planification ne doit pas aplatir ces relations en un seul prix produit, sauf si l’entreprise souhaite réellement simplifier son modèle après migration. Le contexte tarifaire doit être étudié comme une relation entre produits, clients, groupes, listes de prix, conditions de quantité, vitrines, canaux, applications et systèmes externes.
| Source du prix | Signification à préserver |
|---|---|
| Prix de base du produit | La valeur de vente par défaut. |
| Tarification dégressive | Les attentes de prix selon les quantités. |
| Prix par groupe de clients | La logique par segment d’acheteurs ou de gros. |
| Liste de prix | Un contexte tarifaire plus structuré selon l’audience, le canal ou l’entreprise. |
| Prix géré par une application | Une logique métier qui peut rester détenue par l’application ou nécessiter un propriétaire tarifaire externe. |
| Système tarifaire externe | La continuité des identifiants et de la synchronisation, pas seulement le prix visible. |
Un Product migré peut afficher le bon prix de base tout en portant une signification commerciale incorrecte pour un acheteur de gros, un groupe de clients, un canal ou une vitrine régionale. Les cas tarifaires sensibles doivent donc être modélisés explicitement comme des combinaisons Product–groupe de clients–liste de prix–canal plutôt que déduits du prix de base du Product.
Canaux, vitrines et contexte de vente
Les structures de canaux et de vitrines BigCommerce peuvent affecter la disponibilité des Products, la présentation des Categories, le contexte des devises, les relations avec les sites, les menus, les hypothèses tarifaires, les redirections et l’expérience client. Le sens du canal fait donc partie du modèle de données, et ne constitue pas seulement un paramètre d’implémentation.
Les plateformes source peuvent exprimer cette logique par plusieurs boutiques, sites, marketplaces, régions, versions linguistiques, domaines, intégrations ou code personnalisé. BigCommerce exige une interprétation cible explicite pour chaque relation : quels Products sont affectés à quels canaux, quelle arborescence de Categories soutient chaque site, quels contenus et chemins appartiennent à chaque vitrine et quels prix ou règles clients s’appliquent dans ce contexte.
| Signification dans la source | Relation BigCommerce à définir |
|---|---|
| Vitrine régionale ou de marque | Canal, site, domaine, arborescence de Categories, propriété du contenu et destination des redirections. |
| Marketplace ou canal social | Affectation du produit, propriété du listing externe, identifiants et responsabilité de la synchronisation. |
| Sous-ensemble de catalogue propre à une boutique | Affectation Product-canal et structure des Categories visible dans cette vitrine. |
| Tarification propre à une boutique | Liste de prix, groupe de clients, contexte du canal, système de tarification externe ou autre propriétaire défini. |
| Contenu ou navigation localisés | Contenu détenu par la vitrine, configuration du thème, contenu traduit ou couche d’implémentation distincte. |
Les Products partagés peuvent rester communs tandis que leurs affectations et leur présentation diffèrent selon les canaux. Aplatir ces relations peut donner une administration apparemment complète alors qu’une vitrine reçoit le mauvais assortiment, le mauvais chemin de catégorie, le mauvais contexte tarifaire ou la mauvaise destination de redirection. La carte de migration doit donc enregistrer à la fois l’enregistrement partagé et chaque relation propre au canal qui doit survivre.
Clients, comptes et historique de commandes
Les données clients et commandes doivent être interprétées comme un contexte commercial et de service. Une fiche client peut inclure l’identité, les adresses, l’état du compte, l’affectation à un groupe, des attributs personnalisés, le consentement, les relations avec les commandes et des attentes tarifaires. Une commande peut préserver les noms de produits, SKU, quantités, remises, taxes, expédition, facturation, traitement des commandes, libellés de paiement, notes, remboursements et références externes.
Le plan de migration doit définir ce que l’entreprise attend de l’historique client et des commandes. Le service client, les achats répétés, l’accès de gros, la recherche par le support, le reporting, l’examen des remboursements et la réconciliation avec les intégrations peuvent demander des niveaux de détail différents.
Un système de comptes source peut ne pas se transposer exactement au fonctionnement des comptes BigCommerce. Les mots de passe, appartenances à des groupes, données de fidélité, abonnements, processus de devis, comptes d’entreprise, approbations clients ou références CRM externes peuvent nécessiter une revue séparée. Certaines valeurs peuvent être mappées. Certaines peuvent utiliser un mapping ou filtrage direct des champs. D’autres peuvent nécessiter une restructuration des données ou un parcours de migration propre à une application. Certaines peuvent demander la configuration d’une application côté cible ou rester hors périmètre.
Les Orders exigent la même discipline. L’historique doit rester lisible et utile, mais la configuration active des paiements, le fonctionnement du checkout, la configuration de l’expédition, les paramètres fiscaux, les notifications et le processus de traitement des commandes appartiennent à la configuration de la boutique cible.
Contenus, pages, Blog Posts, redirections et sens des chemins
La continuité des contenus et URL BigCommerce fait partie de la traduction du modèle de données, car les pages, Blog Posts, redirections, chemins de produits, chemins de catégories et destinations de vitrines influencent la confiance des clients et la continuité dans les moteurs de recherche. Une redirection peut fonctionner techniquement tout en dégradant le parcours si elle envoie une ancienne URL produit, catégorie ou contenu vers une destination trop générale ou sans rapport.
Les CMS Pages et Blog Posts doivent être examinés selon leur fonction. Certaines pages soutiennent la confiance, les politiques, l’explication de la marque, l’aide à l’achat, le trafic de campagne ou la découverte SEO. Certains Blog Posts peuvent porter une valeur de recherche longue traîne ou d’éducation produit. Certaines pages de la source ne méritent plus d’être migrées mais nécessitent tout de même une redirection vers une destination utile.
| Type de contenu ou chemin | Décision de migration |
|---|---|
| URL produit | La préserver ou la rediriger vers le produit correspondant le plus proche. |
| URL de catégorie | Préserver autant que possible l’intention de découverte. |
| CMS Page | Migrer, reconstruire, consolider, rediriger ou retirer. |
| Blog Post | Préserver s’il apporte du trafic, de l’éducation, de la confiance ou de la valeur aux liens internes. |
| Page de campagne | Décider si la campagne reste active, nécessite une redirection ou doit être retirée. |
| Chemin propre à une vitrine | Confirmer la bonne destination de vitrine ou de canal. |
L’identité du chemin appartient au modèle de données BigCommerce parce que les redirections relient l’intention de la source à une destination exploitable. De bonnes relations de redirection préservent les parcours clients au lieu d’être de simples associations techniques isolées.
Applications, intégrations et données de systèmes externes
Les migrations BigCommerce croisent souvent des systèmes externes. ERP, PIM, CRM, comptabilité, fiscalité, expédition, abonnements, personnalisation, recherche, avis, fidélité, entrepôt, marketplace ou marketing peuvent dépendre d’identifiants et de champs personnalisés qui ne sont pas visibles lors d’une revue ordinaire de la vitrine.
La question du modèle de données consiste à déterminer si BigCommerce doit posséder la donnée, l’afficher, la transmettre à une application, la préserver pour la réconciliation ou l’ignorer parce que le processus sera reconstruit. Ces résultats sont différents.
| Dépendance externe | Point de vigilance pour la migration BigCommerce |
|---|---|
| ERP ou comptabilité | Identifiants de produits, SKU, références de commandes, identifiants clients et contexte des taxes/remises. |
| PIM | Propriété des attributs, textes produit, images, variantes et champs personnalisés. |
| CRM ou marketing | Identité client, consentement, segmentation, historique des commandes et attributs personnalisés. |
| Application d’abonnement ou de fidélité | Enregistrements détenus par l’application, fonctionnement et attentes de continuité. |
| Application de recherche ou merchandising | Attributs de filtre, champs personnalisés, tags produit, règles et fonctionnement du classement. |
| Système d’expédition ou fiscal | Identifiants externes et fonctionnement proche du checkout. |
Si les données disposent déjà d’une destination BigCommerce adaptée, un mapping ou filtrage direct peut suffire. Si elles sont détenues par une application, contrôlées depuis l’extérieur ou dépendent d’une relation non native, il faut définir l’application cible, le système externe ou la restructuration des données avant de finaliser la carte source-cible.
Le périmètre des données BigCommerce doit être jugé selon leur usage métier
Le périmètre d’une migration BigCommerce doit être évalué selon l’usage attendu après migration. Products, Customers, Orders, Categories, CMS Pages, Blog Posts et redirections peuvent correspondre à des destinations d’enregistrements ordinaires, mais leur signification peut encore dépendre de la structure des choix de produits, des arborescences de Categories, affectations de canaux, groupes de clients, listes de prix, champs personnalisés, metafields, applications et identifiants externes.
Une carte de représentation utile distingue les résultats suivants :
| Résultat du mapping | Signification dans BigCommerce |
|---|---|
| Enregistrement et relation natifs | Le sens de la source correspond à un Product, une variante, un modifier, une Category, un Customer, un Order, un contenu, une redirection ou une autre relation prise en charge dans BigCommerce. |
| Configuration de vitrine ou de canal | L’enregistrement existe, mais son usage dépend des affectations de canaux, arborescences de Categories, sites, thèmes, menus, contexte tarifaire ou autre configuration de la boutique cible. |
| Propriété par une application ou intégration | La donnée reste détenue par un ERP, PIM, CRM, outil d’abonnement, de fidélité, de recherche ou autre système connecté et nécessite un identifiant stable entre systèmes. |
| Transformation de données conçue pour le besoin | La structure source doit être remodelée car sa signification ne correspond pas à l’enregistrement ou à la relation disponible sur la cible. |
| Exclure, archiver ou repenser | La valeur est obsolète, dupliquée, liée à une logique retirée ou n’a plus de propriétaire métier après migration. |
Ce modèle maintient la migration centrée sur la traduction du sens et évite de confondre un grand nombre d’enregistrements avec un modèle BigCommerce utilisable. Le meilleur périmètre explique ce que devient chaque sens important de la source, quelle relation le préserve, qui en devient responsable après le lancement et ce qui doit volontairement rester en dehors de la boutique cible.
Conclusion
Les différences du modèle de données BigCommerce sont importantes parce que la plateforme donne aux enregistrements migrés une signification commerciale structurée. Produits, variantes, modifiers, catégories, groupes de clients, listes de prix, canaux, clients, commandes, CMS Pages, Blog Posts, redirections, champs personnalisés, metafields, applications et identifiants externes doivent être examinés selon l’usage qu’en fera l’entreprise après le lancement.
Le meilleur plan de migration préserve non seulement la présence des données, mais aussi leur fonctionnement. Il sépare les enregistrements natifs de la configuration des canaux et vitrines, des valeurs détenues par des intégrations, des restructurations de données et des attentes volontairement exclues avant de finaliser le modèle de données cible.
Questions fréquentes
Pourquoi les options produit BigCommerce sont-elles importantes pendant la migration ?
Les options produit peuvent représenter des significations métier différentes. Certains choix doivent devenir des variantes, d’autres se rapprochent de modifiers, certains peuvent devenir des champs personnalisés et d’autres dépendent d’applications ou d’une logique personnalisée. Si le sens est mal interprété, les pages produit peuvent sembler complètes alors que le stock, les prix, le traitement des commandes ou la sélection par le client fonctionnent incorrectement.
Les champs personnalisés et metafields BigCommerce suffisent-ils pour toutes les données personnalisées de la source ?
Non. Ils peuvent préserver certaines données supplémentaires, mais ils ne reproduisent pas automatiquement le fonctionnement de la plateforme source. Les enregistrements détenus par une application, identifiants de systèmes externes, logiques produit sur mesure et transformations personnalisées peuvent nécessiter une restructuration des données, la migration d’une application ou une configuration de la boutique cible.
Les catégories BigCommerce préservent-elles automatiquement la navigation de la source ?
Pas toujours. Les catégories, arborescences, menus, pages d’atterrissage SEO et contextes de vitrines/canaux doivent être examinés séparément. Une Category peut exister alors que le parcours permettant à l’acheteur de la découvrir dépend encore de la navigation cible, du contexte du canal, du contenu ou des relations de redirection.
Comment les listes de prix et groupes de clients doivent-ils influencer la planification ?
Ils doivent être traités comme des relations, et non comme des champs isolés. Un prix produit peut sembler correct alors qu’un groupe de clients, une liste de prix, une règle de quantité ou une condition de vitrine nécessite encore une vérification.
Comment représenter dans BigCommerce les données détenues par des applications ou intégrations ?
Identifiez d’abord le système de référence qui continuera à les détenir. Ne conservez un champ, metafield ou identifiant externe BigCommerce que si l’application ou l’intégration cible l’utilisera. Les contrats d’abonnement, soldes de fidélité, règles de recherche, états marketplace et autres enregistrements similaires doivent suivre le chemin de données pris en charge par l’application de destination, plutôt que d’être aplatis dans des champs génériques Product ou Customer.
Comment préserver le sens du catalogue propre à chaque canal dans BigCommerce ?
Identifiez avant le mapping quels Products, prix, Categories, contenus et règles de visibilité appartiennent à chaque canal. Les enregistrements partagés peuvent rester communs, mais les différences détenues par les canaux ne doivent pas être aplaties lorsqu’elles influencent ce que voient les acheteurs ou ce que gèrent les équipes.