Module de négociation de la confiance

6.4 Module de négociation de la confiance

Dans cette section, nous présentons le modèle de notre mécanisme de négociation. Il se compose de deux parties distinctes : la gestion de la confiance et la gestion de la négociation.

La gestion de la confiance ayant été présentée en détail dans le chapitre 5, nous expliquons comment nous modélisons les activités de chaque entité à l’aide d’une structure d’événements, comment nous définissons leur politique et nous proposons une stratégie pour mener à bien les négociations.

6.4.1 Structure d’événements

Comme nous l’avons présenté au chapitre 5, nous utilisons une structure d’événements et une politique pour modéliser le comportement des différentes entités du système.

Aucun des participants ne connait la politique de l’autre; une politique de confiance est quelque chose de personnel, on ne la partage pas, pour éviter que son correspondant n’en tire un profit concurrentiel par exemple (si mon correspondant connait le montant maximum que je suis prêt à dépenser pour acquérir un bien, c’est cette somme qu’il me réclamera même si elle est supérieure au montant qu’il comptait me demander).

Chaque entité doit définir sa propre structure d’événements. Un soin particulier doit être pris lors de la définition des relations de conflit et de causalité. Ces relations sont à la base du comportement de l’entité et doivent lui permettre des interactions riches avec ses correspondants.

On distingue deux types d’événements dans la structure d’événements :

• les événements qui spécifient des comportements (ou des actions); par exemple la commande de marchandise ou le payement d’un bien;
• les événements qui ne portent que de l’information concernant la transaction ou l’entité engagée dans la transaction; par exemple les événements qui représentent le risque ou la satisfaction.

Ces événements sont importants pour définir la politique de chaque entité. Étant pris en compte dans l’historique des transactions, ils sont utilisés lors de la vérification de la politique à chaque étape de la transaction.

Le choix de la structure d’événements est très important parce que cela a un impact direct sur l’arbre des transitions, et donc la façon dont les négociations seront menées. Le nombre d’événements a aussi son importance; s’ils sont trop nombreux la rédaction des politiques est rendue difficile, et dans le cas contraire, les politiques risquent de ne pas être suffisament riches. Nous fournissons une analyse de ces différents aspect dans les sections concernées.

Poids relatif à la causalité

Pour spécifier notre processus de négociation, nous avons besoin de définir la notion de poids relatif à la causalité d’un événement

Le poids P (e) de la causalité d’un événement e est la plus longue chaîne de conséquences possibles avec une structure d’événements donnée si on déclenche e.

Par exemple, si le déclenchement de l’événement e n’a pas de conséquence possible, son poids P (e) est égal à 0; par contre si e ≤ e1, et e1 ≤ e2 nous avons P (e) = 2 (≤ est la relation de causalité entre deux événements ).

6.4.2 Objectif de négociation

Comme nous l’avons vu dans la section 6.2, chaque entité a son objectif personnel pour la négociation. C’est un but que l’entité veut atteindre en engageant la négociation avec l’autre entité. Du point de vue du concepteur du système dans notre contexte d’application, nous pouvons le reconnaître facilement : c’est un fait ou une observation indiquant que l’entité dispose de ce qu’elle attend.

Par exemple, dans le scénario de la transaction de vente-achat en ligne, l’objectif du client est de recevoir le produit envoyé par le vendeur selon sa commande, celui du vendeur est de recevoir un paiement valide du client.

En modélisant le système avec comme modèle une structure appropriée, l’objectif est marqué dans la structure du modèle. Dans l’implémentation du système, l’objectif est codé dans la structure du programme. La section suivante explique comment l’objectif est modélisé dans cette structure.

Définition : objectif

Dans la structure d’événements proposée pour l’entité en modélisant le système, l’objectif est un événement que l’entité veut pouvoir observer.

La structure d’événements traduit tous les faits ou observations des comportements de l’entité sous la forme d’événements. L’objectif se trouve donc dans cet ensemble d’événements. Pour le trouver dans la structure d’événements, l’événement « objectif » est marqué. Selon la modélisation du système en structure d’événements, il existe un ou plusieurs objectifs dans la structure. Dans la conception, les objectifs de l’entité sont précisés en modélisant le système.

Nous pouvons indiquer les objectifs de chaque entité en définissant leurs structures d’événements. Considérons le scénario de la transaction de vente-achat en ligne : l’objectif du client est de recevoir le produit commandé et ce fait est concrétisé avec l’événement object_received de la structure d’événements du client, donné dans la section 6.5; de même, l’objectif du vendeur est concrétisé par les événements payment_received et payment_TTP_received dans sa structure d’événements.

Définition : chemin d’ob jectif

Le chemin d’objectif est une configuration possible qui contient un objectif.

Il peut y avoir plusieurs chemins d’objectif à partir des conséquences possibles d’une action.

Si à une étape de la négociation on observe l’événement ep , on peut déterminer que l’événement es (qui est une conséquence de ep ) permet de contruire un chemin d’objectif en utilisant la procédure, illustrée par l’algorithme 1

6.4.3 Politique de confiance

Une politique de confiance est contruite en utilisant les événements décrits dans la structure d’événements, les évenements informatifs produits par les différents modules spécialisés et l’historique des transactions. La politique permet de spécifier les conséquences que l’on considère comme risquées et que l’on souhaite éviter. L’utilisation de l’historique permet de tenir compte de sa propre expérience et de modifier son comportement en conséquence.

Supposons que nous voulions que la séquence d’événements eai et ebj (avec eai ≤ ebj ) ne survienne jamais si nous observons l’événement er , il est possible de le spécifier par la politique suivante :

ψ ≡ G−1[er =⇒ ¬(eai ∨ ebj )]

La politique peut se réduire à l’expression de contraintes entre les événements dans la structure d’événements. La négociation peut être interprétée comme le processus de construction itératif d’une session, qui pour être correcte doit respecter les contraintes

Algorithme 1: Chemin d’objectif

imposées par la structure d’événements. Cette dernière permet de contrôler le comportement des parties pour la session courante. La sous-politique est dans ce cas une formule sans quantificateur temporel et la vérification est réalisée uniquement en tenant compte de la session courante de l’historique.

Considérons l’exemple suivant : à un instant donné, l’entité A observe l’événement ebi et elle veut que, si elle réagit en utilisant l’événement eai, cela impose le déclenchement de l’action correspondant à eai+1. Il est possible de spécifier cette contrainte avec la politique suivante :

ψ ≡ (ebi ∧ eai) =⇒ eai+1

Si l’on a défini un ensemble de sous-politiques différentes ψ1, . . . , ψn , qui prennent en compte différentes conséquences considérées comme risquées, la politque globale est une disjonction de cet ensemble de sous-politiques :

ψglobal ≡ ψ1 ∧ . . . ∧ ψn

La négociation est un processus d’échange. Chaque étape va consister à réagir à une action ou un ensemble d’actions successives de son partenaire. Lorsque l’on a observé un événement ou un ensemble d’événements successifs (qui représente le comportement de son partenaire), on recherche quels sont les événements appropriés de notre comportement qui permettent de poursuivre la négociation. Dans cette section, nous spécifions d’abord ce qu’est une étape de la négociation, puis nous proposons un pseudo-code pour cette opération.

6.4.4.1 Spécification

Supposons que l’entité A soit à une étape de négociation où elle vient d’observer l’événement eb′i pour la session xn avec son partenaire B, étape illustrée par la figure 6.5. A peut réagir à cette action avec les événéments eaj ou eaj +1 qui respectent sa politique. Cela veut dire que : HA .{. . . eb′i , eaj . . .} |= ψA et HA.{. . . eb′i, eaj +1 . . .} |= ψA

Fig. 6.5 Étape de négociation

Supposons que à cette étape, la stratégie de négociation de A conseille l’utilisation de eaj , il est ajouté à la session xn de l’historique :

HA = x1 . . . xn−1.{. . . eb′i.eaj }

Quand B observe l’action ea′j (interprétation du message qu’il vient de recevoir), il peut réagir en envoyant à A un message construit à partir d’un des événements sélectionnés comme candidats potentiels EC = (ebk , ebk+1 . . . ebk+n ). Supposons que le

gestionnaire de stratégie de B lui propose d’utiliser ebc (ebc ∈ EC ), mais que :

• ebc ne lui permette pas d’atteindre son objectif;
• ebc soit un événement qui corresponde à une action qui termine la négociation avant que le but de la négociation ne soit atteint.

Dans ce cas, B veut re-négocier avec A pour qu’il réagisse d’une manière différente.

B va se comporter de la manière suivante :

• B ne prend pas en compte ea′j dans son historique,
• B recherche dans la session courante le dernier événement qu’il a pris en compte, noté ebi , qui correspond à la réponse qu’il a faite à A lors de l’étape précédente.
• B envoie de nouveau à A un message correspondant à l’événement ebi.

A observe de nouveau l’événement eb′i (interprétation que A fait du message envoyé

par B et correspondant à ebi). Il détecte qu’il y a un problème, l’événement eb′i étant déjà présent dans la session xn . A comprend que la réaction qu’il a eue à cette action n’est pas compatible avec la politique ou les objectifs de B (c’est la manière dont il faut interpréter la situation). A doit donc ré-évaluer la situation. Si A ne dispose pas d’un nouveau candidat, c’est qu’il avait réagi de la seule manière qui lui était possible à l’étape précédente; il est alors obligé de mettre fin à la transaction. Sinon, A réalise les opérations suivantes :

• A supprime de la session xn l’événement qui vient de déclencher cette réaction; il s’agit de eaj dans ce cas.
• A choisit un autre événement dans l’ensemble des candidats : eaj +1 par exemple.
• A reprend la négociation en envoyant à B un message correspondant à l’événement eaj +1.

6.4.4.2 Pseudo-code d’une étape de négociation

Le pseudo-code suivant présente la procédure de négociation que nous venons de décrire lorsque l’on observe le comportement présenté dans l’algorithme 2

6.4.4.3 Négociation et messages envoyés plusieurs fois

Nous avons vu que que lors de l’étape de re-négociation, un événement est re-proposé au partenaire pour solliciter une autre réponse de sa part. Comme nous l’avons présenté dans la section 6.3, lors d’une re-négociation, le message porte le type négociation, son contenu est donc facilement différenciable d’un message de type proposition par l’Event Analyzer.

6.4.5 Procédure d’envoi et d’observation des événements

Pour simplifier la spécification des échanges, nous proposons deux procédures qui permettent de manipuler les événements : envoyer ou observer des événements. Ces procédures sont partie intégrante de l’Event-Analyzer et sont chargées d’assurer l’interface entre messages et événements.

Envoyer(e) : cette procédure permet d’envoyer à son partenaire un message me correspondant à un événement e. Lors de l’appel de la procédure, l’Event Analyzer interprète l’événement e et le met sous la forme d’un message me; le message est envoyé à l’autre partie.

e=Observer() : cette fonction rend un événement qui correspond à un message observé lors du processus d’échange. Lorsque l’entité reçoit le message me , l’Event Analyzer l’interprète sous la forme d’un événement e, cet événement est fourni au module de négociation pour les traitements nécessaires par la suite.

6.4.6 Processus d’échange

Nous présentons le processus d’échange complet lorsque deux parties utilisent leur structure d’événements pour la négociation. Les données échangées sont des messages comme nous venons de l’expliquer dans la section Protocole de négociation.

Supposons que deux entités A et B veuillent réaliser une transaction. A est à l’initiative de la négociation. Elles disposent chacune de leurs historiques respectifs HA et HB et de leurs politiques ψA et ψB . Le processus d’échange est réalisé en plusieurs étapes et le processus de négociation est le suivant :

Algorithme 2: Procédure d’une étape de négociation.

Spécification des étapes

1.  Avant de commencer le processus de négociation, A et B ajoutent une nouvelle session à leur historique respectif : HA = HA ∪ xa et HB = HB ∪ xb.
2.  A débute l’échange par une proposition, l’événement correspondant est ea1 . Cet événement est ajouté à xa : xa = xa.ea1. Un message est envoyé à B pour l’informer (appel de la procédure : Envoyer(ea1 )).
3.  B reçoit le message envoyé par A et l’interrogation de la fonction Observer() rend à cette étape l’événement ea′1. Cet événement est ajouté à xb . B utilise sa procédure
   de négociation pour déterminer quelle réaction avoir (eb1 = N egotiationEtape(ea′ 1, ψB )). Si cet événement indique la fin de la transaction, le protocole d’échange se termine pour B sinon, B informe A de sa décision (appel la procédure Envoyer(eb1).
4.  À l’étape i, A observe un nouvel événement : eb′i = Observer(); il utilise sa procédure N egotiacionEtape(eb′ i, ψA ) pour déterminer la réaction appropriée. Ce processus continue jusqu’a ce que les deux parties atteignent la fin du processus de négociation.

En appliquant cet algorithme, nous trouverons que la fin de négociation est atteinte lorsque la session courante est une configuration maximale. Nous pouvons vérifier que l’objectif de la négociation est atteint en vérifiant la présence d’un événement d’objectif dans la session.

Pseudo-code

Voici le processus complet de négociation de l’entité A en négociation avec son partenaire B.

Procédure ProcessNégociation(ψA , HA , debut : booleen)

// debut : précise si A débute la négociation

EC : événements candidats

xa : session créée pour cette transaction

HA = HA ∪ xa

si debut = true alors

xa ← ea1 // débuter

Envoyer(ea1) //événement débutant la négociation

fin

tant que F I N = F alse faire eb′i=Observe() N egotiacionEtape(eb′ i, ψA )

fin end

Algorithme 3: Procédure de négociation

6.4.7 Stratégie de négociation

Cette section explique comment une entité peut mettre en œuvre sa stratégie à chaque étape de négociation. La stratégie de négociation est une méthode qui doit permettre de sélectionner le meilleur événement parmi les événements candidats à l’étape suivante. Afin de rendre palpable cette notion de stratégie, nous proposons au lecteur un exemple d’algorithme.

Nous avons vu que l’ensemble des événements candidats EC est composé d’événements ess qui satisfont les contraintes suivantes :

• ils respectent les relations de causalité et de conflit avec les événements de xn (xn est la session courante);
• la politique continue à être satisfaite.

L’acteur peut décider de programmer la stratégie suivante dans son module Strategy Negotiation. Nous distinguons deux cas : l’acteur a atteint son objectif ou ne l’a pas encore atteint (un événement objectif est présent ou non dans la session courante).

1. L’acteur n’a pas encore atteint son objectif :

-Sauf si c’est impossible, l’acteur évite de sélectionner un événement qui l’amène à mettre fin à la négociation.

-L’entité veut atteindre son objectif le plus tôt possible. S’il existe une relation causale (directe ou indirecte) entre un événement ej et un événement d’objectif eob , elle choisit l’événement dont la longueur du chemin d’objectif est le plus court.

-L’entité peut également choisir le ej dont le poids relatif à la causalité est le plus faible. En choisissant cet événement, l’entité a une chance d’atteindre plus rapidement une configuration maximale

2. L’acteur a atteint son objectif et son partenaire ne l’a pas encore atteint. Si l’acteur est honnête, il doit éviter de sélectionner un événement qui mène à la fin de la négociation s’il existe d’autres possibilités. Terminer la négociation empêche toute re-négociation de la part de son partenaire. Par contre, il peut choisir un ej de poids minimal pour terminer au plus tôt la négociation. Dans ce cas, il envoie une proposition à son partenaire pour lui permettre d’être à l’initiative de la fin de la transaction.

Nous pouvons écrire cet algorithme dans le cas où l’entité veut terminer au plus tôt la négociation :

Fonction StratégieNégociation(EC , ep ): événement

// EC : ensemble non vide des événements candidats après avoir observé ep

pour ecj ∈ EC faire

// Calculer le poids de causalité des candidats

P(ecj ) ← poids-causalite (ecj )

fin

si |EC | > 1 alors

// l’événement e donne la FIN si il complète la configuration maximale

Choisir e ∈ EC tel que (e ne donne pas la F I N ) et P (e) plus petit

retourner e

sinon

retourner e unique de EC

fin

end

Algorithme 4: Procédure de la stratégie

Hasard

La stratégie qui consisterait à choisir au “hasard“ l’événement de l’ensemble Ec à utiliser pour l’étape suivante de la négociation est aussi tout à fait utilisable. Cette stratégie a des propriétés intéressantes, comme celle de ne privilégier aucune direction de négociation particulière, mais va aussi rendre difficilement prévisible le comportement d’un pair, ce qui peut être considéré comme un atout dans certaines situations sensibles (si le fait de pouvoir prédire le comportement de son correspondant vous offre un avantage stratégique ou concurrentiel).

6.4.8 Discussion sur le modèle

Les messages échangés par les deux acteurs peuvent contenir des données sensibles qui doivent être protégées. Nous ne traiterons pas ce problème dans le cadre de cette thèse, les protocoles de sécurité traditionnels utilisant des schémas cryptographiques pouvant être utilisés à cette fin.

Une solution pratique, simple et éprouvée que l’on peut mettre en œuvre est de chiffrer l’ensemble des communications en utilisant un protocole construit au dessus de SSL. Nous n’avons besoin que d’assurer la confidentialité des échanges, les aspects liés à l’authentification des correspondants n’ayant pas d’objet dans notre cas : nous sommes en train de tenter d’établir une relation de confiance avec quelqu’un que nous ne connaissons pas.

Nous avons proposé à titre d’exemples des stratégies de négociation qui peuvent s’appliquer dans un contexte général. Dans le cadre d’applications spécifiques, il est toujours possible de proposer d’autres stratégies qui correspondraient mieux aux objectifs des participants, et qui permettraient d’avoir des négociations plus efficaces.

Dans cette modélisation, nous avons considéré la phase de re-négociation de l’entité pour une seule étape de retour en arrière. Il est possible de modéliser cette re-négociation pour pouvoir revenir sur plusieurs étapes précédentes. Cela dépend de la politique proposée par chaque partie.