Bagisto ne traite pas un catalogue e-commerce comme une simple collection à plat de Products et de champs personnalisés. Son architecture fondée sur Laravel distingue les types de produits, attributs produits, familles d’attributs, Categories, canaux, langues, devises, sources de stock, groupes de Customers, Orders, pages CMS, données marketing, packages, API et couches e-commerce optionnelles telles qu’une marketplace ou des fonctions B2B. Un champ de la boutique source ne devient utile dans Bagisto que lorsqu’il rejoint la couche qui porte réellement son sens commercial.
Cette distinction modifie le périmètre de migration. Une valeur de taille peut être un contenu descriptif, un attribut filtrable ou une composante de la relation d’un Product configurable. Une quantité peut appartenir à une source de stock précise plutôt qu’au Product dans son ensemble. Une vitrine peut correspondre à un canal Bagisto disposant de sa propre Category racine, de ses langues, devises, thème et affectations de stock. Un compte d’entreprise ou un vendeur peut dépendre d’un package Bagisto installé plutôt que du modèle Customer natif.
La question centrale n’est donc pas de savoir si Bagisto possède un champ portant un libellé similaire. Il faut déterminer si la boutique cible représente la même relation : à quoi appartient l’enregistrement, ce qu’il contrôle et quels autres enregistrements doivent rester reliés pour que les données migrées conservent leur sens métier.
Bagisto représente les enregistrements à travers plusieurs couches e-commerce
Bagisto associe des entités e-commerce natives à de la configuration et à des structures appartenant aux extensions. Deux valeurs voisines dans un export source peuvent relever de couches cibles différentes. L’identité d’un Product appartient au catalogue. Les champs disponibles pour ce Product sont gouvernés par sa famille d’attributs. Le périmètre d’une vitrine appartient aux canaux. Le stock appartient aux sources de stock. La segmentation des Customers appartient aux groupes de Customers ou à une couche B2B ou marketplace installée. La présentation peut appartenir aux pages CMS, au thème ou à une vitrine headless.
| Sens côté source | Propriétaire probable dans Bagisto | Conséquence pour la représentation |
|---|---|---|
| Article vendable | Product avec un type de produit défini | Le type de produit détermine les enregistrements enfants, choix d’achat, traitement logistique et fonctionnement des prix. |
| Caractéristique produit | Attribut affecté par une famille d’attributs | Une valeur texte visible n’est pas automatiquement filtrable, comparable ou réutilisable. |
| Boutique, marché ou domaine | Canal avec langue, devise, Category racine, thème et relations de stock | Le périmètre de la vitrine doit rester attaché au bon catalogue et au bon contexte de localisation. |
| Quantité d’un entrepôt | Affectation et quantité d’une source de stock | Un stock global peut perdre la propriété liée au lieu. |
| Segment de clients | Groupe de Customers ou structure de compte appartenant à un package | Le sens du prix ou de l’accès peut ne pas tenir dans un seul champ Customer. |
| Vente historique | Order avec lignes, totaux, adresses, factures, expéditions, remboursements et transactions | Le nombre d’Orders ne suffit pas à préserver l’historique commercial. |
| Fonctionnement e-commerce personnalisé | Package Bagisto, module personnalisé, enregistrement piloté par API ou système externe | Un simple mapping vers des champs natifs ne suffit pas lorsqu’un autre composant possède la relation. |
Cette propriété par couches explique pourquoi le mapping individuel de champs n’est pas fiable à lui seul. Une même valeur source peut exiger des destinations Bagisto différentes selon qu’elle influence le choix d’un Product, la gestion du catalogue, la localisation, les stocks, le traitement des comptes, les rapports ou la continuité d’une intégration.
Les types de produits définissent les relations commerciales
Bagisto prend en charge plusieurs types de produits, notamment les Products simples, configurables, virtuels, bundle, groupés, téléchargeables et orientés réservation. Le type n’est pas un simple libellé d’administration. Il définit ce qui est vendu, l’existence éventuelle de Products enfants ou liés, les champs pertinents, l’interprétation du prix et du stock ainsi que les choix proposés à l’acheteur.
Un Product parent avec des enfants couleur et taille peut devenir un Product configurable dont les variations portent leurs propres SKU, prix, quantités, images ou visibilité. Un kit ne correspond à un bundle que si ses composants et règles de sélection correspondent à la relation bundle de Bagisto. Un Product groupé représente un ensemble de Products vendables liés, et non un unique SKU qui porte son propre stock. Un Product téléchargeable nécessite des relations avec ses fichiers et droits d’accès. Un Product de réservation ajoute une notion de disponibilité et de calendrier absente d’une ligne Product ordinaire.
| Structure source | Relation Bagisto à distinguer | Implication pour le périmètre |
|---|---|---|
| Product parent avec SKU enfants | Product configurable et variations | Le contenu parent et les valeurs commerciales des enfants ne doivent pas être fusionnés. |
| Kit de composants optionnels | Product bundle et sélections du bundle | Le choix des composants, les quantités et le fonctionnement du prix peuvent nécessiter une transformation structurelle. |
| Ensemble merchandising d’articles indépendants | Product groupé et Products liés | Chaque Product lié reste vendu et géré en stock indépendamment. |
| Service non physique | Product virtuel ou structure de service appartenant à un package | L’expédition et le traitement logistique diffèrent des Products physiques. |
| Produit numérique | Product téléchargeable, fichiers, liens et règles d’accès | La relation avec le fichier est distincte du texte du Product. |
| Service ou location planifié | Product de réservation ou structure d’un package personnalisé | Les relations de disponibilité et de ressources ne peuvent pas être réduites à de simples options. |
Le choix du type de produit influence également les Orders historiques. Une ligne d’Order doit rester compréhensible même si la boutique cible représente le Product différemment de la boutique source. Conserver uniquement le nom du Product source sans préserver la variation choisie, la sélection du bundle, le téléchargement ou le contexte de réservation produirait un historique techniquement présent mais sémantiquement incomplet.
Les attributs et familles d’attributs gouvernent le sens du catalogue
Les attributs Bagisto définissent des informations structurées sur les Products. Les familles d’attributs regroupent les attributs disponibles pour une classe de Products. Les champs personnalisés d’un catalogue source ne doivent donc pas être copiés indistinctement dans une forme universelle de Product Bagisto.
Un champ utilisé pour filtrer doit être traité différemment d’un champ qui sert uniquement de référence interne. Une valeur créant un choix configurable doit être distinguée d’une caractéristique descriptive. Un titre localisé, un prix, un SKU unique, un indicateur booléen de vitrine et une spécification technique à choix multiples n’ont ni le même type de saisie, ni les mêmes règles de validation et d’indexation, ni le même fonctionnement par canal ou par langue.
La conception des familles d’attributs convertit ainsi les conventions du catalogue source en schéma gouverné de la boutique cible. Un marchand qui vend des vêtements, des machines, des manuels téléchargeables et des services réservables peut avoir besoin de familles distinctes, car chaque groupe de Products exige des attributs et relations commerciales différents.
| Fonction du champ source | Interprétation dans Bagisto | Ce qui doit rester vrai |
|---|---|---|
| L’acheteur choisit la valeur | Attribut configurable ou choix propre au type de produit | La valeur sélectionnée identifie la bonne variation ou le bon résultat vendable. |
| Le client filtre selon la valeur | Attribut Product filtrable | Les valeurs restent suffisamment normalisées pour produire des filtres utiles. |
| Les équipes comparent les Products selon la valeur | Attribut comparable ou structuré | Des faits équivalents ne restent pas enfouis dans les descriptions. |
| Le champ n’existe que pour une classe de Products | Attribut affecté à une famille précise | Les Products non concernés ne reçoivent pas un schéma universel inutilement volumineux. |
| La valeur varie par langue ou canal | Donnée localisable ou spécifique au canal lorsque Bagisto le permet | Le bon contexte de vitrine reçoit la bonne valeur. |
| La valeur est une métadonnée interne d’intégration | Attribut personnalisé, enregistrement de package ou identifiant externe | Les identifiants opérationnels ne sont ni exposés ni réutilisés comme contenu de vitrine. |
Cette séparation évite une distorsion fréquente : considérer toute option, spécification, balise, donnée d’application ou code interne de la source comme un même type d’attribut Product. Bagisto peut stocker des données Product riches, mais cette flexibilité n’apporte de valeur que si chaque information reçoit la bonne famille et le bon fonctionnement.
Categories, canaux, langues et sources de stock définissent le périmètre de la vitrine
Les Categories Bagisto organisent les Products, mais les relations de canal déterminent le catalogue et le contexte de localisation utilisés par une vitrine. Un canal peut porter un nom d’hôte, une Category racine, des langues, devises, un thème et des affectations de sources de stock. Une boutique source, un catalogue régional, un site linguistique ou la vitrine d’une unité commerciale peuvent donc se traduire par davantage qu’une simple arborescence de Categories.
Les Categories peuvent représenter la navigation client, des pages merchandising, une classification interne ou une structure historique héritée. Bagisto doit recevoir les relations encore utiles, pas simplement tous les anciens libellés de Category. La Category racine affectée à un canal est particulièrement importante puisqu’elle définit le sommet de la hiérarchie du catalogue de cette vitrine.
Les sources de stock ajoutent une autre dimension de propriété. Le stock d’un Product peut être réparti entre plusieurs lieux. La quantité source doit donc être interprétée avec le contexte d’entrepôt, de succursale, de fournisseur, de retrait ou de traitement logistique. Additionner tous les lieux en un chiffre peut préserver le total tout en détruisant la disponibilité par emplacement.
| Couche de périmètre | Relation portée dans Bagisto | Ambiguïté fréquente côté source |
|---|---|---|
| Category | Hiérarchie parent-enfant, affectations Products, contenu localisé et sens des URL | Les Categories source peuvent mélanger navigation, SEO et classement interne. |
| Canal | Domaine, Category racine, langues, devises, thème et contexte des sources de stock | Une « boutique » source peut en réalité représenter un marché, une langue, une marque ou une unité commerciale. |
| Langue | Valeurs traduites des Products, Categories et contenus | Les langues peuvent être représentées par des enregistrements dupliqués ou des champs indépendants plutôt que par des traductions liées. |
| Devise | Affichage et contexte commercial de la vitrine | La devise d’un Order historique doit rester distincte de la configuration actuelle du canal. |
| Source de stock | Stock appartenant à un emplacement | Une seule quantité Product peut masquer plusieurs entrepôts ou réserves de stock. |
Un Product migré peut exister correctement dans Bagisto tout en restant invisible ou commercialement incorrect s’il est rattaché à la mauvaise Category racine, absent du canal prévu, dépourvu de valeurs localisées ou affecté à la mauvaise source de stock. Ce sont des erreurs de relations de données même lorsque tous les enregistrements Products sont présents.
Customers, groupes, vendeurs de marketplace et comptes B2B sont des identités différentes
Les Customers natifs de Bagisto comprennent l’identité, les coordonnées, les adresses et les relations de groupe. Les groupes de Customers peuvent influencer le traitement commercial, notamment les prix de groupe et l’éligibilité aux règles. En revanche, les vendeurs de marketplace, entreprises B2B, utilisateurs d’entreprise, rôles d’approbation, listes de réquisition, devis et bons de commande peuvent appartenir à des packages Bagisto optionnels plutôt qu’au Customer natif.
Une étiquette Customer source comme wholesale, dealer, distributor, employee, tax-exempt, approved buyer ou marketplace seller doit être interprétée selon sa fonction. Certaines valeurs appartiennent à un groupe Customer natif. D’autres représentent un compte d’entreprise, une organisation vendeuse, un rôle d’autorisation, une relation de crédit ou une classification CRM externe. Les aplatir dans un champ texte conserve le libellé mais supprime la relation qui lui donnait une fonction opérationnelle.
| Identité source | Question de destination dans Bagisto | Relation à préserver |
|---|---|---|
| Acheteur individuel | Customer natif et adresses | Identité, coordonnées, association au compte et historique d’Orders. |
| Segment commercial | Groupe de Customers ou relation de prix | Le segment reste distinct d’étiquettes arbitraires. |
| Acheteur d’entreprise | Entreprise B2B et structure d’utilisateurs d’entreprise lorsqu’elle existe | Les utilisateurs restent reliés à la bonne entreprise, au bon rôle et au bon contexte commercial. |
| Vendeur marketplace | Enregistrement vendeur appartenant au package marketplace | Products du vendeur, Orders, commissions, paiements et utilisateurs restent reliés. |
| Compte CRM ou ERP externe | Customer plus identifiant externe | La boutique cible peut réconcilier le Customer avec le compte de référence du système externe. |
La bonne destination dépend de l’installation Bagisto réellement utilisée. Bagisto natif, Multi Vendor Marketplace, B2B Marketplace, B2B eCommerce et les packages multi-tenant ne proposent pas un schéma Customer universel. Leurs enregistrements doivent être considérés comme des domaines de propriété distincts, et non comme des structures interchangeables.
Les Orders préservent le contexte commercial historique
Un Order Bagisto est lié à l’identité du Customer ou de l’acheteur invité, aux adresses, lignes d’Order, configurations Products choisies, prix, remises, taxes, expédition, libellés de paiement, statuts, factures, expéditions, remboursements et transactions. Ces enregistrements liés expliquent ce qui s’est produit ; l’en-tête de l’Order ne suffit pas.
Les Orders historiques contiennent aussi des instantanés. Les noms Products, prix, taxes, adresses et options sélectionnées peuvent refléter l’état au moment de l’achat, même si le Product ou le Customer actuel a changé depuis. Remplacer ces instantanés par les valeurs actuelles du catalogue altérerait l’historique. Inversement, importer seulement les totaux sans lignes ni contexte de statut rendrait le service client et les rapports peu fiables.
| Relation de l’Order | Sens historique |
|---|---|
| Ligne d’Order | Identité Product, SKU, quantité, prix, configuration choisie et instantané descriptif. |
| Adresse | Données de facturation et d’expédition au moment de l’achat. |
| Facture | Montant reconnu ou facturé, qui peut différer de l’étape actuelle du cycle de l’Order. |
| Expédition | Enregistrement de traitement logistique et quantités expédiées. |
| Remboursement | Valeur annulée et lignes ou montants concernés. |
| Transaction | Référence du système de paiement et indication de statut lorsqu’elles sont disponibles. |
| Statut de l’Order | Sens du cycle de vie source pouvant nécessiter un équivalent cible choisi délibérément. |
Le périmètre doit préserver le niveau de détail des Orders nécessaire au service client, à l’historique du compte, aux rapports et à la réconciliation avec les systèmes externes. Le fonctionnement actuel du paiement, de l’expédition, des taxes et des notifications relève de la configuration de la boutique cible ; les libellés et montants historiques appartiennent au contexte de l’Order migré.
CMS, URL, données marketing et recherche ont des propriétaires distincts
Bagisto comprend des pages CMS, réécritures d’URL, sitemaps, termes de recherche, synonymes, inscriptions à la newsletter, avis, règles panier et règles catalogue. Ces enregistrements ne doivent pas être fusionnés dans une catégorie générique « contenu », car leurs fonctions sont différentes.
Les pages CMS portent le contenu de page et l’identité de l’URL. Les métadonnées Product et Category appartiennent aux enregistrements du catalogue. Les réécritures d’URL préservent les relations de routage. Les termes et synonymes influencent la découverte. Les avis appartiennent aux Customers et Products. Les inscriptions à la newsletter représentent le consentement et les audiences. Les règles panier et catalogue encodent des conditions et actions, pas de simples valeurs de remise.
| Élément source | Propriétaire dans Bagisto | Limite de représentation |
|---|---|---|
| Page d’information | Page CMS | Contenu, route, métadonnées et relation de navigation sont des sujets distincts. |
| Métadonnées Product ou Category | Enregistrement du catalogue | Les champs SEO doivent rester attachés à la bonne entité et à la bonne langue. |
| Ancienne URL ou redirection | Réécriture d’URL ou structure de redirection | L’ancienne route et sa destination doivent rester explicites. |
| Synonyme de recherche | Enregistrement de synonyme | Une paire de mots-clés n’est pas du contenu de page ordinaire. |
| Avis Product | Relation d’avis Product-Customer | Note, auteur, statut et association au Product sont importants. |
| Règle de promotion | Règle panier ou catalogue | Conditions, actions, dates, canaux et groupes de Customers forment une structure de règle unique. |
Les données marketing sont particulièrement sensibles à la compression sémantique. Un code coupon source sans ses conditions d’éligibilité, dates, périmètre Customer, historique d’utilisation ni action de remise n’est pas la même promotion dans Bagisto. Lorsqu’aucune structure de règle équivalente n’existe, l’enregistrement doit être conservé comme historique ou reconçu dans la configuration de la boutique cible plutôt que forcé dans un mapping direct trompeur.
Packages, API, vitrines headless et tables personnalisées étendent le modèle
Bagisto est conçu pour être étendu par des packages Laravel, types de Products personnalisés, modules, API REST ou GraphQL, webhooks ou code d’intégration et vitrines headless. Ces capacités créent des données qui peuvent ne pas apparaître dans les tables Products, Customers ou Orders natives.
Un package peut introduire ses propres entités, tables de liaison, configurations, statuts, autorisations et identifiants externes. Une vitrine headless peut consommer les données Bagisto natives tout en conservant ailleurs le contenu de présentation ou les index de recherche. Un ERP, PIM, WMS, CRM, connecteur marketplace ou application mobile peut traiter Bagisto comme un participant parmi d’autres d’un système de données plus large.
| Propriétaire des données | Exemples | Implication pour la migration |
|---|---|---|
| Noyau Bagisto | Products, Categories, Customers, Orders, attributs, canaux, sources de stock | Mapper selon le sens des entités et relations natives. |
| Package installé | Vendeurs marketplace, entreprises B2B, ressources de réservation, abonnements, types de Products personnalisés | Examiner le schéma du package et préserver ses liens avec les enregistrements natifs. |
| Module Laravel personnalisé | Tables sur mesure, champs, enregistrements de processus ou historique d’événements | Définir explicitement une destination ou une décision d’archivage pour chaque relation encore active. |
| Couche de présentation headless | Composition de pages, index de recherche, contenu propre au frontend, identifiants en cache | Ne pas supposer que la présentation de la vitrine est stockée dans le noyau Bagisto. |
| Système externe | Identifiant article ERP, identifiant compte CRM, code entrepôt, identifiant de listing marketplace | Préserver les identifiants nécessaires pour reconnecter la boutique cible au système de référence. |
La question décisive est la propriété. Une valeur stockée à proximité d’un Product n’appartient pas automatiquement au Product. Elle peut appartenir à un package, à un système externe ou à une couche de présentation. Le périmètre n’est complet que lorsque ces relations sont nommées et qu’une destination est définie pour les enregistrements encore nécessaires aux opérations.
Décisions de représentation dans Bagisto selon le sens métier
La décision finale sur le modèle de données doit relier chaque structure source à son propriétaire dans Bagisto et à la conséquence d’une attribution incorrecte.
| Structure source | Bonne question de représentation | Conséquence d’une mauvaise hypothèse |
|---|---|---|
| Options avec SKU enfants et stock | S’agit-il d’une relation de Product configurable ? | L’identité de la variante, le stock ou le prix devient incorrect. |
| Spécifications réutilisées dans une classe de Products | Appartiennent-elles aux attributs et à une famille d’attributs ? | Le filtrage et la gouvernance du catalogue restent incohérents. |
| Boutiques régionales séparées | S’agit-il de canaux, langues, devises ou installations indépendantes ? | Products et contenus apparaissent dans le mauvais contexte de vitrine. |
| Quantités par entrepôt | Quelle source de stock possède chaque quantité ? | Le stock total peut être juste alors que la disponibilité par lieu est fausse. |
| Customers grossistes ou entreprises | Le sens correspond-il à un groupe, une entreprise B2B, un utilisateur d’entreprise ou un compte externe ? | Les prix, accès et relations de compte sont aplatis. |
| Products et Orders appartenant à des vendeurs | Un package marketplace installé possède-t-il la relation vendeur ? | La propriété vendeur, les commissions et le contexte des paiements disparaissent. |
| Champs personnalisés provenant d’un package | Quelle entité du package est liée à quel enregistrement natif ? | Les données sont copiées sans le processus qui les utilise. |
Une migration vers Bagisto devient cohérente lorsque Products, attributs, canaux, stocks, Customers, Orders, contenus, packages et identifiants externes sont représentés comme des structures reliées. Cela préserve davantage que la présence des données : cela conserve le sens commercial qui permet à la boutique cible d’utiliser réellement les enregistrements migrés.
Conclusion
Une migration vers Bagisto exige de traduire les relations entre les couches du catalogue, de la vitrine, des stocks, des Customers, des Orders, des contenus, des extensions et des intégrations. Les types de produits définissent les structures vendables. Les familles d’attributs gouvernent l’information Product. Les canaux relient catalogue, localisation et contexte de stock. Les groupes Customer et les packages B2B ou marketplace optionnels définissent différentes relations de compte. Les Orders dépendent de leurs lignes, instantanés, factures, expéditions, remboursements et transactions. Les packages et systèmes externes peuvent posséder des données absentes du noyau Bagisto.
Les décisions de périmètre les plus solides identifient le propriétaire de chaque valeur commercialement importante et préservent les liens entre enregistrements. Lorsque les données source sont mappées uniquement d’après les noms de champs, la flexibilité de Bagisto peut masquer une perte de sens. Lorsqu’elles sont représentées selon leur fonction et leurs relations, la boutique cible reçoit un catalogue et un historique commercial qui restent compréhensibles et exploitables.
Questions fréquentes
En quoi les Products configurables de Bagisto diffèrent-ils d’options Product ordinaires ?
Un Product configurable relie un Product parent à des variations vendables créées à partir d’attributs choisis. Les variations peuvent porter leurs propres SKU, prix, quantités, images ou visibilité. Une option texte qui n’identifie pas une variation gérée indépendamment ne doit pas être transformée automatiquement en cette même structure.
Pourquoi les familles d’attributs sont-elles importantes pendant une migration vers Bagisto ?
Elles déterminent les attributs appartenant à une classe de Products. Elles évitent d’attribuer à chaque Product un ensemble de champs surdimensionné et aident à préserver les différences entre caractéristiques vestimentaires, données d’équipements, contenus téléchargeables, informations de réservation et autres données propres à chaque type de Product.
Une boutique source doit-elle toujours devenir un canal Bagisto ?
Non. Une « boutique » source peut représenter un domaine, une langue, une devise, une marque, une région, un catalogue ou une unité commerciale indépendante. Le bon modèle peut utiliser un canal avec plusieurs langues, plusieurs canaux ou plusieurs installations selon les relations qui doivent rester indépendantes.
Comment représenter le stock par entrepôt dans Bagisto ?
Le stock doit conserver la propriété de sa source de stock lorsque le lieu est important. Fusionner toutes les quantités dans un total Product peut supprimer le contexte d’entrepôt, de retrait, de fournisseur ou de traitement logistique même si le total reste correct.
Les vendeurs marketplace et entreprises B2B sont-ils de simples Customers Bagisto ?
Pas nécessairement. Les relations vendeur et entreprise peuvent appartenir aux packages marketplace ou B2B installés. Ces structures peuvent inclure des utilisateurs d’organisation, rôles, catalogues, commissions, paiements, crédits, devis ou bons de commande qui ne tiennent pas dans l’enregistrement Customer natif.
Que faut-il faire des données appartenant à un package ou à un module Bagisto personnalisé ?
Identifiez le package ou module, les enregistrements natifs qu’il étend et le processus métier qui consomme ses données. Les relations encore actives ont besoin d’une destination cible explicite et d’identifiants préservés ; les données obsolètes peuvent être archivées ou exclues sans prétendre qu’il s’agit de champs Products ou Customers natifs.