Lorsque Wix est envisagé comme plateforme cible, le risque vient de l’interaction entre commerce, création de site, données CMS, fonctions de relation Customer, Members, applications et logique programmable au sein d’une plateforme gérée. Les problèmes apparaissent lorsque base de données, thème, scripts du processus de commande, extensions Product ou enregistrements applicatifs de la boutique source sont supposés devenir de simples données Wix Stores.
L’architecture actuelle du Catalog Wix ajoute une autre frontière importante : Catalog V3 utilise des variantes universelles, sépare options et modifiers, et gère le stock par variante et emplacement. Les Orders appartiennent à un domaine eCommerce plus large où facturation, transactions, factures, traitement et paramètres restent séparés. Les collections CMS et champs de référence peuvent soutenir des applications de site personnalisées, mais ne remplacent pas automatiquement les entités Product, Customer, Order ou celles possédées par des applications.
Chaque chaîne de risque doit donc rendre explicites l’hypothèse de départ, la contrainte Wix, la conséquence sur la migration, l’impact opérationnel, l’orientation de mitigation et le signal de contrôle.
Frontières entre site hébergé, commerce, CMS et applications
Wix n’expose pas une base cible générique dans laquelle chaque table source pourrait être copiée. Les données doivent appartenir à Wix Stores, eCommerce Orders, Contacts, Members, collections CMS, une application Wix, du code Velo, un service plugin ou un système externe. Le design du site et le fonctionnement des pages dynamiques constituent encore d’autres couches.
| Hypothèse source | Contrainte Wix | Conséquence sur la migration | Impact opérationnel | Orientation de mitigation | Signal de contrôle |
|---|---|---|---|---|---|
| Les tables source peuvent être reproduites directement. | Wix utilise des ressources métier, schémas CMS, applications et APIs définis. | Les enregistrements personnalisés sont aplatis en champs ou placés dans le mauvais domaine. | Les équipes perdent état de processus, contexte d’analyse ou liens externes. | Classifier chaque entité non standard par propriétaire et cycle de vie avant toute mise en correspondance. | Chaque enregistrement requis possède un propriétaire Wix ou externe pris en charge. |
| Le thème et les données de page builder migrent avec les enregistrements. | Pages, sections, pages dynamiques, templates et affichage mobile sont une implémentation cible. | Le contenu existe sans la mise en page ni les interactions qui le rendaient utilisable. | Des parcours importants semblent incomplets malgré la présence des données commerciales. | Séparer contenu/références durables et implémentation de la présentation. | Chaque page clé possède une responsabilité claire pour contenu, route et fonctionnement. |
| Les scripts de commande sont de simples champs Order. | Le fonctionnement actif dépend des paramètres Wix, extensions, service plugins, applications et chemins de code pris en charge. | Frais, règles d’approbation, saisies personnalisées ou fonctionnement des prestataires disparaissent. | Les nouveaux Orders ne peuvent pas suivre les règles métier requises. | Représenter l’historique séparément et attribuer le futur fonctionnement à un propriétaire durable. | La règle métier requise possède un propriétaire d’implémentation Wix ou externe explicite. |
| Les enregistrements d’applications font partie du cœur Wix Stores. | Bookings, Events, Restaurants, Pricing Plans, fidélité, subscriptions et autres applications possèdent des entités séparées. | Les enregistrements spécialisés sont aplatis dans Contacts, Products ou notes d’Order. | Calendriers, droits, soldes ou historique des participants deviennent inutilisables. | Préserver les références parent et déplacer l’enregistrement spécialisé vers son domaine réel. | L’application durable reconnaît le Contact, Product et la transaction prévus. |
Cette frontière est à l’origine de nombreux risques Wix. Elle doit être résolue avant de considérer des champs individuels comme faisant partie du périmètre de migration.
Risque de filiation entre Catalog V1, Catalog V3 et Products
Catalog V3 n’est pas simplement le nom d’un nouvel endpoint. Il utilise des variantes universelles : chaque Product possède au moins une variante, même sans options. Les options créent des variantes et influencent le stock. Les modifiers collectent des informations supplémentaires sans créer de variantes. Les Inventory Items sont gérés séparément et peuvent représenter une variante à un emplacement.
Les boutiques source et anciennes intégrations Wix peuvent encore refléter les hypothèses de Catalog V1. Le risque augmente lorsque des enregistrements historiques ou source sont mis en correspondance sans définir la génération de catalogue et le niveau Product utilisés par la boutique cible.
| Hypothèse | Contrainte Catalog | Conséquence sur la migration | Impact opérationnel | Orientation de mitigation | Signal de contrôle |
|---|---|---|---|---|---|
| Un Product sans options n’a pas de variante. | Catalog V3 utilise une variante universelle par défaut. | Les identifiants et le stock au niveau Product sont mis en correspondance de façon incohérente avec les systèmes fondés sur les variantes. | Les mises à jour de stock et intégrations ne retrouvent pas l’unité vendable prévue. | Définir une identité de variante cible pour chaque Product, y compris les Products simples. | Chaque Product possède une variante vendable stable reconnue par les intégrations. |
| Les enregistrements Catalog V1 et V3 sont interchangeables. | V3 modifie les frontières Product, variante, Customization, stock et services associés. | IDs ou relations sont réutilisés dans le mauvais modèle. | La synchronisation catalogue crée des doublons ou manque les changements de variantes. | Documenter la filiation Catalog source et la carte des entités V3 cible. | Chaque Product et variante source se résout une seule fois dans le catalogue cible. |
| La création du Product crée automatiquement toutes les relations de stock. | Product et Inventory Item peuvent être créés séparément. | Les Products existent sans les enregistrements de stock prévus. | Les articles semblent vendables mais ne suivent pas le fonctionnement du stock par emplacement. | Traiter identité Product/variante et Inventory Items comme des enregistrements liés mais distincts. | Chaque variante suivie possède la relation de stock prévue à l’emplacement voulu. |
| Les données Product d’une ancienne application sont des données Catalog natives. | Les applications peuvent étendre ou référencer Products via leurs propres entités. | Le fonctionnement possédé par l’application est copié en champs Product inexpliqués. | Les équipes voient des valeurs qu’aucun processus Wix ne maintient. | Garder entités applicatives et Products du catalogue distincts tout en préservant leurs clés. | L’application peut résoudre le Product ou la variante qu’elle étend. |
Les propriétaires concernés sont les équipes catalogue, intégration et tout système utilisant IDs Product ou variante. La mitigation est une carte de filiation, non une conversion générique de champs.
Risque lié aux options, modifiers, variantes et personnalisations
Les Customizations de Catalog V3 distinguent options et modifiers. Les options créent des combinaisons avec SKUs, prix et stocks distincts. Les modifiers collectent texte ou sélection supplémentaire sans modifier identité de variante ni stock. Les catalogues source regroupent souvent taille, couleur, gravure, emballage, upgrades de service, garanties et spécifications dans une même table d’options.
| Modèle source | Contrainte Wix | Conséquence sur la migration | Impact opérationnel | Orientation de mitigation | Signal de contrôle |
|---|---|---|---|---|---|
| Taille ou couleur est traitée comme métadonnée descriptive. | Les choix vendables doivent former des variantes lorsqu’ils possèdent SKU, prix ou stock. | Le Product affiche la valeur mais ne peut pas gérer la combinaison achetée. | Stock et traitement utilisent le mauvais article. | Préserver la relation option-choix-variante. | L’option sélectionnée se résout vers la variante et l’Inventory Item prévus. |
| Gravure ou texte libre devient une option. | Les options créent des variantes ; les modifiers capturent la saisie sans changer le stock. | Le catalogue génère des combinaisons inutiles pour chaque personnalisation. | Administration Product et stock deviennent ingérables. | Utiliser une responsabilité de type modifier pour les saisies sans impact sur le stock. | La saisie Customer apparaît dans la transaction sans créer de variante. |
| Les extras payants deviennent automatiquement des variantes. | Certains extras changent le prix sans changer l’identité de stock et peuvent appartenir à un modifier ou une application. | De fausses variantes fragmentent analyses et disponibilité. | Les équipes ne distinguent plus Product de base et service facultatif. | Définir si l’extra appartient à un modifier, une application, un bundle ou un processus externe. | Le détail Order montre l’extra tandis que le stock de base reste cohérent. |
| Les composants d’un bundle sont stockés comme texte Product. | Stock et traitement des composants exigent une relation séparée. | L’offre est visible mais la disponibilité des composants ne peut pas être calculée. | Survente et erreurs de préparation apparaissent. | Attribuer la logique des composants à une application compatible ou un système externe. | Le système responsable du stock peut identifier chaque composant. |
| Les spécifications deviennent des dimensions de variante. | Info Sections, Brands, Categories et autres champs du catalogue peuvent décrire les Products sans créer de combinaisons. | Le nombre de variantes explose et les acheteurs voient des choix non pertinents. | La maintenance du catalogue devient complexe et risquée. | Garder les informations non sélectionnables hors des dimensions d’option. | Les spécifications restent réutilisables ou descriptives sans changer l’identité de variante. |
Le risque est maîtrisé lorsque chaque saisie acheteur possède un effet clair sur identité vendable, stock, prix, traitement ou contexte historique de l’Order.
Risque de stock par variante et emplacement
Les Inventory Items Wix peuvent suivre le stock d’une variante précise à un emplacement précis. Les emplacements peuvent représenter boutiques, entrepôts ou centres de traitement. Le modèle de risque est donc plus granulaire qu’une quantité unique au niveau Product.
| Hypothèse | Contrainte de stock | Conséquence sur la migration | Impact opérationnel | Orientation de mitigation | Signal de contrôle |
|---|---|---|---|---|---|
| Une quantité source peut être copiée au Product. | Le stock appartient aux relations variante-emplacement. | La quantité est détachée de l’unité vendable et de l’emplacement de traitement. | Les Customers voient une disponibilité fausse et les équipes utilisent le mauvais stock. | Relier chaque propriétaire de stock source à une variante et un emplacement cible. | Totaux par emplacement et variante correspondent au modèle opérationnel déclaré. |
| Tous les Products doivent avoir un stock suivi. | Services, biens numériques, articles illimités et disponibilité contrôlée extérieurement peuvent suivre d’autres règles. | Des offres sans stock deviennent indisponibles ou affichent des quantités trompeuses. | Des ventes valides sont bloquées ou des Products non pris en charge restent exposés. | Classifier séparément suivi, illimité, précommande et stock externe. | Chaque classe de stock produit le fonctionnement de vente attendu. |
| La création Product prouve que le stock est complet. | Les Inventory Items peuvent nécessiter création et responsabilité séparées. | Les Products existent sans enregistrements de stock. | Les équipes pensent que le stock a migré parce que le catalogue est visible. | Inclure les relations Inventory Item dans le modèle de catalogue. | Chaque variante suivie possède un Inventory Item identifiable à l’emplacement prévu. |
| Un instantané suffit pour un catalogue géré par ERP. | Les systèmes externes continuent à publier le stock après migration. | Les quantités initiales sont correctes mais les mises à jour suivantes échouent ou s’attachent mal. | Le stock de canal dérive rapidement. | Préserver les clés Product, variante, emplacement et système externe. | Une mise à jour continue atteint la bonne relation variante-emplacement. |
| Les Orders historiques doivent rejouer les changements de stock. | Transactions historiques et stock d’ouverture ont des responsabilités différentes. | La quantité est décrémentée une seconde fois. | La boutique démarre avec un stock disponible incorrect. | Établir le stock d’ouverture indépendamment de l’historique Order importé. | Les Orders historiques ne modifient pas la position d’ouverture approuvée. |
Le risque de stock affecte rapidement le revenu, mais le contrôle structurel reste simple : Wix et chaque propriétaire externe du stock doivent utiliser la même identité de variante et d’emplacement.
Contacts, Members, Customers et participants d’applications
Les Contacts Wix peuvent représenter les personnes qui interagissent avec le site, tandis que Members ajoute des relations de compte et d’accès. Customers commerciaux, auteurs de formulaires, abonnés, clients de booking, participants d’events, détenteurs de Pricing Plans, participants fidélité et profils applicatifs peuvent se chevaucher sans être une même entité.
| Hypothèse source | Contrainte Wix | Conséquence sur la migration | Impact opérationnel | Orientation de mitigation | Signal de contrôle |
|---|---|---|---|---|---|
| Tout Customer doit devenir Member. | Identité Contact et accès Member sont des relations séparées. | Les acheteurs invités reçoivent une attente de connexion non prise en charge ou l’accès réservé est perdu. | Support des comptes et contenu protégé deviennent incohérents. | Préserver séparément historique acheteur et droit Member. | Seuls les utilisateurs prévus reçoivent un accès Member et les Orders restent liés au bon Contact. |
| L’email seul prouve une identité unique. | Doublons source, emails partagés, changements d’adresse et IDs externes peuvent représenter des histoires distinctes. | Des Contacts sont fusionnés à tort ou une personne devient plusieurs enregistrements. | Marketing, support et historique Order deviennent peu fiables. | Utiliser IDs source, liens Order, email, téléphone et clés externes selon une hiérarchie d’identité documentée. | Les personnes à forte valeur ou ambiguës se résolvent vers le Contact prévu. |
| Le consentement d’abonnement est une donnée Contact ordinaire. | La permission de communication a une finalité et une provenance distinctes de l’identité. | Des Contacts importés peuvent être considérés comme commercialisables sans relation valide. | Conformité et ciblage sont affaiblis. | Préserver uniquement les préférences prises en charge dont la signification est claire. | Les processus marketing distinguent identité et permission de communication. |
| Les participants d’applications appartiennent à des champs personnalisés Contact. | Bookings, Events, Pricing Plans, fidélité et autres applications possèdent des enregistrements spécialisés. | Calendrier, droit, progression ou solde sont aplatis. | Le service Customer ne comprend plus la relation active. | Garder le lien Contact et migrer ou archiver l’entité spécialisée chez son propriétaire réel. | L’application durable reconnaît le Contact et l’enregistrement de participation prévus. |
| Les IDs CRM externes peuvent être remplacés. | CRM et systèmes de support peuvent considérer la clé existante comme autoritaire. | Les mises à jour créent des Contacts dupliqués ou s’attachent au mauvais enregistrement. | Segmentation et historique de support se fragmentent. | Préserver les identifiants externes durables au niveau Contact ou organisation utilisé par le CRM. | Une recherche CRM retourne le Contact Wix prévu. |
Le contrôle repose sur un modèle d’identité en couches : relations Contact, Member, Customer, participant et compte externe restent reliées sans être confondues.
Orders, facturation, transactions, traitement et paramètres
Les eCommerce Orders Wix gèrent le cycle après achat et relient articles achetés, détails de paiement, informations d’expédition et statut de traitement. Wix sépare également Order Billing, Order Transactions, Invoices, Payment Requests, Fulfillments et Order Settings. La migration historique doit préserver les éléments de ces domaines sans attribuer une autorité opérationnelle actuelle aux anciens enregistrements.
| Chaîne de risque | Conséquence sur la migration | Impact opérationnel | Orientation de mitigation | Signal de contrôle |
|---|---|---|---|---|
| Un statut source est copié comme état complet de l’Order. | Paiement, traitement, annulation, facture et remboursement sont compressés. | Les équipes ne savent pas si argent ou marchandise restent dus. | Préserver un état historique lisible entre les relations Order pertinentes. | Les Orders complexes sont compréhensibles sans accès au système source. |
| Les lignes Order ne pointent que vers Products parents. | Variante achetée, modifier ou configuration possédée par une application est perdue. | Support et traitement ne savent pas ce qui a été acheté. | Préserver instantanés de lignes et références fiables Product/variante/personnalisation. | La ligne montre l’identité vendable et la saisie acheteur prévues. |
| Les données de paiement historiques sont traitées comme autorité active. | Détails de paiement et Transactions documentent le passé ; prestataires et paramètres actuels sont séparés. | Les équipes pensent que d’anciens identifiants ou tokens peuvent traiter de nouvelles ventes. | Conserver des références de transaction sûres et configurer séparément le paiement actuel. | Les paiements historiques restent traçables sans exposer ni réutiliser des identifiants sensibles. |
| Les étiquettes d’expédition recréent le traitement actuel. | Fulfillments, paramètres de livraison, transporteurs et emplacements ont une responsabilité actuelle séparée. | Les nouveaux Orders suivent des parcours incomplets. | Préserver les éléments historiques d’expédition et définir séparément le traitement actif. | Responsabilités historiques et actives sont distinguables. |
| Les Orders importés déclenchent les mises à jour de stock actuelles. | Historique Order et Inventory Items d’ouverture ont des finalités différentes. | Le stock est décrémenté à nouveau ou mal synchronisé. | Isoler l’import historique de l’autorité du stock d’ouverture. | Le stock reste stable après introduction des enregistrements historiques. |
Les propriétaires concernés sont service Customer, finance, opérations et intégration. L’orientation consiste à préserver les éléments historiques tout en maintenant les paramètres Wix actuels comme autorité.
Risque lié aux collections CMS, pages dynamiques et champs de référence
Les collections Wix CMS peuvent stocker des Data Items structurés et des champs de référence. Elles peuvent alimenter pages dynamiques, annuaires, ressources, contenu personnalisé de l’interface de vente et processus applicatifs. Elles peuvent aussi se connecter à des bases externes. Cette flexibilité crée le risque de déplacer des tables source personnalisées dans CMS sans préserver schéma, références, permissions, code ou fonctionnement de page.
| Hypothèse source | Contrainte CMS | Conséquence sur la migration | Impact opérationnel | Orientation de mitigation | Signal de contrôle |
|---|---|---|---|---|---|
| Une table source peut devenir automatiquement une collection CMS. | Champs, schémas d’items, permissions, références, index et pages/code consommateurs sont séparés. | Les lignes sont transférées mais relations et fonctionnement d’édition disparaissent. | Les pages dynamiques affichent des données incomplètes ou ne résolvent plus les liens. | Définir schéma, champs de référence, permissions et consommateurs comme un seul modèle. | Des items représentatifs résolvent chaque référence et relation de page requise. |
| Les IDs numériques source peuvent être copiés comme références. | Les références CMS doivent pointer vers les identités Data Item cible. | Les anciens IDs deviennent des valeurs littérales sans sens. | Enregistrements liés et pages dynamiques se déconnectent. | Traduire les relations source en champs de référence cible. | Chaque relation parent-enfant ou plusieurs-à-plusieurs se résout dans Wix CMS. |
| Mettre à jour un item préserve les valeurs non spécifiées. | Certaines opérations de mise à jour remplacent le contenu lorsque des champs sont omis. | Une synchronisation partielle supprime des données par erreur. | Les systèmes externes effacent des champs qu’ils ne possèdent pas. | Définir la responsabilité des champs et un fonctionnement de mise à jour sûr pour les intégrations durables. | Les mises à jour ne changent que les champs possédés par le système éditeur. |
| Les données CMS reflètent immédiatement chaque écriture partout. | La récupération peut être finalement cohérente dans certains processus. | Automatisations ou lectures du front-end agissent sur un état périmé. | Actions dupliquées ou incohérence temporaire apparaissent. | Concevoir les intégrations pour tolérer la propagation et s’appuyer sur un événement/état faisant autorité. | Les processus sensibles au temps ne reposent pas sur une lecture immédiate après écriture. |
| CMS peut remplacer Product, Order ou domaines applicatifs. | CMS est un stockage flexible mais ne reproduit pas Wix Stores ni le fonctionnement des applications. | Les enregistrements e-commerce ou participants sont dupliqués dans un modèle parallèle non gouverné. | Les équipes maintiennent des sources de vérité conflictuelles. | Utiliser CMS uniquement lorsqu’il est le véritable propriétaire cible, non comme table générique de débordement. | Chaque entité possède un système de référence déclaré. |
Le risque CMS est maîtrisé lorsque schéma, références, permissions, routes et code qui consomment les données sont traités comme une seule chaîne de dépendances.
Risque lié aux pages, URLs, contenu multilingue et SEO
La structure d’un site Wix peut inclure pages statiques, pages dynamiques, routes Product et Category, Blog Posts, menus, médias, formulaires, versions multilingues, domaines, métadonnées SEO et redirections. Les routes et structures de page builder de la boutique source ne se traduisent pas nécessairement directement.
| Dépendance source | Contrainte Wix | Conséquence sur la migration | Impact opérationnel | Orientation de mitigation | Signal de contrôle |
|---|---|---|---|---|---|
| Les enregistrements Product ou Category recréent la navigation. | Categories, menus, pages et routes dynamiques Wix sont liés mais distincts. | Le catalogue existe sans le parcours de découverte prévu. | Les acheteurs ne trouvent pas les Products importants. | Attribuer séparément la responsabilité de navigation/atterrissage et l’appartenance aux Categories. | Les parcours acheteur prioritaires atteignent le Product ou la Category cible prévus. |
| Les URLs source peuvent rester automatiquement identiques. | Les routes dépendent des structures de pages, catalogue, langues et domaines Wix. | Des chemins à forte valeur changent sans continuité. | Trafic de recherche, backlinks et favoris échouent. | Définir destinations canoniques et relations de redirection pour les URLs prioritaires. | Les anciens chemins prioritaires résolvent vers des ressources cibles utilisables. |
| Les données de page builder sont du contenu portable. | Sections Wix, composants, pages dynamiques, applications et code définissent la présentation. | Le texte est transféré mais formulaires, requêtes, interactions et relations de mise en page disparaissent. | Parcours de contenu et conversion deviennent incomplets. | Séparer contenu/médias durables de la présentation et du fonctionnement cible. | Chaque page clé possède un propriétaire opérationnel du contenu, de la route et de l’interaction. |
| La langue n’est qu’un champ de l’enregistrement source. | Le multilingue peut nécessiter routes, pages, items CMS, menus et valeurs Catalog coordonnées. | Les traductions existent mais ne sont pas reliées à l’expérience linguistique prévue. | Les utilisateurs voient contenu dans la mauvaise langue ou des doublons. | Préserver identité de traduction et contexte de route chez les propriétaires pertinents. | Chemins linguistiques et contenu associé sont cohérents pour les parcours prioritaires. |
| Le transfert média préserve les références intégrées. | Contenu, médias Product, items CMS et applications peuvent référencer les ressources différemment. | Les fichiers existent mais les pages ou Products pointent vers d’anciens chemins. | Images et téléchargements cassés réduisent la confiance. | Traduire les relations de pièces jointes et liens intégrés avec l’enregistrement propriétaire. | Les routes représentatives affichent les ressources prévues sans dépendance au domaine source. |
Le signal de contrôle est la continuité du parcours acheteur et contenu, non un nombre identique de pages ou fichiers médias.
Applications, Velo, service plugins et systèmes externes
Le code Velo, les applications Wix, service plugins, webhooks et systèmes externes peuvent calculer des prix, valider des saisies, interroger des collections CMS, gérer memberships, synchroniser Products, publier le stock ou modifier le traitement. Leurs enregistrements et leur logique ne font pas automatiquement partie du cœur Wix Stores.
| Hypothèse de dépendance | Contrainte Wix | Conséquence sur la migration | Impact opérationnel | Orientation de mitigation | Signal de contrôle |
|---|---|---|---|---|---|
| Des applications similaires ont des enregistrements compatibles. | Chaque application définit ses entités, permissions, identifiants et cycle de vie. | Les données sont déplacées vers des champs génériques sans propriétaire applicatif fonctionnel. | Soldes, calendriers, memberships ou historique disparaissent. | Relier l’entité source réelle à l’application Wix ou au propriétaire externe prévu. | L’application durable reconnaît son Contact, Product ou Order parent. |
| Le code Velo peut être copié comme donnée. | Le code dépend des APIs Wix, schémas CMS, événements, permissions et secrets. | Les scripts arrivent sans dépendances valides ni responsabilité cible. | Les règles métier échouent silencieusement ou produisent des données incohérentes. | Recréer uniquement le fonctionnement nécessaire selon le schéma cible et les APIs prises en charge. | Le fonctionnement possède un responsable identifié et aucune dépendance source inexpliquée. |
| Les IDs externes peuvent être régénérés. | ERP, CRM, PIM, WMS, marketplace et comptabilité peuvent utiliser des clés stables. | La synchronisation se rattache à des doublons ou aux mauvais enregistrements. | Les opérations de stock, Customer et Order divergent. | Préserver les identifiants au même niveau d’entité que celui utilisé par le système faisant autorité. | Une recherche externe aller-retour résout un unique enregistrement Wix prévu. |
| Un champ personnalisé reproduit une automatisation. | Les champs stockent des valeurs ; automatisations et service plugins exécutent le fonctionnement. | La donnée survit sans la règle qui la consomme. | Les équipes voient des valeurs obsolètes ou trompeuses. | Attribuer séparément responsabilité de la valeur et responsabilité du fonctionnement. | Le processus durable met à jour et interprète correctement le champ. |
| La disponibilité d’une API garantit l’équivalence des modèles. | Les APIs exposent des ressources et comportements de cohérence définis, non une sémantique source arbitraire. | Le périmètre repose sur la connectivité plutôt que sur une responsabilité compatible. | Des relations manquantes apparaissent après implémentation. | Évaluer la compatibilité des entités et cycles de vie avant de s’appuyer sur l’API. | Chaque intégration durable possède une carte définie d’entités source et cible. |
Ce domaine concerne développeurs, administrateurs d’applications et responsables métier. La mitigation structurelle est une carte des dépendances applicatives avec IDs parent stables et responsabilité explicite du fonctionnement.
Matrice de responsabilité et de contrôle des risques
| Domaine de risque | Responsable principal | Impact métier si non maîtrisé | Orientation de mitigation | Signal de contrôle |
|---|---|---|---|---|
| Filiation Catalog | Responsable catalogue et intégration | Products et variantes dupliqués ou mal identifiés | Définir filiation V1/V3 et identité de variante universelle. | Chaque article vendable source se résout une seule fois dans Catalog V3. |
| Options et modifiers | Responsable catalogue et traitement | Fausses variantes ou personnalisation perdue | Classifier les choix selon effet sur identité, stock et données Order. | Les sélections acheteur produisent la variante ou le modifier prévu. |
| Stock | Responsable opérations de stock | Survente et mauvais emplacement | Protéger la granularité variante-emplacement et l’autorité externe du stock. | Quantités d’ouverture et continues atteignent l’Inventory Item prévu. |
| Contacts et Members | Responsable opérations Customer | Mauvaises fusions, erreurs d’accès et historique applicatif cassé | Préserver identité, accès, consentement et relations applicatives en couches. | Les identités à forte valeur ou ambiguës se résolvent correctement. |
| Orders | Service Customer et finance | Historique illisible ou hypothèses opérationnelles dangereuses | Préserver instantanés historiques et éléments liés de transaction/traitement. | Les anciens Orders complexes sont explicables de bout en bout. |
| CMS et site | Responsable site et contenu | Pages dynamiques, routes et références cassées | Définir ensemble schéma, références, pages, permissions et URLs. | Les parcours statiques/dynamiques prioritaires se résolvent correctement. |
| Applications et Velo | Responsable application ou ingénierie | Fonctionnement perdu et intégrations cassées | Reconstruire le fonctionnement selon entités cibles et IDs stables. | Les processus durables reconnaissent et mettent à jour les enregistrements prévus. |
La matrice identifie les responsabilités de contrôle pour que l’implémentation et les vérifications suivent les relations déclarées au lieu d’inventer une nouvelle responsabilité pendant l’exécution.
Conclusion
Les contraintes d’une migration vers Wix proviennent de l’interaction entre plateforme gérée de création de site, Catalog V3, variantes universelles, Inventory Items par variante et emplacement, Contacts, Members, Orders, collections CMS, applications, Velo et systèmes externes. Les risques les plus sérieux apparaissent lorsque ces domaines sont traités comme une seule base de données ou lorsque des hypothèses Catalog V1 et V3 sont mélangées.
Une migration maîtrisée protège la filiation Product, distingue options et modifiers, attribue le stock à la bonne variante et au bon emplacement, sépare l’identité Contact des relations Member et applicatives, préserve les Orders historiques sans leur donner d’autorité active, et traite CMS, site et fonctionnement applicatif comme des domaines de responsabilité explicites. Ces contrôles transforment des avertissements génériques en chaînes spécifiques reliant cause et impact.
Questions fréquentes
Pourquoi Catalog V1 et Catalog V3 créent-ils un risque de migration ?
Catalog V3 utilise des variantes universelles et sépare plus explicitement Products, Customizations, Inventory Items, emplacements et autres services du catalogue. Réutiliser des hypothèses ou identifiants V1 sans carte de filiation peut créer Products dupliqués, stock manquant ou intégrations cassées.
Quel est le risque de traiter les modifiers Wix comme des options Product ?
Les options créent des variantes et influencent SKU, prix et identité de stock. Les modifiers collectent des informations supplémentaires sans créer de variantes. Les confondre peut générer de fausses combinaisons de stock ou supprimer l’identité réelle de la variante achetée.
Pourquoi un Product Wix peut-il exister sans fonctionnement de stock complet ?
Les relations Product et Inventory Item peuvent être créées séparément, et le stock suivi est propre à une variante et un emplacement. Un Product visible ne prouve pas que chaque variante suivie possède l’Inventory Item et l’affectation d’emplacement prévus.
Contacts, Members et Customers Wix sont-ils la même entité ?
Non. Un Contact apporte identité et contexte CRM, un Member ajoute des relations de compte ou d’accès, le commerce crée un contexte Customer et Order, et les applications Wix peuvent posséder des enregistrements distincts de participant ou de droit. Ils doivent rester reliés sans être aplatis.
Les Orders historiques peuvent-ils prouver que le processus de commande et le traitement Wix actuels sont prêts ?
Non. Les Orders historiques préservent articles achetés, détails de paiement, informations d’expédition et état de traitement. Prestataires actifs, Order Settings, mises à jour de stock, notifications, règles de livraison et services de traitement restent de la configuration actuelle.
Quand les données personnalisées source doivent-elles utiliser Wix CMS plutôt qu’une application Wix ou un système externe ?
Utilisez CMS lorsque la collection est le véritable propriétaire de données structurées du site et que son schéma, ses références, permissions, pages et mécanismes de mise à jour sont définis. Les enregistrements spécialisés de commerce, membership, planification ou transaction doivent rester avec l’application ou le système externe qui possède leur cycle de vie.