Les migrations vers Wix échouent lorsque Wix Stores, le CMS, les membres du site, les applications, le contenu multilingue, la logique Velo et les automatisations sont traités comme une seule couche de données interchangeable. Ces systèmes peuvent afficher des informations liées tout en conservant des règles distinctes de propriété, d’autorisation et de fonctionnement.
La prévention consiste à identifier le propriétaire de chaque enregistrement et de chaque fonction, à conserver les tableaux qui rendent ces limites visibles et à définir une condition de réussite concrète pour chaque scénario d’échec. Le résultat attendu est un site Wix et une boutique réellement utilisables, pas seulement un tableau de bord rempli de données.
Piège 1 : traiter Wix comme une boutique hébergée générique
Ce qui se passe mal
La migration est planifiée comme si Wix n’était qu’une destination pour les Products, les Customers et les Orders. L’équipe vérifie la présence des enregistrements, mais pas leur fonctionnement dans l’environnement Wix qui combine création de site et commerce. Les Products apparaissent dans le catalogue, tandis que l’affichage des pages, les collections, la navigation du site, la configuration du processus de commande, les contacts, les membres, le contenu CMS, les médias, les URL et les applications restent insuffisamment préparés.
Cette approche crée une fausse confiance avant le lancement. Le site cible peut contenir les enregistrements migrés alors que les clients ne parviennent pas à trouver certains Products, à choisir correctement leurs options, à accéder aux pages importantes, à finaliser une commande ou à suivre d’anciennes URL vers le nouveau site Wix.
Signaux d’alerte
| Signal d’alerte | Pourquoi c’est important |
|---|---|
| Le périmètre de migration ne mentionne que les Products, Customers et Orders. | La structure du site Wix, le contenu, les URL, les applications et la configuration risquent d’être absents de la préparation au lancement. |
| La vérification des Products se fait uniquement dans le tableau de bord. | L’affichage côté client et la découverte des Products peuvent encore échouer. |
| La conception du site, les menus, les domaines et les redirections sont repoussés à la fin. | Le parcours client dépend de bien plus que des enregistrements migrés. |
| Les applications, formulaires, membres, collections CMS ou la logique Velo ne sont pas inventoriés. | Des fonctions essentielles peuvent se trouver en dehors des enregistrements principaux de Wix Stores. |
Prévention
Planifiez Wix comme une destination qui combine site et commerce. Examinez les enregistrements du catalogue, les pages Product, l’affichage des collections, les parcours de navigation, les Pages CMS, les Blog Posts, les médias, la signification des Customers et des membres, les Orders historiques, les URL, les redirections, les domaines et les dépendances applicatives comme des domaines opérationnels liés entre eux.
Distinguez les enregistrements transférés du fonctionnement qui relève du marchand, de la configuration Wix, des développeurs, des fournisseurs d’applications et des systèmes externes. Cette séparation évite de confondre des lacunes de configuration côté cible avec des défauts de transfert de données.
Exemple de recommandation
Un marchand qui passe de Shopify à Wix devrait examiner, dans un même échantillon cohérent, un Product simple, un Product comportant de nombreuses variantes, une collection de Products, une page Product à fort trafic, un Blog Post, une Page CMS, un Order invité, un Customer récurrent, un enregistrement lié à un membre et une redirection prioritaire.
Condition de réussite
Le site Wix cible prend en charge les parcours de vente, de contenu, de Customer, d’historique des Orders et les processus opérationnels convenus. Les écarts restants ont un responsable explicite : correction des enregistrements, configuration Wix, implémentation personnalisée, travail sur un système externe, reconstruction manuelle ou exclusion acceptée.
Piège 2 : aplatir les Products, options, choix et variantes
Ce qui se passe mal
Le catalogue source est migré sous forme de Products Wix simples sans préserver le sens des options, choix, variantes, SKU propres aux variantes, prix, stocks, images, poids, personnalisations ou règles de Product propres à la source. Le nombre de Products peut sembler correct, alors que les clients et les équipes perdent une partie importante du contexte de sélection et d’achat.
Ce piège est fréquent lorsque l’ancienne boutique utilise des options de Product, des Products configurables, des options personnalisées, des bundles, des compléments de Product, des champs de personnalisation, des configurateurs ou des choix gérés par une application. Wix peut prendre en charge des options, des choix et des variantes, mais la signification du modèle source doit toujours être interprétée avec précision.
Signaux d’alerte
| Signal d’alerte | Pourquoi c’est important |
|---|---|
| Les options de Product ne sont pas distinguées des variantes. | L’affichage du choix peut fonctionner alors que le SKU, le prix, le stock ou le détail de l’Order devient incorrect. |
| Le stock propre à chaque variante n’est pas échantillonné. | Les quantités peuvent sembler exactes uniquement au niveau du Product parent. |
| Les médias Product sont validés uniquement par nombre de fichiers. | Les images peuvent ne pas apparaître dans le bon contexte de Product ou de choix. |
| Les bundles, personnalisations ou options payantes sont décrits comme de simples données Product. | Le besoin peut nécessiter une implémentation personnalisée, une configuration d’application, du travail Velo/API ou une reconstruction manuelle. |
Prévention
Constituez un ensemble représentatif de Products avant le basculement. Incluez des Products simples, des Products comportant de nombreuses variantes, des Products avec des prix différents selon les variantes, des SKU différents selon les variantes, des variantes sensibles au stock, des Products riches en médias, des Products affectés à des collections importantes et des Products contrôlés par des applications ou une logique personnalisée.
Classez les comportements complexes de la source avant d’accepter le périmètre. Des champs Product explicites peuvent correspondre à une mise en correspondance directe. Une logique Product détenue par une application, des configurateurs personnalisés, des transformations spécifiques ou un fonctionnement de catalogue externe nécessitent une configuration Wix, une implémentation personnalisée, une prise en charge par un système externe ou une exclusion délibérée.
Exemple de recommandation
Un Product source possède des variantes de couleur et de taille, des images propres aux options, des SKU distincts et des quantités de stock séparées. L’échantillon de validation Wix doit confirmer non seulement l’existence du Product, mais aussi la conservation du SKU, du prix, de l’image, du stock et du sens de la ligne d’Order pour chaque variante.
Condition de réussite
Les Products Wix représentatifs peuvent être trouvés, affichés, sélectionnés, ajoutés au panier et vérifiés dans l’historique des Orders avec le sens attendu pour les options, choix, variantes, SKU, prix, images et stocks.
Piège 3 : confondre les collections avec l’ensemble de la navigation du site
Ce qui se passe mal
Les anciennes catégories, collections, menus, filtres, pages d’atterrissage et groupes de merchandising sont traités comme un même objet. La migration peut créer les collections Wix, tandis que les clients perdent encore des parcours de navigation, la logique des menus, des pages d’atterrissage SEO ou des relations avec les pages de campagne.
Les collections Wix sont importantes pour regrouper les Products, mais l’expérience complète du site dépend également des pages, menus, sections dynamiques, galeries de Products, liens internes, recherche, redirections et de la conception des pages. La migration des collections ne recrée pas à elle seule le modèle de découverte de l’ancienne boutique.
Signaux d’alerte
| Signal d’alerte | Pourquoi c’est important |
|---|---|
| La migration des catégories est considérée comme équivalente à la migration de la navigation. | Les clients peuvent ne plus atteindre les bons Products après le lancement. |
| Les anciennes pages d’atterrissage ne figurent pas dans l’examen des URL. | Des parcours de trafic à forte valeur peuvent être perdus. |
| Les groupes de Products sont validés sans vérifier les menus ni les liens. | Les collections Wix peuvent exister tout en restant déconnectées du parcours client. |
| Les règles de filtrage ou de merchandising sont supposées être transférées automatiquement. | Le fonctionnement source peut nécessiter une configuration Wix, une logique applicative ou un travail manuel sur les pages. |
Prévention
Séparez les données de collection des décisions de navigation du site. Validez séparément l’affectation Product-collection, l’affichage des galeries de Products, les liens de menu, les liens internes, les pages d’atterrissage, les redirections, la recherche et les parcours à fort trafic parmi les responsabilités de lancement Wix.
Une prévention solide associe chaque rôle des anciennes catégories et collections à un résultat Wix : regroupement de Products, entrée de menu, page d’atterrissage, destination de redirection, page de contenu, page CMS dynamique ou page retirée.
Exemple de recommandation
Une catégorie source appelée « Summer Essentials » pouvait servir à la fois de groupe de Products, de lien de campagne sur la page d’accueil, de page d’atterrissage SEO et de destination d’une campagne e-mail. Dans Wix, elle peut nécessiter une collection, une page d’atterrissage, un emplacement dans le menu, une redirection et un suivi analytique après lancement.
Condition de réussite
Les parcours importants de découverte des Products sont recréés, redirigés, retirés volontairement ou affectés à une configuration Wix. Les collections sont validées comme groupes de Products, et la navigation comme structure du site visible par les clients.
Piège 4 : considérer les Orders historiques comme une preuve que le processus de commande est prêt
Ce qui se passe mal
La migration des Orders historiques est utilisée pour conclure que le processus de commande Wix est prêt. Les Orders migrés peuvent conserver les anciens Products, libellés de paiement, informations de livraison, remboursements, remises, taxes, statuts de traitement, notes et liens Customer, mais ils ne configurent pas les futurs prestataires de paiement, champs du processus de commande, règles de livraison, taxes, remises, notifications, processus de traitement ni paramètres d’Order.
Le risque de lancement est important : les équipes peuvent consulter les anciens Orders alors que la boutique cible n’est pas encore capable de traiter correctement les nouvelles commandes.
Signaux d’alerte
| Signal d’alerte | Pourquoi c’est important |
|---|---|
| Les échantillons d’Orders historiques sont considérés comme des tests du processus de commande. | Les données passées ne prouvent pas que le futur parcours d’achat Wix fonctionne. |
| Les libellés de paiement sont pris pour une configuration du prestataire de paiement. | La configuration des paiements doit être réalisée et testée dans Wix. |
| Les valeurs de livraison et de taxe ne sont vérifiées que dans les anciens Orders. | Le futur calcul peut encore être incomplet. |
| Les règles personnalisées du processus de commande ne sont pas recensées. | Des frais, validations ou règles de livraison propres à la source peuvent nécessiter des applications, des service plugins, du travail Velo/API ou une implémentation personnalisée. |
Prévention
Validez séparément les Orders historiques et le processus de commande actif. La validation des Orders historiques doit couvrir l’identité de l’Order, les lignes, les totaux, remises, taxes, livraison, libellés de paiement, remboursements, contexte de traitement, notes et liens Customer. La validation du processus de commande actif doit tester le parcours d’achat Wix configuré, le paiement, la livraison, les taxes, les remises, le traitement et les notifications.
Si la boutique source utilisait une logique personnalisée au moment de la commande, documentez si ce fonctionnement relève de la configuration Wix, d’une application, d’une implémentation de service plugin, d’une implémentation personnalisée ou d’une exclusion.
Exemple de recommandation
Un marchand possède d’anciens Orders dont les frais de livraison locale étaient calculés selon des zones personnalisées. Ces montants historiques peuvent être migrés comme données lisibles, mais la future tarification de livraison locale doit être configurée et testée séparément dans Wix.
Condition de réussite
Les Orders historiques sont lisibles et utiles pour le support, tandis que le futur processus de commande Wix a été configuré et testé séparément pour les paiements, la livraison, les taxes, les remises, le traitement et les communications avec les clients.
Piège 5 : mal interpréter les Customers, contacts, membres et participants d’applications
Ce qui se passe mal
Les comptes clients de la source sont importés sans distinguer les Customers, contacts, membres, abonnés, acheteurs invités, utilisateurs de programmes de fidélité, participants à des réservations, utilisateurs de formules payantes ou identités propres à une application. Wix peut stocker ou exposer ces significations par l’intermédiaire de fonctions ou d’applications différentes. Un contact migré ne recrée donc pas automatiquement l’accès au compte, le fonctionnement de l’adhésion, la participation à un programme de fidélité ni le statut marketing.
Cela peut créer des problèmes de support et d’expérience client après le lancement. Les équipes voient un enregistrement sans savoir s’il représente un acheteur, un membre du site, un contact, un abonné ou un participant d’application.
Signaux d’alerte
| Signal d’alerte | Pourquoi c’est important |
|---|---|
| Le nombre de Customers est utilisé comme preuve de continuité des identités. | Les volumes ne confirment pas les relations de compte, de membre, d’Order ou de CRM. |
| Les acheteurs invités ne sont pas échantillonnés. | Leur historique d’Orders peut se comporter différemment de celui des Customers enregistrés. |
| Les membres et les contacts sont traités comme une seule notion. | Les règles d’accès et le contexte CRM peuvent nécessiter des traitements Wix différents. |
| La fidélité, les abonnements, les réservations ou les formules payantes sont supposés migrer automatiquement. | Les données détenues par des applications nécessitent souvent un examen ou une configuration séparés. |
Prévention
Définissez les catégories d’identité avant la migration. Séparez les Customers, acheteurs invités, contacts, membres, abonnés, participants à des formulaires, participants à des réservations, utilisateurs de fidélité, membres de formules payantes, enregistrements wholesale et identifiants CRM externes. Affectez ensuite chaque catégorie à une mise en correspondance d’enregistrements principaux, une configuration Wix, un import d’application, une implémentation personnalisée, un travail sur un système externe, une reconstruction manuelle ou une exclusion.
La validation doit inclure des acheteurs récurrents, des acheteurs invités, des Customers avec plusieurs adresses, des membres ayant des exigences d’accès, des Customers liés à des Orders et des exemples d’identités propres aux applications.
Exemple de recommandation
Une boutique source contient des Customers, des abonnés à la newsletter, des acheteurs wholesale, des membres payants et des utilisateurs d’un programme de fidélité. Le périmètre Wix ne doit pas traiter tous ces enregistrements comme une seule entité Customer. Chaque type d’identité doit avoir son résultat cible et son échantillon de validation propres.
Condition de réussite
Les relations migrées entre Customers, contacts, membres et historique des Orders dans Wix correspondent au périmètre convenu. Les comportements d’identité, d’accès ou de CRM propres aux applications sont implémentés, examinés séparément ou documentés comme exclus.
Piège 6 : oublier les Pages CMS, Blog Posts, médias, URL et la continuité SEO
Ce qui se passe mal
La migration conserve les Products mais affaiblit l’expérience du site Wix. Les Pages CMS, Blog Posts, pages dynamiques, médias, images Product, pages de collection, pages d’atterrissage, menus, liens internes, redirections, titres de pages, méta-descriptions, textes alternatifs, attentes de canonicalisation, domaines, parcours multilingues et mise en page mobile peuvent ne pas être conservés comme prévu s’ils ne font pas partie du périmètre et du plan de validation.
Ce piège est particulièrement sérieux pour les boutiques qui dépendent du référencement naturel, de guides d’achat détaillés, d’une stratégie de vente fondée sur le contenu, de pages de campagne ou d’un trafic important provenant du blog.
Signaux d’alerte
| Signal d’alerte | Pourquoi c’est important |
|---|---|
| Le SEO est examiné uniquement au niveau des Products. | Les risques liés aux pages, Blog Posts, collections, redirections et liens internes peuvent subsister. |
| Le transfert des médias est considéré comme une preuve que les pages sont prêtes. | Les fichiers image peuvent exister sans placement correct, contexte alternatif ni mise en page adéquate. |
| Les redirections et les étapes liées au domaine sont reportées au jour du lancement. | Le trafic de recherche, les favoris, les outils d’analyse et les liens de campagne peuvent être rompus. |
| Les Blog Posts ou Pages CMS ne sont pas échantillonnés. | Des pertes de contenu peuvent n’apparaître qu’après le lancement. |
Prévention
Créez une liste de validation du contenu et du SEO. Incluez les pages Product prioritaires, pages de collection, Pages CMS, Blog Posts, pages riches en médias, liens internes, parcours de menu, URL à forte valeur, redirections, titres de pages, méta-descriptions, contexte des textes alternatifs, attentes de canonicalisation, étapes liées au domaine et tâches de présentation mobile.
Distinguez le contenu transféré du travail de conception Wix. La reconstruction des mises en page, l’optimisation mobile, la stratégie des menus, la refonte visuelle et le travail sur le domaine restent des responsabilités côté Wix ou des tâches d’implémentation personnalisée.
Exemple de recommandation
Un marchand possède des guides d’achat, des tutoriels de blog et des pages de catégorie Product bien classées dans les moteurs de recherche. Le plan de prévention Wix doit inclure la correspondance des URL prioritaires, l’échantillonnage du contenu, la validation des Blog Posts, l’examen des liens internes, la préparation des redirections, le contrôle des médias et la vérification mobile avant lancement.
Condition de réussite
Les Products, pages, Blog Posts, médias, menus, redirections, métadonnées et liens internes prioritaires sont validés dans Wix. Les tâches de design, mise en page, domaine, outils d’analyse et SEO situées hors du périmètre de migration sont affectées avant le lancement.
Piège 7 : supposer que les applications, la logique Velo, les service plugins et les systèmes externes sont des données standard
Ce qui se passe mal
Les applications, la logique Velo/API, les collections CMS, catalogues personnalisés, service plugins, règles personnalisées du processus de commande, frais personnalisés, intégrations de tarifs d’expédition, services de paiement externes, connexions ERP/CRM/PIM/WMS/comptabilité ou références de marketplace sont traités comme de simples champs de catalogue, Customer ou Order. La boutique cible peut réussir les contrôles de migration élémentaires alors que des processus essentiels ne fonctionnent plus.
L’extensibilité de Wix ne rend pas chaque fonction transférable sous forme de données ordinaires. Certaines fonctions relèvent de la configuration des applications Wix, des autorisations CMS, du code Velo, des automatisations, des intégrations externes, d’une reconstruction manuelle ou d’une exclusion délibérée.
Signaux d’alerte
| Signal d’alerte | Pourquoi c’est important |
|---|---|
| Les enregistrements détenus par les applications ne sont pas inventoriés séparément. | Des données importantes peuvent ne pas appartenir au périmètre principal de migration Wix Stores. |
| Le fonctionnement Velo/API est décrit sans exemples. | Une logique pilotée par du code ne peut pas être validée comme de simples enregistrements. |
| Le fonctionnement des service plugins est déduit des données historiques. | Les règles de commande, livraison, paiement et traitement peuvent nécessiter une implémentation. |
| Les systèmes externes ne sont testés qu’après le lancement. | Les processus opérationnels peuvent échouer une fois le trafic redirigé vers Wix. |
Prévention
Inventoriez toutes les dépendances personnalisées et externes avant la migration. Pour chaque application, champ personnalisé, collection CMS, script, fonctionnement de service plugin et système externe, identifiez le responsable, la finalité métier, l’exemple source, le résultat Wix attendu, le mode de prise en charge et l’élément de validation.
Utilisez la mise en correspondance de champs prise en charge uniquement pour les relations d’enregistrements explicites. Les enregistrements détenus par des applications, le fonctionnement Velo/API, les identifiants externes, les transformations spécifiques et les dépendances de systèmes externes nécessitent une application cible, une implémentation personnalisée, un responsable d’intégration ou une exclusion délibérée.
Exemple de recommandation
Une boutique source utilise un configurateur de Product, une application de fidélité et une synchronisation ERP. Les enregistrements Product peuvent migrer vers Wix, mais le fonctionnement du configurateur, les soldes de fidélité et la synchronisation ERP doivent être traités séparément. Ils peuvent nécessiter une configuration d’application Wix, du travail Velo/API, une implémentation sur un système externe, une reconstruction manuelle ou une exclusion acceptée.
Condition de réussite
Toutes les dépendances liées aux applications, Velo/API, collections CMS, systèmes externes et données personnalisées ont un propriétaire déclaré et un résultat cible utilisable distinct des enregistrements principaux de Wix Stores.
Piège 8 : traiter les collections Wix CMS comme des données du catalogue Wix Stores
Ce qui se passe mal
Les collections CMS personnalisées et les collections des applications Wix sont traitées comme des espaces interchangeables pour stocker les données Product. Une équipe peut voir des Products, stocks, Orders ou membres exposés dans des vues CMS et supposer que ces collections peuvent être importées, modifiées ou soumises aux mêmes autorisations que des collections personnalisées ordinaires. La cible peut alors contenir des données dupliquées, des enregistrements en lecture seule, des pages dynamiques déconnectées ou des formulaires qui écrivent dans la mauvaise collection.
Wix Stores et les autres applications sont propriétaires de leurs collections applicatives. Les collections CMS personnalisées peuvent prendre en charge des modèles de contenu distincts, mais elles ne deviennent pas automatiquement le catalogue opérationnel Wix Stores.
Signaux d’alerte
| Signal d’alerte | Pourquoi c’est important |
|---|---|
| Une collection personnalisée est proposée comme destination des Products importés de la boutique. | L’affichage des Products peut être reconstruit sans le fonctionnement commercial de Wix Stores. |
| Les collections d’applications Wix sont traitées comme des tables personnalisées modifiables. | Les enregistrements détenus par une application peuvent être en lecture seule ou soumis à des autorisations fixes. |
| Des pages dynamiques affichent un contenu ressemblant à des Products depuis une collection personnalisée. | La page peut sembler correcte alors que les relations avec le panier, le stock et les Orders sont absentes. |
| Des formulaires ou du code Velo écrivent directement dans une collection sans décision de propriété. | Les données peuvent contourner l’application qui devrait les gouverner. |
Prévention
Associez chaque collection à son propriétaire et à son objectif. Les collections applicatives Wix Stores doivent rester gouvernées par Wix Stores. Les collections CMS personnalisées ne doivent être utilisées que lorsqu’elles représentent un modèle de contenu distinct avec des champs, autorisations, pages dynamiques et une logique d’intégration définis. Ne dupliquez pas des données Product opérationnelles sauf si cette duplication possède un responsable de synchronisation et un objectif métier explicites.
| Type de collection | Utilisation appropriée | Contrôle principal |
|---|---|---|
| Collection applicative Wix Stores | Afficher ou référencer des données commerciales détenues par l’application. | Gérer les données opérationnelles via Wix Stores. |
| Collection CMS personnalisée | Contenu structuré, annuaires, ressources ou processus personnalisés. | Définir les champs, autorisations, pages dynamiques et la propriété des données. |
| Collection privée de membres | Enregistrements ou soumissions propres aux membres. | Préserver les rôles et les règles d’accès au niveau de l’élément. |
| Miroir d’un système externe | Utilisation pour les rapports ou les intégrations. | Définir la synchronisation, les identifiants et la gestion des conflits. |
Exemple de recommandation
Une boutique source possède un guide comparatif personnalisé lié aux Products. Importez les Products dans Wix Stores et les enregistrements du guide dans une collection CMS personnalisée. Reliez-les à l’aide d’identifiants stables ou de références explicites ; ne reconstruisez pas le catalogue Product dans la collection du guide simplement parce que les deux apparaissent sur des pages dynamiques.
Condition de réussite
Chaque collection possède un propriétaire, un objectif, un modèle d’autorisation et un circuit de mise à jour déclarés. Les Products opérationnels restent gouvernés par Wix Stores, tandis que le contenu CMS personnalisé ne prend en charge que le comportement distinct qu’il est destiné à gérer.
Piège 9 : aplatir le contenu multilingue et les relations entre URL
Ce qui se passe mal
Les langues sont migrées comme de simples valeurs de texte dupliquées sans préserver la relation entre le contenu principal, le contenu traduit, les champs SEO propres à chaque langue et les URL localisées. Les traductions de Products, noms de Categories, textes du processus de commande, contenu CMS et redirections peuvent devenir incomplets ou diriger les visiteurs vers la mauvaise version linguistique.
Une liste unique de redirections est particulièrement risquée lorsque les anciens chemins diffèrent selon la langue ou lorsque la cible utilise une structure d’URL multilingue différente.
Signaux d’alerte
| Signal d’alerte | Pourquoi c’est important |
|---|---|
| Les traductions sont stockées sans relation avec un enregistrement principal. | Les mises à jour peuvent créer des versions linguistiques incohérentes ou orphelines. |
| Les traductions de Products et Categories sont examinées séparément des textes du processus de commande et des e-mails. | Le parcours d’achat peut changer de langue de manière inattendue. |
| Les redirections sont préparées sans colonne de langue ni vérification de destination. | Les visiteurs peuvent arriver sur la page dans la langue par défaut ou sur un chemin cassé. |
| Les URL de pages CMS dynamiques sont supposées se traduire exactement comme celles des Pages ordinaires. | Le fonctionnement des URL peut différer selon le type de contenu. |
Prévention
Créez une carte des relations linguistiques couvrant les Products, Categories, contenu CMS, Blog Posts, menus, textes du processus de commande, textes d’e-mails, champs SEO et redirections. Définissez la langue principale, la propriété des traductions, le fonctionnement de repli et la structure d’URL cible. Examinez les redirections dans le bon contexte linguistique au lieu de les traiter comme une liste unique et indifférenciée pour tout le site.
| Couche multilingue | Décision de prévention |
|---|---|
| Textes Product et Category | Préserver la relation avec l’enregistrement commercial principal. |
| Contenu CMS et Blog | Mettre en correspondance les champs traduits et les pages qui les affichent. |
| URL et redirections | Affecter les anciens et nouveaux chemins selon la langue et la pertinence de la destination. |
| Processus de commande et communications | Configurer les libellés, e-mails et messages opérationnels traduits. |
Exemple de recommandation
Une boutique possède des pages Product en anglais et en français avec des chemins historiques différents. Associez les deux versions linguistiques à la même identité Product dans Wix Stores, puis créez les redirections adaptées à chaque langue et vérifiez que la navigation, le texte Product, les libellés du processus de commande et les e-mails restent en français sur le parcours français.
Condition de réussite
Des parcours représentatifs restent cohérents dans chaque langue, de la page d’arrivée à la découverte du Product puis au processus de commande. Les traductions restent rattachées aux bons enregistrements et les URL historiques prioritaires mènent à des destinations pertinentes dans la langue prévue.
Piège 10 : supposer que les automatisations et notifications Wix suivent les enregistrements migrés
Ce qui se passe mal
Les Products, contacts, membres, Orders, formulaires ou enregistrements CMS apparaissent dans Wix et l’équipe suppose que les automatisations associées vont recommencer à fonctionner automatiquement. En réalité, les automatisations Wix dépendent de déclencheurs, actions, conditions, temporisations et applications configurés, et parfois de code Velo ou de connexions webhook. Les données historiques ne recréent pas ces définitions de processus.
Cela peut entraîner des défaillances opérationnelles silencieuses : les Customers ne reçoivent aucune confirmation, les tâches internes ne sont pas créées, les prospects ne sont pas distribués ou les systèmes externes ne reçoivent plus les événements attendus.
Signaux d’alerte
| Signal d’alerte | Pourquoi c’est important |
|---|---|
| La source possède des processus de panier abandonné, d’Order, de formulaire, d’adhésion ou de prospect sans inventaire correspondant côté cible. | Des déclencheurs et actions importants peuvent manquer. |
| Les notifications sont déduites d’anciens e-mails ou de notes d’Order. | Les sorties passées ne révèlent pas la définition complète du processus. |
| Les applications sont installées après la préparation des automatisations. | Les déclencheurs et actions disponibles peuvent varier selon l’ensemble d’applications installé. |
| Les webhooks ou actions Velo n’ont ni responsable ni examen des journaux d’exécution. | Des processus externes peuvent échouer sans erreur visible sur le site. |
Prévention
Inventoriez chaque automatisation essentielle par déclencheur, conditions, actions, temporisation, audience, dépendance applicative, champs de données et point de terminaison externe. Ne reconstruisez que les processus qui répondent encore à un besoin métier actuel. Après configuration, utilisez des événements réels représentatifs pour confirmer le déclenchement, l’application correcte des conditions, l’exécution complète des actions et la réception des données attendues par les systèmes externes.
| Type de processus | Contrôle requis |
|---|---|
| Automatisation liée aux Orders ou au panier | Confirmer le déclencheur Wix Stores, les données Customer, le message, la temporisation et la gestion des exceptions. |
| Automatisation de formulaire ou de prospect | Confirmer la source du formulaire, la correspondance des champs, l’affectation et l’action de suivi. |
| Automatisation de membre | Confirmer le rôle, l’événement d’accès, la notification et l’état d’adhésion. |
| Processus webhook ou Velo | Confirmer le point de terminaison, la charge utile, l’authentification, la gestion des erreurs et le journal d’exécution. |
Exemple de recommandation
Une boutique source envoie un e-mail aux équipes lorsqu’un Order de forte valeur est passé et transmet les données de l’Order à un ERP. Reconstruisez la notification interne et la transmission externe comme deux processus Wix distincts, puis déclenchez un Order représentatif et confirmez à la fois l’action interne et la charge utile externe.
Condition de réussite
Chaque automatisation essentielle possède un déclencheur actif, des conditions correctes, des actions complètes, un responsable et des éléments de validation issus d’un événement représentatif. Les enregistrements migrés ne sont pas considérés comme une preuve que le processus lui-même existe.
Priorités de prévention communes aux différents pièges
| Domaine de contrôle | Priorité de prévention | Élément de validation |
|---|---|---|
| Catalogue Wix Stores | Préserver les relations entre Products, options, variantes, médias, stocks et Categories. | Des Products représentatifs restent sélectionnables, achetables et compréhensibles sur le plan opérationnel. |
| Découverte sur le site | Relier intentionnellement Categories, menus, Pages, Blog Posts, contenu CMS et pages dynamiques. | Les clients peuvent passer du contenu et de la navigation aux Products attendus. |
| Identités | Séparer les Customers, contacts, membres du site et participants d’applications selon leur usage. | Chaque type d’identité conserve le contexte de compte, d’accès ou de communication dont il a besoin. |
| Collections | Distinguer les collections applicatives Wix des collections CMS personnalisées et de leurs autorisations. | Chaque collection possède un propriétaire et un circuit de mise à jour déclarés. |
| Structure multilingue | Préserver le contenu traduit, les champs SEO, les URL et les redirections comme des parcours linguistiques liés. | Les parcours prioritaires restent cohérents dans chaque langue prise en charge. |
| Fonctionnement personnalisé | Inventorier les applications, Velo, service plugins, systèmes externes et champs personnalisés. | Chaque dépendance possède une implémentation cible ou une exclusion délibérée. |
| Automatisations | Reconstruire les déclencheurs, conditions, actions et intégrations séparément des enregistrements. | Des événements représentatifs exécutent correctement les processus internes et externes attendus. |
Conclusion
Les pièges d’une migration Wix peuvent être évités lorsque Wix Stores, les collections CMS, les membres du site, le contenu, le routage multilingue, les applications, la logique Velo et les automatisations sont considérés comme des systèmes liés mais gouvernés séparément. Un tableau de bord rempli ne suffit pas si les données appartiennent à la mauvaise collection, si les traductions perdent leurs relations ou si les déclencheurs des processus n’existent plus.
Une migration solide préserve la profondeur propre à la plateforme tout en offrant un parcours de lecture clair. Le texte explique les causes et les conséquences ; les tableaux clarifient les signaux d’alerte, les limites de responsabilité et les choix de prévention ; les conditions de réussite prouvent que le fonctionnement cible est réellement utilisable.
Questions fréquentes
Pourquoi Wix est-il plus qu’une simple boutique hébergée ?
Wix combine Wix Stores avec des Pages, du contenu Blog, des collections CMS, les membres du site, des applications, des fonctions multilingues, du code Velo et des automatisations. Ces couches peuvent référencer le même Customer ou Product tout en conservant des propriétaires et des autorisations différents.
Quel est le principal piège lié à la structure Product dans Wix Stores ?
Les options et variantes de la source ne se traduisent pas toujours directement en relations Wix entre Product, option, choix, variante, média, prix et stock. Évaluez les Products complexes selon leur fonctionnement réel à l’achat plutôt qu’en vous limitant au nombre de Products.
Les collections Wix CMS sont-elles identiques aux collections Wix Stores ?
Non. Les collections applicatives Wix exposent des données détenues par l’application concernée et restent gouvernées par cette application. Les collections CMS personnalisées possèdent leurs propres champs, autorisations et usages de pages dynamiques ; elles ne deviennent pas automatiquement un catalogue opérationnel de boutique.
Comment faut-il distinguer les Customers, contacts et membres du site ?
Classez chaque identité selon la fonction qu’elle doit prendre en charge : historique commercial, communication marketing, connexion au site, contenu restreint, fidélité, réservation ou autre relation propre à une application. Ne conservez que les significations disposant d’un propriétaire cible.
Pourquoi une migration Wix multilingue est-elle risquée ?
Les traductions, textes Product, contenu CMS, champs SEO, langue du processus de commande et redirections doivent rester liés aux bons enregistrements principaux et aux chemins propres à chaque langue. Une liste unique et générique de traductions ou de redirections ne suffit pas.
Les automatisations Wix reprennent-elles automatiquement lorsque les enregistrements sont migrés ?
Non. Les automatisations nécessitent des déclencheurs, conditions, actions, temporisations et dépendances applicatives configurés, et parfois du code Velo ou des webhooks. Reconstruisez-les puis déclenchez des événements représentatifs pour prouver leur fonctionnement.