Les problèmes d’une migration vers Square proviennent rarement d’un simple écart dans le nombre d’enregistrements. Ils apparaissent surtout lorsqu’une boutique source est transposée dans Square sans préserver les relations entre la bibliothèque d’articles, les opérations Point of Sale, les points de vente, le stock, les Customers, les Orders et Square Online. Un Product peut être présent mais difficile à vendre, un Order lisible mais déconnecté de son contexte de remboursement ou de traitement, et un Customer peut exister alors que les identifiants utilisés par les équipes ou les intégrations ont disparu.
La meilleure prévention consiste à traiter chaque fonctionnement important de la source comme une relation opérationnelle à reconstruire dans Square. Chaque piège ci-dessous décrit une défaillance récurrente, les signaux qui permettent de la détecter tôt et une condition concrète démontrant que le risque est maîtrisé.
Piège 1 : traiter Square comme une simple plateforme de vitrine
Ce qui se passe mal
La migration est planifiée comme un transfert classique de site web : Products, Customers et Orders sont déplacés, donc le projet semble terminé. Square relie pourtant la bibliothèque d’articles au Point of Sale, aux points de vente, au stock, aux Orders, aux paiements, au Customer Directory et éventuellement à la vente en ligne. Lorsque ces relations ne sont pas définies, les équipes reçoivent des enregistrements présents techniquement mais inutilisables dans le processus de vente prévu.
Un marchand historiquement centré sur le web peut découvrir que le catalogue migré est difficile à utiliser au comptoir. Un marchand principalement orienté POS peut constater que la visibilité en ligne, le traitement et les URL n’ont jamais reçu de responsable. L’échec vient d’abord d’un rôle cible mal défini, et non d’un champ isolé.
Signaux d’alerte précoces
| Signal d’alerte | Conséquence probable |
|---|---|
| Le projet décrit Square uniquement comme le nouveau site web. | Les relations liées au POS, aux points de vente et au fonctionnement des paiements restent indéfinies. |
| Les nombres de Products constituent le principal critère d’acceptation du catalogue. | Les articles peuvent exister sans variations, modifiers ou visibilité par canal réellement exploitables. |
| Square Online n’est abordé qu’après la migration du catalogue. | Pages, parcours, Categories et disponibilité en ligne deviennent des reprises tardives. |
| Les processus des équipes sont absents des exemples. | Les données peuvent être présentes techniquement mais inutilisables dans les opérations. |
Prévention
Définissez le rôle cible de Square avant de mapper les enregistrements. Précisez si la boutique utilisera Point of Sale, Square Online, plusieurs points de vente, le retrait ou la livraison, des services, un stock retail ou une combinaison de ces éléments. Reliez ensuite chaque type d’enregistrement migré à la partie de Square qui doit l’utiliser.
Utilisez une carte simple des responsabilités : les données migrées établissent les enregistrements historiques ou de catalogue ; la configuration Square contrôle le fonctionnement actif de la vente ; les intégrations possèdent les données synchronisées ou externes. Cette séparation empêche de confondre les différentes couches.
Exemple de recommandation
Pour un détaillant quittant une plateforme centrée sur le web, sélectionnez une famille de Products représentative et suivez-la dans la bibliothèque d’articles, une vente POS, la visibilité en ligne, le stock par point de vente et l’Order obtenu. Cette vérification révèle les lacunes du modèle cible qu’une revue limitée à la vitrine ne montrerait pas.
Condition de réussite
Le modèle opérationnel cible identifie les produits et points de vente Square qui utiliseront chaque zone de données migrée, et les enregistrements représentatifs prennent en charge les processus attendus pour les équipes et les acheteurs sans dépendre d’hypothèses non documentées.
Piège 2 : aplatir les articles, variations, options et modifiers
Ce qui se passe mal
Une structure Product source est convertie en une liste plate d’articles Square. Les choix de variante, valeurs d’option, modifiers appliqués au moment de la vente, SKU, prix, images et règles de stock sont mélangés ou placés au mauvais niveau. Le résultat peut multiplier inutilement les articles, supprimer des choix nécessaires ou transformer des variantes portant du stock en simples sélections non suivies.
Square distingue l’article parent des variations d’article et peut aussi utiliser des options d’article et des listes de modifiers. Ces structures répondent à des besoins différents. Les variations représentent des formes vendables d’un article ; les options standardisent les attributs servant à générer ou identifier les variations ; les modifiers représentent des sélections appliquées à la vente. Un choix source ne peut donc pas être mappé correctement avant d’en comprendre la fonction commerciale.
Signaux d’alerte précoces
| Fonctionnement source | Signal d’alerte dans Square |
|---|---|
| La taille ou la couleur contrôle le SKU et le stock. | Le choix est représenté uniquement comme modifier. |
| Un choix de repas ajoute un supplément facultatif. | Il est développé en variations de stock distinctes. |
| Les images ou prix propres aux variantes sont importants. | Toutes les sélections héritent des mêmes valeurs parent. |
| Des sélections obligatoires existent dans la boutique source. | Square permet de vendre l’article sans le choix attendu. |
Prévention
Classez chaque option source selon sa fonction : identité, stock, prix, traitement, affichage ou personnalisation au moment de la vente. Mappez les choix portant l’identité ou le stock vers les variations d’article ou options d’article. Utilisez les listes de modifiers pour les ajouts facultatifs au moment de la vente uniquement lorsque leur fonctionnement correspond à la règle métier.
Conservez les SKU et identifiants externes au niveau où les systèmes en aval les attendent. Décidez également si les noms de variations doivent être générés à partir de valeurs d’option standardisées ou conservés comme noms explicites.
Exemple de recommandation
Pour un Product textile configurable, comparez une combinaison source comme taille M, couleur noire et broderie avec sa représentation Square. La taille et la couleur peuvent appartenir à la variation, tandis que la broderie peut être un modifier si elle est choisie au moment de la vente et ne possède pas son propre stock.
Condition de réussite
Les familles de Products représentatives restent faciles à trouver et à vendre, et chaque choix conserve le bon SKU, prix, image, stock, caractère obligatoire et sens sur la ligne d’Order.
Piège 3 : réduire le stock par point de vente à une seule quantité
Ce qui se passe mal
La boutique source expose un stock total unique ou plusieurs quantités par entrepôt, mais la migration les réduit à une seule quantité Square sans définir la responsabilité par point de vente. Des Products apparaissent alors disponibles au mauvais endroit, la disponibilité en ligne ne correspond plus au retrait attendu ou les équipes ne peuvent plus rapprocher le stock d’ouverture migré avec les ajustements suivants.
Square suit le stock des variations d’article par point de vente et peut représenter différents états de stock. Une quantité dépourvue de point de vente et d’état est donc une donnée opérationnelle incomplète.
Signaux d’alerte précoces
| Signal d’alerte | Risque |
|---|---|
| L’export source contient un total unique alors que le marchand exploite plusieurs points de vente. | Le stock est affecté arbitrairement ou dupliqué. |
| Le retrait et les ventes en magasin partagent le stock mais les règles de point de vente ne sont pas documentées. | Les acheteurs voient une disponibilité que les équipes ne peuvent pas honorer. |
| Les bundles ou composants sont traités comme un stock de variation ordinaire. | La quantité affichée ne représente pas la disponibilité réelle des composants. |
| Le stock d’ouverture est chargé sans horodatage faisant autorité. | Les ajustements ultérieurs ne peuvent pas être rapprochés du solde migré. |
Prévention
Définissez la granularité du stock avant la migration : variation Product, point de vente et état requis. Déterminez quel système possède le solde d’ouverture et lequel devient l’autorité après la bascule. Lorsque la source ne fournit pas de quantités par point de vente, documentez la méthode d’allocation au lieu de copier silencieusement le même total partout.
Séparez le stock que Square peut suivre directement de la disponibilité des bundles, composants ou systèmes externes qui nécessite un autre responsable.
Exemple de recommandation
Un marchand avec deux boutiques physiques et Square Online doit sélectionner plusieurs SKU sensibles au stock et documenter le stock d’ouverture attendu sur chaque point de vente, la disponibilité en ligne et le fonctionnement du retrait. La comparaison doit inclure une variation en rupture et un Product disponible sur un seul point de vente.
Condition de réussite
Chaque variation contrôlée possède un solde d’ouverture par point de vente explicable, le système faisant autorité pour le stock est connu et la disponibilité en ligne ou en retrait respecte les règles approuvées par point de vente.
Piège 4 : préserver les enregistrements de catalogue sans préserver leur visibilité par canal
Ce qui se passe mal
Les articles, Categories, images, taxes et remises sont présents dans le catalogue Square mais ne sont pas exposés sur le canal prévu. Des Products peuvent être vendables dans Point of Sale mais absents de Square Online, visibles en ligne sur le mauvais point de vente ou regroupés dans des Categories qui ne permettent plus aux clients de les découvrir correctement.
Le catalogue constitue une infrastructure partagée ; sa présence ne prouve pas que chaque article est publié ou organisé correctement sur chaque surface de vente. La visibilité par canal, le type d’article, l’affectation des images, l’appartenance aux Categories et la présentation en ligne doivent encore être définis explicitement.
Signaux d’alerte précoces
| Résultat de catalogue | Défaillance cachée |
|---|---|
| L’article apparaît dans le Dashboard. | Il peut rester indisponible dans Square Online ou au point de vente prévu. |
| Les Categories ont été migrées par nom. | L’appartenance des Products et la navigation des acheteurs peuvent ne pas correspondre. |
| Les images existent dans le catalogue. | L’image principale ou propre à une variation peut être incorrecte en ligne. |
| Les remises et taxes existent comme objets. | Leur application peut ne pas correspondre à la règle commerciale source. |
Prévention
Créez une matrice de visibilité par canal pour des Products représentatifs. Consignez où chaque Product doit être vendable, s’il nécessite des images et contenus en ligne, quels parcours Category sont importants et quelles règles de point de vente ou de traitement influencent la publication.
Traitez la migration des Categories comme une décision de découverte et non comme un simple transfert de libellés. Consolidez les parcours obsolètes, préservez les regroupements commercialement importants et identifiez la navigation en ligne qui doit être configurée hors de la migration des enregistrements.
Exemple de recommandation
Pour une famille de Products saisonniers, comparez la bibliothèque d’articles, la disponibilité Point of Sale, la page Product Square Online, l’appartenance aux Categories, l’ordre des images et le point de retrait. Le Product ne doit pas être considéré conforme uniquement parce que son objet de catalogue existe.
Condition de réussite
Les Products représentatifs sont disponibles uniquement sur les canaux et points de vente prévus, avec la bonne appartenance aux Categories, les bonnes images, le bon état de publication et l’applicabilité commerciale correcte pour chaque parcours acheteur.
Piège 5 : migrer les Customers sans leur contexte de groupe ou personnalisé
Ce qui se passe mal
Les profils Customer sont migrés avec nom, e-mail, téléphone et adresses, mais la signification métier portée par les groupes, attributs personnalisés, identifiants CRM, champs de consentement ou notes d’équipe est omise. Les équipes peuvent retrouver un Customer sans pouvoir identifier la relation, la segmentation ou le lien vers un système externe qui rendait le profil utile.
Square peut gérer les profils Customer, l’appartenance aux groupes et des attributs personnalisés, mais ce sont des relations distinctes. Un attribut personnalisé ne fait pas automatiquement partie d’un profil Customer de base, et un segment source peut ne pas avoir de destination Square pertinente.
Signaux d’alerte précoces
| Signal Customer | Risque s’il est ignoré |
|---|---|
| Les groupes pilotent des promotions ou le traitement par les équipes. | Les Customers deviennent impossibles à distinguer après migration. |
| Des identifiants CRM externes sont stockés dans des champs personnalisés. | La synchronisation crée des doublons ou perd les relations. |
| Consentement et préférences de communication sont mélangés aux données de profil. | Le traitement marketing devient peu fiable. |
| Des profils en double existent entre POS et canaux en ligne. | L’historique d’achat et l’identité restent fragmentés. |
Prévention
Classez les données Customer en identité, coordonnées, appartenance à un groupe, attributs personnalisés, consentement et identifiants externes. Définissez quelles valeurs appartiennent au Customer Directory, lesquelles relèvent des groupes Customer, lesquelles nécessitent des définitions d’attribut personnalisé et lesquelles restent sous la responsabilité d’un autre système.
Établissez une règle de traitement des doublons avant l’import. Utilisez des identifiants stables lorsque disponibles et évitez de fusionner des Customers uniquement parce que leurs noms ou e-mails se ressemblent.
Exemple de recommandation
Sélectionnez un Customer régulier, un Customer appartenant à un groupe ciblé, un profil avec identifiant ERP ou CRM et un doublon probable. Confirmez comment chaque profil sera reconnu par les équipes et intégrations après migration.
Condition de réussite
Les Customers représentatifs conservent l’identité, le groupe, le contexte personnalisé et les relations externes nécessaires au support et à la synchronisation, sans résultat de doublon ou de fusion inexpliqué.
Piège 6 : traiter les Orders historiques comme une configuration active des paiements et du traitement
Ce qui se passe mal
Les Orders historiques sont importés ou conservés pour référence et l’équipe suppose alors que les paiements, remboursements, retraits, livraisons, expéditions, taxes ou processus internes sont configurés. Les données historiques et la configuration opérationnelle active sont deux couches distinctes.
Les Orders Square peuvent contenir lignes, références Customer, taxes, remises, retours, remboursements et informations de traitement. Un enregistrement historique migré peut préserver une partie de ces éléments sans activer un moyen de paiement, créer un processus de traitement actif ni recréer chaque statut source.
Signaux d’alerte précoces
| Raccourci de revue des Orders | Conséquence |
|---|---|
| Seuls le numéro, la date et le total de l’Order sont contrôlés. | Les lignes, remises, remboursements et informations de traitement peuvent être illisibles. |
| Les libellés de paiement source sont considérés comme une configuration de paiement active. | Les équipes attendent un processus d’achat qui n’a jamais été configuré. |
| Les remboursements sont représentés uniquement par des totaux négatifs. | Les éléments de retour et de paiement deviennent difficiles à expliquer. |
| Des statuts personnalisés sont copiés sans règle de responsabilité. | Les équipes ne savent pas si un état est historique, actif ou obsolète. |
Prévention
Définissez la finalité des Orders historiques : support Customer, référence financière, historique de traitement ou rapprochement. Préservez les éléments nécessaires à cette finalité, notamment lignes, totaux, contexte fiscal et de remise, lien Customer, remboursements ou retours et informations de traitement pertinentes.
Attribuez séparément la responsabilité des paiements actifs, de la création d’Orders, du traitement, des opérations de remboursement et des permissions des équipes.
Exemple de recommandation
Examinez un Order terminé en magasin, un Order en ligne avec expédition ou retrait, un Order remisé et un Order remboursé ou échangé. Confirmez que les équipes peuvent expliquer la transaction sans supposer que l’enregistrement historique pilote les paramètres Square actifs.
Condition de réussite
Les Orders historiques sont lisibles pour leur finalité métier approuvée, et chaque processus actif de paiement, traitement et remboursement possède un responsable de configuration distinct.
Piège 7 : perdre le sens des taxes, remises et prix appliqués au moment de la vente
Ce qui se passe mal
Les taxes et remises migrent comme libellés ou valeurs tandis que leur périmètre et leur logique d’application disparaissent. Une taxe peut s’appliquer à certains Products ou points de vente. Une remise peut être automatique, appliquée à une ligne, à un Order ou conditionnée par une autre règle. Si la cible reçoit seulement le nom et le montant, le prix final peut devenir incorrect.
Square modélise taxes et remises comme objets de catalogue et applique les ajustements de prix via les Orders et relations de catalogue. La règle source doit donc être reconstruite dans une relation commerciale prise en charge par Square ou recréée volontairement ailleurs.
Signaux d’alerte précoces
| Règle commerciale | Signal d’alerte précoce |
|---|---|
| Traitement fiscal propre à certains Products | Tous les Products héritent de la même taxe après migration. |
| Remise automatique | La remise existe mais ne s’applique jamais au moment de la vente. |
| Prix propres à un Customer ou à un canal | Le modèle cible ne possède qu’un prix de base global. |
| Ajustement de prix par modifier | La ligne d’Order n’explique pas le supplément. |
Prévention
Inventoriez les règles qui modifient la valeur de vente et classez chacune par déclencheur, périmètre, calcul et responsable. Préservez les données source nécessaires pour comparer les totaux attendus sans supposer que les valeurs historiques recréent la logique active.
Lorsqu’une règle ne peut pas être représentée directement, définissez un responsable de configuration cible, d’app ou d’intégration et documentez la manière dont le prix final sera calculé.
Exemple de recommandation
Utilisez un panier représentatif contenant un Product taxable, un Product remisé et un article avec modifier payant. Comparez les ajustements attendus au niveau des lignes et de l’Order avec leur représentation dans Square.
Condition de réussite
Les règles commerciales approuvées produisent des prix et totaux explicables sur les ventes représentatives, sans règle réduite à un libellé inutilisé.
Piège 8 : reporter les parcours et redirections Square Online à la fin
Ce qui se passe mal
La migration du catalogue est approuvée avant la planification des pages Square Online, URL Product, parcours Category, domaines et redirections. Le nouveau site est alors lancé avec des liens entrants cassés, des destinations de redirection sans rapport ou des chemins de contenu importants manquants alors même que les Products sont disponibles.
Square Online peut prendre en charge des redirections d’URL, mais une redirection a toujours besoin d’une destination pertinente. Rediriger tous les anciens parcours vers la page d’accueil ne préserve ni l’intention de l’acheteur ni la pertinence du contenu.
Signaux d’alerte précoces
| Situation de parcours | Priorité de prévention |
|---|---|
| Une URL Product à fort trafic change. | La mapper vers la page Product active équivalente. |
| Une ancienne Category est consolidée. | Choisir la Category ou page d’atterrissage survivante la plus proche. |
| Le domaine change en même temps que la plateforme. | Confirmer quelles redirections restent techniquement possibles. |
| Des images, documents ou chemins non pris en charge sont importants. | Prévoir un traitement séparé plutôt que supposer que les redirections de page suffisent. |
Prévention
Construisez l’inventaire des parcours pendant que les décisions sur le catalogue et le contenu sont encore prises. Classez chaque chemin important comme préservé, redirigé, consolidé, reconstruit ou retiré. Priorisez Products, Categories, campagnes, pages de politique et contenus liés depuis l’extérieur.
Vérifiez que les pages de destination sont publiées et pertinentes avant d’activer les redirections.
Exemple de recommandation
Pour une Category supprimée comportant plusieurs pages Product bien positionnées, mappez chaque Product vers son remplacement ou successeur et la Category vers la collection active ou le guide d’achat le plus pertinent. N’utilisez pas une destination unique pour tous les parcours.
Condition de réussite
Les URL source prioritaires atteignent des destinations Square Online pertinentes et publiées, et aucun parcours important ne dépend d’une hypothèse de redirection non documentée ou techniquement non prise en charge.
Piège 9 : cacher les données appartenant aux intégrations dans des champs ordinaires
Ce qui se passe mal
Les identifiants externes, métadonnées d’app, attributs personnalisés, horodatages de synchronisation ou indicateurs opérationnels sont copiés dans des champs Square génériques sans définir qui les lit ni qui les maintient. Les valeurs peuvent être visibles via une API mais indisponibles pour les équipes Point of Sale, ou être écrasées par une intégration après la bascule.
Square prend en charge des attributs personnalisés pour des objets Catalog et Customers, mais la visibilité varie selon l’objet et l’interface. Stocker une valeur ne suffit pas ; il faut connaître le consommateur qui continue à l’utiliser et le chemin d’accès.
Signaux d’alerte précoces
| Signal de données | Défaillance probable |
|---|---|
| Une valeur est migrée parce qu’elle pourrait être utile plus tard. | Aucun système ni aucune personne ne la consomme réellement. |
| Les équipes ont besoin de la valeur dans Point of Sale. | Elle est stockée uniquement dans un attribut personnalisé visible par API. |
| Un ERP resynchronisera le champ. | La valeur migrée est écrasée ou crée un conflit. |
| Les identifiants externes sont déplacés vers un autre niveau d’enregistrement. | Les relations Product, variation, Customer ou Order se rompent. |
Prévention
Créez un registre de responsabilité des intégrations pour chaque valeur non standard. Consignez le responsable source, l’enregistrement cible, le champ ou attribut personnalisé cible, le consommateur continu, l’autorité d’écriture et l’exigence de visibilité. Excluez les valeurs obsolètes au lieu de les conserver sans finalité.
Vérifiez que les équipes, rapports, apps et intégrations peuvent accéder à la valeur par l’interface qu’ils utilisent réellement.
Exemple de recommandation
Pour un identifiant ERP au niveau variation, confirmez qu’il reste rattaché à la variation vendable et non à l’article parent, puis vérifiez que l’intégration ERP lit exactement cet emplacement après la bascule.
Condition de réussite
Chaque valeur personnalisée ou appartenant à une intégration qui est conservée possède un consommateur identifié, un emplacement cible stable, la bonne visibilité pour les équipes ou l’API et une responsabilité d’écriture sans ambiguïté une fois la synchronisation active.
Carte de prévention transversale
| Zone de contrôle | Pièges couverts | Résultat requis |
|---|---|---|
| Modèle opérationnel cible | 1, 4, 6 | Les produits Square, canaux, points de vente et responsables de configuration active sont explicites. |
| Carte des relations de catalogue | 2, 3, 4, 7 | Articles, variations, modifiers, stock, Categories, taxes et remises conservent leur fonction. |
| Registre d’identité et d’intégration | 5, 9 | Le contexte Customer et celui des systèmes externes restent exploitables et gouvernés. |
| Modèle d’éléments pour les Orders | 6, 7 | Les transactions historiques restent explicables sans être confondues avec la configuration active. |
| Inventaire des parcours | 4, 8 | La découverte en ligne et les chemins entrants importants restent maîtrisés. |
Conclusion
La qualité d’une migration Square dépend de la préservation des relations opérationnelles, pas seulement de l’import de types d’enregistrements familiers. La structure de la bibliothèque d’articles influence la vente, le stock par point de vente influence la disponibilité, le contexte Customer influence le service, les éléments d’Order influencent le support et les parcours Square Online influencent la découverte. Lorsque chaque relation possède un responsable cible défini et une condition de réussite précise, les pièges récurrents deviennent visibles et peuvent être évités avant de perturber les opérations quotidiennes.
Questions fréquentes
Pourquoi Square diffère-t-il d’une migration vers une vitrine e-commerce classique ?
Square peut relier le même catalogue à Point of Sale, aux points de vente, au stock, aux Customers, Orders, paiements et à la vente en ligne. Un enregistrement correct dans une zone peut rester incomplet dans une autre ; le modèle opérationnel cible doit donc être explicite.
Les variantes source doivent-elles toujours devenir des variations d’article Square ?
Non. Un choix qui contrôle SKU, prix, image ou stock relève généralement de la structure de variation. Un ajout facultatif choisi au moment de la vente peut correspondre à un modifier. La fonction commerciale doit déterminer le niveau cible.
Peut-on copier un même total de stock sur tous les points de vente Square ?
Uniquement si cette duplication correspond réellement à la règle opérationnelle. Les marchands multi-sites ont généralement besoin d’une allocation approuvée ou d’une source de stock par point de vente. Copier le même total partout peut surestimer le stock disponible.
Les Orders migrés configurent-ils les paiements et le traitement Square ?
Non. Les Orders historiques peuvent conserver les éléments de transaction, mais le traitement des paiements, le traitement opérationnel, les remboursements et les processus des équipes nécessitent une configuration Square et des responsables distincts.
Comment gérer les champs personnalisés dans Square ?
Conservez uniquement les valeurs qui ont un consommateur continu. Déterminez si chacune appartient à un champ natif, un groupe, un attribut personnalisé, une app ou un système externe, puis confirmez que les personnes ou intégrations qui en ont besoin peuvent y accéder.
Qu’est-ce qui prouve que la gestion des parcours Square Online est prête ?
Les URL source prioritaires doivent atteindre des destinations publiées et pertinentes, les chemins Product, Category, campagne et contenu étant traités individuellement plutôt que redirigés sans distinction.