Règles COD intelligentes sur Shopify : pays, code postal, panier et tags client

Pour de nombreux marchands Shopify, le paiement à la livraison commence comme un simple réglage activé ou désactivé : l’afficher à tout le monde, ou le supprimer complètement. C’est aussi le moyen le plus rapide soit de faire fuir de bons clients, soit d’assumer un risque évitable.

La solution n’est pas de supprimer le COD. Il faut contrôler où il apparaît. Un client qui achète un article de faible valeur dans une zone avec un bon historique de livraison n’a rien à voir avec un nouvel acheteur qui passe une commande élevée dans un code postal connu pour ses échecs de livraison. Traiter ces deux cas de la même manière, en affichant toujours le COD ou en ne l’affichant jamais, revient à ignorer cette différence.

C’est précisément à cela que servent les règles de visibilité du COD. Au lieu d’un simple interrupteur on/off, la boutique décide qui voit le paiement à la livraison comme option, selon le pays, le code ZIP ou postal, le montant du panier et les tags client. Ce guide explique comment configurer chacun de ces leviers dans Progus COD Form & OTP SMS.

Avant de commencer, il est utile de distinguer deux notions souvent confondues. Les règles de visibilité déterminent si un client voit ou non le paiement à la livraison comme option de paiement : si une règle masque le COD pour un pays, un montant de panier ou un client donné, ce client n’accède même pas à l’étape de paiement COD. La vérification OTP est une couche distincte qui confirme le numéro de téléphone d’un client ayant déjà choisi le COD, une fois arrivé à cette étape ; elle ne décide pas qui voit l’option, elle vérifie qui est réel parmi ceux qui y ont déjà accès. Les deux fonctionnent donc en séquence : les règles de visibilité filtrent d’abord, puis la vérification OTP contrôle ce qu’il reste. Pour une vue d’ensemble de la façon dont ces couches fonctionnent avec les listes de blocage pour les récidivistes, consultez le guide Progus sur la fraude COD et les abus de retours ; ce tutoriel se concentre spécifiquement sur la configuration de la couche de visibilité.

Étape 1 : activer les règles avant toute configuration

Le générateur de règles doit être activé avant de permettre la création de règles. Dans Progus COD Form & OTP SMS, allez dans la section Checkout de l’application, choisissez quel tarif d’expédition doit être considéré comme COD, puis activez le COD au checkout. Tant que cette activation n’est pas terminée, l’écran des règles affichera un message de type « configuration required » au lieu de proposer l’ajout d’une règle.

Étape 2 : choisir les leviers vraiment utiles

Avant de créer une règle, définissez clairement le problème qu’elle doit résoudre. Au lieu d’un simple interrupteur activé/désactivé, l’application permet d’afficher ou de masquer le COD selon le pays, le code ZIP ou postal, le montant du panier et les tags client, et une seule règle peut combiner plusieurs de ces critères.

Voici quelques points de départ fréquents :

• Protection des commandes à forte valeur : masquez le COD lorsque le montant du panier dépasse un seuil défini, afin que les commandes les plus risquées passent en paiement anticipé.
• Exclusion par code postal : affichez le COD sur votre marché domestique principal, mais masquez-le pour les codes postaux avec des échecs de livraison répétés ou des retours à l’expéditeur.
• Exception pour les clients de confiance : utilisez un tag client pour maintenir le COD disponible pour les clients récurrents avec un bon historique de livraison, même si des règles plus larges le limiteraient autrement.

Les étapes 3 à 5 ci-dessous détaillent chaque levier séparément. Vous n’avez pas besoin de tous les utiliser : choisissez ceux qui correspondent au problème identifié ici, et combinez-les dans une seule règle si votre formule ne permet qu’une seule règle active à la fois (nous y revenons à l’étape 7).

Avant d’écrire la moindre règle, partez de données concrètes, pas d’hypothèses : vérifiez quels pays, codes postaux ou tranches de panier présentent réellement un schéma d’échecs de livraison COD ou de fraude, car une règle fondée sur une intuition risque autant de bloquer de bons clients que de mauvais. Une fois le vrai problème identifié, privilégiez des exclusions ciblées plutôt que des restrictions larges : exclure les codes postaux réellement problématiques est plus sûr que restreindre toute une région, et limiter une tranche de panier au-dessus d’un seuil clair est plus sûr que désactiver le COD pour tout un pays à cause de quelques mauvaises commandes.

Le générateur de règles prend aussi en charge des conditions liées à la présence d’une remise, au poids de la commande, au statut d’inscription du client, au nombre de commandes, à l’e-mail du client, aux collections de produits, à la présence de cartes-cadeaux dans le panier et aux plages de dates pour des règles planifiées ou saisonnières. Il est utile de le savoir même si ce tutoriel ne les couvre pas en détail : une condition de plage de dates, par exemple, peut limiter le COD à une période promotionnelle précise, et une condition de poids de commande peut cibler la disponibilité du COD selon la complexité logistique plutôt que le prix seul.

Étape 3 : définir les conditions par pays et code postal

Pays. C’est le levier le plus simple. Certaines boutiques proposent le COD uniquement au niveau national, là où les réseaux de livraison sont fiables et les retours maîtrisables, tandis que les commandes internationales passent par défaut en paiement anticipé. D’autres ont besoin de l’inverse : activer le COD spécifiquement sur les marchés où le paiement anticipé inspire peu confiance et convertit mal, et le désactiver là où il n’est pas nécessaire.

Code ZIP ou code postal. Un contrôle au niveau du pays est souvent trop large. La fiabilité de livraison, les taux de retour à l’expéditeur et la couverture des transporteurs varient fréquemment d’une zone à l’autre au sein d’un même pays. Une boutique dont les problèmes COD sont concentrés sur quelques codes postaux n’a pas besoin de restreindre tout le pays, seulement ces zones précises, soit en excluant les codes connus comme problématiques, soit en autorisant le COD uniquement dans les codes postaux ayant un bon historique de livraison.

Le pays et le code postal se trouvent dans la même catégorie Location. Cela signifie que vous pouvez créer une seule règle qui autorise le COD dans un pays tout en excluant certains codes postaux avec des échecs de livraison répétés, sans avoir besoin de deux règles distinctes.

Par ailleurs, la zone de protection contre la fraude de l’application inclut aussi son propre blocage par code postal, ainsi que par e-mail, numéro de téléphone et adresse IP, avec en plus une limite sur le nombre de commandes qu’un même client peut passer sur une période donnée. Cet outil vise spécifiquement les acteurs malveillants identifiés, plutôt que la gestion générale de la visibilité du COD. Une boutique peut donc utiliser les codes postaux à deux endroits pour des raisons différentes : d’un côté pour ajuster largement la visibilité dans le générateur de règles, et de l’autre pour un blocage antifraude ciblé dans les paramètres de protection.

Étape 4 : ajouter une limite de montant du panier

Les commandes de forte valeur comportent un risque absolu plus élevé lorsqu’une livraison COD échoue ou est refusée : coût produit plus important, frais d’expédition perdus, marge davantage exposée. Une pratique courante consiste à plafonner le COD en dessous d’un certain montant de panier et à exiger un paiement anticipé au-delà, afin que les commandes où l’enjeu financier est le plus élevé soient aussi celles dont le paiement est confirmé à l’avance.

Définissez cela comme une condition Order Details dans la même règle que vos conditions de localisation si votre formule limite le nombre de règles, ou comme une règle séparée si votre formule autorise un nombre illimité de règles.

Étape 5 : utiliser les tags client pour les acheteurs fiables ou à risque

Le pays, le code postal et le montant du panier s’appliquent tous avant que la boutique ne sache quoi que ce soit sur l’acheteur précis. Les tags client permettent à une règle de réagir à l’identité réelle de l’acheteur : un tag pour les clients avec un bon historique de livraisons COD peut maintenir l’option ouverte pour eux malgré d’autres conditions, tandis qu’un tag appliqué après une livraison échouée ou refusée peut restreindre le COD pour ce client à l’avenir sans pénaliser les autres.

Les tags client se configurent dans la catégorie Customers du même générateur de règles, aux côtés des conditions liées au statut d’inscription, au nombre de commandes et à l’e-mail du client. Utilisez les tags pour créer des exceptions, pas seulement des restrictions : un tag est tout aussi utile pour garder le COD disponible pour un client fidèle et fiable, même si une règle plus large le limiterait autrement, afin que la fidélité ne soit pas pénalisée par une règle pensée pour les inconnus.

Étape 6 : tester l’interaction entre les conditions d’affichage et de masquage

Si une même règle combine une condition « show » avec une condition « hide », l’application affiche un avertissement, car il existe un ordre de priorité fixe à connaître avant de s’y fier : « show » l’emporte toujours sur « hide ». Dès qu’une condition « show » correspond, elle gagne, quelle que soit la condition « hide ».

Par exemple, si une règle masque le COD pour un code postal précis mais affiche aussi le COD pour les clients portant le tag [trusted-cod], un client avec ce tag pourra quand même voir le COD même si son code postal figure sur la liste de masquage. Cela peut être utile, mais seulement si c’est intentionnel. Il faut donc tester cette combinaison avant de supposer qu’une condition « hide » fait bien ce que vous attendez.

Étape 7 : revoir la règle après le lancement

Un code postal qui posait problème il y a six mois n’en pose peut-être plus aujourd’hui. Les règles qui ne sont jamais réévaluées passent souvent de « ciblées sur un vrai problème » à « restrictives sans raison actuelle », donc prévoyez un rappel pour vérifier leurs performances au fil du temps, et pas seulement lors de la configuration initiale.

Cette fonctionnalité apparaît dans l’application sous le nom Smart checkout rules, et le nombre de règles que vous pouvez consulter ou ajouter dépend de votre formule : Free et Basic autorisent 1 règle active, donc la révision consiste à vérifier que cette règle unique combine toujours les bons critères ; Standard et Premium autorisent un nombre illimité de règles, donc la révision consiste à vérifier si certaines sont devenues obsolètes ou redondantes maintenant que plusieurs règles sont en place.

Erreurs fréquentes

1. Créer des règles pour des marchés où la boutique vend à peine. Passer du temps à restreindre un pays qui génère quelques commandes par an est rarement pertinent comparé au fait d’optimiser correctement les règles pour le marché domestique ou le principal marché.
2. Empiler trop de conditions dans une seule règle. Une règle qui combine de nombreux critères devient difficile à comprendre et à déboguer quand quelque chose ne se comporte pas comme prévu. Sur les formules avec règles illimitées, des règles séparées et plus simples sont généralement plus faciles à maintenir. Sur Free ou Basic, où une seule règle active est disponible, la priorité doit être une règle ciblée qui ne combine que les conditions ayant le plus d’impact.
3. Oublier de tester sur mobile. Quel que soit ce que la règle affiche ou masque, vérifiez que le checkout reste correct sur téléphone, car c’est souvent là que le trafic COD convertit ou abandonne le plus.
4. Ne jamais vérifier ce que les règles ont réellement bloqué. Une règle qui masque discrètement le COD pour une condition trop large peut faire baisser les conversions sans que personne ne s’en rende compte, si personne n’analyse les commandes concernées.

Checklist de configuration

Les règles COD intelligentes fonctionnent bien lorsque :

• les règles s’appuient sur les données réelles de livraison et de fraude de la boutique, et non sur des suppositions concernant les marchés ou régions à risque
• les exclusions par code postal sont précises et ne servent pas de substitut pour exclure toute une région
• un seuil de montant du panier existe pour les tailles de commande les plus risquées, et il est révisé à partir de vraies données de commande plutôt que d’une estimation
• les tags client servent à protéger les acheteurs fidèles et fiables, pas seulement à restreindre les profils à risque
• quelqu’un examine les performances des règles régulièrement, et pas uniquement au moment de la mise en place

En conclusion

Le paiement à la livraison n’a pas besoin d’être une solution tout ou rien. Les règles de visibilité permettent à une boutique de conserver le COD là où il est réellement utile, en transformant des acheteurs hésitants en commandes finalisées, tout en le retirant des pays, codes postaux, montants de panier et historiques client précis où il tend plutôt à créer du risque.

L’objectif n’est pas de rendre le COD rare. Il est de le rendre disponible exactement dans les situations où il fonctionne, et absent là où il ne fonctionne pas. Si le paiement à la livraison fait partie de votre checkout Shopify, Progus COD Form & OTP SMS peut vous aider à construire cet ensemble de règles au même endroit, des règles de visibilité COD jusqu’à la vérification OTP pour les commandes qui nécessitent encore une confirmation.