Vendredi, 16 h 30. Une boutique Shopify active une remise réservée aux clients professionnels avant une campagne du week-end. Un test rapide est concluant : le produit s’ajoute au panier, le code passe et le paiement aboutit.
Lundi, le service client découvre trois réalités différentes. Un particulier connecté a obtenu la remise. Une commande B2B valide n’affiche pas le numéro de commande interne attendu. Une livraison locale payée normalement ne contient plus la consigne saisie dans le panier.
Le checkout n’était pas « en panne ». Il a encaissé. C’est précisément pourquoi ces erreurs sont dangereuses : elles déplacent le problème vers la marge, la préparation, la comptabilité ou le support, là où il coûte plus cher et devient plus difficile à reproduire.
Tester une règle Shopify ne consiste donc pas à cliquer une fois sur « payer ». Il faut vérifier une chaîne : client → panier → checkout → paiement → commande → email → admin → support.
Une règle peut casser sans bloquer le paiement
Une règle commerciale dépend rarement d’un seul écran. Elle peut lire le statut du client, une adresse, une zone de livraison, un produit, un montant, un attribut de panier ou la présence d’une remise. Une application peut ensuite enrichir la commande, un email reprendre certaines données et l’équipe logistique travailler depuis une vue différente.
Le paiement peut réussir tandis que :
- la mauvaise catégorie de client bénéficie d’une remise ;
- une restriction s’applique au panier classique mais pas au checkout accéléré ;
- une note cadeau ou une préférence de livraison reste dans le panier sans arriver dans la commande ;
- le prix est juste dans le checkout mais l’email affiche une information ambiguë ;
- l’administrateur voit la commande, mais pas le champ nécessaire au traitement ;
- un événement de campagne est envoyé sans la donnée qui permet de distinguer le parcours ;
- un remboursement devient manuel parce que le support ne comprend pas quelle règle a été appliquée.
La documentation Shopify actuelle renforce cette nécessité de tester par surface. Les fonctions Cart and Checkout Validation exécutent des règles côté serveur et peuvent couvrir le panier, le checkout et certains parcours accélérés, mais leur compatibilité n’est pas identique partout. Par ailleurs, Shopify déprécie depuis la version API 2026-07 le hook useBuyerJourneyIntercept, auparavant utilisé par certaines extensions pour bloquer la progression. Une boutique qui modifie une règle doit savoir où elle vit aujourd’hui, pas seulement où elle vivait lors de son installation.
Ce contexte technique ne demande pas au marchand d’éditer une API. Il demande une recette qui couvre les vrais cas de vente.
Partez du changement, puis dessinez ses dépendances
Avant d’ouvrir le navigateur, écrivez la nouvelle règle en une phrase sans vocabulaire technique :
« Les clients professionnels identifiés peuvent commander par multiples de six, avec une remise dédiée, et doivent fournir leur référence d’achat. »
Puis traduisez-la en questions observables :
- Comment Shopify reconnaît-il un client professionnel : connexion, entreprise B2B, tag, adresse ou autre donnée ?
- À quel moment la quantité est-elle contrôlée ?
- La remise est-elle automatique, saisie ou fournie par une application ?
- Où la référence d’achat doit-elle apparaître après paiement ?
- Que voit un client non éligible ?
- Que se passe-t-il avec un wallet ou un checkout accéléré ?
- Quel email et quelle vue admin utilisent les équipes ensuite ?
Cette carte courte évite le piège du « test de l’application ». Une règle peut traverser le thème, une fonction Shopify, une extension checkout, une application de remise, un outil de livraison, les notifications et l’ERP. L’objectif n’est pas d’attribuer immédiatement la faute. Il est de définir le résultat attendu à chaque relais.
Pour une boutique dont les dépendances se sont accumulées au fil des campagnes, une maintenance et gestion technique utile commence par cet inventaire avant toute nouvelle modification.
La matrice minimale avant mise en ligne
Préparez des données fictives ou des comptes de test. Évitez de créer une vraie obligation de livraison, une écriture comptable ou un débit non maîtrisé. Pour chaque ligne, notez le résultat attendu avant d’exécuter le parcours : sinon, une anomalie risque d’être acceptée simplement parce que l’écran « a l’air normal ».
| Cas à tester | Règle attendue | Preuve à garder | Risque si c’est faux |
|---|---|---|---|
| Client invité | Règle claire sans compte | Checkout + commande test | Blocage ou donnée manquante |
| Client existant | Profil et règle cohérents | Fiche client + commande | Mauvaise remise ou livraison |
| Client B2B / pro | Conditions pro et référence valides | Checkout + admin + email | Erreur commerciale ou support |
| Remise / bundle | Prix, exclusions et quantités justes | Panier + commande + email | Marge ou promotion incontrôlée |
| Livraison locale | Zone, frais, date et note cohérents | Checkout + détail commande | Livraison impossible ou coût faux |
| Paiement échoué | Panier et contexte restent exploitables | Échec simulé + abandon | Relance ou support sans contexte |
| Après commande | Email, admin et remboursement lisibles | Email + admin + note support | Traitement lent ou incorrect |
La matrice est un socle, pas une liste universelle. Ajoutez au moins un cas « frontière » propre à votre commerce : un code postal à la limite d’une zone, un panier juste sous le minimum, un client dont le statut vient d’être modifié, une remise à la date d’expiration ou un produit exclu ajouté à un bundle.
Ne testez pas seulement le parcours qui doit réussir
Une bonne validation doit accepter les cas valides et refuser proprement les autres. Pour la règle B2B ci-dessus, testez par exemple :
- un client pro connecté avec six unités et une référence valide ;
- le même client avec cinq unités ;
- un client particulier avec six unités ;
- un client pro dont le statut vient de changer ;
- le parcours via le bouton de checkout accéléré disponible sur la boutique ;
- une correction de quantité après affichage du premier message d’erreur.
Le message doit permettre à l’acheteur de corriger son action. Un blocage générique ou contradictoire peut être techniquement exact et commercialement désastreux.
Faites un passage mobile réel
Le checkout mobile n’est pas une réduction décorative du desktop. Vérifiez le clavier affiché, la visibilité du message, le retour au champ concerné, l’ouverture d’un lien d’aide et la conservation des données après correction. Un message placé hors écran ou une consigne tronquée transforme une validation légitime en abandon inexpliqué.
Pour un projet de création ou évolution de site e-commerce à Lyon, cette recette fonctionnelle doit être prévue dans le périmètre, avec les applications et parcours réellement utilisés par l’entreprise.
Gardez un dossier de preuves qui permet de corriger
Sept captures sans contexte ne constituent pas une recette. Pour chaque cas, conservez un petit paquet cohérent :
- identifiant du scénario et date du test ;
- état initial du compte, du panier et de la règle ;
- capture du panier et du checkout à l’étape utile ;
- numéro de commande test ou identifiant d’abandon ;
- résultat visible dans la commande et la fiche client admin ;
- email de confirmation ou de relance reçu ;
- note ou donnée visible par le support et la logistique ;
- trace de campagne ou d’événement si elle fait partie du besoin, sans la confondre avec une preuve absolue d’attribution ;
- résultat attendu, résultat obtenu et personne chargée du retest.
Masquez les données personnelles avant de partager ce dossier. Utilisez des comptes et adresses de test lorsque c’est possible, et supprimez les commandes fictives selon la procédure de l’entreprise.
Cette discipline raccourcit les échanges. « La remise ne marche pas » oblige le développeur ou l’éditeur d’application à reconstruire le contexte. « Scénario B2B-04, client tagué pro, panier de cinq unités, message absent sur checkout accéléré, commande test X » rend le défaut reproductible.
Règle, configuration, application ou développement : triez avant de corriger
Lorsqu’un scénario échoue, résistez à la tentation de modifier immédiatement plusieurs réglages. Classez d’abord l’anomalie.
Décision commerciale non définie. L’équipe ne sait pas si une carte cadeau se cumule avec la remise, si une commune frontalière appartient à la zone locale ou si un client pro nouvellement créé doit être éligible immédiatement. Le correctif est d’abord une décision écrite.
Configuration incohérente. Dates, segments clients, zones, exclusions produits ou priorités de remises ne correspondent pas à la règle validée. Corrigez un paramètre à la fois et rejouez les scénarios concernés.
Dépendance d’application. Le panier, le checkout et l’admin n’utilisent pas la même donnée, ou une application écrase le résultat d’une autre. Relevez les applications impliquées, leur rôle, leur version et le contact éditeur avant d’ouvrir un ticket documenté.
Développement à revoir. Une fonction, extension ou intégration personnalisée interprète mal une identité client, un attribut, une adresse ou une étape du parcours. C’est le moment de fournir le dossier de preuves au développeur, pas de demander au marchand de bricoler l’API.
Effet aval. La commande est correcte dans Shopify, mais l’email, le connecteur logistique, le CRM ou le support perd l’information. Le propriétaire du correctif est alors le système de transmission concerné.
Un audit de devis et de périmètre web aide aussi à rendre ces responsabilités explicites : qui vérifie la règle, qui configure l’application, qui développe, qui réalise la recette et qui accepte la mise en production ?
Le feu vert n’est pas « un test a marché »
Avant la mise en ligne, réunissez les preuves dans une courte fiche de décision :
- scénarios critiques réussis ;
- anomalies restantes et impact commercial ;
- règle de retour arrière ;
- personne joignable pendant la fenêtre de lancement ;
- indicateurs à surveiller : échecs, demandes support, remises inhabituelles, modes de livraison ou commandes incomplètes ;
- heure du retest après publication.
Une anomalie mineure peut être acceptée si son impact et son contournement sont compris. Une incertitude sur le prix, l’éligibilité, le paiement ou la capacité de livrer doit bloquer la publication. Cette décision appartient au marchand ; l’outil de test sert à la rendre factuelle.
Quand demander un audit checkout à 1Design
Un audit court devient pertinent lorsque la règle traverse plusieurs applications, que personne ne sait où elle est exécutée, que le prestataire historique n’est plus disponible ou qu’une campagne fixe une échéance impossible à déplacer.
1Design peut alors préparer un périmètre borné :
- carte des dépendances du panier au support ;
- matrice de scénarios adaptée à vos règles ;
- exécution et captures des parcours critiques ;
- classement des écarts par risque de chiffre d’affaires, de marge, de livraison ou de support ;
- notes de transmission pour le marchand, le développeur et les éditeurs d’applications.
Ce travail ne promet ni conversion garantie ni certification juridique, fiscale, analytics ou prestataire de paiement. Il vise une question plus concrète : la règle commerciale décidée par l’entreprise produit-elle le bon résultat, pour le bon client, jusque dans les outils qui traitent la commande ?
Avant d’activer une nouvelle remise, une règle de livraison, un parcours B2B, un champ checkout ou une campagne, contactez 1Design avec la règle en une phrase, les applications concernées et deux cas clients anonymisés. Nous pourrons cadrer une recette courte avant que le support ne découvre le défaut en production.
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?