6.5.5 Stratégie de négociation
Après avoir présenté la structure d’événements et la politique propre de chaque partie du protocole, nous allons détailler la phase de négociation et l’utilité du module de gestion de la Stratégie de Négociation. La négociation est décrite par la succession des événements sélectionnés à chaque étape du processus. Nous allons dérouler le processus de négociation pour deux situations : l’achat d’un morceau de musique en MP3 et l’achat d’un Smartphone.
La différence entre ces deux scénarios est liée au montant de la transaction et aux risques qui peuvent être perçus différemment par les participants. Nous rappelons que le processus de négociation utilise l’historique des interactions propre à chacun des participants et que les observations se traduisent par la mise à jour de la session courante de cet historique.
Supposons que l’historique du client et celui du marchand soient respectivement Hc et Hm au moment de la transaction :
Hc ={object_request, average_risk, payment_request, object_received}
{object_request, low_risk, payment_request, object_time_out}
{object_request, high_risk, payment_request, pay_T T P,
object_received, pay_conf irm}
Hm ={object_order, low_risk, object_send, pay_time_out}
{object_order, average_risk, aks_payement, payment_received, object_send}
{object_order, high_risk, payment_request, pay_T T P, T T P _notif ied,
object_send, payement_received}
Il nous faut préciser que l’historique du client et celui du vendeur peuvent ne pas contenir le même nombre de sessions. Le client et le vendeur peuvent ne sauvegarder que les sessions qu’ils considèrent comme importantes.
Transaction pour une chanson MP3
Pour la transaction concernant l’achat d’une chanson MP3, l’acheteur et le vendeur peuvent considérer que le niveau de risque est bas. Cela nous conduit à une situation où le Risk Evaluator de chaque participant fournit l’événement low_risk pour la transaction.
C’est le client qui débute la négociation. Le processus de négociation passe par les étapes suivantes (client et marchand ) :
Étape 1, côté client
-Pour débuter la négociation, une nouvelle session, xc est ajoutée à l’historique HC . Le client envoie la commande, son action est prise en compte et ajoutée à xc , xc = {object_request}.
-Le client évalue immédiatement le risque, il trouve low_risk pour ce cas et cela est aussi pris en compte en xc, xc = {object_request, low_risk}
Étape 2, côté marchand
-Pour prendre en compte la transaction, une nouvelle session xm, est également ajoutée à l’historique Hm. Le marchand reçoit la commande, l’événement object_order est ajouté à xm , xm = {object_order}
-Le marchand évalue immédiatement le risque, il trouve low_risk pour ce cas et c’est aussi pris en compte dans xm , xm = {object_order, low_risk}
-Ensuite, le marchand sélectionne un événement qui correspond avec sa politique pour réagir. Cette vérification fournit ask_payment comme le résultat, il est pris en compte. La session xm actuelle est : xm = {object_order, low_risk, ask_payment}.
Étape 3, côté client
-Lorsque le client reçoit la demande de paiement, il met son historique à jour (xc = {object_request, low_risk, pay_request}).
-En confrontant sa politique de confiance à son historique, le client trouve que les actions correspondant aux événements pay_direct, pay_T T P et pay_ignore sont des candidats possibles.
-La Stratégie de Négociation sélectionne pay_direct pour réagir auprès du marchand; l’événement est ajouté à l’historique et le message envoyé :
xc = {object_request, low_risk, pay_request, pay_direct}.
Étape 4, côté marchand
-Le marchand interprète le message du client sous la forme de l’événement payment_received. A ce stade, sa session courante est :
xm = {object_order, low_risk, ask_payment, payment_received}.
Après vérification de sa politique, il trouve que l’événement send_objet est une réaction appropriée. Il envoie l’objet commandé au client et ajoute send_objet à xm : xm = xm.send_objet
-À ce stade, le marchand se trouve à la fin de la négociation.
Étape 5, côté client
-Le client reçoit l’information et interprète le message comme la réception de l’objet commandé sous la forme de l’événement object_received et le rajoute à son historique : Hc = {object_request, low_risk, pay_request, pay_direct, object_received}.
-À ce stade, le client se trouve à la fin de la négociation.
Fin de la négociation
-Le client ne peut plus qu’évaluer la transaction en ajoutant à son historique un des événements positive, neutral ou negative. Son historique actuel :
Hc ={object_request, low_risk, pay_request, object_received, positive}
Le contenu de la session est maintenant une configuration maximale (il n’est plus possible de rajouter d’événements tout en respectant les relations de conflits et de causalités ). Cela marque pour lui la fin de la transaction et de la négociation.
-De la même manière, le marchand n’a plus que la possibilité d’évaluer la transaction.
Après l’ajout de son appréciation, son historique devient une configuration maximale qui marque pour lui aussi la fin de la transaction :
Hm ={object_order, low_risk, ask_payment, payment_received, send_object, positive}
Transaction pour un Smartphone
Le prix d’un Smartphone est élevé par rapport à celui d’un morceau de musique, on imagine facilement que le client et le marchand puissent considérer qu’il s’agisse d’une transaction risquée. Nous sommes dans la situation où le module Risk manager du client lui rend un événement high_risk pour la transaction alors que celui du marchand rend average_risk. Cela va donc avoir une influence sur le déroulement de la négociation.
C’est toujours le client qui débute la négociation. Le processus de négociation passe successivement par les étapes suivantes (client et marchand ) :
Étape 1, côté client
-Une nouvelle sessions xc est ajoutée à Hc. Le client envoie la commande et met à jour son historique : xc = {object_request}.
-En même temps, il évalue le risque et le prend en compte dans l’historique
Étape 2, côté marchand
-De la même manière, une nouvelle session xm est ajoutée à Hm. Quand le marchand reçoit la commande, l’événement object_order est ajouté à l’historique : xm = {object_order}
-Le risque est évalué à cette étape comme average_risk et pris en compte dans xm : xm = xm.average_risk
-A la suite de la commande, le marchand ajoute l’événement ask_payment à son historique et envoie le message correspondant au client. La session courante est : xm = {object_order, average_risk, ask_payment}.
Étape 3, côté client
-Le client reçoit une demande de paiement et met à jour son historique : xc = xc .pay_request. Après analyse de la politique de confiance, les réactions possibles correspondent aux événements : pay_T T P, pay_ignore.
-La stratégie du client sélectionne l’événement pay_T T P et le prend en compte dans la session. Le contenu de la session courante de l’historique du client est : xc = {object_request, high_risk, pay_request, pay_T T P }. Un message est envoyé au tiers de confiance pour confirmer le paiement au marchand.
Étape 4, côté marchand
-Le marchand reçoit un message du tiers de confiance qui l’informe que le client lui a bien confié la somme correspondant au montant de l’achat. Le marchand ajoute à son historique l’événement pay_T T P _notif ied, xm = xm .pay_T T P _notif ied.
La politique du marchand permet maintenant l’envoi de la marchandise, l’événement object_send est ajouté à l’historique. La session courante de l’historique est : xm ={object_order, average_risk, ask_payment, pay_T T P _notif ied, object_send}
Étape 5, côté client
-Le client reçoit la marchandise et ajoute à son historique l’évenement object_received, xc = xc.object_received. Après la vérification de la politique, les candidats possibles sont pay_conf irm et pay_cancel.
-La stratégie de négociation sélectionne le pay_cancel. La session courante est :
Hc ={object_request, high_risk, pay_request, pay_T T P, object_received, pay_cancel}.
Il est possible à cette étape de mettre fin à la négociation.
Étape 6, côté marchand
-Le marchand observe l’événement T T P _time_out, c’est une possibilité de fin de négociation. Celui-ci est pris en compte dans l’historique, xm = xm .T T P _time_out. Pourtant, il n’a pas encore atteint son objectif (T T P _conf irm). Il sollicite une re-négociation.
-Le marchand relance le message de l’étape précédente pour re-négocier et obtenir une autre réaction de la part du client, le message correspondant est construit à partir de l’événement object_send. Ce second envoi de object_send doit être interprété en message du type de négociation (c.f.6.3.4)
Étape 7, côté client
-Le client reçoit une nouvelle fois l’événement object_send. Cela lui indique que le marchand veut re-négocier l’étape 5. Il dispose d’une autre possibilité de réaction : pay_conf irm.
-Si il est honnête, il réagit avec l’événement pay_conf irm. Le message de confirmation de paiement est envoyé au tiers de confiance. La session courante xc de son historique est : xc ={object_request, high_risk, pay_request, pay_T T P, object_received, pay_conf irm}.
Le client, ayant accepté de négocier, supprime le pay_cancel de son historique.
Étape 8, côté marchand
-Le marchand observe l’événement pay_T T P _received qui indique qu’il peut récupérer l’argent auprès du tiers de confiance. Son objectif est atteint.
-La session courante de son historique est :
xm ={object_order, average_risk, ask_payment, pay_T T P _notif ied, object_send, pay_T T P _received}
Il se trouve dans une situation ou il peut mettre fin à la négociation
Fin de négociation
-Le marchand observe le paiement de l’achat et ajoute l’événement pay_T T P _received son historique. Il ne lui reste plus qu’à évaluer la transaction pour clore la session. L’évaluation est saisie interactivement par l’acteur humain du système. En observant tout ce qui s’est passé au long de cette transaction, le vendeur peut mettre une évaluation neutre. L’événement neutral sera ajouté à son historique.
xm ={object_order, average_ris, ask_payment, pay_T T P _notif ied, object_send, pay_T T P _received, neutral}.
-Le client évalue lui aussi la transaction pour terminer la transaction : xc ={object_request, high_risk, pay_request, object_received, pay_conf irm, positive}
6.5.6 Conclusion sur le scénario
Avec la structure d’événements, la politique et la stratégie de négociation de chaque partie impliquée dans la négociation (le client et le vendeur), nous avons montré qu’il était possible d’atteindre les objectifs que nous nous étions fixés :
-la négociation entre les deux parties doit être de confiance (respecter les politiques des parties en présence) pour pouvoir mener la transaction à son terme;
-chaque partie impliquée dans la transaction a son propre objectif dans la négociation : le client paie pour avoir le produit qu’il convoite et le vendeur reçoit le paiement du produit qu’il a livré.
-Le tiers de confiance utilisé pour le paiement dans le scénario est seulement un moyen de traitement. Le processus de négociation et la décision à chaque étape ne concerne que les deux parties engagées dans la transaction. Pour l’instant, nous ne considérons pas les aspects de négociation avec ce tiers de confiance.
6.6 Synthèse
Dans ce chapitre, nous avons présenté notre système de négociation de confiance. Ce système de négociation peut être vu comme un mécanisme engendrant dynamiquement des protocoles respectant les politiques de confiance des participants à une transaction.
En appliquant le modèle de gestion de la confiance présenté dans le chapitre 5, nous avons montré qu’il est possible de synthétiser dynamiquement un protocole de communication qui respecte les politiques exprimées par les paires engagées dans la transaction. Nous avons étudié également le scénario d’une application pratique de la négociation pour présenter les aspects concrets de notre système.
Lire le mémoire complet ==> <(a title=»Infrastructure de gestion de la confiance sur Internet » href=»https://wikimemoires.net/2013/02/infrastructure-de-gestion-de-la-confiance-sur-internet/»>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
