Politique de confiance dans une transaction de e-commerce
6.5.3 Observations et structures d’événements
Nous proposons dans cette section un modèle d’observation de la transaction. Celuici est décrit par la structure d’événements définie par chacune des entités, le vendeur et l’acheteur. Nous précisons que le modèle d’observation de chaque entité lui est propre et dépend de la structure d’événements qu’il a choisie. Nous présentons la structure d’événements de l’acheteur dans la figure 6.7 et celle du vendeur figure 6.8.
Fig. 6.7 Acheteur : Structure d’événements
La structure d’événements de chaque entité décrit les relations de conflit et de causalité que doivent respecter les événements. Les points suivants présentent des explications détaillées sur chacun des événements de la structure d’événements de l’acheteur et du vendeur.
Fig. 6.8 Vendeur : Structure d’événements
Acheteur : structure d’événements
La spécification des événements de la structure d’événements de l’acheteur est donnée ci-dessous.
- -object_request : événement local indiquant que l’acheteur passe une commande à un vendeur.
- -object_received : indique qu’il reçoit un message contenant une confirmation du paiement et un plan d’envoi du produit de la part du vendeur.
- -obj_time_out : indique qu’il n’a reçu aucune information du vendeur après avoir passé sa commande.
- -high_risk, average_risk, low_risk : événements locaux qui décrivent le niveau de risque de la transaction (élevé, moyen ou faible). Ces événements sont déterminés par le risk manager qui sera présenté dans le chapitre 7. Ce composant utilise les informations disponibles sur la transaction (coût total, probabilité d’échec. . . ) pour évaluer le niveau de risque.
- -positive, neutral, negative : évaluation de la qualité de la transaction par le client.
- -payment_request : l’événement qui indique que le vendeur a envoyé une demande de paiement suite à la commande.
- -pay_direct : événement qui indique que le paiement est effectué directement (carte bancaire, argent liquide…). Cet événement fait suite à la demande de paiement du vendeur.
- -pay_TTP : événement qui indique que le paiement est effectué en ayant recours aux services d’un tiers de confiance.
- -pay_ignore : indique qu’il ignore la demande de paiement du vendeur.
- -pay_confirm : indique qu’il confirme le paiement auprès du tiers de confiance.
- -pay_confirm_req : l’événement qui indique que le vendeur demande une confirmation de paiement
- -pay_cancel : indique que le vendeur ne valide pas son paiement auprès du tiers de confiance.
À partir de cet ensemble d’événements et l’objectif du client, nous pouvons trouver que l’événement qui spécifie l’objectif du client dans la structure d’événements est object_received.
Vendeur : structure d’événements
Nous trouvons ci-dessous la spécification de la structure d’événements du vendeur.
-object_order : indique que le vendeur reçoit une commande d’un acheteur.
-object_send : événement qui indique que le vendeur a envoyé le produit à l’acheteur.
-order_ignore : événement local qui indique que le vendeur ignore la commande du client. Cela peut survenir dans le cas d’une commande invalide ou dans le cas d’un client considéré comme étant un escroc, un voleur…
-ask_payment : l’événement indiquant que le vendeur réclame le paiement de la commande à l’acheteur.
-payment_received : indique que le vendeur a reçu le paiement de l’acheteur par la méthode de paiement direct.
-payment_TTP_received : indique que le vendeur a reçu le paiement avec la méthode de paiement par du tiers de paiement.
-pay_TTP_notified : indique que qu le vendeur reçoit une notification de paiement par un tiers de confiance.
-payment_time_out : indique qu’il n’a toujours pas reçu de paiement après un délai fixé.
-Les autres événements ont la même sémantique que ceux décrits pour la structure d’événements de l’acheteur.
-ask_pay_confirm : l’événement indiquant que le vendeur demande une confirmation de paiement l’acheteur.
À partir de cet ensemble d’événements et de l’objectif du vendeur, nous voyons que les événements d’objectif du vendeur dans la structure d’événements sont payment_received et payement_TTP_received.
6.5.4 Politique de confiance
Grâce à sa structure d’événements, chaque entité qui participe à la transaction (vendeur et acheteur) peut construire sa propre politique de confiance. Cette politique lui permet de vérifier que, à chaque étape, la négociation se déroule en satisfaisant correctement sa politique. La politique est exprimée sous la forme d’une formule logique PP-LTL qui décrit le comportement attendu tout au long de la transaction.
Politique de l’acheteur
La politique que l’acheteur met en place tend à minimiser les risques qu’il prend. Il refuse de prendre des risques avec les gens qu’il ne connaît pas, si les pertes financières possibles sont trop conséquentes ou s’il a déjà eu des problèmes avec le vendeur.
Avec la structure d’événements du client présentée par la figure 6.7, nous constatons que le client peut éviter deux conséquences risquées qui peuvent survenir s’il effectue le paiement après la demande du vendeur :
- -la conséquence pay_direct → obj_time_out indique que le client a payé par un règlement direct mais que le vendeur n’a pas envoyé le produit;
- -la conséquence pay_T T P → obj_time_out indique que le client a payé par l’intermédiaire d’un service de confiance mais que le vendeur n’a pas envoyé le produit.
Pour éviter cela, en tenant compte des informations liées aux risques et à l’historique des transactions, le client peut proposer les politiques suivantes pour éviter de voir apparaitre ces conséquences lors de la négociation.
-Lorsqu’il reçoit une demande de paiement du vendeur, le client n’effectue pas de paiement direct s’il trouve que dans ses transactions antérieures avec ce vendeur il y a déjà eu pay_direct → obj_time_out, ou si le risque lié à la transaction est elevé.
ψ1 : pay_direct =⇒ ¬(payment_request∧
high_risk ∧ F −1 (pay_direct ∧ obj_time_out))
-Lorsque le risque est bas, ou lorsque le risque est moyen et que dans le passé il
n’y a jamais eu pay_direct → obj_time_out, le client n’utilise pas les services du tiers de confiance.
ψ2 : pay_T T P =⇒ payment_request ∧ [low_risk
∨(average_risk ∧ G−1 (pay_direct ∧ obj_time_out)]
La politique globale de l’acheteur serait alors : ψA ≡ ψ1 ∧ ψ2 .
Politique du vendeur
De la même manière, le vendeur veut se protéger des acheteurs indélicats et minimiser ses risques de pertes financières. Nous utilisons la structure d’événements pour spécifier d’abord les conséquences à risque pour le vendeur.
Dans l’arbre des transitions, nous voyons que le vendeur a intérêt à éviter les conséquences qui contiennent les chaînes suivantes :
-object_send → T T P _time_out : le client a payé par un tiers de confiance, le vendeur a envoyé le produit mais il n’y a jamais eu de confirmation du paiement.
-object_send → pay_time_out : le vendeur a envoyé le produit avant de demander un paiement au client et le client ne le paie pas.
-ask_pay_conf irm → T T P _time_out : le vendeur a envoyé le produit avant d’avoir le paiement; le client a payé par le tiers de confiance mais ne confirme jamais le paiement.
-obj_order → ignore_cmd : cas où le vendeur reçoit des commandes de clients considérés comme indélicats.
En utilisant les informations de risque et l’historique, le vendeur peut proposer les politiques suivantes pour éviter ces situations :
-Le vendeur n’accepte pas les commandes de la part de clients qu’il a évalués de manière négative dans le passé. ψ1 : G−1 (negative) =⇒ obj_order ∧ ignore_cmd
-Si le vendeur accepte d’envoyer le produit au client avant d’en avoir le paiement, il envoie en même temps la demande de paiement. ψ2 : (object_order ∧ object_send) =⇒ ask_payment
-Le vendeur envoie le produit au client avant de demander un paiement seulement dans le cas où les risques sont faibles et s’il n’y a pas eu d’évaluation négative sur une transaction avec ce client. ψ3 : object_send =⇒ [low_risk ∧ F −1(negative)]
-Le vendeur n’accepte que le mode de paiement par un tiers de confiance si les risques sont élevés et si dans le passé, il n’a pas eu de problème de paiement après l’envoi du produit.
ψ4 : [high_risk ∧ F −1 (object_send ∧ pay_cancel)]
=⇒ T T P _notif ied
La politique globale du vendeur est donc : ψ ≡ ψ1 ∧ ψ2 ∧ ψ3 ∧ ψ4 .
