Squarespace combine la structure d’un site hébergé et les données commerciales dans un même environnement. Cette combinaison modifie la signification des données lors d’une migration. Un Product n’existe pas seulement comme une ligne de catalogue : il appartient à une Store Page, possède un type de Product précis, peut contenir des variantes et attributs et s’affiche à travers la structure de contenu et de navigation du site. Un acheteur peut apparaître comme Contact, Customer, abonné, donateur ou utilisateur du site selon la relation à l’origine de la donnée. Un Order conserve une transaction, mais ne devient pas la configuration qui déterminera le futur fonctionnement du processus d’achat, des paiements, du traitement des commandes ou des taxes.
La tâche centrale consiste à préserver les relations qui rendent chaque donnée utile dans Squarespace. Les données Product doivent rester reliées à leur type de Product, leur Store Page, leurs variantes, images, URL et stocks. Les données Contact doivent conserver la distinction entre identité d’acheteur, inscription à une liste de diffusion, activité de don et accès à un compte. Les contenus et données SEO doivent garder leur destination et leurs références internes au lieu d’être traités comme du texte décoratif autour de la boutique.
La signification commerciale de Squarespace commence par le site et la Store Page
Squarespace n’est pas un catalogue autonome placé à côté d’un site indépendant. Les données commerciales vivent dans un site dont le panneau Pages, les Store Pages, la navigation, les collections de contenu, les domaines et les URL déterminent la façon dont les Products sont publiés et découverts. Chaque Product appartient à une seule Store Page, tandis que sa visibilité dépend à la fois de son propre état et de celui de la Store Page.
Cette règle de propriété est importante lorsque la plateforme source utilise plusieurs catalogues, collections, sites ou canaux de vente. Un Product ne peut pas être transposé correctement tant que sa relation avec la Store Page de destination n’est pas définie. Le placement sur une Store Page n’est pas seulement un choix de menu : il participe à la visibilité et à la signification de l’URL du Product.
| Hypothèse de la boutique source | Signification de la relation dans Squarespace | Conséquence pour la transposition |
|---|---|---|
| Les Products existent indépendamment du site | Chaque Product appartient à une Store Page au sein d’un site Squarespace | Préserver l’identité du Product avec la Store Page qui doit en être propriétaire. |
| L’affectation à une catégorie recrée la navigation | Le regroupement des Products, le placement sur les Store Pages, les tags, Categories et la navigation du site sont liés mais distincts | Transposer la classification séparément des menus et de la présentation des pages. |
| Un type de Product générique convient à toutes les offres | Squarespace distingue les Products physiques, services, cartes-cadeaux et téléchargements | Le type de Product détermine les relations disponibles avec variantes, stocks, traitement des commandes et fichiers. |
| Customer équivaut à abonné à la liste de diffusion | Les Contacts peuvent représenter des Customers, abonnés, donateurs et d’autres relations avec le site | Préserver la raison pour laquelle la personne existe dans la destination, et pas seulement son adresse e-mail. |
| Les Orders importés recréent les opérations commerciales | Les Orders préservent l’historique et l’état de la transaction ; le fonctionnement futur reste configuré ailleurs | Séparer les éléments historiques de la configuration des paiements, taxes, livraisons et notifications. |
Cette relation entre site et commerce influence aussi les identifiants externes. Un identifiant Product source peut devoir rester attaché au Product ou à la variante Squarespace utilisé par un ERP. Un identifiant de page source peut appartenir à la migration du contenu plutôt qu’au commerce. Un identifiant CRM d’un Customer doit rester lié à la relation Contact reconnue par le CRM, et non à un Order simplement parce que sa première occurrence provient du processus d’achat.
Les types de Product définissent des relations différentes
Squarespace prend en charge les Products physiques, services, cartes-cadeaux et téléchargements. Ces types ne sont pas de simples libellés. Ils déterminent si un Product peut avoir des variantes, comment les stocks sont représentés, quelle signification donner au traitement des commandes et quelles données supplémentaires interviennent dans la vente.
Les Products physiques peuvent contenir des variantes et des données liées à la livraison. Les Products de service peuvent également comporter des variantes, par exemple une durée ou un niveau de prestation, mais leur mode de réalisation diffère d’une livraison physique. Les Products de carte-cadeau peuvent utiliser des variantes pour les montants. Les Products à télécharger relient le Product à un bien numérique et ne prennent pas en charge des variantes de la même manière.
| Offre source | Signification du Product dans Squarespace | Relation à préserver |
|---|---|---|
| Marchandise physique | Product physique | Store Page, variantes, SKU, prix, poids/dimensions lorsque pertinent, stocks, images, logique de livraison et URL. |
| Conseil, cours, expérience ou niveau de service | Variante d’un Product de service | Identité du service, niveau ou durée, prix, contenu et éventuel système distinct responsable de la planification ou de la réalisation. |
| Crédit boutique ou certificat cadeau numérique | Variante d’un Product de carte-cadeau | Montant achetable, relation d’émission de la carte, contexte acheteur/bénéficiaire et signification financière. |
| Fichier téléchargeable | Product à télécharger plus relation DigitalGood | Métadonnées du Product, fichier acheté, droit de livraison et URL ; pas un ensemble artificiel de variantes. |
| Offre par abonnement ou récurrente | Product plus relation d’abonnement et d’Order | L’identité du Product reste distincte de la facturation récurrente, du droit d’accès et de l’état du renouvellement. |
| Offre de don ou d’adhésion | Don, adhésion ou zone Squarespace connectée plutôt qu’un Product ordinaire lorsque pertinent | Les relations Contact, transaction, accès et contenu restent détenues par la bonne fonction Squarespace. |
Une plateforme source peut modéliser toutes ces offres comme des Products, SKU ou types de Product personnalisés. La transposition vers Squarespace doit suivre le fonctionnement de la destination. Un fichier de cours à télécharger, une consultation planifiée et un livre expédié peuvent avoir un titre et un prix, sans partager pour autant les mêmes relations de données ni le même mode de réalisation.
Attributs Product, variantes, images et stocks
Les attributs Product de Squarespace définissent des valeurs telles que couleur ou taille, tandis que les variantes représentent les combinaisons réellement achetables. Une variante peut porter un SKU unique, un prix, une quantité de stock, des dimensions et les valeurs d’attribut sélectionnées. Les images Product appartiennent à la collection d’images du Product et peuvent être associées aux variantes.
Les options source doivent être distinguées selon leur effet commercial. Une valeur qui modifie le SKU, le prix, le stock, l’image ou l’identité de réalisation se comporte comme une variante. Une instruction de personnalisation, un service facultatif, un composant de bundle ou une configuration générée par une application peut ne pas avoir d’équivalent direct comme variante Squarespace. Transformer chaque choix source en variante peut créer une matrice de Products ingérable ; à l’inverse, réduire de vraies variantes à du texte fait disparaître leur identité de SKU et de stock.
| Modèle d’option source | Propriétaire dans Squarespace | Signification à préserver |
|---|---|---|
| Combinaison taille/couleur avec SKU et stock | Attributs Product et ProductVariant | Identité achetable, valeurs d’attribut, SKU, prix, stock et relation avec l’image. |
| Niveau ou durée de service | Variante d’un Product de service | Choix de service vendable et ses différences de prix ou de description. |
| Montant d’une carte-cadeau | Variante d’un Product de carte-cadeau | Montant monétaire achetable. |
| Format d’un téléchargement | Généralement identité de Product séparée ou relation avec le fichier, plutôt qu’une variante de Product à télécharger | Bon droit d’accès au fichier et bonne identité du Product. |
| Gravure, texte libre ou fichier envoyé par l’acheteur | Saisie personnalisée, donnée de ligne d’Order ou extension connectée selon le fonctionnement pris en charge | La valeur fournie par le client reste liée à l’achat et au responsable de sa réalisation. |
| Bundle ou configurateur | Relation Product, simplification acceptée ou structure d’une extension / d’un système externe | Les composants, le SKU résultant, le prix, le stock et le résultat dans la ligne d’Order restent explicables. |
Les stocks sont gérés au niveau des variantes. L’Inventory API de Squarespace représente un InventoryItem comme une variante d’un Product physique ou de service et conserve l’information indiquant si le stock est suivi ou illimité, ainsi que le SKU et la disponibilité. Une quantité source stockée au niveau du Product doit donc d’abord être réconciliée avec la structure de variantes de destination.
Une valeur de stock source nécessite aussi une décision sur le système faisant autorité. Si Squarespace détient le stock, la quantité d’ouverture doit correspondre aux variantes Product de destination. Si un entrepôt ou ERP reste la source de référence, la relation durable devient ProductVariant → clé de stock externe → synchronisation du stock. Une quantité copiée sans cet identifiant devient obsolète dès que le système externe reprend ses mises à jour.
Store Pages, Categories, tags, navigation et découverte
Les Store Pages détiennent les Products, mais ne remplacent pas toutes les structures de découverte de la source. Categories, tags, placement sur une Store Page, liens de navigation, blocs de synthèse, recherche, pages de contenu et liens de campagnes externes peuvent tous aider les visiteurs à trouver les Products. Une collection source peut représenter un rayon permanent, une campagne temporaire, une marque, un résultat de filtre ou une page éditoriale. Ces significations doivent rester distinctes.
| Structure de découverte source | Signification dans Squarespace |
|---|---|
| Rayon permanent du catalogue | Product Category ou regroupement durable sur une Store Page selon la structure de destination. |
| Marque du Product | Tag, relation de contenu, convention de nommage ou champ d’information Product externe selon l’usage de la marque. |
| Collection saisonnière | Category, tag, page organisée ou relation de navigation temporaire plutôt qu’un type de Product permanent. |
| Attribut de filtre à facettes | Attribut de variante, contenu Product structuré, tag ou système externe chargé de la recherche/du filtrage ; pas automatiquement une Category. |
| Lien de navigation principal | Relation de navigation du site pointant vers une Store Page, une vue Category, une page de contenu ou une URL externe. |
| Page d’atterrissage SEO | Page ou destination Store Page reliée aux Products, au contenu, à l’URL, aux métadonnées et aux liens internes. |
La Products API n’expose pas toutes les relations de Category des Store Pages de la même manière qu’elle expose les données Product, ce qui renforce la nécessité de distinguer les données du catalogue de l’organisation du site. Le modèle cible doit identifier quelles données détiennent la classification des Products et quelles données du site contrôlent leur découverte publique.
Un Product peut être migré correctement mais rester pratiquement indisponible s’il appartient à la mauvaise Store Page, est masqué ou n’a aucun parcours de navigation accessible. Il s’agit alors d’un problème de relation, pas de la preuve que les champs du Product sont absents.
Contacts, Customers, abonnés, donateurs et accès aux comptes
Les fonctions commerciales et marketing de Squarespace peuvent créer plusieurs significations autour d’une même personne. Les Contacts peuvent représenter des Customers, des abonnés, des donateurs et d’autres personnes associées au site. Les carnets d’adresses et préférences marketing appartiennent à ces relations. L’ancien modèle Profiles exposait des catégories proches d’utilisateurs du site, tandis que l’actuelle Contacts API constitue le propriétaire moderne de la gestion plus large des Contacts.
Un compte Customer source peut aussi contenir des mots de passe, groupes de clients, rôles B2B, soldes de fidélité, moyens de paiement enregistrés, droits d’adhésion, états d’abonnement, exonérations fiscales ou attributs CRM. Ces significations ne doivent pas être aplaties dans une seule donnée Contact simplement parce que la personne possède une adresse e-mail unique.
| Modèle d’identité source | Décision de relation dans Squarespace |
|---|---|
| Acheteur enregistré | Identité Contact/Customer reliée aux Orders, adresses et fonctions de compte prises en charge. |
| Acheteur invité | Identité d’acheteur liée à l’Order, avec un Contact durable uniquement lorsque la relation de destination le permet. |
| Abonné à une newsletter | Contact plus relation de liste marketing et de consentement, séparée de l’historique d’achat lorsque nécessaire. |
| Donateur | Contact plus historique de dons/transactions, pas automatiquement un Customer commercial. |
| Membre ou participant à un contenu restreint | Contact/utilisateur du site plus relation d’adhésion ou d’accès ; mot de passe et droit d’accès ne sont pas de simples champs de profil. |
| Acheteur B2B ou organisation | Contact plus responsabilité du CRM/système externe pour l’entreprise, le rôle, le prix, la fiscalité ou les structures d’approbation. |
| Profils source en double | Fusion uniquement lorsque l’identité, le consentement, l’adresse et les éléments liés aux Orders démontrent qu’il s’agit d’une même personne. |
L’e-mail constitue un signal d’identité important, mais pas le seul. Adresses partagées, changements d’e-mail, Orders invités, imports en double et contacts d’organisation peuvent provoquer de fausses fusions. Des identifiants CRM externes, identifiants Customer source, adresses et relations avec les Orders peuvent être nécessaires pour préserver les personnes distinctes et leur historique.
Le consentement marketing doit rester une relation distincte de l’identité d’acheteur. Un Customer ayant acheté ne devient pas automatiquement un abonné à une liste de diffusion, et un abonné peut n’avoir jamais acheté. Préserver le Contact sans préserver la relation qui explique sa présence peut créer à la fois de la confusion opérationnelle et des problèmes de consentement.
Orders, transactions, traitement des commandes et contexte historique
Les Orders Squarespace peuvent représenter des achats ponctuels et des Orders liés à des abonnements. Ils contiennent les lignes d’achat, informations Customer, adresses de facturation et de livraison, totaux, remises, taxes, informations de livraison, état de traitement, état de paiement, remboursements et autres éléments de contexte transactionnel. Les Transactions constituent les données financières associées aux Orders et aux dons.
L’Order doit conserver le Product ou la variante acheté au moment de la transaction, même si le Product actuel change ensuite. Une ligne d’Order est un instantané transactionnel, et non une référence dynamique qui doit être écrasée par le contenu courant du catalogue. Les états de paiement et remboursement décrivent ce qui s’est passé financièrement. Le traitement et le suivi expliquent comment l’achat a été pris en charge. Les Orders importés ou historiques ne définissent pas les processeurs de paiement actuels, règles de livraison, configuration fiscale, fonctionnement des e-mails ni connexions aux entrepôts.
| Donnée historique | Signification dans Squarespace |
|---|---|
| Numéro d’Order source | Référence externe traçable pour le service client et les rapprochements. |
| Ligne Product/variante | Titre acheté, SKU, attributs sélectionnés, quantité, prix et autres valeurs d’instantané de ligne. |
| Adresses de facturation et livraison | Contexte historique de transaction, pas une adresse permanente de compte sauf si le Contact la détient séparément. |
| Ligne de remise, taxe et livraison | Explication du total historique plutôt que configuration actuelle des remises ou taxes. |
| État de paiement et transaction | Historique financier lié à l’Order, pas des identifiants de paiement réutilisables. |
| Traitement et suivi | Contexte historique d’expédition ou de réalisation du service, pas définition des méthodes actuelles de traitement. |
| État d’abonnement ou de plan de paiement | Cycle de vie d’Order et de transaction qui doit rester relié au système contrôlant les futurs prélèvements. |
| Order importé d’un canal tiers | Historique d’Order plus identifiant du canal externe et relation avec la source. |
Squarespace peut importer des Orders de canaux de vente tiers via ses Commerce APIs, mais l’historique importé doit toujours conserver sa source et ses identifiants d’origine. La création d’un Order Squarespace ne fait pas disparaître la marketplace, le prestataire de paiement ou le système de traitement historique comme propriétaire des références associées.
Pages, Blog Posts, médias, URL et relations SEO
Un site Squarespace peut contenir des pages classiques, Store Pages, Blog Posts, éléments de collections, images, fichiers, liens de navigation, URL de Products, vues de Category, champs SEO, redirections, domaines et services connectés. Ces données forment un graphe de contenu autour du catalogue commercial.
Une description Product source appartient au Product. Un guide d’achat peut être une page ou un Blog Post reliant plusieurs Products. Une description de Category peut devenir du contenu de Store Page ou de page d’atterrissage. Une page de campagne peut référencer des Products sans détenir leurs données. Les médias peuvent être partagés entre Products et contenus, mais l’ordre des images, le recadrage, le texte alternatif, les légendes et les liens internes ont une signification propre au site.
| Ressource web source | Propriétaire dans Squarespace |
|---|---|
| Titre, description, images, slug d’URL et données SEO du Product | Relation Product et Store Page. |
| CMS Page de politique ou d’information | Page Squarespace avec contenu, médias, métadonnées et relation de navigation. |
| Blog Post | Élément de collection Blog avec contexte de publication, categories/tags, médias, liens internes et URL. |
| Guide produit ou page d’atterrissage de campagne | Page/collection de contenu plus références Product et navigation. |
| Élément de menu | Relation de navigation du site pointant vers une page, Store Page, destination Product, ancre ou URL externe. |
| URL source | Route de destination plus relation de redirection lorsque le chemin change. |
| Bloc de thème ou code personnalisé | Présentation/configuration du site qui référence les contenus et données commerciales sans en devenir propriétaire. |
La continuité des URL dépend de l’identité de destination. Une redirection doit relier l’ancien chemin source au bon Product, à la bonne Store Page, page, Blog Post ou autre destination. Elle ne doit pas masquer l’incertitude sur la donnée qui remplace réellement la page source. Les liens internes à l’intérieur du contenu migré doivent eux aussi pointer vers la destination prévue plutôt que conserver des URL source obsolètes.
Extensions, API, champs personnalisés et propriété des systèmes externes
Les Commerce APIs de Squarespace exposent Products, Inventory, Orders, Transactions, Contacts, Discounts, Websites et webhooks. Les services et extensions connectés peuvent également détenir des avis, programmes de fidélité, abonnements, traitements de commandes, données comptables, livraisons, marketing, planification, dons, adhésions ou autres données. Une donnée d’application source ne doit pas être traitée comme une donnée Squarespace native simplement parce qu’une extension de destination fournit une fonction comparable.
Le propriétaire correct dépend de l’objectif métier et du cycle de vie. Un identifiant d’entrepôt Product appartient à la relation ProductVariant/ERP. Un identifiant CRM Contact appartient au Contact et au CRM. Un identifiant d’Order de marketplace appartient à l’Order et au canal. Un droit d’adhésion appartient au système d’adhésion, et non à une note générique du Contact.
| Valeur personnalisée ou externe | Propriété de destination |
|---|---|
| Identifiant ERP de Product ou variante | Product/ProductVariant plus relation ERP au même niveau de granularité du catalogue. |
| Clé de stock externe | ProductVariant plus entrepôt ou système d’inventaire. |
| Identifiant CRM du Contact | Contact plus relation CRM. |
| Identifiant d’Order de marketplace | Order plus relation avec le canal de vente. |
| Donnée d’avis, fidélité ou abonnement | Extension ou système externe plus références Product, Contact ou Order. |
| Résultat d’un configurateur Product | Product/variante plus configuration détenue par l’extension et instantané de ligne d’Order résultant. |
| Réponse personnalisée au processus d’achat | Order ou Contact selon l’objectif métier, plus formulaire/extension responsable de la collecte et de l’affichage. |
| Table source non prise en charge | Relation parent explicite, clé durable, cycle de vie et propriétaire de destination avant de conserver la valeur. |
Cette frontière évite deux erreurs courantes : forcer chaque valeur dans le champ Squarespace le plus proche et préserver des données d’application sans consommateur dans la destination. Un champ personnalisé n’est utile que lorsque l’équipe cible sait quelle donnée le détient, quel système le reconnaît et s’il décrit le commerce actuel, un contexte historique, du contenu ou une configuration externe.
Chaînes de transposition représentatives pour Squarespace
Une chaîne de relations montre comment un concept source est réparti entre les données commerciales, Contacts, contenus et systèmes externes de Squarespace. Elle rend le propriétaire de destination visible et évite qu’un seul champ importé porte plusieurs significations incompatibles. La chaîne doit rester compréhensible même lorsque la plateforme source n’est plus accessible, afin que chaque Product, Contact, Order, URL et référence d’extension conserve un parent et un consommateur clairement identifiés.
| Modèle source | Relation de destination dans Squarespace |
|---|---|
| Product vestimentaire avec stocks par taille/couleur | Store Page → Product physique → attributs → ProductVariants → images/SKU de variantes → InventoryItems. |
| Forfaits de conseil | Store Page → Product de service → variantes de niveau/durée → contenu → système externe de planification ou réalisation lorsque nécessaire. |
| Téléchargement numérique | Store Page → Product à télécharger → DigitalGood → ligne d’Order → Contact acheteur → droit de livraison. |
| Abonné qui devient ensuite acheteur | Contact → relation liste de diffusion/consentement → historique Customer/Order, sans supposer que ces deux relations sont identiques. |
| Vente importée d’une marketplace | Order → instantané de ligne → historique de transaction/traitement → Contact → identifiant externe de marketplace. |
| Collection Product sensible au SEO | Store Page/Category ou page organisée → références Product → navigation → URL de destination → redirections depuis les chemins source. |
| Donnée d’adhésion ou de don | Contact → propriétaire de l’adhésion ou du don → historique de transaction/accès, distinct des champs ordinaires Product et Customer. |
Ces chaînes maintiennent visibles les responsabilités relatives aux Products, au site, aux Contacts, Orders, contenus et systèmes externes. Elles montrent aussi les endroits où une plateforme source peut avoir regroupé plusieurs significations dans une seule donnée alors que Squarespace les représente séparément.
Conclusion
La transposition du modèle de données vers Squarespace dépend de la relation entre les données commerciales et le site qui les publie. Les Products appartiennent à des Store Pages et à des types de Product ; les variantes détiennent les combinaisons vendables et les stocks ; les Contacts peuvent porter des significations de Customer, abonné, donateur et compte ; les Orders préservent l’historique transactionnel ; les pages, Blog Posts, URL et éléments de navigation structurent la découverte du contenu ; les extensions et systèmes externes détiennent les fonctionnements spécialisés.
Un bon modèle de destination préserve ces relations sans confondre les données migrées avec la présentation du site ou la future configuration opérationnelle. Le résultat ne doit pas être seulement un site Squarespace rempli de données, mais un ensemble cohérent de Products, Contacts, Orders, contenus et données de systèmes externes dont les responsabilités restent compréhensibles.
Questions fréquentes
Pourquoi la propriété d’une Store Page est-elle importante pour les Products Squarespace ?
Chaque Product Squarespace appartient à une Store Page et sa disponibilité dépend à la fois de sa visibilité et de l’état de cette Store Page. Les données Product et le placement sur la Store Page forment donc une même relation de destination, même si la navigation du site reste une couche distincte.
Chaque option Product source peut-elle devenir une variante Squarespace ?
Non. Une variante est appropriée lorsque le choix crée une combinaison achetable distincte avec un SKU, un prix, un stock, une image, des dimensions ou une autre signification commerciale. Les personnalisations, bundles, fichiers envoyés ou choix contrôlés par des applications peuvent nécessiter un autre propriétaire.
Les Contacts, Customers et abonnés Squarespace sont-ils le même type de donnée ?
Ils peuvent faire référence à la même personne, mais les relations sont différentes. L’historique Customer, le consentement à une liste de diffusion, l’activité de don, les carnets d’adresses et l’accès au compte doivent rester distinguables même lorsqu’un Contact les relie.
Un Order migré recrée-t-il le fonctionnement du processus d’achat Squarespace ?
Non. L’Order préserve le contexte de transaction, lignes, paiement, remboursement, adresses et traitement. Les processeurs de paiement actuels, paramètres fiscaux, méthodes de livraison, notifications et connexions aux systèmes de traitement restent une configuration séparée.
Comment les stocks Product doivent-ils être représentés dans Squarespace ?
Le stock doit suivre le ProductVariant Squarespace qui représente l’article réellement vendable. Si un système d’inventaire externe reste la source de référence, la variante doit aussi conserver la clé externe durable utilisée pour maintenir le stock après le transfert initial.
Où doivent résider les données personnalisées ou détenues par des applications dans Squarespace ?
Elles doivent rester avec le Product, ProductVariant, Contact, Order, contenu, extension ou système externe qui détient leur finalité métier. Des notes génériques ne remplacent pas une relation parent définie et un identifiant durable.