Si Squarespace est retenu comme plateforme cible, la préparation doit d’abord établir comment le catalogue commercial s’intègre au site dans son ensemble avant toute exécution de migration. Chaque Product appartient à une Store Page, tandis que les Products physiques, de service, cartes-cadeaux et téléchargements suivent des règles différentes pour les variantes et les stocks. Contacts, Orders, Transactions, Pages, Blog Posts, navigation, extensions et design du site restent également des familles de données distinctes.
La préparation doit associer chaque action requise à un responsable, à des éléments de référence et à une condition claire indiquant qu’elle est prête. Cela évite de confondre un export Product complet avec une Store Page complète, un Contact avec un droit d’abonnement ou d’adhésion, ou des données de paiement historiques avec la configuration actuelle du processus d’achat.
Confirmer le modèle du site Squarespace et des Store Pages
Définissez la relation prévue entre le site, les Store Pages, les Products, le contenu, la navigation et les systèmes connectés.
| Domaine de préparation | Décision à consigner | Responsable | Élément prouvant que la préparation est prête |
|---|---|---|---|
| Structure du site | Domaines, paramètres régionaux, devise, navigation, Pages, Blog et zones commerciales | Responsable du site | Cartographie du site et des parcours |
| Store Pages | Store Page propriétaire de chaque famille de Products | Responsable commerce | Matrice d’affectation des Store Pages |
| Types de Product | Traitement des Products physiques, de service, cartes-cadeaux et téléchargements | Responsable merchandising | Inventaire des types de Product |
| Modèle Customer | Contacts, abonnés, donateurs, Customers, comptes et relations CRM externes | Responsable clients | Matrice de classification des Contacts |
| Modèle Order et financier | Orders, Orders d’abonnement, Transactions, remboursements et références externes | Opérations/finance | Dossier d’éléments historiques |
| Modèle d’extensions | Propriété du traitement des commandes, abonnements, adhésions, réservations, taxes, marketing et analyses | Responsable technique | Registre des dépendances |
Le modèle est prêt lorsque chaque grande famille de données commerciales ou de contenu possède un propriétaire Squarespace ou externe prévu et que chaque famille de Products est affectée à une Store Page.
Préparer les accès, archives source et éléments récupérables
Rassemblez :
- les accès administrateur source ainsi que les autorisations nécessaires pour le site et le commerce Squarespace ;
- des exports ou sauvegardes datés pour Products, Customers, Orders, contenus, abonnés et données personnalisées pertinentes ;
- les images Product, fichiers téléchargeables, médias de pages et archives du contenu source ;
- les inventaires de Store Pages, navigation, domaines et URL ;
- les éléments relatifs aux extensions, API, webhooks et systèmes externes ;
- les identifiants externes de Products, Contacts, Orders et transactions ;
- un responsable des changements source affectant Products, Contacts, Orders, contenus et stocks pendant la fenêtre de migration.
| Élément | Pourquoi il est important | Condition de préparation |
|---|---|---|
| Registre des accès | Confirme que les zones source et cible peuvent être contrôlées | Les autorisations nécessaires sont disponibles |
| Archive source datée | Conserve un état de référence récupérable | Les exports s’ouvrent correctement et sont datés |
| Archive des médias et fichiers | Protège images Product, médias de pages et téléchargements | Les fichiers peuvent être rattachés à leurs données propriétaires |
| Inventaire des Store Pages | Évite d’affecter des Products à la mauvaise page commerciale | Chaque famille de Products possède une Store Page de la boutique cible |
| Registre des identifiants externes | Protège la continuité CRM, logistique, comptable ou marketplace | Chaque clé est affectée à la bonne donnée métier |
| Journal des changements | Capture les modifications source après la date d’archive | Les nouvelles données et modifications ont des responsables identifiés |
Si une application ou un système externe ne permet aucun export, consignez cette limite et le responsable concerné au lieu de l’ignorer dans la préparation.
Préparer les types de Product, variantes, images et stocks
Squarespace prend en charge les Products physiques, de service, cartes-cadeaux et téléchargements. Les Products physiques et de service peuvent utiliser des variantes ; les données de stock s’appliquent aux variantes physiques et de service et peuvent être suivies ou illimitées. Les Products à télécharger ont des relations avec des fichiers mais n’utilisent pas le même modèle de variantes.
Préparez des exemples représentatifs pour :
- chaque type de Product utilisé par l’activité ;
- les Products simples et riches en variantes ;
- les attributs Product tels que couleur, taille ou poids ;
- les relations entre variante, SKU, prix, stock et image ;
- les fichiers téléchargeables et les attentes d’accès ;
- les Products de service et leurs éventuelles dépendances de réservation ou planification externe ;
- l’historique ou les soldes courants de cartes-cadeaux lorsque pertinent ;
- les bundles, abonnements, personnalisations ou fonctionnements détenus par des extensions ;
- les identifiants ERP, PIM, entrepôt, marketplace et traitement des commandes.
| Fonctionnement source | Décision de préparation | Élément de référence | Condition de préparation |
|---|---|---|---|
| Product physique ou de service avec variantes | Définir la propriété Product et variante | IDs parent/variante, attributs, SKU, prix, stock et images | Chaque combinaison possède une variante Squarespace prévue |
| Product à télécharger | Définir la propriété du Product, du fichier et de la livraison | Fichier source, Product ID, règles d’accès et exemple d’Order | La relation avec le fichier possède un propriétaire identifié |
| Product de service utilisant une planification | Séparer les données Product des données de réservation ou planification externe | Exemples de service et rendez-vous | La responsabilité de la planification est documentée |
| Carte-cadeau ou valeur stockée | Définir le propriétaire historique et actuel | Exemples de codes/soldes et responsable finance | Le traitement de la valeur stockée est explicite |
| Fonctionnement Product détenu par une extension | Identifier l’extension ou le système externe qui continue de fonctionner | Éléments Product et configuration associés | Les données requises figurent dans le registre des dépendances |
La zone est prête lorsque chaque famille de Products possède un type, une Store Page, un modèle de variantes, un traitement de stock, un propriétaire média/fichier et une clé externe.
Préparer les Store Pages, Categories, la navigation et la découverte des Products
Chaque Product Squarespace appartient à une Store Page. Les catégories de Store Page et la navigation sont toutefois des structures séparées. La Products API ne fournit pas les affectations aux catégories d’une Store Page, de sorte que les éléments source relatifs aux regroupements Product et à la découverte de la boutique doivent être préparés directement.
Rassemblez :
- noms, identifiants, URL et affectations Product des Store Pages ;
- catégories Product et groupes de merchandising utilisés dans chaque Store Page ;
- navigation principale, secondaire, liens de pied de page et pages d’atterrissage ;
- filtres, attributs, liens internes et collections de campagnes ;
- parcours d’achat à forte valeur et URL source ;
- redirections et décisions de retrait.
| Domaine de découverte | Responsable | Éléments requis | Condition de préparation |
|---|---|---|---|
| Store Page | Responsable commerce/site | Liste des Store Pages et affectations Product | Chaque Product possède une Store Page prévue |
| Category ou regroupement | Responsable merchandising | Appartenance des Products et exemples de parcours publics | La signification du groupe est documentée indépendamment de la navigation |
| Navigation | Responsable du site | Arborescence des menus et liens de destination | Store Pages, Categories, Pages et liens externes ont leur emplacement prévu |
| Contenu d’atterrissage | Responsable éditorial | Contenu, médias, métadonnées et références Product de la page | Les parcours de campagne et permanents possèdent des propriétaires définis |
| Redirection | Responsable SEO | Registre URL source/destination | Chaque parcours prioritaire possède un résultat approuvé |
Ne supposez pas que la migration des Products recrée automatiquement les catégories des Store Pages, le placement dans les menus ou les parcours d’achat. Ces relations nécessitent leurs propres éléments et responsables.
Préparer les Contacts, carnets d’adresses, abonnés et identités Customer
La Contacts API de Squarespace représente les personnes associées au site, notamment Customers, abonnés à des listes de diffusion, donateurs et autres participants. Les Contacts peuvent posséder des carnets d’adresses et préférences marketing, et l’ID Contact correspond au Customer ID référencé par les Orders.
Préparez :
- Customers enregistrés, acheteurs invités, abonnés, donateurs et autres Contacts ;
- exemples d’e-mails ou identités en double ;
- carnets d’adresses Contact et adresses de livraison par défaut ;
- préférences marketing et éléments de consentement ;
- Customer/Contact IDs utilisés par les Orders ;
- attentes liées à l’accès aux comptes ;
- données d’adhésion, abonnement, fidélité, réservation ou CRM détenues ailleurs ;
- identifiants Contact et Customer externes.
| Cas d’identité | Responsable | Éléments | Condition de préparation |
|---|---|---|---|
| Customer avec Orders | Opérations clients | Contact ID, carnet d’adresses et exemples d’Orders | Les relations Order utilisent l’identité Contact prévue |
| Acheteur invité | Opérations clients | E-mail, Order et instantanés d’adresses | L’historique invité est documenté sans inventer de compte |
| Abonné ou donateur | Responsable marketing/collecte | Consentement, liste et contexte d’activité | L’identité non commerciale n’est pas traitée par défaut comme un Customer retail |
| Participant à une adhésion ou un abonnement | Responsable applicatif | Plan, droit, renouvellement ou données d’accès | La relation spécialisée possède un propriétaire qui continue de fonctionner |
| Contact CRM externe | Responsable intégration | ID CRM et règles de rapprochement | L’identité intersystèmes est documentée |
L’authentification et l’accès au compte doivent être préparés séparément de l’identité Contact. Une donnée Contact ne reproduit pas à elle seule un mot de passe source, un droit d’adhésion ou un profil applicatif.
Préparer les Orders historiques, Orders d’abonnement et Transactions
Sélectionnez des Orders révélant des achats ponctuels et récurrents, des lignes Product et variante, Customer IDs, adresses, remises, taxes, livraison, traitement, remboursements et références externes. Préparez les Transactions séparément, car les documents financiers peuvent contenir paiements, remboursements, frais et erreurs de passerelle liés à un Order ou un don.
| Domaine historique | Éléments requis | Condition de préparation |
|---|---|---|
| Order ponctuel | Lignes Product/variante, Customer, totaux, état et traitement | La transaction peut être expliquée à partir du dossier source |
| Order d’abonnement | Contexte d’abonnement, historique des renouvellements, Products et Customer | La récurrence historique est distinguée de la configuration active de l’abonnement |
| Paiement et remboursement | Document Transaction, type de paiement, remboursement et exemples d’erreur | L’historique financier est relié au bon Order |
| Traitement | Expédition, suivi, quantités traitées et identifiants externes | Le contexte de livraison passé est compréhensible |
| Order invité | E-mail, adresse et relation Order | L’identité invitée reste distincte d’un compte persistant |
| Order externe | Identifiant canal, ERP, comptabilité ou support | Les clés de rapprochement restent attachées au bon Order |
Les Orders et Transactions historiques préservent le commerce passé. Les processeurs de paiement actuels, le processus d’achat, les taxes, livraisons, remises, facturation des abonnements et configuration du traitement restent des préparations séparées détenues par les équipes responsables.
Préparer les contenus, Blog Posts, médias, domaines et URL
Le commerce Squarespace s’intègre couramment à un site centré sur le contenu. Préparez :
- CMS Pages, Blog Posts, contenu des Store Pages, descriptions Product et pages d’atterrissage ;
- auteurs, dates, tags, categories, médias et liens internes ;
- inventaires d’images, vidéos, fichiers téléchargeables et textes alternatifs ;
- domaine principal, domaines secondaires, paramètres régionaux, devise et responsabilité des analyses ;
- URL de Products, Store Pages, contenus, Blog Posts et campagnes ;
- métadonnées, relations canoniques, redirections et parcours retirés ;
- navigation, pied de page et liens de campagnes.
| Domaine de contenu | Responsable | Éléments | Condition de préparation |
|---|---|---|---|
| CMS Page | Responsable éditorial | Contenu, médias, métadonnées, parcours et contexte de navigation | Chaque Page possède une destination et un parcours prévus |
| Blog Post | Responsable éditorial | Corps, auteur/date, médias, tags/categories et URL | L’historique éditorial et le parcours sont documentés |
| Contenu Product/Store Page | Responsable commerce | Description, images, regroupement et propriété de page | Le contenu reste attaché au bon objet commercial |
| Domaine et parcours | Responsable SEO/site | Registre domaine/URL | Chaque parcours prioritaire possède une destination ou une décision de retrait |
| Dépendance modèle ou bloc | Designer du site | Inventaire de mise en page, bloc, formulaire, intégration ou code | Le travail de présentation est séparé du contenu migré |
Une donnée de contenu est prête lorsque son corps, ses médias, son parcours, son propriétaire et sa couche de présentation prévue sont connus. Copier le texte seul ne constitue pas une préparation complète.
Inventorier les extensions, API, webhooks et systèmes externes
Créez un registre des dépendances couvrant traitement des commandes, abonnements, adhésions, réservations, e-mail marketing, CRM, comptabilité, taxes, livraison, avis, fidélité, marketplace, dons, analyses et applications personnalisées.
Pour chaque dépendance, consignez :
- l’objectif métier ;
- les Products, Contacts, Orders, Transactions, contenus ou fichiers concernés ;
- le système faisant autorité et les identifiants externes ;
- la disponibilité d’un export ou d’une API ;
- le responsable de la configuration ;
- la destination qui continue, son remplacement ou la décision de retrait ;
- les éléments source requis avant de configurer le processus de destination.
Le registre est prêt lorsque chaque champ ou donnée détenu par une extension active possède un propriétaire nommé, une donnée parente, un consommateur durable, un identifiant stable et des éléments source récupérables sans dépendre uniquement de l’affichage de la boutique.
Sélectionner des échantillons représentatifs pour les tests de migration
| Échantillon | Objectif de préparation |
|---|---|
| Product physique avec variantes | Révéler les relations entre attributs, SKU, images et stocks |
| Product de service | Distinguer données Product et propriété de la planification ou d’un service externe |
| Product à télécharger | Révéler les relations Product-fichier et Order-accès |
| Product affecté à une Store Page prioritaire | Révéler la propriété des Store Pages, categories, navigation et URL |
| Contact avec plusieurs adresses et Orders | Révéler Contact ID, carnet d’adresses et relation Customer |
| Order d’abonnement ou remboursé | Révéler récurrence, Transactions, remboursement et totaux |
| CMS Page ou Blog Post | Révéler propriété du contenu, médias, métadonnées et parcours |
| Donnée détenue par une extension | Révéler l’application qui continue de fonctionner et les identifiants externes |
Pour chaque échantillon, consignez l’ID source, l’URL source lorsque pertinente, le type de Product, la Store Page, la raison métier, le propriétaire Squarespace prévu, les exclusions connues, les clés externes et le responsable de la validation.
Vérifier l’état de préparation pour Squarespace
| Question de préparation | Éléments requis | Condition de préparation |
|---|---|---|
| Les accès et archives source sont-ils récupérables ? | Registre des accès et exports/sauvegardes datés | Les données requises peuvent être contrôlées indépendamment de la source active |
| La propriété du site et des Store Pages est-elle définie ? | Matrice site/Store Page | Chaque famille de Products et zone de contenu possède un propriétaire |
| Les types de Product et variantes sont-ils préparés ? | Inventaire types/variantes | Les cas physiques, services, cartes-cadeaux et téléchargements sont documentés |
| Les Contacts et Orders sont-ils reliés ? | Exemples de relations Contact/Order | L’identité, les adresses et transactions historiques sont compréhensibles |
| Les Transactions et extensions sont-elles inventoriées ? | Éléments financiers et registre des dépendances | Remboursements, paiements et données d’applications possèdent des propriétaires nommés |
| Le contenu et les URL sont-ils préparés ? | Registre contenu/parcours | Pages, Blog Posts, Store Pages, médias et redirections possèdent des destinations prévues |
| Les échantillons représentatifs sont-ils choisis ? | Registre d’échantillons | La complexité du catalogue, des identités, Orders, transactions, contenus et extensions est couverte |
| Les points non résolus sont-ils contrôlés ? | Journal de décisions | Chaque point ouvert possède un responsable et une échéance |
La préparation est complète lorsqu’aucune décision critique concernant Store Page, type de Product, variante, Contact, Order, Transaction, contenu, parcours ou extension ne dépend d’une hypothèse non documentée.
Conclusion
La préparation d’une migration vers Squarespace doit produire un dossier d’éléments couvrant le site et le commerce. Les Products doivent être affectés à la bonne Store Page et au bon type de Product, les variantes et stocks doivent conserver leurs relations, les Contacts doivent rester distincts des programmes de compte spécialisés, les Orders et Transactions doivent préserver leur contexte historique et les contenus ou parcours doivent avoir des responsables clairs.
Lorsque ces décisions sont documentées avant le test représentatif de migration, l’échantillon peut représenter le site Squarespace prévu sans confondre les données commerciales importées avec le design du site ou la configuration active du processus d’achat.
Questions fréquentes
Que faut-il préparer en premier pour Squarespace ?
Commencez par la cartographie des responsabilités du site et des Store Pages. Définissez quelle Store Page détient chaque famille de Products et quelles Pages, Blog Posts, domaines, Contacts et systèmes externes appartiennent à la destination.
Pourquoi faut-il préparer séparément les types de Product Squarespace ?
Les Products physiques, de service, cartes-cadeaux et téléchargements ne partagent pas les mêmes relations avec variantes, stocks, fichiers, traitement ou applications. Chaque type nécessite des éléments source représentatifs.
Comment préparer les catégories de Store Page ?
Collectez-les directement avec leurs appartenances Product, leurs parcours et leur rôle de merchandising. Elles ne sont pas disponibles via la Products API et ne doivent pas être déduites des seules données Product.
Les Contacts et Customers Squarespace sont-ils des identités séparées ?
Les Contacts représentent les personnes associées au site, notamment Customers, abonnés et donateurs. Le même Contact ID peut apparaître comme Customer ID sur un Order, mais des adhésions ou abonnements spécialisés peuvent rester détenus par une autre application.
Pourquoi préparer Orders et Transactions séparément ?
Les Orders expliquent les articles achetés et leur traitement, tandis que les documents Transaction expliquent paiements, remboursements, frais et erreurs de passerelle. Les deux sont nécessaires pour préserver un contexte historique complet.
Quand la préparation Squarespace est-elle complète ?
Elle est complète lorsque accès, Store Pages, types de Product, variantes, stocks, Contacts, Orders, Transactions, contenus, parcours, extensions, échantillons et décisions non résolues possèdent tous des responsables identifiés et des éléments récupérables.