Transaction dans le cadre du commerce électronique et la confiance

By 27 February 2013

5.3 Scénario 1 : Transaction dans le cadre du commerce électronique

Dans cette section, nous étudions le scénario d’une application de commerce électronique et nous proposons un modèle basé sur notre système de gestion de la confiance pour en assurer la sécurité des transactions. Notons que ce scénario a été présenté au chapitre 4.

5.3.1 Problème de confiance lors d’une transaction

Dans cet exemple nous considérons une transaction entre un marchand (le seller ) et un client (le buyer ). Le client veut acheter un produit chez le marchand. Le marchand observe la demande du client, et peut prendre en considération différents paramètres concernant la transaction : le profil du client, le montant de la transaction. . . Pour que la commande soit validée, le client doit payer son achat au marchand et pour ce faire il dispose de plusieurs méthodes : paiement par carte bancaire, virement, chèque ou mandat. Quand le marchand dispose de toutes les informations concernant la commande du client, comment peut-il décider de valider ou pas la transaction ? Le marchand dispose d’un ensemble d’informations concernant les transactions passées de ce client (sauvegardées dans son historique), le montant de la transaction courante, les informations relatives au paiement. . . Pour réduire les risques, le marchand met en place une politique de confiance qui va l’aider à prendre une décision sur la suite à donner à la commande que le client vient de passer. Si l’historique (avec ses configurations courantes) satisfait sa politique de confiance, la transaction peut se poursuivre, sinon elle sera interrompue. Ce scénario est illustré figure 5.2.

Dans cette figure, le client envoie sa commande au marchand et le paie en utilisant une des méthodes proposées par le marchand. Après avoir eu toutes ces informations, le marchand prend une décision pour traiter la demande du client. Cette décision est prise par le module de Gestion de la confiance.

Nous pouvons distinguer trois possibilités sur l’état d’un paiement : paiement valide,

paiement invalide et paiement inconnu :
-paiement valide : le marchand a reçu du client un paiement effectué par un moyen de confiance, par exemple un paiement par carte bancaire, par un mandat (le montant de la transaction a été effectivement crédité sur son compte).
-paiement invalide : le marchand reçu du client une preuve de paiement invalide (carte bancaire volée, fausse monnaie électronique).
-paiement inconnu : le marchand a reçu un paiement mais il n’a pas encore pu en vérifier la validité. Par exemple, le marchand a reçu un paiement par chèque mais il ne l’a pas encore encaissé.

À la fin de chaque transaction, le marchand peut évaluer le comportement du client concernant la transaction. Cette évalution peut être posivitve, négative ou neutre.

Pour minimiser les risques pris lors d’une transaction tout en simplifiant ses relations avec ses bons clients, le marchand peut mettre en œuvre la politique de confiance suivante :
-Si les risques sont faibles (le montant de la transaction est petit), il accepte de mener à leur terme les transactions avec des clients qu’il n’a jamais évalués de manière négative par le passé.
-Si les risques sont élevés (le montant de la transaction est important), il accepte de poursuivre la transaction s’il a reçu le paiement et si le client n’a jamais été évalué de manière négative.

Transaction du commerce électronique
Fig. 5.2 Transaction du commerce électronique

5.3.2 Modélisation du scénario

Nous proposons dans cette section une structure d’événements et une politique de confiance adaptées à ce scénario. Nous précisons également que cet exemple de modélisation a pour objectif de prendre une décision sur la transaction du côté du marchand. Nous présenterons au chapitre 6 une autre modélisation qui permettra au client et au marchand de mener à bien la transaction sous la forme d’une négociation.

Structure d’événements

La structure d’événements observée par le marchand est illustrée dans la figure 5.3. Les événements observés par le marchand se composent des actions et des données transmises par le client lors de la transaction.

-valid_payment, unvalid_payment, unkown_payment : le marchand a reçu un paiement qui est valide, invalide ou qui n’est pas encore vérifié.
-positive, negative, neutre : de quelle manière le marchand évalue le client.
-high_risk, low_risk, average_risk : niveau de risque de la transaction.
-object-order : le marchand a observé que le client envoie une commande.

Structure d’événements observée par le seller
Fig. 5.3 Structure d’événements observée par le seller

-object-send : le marchand a validé la transaction et envoie la marchandise au client.
-ignore : le marchand ne valide pas la transaction.

Notons que le risque sera calculé par un modèle de risque que nous présentons au chapitre 7. Pour l’instant, nous considérons que le risque associé à la transaction est représenté par un événement qui peut prendre comme valeur high_risk, low_risk ou average_risk.

Politique de confiance

Après avoir identifié des séquences à risque, le marchand peut proposer les politiques suivantes pour en limiter les conséquences :

-Le marchand rejette immédiatement la commande du client dont le paiement est invalide, ou si toutes les évaluations des transactions antérieures sont négatives :

(ψ1 ) : ignore → (object_order) ∧ (unvalid_payment ∨ G−1 (negative))

-En cas de risque important, le marchand n’accepte que les commandes de client dont le paiement est valide ou si toutes les évaluations de transactions antérieures sont positives :

(ψ2 ) : high_risk → (valid_payment ∨ G−1 (positive))

-En cas de risque faible, le vendeur accepte les commandes du client dont le statut du paiement est encore inconnu même si par le passé il a eu des évaluations négatives :

(ψ3 ) : low_risk ∧ unkown_payment ∧ F −1(negative)

La politique globale de confiance est une fonction (disjonction) des sous-politiques que nous venons de présenter :

ψglobal ≡ ψ1 ∧ ψ2 ∧ ψ3

Historique et vérifications

À chaque instant de la transaction, le marchand collecte les événements concernant la transaction et les sauvegardes dans la session courante de l’historique. L’ensemble des événements observé lors d’une transaction entre un client et un marchand permet de définir une session de l’historique. Le marchand peut avoir un nombre quelconque de sessions dans son historique.

Supposons que le marchand ait l’historique suivant pour un client :
HV ={object_order, low_risk, unkown_payment, negative}
{object_order, high_risk, valide_payment, positive}
{object_order, low_risk, valide_payment, positive}
{object_order, low_risk, valide_payment, positive}

Si la transaction courante avec ce client, la session xi contient les événements suivants :

1. {object_order, low_risk, unkown_payment}
Nous voyons que HV et xi satisfont la politque ψglobal , cette commande est donc validée.

2. {object_order, high_risk, unkown_payment}
Dans ce cas, nous voyons que xi ne satisfait pas la politique (et donc l’historique),

cette commande n’est pas validée.

5.3.3 Discussion

Dans ce scénario, nous avons présenté la mise œuvre de la politique de confiance du seul point de vue du marchand, mais nous devons considérer la politique de confiance des deux parties en présence dans la transaction, le marchand et le client. C’est de l’interaction de ces deux politiques de confiance que naitra la négociation entre les deux parties, qui permettra d’obtenir une confiance mutuelle pour la transaction. Ce problème sera étudié au chapitre 6 avec l’introduction de notre système de négociation de la confiance.

Lire le mémoire complet ==> (Infrastructure de gestion de la confiance sur Internet )
Thèse pour obtenir le grade de Docteur – Spécialité : Informatique
École Nationale Supérieure des Mines de Saint-Étienne