Les scénarios d’adresses transfrontalières sont souvent testés comme si une seule valeur de pays traversait la transaction. En pratique, une commande en porte fréquemment plusieurs : là où le client est enregistré, là où va la facture, là où le colis est livré, et sous les règles d’identité de quel pays le client a été vérifié.
Chacune de ces valeurs est un pays légitime, et rien ne les oblige à concorder. Le travail intéressant consiste à décider ce qui doit concorder, ce qui peut différer, et laquelle des valeurs est autorisée à régir une règle de validation.
Combien de valeurs de pays une commande peut-elle porter ?
Quatre est un bon point de départ, et elles sont suffisamment distinctes pour que fusionner deux quelconques d’entre elles fasse perdre de l’information.
| Rôle | Ce qu’il décrit | Quand il change |
|---|---|---|
| Pays d’enregistrement | Là où le compte a été créé | Presque jamais |
| Pays de facturation | Quelles règles et quelle devise le paiement suit | En cas de changement de moyen de paiement |
| Pays de livraison | Là où vont les marchandises | À chaque commande |
| Pays d’identité | Avec quel document la personne a été vérifiée | Lorsque le document est renouvelé ou remplacé |
Un cinquième apparaît dès qu’une plateforme, un vendeur de place de marché et un transporteur ont chacun leur propre vue de la destination. Ce n’est pas un cas limite ; c’est la forme normale d’une transaction transfrontalière à plus d’un participant.
La première décision de modélisation est de savoir si ces valeurs sont stockées comme une seule adresse avec plusieurs étiquettes ou comme plusieurs adresses qui se trouvent être liées. L’une ou l’autre peut fonctionner, mais un système qui stocke un seul pays et le réécrit à chaque étape ne peut plus répondre ensuite à la question qu’un litige posera : quel pays était vrai au moment où la commande a été passée ?
Laquelle d’entre elles doit régir la validation ?
Il n’y a pas de réponse universelle, ce qui est précisément pourquoi la règle doit être écrite. Plusieurs politiques défendables existent, et les mélanger silencieusement produit le défaut où une valeur est acceptée sur un écran et rejetée sur le suivant.
Une politique est que le pays de livraison régit, car l’adresse qui doit être physiquement accessible est celle dont les conventions comptent le plus. Une autre est que le pays de facturation régit, car les instruments de paiement et leurs règles suivent habituellement le payeur. Une troisième est que chaque champ est validé contre le pays auquel il appartient, ce qui est le plus correct et le plus exigeant à implémenter.
Quelle que soit celle retenue, le mode de défaillance de l’absence de choix est constant : deux composants ne sont pas d’accord, on dit à l’utilisateur que son adresse est invalide, et rien dans le message n’indique à laquelle des quatre valeurs de pays le reproche se réfère.
Que se passe-t-il lorsque les champs se contredisent ?
Un désaccord est normalement un signal plutôt qu’une erreur. Une adresse de livraison dans un pays et un numéro de téléphone dont l’indicatif appartient à un autre est banal pour quelqu’un qui vit près d’une frontière, et c’est aussi un schéma connu de fraude, si bien que le traiter comme automatiquement invalide fait perdre des clients légitimes.
L’approche pratique consiste à distinguer les conditions bloquantes des conditions indicatives. Très peu de désaccords empêchent véritablement la commande de se poursuivre ; la plupart réduisent simplement la confiance, et la confiance se traite mieux comme un signal collecté pour examen que comme une erreur de validation montrée au client.
La suite de tests devrait donc contenir des incohérences délibérées. Un pays de livraison différent du pays de facturation, un indicatif téléphonique qui appartient à un troisième pays, et une devise dont le foyer habituel est un quatrième sont trois cas qu’une fixture mono-pays ne peut jamais produire, et ce sont les cas où les défauts transfrontaliers se concentrent.
Il existe déjà un guide dédié à l’un de ces signaux, sur la correspondance entre indicatif téléphonique et localité, qui couvre le volet des indicatifs en détail ; ici, il suffit de noter que le signal appartient à un pays différent de l’adresse qu’il accompagne.
Qui est responsable de la décision lorsqu’une valeur est rejetée ?
La responsabilité est la partie que l’on saute, et son absence est ce qui transforme un bogue transfrontalier en longue discussion.
Pour chaque règle de validation, quelqu’un devrait pouvoir répondre à trois questions. Quelle valeur de pays a sélectionné cette règle ? Quelle est la justification de la règle ? Et qui peut la modifier ? Une règle dont le responsable est inconnu ne peut pas être modifiée en toute sécurité, si bien qu’elle reste en place et accumule des exceptions sur ses bords.
Attribuer une responsabilité expose aussi les règles qui existent sans raison. Une règle héritée qui rejette une valeur bien formée pour un pays avec lequel personne ne commerce est un coût pur, et elle ne remontera jamais tant que personne n’est mis au défi de la défendre.
Pour les développeurs : modélisez les rôles, pas un seul champ pays
Donnez à chaque rôle sa propre valeur, avec son propre cycle de vie et sa propre validation, et laissez la transaction consigner quel rôle a régi quelle décision. Ce seul changement transforme la plupart des questions transfrontalières d’archéologie en simple consultation.
Ensuite, testez les combinaisons plutôt que les champs. Une matrice dans laquelle le pays de livraison, le pays de facturation et l’indicatif téléphonique varient indépendamment est assez petite pour s’exécuter et assez grande pour détecter les désaccords qui comptent. Lorsqu’un petit territoire est impliqué, les pièges spécifiques sont couverts dans le guide des petits territoires et codes spéciaux, car ces destinations sont celles où les incohérences de rôle sont le plus souvent mal gérées.
Gardez les cas résultants lisibles. Un cas nommé pour ce qu’il fait varier vaut mieux qu’un cas nommé pour le ticket qui l’a produit. Pour la forme de l’adresse elle-même une fois le pays fixé, le répertoire des pays et régions et une page telle que l’entrée de l’Allemagne montrent comment les conventions d’un pays sont décrites isolément, ce qui est le bon point de comparaison avant d’ajouter un second pays à la transaction.
Toutes les adresses, combinaisons de pays et détails de commande utilisés dans cet article sont des exemples fictifs écrits pour illustrer une question de modélisation. Ils ne décrivent aucun client, aucune commande et aucune transaction réels, et aucune valeur montrée ici ne doit être lue comme une donnée issue d’un système en production.
Prochaines étapes
Prenez un enregistrement de commande existant et essayez de répondre, à partir des seules données stockées, quel pays a régi chaque validation exécutée pendant le paiement. Si l’une de ces réponses est indisponible, les rôles ne sont pas encore modélisés séparément. Le guide pays ou langue couvre la distinction voisine entre le lieu et la langue, que les cas transfrontaliers tendent à confondre de la même manière.