La validation d’une migration vers Square doit démontrer que les enregistrements migrés fonctionnent dans les relations propres au catalogue Square, aux points de vente, au stock, aux Customers, aux Orders et au site en ligne. Un nombre d’articles identique est utile pour le rapprochement, mais il ne prouve pas que la bonne variation peut être vendue, que le stock appartient au bon point de vente, que les modifiers restent distincts des variations, que les Customers sont retrouvables, que les Orders historiques restent compréhensibles ou que Square Online présente le catalogue et les parcours attendus.
Le modèle de validation doit distinguer les données migrées de la configuration Square active. Les Orders historiques peuvent conserver les lignes, ajustements, contexte de traitement et références de paiement sans configurer les paiements ou traitements actuels. Les enregistrements du catalogue peuvent être complets alors que la navigation Square Online, le retrait, la livraison, l’expédition, les domaines ou la présentation des pages nécessitent encore un travail côté cible. L’autorisation de mise en ligne dépend donc à la fois des éléments issus de la migration et d’un responsable identifié pour chaque point de configuration ou d’implémentation restant.
Définir l’ensemble des éléments de validation Square
La validation Square doit commencer par des enregistrements représentatifs qui exposent le modèle de relations de la plateforme. Les cas simples confirment le transfert de base ; les cas difficiles montrent si la migration a réellement préservé les structures utilisées par les équipes, les processus de stock, le support Customer et les systèmes connectés.
L’ensemble représentatif doit inclure, lorsque cela s’applique :
- un article de catalogue simple avec une seule variation vendable ;
- un article avec plusieurs variations définies par des options ;
- un article utilisant des modifiers plutôt que des variations portant du stock ;
- une variation avec un stock propre à un point de vente ;
- un article sensible aux Categories ou fortement dépendant des images ;
- un Customer avec plusieurs Orders ou un contexte de groupe/attribut personnalisé ;
- un acheteur invité ou faiblement identifié ;
- un Order comportant remises, taxes, frais de service, pourboires, traitement, remboursement ou références externes ;
- un article ou parcours Category prioritaire dans Square Online ;
- un identifiant appartenant à une application ou à un système externe.
| Type d’élément | Preuve lors du test de migration représentatif | Preuve lors d’une exécution plus large |
|---|---|---|
| Catalogue | Les articles, variations, options, modifiers, Categories, images, taxes et remises représentatifs conservent leur rôle prévu. | Le catalogue complet respecte la structure d’articles et de variations approuvée, sans exception inexpliquée. |
| Stock | Les variations sélectionnées présentent la quantité, l’état et la relation au point de vente attendus. | Toutes les quantités variation-point de vente incluses dans le périmètre sont rapprochées avec le modèle de stock d’ouverture approuvé. |
| Customers et Orders | Les exemples difficiles de Customers et d’Orders restent liés et lisibles. | Le périmètre historique complet, les exclusions, doublons et exceptions de relation sont rapprochés. |
| Square Online | Les exemples prioritaires d’articles, Categories, contenus, domaines et parcours atteignent les destinations prévues. | Tous les parcours prioritaires et contenus inclus ont un résultat approuvé et un responsable. |
| Intégrations | Les identifiants externes et enregistrements appartenant à des applications ont des responsables définis et des consommateurs testables. | Chaque clé d’intégration et sortie personnalisée incluse est rapprochée sur tout le périmètre. |
Les tests représentatifs doivent révéler les hypothèses avant l’exécution plus large. Ils ne doivent pas être approuvés simplement parce que des Products simples et des Orders récents semblent corrects.
Valider les articles, variations, options et modifiers
La bibliothèque d’articles Square distingue l’article général de la variation d’article effectivement vendue. Les options d’article peuvent standardiser des attributs de variation comme la taille ou la couleur. Les modifiers représentent des ajouts ou préférences au moment de la vente et ne créent pas automatiquement une identité distincte gérée en stock. La validation doit démontrer que la structure migrée respecte ces distinctions.
| Relation de catalogue | Élément de validation positif | Signal à surveiller | Signal bloquant |
|---|---|---|---|
| Article et variation | L’article parent et la variation vendable restent liés ; SKU, prix, image, mesure et identifiants appartiennent à la variation prévue. | Un nettoyage mineur des noms ou de l’ordre d’affichage reste nécessaire. | L’identité de variation est fusionnée, dupliquée ou liée au mauvais article. |
| Options d’article | Les valeurs d’option génèrent ou décrivent de façon cohérente les combinaisons de variations prévues. | Les libellés ou l’ordre nécessitent une normalisation côté cible. | Les acheteurs ne peuvent pas sélectionner la bonne combinaison vendable. |
| Modifiers | Les ajouts et préférences facultatifs restent distincts des variations portant le stock. | L’affichage ou le regroupement nécessite une configuration. | Un modifier est devenu un faux SKU, ou une vraie variation est devenue un modifier sans suivi de stock. |
| Categories et images | Les articles apparaissent dans les bonnes Categories et conservent le sens des images principales, de galerie ou propres aux variations. | L’ordre de médias secondaires doit être ajusté. | Des Products prioritaires sont masqués, mal classés ou privés d’images essentielles. |
| Taxes et remises | Les relations de catalogue incluses sont rattachées aux bons articles et les Orders historiques restent financièrement compréhensibles. | La configuration actuelle de la règle reste affectée à un responsable côté cible. | Les valeurs migrées produisent des prix visibles incorrects ou rendent les totaux historiques incompréhensibles. |
La validation doit également vérifier la possibilité de modifier les données. Les équipes doivent pouvoir identifier le bon article et la bonne variation, comprendre quelles valeurs sont partagées et lesquelles sont propres à une variation, puis mettre à jour le bon enregistrement sans créer d’identités commerciales en double. Il faut inclure au moins un Product dans lequel modifiers et options coexistent, car la vitrine peut sembler correcte alors que les équipes ne savent pas distinguer la sélection qui modifie le stock, le prix ou seulement la préférence au moment de la vente.
Valider le stock par variation et par point de vente
Dans Square, le stock est suivi pour les variations d’article et peut être propre à chaque point de vente. Une quantité au niveau Product est donc insuffisante lorsque la boutique source utilisait des SKU enfants, des succursales, des entrepôts ou des réserves de stock séparées. La validation doit relier la quantité à la variation vendable et au point de vente Square prévu.
Pour les enregistrements représentatifs portant du stock, vérifiez :
- que la bonne variation d’article est suivie en stock ;
- que le SKU et les clés de stock externes identifient la même unité vendable ;
- que la quantité apparaît sur le bon point de vente actif ;
- que les états illimité, non suivi, zéro, réservé, endommagé, retourné ou autres états source ont un sens Square approuvé ;
- qu’une vente ou un retour affecterait la bonne variation et le bon point de vente, et non l’article parent ou une autre succursale ;
- qu’un ERP, entrepôt ou canal connecté peut encore identifier la variation cible lorsque ce système reste l’autorité.
| Constat | Interprétation pour le lancement |
|---|---|
| La quantité diffère uniquement parce que l’horodatage approuvé du stock d’ouverture a changé | À surveiller, si l’écart est expliqué et que la règle de bascule finale a un responsable. |
| La quantité est correcte mais affectée au mauvais point de vente | Bloquant, car la disponibilité opérationnelle et la responsabilité de traitement sont incorrectes. |
| Le total parent correspond mais pas les quantités par variation | Bloquant, car les unités réellement vendables ne sont pas fiables. |
| La clé de stock externe existe mais n’est plus reconnue par le système faisant autorité | Bloquant jusqu’à correction de la clé ou du mapping d’intégration. |
| Un service non stocké n’est volontairement pas suivi en inventaire | Conforme lorsque le fonctionnement attendu de disponibilité est documenté. |
La validation du stock ne doit pas déclencher de mouvements de stock en double à partir des Orders historiques. L’Order importé constitue une trace du commerce passé ; le stock d’ouverture approuvé représente l’état opérationnel actuel.
Valider Square Online, les Categories, la recherche et les parcours
La validation du catalogue Square et celle de Square Online sont liées mais distinctes. Un article peut exister dans la bibliothèque d’articles tout en restant non publié, difficile à trouver, affecté à la mauvaise Category ou déconnecté du parcours en ligne prévu. Les pages Square Online, la navigation, les domaines, URL, redirections, le retrait, la livraison, l’expédition, la présentation et la publication du site nécessitent donc leurs propres éléments de validation lorsqu’ils font partie du périmètre cible.
Utilisez un registre des parcours prioritaires couvrant les Products générant du chiffre d’affaires, Categories importantes, destinations de campagne, pages de politique, pages de contenu et URL liées depuis l’extérieur. Pour chaque parcours, consignez la destination Square Online attendue et classez le résultat : résolution directe, redirection unique et pertinente, retrait approuvé ou échec non résolu.
Les éléments de validation positifs comprennent :
- les articles et Categories prioritaires sont visibles dans le contexte en ligne prévu ;
- l’appartenance aux Categories et la navigation mènent au bon ensemble de Products ;
- la recherche ou la navigation expose les articles représentatifs avec les libellés et options attendus ;
- images, descriptions, prix, disponibilité et présentation du traitement sont cohérents ;
- les domaines et l’état de publication dirigent les acheteurs vers le site prévu ;
- les anciennes URL prioritaires atteignent une destination pertinente sans boucle ni redirection sans rapport.
Un lien de menu manquant n’est pas automatiquement un défaut de migration, et une Category migrée ne recrée pas automatiquement la navigation du site. Le dossier d’autorisation de lancement doit distinguer les corrections apportées aux données migrées des travaux de configuration et de design Square Online.
Valider les Customers et les Orders historiques
Les profils Customer Square peuvent contenir coordonnées, relations de groupe, identifiants de référence, attributs personnalisés et liens vers des Orders. La validation doit démontrer la continuité d’identité sans créer de faux rapprochements ni de doublons inutiles. L’e-mail et le téléphone sont utiles comme indices, mais les achats invités, coordonnées partagées, adresses modifiées et identifiants CRM externes peuvent nécessiter un contexte supplémentaire.
La validation Customer doit couvrir :
- les acheteurs enregistrés et invités ;
- les identités dupliquées ou presque dupliquées ;
- les adresses et informations d’entreprise ;
- le contexte de groupe, segment, consentement, fidélité ou attribut personnalisé lorsqu’il est inclus ;
- les identifiants Customer externes utilisés par un CRM, système comptable, programme de fidélité ou processus de support ;
- les liens entre Customers et Orders historiques représentatifs.
La validation des Orders historiques doit inclure les lignes, références ou instantanés de variations, modifiers, quantités, prix, remises, frais de service, pourboires, taxes, liens Customer, adresses, source, point de vente, traitement, remboursements et identifiants externes lorsqu’ils sont inclus dans le périmètre. Les équipes doivent pouvoir répondre à la question : qui a acheté quoi, sur quel point de vente, dans quel Order et avec quel contexte financier et de traitement ?
| Résultat observé | Statut |
|---|---|
| Les totaux d’Order sont rapprochés et le sens des lignes est clair, tandis que la configuration actuelle du moyen de paiement reste séparée | Conforme |
| Le libellé de paiement est lisible mais une référence de transaction externe doit encore être confirmée par son responsable | À surveiller |
| Les Orders existent mais les lignes pointent vers les mauvaises variations ou les mauvais Customers | Bloquant |
| Le traitement historique est présent mais la configuration actuelle du retrait ou de la livraison est incomplète | À surveiller ou bloquant selon la dépendance au lancement ; responsabilité de l’implémentation cible et non d’une correction de migration |
| L’historique de remboursement ou d’ajustement modifie sensiblement le résultat financier mais manque ou induit en erreur | Bloquant |
Les Orders historiques ne prouvent pas que le processus d’achat actuel, les paiements, taxes, traitements, notifications ou le fonctionnement du stock sont prêts. Ces processus actifs exigent des éléments de validation séparés côté cible.
Valider le contenu, les attributs personnalisés, les apps et les systèmes externes
Une migration Square peut inclure des attributs personnalisés, identifiants de référence, champs appartenant à des applications, références de fidélité ou de carte-cadeau, clés comptables, données de livraison, identifiants marketplace ou autres données externes. Chaque valeur incluse doit avoir une entité parente définie et un consommateur qui continue à l’utiliser.
Utilisez un enregistrement traçable pour chaque besoin non standard :
| Champ requis | Élément de validation |
|---|---|
| Responsable source et ID d’exemple | Identifie précisément l’enregistrement et le système source. |
| Destination Square | Nomme l’article, la variation, le Customer, l’Order, la ligne, l’enregistrement du site ou l’objet d’application propriétaire de la valeur. |
| Transformation | Explique toute normalisation, combinaison ou restructuration. |
| Consommateur continu | Identifie le processus d’équipe, l’API, l’app, l’ERP, le CRM, l’entrepôt ou le rapport qui utilise le résultat. |
| Condition de réussite | Définit le résultat démontrant que la valeur reste exploitable. |
Les sorties de migration approuvées doivent être vérifiées par rapport à la demande achetée de filtrage, mapping ou configuration. Les sorties non standard doivent être vérifiées par rapport à la spécification Custom convenue. La validation ne doit pas étendre le périmètre accepté à une implémentation Square, une installation d’application, un design ou un déploiement d’intégration sans rapport, sauf si ces livrables ont été explicitement inclus.
Lorsqu’une intégration reste active, vérifiez les identifiants et relations dans le processus connecté. La présence d’une clé ERP dans Square ne suffit pas si l’ERP ne retrouve plus la variation ; une référence d’Order ne suffit pas si la comptabilité ne peut plus la rapprocher ; un identifiant de fidélité ne suffit pas si le compte de fidélité n’est plus relié au Customer.
Revalider après des actions de migration ultérieures
Un résultat déjà approuvé ne couvre pas automatiquement l’activité source ultérieure ni les changements de configuration. La revalidation doit suivre précisément l’action utilisée :
| Action de migration | Axe de revalidation requis |
|---|---|
| continuer avec la configuration acceptée | Démontrer que les nouveaux enregistrements éligibles respectent les filtres, mappings, modèle article/variation, responsabilité des points de vente et clés d’intégration déjà approuvés. |
| continuer avec une configuration révisée | Revalider chaque zone touchée par la modification des filtres, mappings, sélection de types de données ou configuration prise en charge, y compris les hypothèses précédemment approuvées qui ne s’appliquent plus. |
| produire un nouveau résultat de migration distinct | Traiter le nouveau résultat comme un ensemble d’éléments séparé ; répéter les contrôles de catalogue, stock, Customer, Order, contenu, intégration et décision de lancement. |
Pour chaque action, comparez les enregistrements concernés au résultat précédemment approuvé et confirmez la stabilité des enregistrements inchangés. Consignez les articles, variations, ensembles d’options, modifiers, affectations de points de vente, Customers, Orders, parcours, attributs personnalisés et références d’apps externes modifiés, puis répétez les scénarios acheteur, équipe et intégration qui en dépendent. Un échantillonnage ciblé est acceptable uniquement lorsque la dernière configuration utilisée et les relations entre objets Square restent inchangées. Une nouvelle configuration ou un résultat distinct exige une base de validation plus large. Les nouveaux Products, Customers, Orders et Blog Posts migrés doivent être rapprochés avec leurs relations et non vérifiés uniquement comme des volumes supplémentaires.
Appliquer les décisions de lancement Pass, Watch et Block
La décision finale doit reposer sur des éléments observables et une responsabilité claire. Chaque constat matériel doit identifier l’enregistrement ou le processus concerné, le responsable, la correction requise et la condition de nouveau contrôle.
| Décision | Interprétation Square |
|---|---|
| Pass | Le résultat migré est correct et exploitable pour l’usage Square prévu. |
| Watch | Une correction non bloquante, un point de configuration ou une décision de responsable reste ouvert, avec échéance et nouveau contrôle consignés. |
| Block | Le problème affecterait de manière importante la vente, l’identité des variations, le stock, la continuité Customer, les Orders historiques, le contexte financier, les parcours prioritaires, le traitement, la conformité ou une sortie Custom convenue. |
Square est prêt à être lancé uniquement lorsque tous les Blocks sont clôturés, que les éléments Watch ont des responsables, échéances et contrôles définis, et que les éléments de validation couvrent à la fois les enregistrements migrés et le fonctionnement requis côté cible. Le dossier de décision doit nommer précisément l’article, la variation, l’ensemble d’options, le modifier, le point de vente, le Customer, l’Order, le parcours et le processus externe testés. Il doit également distinguer les preuves issues des Orders historiques de la publication actuelle du catalogue, du stock par point de vente, des paiements, taxes, traitements, de la présentation Square Online et de la configuration des apps. Un décompte de catalogue, une connexion réussie ou une capture d’écran propre ne remplace pas ce dossier de décision.
Conclusion
La validation Square doit démontrer le fonctionnement du commerce connecté entre articles de catalogue, variations, modifiers, stock par point de vente, Customers, Orders historiques, Square Online et systèmes externes. Les tests représentatifs doivent exposer les relations difficiles ; l’exécution plus large doit rapprocher l’intégralité du périmètre approuvé et ses exceptions.
La décision de lancement devient crédible lorsque les données migrées et la configuration côté cible sont séparées, que les sorties prises en charge et sur mesure sont testées par rapport aux exigences convenues, que les actions de migration ultérieures reçoivent une revalidation proportionnée et que chaque constat aboutit à Pass, Watch ou Block avec un responsable identifié.
Questions fréquentes
Que faut-il valider en premier après un test représentatif de migration Square ?
Commencez par les enregistrements qui exposent le modèle de relations de Square : un article avec plusieurs variations, un article fondé sur des modifiers, un stock propre à un point de vente, un Customer avec des Orders liés, un Order avec des ajustements financiers ou de traitement, un parcours Square Online prioritaire et un identifiant externe utilisé par un système qui reste actif.
Des nombres d’articles et d’Orders identiques suffisent-ils pour approuver une migration Square ?
Non. Les décomptes peuvent révéler des enregistrements manquants, mais ils ne démontrent pas la bonne structure article-variation, le stock par point de vente, les liens Customer, le sens des lignes d’Order, la visibilité Square Online ou la continuité des intégrations.
Comment valider le stock Square ?
Validez la quantité et l’état au niveau de la variation d’article et du point de vente. Confirmez que la même variation est reconnue par les équipes et par tout ERP, entrepôt, canal ou système de reporting qui reste en service.
Les Orders migrés prouvent-ils que les paiements et le traitement Square sont prêts ?
Non. Les Orders historiques conservent des éléments de transaction. Les paiements, taxes, retrait, livraison, expédition, notifications et traitements actuels exigent une configuration et des preuves séparées côté cible.
Comment approuver des sorties correspondant à un ajustement convenu ou à une migration sur mesure ?
Vérifiez les ajustements de migration approuvés par rapport au résultat limité acheté de filtrage, mapping ou configuration, et les traitements non standard par rapport à la spécification Custom convenue. Aucun des deux ne doit être approuvé en fonction d’une attente non définie d’implémentation complète de Square.
Que faut-il revalider après une action de migration Square ultérieure ?
Revalidez les enregistrements et relations concernés par l’action choisie. Une nouvelle configuration exige des contrôles ciblés sur chaque mapping ou filtre modifié, tandis qu’une nouvelle migration nécessite un nouvel ensemble de validation de bout en bout.