Évaluation

La valeur du risque est évaluée avec la probabilité et le coût/bénéfice de chaque conséquence estimée, en utilisant la formule de la fonction PDF. Considérons deux cas :

(a) L’historique au moment de la transaction est vide. Le résultat trouvé dans ce cas sera :

P

p(oi) ∗ cb(oi) = 10 ∗ 0.8/6 + 110 ∗ 0.8/6 + 5 ∗ 0.8/12 − 100 ∗ 0.8/12 + 0 ∗ 0.8/8+ 0∗0.8/3+ 0∗0.1+ 10∗0.1/3+ 5∗0.1/6− 100∗0.1/6− 100∗0.1/3 = 5.1 (b) L’historique au moment de transaction est celui donné ci-dessous, dans ce

cas le risque est : P

p(oi) ∗ cb(oi) = 10 ∗ 1/7 + 110 ∗ 0 + 5 ∗ 2/7 − 100 ∗ 1/7 + 0 ∗ 1/7 + 0 ∗ 0 + 0 ∗ 0 + 10 ∗ 1/7 + 5 ∗ 0 − 100 ∗ 0 − 100 ∗ 1/7 = −24

7.3.4 Échantillonnage du risque

Nous venons de voir de quelle manière peut être calculée la valeur du risque pris par chacune des parties engagées dans une transaction. Il est nécessaire de ré-échantilloner ces niveaux de risque pour pouvoir les traduire en événements : low_risk, medium_risk, high_risk.

Les seuils pour l’échantillonnage peuvent être calculés après le processus d’appren- tissage par les essais. Le bénéfice est une valeur positive, et le coût porte une valeur négative dans ce cas. Dans le cadre du sénario proposé en exemple, après quelques essais d’apprentissage de chaque côté, le client et le vendeur, les échelles suivantes peuvent être appliquées :

– Pour le client, nous distinguons les niveaux : – ≥ 0 : low_risk – -10 à 0 : average_risk – ≤ -10 : high_risk 0 low_risk high_risk average_risk −10

– Pour le vendeur, nous distinguons les niveaux : – ≥ 0 : low_risk – -15 à 0 average_risk – ≤ -15 : high_risk −15 low_risk high_risk average_risk 0 7.3.5 Discussion

Quand nous identifions le risque de la transaction, nous nous intéressons aux risques importants qui concernent la réussite globale de la transaction, ceux que nous avons

Synthèse 127

abordés ci-dessus. Pourtant, il y a aussi d’autres aspects également liés aux risques que nous ne prenons pas en compte, tels que :

– Pour le client, il y a un risque que la qualité du produit ne soit pas conforme à celle qui était décrite.

– Pour le vendeur, il y a un risque que le paiement du produit livré ait été fait avec un moyen de paiement volé ou falsifié (numéro de carte VISA volé).

– Il y a aussi des risques liés au transport entre les deux parties, tels que par exemple la perte du produit, un retard de livraison. . .

– Les coûts indirects liés à la baisse de réputation d’un client ou d’un vendeur, etc. La prise en compte de ces aspects aurait alourdi l’exemple proposé, mais elle peut s’effectuer si l’on veut obtenir des modèles plus réalistes.

Nous pouvons constater facilement que la valeur du risque évolue après chaque tran- saction. Le fait que l’historique change après chaque transaction implique le changement de la probabilité des conséquences, et le risque évolue donc. C’est aussi un fait indiquant qu’il est nécessaire de réévaluer les probabilités quand on veut lancer une nouvelle tran- saction.

7.4

Synthèse

Nous avons présenté dans ce chapitre notre réalisation de la gestion du risque. Nous avons défini des phases dans la gestion du risque afin de concevoir ce module. Ensuite, un modèle du risque basé sur l’approche quantitive a été intégré à notre système de gestion de la confiance. Enfin, nous avons détaillé notre modèle en analysant le risque pour le scénario d’application d’une transaction du commerce electronique.

Chapitre 8

Prototype de négociation de la

confiance

Dans ce chapitre, nous présentons l’implémentation de notre prototype de biblio- thèque de négociation de la confiance. Il s’agit d’un prototype qui implémente le scénario d’application pour les transactions de e-commerce. Le modèle de la négociation de ce prototype a été présenté au chapitre 6 et se compose de plusieurs éléments : l’historique, la politique de confiance et la vérification de la conformité de cette politique. Nous avons choisi de réaliser ce prototype sous la forme d’un module de négociation de manière à ce qu’il puisse être facilement intégré à différentes applications.

Dans un premier temps, nous allons présenter l’architecture générale du prototype, puis nous présenterons les détails de l’implémentation de chaque module.

Le prototype est implémenté en langage Java. Dans le cadre du développement de ce prototype, nous utilisons certains packages et certaines classes proposés par K. Krukow [58] avec son application JavaHBAC1

.

8.1

Architecture

La négociation entre deux entités est réalisée sous la forme d’un protocole mis en œuvre par le module intégré à chaque l’entité. Le prototype est construit pour implé- menter le scénario de négociation entre les deux entités. Il utilise quelques éléments (classes, une partie du schéma XML) issus de l’application JavaHBAC [58].

Le prototype est implémenté en Java. Chaque partie participant à la négociation, le client ou le vendeur, est représentée par une application. La communication entre deux parties (les deux applications) est assurée par le protocole de négociation. L’archi- tecture commune à chaque application est présentée figure 8.1. Elle est constituée des composants suivants :

– Policy : la spécification de la politique de chaque participant est stockée sous la forme d’un fichier XML. Ce formalisme nous permet de représenter et de mani- puler efficacement les politiques de confiance (PP-LTL). Ce fichier de politique est chargé et traduit dans la représentation interne au programme à l’aide d’un analyseur syntaxique XML standard lors de l’initialisation du module.

– Negociation Agent : ce module gère la stratégie de l’acteur associé à l’application. Il s’agit de classes Java qui sont en relation avec les composants suivants : History,

1

l’application JavaHBAC est un démonstrateur de son système de réputation qui permet de contrôler les droits d’accès à des fichiers disponibles sur une machine.

Agent

Negotiation

Interface + Protocole

Policy

History

en XML

Policy

Verification

Risk Manager

Fig. 8.1 – Architecture de l’application

Risk Manager, Interface & Protocole et Policy Verification.

– Risk Manager : ce module réalise les calculs de risque conncernant la transaction en cours.

– Policy verification : ce module est chargé de vérifier en permanence que la politique de confiance est satisfaite (vérification de la satisfiabilité d’une formule logique PP-LTL sur d’un historique donné). Il doit pouvoir accéder à l’historique et à la politique de l’acteur.

– Interface & Protocole : ce composant assure deux fonctions — l’échange d’informa- tions entre les deux parties et l’interface interactive avec l’application. L’interface permet à l’utilisateur d’interagir avec le module lorsque lui seul est à même de prendre une décision, et elle permet aussi d’afficher des informations ou des ex- plications sur la transaction en cours. Les messages échangés par les deux parties sont pré-définis et constituent le protocole de communication.

La description de l’architecture de l’application nous a donné une vue globale du prototype. Le développement de ces composants et leur fonctionnement est détaillé dans les sections suivantes.