Lorsque ShopWired est envisagée comme plateforme cible, le risque de migration vient surtout de la séparation entre variations Product, Product Choices, Product Extras, champs de personnalisation, bundles, tarification B2B, Quotes, inventaire, configuration du parcours de commande, applications, thèmes et intégrations. Plusieurs de ces structures peuvent apparaître comme de simples « options » dans un export de la boutique source alors qu’elles ont des conséquences très différentes sur les SKU, le stock, le prix, les images et les Orders.
ShopWired est une plateforme hébergée : le code personnalisé côté source et les structures directes de base de données ne sont donc pas transférés comme actifs d’implémentation. Leur finalité métier doit être reconstruite avec des enregistrements ShopWired, des applications, le thème ou des systèmes externes. Chaque risque majeur commence ainsi par une hypothèse sur ce qui peut être copié et se termine par des éléments de validation montrant que le résultat commercial attendu possède un responsable dans l’environnement cible.
Les variations peuvent se multiplier plus vite que le catalogue ne peut être gouverné
Les variations ShopWired peuvent combiner jusqu’à trois types de variations, avec des enregistrements séparés pour les combinaisons valides. Chaque combinaison configurée peut posséder son propre SKU, stock, prix, prix promotionnel, poids, GTIN, MPN, image et autres valeurs.
| Élément de la chaîne de risque | Interprétation propre à ShopWired |
|---|---|
| Hypothèse | Chaque dimension d’option source peut être convertie en variation ShopWired sans modifier l’administration du catalogue. |
| Contrainte de plateforme | Le nombre de types de variations est limité et chaque combinaison générée peut créer un enregistrement commercial distinct à gérer. |
| Conséquence pour la migration | Les configurateurs source complexes dépassent la structure disponible ou créent un grand nombre de combinaisons invalides et difficiles à maintenir. |
| Impact opérationnel | Les équipes ne peuvent plus gouverner correctement prix et stock, les acheteurs rencontrent des combinaisons indisponibles et les imports ou flux deviennent difficiles à rapprocher. |
| Piste d’atténuation | Conserver dans la grille de variations uniquement les dimensions qui définissent SKU, stock, prix, poids ou image, et déplacer les autres sélections vers la structure ShopWired appropriée. |
| Responsables concernés | Opérations catalogue, inventaire, merchandising, traitement des commandes et marketplaces. |
| Signal de contrôle | Chaque combinaison générée est commercialement valide, identifiable de façon unique, maintenable et reliée au bon sens de stock, prix, image et traitement des commandes. |
La limite n’est pas seulement technique. Même dans la structure prise en charge, un grand produit cartésien de combinaisons peut créer une charge opérationnelle qui n’existait pas dans la boutique source.
Les Product Choices peuvent être confondus avec des variations portant du stock
Les Product Choices ShopWired sont des ensembles réutilisables affectés à des Products. Ils peuvent ajouter un prix au Product de base, mais ne possèdent ni SKU, ni quantité en stock, ni poids, ni image propres. Ils constituent une alternative aux variations, et non un second nom pour le même enregistrement.
| Élément de la chaîne de risque | Interprétation propre à ShopWired |
|---|---|
| Hypothèse | Les Product Choices peuvent remplacer n’importe quelle variante ou combinaison source puisqu’ils présentent des valeurs sélectionnables à l’acheteur. |
| Contrainte de plateforme | Les Choices ne possèdent ni SKU, ni stock, ni poids, ni image et ajoutent un coût au lieu de définir le prix de remplacement d’une unité vendable. |
| Conséquence pour la migration | Des variantes portant du stock sont représentées comme choix réutilisables, ou des choix descriptifs sont transformés en combinaisons de variations inutiles. |
| Impact opérationnel | Le stock ne peut pas être contrôlé par sélection, les lignes d’Order perdent la précision du SKU, les poids de livraison deviennent incorrects et les prix produisent des totaux inattendus. |
| Piste d’atténuation | Affecter une valeur source à Product Choices uniquement lorsqu’elle est réutilisable, sans stock, sans image propre et compatible avec une tarification additive. |
| Responsables concernés | Administration du catalogue, tarification, inventaire, traitement des commandes et service Customer. |
| Signal de contrôle | Chaque Product Choice se comporte comme une sélection additive sans inventaire, tandis que chaque véritable combinaison vendable reste une variation. |
Un même tableau d’attributs source peut contenir les deux types de structures. Le nom du champ ne suffit pas à déterminer la destination ShopWired correcte.
Product Extras, bundles et champs de personnalisation ont des conséquences de stock différentes
Les Product Extras peuvent ajouter des articles facultatifs et être reliés au SKU d’un Product de base, mais pas à une variation Product précise. Les bundles relient des Products constituants et leurs quantités, tandis que les champs de personnalisation collectent du texte ou des fichiers saisis par l’acheteur pour un Order.
| Élément de la chaîne de risque | Interprétation propre à ShopWired |
|---|---|
| Hypothèse | Les articles facultatifs, composants de bundle et personnalisations peuvent tous être représentés comme valeurs de variation supplémentaires. |
| Contrainte de plateforme | Extras, bundles, champs de personnalisation et variations ont des comportements différents concernant relation Product, stock, Order et compatibilité. |
| Conséquence pour la migration | Un extra lié pointe vers le mauvais enregistrement de stock, un bundle perd les quantités de composants ou une information saisie par l’acheteur devient une donnée de catalogue réutilisable. |
| Impact opérationnel | Les déductions de stock deviennent incorrectes, les extras retournés ne rétablissent pas le stock attendu, la livraison numérique ou le traitement des commandes oublie des composants et les Orders personnalisés perdent leurs instructions. |
| Piste d’atténuation | Déterminer si la relation source est un article lié facultatif, un ensemble de composants requis, une saisie de l’acheteur ou une variante vendable, puis préserver son comportement spécifique de stock et d’Order. |
| Responsables concernés | Inventaire, traitement des commandes, merchandising, service Customer, livraison numérique et retours. |
| Signal de contrôle | Extras, bundles et valeurs de personnalisation créent les éléments d’Order et les effets de stock attendus sans être rattachés à une relation de variation non prise en charge. |
Ces différences sont particulièrement importantes pour les Products qui combinent bundles et options, car ShopWired peut imposer des limites de compatibilité entre ces structures.
Les comptes B2B et la tarification peuvent dépendre de plus que la classification Customer
Les opérations B2B ShopWired peuvent utiliser des remises globales en pourcentage, des prix Product propres à un Customer, des bandes tarifaires, des prix masqués, des processus de Quote et d’autres règles de compte. Le simple fait de marquer un Customer comme B2B ne lui attribue pas automatiquement l’ensemble de son traitement commercial.
| Élément de la chaîne de risque | Interprétation propre à ShopWired |
|---|---|
| Hypothèse | Migrer un indicateur de compte B2B ou un Customer Group préserve la tarification et l’accès B2B. |
| Contrainte de plateforme | La tarification B2B peut être globale, propre à un Product ou fondée sur une bande tarifaire, tandis que la visibilité et le fonctionnement des Quotes peuvent dépendre de paramètres distincts du thème ou d’applications. |
| Conséquence pour la migration | Les comptes arrivent sans la source de prix, l’affectation de bande, la règle de prix masqué ou la relation Quote qui contrôlait leur expérience d’achat. |
| Impact opérationnel | Les Customers B2B voient les prix retail, des prix confidentiels deviennent publics, les équipes commerciales perdent le contexte négocié et les Quotes ne peuvent pas être convertis de manière cohérente. |
| Piste d’atténuation | Relier chaque compte B2B à son mécanisme de tarification, sa règle de visibilité, son état de Quote, son traitement fiscal, ses attentes de paiement et son identifiant de compte externe. |
| Responsables concernés | Ventes B2B, finance, service Customer, gestion de comptes et administration de la boutique. |
| Signal de contrôle | Des comptes B2B représentatifs reçoivent les prix et la visibilité attendus et peuvent suivre le parcours Quote ou commande directe requis sans correction manuelle. |
La source peut contenir plusieurs modèles B2B simultanément. Un seul champ de pourcentage ne peut pas représenter à la fois des exceptions de prix propres à des Customers et des relations de bandes tarifaires.
La compatibilité des Quotes peut dépendre de la manière dont les variations ont été créées
Les Quotes ShopWired peuvent inclure Customers existants, Products, livraison, traitement TVA, statut et commentaires. Les Products créés avec l’approche simplifiée « all variants » ne sont pas compatibles avec les Quotes tant que leurs combinaisons de variations ne sont pas configurées individuellement.
| Élément de la chaîne de risque | Interprétation propre à ShopWired |
|---|---|
| Hypothèse | Tout Product visible dans la boutique peut être ajouté à un Quote avec les mêmes données Product et d’options. |
| Contrainte de plateforme | La compatibilité avec les Quotes dépend de combinaisons de variations configurées individuellement plutôt que de la représentation simplifiée de toutes les variantes. |
| Conséquence pour la migration | Les Products paraissent corrects dans le catalogue mais ne peuvent pas être ajoutés à un Quote ou correspondent à une combinaison ambiguë dans le processus commercial. |
| Impact opérationnel | Les équipes commerciales ne peuvent pas établir des Quotes fiables, les contrôles de stock deviennent incertains et les Quotes payés se transforment en Orders avec une identité Product incomplète. |
| Piste d’atténuation | Identifier les Products utilisés dans les processus de Quote et s’assurer que chaque combinaison pertinente possède un enregistrement explicite compatible avec la sélection dans les Quotes. |
| Responsables concernés | Ventes B2B, gestion de comptes, inventaire, finance et service Customer. |
| Signal de contrôle | Des Quotes représentatifs peuvent sélectionner les combinaisons Product attendues, afficher le bon contexte de stock et de fiscalité, et conserver commentaires et prix lors de la conversion. |
Ce risque est facile à manquer lorsque le catalogue est contrôlé séparément du processus de Quote. Un même Product peut réussir l’inspection de la boutique tout en restant inutilisable par l’équipe commerciale.
L’inventaire peut dépendre du SKU, de la variation, du bundle, de l’extra et d’un système externe
Dans ShopWired, le stock peut être géré au niveau du Product de base ou d’une variation configurée. La saisie du stock dépend de la présence de SKU, tandis que bundles, extras liés, flux et systèmes externes peuvent introduire d’autres relations de responsabilité.
| Élément de la chaîne de risque | Interprétation propre à ShopWired |
|---|---|
| Hypothèse | Une quantité d’ouverture unique par Product suffit à préserver la disponibilité. |
| Contrainte de plateforme | La quantité peut appartenir à une variation, un Product lié, un composant de bundle ou une autorité externe de stock, et certaines fonctions appliquent les règles de stock différemment. |
| Conséquence pour la migration | Le stock est placé sur le Product parent, dupliqué entre les variations ou mis à jour simultanément par ShopWired et un système externe. |
| Impact opérationnel | Des surventes apparaissent, la disponibilité des bundles devient trompeuse, les retours ne restaurent pas les quantités attendues et les mises à jour d’intégration écrasent des valeurs correctes. |
| Piste d’atténuation | Déclarer le responsable de l’inventaire pour chaque famille Product et préserver les relations SKU-vers-variation, composants de bundle, extras liés et emplacements externes. |
| Responsables concernés | Entrepôt, achats, traitement des commandes, retours, marketplaces et équipes d’intégration. |
| Signal de contrôle | Chaque article vendable reçoit sa quantité d’une seule source faisant autorité, et chaque Order, bundle, extra, retour et synchronisation affecte l’enregistrement de stock attendu. |
L’inventaire d’ouverture et les Orders historiques nécessitent des contrôles distincts. L’import d’anciens Orders ne doit pas rejouer des mouvements de stock sur l’état d’ouverture de la cible.
Parcours de commande, livraison, paiement, TVA et taxe sur les ventes constituent des risques de configuration
Les Orders historiques peuvent préserver d’anciens libellés de paiement, livraison et fiscalité, mais ces enregistrements ne configurent pas le parcours de commande ShopWired. Le fonctionnement en production dépend des moyens de paiement actifs, zones et tarifs de livraison, règles de retrait, champs du parcours de commande, paramètres TVA, paramètres de taxe sur les ventes, règles B2B et applications installées.
| Élément de la chaîne de risque | Interprétation propre à ShopWired |
|---|---|
| Hypothèse | Migrer les données historiques du parcours de commande recrée les règles nécessaires aux nouveaux Orders. |
| Contrainte de plateforme | Le fonctionnement actuel du parcours de commande est contrôlé par la configuration cible et les applications, et non par les libellés des Orders historiques. |
| Conséquence pour la migration | Les anciens Orders restent lisibles tandis que les nouveaux paniers calculent la taxe, la livraison, la disponibilité des paiements ou les champs obligatoires différemment des règles métier attendues. |
| Impact opérationnel | Les Customers sont surfacturés ou sous-facturés, certaines régions valides ne peuvent pas commander, les comptes B2B perdent les méthodes attendues et le traitement des commandes reçoit des informations incomplètes. |
| Piste d’atténuation | Séparer les éléments historiques de la responsabilité du parcours de commande actif et définir la règle cible pour chaque région, type de Product, catégorie de Customer, moyen de paiement et parcours de livraison. |
| Responsables concernés | Finance, fiscalité, opérations du parcours de commande, traitement des commandes, ventes B2B et service Customer. |
| Signal de contrôle | Des paniers retail et B2B représentatifs produisent le comportement attendu pour fiscalité, livraison, paiement, retrait et champs du parcours de commande avec la configuration cible actuelle. |
Il s’agit d’une limite structurelle et non d’un problème de nombre d’enregistrements. Un historique d’Orders complet peut coexister avec un parcours de commande mal configuré.
Applications, API, webhooks, thèmes et systèmes externes peuvent laisser des fonctionnements orphelins
ShopWired expose via son API Products, variations, choix, extras, champs de personnalisation, Categories, marques, tags, stocks, Customers, Orders et ressources de livraison. Applications, webhooks, thèmes, systèmes comptables, traitement des commandes, marketplaces et plateformes marketing peuvent posséder d’autres fonctionnements et identifiants.
| Élément de la chaîne de risque | Interprétation propre à ShopWired |
|---|---|
| Hypothèse | Des fonctions cibles similaires reprendront automatiquement les applications, flux, webhooks, logique de thème et processus externes de la boutique source. |
| Contrainte de plateforme | Enregistrements d’application, authentification, abonnements aux événements, code du thème, définitions de champs et identifiants externes sont séparés des enregistrements Product et Order ordinaires. |
| Conséquence pour la migration | Les données principales arrivent mais abonnements, flux, événements de traitement des commandes, liens comptables, règles d’affichage personnalisées ou segments marketing restent déconnectés. |
| Impact opérationnel | Les Orders cessent d’atteindre les systèmes externes, stocks et prix deviennent obsolètes, des informations commerciales dépendant du thème disparaissent et le rapprochement perd sa traçabilité. |
| Piste d’atténuation | Affecter à chaque application ou intégration un responsable, une capacité cible, un identifiant, un événement ou une dépendance API, une clé durable, une dépendance de thème et un processus de gestion des exceptions. |
| Responsables concernés | Ingénierie des intégrations, finance, traitement des commandes, marketing, développement de la boutique, sécurité et gouvernance des données. |
| Signal de contrôle | Chaque processus qui perdure peut identifier le bon enregistrement cible, recevoir ou envoyer l’événement requis et récupérer d’un échec de synchronisation sans ambiguïté manuelle. |
Une plateforme cible hébergée modifie la limite d’implémentation. Le code source doit être interprété comme un élément indiquant un fonctionnement métier à préserver, et non comme un actif supposé portable.
Conclusion
Les risques de migration vers ShopWired se concentrent là où des structures de choix visuellement proches ont des responsabilités commerciales différentes. Variations, Product Choices, Extras, bundles, champs de personnalisation, prix B2B, Quotes, stocks, règles du parcours de commande, applications et systèmes externes ne peuvent pas être aplatis dans un modèle unique Product + options.
Le risque est maîtrisé lorsque chaque fonctionnement source possède un propriétaire ShopWired délibéré et un signal de contrôle observable. Cela permet de préserver l’identité vendable, le traitement des comptes B2B, l’utilisation des Quotes, l’autorité sur le stock, l’exactitude du parcours de commande, le sens historique et la continuité des intégrations sans reproduire des mécanismes source non pris en charge.
Questions fréquentes
Quel est le principal risque de structure Product dans ShopWired ?
Le risque principal consiste à traiter variations, Product Choices, Extras, bundles et champs de personnalisation comme des options interchangeables. Ils diffèrent par leurs comportements de SKU, stock, prix, image, composants et Orders.
Quand une option source doit-elle devenir une variation ShopWired ?
Elle doit devenir une variation lorsque le choix identifie une véritable combinaison vendable possédant son propre SKU, stock, prix, poids, GTIN, image ou sens de traitement des commandes. Les sélections réutilisables sans stock peuvent davantage correspondre aux Product Choices.
Pourquoi les comptes B2B peuvent-ils rester incomplets après la migration des Customers ?
Le traitement B2B peut dépendre de remises globales, prix propres à un Customer, bandes tarifaires, règles de prix masqué, Quotes, contexte fiscal et identifiants de compte. L’indicateur de compte seul ne préserve pas ces relations.
Pourquoi un Product peut-il fonctionner dans la boutique mais échouer dans les Quotes ?
Les Products créés avec l’approche simplifiée « all variants » ne sont pas compatibles avec les Quotes ShopWired. Les combinaisons utilisées dans les Quotes doivent disposer d’enregistrements de variation explicites que le système de Quote peut sélectionner.
Les Orders historiques prouvent-ils que le parcours de commande est correctement configuré ?
Non. Les Orders historiques préservent des libellés et totaux passés. Le fonctionnement actuel des paiements, livraisons, taxes, retraits, règles B2B et champs du parcours de commande dépend des paramètres ShopWired actifs et des applications.
Comment le code personnalisé source doit-il être traité dans une migration ShopWired ?
Considérez-le comme un élément décrivant un fonctionnement métier requis. Ce fonctionnement doit être pris en charge par une configuration ShopWired, une application, le thème, un système externe ou une décision volontaire de retrait ; l’implémentation source elle-même n’est pas portable.