Migrer vers Storeden exige davantage que placer des enregistrements dans une nouvelle administration. Storeden fonctionne comme un environnement e-commerce cloud capable de relier gestion du catalogue, stock, traitement des Orders, paiements, thèmes, applications, ventes marketplace, logistique, ressources API et données de l’écosystème TeamSystem. Ce modèle opérationnel change la manière dont les données migrées doivent être interprétées.
Une boutique source peut contenir Products, Categories, Customers, Orders, données SEO, champs d’applications, identifiants marketplace ou références ERP qui semblaient complets dans la plateforme précédente. Après migration, ces mêmes valeurs doivent soutenir la structure du catalogue Storeden, la préparation aux canaux de vente, les processus Order, les intégrations et le suivi métier. La question du modèle de données ne consiste donc pas seulement à savoir si les enregistrements arrivent. Il faut vérifier qu’ils conservent le bon sens commercial dans Storeden.
Le sens des données Storeden en un coup d’œil
La planification doit séparer le transfert d’enregistrements de leur interprétation opérationnelle. Une valeur qui apparaît dans la source comme option Product, note Order, libellé de paiement, mode de livraison, groupe Customer, champ personnalisé ou référence marketplace peut nécessiter un traitement différent dans Storeden.
| Domaine de données | Sens à préserver | Question de responsabilité dans Storeden | Pourquoi la différence compte |
|---|---|---|---|
| Products | Identité vendable du catalogue | Nom, description, images, prix, stock, placement en Category, visibilité et préparation aux canaux | Un Product peut exister tout en restant difficile à vendre, trouver, gérer ou publier correctement. |
| Variantes et options | Choix du client et signification opérationnelle du SKU | Choix assimilables à des variantes, valeurs d’attribut, relations SKU, incidences sur le stock, logique d’image et écarts de prix | La structure des options influence sélection, traitement, stock et flux marketplace. |
| Categories et navigation | Découverte Product et hiérarchie de merchandising | Regroupement Category, logique de menu, placement Product, filtres attendus et parcours SEO | Un catalogue peut sembler complet dans le back-office tout en dégradant la découverte client. |
| Stock | Disponibilité et confiance dans le traitement | Quantités, références SKU, disponibilité multicanale, dépendances logistiques et sources de stock connectées à TeamSystem | Le sens du stock peut dépendre de plusieurs canaux ou systèmes. |
| Customers | Identité de compte, acheteur et service | Profil, historique de facturation/livraison, coordonnées, contexte entreprise et références externes | Les données Customer doivent soutenir service, recherche Order, continuité de compte et marketing. |
| Orders | Contexte commercial historique | Products achetés, relation Customer, totaux, taxes, libellés de paiement, détails de livraison, statuts et origine marketplace | L’historique n’est utile que si les équipes peuvent le comprendre et agir à partir de lui. |
| Paiements et livraison | Libellés historiques par rapport à la configuration active | Libellés Order préservés comparés à la configuration actuelle des paiements, transporteurs, logistique et taxes | L’historique migré ne configure pas le futur processus de commande. |
| Données marketplace | Contexte de vente propre au canal | IDs de listing, Categories marketplace, prix par canal, règles de disponibilité et origine des Orders | La continuité marketplace peut exiger plus qu’une migration Product/Order ordinaire. |
| Données d’applications et API | Responsabilité des processus et identité des intégrations | Données détenues par applications, références API, IDs externes, déclencheurs d’automatisation et connexions TeamSystem | Les processus connectés peuvent exiger configuration ou conception cible distincte même si les enregistrements standard migrent. |
| SEO et contenu | Découverte et continuité | URLs, redirections, métadonnées, descriptions Product, contenu Category, noms d’images et pages contrôlées par le thème | Recherche et continuité utilisateur dépendent de présentation et routage, pas seulement des enregistrements importés. |
Les données Product deviennent un catalogue Storeden géré
Les fiches Product sont le centre visible d’une migration Storeden, mais leur signification dépasse la ligne Product. Une fiche source peut inclure titres, descriptions, codes, SKU, marques, fournisseurs, classes fiscales, prix normaux et promotionnels, visibilité, Categories, images, relations de variantes, Products associés, champs personnalisés, attributs marketplace et clés externes de stock.
Storeden doit utiliser ces valeurs pour construire un catalogue administrable de manière centralisée et distribuable sur les canaux de vente prévus. Trois couches de responsabilité doivent rester distinctes : le Product commercial vu par le client, l’article opérationnel géré par les équipes et la représentation de canal ou de système externe utilisée par marketplaces, services de stock ou systèmes comptables.
| Élément source | Interprétation Storeden | Conséquence relationnelle |
|---|---|---|
| Titre et descriptions Product | Contenu de catalogue destiné au client | Langue, mise en forme et identité Product doivent rester liées au même article commercial. |
| SKU ou code Product | Identité opérationnelle ou inter-systèmes | Variantes, lignes d’Order, mises à jour de stock et intégrations doivent référencer l’article vendable prévu. |
| Images | Relation média Product ou variante | Image principale, galerie et images propres aux variantes ne doivent pas être aplaties en liste de fichiers non ordonnée. |
| Prix normal et promotionnel | Valeur commerciale pouvant dépendre du temps ou du canal | Les prix historiques des Orders restent des éléments de référence ; la responsabilité des prix futurs appartient au processus de tarification cible. |
| Affectation Category | Organisation du catalogue | L’appartenance à une Category ne doit pas être confondue avec le placement dans les menus ou la taxonomie marketplace. |
| Visibilité ou statut | État de publication | Products actifs, masqués, brouillons ou retirés doivent recevoir un sens cible intentionnel. |
| Champ personnalisé | Donnée descriptive, opérationnelle, de canal ou d’intégration | La destination dépend de la personne ou du système qui lit ou met à jour la valeur après migration. |
Un Product n’est donc complet que lorsque son identité, ses relations de variantes, Categories, médias, contexte de prix et clés externes décrivent le même objet vendable.
Variantes, options et attributs relèvent de responsabilités différentes
Taille, couleur, matière, quantité de lot, texte de personnalisation, choix d’un bundle, intervalle d’abonnement et préférence de livraison peuvent tous apparaître comme des « options » dans un export source sans représenter le même type d’information. La traduction vers Storeden doit distinguer une variante vendable d’une information descriptive Product, d’une saisie de ligne Order, d’une logique applicative et d’un attribut propre à un canal.
La distinction compte parce qu’une vraie variante peut posséder son SKU, son stock, son prix, son image, son poids, son traitement fiscal ou son identité marketplace. Un attribut descriptif peut servir au filtrage ou à la compréhension sans créer un article vendable distinct. Une personnalisation peut appartenir à la ligne Order plutôt qu’au Product maître. Un bundle peut être calculé par une application ou un système de stock externe.
| Schéma source | Sens cible | Relation qui doit rester claire |
|---|---|---|
| Taille ou couleur avec SKU et stock | Variante vendable | Product parent, valeurs choisies, stock, prix, image et ligne Order doivent viser la même variante. |
| Matière ou propriété technique | Attribut descriptif ou valeur de filtre | Conserver le sens structuré sans créer de fausses variantes porteuses de stock. |
| Texte de personnalisation | Saisie du client liée à un achat | Conserver la valeur sur la ligne Order pertinente lorsqu’elle doit rester visible historiquement. |
| Bundle ou kit | Relation commerciale ou de stock composite | Décider si Storeden, une application ou un système externe possède la logique des composants. |
| Attribut marketplace | Taxonomie de canal ou exigence de listing | Le conserver séparé du modèle Product canonique du web-store sauf si les deux portent exactement le même sens. |
| Code lié à l’ERP | Clé inter-systèmes | Préserver l’identifiant stable sans l’exposer inutilement dans le boutique en ligne. |
Cette interprétation évite un catalogue visuellement correct qui n’identifie plus l’article réellement tarifé, stocké, publié ou traité.
Categories, navigation et taxonomies de canal sont des structures distinctes
Une Category source peut servir de parent de catalogue, entrée de menu, landing page SEO, groupe promotionnel, règle de filtre, segment de suivi ou correspondance de taxonomie marketplace. Storeden ne doit pas hériter de toutes ces fonctions au travers d’un seul enregistrement Category.
| Structure source | Rôle dans Storeden | Conséquence de responsabilité |
|---|---|---|
| Arborescence Category parent-enfant | Organisation canonique du catalogue | Appartenance Product et hiérarchie restent des relations de données. |
| Menu du boutique en ligne | Présentation de navigation | Ordre et libellés de menu peuvent référencer les Categories sans appartenir au modèle Category lui-même. |
| Description et métadonnées Category | Contenu d’une landing page | Contenu et sens SEO restent attachés au bon parcours public. |
| Filtre ou facette | Logique de découverte fondée sur des valeurs structurées | L’attribut sous-jacent doit rester cohérent entre les Products. |
| Collection manuelle ou groupe de campagne | Relation de merchandising | Peut nécessiter curation, règles ou présentation par le thème plutôt qu’une Category permanente. |
| Category marketplace | Taxonomie propre au canal | Conserver la correspondance séparément de l’arbre Category du web-store. |
Cette séparation permet au catalogue Storeden d’être géré centralement tandis que chaque boutique en ligne ou marketplace présente les Products selon son propre modèle de découverte.
Les valeurs de stock exigent un système de référence déclaré
Une quantité source peut représenter le stock physique, stock vendable, stock réservé, disponibilité fournisseur, stock d’entrepôt, disponibilité par canal, capacité de précommande ou une valeur synchronisée depuis un ERP. Storeden doit recevoir la valeur correspondant à son rôle, avec les identifiants nécessaires pour qu’elle reste liée au futur système de référence.
| Schéma de stock | Signification | Décision de responsabilité Storeden |
|---|---|---|
| Une quantité par Product | Disponibilité vendable simple | Storeden peut posséder la valeur lorsqu’aucun autre système ne gère le stock. |
| Quantité par variante ou SKU | La disponibilité appartient à l’article vendable enfant | Identité de variante et stock doivent rester alignés. |
| Stock géré par ERP ou entrepôt | Autorité opérationnelle externe | Storeden peut recevoir une disponibilité synchronisée tandis que le système externe reste autoritaire. |
| Disponibilité propre à une marketplace | Allocation par canal | Maintenir les règles du canal distinctes de la quantité Product canonique. |
| Stock de bundle | Dérivé de la disponibilité des composants | Préserver les identifiants des composants et le propriétaire du calcul. |
| Article sans stock ou service | La disponibilité n’est pas une quantité physique | Ne pas inventer de relations de stock absentes du modèle source. |
La frontière de migration doit préserver les quantités initiales lorsque pertinent, mais surtout les clés Product/variante qui permettront aux futures mises à jour de stock d’atteindre le bon enregistrement.
Les données Customer et de compte portent plusieurs rôles
Les enregistrements Customer peuvent représenter acheteurs, titulaires de compte, Contacts newsletter, comptes d’entreprise, contacts d’achat B2B, destinataires de facturation ou livraison, Customers marketplace, fiches CRM ou identités connectées à TeamSystem. Les aplatir dans une liste Customer unique peut réduire l’utilité de la boutique cible.
La planification doit définir ce que signifie la continuité Customer pour le marchand. Certaines boutiques ont surtout besoin de consulter l’historique Order. D’autres exigent accès au compte, segmentation Customer, relations B2B, éligibilité marketing, références de facture ou continuité d’intégration.
| Valeur liée au Customer | Question de modèle de données | Enjeu de migration Storeden |
|---|---|---|
| Nom et e-mail | S’agit-il d’un vrai compte, d’un acheteur ou d’un Contact ? | Doublons ou fiches partielles peuvent affecter support et marketing. |
| Adresses de facturation et livraison | Les adresses sont-elles complètes et liées au bon Customer ou Order ? | Les équipes ont besoin des adresses pour la revue historique et le service client. |
| Groupe ou segment Customer | La valeur est-elle descriptive, liée aux prix ou aux permissions ? | Prix et accès peuvent nécessiter configuration cible ou conception séparée. |
| Données société ou fiscales | Le marchand utilise-t-il des processus B2B ou de facturation ? | Les informations d’entreprise peuvent compter pour comptabilité et historique Order. |
| IDs externes | CRM, ERP, comptabilité ou marketing dépendent-ils de cet ID ? | Préserver ou mettre en correspondance les identifiants lorsqu’ils restent nécessaires. |
| Consentement et marketing | La source contient-elle des préférences juridiquement sensibles ? | Ne pas considérer la migration des Contacts comme une autorisation de réutiliser les données marketing sans revue. |
Un modèle Customer Storeden utile permet aux équipes de reconnaître, servir et segmenter correctement les Customers. Les volumes seuls ne préservent ni compte, segmentation, B2B, consentement ni signification inter-systèmes.
Les Orders préservent les relations commerciales historiques
Un Order Storeden est utile lorsqu’il explique la transaction historique : qui a acheté, quel Product ou quelle variante a été sélectionné, quelles quantité et prix s’appliquaient, quelles remises et taxes ont modifié le total, comment paiement et livraison étaient décrits, quel canal a généré l’Order et quel statut ou contexte de suivi a suivi.
| Valeur historique d’Order | Sens à préserver | Préoccupation cible distincte |
|---|---|---|
| Libellés Product et variante | Identité de l’article acheté | La structure Product actuelle peut évoluer sans réécrire la ligne historique. |
| Prix, remise et taxe | Instantané commercial au moment de l’achat | Prix futurs, campagnes et règles fiscales appartiennent à la configuration actuelle. |
| Libellé de paiement ou référence de transaction | Élément indiquant comment l’Order a été payé | Ne crée pas une connexion de paiement active. |
| Mode de livraison et suivi | Contexte historique de traitement | Ne définit pas les tarifs transporteur ou règles logistiques actuels. |
| Statut et notes | État opérationnel passé | Les nouveaux processus Order peuvent utiliser d’autres statuts. |
| Origine marketplace | Attribution de canal et contexte de suivi | Listings et synchronisation actuels restent des enregistrements séparés. |
Cette séparation maintient l’historique lisible sans laisser croire que les libellés historiques possèdent le futur fonctionnement de commande, paiement, fiscalité ou traitement.
Les enregistrements marketplace et multicanaux forment une couche parallèle
Le rôle multicanal de Storeden fait des données marketplace une couche parallèle plutôt que quelques champs Product supplémentaires. IDs de listing, Categories de canal, titres d’offre, prix par canal, règles de disponibilité, attributs marketplace, références vendeur et origine des Orders peuvent tous se rattacher au même Product canonique tout en restant détenus par un canal ou connecteur spécifique.
| Enregistrement de canal | Relation canonique | Frontière de responsabilité |
|---|---|---|
| Identifiant de listing | Relie un Product ou une variante Storeden à une offre externe | Le conserver si le futur connecteur ou processus de suivi l’utilise encore. |
| Category marketplace | Relie le Product à la taxonomie du canal | Ne pas la fusionner dans l’arbre Category du boutique en ligne Storeden. |
| Prix de canal | Valeur commerciale pour une destination donnée | Identifier si Storeden, un middleware ou la marketplace publie le prix final. |
| Stock de canal | Disponibilité allouée ou synchronisée | Maintenir la règle de canal séparée du stock physique ou canonique. |
| Origine marketplace de l’Order | Contexte historique du canal de vente | La conserver sur les Orders lorsqu’elle soutient suivi et service. |
| Attribut de flux | Donnée Product exigée par le canal | La stocker séparément lorsqu’elle ne représente pas le sens canonique du Product. |
La relation essentielle est un article commercial canonique vers plusieurs représentations de canal. La migration doit préserver cette identité sans dupliquer chaque enregistrement marketplace comme Product Storeden indépendant.
Applications, API et connexions TeamSystem définissent la responsabilité des enregistrements
Storeden peut participer à un écosystème plus large d’applications, API, comptabilité, stock, logistique, marketplaces et processus connectés à TeamSystem. Ces connexions créent des enregistrements qui peuvent apparaître dans la boutique tout en étant produits ailleurs.
| Propriétaire de l’enregistrement | Données typiques | Règle de traduction |
|---|---|---|
| E-commerce Storeden principal | Products, Categories, Customers, Orders | Préserver directement dans Storeden les relations entre types de données pris en charge. |
| Application ou connecteur | Reviews, fidélité, options personnalisées, flux, état d’automatisation | Déterminer si l’application cible expose un enregistrement équivalent et un identifiant durable. |
| ERP, comptabilité, CRM ou entrepôt | Codes Product, autorité de stock, clés Customer, références de facture | Conserver la clé inter-systèmes sans dupliquer inutilement tout le modèle externe. |
| Marketplace | Listing, offre, taxonomie et statut de canal | Préserver seulement les enregistrements nécessaires au processus de canal continu. |
| Thème ou couche boutique en ligne | Mises en page, blocs, menus et présentation | Recréer la présentation séparément des enregistrements e-commerce canoniques. |
| Processus API | Import, mise à jour, synchronisation ou logique événementielle | Traiter le processus comme une conception d’intégration, pas comme un champ statique migré. |
Lorsque la source contient des tables applicatives non prises en charge ou des données propriétaires de connecteur, le modèle de migration doit préserver la signification métier et la clé externe uniquement lorsqu’un propriétaire cible défini existe.
Contenu, URLs et données SEO possèdent leurs propres relations
Descriptions Product, contenu Category, pages, Blog Posts, images, métadonnées, liens internes, menus et redirections peuvent être dispersés dans la boutique source. Storeden doit séparer la responsabilité du contenu de celle du catalogue même lorsque le contenu apparaît sur un parcours Product ou Category.
| Élément de contenu ou d’itinéraire | Relation aux données e-commerce | Sens cible |
|---|---|---|
| URL Product | Parcours public vers un Product | Le parcours peut changer tandis que l’identité Product reste stable grâce aux clés internes et externes. |
| URL Category | Parcours public vers un regroupement de catalogue | Hiérarchie Category, slug, placement menu et redirection sont liés mais distincts. |
| Métadonnées | Description de recherche d’une ressource publique | Les conserver sur le bon Product, Category ou page. |
| Contenu de page riche | Présentation éditoriale ou gérée par thème | Le reconstruire dans la bonne couche de contenu/boutique en ligne lorsqu’il ne s’agit pas de texte de catalogue ordinaire. |
| Images et contexte alternatif | Médias liés aux Products ou au contenu | Préserver rattachement et séquence, pas seulement les fichiers. |
| Lien interne | Relation entre itinéraires publics | Le réécrire lorsque les chemins source changent. |
| Redirection | Règle de continuité depuis un ancien parcours | La préserver comme logique de routage plutôt que contenu Product. |
Cette séparation évite de charger la migration du catalogue avec le fonctionnement du thème tout en protégeant le contenu et les itinéraires qui rendent les Products découvrables.
Conclusion
Storeden change le sens des données lorsqu’un Product géré centralement est représenté par des variantes, Categories, stock, marketplaces, applications et systèmes métier externes. Une même valeur source peut être donnée de catalogue, attribut de canal, instantané d’Order, clé de connecteur ou contenu boutique en ligne selon son propriétaire et son mode de mise à jour.
Un modèle cohérent définit donc une identité Product canonique, préserve les relations de variantes et Orders, déclare le système de référence du stock, sépare les Categories du web-store des taxonomies marketplace et ne conserve que les identifiants externes nécessaires aux intégrations qui continuent. Ce modèle multicanal est plus propre que la copie de chaque champ source dans Storeden sans contexte de responsabilité.
Questions fréquentes
Pourquoi les données Product représentent-elles davantage qu’un simple import Product dans Storeden ?
Elles doivent soutenir présentation du boutique en ligne, placement en Category, confiance dans le stock, prix, images, préparation aux canaux et administration par les équipes. Une fiche Product est incomplète si ses variantes, son placement Category, sa visibilité ou ses attributs marketplace ne portent plus le même sens.
Les Orders migrés configurent-ils les paiements et la livraison dans Storeden ?
Non. Les Orders migrés préservent les informations historiques de paiement et livraison pour référence. Le futur fonctionnement de commande, paiement, livraison, logistique, fiscalité et traitement appartient aux enregistrements et réglages actifs de la plateforme cible.
Quand faut-il examiner séparément les données marketplace ?
Lorsque la boutique source utilise listings propres aux canaux, prix, Categories, attributs, règles de stock, origines Order ou identifiants marketplace. Ces valeurs peuvent ne pas fonctionner comme des champs Product ordinaires du web-store.
Comment traiter champs personnalisés et identifiants externes ?
Ils doivent être classés selon leur usage métier. S’ils soutiennent ERP, comptabilité, CRM, logistique, synchronisation marketplace ou suivi, ils peuvent nécessiter une correspondance, un traitement structuré ou une conception cible dédiée plutôt qu’un simple transfert de champ.
Pourquoi les volumes d’enregistrements ne suffisent-ils pas pour traduire les données vers Storeden ?
Ils ne montrent pas si les variantes identifient toujours les articles vendables, si le stock appartient au bon système, si les enregistrements marketplace restent reliés, si les Orders conservent leur contexte commercial ou si les identifiants externes relient encore les bons systèmes. La signification des relations est le critère décisif.
Comment les intégrations marketplace ou de canal doivent-elles influencer la responsabilité des données dans Storeden ?
Identifiez quel système possède le Product canonique, la valeur de stock, l’identité Customer, le statut Order et l’identifiant externe de listing. Préservez les clés inter-systèmes encore opérationnelles, mais ne dupliquez pas les enregistrements générés par les intégrations comme si Storeden en était la source d’origine.