THÈSE - univ-oran1.dz

T H È S EEn vue de l’obtention du diplôme de

Doctorat LMD

Spécialité : Informatique De La Répartition et Aide à laDécision (IRAD)

Présentée par : Mounya ABDELHADI

Élaboration d’un modèle de négociationpar les web services dans un systèmed’aide multicritères à la décision de

groupe

M.Mohammed Fayçal KHELFI Pr, Université Oran1 Ahmed BENBELLA PrésidentM.Mustapha Kamel ABDI MCA, Université Oran1 Ahmed BENBELLA ExaminateurM.Larbi SEKHRI Pr, Université Oran1 Ahmed BENBELLA ExaminateurM.Abdelmalek AMINE Pr, Université Tahar Moulay Saida ExaminateurM. Mohammed BENYETTOU Pr, Université USTO Mohamed Boudiaf ExaminateurMme. Djamila HAMDADOU Pr, Université Oran1 Ahmed BENBELLA Directrice de Thèse

Soutenue publiquement devant le jury composé de :04/03/2019

I

Résumé

Dans un système d’aide à la décision de groupe, les différents décideurs disposentde leurs propres informations, contraintes, stratégies de décision, préférences et ob-jectifs qui ne sont généralement pas partagés ou communiqués. Cela implique que leprocessus de décision du groupe est réparti entre les différentes entités impliquées etimpactées par les caractéristiques des différents membres du groupe. La solution àce problème est de trouver une décision qui serait acceptable pour tous les décideursselon leurs préférences, suite à la nécessité d’un processus de négociation qui per-met l’élaboration d’un accord commun pour un groupe confronté à un conflit sur ladécision à prendre. Dans la présente thèse, nous proposons d’établir une plateformede communication pour un système d’aide à la décision de groupe (GDSS) utilisantles services Web, et intégrant un protocole de négociation basé sur la médiation etl’analyse multicritères.

noindent Mots clés Aide à la décision, Système d’aide à la décision de groupe(GDSS), Analyse multicritères, Protocole de négociation, PROMETHEE II, les ser-vices web, les systèmes multi agents.

II

Abstract

In a group decision support system, the various decision-makers have their owninformation, constrains, decision strategies, preferences, and objectives which are ge-nerally not shared or communicated. This implies that the group decision process isdistributed between the different entities implicated and impacted by various groupmembers’ characteristics. Solution to this problem is to find a decision that would beacceptable to all the decision-makers, following the necessity of a negotiation processthat allows the elaboration of a common agreement for a group that faces a conflicton the decision to take. In the current study, we propose to establish a communi-cation platform for a group decision support system (GDSS) using on web services,incorporating a negotiation protocol based mediation and multicriteria analysis.

Key-words Decision Support, Group Decision Support System (GDSS), Multicri-teria Analysis, Negotiation Protocol, PROMETHEe II, Web Services, Multi agentssystem.

III

IV

« Étudiez comme si vous deviez vivre toujours,Vivez comme si vous deviez mourir demain »

Saint Isidore

V

Remerciements

En tout premier lieu je remercie DIEU le tout puissant de m’avoir donné la force pour avanceret le courage pour avoir accompli ce modeste travail.

Mes vifs remerciements s’adressent en premier lieu à ma directrice de thèse madame DjamilaHAMDADOU, Professeur à l’université Oran1 Ahmed BENBELLA, une femme remarquable pourm’avoir proposé ce sujet, dirigé mes travaux, pour sa gentillesse, sa disponibilité, ses conseils, sonaide précieuse, sa patience sans limite, et pour avoir cru en moi.

Mon profond respect et mes remerciements vont à Monsieur Mohamed Fayçal KHELFI, Pro-fesseur à l’université Oran1 Ahmed BENBELLA, pour l’immense honneur qu’il me fait de présiderce jury.

Mes vifs remerciements s’adressent, également, à Monsieur Larbi SEKHRI, professeur à l’uni-versité Oran1 AHMED BENBELLA, et ma reconnaissance envers la précieuse formation qu’il nousa donnée durant notre cursus. Je tiens à remercier, chaleureusement, Monsieur Mustapha KamelABDI, Maitre de Conférences « A » à l’université Oran1 Ahmed BENBELLA, qui malheureuse-ment je n’ai pas eu la chance d’avoir comme enseignant durant mes années d’étude.J’adresse mes sincères remerciements à Monsieur Mohamed BENYETTOU, Professeur à l’USTOMohamed Boudiaf, et Monsieur Abdelmalek AMINE, Professeur à l’université Dr Tahar MoulaySaida, pour avoir accepté d’examiner et de juger mon travail de thèse.

A mes parents et mes beaux-parents qui m’ont toujours soutenu, sans leur encouragement jen’aurai jamais pu continuer.

Une tendre et particulière pensée va à mon mari que je remercie infiniment qui a tout fait pourme voir réussir. A mes enfants qui sont ma raison d’être, pour qui j’espère être une grande fierté.

Je remercie ma famille particulièrement ma sœur et mes belles sœurs, mes amis en particulierAmina BELLAHCENE une femme admirable qui a énormément contribué à ma réussite, je remer-cie tous ceux qui de près ou de loin m’ont soutenue et m’ont encouragée à poursuivre mon rêvejusqu’au bout. . .

Mounya ABDELHADI

Table des matières

Liste des figures X

Liste des tableaux XII

Liste des abréviations XIII

Introduction Générale 1

I Synthèse de l’état de l’art 7

1 L’aide à la décision de groupe 81.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2 L’Aide à la Décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2.1 La décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.2 Les niveaux de la décision . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.3 La typologie de la décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.4 Les acteurs de l’aide à la décision . . . . . . . . . . . . . . . . . . . . . . . . 101.2.5 Le processus décisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3 Les Systèmes d’Aide à la Décision (SAD) . . . . . . . . . . . . . . . . . . . . . . . 121.3.1 La taxinomie des SAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4 l’aide à la décision de groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4.2 Le processus de prise de décision . . . . . . . . . . . . . . . . . . . . . . . . 141.4.3 Les principaux acteurs de la décision de groupe . . . . . . . . . . . . . . . 15

1.5 Les systèmes d’aide à la décision de groupe (SADG) . . . . . . . . . . . . . . . . . 151.5.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.5.2 La structure d’un SADG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5.3 L’architecture générale d’un processus de décision de groupe . . . . . . . . 161.5.4 Les intérêts des GDSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.5.5 La typologie des GDSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.6 L’aide à la décision multicritères . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.6.1 Définition de l’aide à la décision multicritères . . . . . . . . . . . . . . . . . 201.6.2 Vocables associés à l’analyse multicritères . . . . . . . . . . . . . . . . . . . 201.6.3 Démarche générale d’une méthode Multicritères . . . . . . . . . . . . . . . 221.6.4 Classification des différentes méthodes d’Analyse Multicritères . . . . . . . 23

1.7 Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

TABLE DES MATIÈRES VII

2 La négociation dans les Systèmes Multi Agents 272.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2 Les agents et les systèmes multi agents . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.1 Définition d’agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2.2 Typologie des agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2.3 Les systèmes multi agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.3 La coopération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.4 La résolution de conflits n’incluant pas la négociation . . . . . . . . . . . . . . . . 30

2.4.1 Take it or leave it offer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.4.2 One Step Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.4.3 Les enchères sans négociation . . . . . . . . . . . . . . . . . . . . . . . . . . 312.4.4 Les systèmes de vote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.4.5 La délibération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.5 La résolution de conflit incluant la négociation . . . . . . . . . . . . . . . . . . . . 332.5.1 La négociation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.6 Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 Les services web 433.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2 L’architecture orientée service SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.3 Historique sur les services web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.4 Les acteurs SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.5 Définition du service web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.5.1 Définition du ‘W3C’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.5.2 Définition de ‘Dico du net’ . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.5.3 Définition ‘Wikipédia’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.6 Motivation et intérêt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.7 Organisation des services web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.8 L’architecture d’un service web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.9 L’architecture étendue des services web SOAP/WSDL/UDDI . . . . . . . . . . . . 50

3.9.1 Le protocole de communication SOAP . . . . . . . . . . . . . . . . . . . . . 503.9.2 Le langage XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.9.3 Le langage de description WSDL . . . . . . . . . . . . . . . . . . . . . . . . 513.9.4 L’annuaire des services UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . 523.9.5 Les Avantages de l’architecture étendue . . . . . . . . . . . . . . . . . . . . 533.9.6 Les inconvénients de l’architecture étendue . . . . . . . . . . . . . . . . . . 53

3.10 L’architecture REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.10.1 URI et Ressource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.10.2 Les méthodes HTTP (GET, POST, PUT,etc.) . . . . . . . . . . . . . . . . 543.10.3 Les avantages de l’architecture REST . . . . . . . . . . . . . . . . . . . . . 543.10.4 Les inconvénients de l’architecture REST . . . . . . . . . . . . . . . . . . . 55

3.11 Systèmes utilisant les services web . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.12 L’aide à la décision et les services web . . . . . . . . . . . . . . . . . . . . . . . . . 573.13 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

TABLE DES MATIÈRES VIII

II Contributions 59

4 Modélisation de l’approche proposée 604.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.2 Objectifs visés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.3 Modèle décisionnel proposé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.4 Description du système d’aide à la décision de groupe proposé . . . . . . . . . . . . 66

4.4.1 Modèle SMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.4.2 Identification des acteurs concernés . . . . . . . . . . . . . . . . . . . . . . . 674.4.3 Description de la plateforme de communication proposée . . . . . . . . . . 68

4.5 la démarche décisionnelle adopté par le système d’aide à la décision . . . . . . . . . 894.6 Description des services web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.7 La Synchronisation des échanges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5 Expérimentation et résultats obtenus 1005.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.2 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.2.1 GWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.2.2 Tomcat 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.2.3 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.2.4 Jade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.3 Espaces d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.3.1 Espace administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.3.2 Espace utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

5.4 Scénario illustratif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.4.1 Délimitation de la région d’étude . . . . . . . . . . . . . . . . . . . . . . . . 1095.4.2 Identification des critères d’adéquation du territoire pour l’habitat . . . . . 1095.4.3 Identification des différents décideurs impliqués . . . . . . . . . . . . . . . . 1115.4.4 Description du processus décisionnel . . . . . . . . . . . . . . . . . . . . . . 112

5.5 Interprétation des échanges de messages par les agents . . . . . . . . . . . . . . . . 1175.5.1 Phase d’initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195.5.2 Phase de d’évaluation et de proposition . . . . . . . . . . . . . . . . . . . . 1205.5.3 Phase de décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Conclusion Générale et Perspectives 122

III Annexes 126

A Les méthodes d’analyse multicritères 127A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127A.2 Les méthodes d’aide multicritères à la décision . . . . . . . . . . . . . . . . . . . . 127

A.2.1 Avantages des méthodes multicritères . . . . . . . . . . . . . . . . . . . . . 127A.2.2 Le but des méthodes d’analyse multicritères . . . . . . . . . . . . . . . . . . 128A.2.3 Les différentes problématiques en Aide Multicritères à la Décision . . . . . 128

A.3 Classification des méthodes multicritères . . . . . . . . . . . . . . . . . . . . . . . . 129A.3.1 Les méthodes d’agrégation . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

A.4 La famille ELECTRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

TABLE DES MATIÈRES IX

A.4.1 La méthode ELECTRE I . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131A.4.2 La méthode ELECTRE II . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131A.4.3 La méthode ELECTRE III . . . . . . . . . . . . . . . . . . . . . . . . . . . 131A.4.4 La méthode ELECTRE IV . . . . . . . . . . . . . . . . . . . . . . . . . . . 131A.4.5 La méthode ELECTRE IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 132A.4.6 La méthode ELECTRE Tri . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

A.5 La famille PROMETHEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132A.5.1 Le principe de la méthode PROMETHEE : . . . . . . . . . . . . . . . . . . 132A.5.2 Le principe de la méthode PROMETHEE . . . . . . . . . . . . . . . . . . . 133A.5.3 La méthode PROMETHEE I : rangement partiel . . . . . . . . . . . . . . 133A.5.4 La méthode PROMETHEE II : rangement complet . . . . . . . . . . . . . 133A.5.5 PROMETHEE III, alpha : Amplification de la relation d’indifférence . . . 133A.5.6 PROMETHEE VI : Problèmes aisés ou difficiles . . . . . . . . . . . . . . . 133A.5.7 PROMETHEE V : Problèmes multicritères avec contraintes additionnelles . 133

A.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

B Les Systèmes Multi Agents 135B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135B.2 Acteur et agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135B.3 Définition des Systèmes Multi agents . . . . . . . . . . . . . . . . . . . . . . . . . . 135B.4 Architecture des systèmes multi agents . . . . . . . . . . . . . . . . . . . . . . . . . 136B.5 Caractéristiques d’un SMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137B.6 Types d’agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

B.6.1 Catégories ou modèles d’agents . . . . . . . . . . . . . . . . . . . . . . . . . 137B.7 Les plateformes SMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138B.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Bibliographie 140

Bibliographie 140

Webographie 148

Liste des figures

1.1 Processus de décision de Simon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Taxinomie des SAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3 Architecture générale d’un processus de décision de groupe . . . . . . . . . . . . . 17

2.1 Les différents éléments d’une négociation et leurs structures . . . . . . . . . . . . . 342.2 Taxinomie des processus de résolution de conflit . . . . . . . . . . . . . . . . . . . . 35

3.1 Acteurs et rôles dans l’architecture Orientée Service . . . . . . . . . . . . . . . . . 453.2 Architecture en couche des services web . . . . . . . . . . . . . . . . . . . . . . . . 483.3 Cycle de vie des services web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4 Structure d’un document WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.5 Cas d’utilisation des Méthode HTTP sur une ressource . . . . . . . . . . . . . . . 54

4.1 Phases et étapes du modèle décisionnel proposé dans [52] . . . . . . . . . . . . . . 644.2 Le modèle décisionnel proposé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.3 Identification des rôles dans la plateforme . . . . . . . . . . . . . . . . . . . . . . . 674.4 Diagramme montrant la navigation dans les espaces de travail selon le rôle . . . . 674.5 La plateforme de communication proposée : vue d’ensemble . . . . . . . . . . . . . 684.6 Les acteurs et les modules dans la plateforme . . . . . . . . . . . . . . . . . . . . . 694.7 Diagramme de cas d’utilisation : Gestion comptes utilisateurs . . . . . . . . . . . . 704.8 Diagramme de cas d’utilisation : Gestion des sessions . . . . . . . . . . . . . . . . 714.9 Diagramme de cas d’utilisation : messagerie . . . . . . . . . . . . . . . . . . . . . . 724.10 Diagramme de cas d’utilisation : Partage de documents . . . . . . . . . . . . . . . 734.11 Diagramme de cas d’utilisation : Système de formulaires . . . . . . . . . . . . . . 744.12 Fonction de préférence linéaire [55] . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.13 Fonction de préférence en V [55] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.14 Démarche d’utilisation de PROMETHEE II . . . . . . . . . . . . . . . . . . . . . 784.15 Diagramme d’état transition : Analyse multicritères par PROMETHEE II . . . . 794.16 Formulaire choix simple : option A gagnante . . . . . . . . . . . . . . . . . . . . . 804.17 Formulaire choix multiple : option B gagnante . . . . . . . . . . . . . . . . . . . . . 814.18 Etapes du protocole de négociation . . . . . . . . . . . . . . . . . . . . . . . . . . 864.19 Diagramme de séquences du protocole de Négociation proposé . . . . . . . . . . . 894.20 La démarche décisionnelle adoptée par le système d’aide à la décision de groupe . 904.21 Comparaison taille message JSON – XML . . . . . . . . . . . . . . . . . . . . . . 914.22 Diagramme de classes : perspective = utilisateur . . . . . . . . . . . . . . . . . . . 924.23 Diagramme de classes : perspective = Session . . . . . . . . . . . . . . . . . . . . . 934.24 Diagramme de classes : perspective = message . . . . . . . . . . . . . . . . . . . . 934.25 Diagramme de classes : perspective = formulaire . . . . . . . . . . . . . . . . . . . 954.26 Diagramme de classes : Analyse multicritères . . . . . . . . . . . . . . . . . . . . . 97

LISTE DES FIGURES XI

5.1 Echange client web/ Serveur web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.2 Architecture de la plateforme JADE . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.3 Agent RMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.4 Agent Dummy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.5 Agent Sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.6 Authentification par compte administrateur . . . . . . . . . . . . . . . . . . . . . . 1045.7 Espace administrateur – consultation des comptes utilisateurs . . . . . . . . . . . 1055.8 Espace administrateur – création d’un utilisateur . . . . . . . . . . . . . . . . . . 1055.9 Authentification avec un compte non administrateur . . . . . . . . . . . . . . . . . 1065.10 Espace utilisateur – liste des sessions . . . . . . . . . . . . . . . . . . . . . . . . . 1065.11 Espace utilisateur – Création d’une session et inscription des participants avec at-

tribution des poids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.12 Espace utilisateur : création d’une session . . . . . . . . . . . . . . . . . . . . . . . 1075.13 Espace initiateur : sommaire des réponses de formulaires . . . . . . . . . . . . . . 1085.14 Espace décideur choix des critères . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.15 Zone d’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.16 Formulaire sur la compréhension du problème créé grâce au générateur . . . . . . 1135.17 Formulaire - Résumé des réponses . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135.18 Formulaire – critères à retenir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145.19 Formulaire critères à retenir : résumé avec poids des décideurs . . . . . . . . . . . 1145.20 Formulaire critères à retenir : résumé sans poids des décideurs . . . . . . . . . . . 1145.21 Espace décideur – Matrice de performances . . . . . . . . . . . . . . . . . . . . . . 1155.22 Espace décideur – introduction des paramètres subjectifs de tous les décideurs . . 1155.23 Espace décideur Résultat de la méthode Prométhée II Classement des terrains . . 1165.24 Paramétrage du protocole de négociation . . . . . . . . . . . . . . . . . . . . . . . 1165.25 Échanges de messages entre l’initiateur et les décideurs pendant la négociation . . 1185.26 Échange entre les agents durant la phase d’initialisation . . . . . . . . . . . . . . . 1195.27 Échange entre les agents durant la phase de proposition . . . . . . . . . . . . . . . 1205.28 Annonce de la décision finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

A.1 Classification des Méthodes Multicritère (MMC) . . . . . . . . . . . . . . . . . . . 129

B.1 Représentation d’un agent en interaction avec son environnement et les autres agents 136B.2 Modèle d’agent cognitif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137B.3 Modèle d’agent réactif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Liste des tableaux

1.1 Les différents niveaux de la décision . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 Matrice de performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.3 Importance (poids) des critères . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.4 Différents calculs effectués par la méthode . . . . . . . . . . . . . . . . . . . . . . 221.5 SADG : Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.1 Les différents niveaux de décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.2 Protocoles de négociations :Travaux connexes . . . . . . . . . . . . . . . . . . . . . 41

3.1 Exemple de service web : Gmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.2 Exemple de service web : Github . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.3 Exemple de service web : Weather Underground . . . . . . . . . . . . . . . . . . . . 573.4 Exemple de service web : Instagram . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1 Analogie entre les niveaux du système proposé et ceux proposés par Desanctis etGallup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.2 Les phases des processus de décision, d’après Schwenk . . . . . . . . . . . . . . . . 634.3 Services web d’authentification et gestion des utilisateurs . . . . . . . . . . . . . . 924.4 Services web de gestion des sessions . . . . . . . . . . . . . . . . . . . . . . . . . . 934.5 Services web de gestion des documents . . . . . . . . . . . . . . . . . . . . . . . . . 944.6 Services web de gestion des formulaires . . . . . . . . . . . . . . . . . . . . . . . . . 964.7 Services web de l’analyse multicritères . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.1 Identification des critères . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105.2 Les différents niveaux de la décision . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.3 Paramètres subjectifs exprimés par le décideur 1 . . . . . . . . . . . . . . . . . . . 1115.4 Paramètres subjectifs exprimés par le décideur 2 . . . . . . . . . . . . . . . . . . . 1125.5 Paramètres subjectifs exprimés par le décideur 3 . . . . . . . . . . . . . . . . . . . 1125.6 Paramètres subjectifs exprimés par le décideur 4 . . . . . . . . . . . . . . . . . . . 1125.7 Résultat utilisant le rang [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165.9 Résultat utilisant le flux net [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

A.1 Les quatre problématiques de référence . . . . . . . . . . . . . . . . . . . . . . . . . 129

Liste des abréviations

AD Aide à la DécisionADG Aide à la Décision de GroupeAHP Analytic Hierarchy ProcessAPI Application Programming InterfaceAT Aménagement du TerritoireAMCD Analyse MultiCritères à la DécisionB2B Business to BusinessBDD Base De DonnéesBDI Belief Desire IntentionBEEP Blocks Extensible Exchange ProtocolBTP Business Transaction ProtocolCORBA Common Object Request Broker ArchitectureDCOM Distributed Component Object ModelDIAG Aide au Diagnostic de GroupeDS Decision Support SystemDSS-NPS Système d’Aide à la Décision pour la Sélection de Protocole de NégociationELECTRE ELimination Et Choix Traduisant la REalitéFTP File Transfer ProtocolIBM International Business MachinesICE Internet Communications EngineID Informatique DécisionnelleiOS iPhone Operating SystemGDSS Group Support Decision SystemGWT Google Web ToolkitHP Hewlett-Packard CompanyHTTP HyperText Transfer ProtocolHTTPS L’HyperText Transfer Protocol SecureHTML HyperText Markup LanguageJAX-RS Java API for RESTful Web ServicesJSON JavaScript Object NotationLIO Laboratoire d’Informatique d’OranMALE Multi-Agent Learning EnvironmentMAUT Multi Attribut Utility TheoryMIME Multipurpose Internet Mail ExtensionsOASIS Organization for the Advancement of Structured Information StandardsOSI Open Systems InterconnectionPHP Hypertext PreprocessorPLM programmation linéaire multicritèresPOP Post Office ProtocolPROMETHEE Preference Ranking Organisation Method for Enrichment Evaluations

Liste des abréviations XIV

QCM Questionnaire à Choix MultiplesQCS Questionnaire à Choix SimplesREST Representational State TransferRMI Remote Method InvocationRPC Remote Procedure CallRSS Rich Site SummarySAD Système d’Aide à la DécisionSAML Security Assertion Markup LanguageSANP Speech Act Based Negotiation ProtocolSGBDR Système de Gestion de Base de Données RelationnelleSIAD Systèmes d’Information et Aide à la DécisionSIG Systèmes d’Information GéographiqueSMA Système Multi AgentsSMTP Simple Mail Transfer ProtocolSOA Architecture Orientée ServicesSOAP Simple Object Access ProtocolSSL Secure Sockets LayerTCP Transmission Control ProtocolTLS Transport Layer SecurityTOPSIS Technique for Order of Oreference by Similarity to Ideal SolutionUDDI Universal Description Discovery and IntegrationUML Unified Modeling LanguageURI Uniform Resource IdentifierURL Uniform Resource LocatorUTA UTilités AdditivesUUCP Unix-to-Unix CopyUV Ultra VioletW3C World Wide Web ConsortiumWS Web ServiceWSDL Web Services Description LanguageWS-I Web Services-InteroperabilityXACML eXtensible Access Control Markup LanguageXHTML Extensible HyperText Markup LanguageXSLT eXtensible Stylesheet Language TransformationsXML eXtensible Markup Language

Introduction Générale

Contexte de l’étudeDans toutes les organisations, des décisions sont prises quotidiennement afin de résoudre des

problèmes. Ces décisions peuvent être prises individuellement ou collectivement et impactent à unniveau stratégique, tactique ou opérationnel. Néanmoins, quelle que soit leur complexité, elles sonttoujours engendrées selon le même processus décisionnel de base : tout d’abord, il faut identifier leproblème, ensuite le résoudre en collectant l’information, puis l’analyser et aboutir à la création desolutions potentielles, et pour finir, il faut opérer un choix sur ces dernières (renoncer aux autrespossibilités).

Pour prendre une décision importante, le (ou les) décideur doit recourir à une aide qui peutintervenir à différentes étapes du processus décisionnel. En effet, les enjeux sont souvent trop im-portants pour prendre le risque d’une prise de décision soumise à la seule vision éventuellementsubjective et généralement non experte du décideur. Par ailleurs, dans le cadre d’une décision degroupe, il y a le risque que les décideurs ne se mettent pas d’accord rapidement (ou même pas dutout) en occasionnant ainsi d’importantes pertes de temps lors de réunions longues et répétées.

Autrefois, l’Aide à la Décision (AD) reposait sur l’expérience individuelle, le savoir et l’expé-rience des conseillers des décideurs ainsi que sur l’analyse historique. L’opinion et la subjectivitéavait une grande importance, ensuite l’être humain a eu recours aux outils mathématiques pourformaliser l’acte de décision. Mais aujourd’hui la prise de décision repose sur des critères plus évo-lués car le monde est devenu plus complexe et les domaines sont très vastes ce qui rend plus difficileà un seul homme ou plus précisément un seul décideur de comprendre et maitriser les aspects d’undomaine donné.

L’aide à la décision ne résout pas le problème décisionnel seulement, mais, procure une aide audécideur afin qu’il clarifie ses idées et exprime au mieux ses préférences. Elle peut être un ensembled’opérations qui facilitent la tâche de prise de décision en simplifiant ou en raccourcissant le chemincognitif suivi par l’homme. Les fonctions de cette aide peuvent être très diverses dont nous citons :

– Recherche d’informations pertinentes.

– Organisation des informations.

– Traitement partiel ou total d’ensembles d’informations.

– Activation ordonnée de connaissances.

– Établissement de scénarios.

– Représentations spatiales et ou temporelles.

– Propositions de recommandation.

Introduction générale 2

L’aide à la décision est dite de Groupe quand les décideurs impliqués dans le processus décisionnelsont nombreux. Ce domaine est né lorsque les organisations ont réalisé que la décision à un seuldécideur n’était en fait pas une décision mais un résultat donné par un seul décideur, les organisa-tions ont cherché une véritable aide à la décision qui leur permettra de régler les problèmes dus àla multitude et la variété des décideurs ainsi qu’à la complexité des problèmes.

De l’aide à la décision collective sont nés les systèmes d’aide à la décision de groupe (GDSS :Group Decision Support System) qui ne sont que l’informatisation de ce concept c’est-à-dire unenvironnement informatique interactif permettant à un groupe de décideur de parvenir à une dé-cision collective.

Dans [60], le rôle principal d’un GDSS est d’augmenter l’efficacité des groupes de décision,en fournissant des niveaux différents d’aide, en incluant entre autres le partage d’information etl’analyse de la décision.

L’aide à la décision de groupe est une activité qui aide les décideurs à prendre une décision ouà mieux décider ce qu’il leur permet de gagner du temps et d’orienter, par conséquent, la prise dedécision qui est peut être impossible sans son aide.

Dans la réalité, les décideurs ne sont pas toujours dans le même lieu mais plutôt géographi-quement dispersés, la communication est alors nécessaire pour pouvoir décider. D’un point de vueopérationnel, l’aide à la décision a connu ces derniers temps une révolution : l’orientation desktopa évolué vers une orientation web pour faciliter la communication entre les décideurs en temps réel,parmi les outils du web il y a les services web proposant tous leurs avantages aux systèmes d’aideà la décision.

Un système d’aide à la décision orienté web est facile à contrôler et à adapter, et peut évolueren complexité au fur et à mesure. Les services web sont des outils permettant la communicationet l’échange de données entre applications et systèmes hétérogènes dans des environnements dis-tribués.

Les services Web sont, actuellement, promus par plusieurs compagnies, entre autres, Sun,Oracle, HP, Microsoft et IBM. Un terme nouveau, mais le concept est ancien car il s’agit, princi-palement, de déporter le traitement de données d’un poste client, vers un poste serveur sur lequel"tourne" l’application.

A cet effet, les services web sont conçus pour accélérer et faciliter la distribution de l’informationentre clients, fournisseurs, partenaires commerciaux et leurs différentes plates-formes, les servicesweb sont des programmes informatiques permettant la communication et l’échange de donnéesentre systèmes hétérogènes. Trois raisons pourraient inciter à opter pour un tel traitement :

1. la machine distante peut être en possession des données, les autres non ;

2. la machine distante peut disposer d’une puissance de calcul supérieure ;

3. la machine distante dispose de logiciels plus adaptés au traitement des données.[21]

En utilisant les standards XML, JSON et HTTP pour transférer des données, les servicesweb facilitent l’intégration d’applications tierces permettant d’offrir de nombreuses applicationsaccessibles à distance.


ProblématiqueLes outils de l’aide à la décision répondent donc aux besoins des décideurs face à toute la com-

plexité de la prise de décision pour analyser, valider, justifier, évaluer ou corriger des décisions àprendre.

Les Systèmes d’Aide à la Décision (SAD) ont pris une place de plus en plus essentielle danscertains processus de décision, au point parfois de remplacer l’intervention humaine par des pro-cessus automatiques.

De plus, avec le développement des réseaux et d’Internet, on a vu apparaître des moyens inéditsde consultation et d’expression ainsi que des outils de travail collaboratifs permettant de nouveauxtypes de processus de décision et d’aide à la décision de groupe ADG.

L’apport des systèmes d’aide à la décision est d’autant plus estimable quand les problèmes àrésoudre sont complexes. D’une manière générale, il y a deux aspects qui accroissent la complexitéd’un problème décisionnel et par conséquent rendent la prise de décision plus difficile ; les aspectsmulticritères et multi-décideurs.

L’aspect multicritères apparait naturellement dans les problèmes décisionnels, car, prendre unedécision implique forcément de faire un choix entre plusieurs alternatives en se basant sur un certainnombre de critères. Visant à traduire la réalité multicritères des problèmes et à aider un décideur àexprimer ses préférences, l’aide multicritères à la décision a largement intégré le domaine de l’aideà la décision.

Quant à l’aspect multi-décideurs, il apparait lorsqu’une décision n’est pas le fait d’un individuisolé mais plutôt d’un groupe d’individus pouvant avoir des points de vue différents, voir mêmeconflictuels. C’est ce que l’on appelle une décision de groupe. Une telle décision doit faire l’ob-jet d’une acceptation mutuelle de la part du groupe et nécessite des phases de confrontation despoints de vue comme la négociation ou le vote. Les systèmes d’aide à la décision de groupe ouGDSS (Group Support Decision System) sont une extension des systèmes d’aide à la décision, quiprennent en charge, outre l’aide individuelle à l’expression des préférences (comme l’aide multi-critères), la dimension multi-participants en facilitant la communication et l’échange structuré dedonnées et d’information, ainsi qu’en fournissant des outils d’agrégation des différents points devue et d’arbitrage.

Une prise de décision implique de faire le choix parmi plusieurs possibilités, un choix condi-tionné par l’évaluation de ces possibilités par rapport à plusieurs critères. Le cas du critère uniquen’est que peu présent dans la réalité. L’aide multicritères propose de prendre en charge cette réalitéet permet à un décideur de hiérarchiser un ensemble de solutions selon l’importance accordée auxdifférents critères.

De par leur efficacité, les méthodes d’aide multicritères à la décision ont largement intégré lessystèmes d’aide à la décision actuels. Néanmoins, ces systèmes doivent s’adapter à une autre réa-lité ; celle de la prise de décision de groupe, et s’étendre vers ce que l’on appelle des systèmes d’aidemulticritères à la décision de groupe.

Le croisement de certaines disciplines de l’AD entre elles représente un obstacle, et en particu-lier, c’est souvent l’ADG qui se greffe aux autres (ID et AMCD). Ainsi, la problématique de l’ADG


se résout de manière différente selon son positionnement par rapport au processus décisionnel. Elleconsistera en des outils soit de support de tâche collective et de communication, soit de résolutionde conflit pour parvenir à un accord entre les différents décideurs.

La collégialité de la prise de décision peut être expressément requise par le type de problèmetraité ou être une conséquence d’un choix structurel. Dans les deux cas, le processus décisionnelmulti-décideurs doit aboutir à une décision qui fait consensus au sein du groupe. Ainsi, un systèmed’aide à la décision de groupe GDSS doit fournir des mécanismes qui facilitent la confrontation despoints de vue et permettent de guider le groupe vers une solution mutuellement acceptable.

Aussi, le travail collaboratif de manière générale a considérablement évolué tirant tout l’avan-tage qu’offrent les nouvelles technologies. Un groupe ne doit plus être rassemblé en un même endroitpour pouvoir travailler. Les GDSS doivent s’inscrire dans cette logique et permettre à des décideursgéographiquement dispersés de réaliser leurs tâches.

Dans le contexte de la présente étude, nous nous posons les questions suivantes :

– Comment gérer les conflits et les désaccords lorsque nous avons une multitude de décideursayant chacun des intérêts, des points de vue et des préférences différents ?

– Comment trouver un compromis pour satisfaire tous les décideurs ?

– Comment gérer la décision lorsque plusieurs critères (quantitatifs et qualitatifs) contradic-toires sont impliqués ?

– Comment réaliser un système d’aide à la décision de groupe générique interopérable et faci-lement modifiable pour assurer la communication entre les différentes parties de la décision ?

ContributionsAfin de répondre aux besoins cités et pour faire face à une décision collective où différents points

de vue (préférences) des décideurs et plusieurs critères doivent être pris en considération, notretravail se situe dans l’aide multicritères à la décision de groupe et notre contribution, par la présenteétude, consiste à concevoir et mettre en œuvre une plateforme de communication, permettant defaire participer des décideurs géographiquement éloignés pour résoudre un problème décisionnel .Afin d’atteindre ce but, la mise en œuvre de la plateforme exploite les technologies du web, et plusspécifiquement la technologie des services web. Ces derniers permettent de mettre en place dessystèmes hautement évolutifs et dont l’intégration dans d’autres systèmes hétérogènes est aisée.Les services web de type REST reposent naturellement sur les standards du web et présententl’avantage de la simplicité, par conséquent, ce type de services web a été retenu pour la mise enplace de la plateforme.La plateforme proposée est composée de deux principales applications :

– Une application qui expose des services web prenant en charge les fonctionnalités d’aide àla décision de groupe et d’aide multicritères à la décision, ainsi que la gestion du systèmed’information sous-jacent.

– Une application cliente utilisant les services web précédemment cités, permettant aux utili-sateurs finaux d’utiliser les fonctionnalités exposées.

D’une manière générale, le processus décisionnel de groupe passe par trois phases principales :


– Compréhension collective du problème,

– Génération des solutions,

– Prise de décision.

La plateforme réalisée propose des fonctionnalités afin de prendre en charge ces trois étapes, nousen citons ici les principales :

– L’échange de messages entre participants.

– L’échange et archivage de documents.

– La prise en charge de l’aspect asynchrone des échanges.

– La génération de formulaires.

– La consultation des résultats par le biais de formulaires et d’agrégation.

– L’aide à la décision par exploitation de méthode d’analyse multicritères.

Au final, nous intégrons dans notre plateforme un protocole de négociation automatisé, basé sur lamédiation et l’agrégation multicritères (PROMETHEE II), permettant de dégager un compromisentre les décideurs.

Plan du documentPour répondre à la problématique abordée, ce document est organisé en trois grandes parties :

La première partie (Synthèse de l’état de l’art) illustre les notions fondamentales liées l’aideà la décision de groupe, les services web et la négociation dans les SMA.

La deuxième partie (Contributions) décrit notre contribution en deux chapitres la modéli-sation de l’approche proposée et enfin l’expérimentation et les résultats obtenus. En dernier nousavons un index intitulé l’analyse multicritères.

La troisième partie (Annexes) aborde, sous forme d’annexes les méthodes l’analyse multicri-tères ainsi que les systèmes multi agents.

Première partie : Synthèse de l’état de l’art

– Chapitre 1 : L’aide à la décision de groupe (SADG)Ce chapitre constitue une présentation générale des SAD en passant par la décision sa ty-pologie, ses acteurs, etc. Il définit, également, les processus décisionnels pour aboutir auxsystèmes d’aide à la décision de groupe. Nous concluons le chapitre par les travaux existantsdans la littérature et liés à ce contexte.

– Chapitre 2 : La négociation dans les Systèmes Multi Agents

Dans ce chapitre nous décrivons les concepts liés aux agents, aux systèmes multi agents, lesdifférentes techniques existantes dans la littérature pour résoudre les conflits afin de parvenirà un accord mutuellement acceptable selon un processus de négociation.Nous explicitons, plus en détails, les différentes formes de négociation et enfin nous présen-terons quelques travaux traitant la négociation dans les deux domaines : les systèmes d’aideà la décision de groupe et les Systèmes Multi Agents.


– Chapitre 3 : Les services webA travers ce chapitre, sont présentées les technologies web plus précisément les services web.Nous présentons des définitions en passant par l’intérêt de cette technologie, une architecturedétaillée ainsi que le fonctionnement des services web. Les principaux types de services sontdécrits dans ce chapitre. Les travaux les plus significatifs utilisant les services web sont passésen revue.

Deuxième partie : Contributions

– Chapitre 4 : La modélisation de l’approche proposéeCe chapitre décrit notre contribution qui porte sur :

– La proposition d’un modèle de processus de décision de groupe dans un contexte mul-ticritères et multi décideurs. Le système d’aide à la décision de groupe correspondants’articule autour d’une plateforme de communication web susceptible d’assurer la né-gociation entre un ensemble de décideurs en conflit. Cette plateforme sera détailléepar son architecture globale et son fonctionnement en décrivant chacun des modules lacomposant tout en détaillant les services web utilisés.

– La proposition d’un protocole de négociation basé sur la médiation l’analyse multicri-tères assurée par la méthode « PROMETHE II » afin d’aider les décideurs à mieuxexprimer leurs préférences.

– Chapitre 5 : l’expérimentation et résultats obtenusNous décrivons dans ce chapitre l’utilisation de notre plateforme à travers un scénario d’exé-cution et présentons les résultats obtenus.

Troisième partie : Annexes

– Annexe A : Les méthodes d’analyse multicritères

– Annexe B : Les systèmes multi agents

Le présent document s’achève par une conclusion où nous récapitulons les apports de notreétude et ouvrons des perspectives à cette dernière.

Première partie

Synthèse de l’état de l’art

Chapitre 1

L’aide à la décision de groupe

1.1 IntroductionLa prise de décision est une activité intrinsèque à celui qui est amené à la prendre. Elle est

souvent prise sur la base d’intuitions et d’expériences passées issues d’heuristiques observables autravers de biais systématiques [67].

Toutefois, dans la vraie pratique ceci n’est applicable que pour les problèmes familiers, nousnous retrouvons rapidement dans la difficulté de prendre une décision une fois confrontés à denouvelles situations. A ce titre, plus que jamais dans un monde complexe, et plein d’imprévus,l’entreprise se trouve dans l’obligation de prendre des décisions stratégiques, tactiques ou opéra-tionnelles, lourdes de conséquences (financières, humaine, etc.) pour sa compétitivité.

Afin d’appréhender les problèmes de décision complexes, les décideurs sont, régulièrement,confrontés à disposer des concepts et méthodologies permettant de formaliser un problème de dé-cision.

Pour répondre à ces besoins, le rôle de l’informatique est de proposer une architecture quiserve de fondations aux applications décisionnelles : un nouveau secteur informatique est en pleinexpansion c’est « l’aide à la décision ».

1.2 L’Aide à la DécisionROY [102] définit l’AD comme étant : « L’activité de celui qui , prenant appui sur des mo-

dèles clairement explicités mais non nécessairement complètement formalisés, aide à obtenir deséléments de réponse aux questions que se pose un intervenant dans un processus de décision, élé-ments concourant à éclairer la décision et normalement à recommander, ou simplement à favoriser,un comportement de nature à accroître la cohérence entre l’évolution du processus d’une part, lesobjectifs, et le système de valeurs au service desquels cet intervenant se trouve placé d’autre part».

A la lumière de cette définition, il apparait clairement que l’aide à la décision ne résout pas leproblème décisionnel, mais, procure une aide au décideur afin qu’il clarifie ses idées et exprime aumieux ses préférences.

Chapitre 1.L’aide à la décision de groupe 9

Selon [103] : "Aider à décider, c’est tout d’abord aider à clarifier la formulation, la transfor-mation et l’argumentation des préférences. A ce niveau, le concept clé est celui du critère". Cetteapproche monocritère suppose que le système soit suffisamment simple pour qu’il soit possibled’évaluer les différentes possibilités d’action en utilisant un seul indicateur.

Pour bien assimiler ces définitions, il s’avère nécessaire de se familiariser avec les différentesnotions se rapportant à l’aide de la décision que nous décrivons dans ce qui suit [12] :

1.2.1 La décisionLa décision est une action qui est prise pour résoudre un problème qui se pose à l’individu ou

à l’organisation [72]. Certaines écoles considèrent simplement la décision comme étant « un choixentre plusieurs alternatives » [105] ;

Mintzberg [79], définit la décision, qu’elle soit individuelle ou collective, comme « L’engagementdans une action, c’est-à-dire une intention explicite d’agir ». Elle a pour but la résolution de pro-blèmes qui se posent à l’organisation ou à l’individu ; et elle peut correspondre à un changementde l’environnement (comportement réactif) ou au désir de saisir une opportunité et ainsi changerl’environnement (comportement d’anticipation).

Dans le même sens, [43] a défini la décision par : « Décider, c’est prendre des risques certesmais c’est être en réaction face à un choix stratégique à prendre ».

Pendant que d’autres considèrent la décision en lui incluant le processus de sélection de butset d’alternatives (des solutions possibles). La prise de décision peut difficilement être définie in-dépendamment de l’environnement dans lequel elle est développée et la décision est elle-mêmeindissociable du contexte global du processus de prise de décision [118].

1.2.2 Les niveaux de la décisionLa décision est classée en trois niveaux [140] :

1. Le niveau stratégique : engage l’organisation sur une longue période (plus de 5 ans). Lesdécisions sont prises par le plus haut niveau hiérarchique, par exemple la Direction Général.Ces décisions sont uniques, occasionnelles, les modèles analytiques sont utilisés dans ce niveaude décision.

2. Le niveau tactique : engage l’organisation à moyen terme (de 2 à 5 ans). Les décisions sontprises par les encadrements supérieurs. Ces décisions sont peu fréquentes, peu prévisibles, lasimulation est très utilisée du fait de la complexité des systèmes.

3. Le niveau opérationnel : engage l’organisation à court terme (moins de 2 ans). Les déci-sions sont prises par les exécutants. Ces décisions sont fréquentes, très prévisibles. Ce niveauconcerne le plan détaillé (ordonnancement, allocation de tâches, etc.).

Le tableau 1.1 décrit succinctement les différents niveaux de la décision.


Caractéristiques Stratégique Tactique OpérationnelleDomaine de la déci-sion

Relations avecl’environnement

Gestion des res-sources

Utilisation des ressource dansle processus de transforma-tion

Horizon de temps Long terme Moyen terme Court termeEffet de la décision Durable Bref Très brefRéversibilité de ladécision

Nulle Faible Forte

Procédure de déci-sion

Non program-mable

Semi program-mable

Programmable

Niveau de la prisede décision

Direction géné-rale

Directions fonc-tionnelles

Chefs de services, chefs d’ate-lier

Nature des informa-tions

Incertaines etexogènes

Presque com-plètes et endo-gènes

Complètes et endogènes

Table 1.1 – Les différents niveaux de la décision

1.2.3 La typologie de la décisionSelon [118], les décisions peuvent être classées en 3 types dépendant de leurs niveaux de struc-

turation :

1. Décision structurée : une décision est bien structurée quand un processus connu et expli-citable existe permettant de traiter les informations dans le système.

2. Décision semi structurée : le problème n’est pas clairement posé, les données sont souventqualitatives et pas fiables, donc difficilement formalisable et le processus décisionnel ne peutpas être modélisé tel qu’il est, il faut le décomposer en sous modéliser au moins une partiedu processus, la décision est difficilement exprimables forme algorithmique.

3. Décision non structurée : difficilement justifiable de manière rationnelle.

1.2.4 Les acteurs de l’aide à la décisionEn AD, le terme acteur désigne un individu ou un groupe d’individus intervenant dans le

processus d’AD. Dans [69], l’auteur distingue 8 acteurs différents :

1. Le décideur : c’est celui qui a des problèmes encore très confus dans son esprit et que l’ADvise à résoudre en l’assistant pour mieux exprimer ses préférences vis-à-vis d’une situationdonnée.

2. L’homme d’étude (l’informaticien, l’analyste) : c’est celui qui prend en charge l’AD, ildoit à la fois concevoir des modèles et les mettre en œuvre au sein d’un processus de décision.

3. L’intervenant (l’expert du domaine) : c’est celui qui par son intervention, conditionnedirectement la décision en fonction du système de valeurs dont il est porteur.

4. L’Agi : il est concerné par les conséquences de la décision. Il intervient indirectement dansle processus par l’image que d’autres acteurs se font de ses valeurs et plus concrètement deson système de préférences.

5. Le demandeur : il demande l’étude et alloue les moyens.


6. Le Négociateur : mandaté par un décideur en vue de faire valoir la position de celui-ci dansune négociation et de rechercher une action compromis.

7. Le Médiateur : intervient en vue d’aider les décideurs (ou les négociateurs) à rechercherune action compromis.

8. L’Arbitre (juge) : intervient en se substituant aux acteurs dans la recherche d’une actioncompromis.

1.2.5 Le processus décisionnelL’activité d’AD s’articule autour d’un processus de décision qui peut être défini comme suit :

« Le processus de décision est un ensemble d’activités déclenché par un stimulus, et aboutissant àun engagement spécifique à l’action » [25].

Il est essentiel de distinguer les deux phases principales [129] :

1. La détermination du problème (problem finding) : c’est à dire le décideur détermineà quel problème il estime être confronté ;

2. la résolution du problème (problem solving) : c’est la phase la plus étudiée qui consisteà répondre au problème précédemment formulé. Il est possible que les étapes nécessaires à larésolution du problème amènent le décideur à reformuler son problème initial.

Cette phase de résolution se décompose à son tour en plusieurs étapes que décrit le processusde Simon (le plus célèbre des processus décisionnels disponibles dans la littérature) et qui opèreen 4 étapes non nécessairement séquentielles [111] : Information, Conception, Choix et Evaluation,comme indiqué dans la figure 1.1.

Figure 1.1 – Processus de décision de Simon

– Information : consiste à déterminer et collecter l’ensemble des données et informationsnécessaires (mais pas forcément suffisantes) qui seront utilisées lors des phases suivantes.

– Conception : consiste à analyser les données, récolter et créer des solutions potentielles, donctout simplement générer les différentes alternatives qui forment l’ensemble des possibilités.

– Choix : cette étape constitue la phase de décision proprement dite. Elle consiste à restreindrel’ensemble des possibilités au sous-ensemble des possibilités sélectionnées, répondant le mieuxaux exigences d’une décision correcte.

– Evaluation : en regard des trois phases précédentes, de la solution provisoirement retenuecomme satisfaisante, cette phase peut amener à la réactivation de l’une des trois phasesprécédentes ou, au contraire, à la validation de la solution.


1.3 Les Systèmes d’Aide à la Décision (SAD)Les systèmes d’aide à la décision font référence à un ensemble vaste et varié d’outils informa-

tiques supportant directement ou indirectement la décision voire le travail général des gestionnairesà différents niveaux du processus décisionnel.

L’existence de ces outils modifie considérablement la décision, ils permettent aux décideurset aux organisations de mieux gérer la masse et la complexité de l’information, de la structureret de l’utiliser pour produire des nouvelles connaissances, ainsi les organisations peuvent mieuxcoordonner l’activité des décideurs.

1.3.1 La taxinomie des SADMême si dans la littérature, il n’existe pas une taxinomie universellement admise des SAD car

leur classification varie d’un auteur à un autre, trois principales périodes de recherche sont claire-ment distinguées et permettent de classer les SAD selon trois grands axes [128].

– Au départ, un SAD faisait référence à tout outil informatique qui aide le gestionnaire dansses tâches de prise de décision, en se concentrant simplement sur la phase choix du processusdécisionnel. Donc ces types de SAD ne pouvaient aider à résoudre que des problématiquesdécisionnelles bien structurées dont l’espace des solutions a été défini ou est connu.

– Après, vers la fin des années quatre-vingt, les chercheurs se sont davantage intéressés au SADcomme outil d’aide à la décision au sens large du terme et donc au processus décisionnel, in-vestissant ainsi le terrain des phases d’information et de conception du processus décisionnel,ce qui a engendré des SAD spécifiques pouvant résoudre des problématiques décisionnellesmal structurées.

– Dernièrement, l’aspect social, c’est-à-dire l’échange de l’information dans une organisationainsi que la communication et le travail coopératif sont au centre de l’attention de la recherche,formant ainsi ce qui est appelé les systèmes d’aide à la décision de groupe SADG.

Aujourd’hui, certains systèmes sont très spécialisés, alors que d’autres tentent d’intégrer plu-sieurs fonctionnalités de ces trois axes comme le montre la figure 1.2 [13] :

1.4 l’aide à la décision de groupeLa décision de groupe a vu le jour lorsque les organisations se sont rendues compte que les

modèles de décision mono décideur n’étaient réellement pas une décision mais un résultat donnépar un seul décideur alors que le besoin de ces organisations était plus complexe que ce résultatet en réalité elles avaient besoin de véritables décisions issues de compromis entre les intérêts etpoints de vue de plusieurs decideurs concernés par cette décision.

1.4.1 DéfinitionsL’aide à la décision de groupe selon Marakas [74] est : «une activité conduite par une entité

collective composée de deux ou plusieurs individus et caractérisée à la fois en termes de propriétésde l’entité collective et de celles de ses membres individuels»


Figure 1.2 – Taxinomie des SAD


Tandis que Laborie [68] la définit comme étant : « une convergence d’interactions cognitives etvisuelles, planifiées ou opportunistes, où des personnes acceptent de se rassembler pour un objectifcommun, dans une période de temps définie, soit au même endroit, soit dans des endroits diffé-rents, dans le but de prendre des décisions ».

Cette définition combine plusieurs aspects définis dans la littérature. Elle s’inspire notammentde l’ingénierie, des sciences de l’information et des sciences de gestion [64], [96]. Elle comporte septdimensions :

1. Le groupe de personnes définit l’aspect collectif. La décision n’est pas le fait d’un seulindividu, mais d’un collège aux rôles et objectifs potentiellement différents.

2. La prise de décision est l’objectif premier du groupe. Elle constitue l’activité de choixentre plusieurs solutions.

3. Une convergence d’interactions souligne la notion de focalisation de l’activité du groupe.

4. Un objectif commun pour lequel les acteurs acceptent de se rassembler fait écho auxdéfinitions de la collaboration et de la coordination. Il s’agit du partage de l’objectif finalentre les participants et de la compréhension de leur rôle dans l’atteinte de cet objectif.

5. Le niveau de formalisation variable (« planifiée ou opportuniste ») : la définition englobeen partie les échanges opportunistes, imprévus et informels.

6. La dimension temporelle bornée (« une période de temps définie ») est primordiale carelle induit un début et une fin à l’activité. Il peut s’agir d’une activité informelle de quelquesminutes jusqu’à une activité pouvant prendre plusieurs semaines.

7. La distribution géographique des acteurs de la décision se justifient par les réalités or-ganisationnelles. La prise de décision peut ainsi rassembler des acteurs distribués sur un ouplusieurs sites [17].

1.4.2 Le processus de prise de décisionLe processus de prise de décision fait référence aux états successifs par lesquels passe le groupe

pour arriver à la décision. Le processus de décision est considéré comme une machine à états : legroupe part d’un état initial, où plusieurs perspectives existent et, en intégrant des perspectives,atteint un état final.

Laborie [68] propose un modèle du processus de décision collective qui passe par les étapessuivantes [90] :

– Compréhension collective du problème.

– Génération des solutions.

– Négociation et confrontation des points de vue.

– Décision.


1.4.3 Les principaux acteurs de la décision de groupeParmi les acteurs d’un processus d’aide à la décision, il y a deux types d’acteurs principaux

qu’il faut identifier : le facilitateur et les participants. En effet, le processus de décision degroupe concerne surtout l’organisateur de la prise de décision (appelé aussi facilitateur, médiateurou bien initiateur) et les experts dans la prise de décision (les participants) [27] :

1. Le facilitateurLe facilitateur est une composante clé dans le processus de prise de décision de groupe, c’estun agent accepté par tous les participants à la réunion. Il doit s’occuper entre autres de :

– Lancer et préparer les étapes du processus décisionnel.

– Définir la problématique de la décision.

– Organiser le groupe de décideurs pour le processus.

– Gérer le groupe de façon à équilibrer les contributions individuelles et le fonctionnementde groupe.

– Faire converger le processus de prise de décision et diffuser les résultats aux participantsà la fin, en effet, il est responsable du processus complet et de son achèvement.

2. les participantsLes participants sont des acteurs qui interviennent dans la session de prise de décision, pro-duisant et partageant différents types d’informations telles que les idées et les commentaires.Les activités de groupe sont, en effet, exécutées par des équipes en collaboration. Elles in-cluent la communication des idées, l’échange et le partage des informations, la coordinationdes activités, la discussion des résultats et la prise des décisions. Elles impliquent de nom-breuses variables organisationnelles et sociales qui conditionnent le succès de n’importe quelletechnologie d’aide. Dans le contexte du système d’aide à la décision de groupe, la structurede groupe, la taille du groupe, les rôles, les buts, les conflits individuels et les motivationssont des exemples de telles variable [3].

1.5 Les systèmes d’aide à la décision de groupe (SADG)

1.5.1 DéfinitionLes systèmes d’aide à la décision de groupe ou en anglais Group Decision Support System

(GDSS) peuvent être vus comme des SAD évolués par le fait qu’il y a plus d’un décideur impliquésdans le processus décisionnel. [13]

Concrètement, ce sont des environnements informatiques interactifs qui favorisent un effortconcerté et coordonné d’une équipe de décideurs vers l’achèvement de tâches collectives de prise dedécision. Ils font évoluer la prise de décision collectivement en facilitant l’échange et l’utilisationd’informations par les membres du groupe d’un côté, et l’interaction entre le groupe et le systèmed’un autre côté.

En plus des données et des modèles de décision, les GDSS doivent prendre en compte la dyna-mique du processus de prise de décision de groupe.

Parmi les définitions qu’on retrouve dans la littérature, nous avons préféré l’une des plus popu-laires celle de Desanctis et Gallupe [34] qui présente un GDSS comme étant : « une combinaisond’ordinateurs, de communications et de technologies de décision travaillant en tandem pour fournir


une aide à l’identification de problème, à la formulation et à la génération de solutions pendant lesréunions de groupe. »

1.5.2 La structure d’un SADGUn SADG fournit une certaine aide informatique pour la communication, le partage d’infor-

mation, l’intégration d’idées multiples et la résolution de conflit.

Il peut être caractérisé comme comprenant trois principaux composants [10] :

1. Une structure physique : elle peut aller des plus spécialisées (salle équipée de stationsspécialisées, affichage de groupe, surface de travail configurée, éclairage modifiable, etc.) auxsalles de réunion ordinaires (à condition que chaque participant ait son PC portable) enpassant par les salles de vidéo-conférence.

2. Des outils : incluant certains supports pour les différentes phases du processus décisionneltels que la génération d’idées, l’évaluation et le classement des solutions alternatives, le voteet la sélection d’actions et divers modèles de décision.

3. Un médiateur : agissant comme un « facilitateur » pour le groupe et aidant ce dernierdans l’élaboration de l’ordre du jour de la réunion et dans l’utilisation des outils appropriéspour les activités collectives.

1.5.3 L’architecture générale d’un processus de décision de groupeLe terme processus de prise de décision fait référence aux états successifs par lesquels passe

le groupe pour arriver à la décision [68]. Un processus de décision de groupe comprend plusieursétapes au cours desquelles il est question de cerner la problématique, de collecter des données,d’élaborer des règles faisant en sorte que le processus devienne un contrat entre les participants quis’engagent ainsi à accepter le résultat qui en découle, d’évaluer des solutions préconisées en regarddes points de vue retenus, de mettre en application les règles sur lesquelles les participants se sontmis d’accord et de s’enquérir de l’adéquation des recommandations. Les observations empiriqueset leur confrontation avec des études existantes permettent de soutenir que les processus de prisede décision de groupe peuvent être modélisés de façon générique [3] illustrée par la figure 1.3 :


Figure 1.3 – Architecture générale d’un processus de décision de groupe

– Phase de préparation Cette phase (asynchrone), permet de préparer en ligne des réunionsen :

– Fixant avec concertation de tous les participant la date et l’heure de la réunion pours’assurer de leur disponibilité, cela peut se faire au travers d’outils d’organisation au-tomatique des réunions par consultation automatique des plages libres de chacun (avecréservation automatique de la salle de réunion ou des salles de téléconférence égalementsi le besoin y est).

– Informant les participants de l’objet de la réunion (la problématique) afin qu’ils puissentfaire de la documentation, de la recherche d’information et de la collecte des données.

– Phase de compréhension collective du problème Cette phase (synchrone ou asyn-chrone) permet de mieux cerner et d’analyser la problématique collective grâce à la commu-nication électronique sous forme de :

– Outils de partage d’informations et de documents à distance sur un support numérique.

– Outils d’édition de documents en groupe telles que les Wikis qui permettent maintenantde faire travailler de manière asynchrone, sans les réunir et sans qu’elles aient besoinde se connaître des personnes construisant collaborativement un même document (livre,scenario, cours universitaire, cahier des charges, plan, carte, etc.)


– Outils d’AD d’analyse tels que les SIAD et les SIG.

– Phase de génération des solutions et hiérarchisation Cette phase (synchrone) permetde concevoir différentes solutions potentielles à la problématique, en utilisant :

– Des outils de génération d’idées.– Des outils de classifications et de hiérarchisation comme la catégorisation et/ou le ran-gement.

– Phase de négociation et confrontation des points de vue Cette phase (synchrone)permet la confrontation des points de vue des participants sur les solutions initialement créeset essaye de les amener vers un consensus qui satisfait toutes les partis, elle est réalisée autravers :

– d’outils de résolution de conflit tel que les méthodes de vote électronique et de négocia-tion.

– d’outils d’échange des commentaires sur les différentes solutions.

– Phase de Décision Cette phase (synchrone ou asynchrone) permet d’évaluer des solutionspréconisées dans la phase précédente en regard des points de vue retenus puis de valider ladécision prise, des outils de simulation et de prédiction peuvent être utilisés.

– Phase de suivi Cette phase (synchrone ou asynchrone) permet de mettre en application ladécision qui a été prise et d’évaluer son impact sur la problématique [13].

1.5.4 Les intérêts des GDSSLe rôle principal d’un GDSS est d’augmenter l’efficacité des groupes de décision, en fournissant

des niveaux différents d’aide, en incluant [60] :

– La génération d’idées.

– Le partage d’informations.

– L’analyse de la décision.

– L’évaluation ou le vote des options alternatives.

– L’élaboration du rapport de la session de prise de décision

Cela peut être accompli en ôtant les barrières de communication, en fournissant des techniquespour structurer l’analyse de décision et gérer systématiquement le modèle, le temps, le choix ou lecontenu de la discussion [34].Les GDSS sont de plus en plus populaire en raison de leur capacité à améliorer l’interaction entreles membres d’un groupe et d’augmenter sa productivité. Ils offrent une alternative intéressanteaux environnements traditionnels de réunion « face-à-face ». Les managers les trouvent plus utilescar les réunions traditionnelles peuvent causer une perte de temps tout en étant improductives [57].Il y a de nombreux autres avantages des GDSS. Incluant l’anonymat, la communication parallèle,l’automatisation de la tenue des dossiers, les GDSS impliquent plus de structure et une productivitéaccrue [4].

1. L’anonymat : permet l’échange libre d’idées, sans crainte du jugement, ceci ayant pour effetd’accroitre la participation des membres du groupe, et par la même, d’augmenter la quantitéd’information échangée [4]. Aussi, les participants se sentent moins tenus de se conformer àl’opinion du groupe ou à celle de la hiérarchie, ce qui les encourage à présenter des idées nonconventionnelles ou moins communes [93].


2. La communication parallèle : un GDSS permet à chacun de «parler» et «penser» enparallèle. En effet, dans une réunion traditionnelle, les participants doivent suivre le locuteuret ne peuvent pas prendre le temps de réfléchir. De plus, chaque personne n’a que quelquesminutes pour exprimer ses idées. Un GDSS permet à tous les participants de s’exprimer enparallèle et pendant toute la durée de la réunion. De cela découle une participation accrueet une synergie de groupe [57].

3. L’automatisation de la tenue des dossiers : un GDSS peut automatiquement enregistrerles commentaires, votes et autres informations partagées par un groupe. Cela permet auxparticipants de ne plus avoir à se souvenir mentalement de ce qui a été dit ou de prendre desnotes.

En utilisant un GDSS, les membres du groupe peuvent discuter un problème, échanger desidées, évaluer les solutions alternatives, voter et choisir une solution, imprimer des rapports etaccomplir tout autre travail collaboratif. Les GDSS sont censés améliorer la performance du groupeen améliorant le processus de prise de décision. A ce titre, les GDSS offrent au groupe plusieursavantages :

– Les GDSS peuvent améliorer la participation et la compréhension et atténuer les conflitsinterpersonnels contre productifs [81] ;

– La fragmentation du temps peut également être réduite par les GDSS puisque les participantspeuvent faire des contributions simultanément [33]. Les personnes travaillent sur le systèmeen parallèle. Nous parlons de parallélisme de la communication [39]. Ainsi, il est possible degénérer des solutions innovatrices et créatives, d’obtenir plusieurs idées en circulation et deles capter rapidement ;

– L’évaluation des alternatives peut également être plus objective avec l’utilisation des GDSS[31], [108] ;

– Le système fournit un schéma anonyme. Toute suggestion d’idées est anonyme et aucunedominance n’est privilégiée. De ce fait, il y a une opportunité égale pour la participation àtoutes les réunions pour chaque participant. Ainsi, le participant ne se sent pas encombrépar les statuts des autres ;

– Le schéma d’anonymat maximise la participation des intervenants dans l’élaboration de so-lutions, aide les membres à exprimer leurs opinions plus librement et assure ainsi un plusgrand appui aux solutions élaborées de la part des participants [47] ;

– Le système offre un accès à des sources d’information externes afin qu’il puisse être utilisédans un processus décisionnel collectif efficacement et plus facilement ;

– Le système favorise le développement d’une mémoire organisationnelle en gardant un enre-gistrement des entrées des participants et des choix faits ;

Un autre aspect positif des GDSS est l’amélioration de la cohésion du groupe et des relationsentre les participants dans le contexte de la prise de décision collective [6], [28] et, selon [119], unedécision de plus grande qualité [17].

1.5.5 La typologie des GDSSDeSanctis et Gallupe [34] distinguent trois types de GDSS correspondant aux trois niveaux

d’évolution que ces auteurs ont mis en perspectives :


– Niveau 1 : la fonction essentielle des GDSS du premier niveau est d’améliorer la communi-cation entre les décideurs.

– Niveau 2 : les GDSS du deuxième niveau, intégrant les mêmes caractéristiques que ceux dupremier, sont en plus dotés de procédures permettant de modéliser et d’agréger les préférencesindividuelles afin d’établir un consensus. Remarquons que les GDSS de ces niveaux fontsouvent intervenir un facilitateur dont le rôle est de faire avancer le processus de décision.

– Niveau 3 : les GDSS de niveau trois permettent de façon automatisée de structurer leséchanges d’information et la communication sur la base de recommandations émises par dessystèmes experts ou d’experts humains, comme par exemple, les règles à suivre au cours duprocessus de décision et les méthodes d’aide à la décision à mettre en œuvre, en fonction ducontexte.

1.6 L’aide à la décision multicritèresLa plupart des problèmes de décision qu’ils soient économiques, industriels, financiers ou poli-

tiques sont de nature multicritères, L’existence d’une pluralité de critères utilisés (coût avantage,coût efficacité) est le signe manifeste de la complexité des problèmes de choix. Les méthodes multi-critères sont des outils d’aide à la décision, leur développement a débuté dans le contexte militairedepuis les années 1960 pour deux raisons essentielles : L’amélioration de la gestion et la fournituredes moyens nécessaires pour les soldats. Les méthodes utilisées, à l’époque, sont issues du do-maine de la recherche opérationnelle. Ces méthodes permettaient d’optimiser une fonction tout enconsidérant un ensemble de contraintes prédéfinies. Par la suite, ces méthodes ont investi d’autresproblématiques décisionnelles où le facteur humain a pris une dimension importante [13].

1.6.1 Définition de l’aide à la décision multicritèresD’après Vincke [123] : « L’aide à la décision multicritères vise, comme son nom l’indique, à

fournir à un décideur des outils lui permettant de progresser dans la résolution du problème dedécision où plusieurs critères souvent contradictoires, doivent être pris en compte, elle permet demodéliser de la manière la plus fidèle possible les préférences d’un expert, une telle modélisationpermet ensuite la construction d’outils adaptés et capables d’assister ou de remplacer un décideursur des problèmes complexes ».

1.6.2 Vocables associés à l’analyse multicritèresDans cette section, nous définissons tous les concepts fondamentaux qui structurent l’AMC.

1.6.2.1 Actions

Ce sont des éléments qui font l’objet de l’analyse multicritères. Les ouvrages de référence decette discipline parlent plutôt des actions potentielles qui sont les éléments qui vont faire l’objet dela comparaison. Dans les différentes formes, en fonction de la procédure retenue : Action potentielleest une action provisoirement jugée possible par un des intervenants au moins ou présumée tellepar l’homme d’étude en vue de l’aide à la décision [76].

1.6.2.2 Critères

Un critère est : « Une expression qualitative ou quantitative permettant de juger la conséquence,désignée aussi par le terme de performance, d’une action vis à vis d’un objectif ou d’une contrainte


», l’ensemble des critères C comprend m critères (de c1 à cm) [13].La performance, ou l’évaluation, de l’action ai pour un critère cj donné est définie par le termegj(aj). Le choix des critères doit être cohérent et doit permettre de « faire le tour de la question» [107]. Cette cohérence est vérifiée si les trois conditions suivantes sont respectées [117] :

1. Exhaustivité : il s’agit de ne pas oublier un critère. Le test d’exhaustivité proposé par Royet Bouyssou [102] est très simple : quand les conséquences de deux actions sont identiquespour l’ensemble des critères en présence, il doit exister une relation d’indifférence entre cesdeux actions [102].

2. Cohérence : il doit y avoir une cohérence entre les préférences locales de chaque critèreet les préférences globales. C’est-à-dire que si une action a est égale à une action b pourtous les critères sauf un où elle lui est supérieure, ceci signifie que l’action a est globalementsupérieure à l’action b.

3. Indépendance : il ne doit pas y avoir une redondance entre les critères. Leur nombre doitêtre tel que la suppression d’un des critères ne permet plus de satisfaire les deux conditionsprécédentes [76].

1.6.2.3 La matrice de performances

Appelée aussi matrice d’évaluation ou de jugement (Table 1.2), elle se compose des élémentssuivants :

– Ensemble des actions potentielles A= a1, a2, a3, ..., an avec A = ai Pour i = 1, 2, ..., n.

– Différents critères gj Pour j = 1, 2, ...,m.Le poids Pj qualifie l’importance relative d’un critère Cj donné vis à vis des autres critères.Il s’agit d’un paramètre inter critère.

– Évaluations ou jugements eij Pour i = 1, 2, ..., n; j = 1, 2, ...,m.

g1 ... gj ... gn

a1 g1(a1) ... gj(a1) ... gn(a1). ... ... ... ... .... ... ... ... ... ...ai g1(ai) ... gj(ai) ... gn(ai). ... ... ... ... .... ... ... ... ... ...an g1(an) ... gj(an) ... gn(an)

Table 1.2 – Matrice de performance

1.6.2.4 Paramètres subjectifs

Ce sont des paramètres fixés par le décideur, selon l’application et la situation traitée. Ilspeuvent être classifiés en deux catégories [55] paramètres inter critères et paramètres intra critères.

– Paramètres inter critèresCe sont des paramètres utilisés pour évaluer l’importance relative de chaque critère, on parlesouvent de poids des critères. Il s’agit d’un nombre Pj attribué différemment à chaque critère,selon son importance vis-à-vis des autres critères. Cette opération n’est pas toujours facile


Performance Design AutonomiePerformance 1 5 2

Design 1/5 1 1/3Autonomie 1/2 3 1

Table 1.3 – Importance (poids) des critères

pour le décideur, l’homme d’étude peut l’aider à exprimer clairement son appréciation del’importance relative de chaque critère.

Remarque : La performance du produit est beaucoup plus importante que le design. Lamatrice doit, ensuite, être normalisée en divisant chaque élément par le total de la colonne.Le poids est obtenu en calculant la moyenne de la ligne (Poids=Moyenne).

Performance Design Autonomie PoidsPerformance 0.58 0.56 0.6 0.58

Design 0.11 0.11 0.11 0.11Autonomie 0.29 0.33 0.3 0.31Somme 1.7 9 3.33

Table 1.4 – Différents calculs effectués par la méthode

– Paramètres intra critèresIls formalisent pour, chaque critère, l’appréciation subjective de leurs valeurs. Ils comprennentle seuil d’indifférence, le seuil de préférence et le seuil de veto [63].

1. Seuil d’indifférence Le seuil d’indifférence indique l’écart dans lequel aucune pré-férence ne peut être établie sur un critère. Ces seuils permettent de tenir compte del’imprécision et des incertitudes sur les évaluations ou sur les données.

2. Seuil de préférence Le seuil de préférence indique l’écart à partir duquel une préfé-rence nette peut être établie entre deux évaluations. L’écart entre le seuil d’indifférenceet le seuil de préférence indique une préférence faible entre deux évaluations.

3. Seuil de veto Le seuil de veto permet de fixer une notion supplémentaire. Si ce seuilest dépassé sur un critère, alors l’action ne peut être prise en considération. Il définitdonc une situation intolérable pour un des décideurs. Il s’exprime par l’écart maximumacceptable autour de la valeur de l’évaluation [55].

1.6.3 Démarche générale d’une méthode MulticritèresLa démarche multicritères est différente d’une méthode à une autre mais pour la majorité des

méthodes, on distingue les quatre étapes suivantes [78] :

1. Dresser la liste des actions potentielles Au cours de cette étape, on établit une listedes actions potentielles qui vont rentrer en concurrence. Cette liste n’est pas exhaustive etdéfinitive. Elle peut évoluer tout au long de l’étude (suppression ou ajout d’actions)[117].

2. Cerner la famille des critères Il s’agit d’élaborer la liste des critères à prendre en consi-dération. Un critère peut être plus important qu’un autre. Cette importance relative estexprimée par un nombre appelé poids [117].


3. Établir la matrice des performances Comme son nom l’indique la matrice de perfor-mances est un tableau à double entrées, dans lequel chaque ligne représente une action etchaque colonne un critère. L’intersection d’une colonne j avec une ligne i représente le juge-ment de l’action i par rapport au critère j. Chaque action est jugée par rapport à chacun descritères. Pour définir une solution (action) qui fait émerger une préférence commune (jouitglobalement des meilleures évaluations), les jugements doivent être agrégés [52].

4. Agrégation des performances Pour définir une solution (action) qui fait émerger une pré-férence commune (qui jouit globalement des meilleures évaluations), les jugements doiventêtre agrégés. Les méthodes multicritères diffèrent selon leurs façons de traiter cette dernièreétape [89]. On distingue une multitude de méthodes d’agrégations, et si elles sont si nom-breuses c’est parce qu’aucune méthode ne respecte la totalité des exigences.

1.6.4 Classification des différentes méthodes d’Analyse MulticritèresLes différentes méthodes d’analyse multicritères sont classifiées dans ce qui suit selon leurs

propriétés dans le traitement de la matrice d’évaluation (la méthode d’agrégation)[63].

1.6.4.1 Agrégation complète

Dans cette approche d’inspiration américaine, les différents critères sont synthétisés dans uneseule fonction mathématique monotone (à sens d’évaluation unique). A partir des évaluations desdifférents critères, la fonction d’optimisation résultante dite d’utilité ou d’agrégation, produit doncune valeur unique évaluant globalement la solution [mena, 00] La somme ou moyenne pondéréede notes est l’exemple le plus connu de ces techniques. Elle présente comme défauts, graves ounon selon la situation, une compensation possible entre critères (notes) et une forte sensibilité auxchangements d’échelle. L’approche suppose que tous les jugements soient commensurables et tran-sitifs et exclut toute incomparabilité entre deux actions. Les méthodes relevant de cette approcheconviennent bien aux problèmes dont les critères sont indépendants, autrement dit, lorsque tousles critères interagissent sur la décision finale. Comme exemple de cette approche on peut citerplusieurs méthodes : MAUT (Multiple Attribute Utility Theory), UTA (Utilité Additives), AHP(Analytic Hierarchy Process), etc.[20], [89].

1.6.4.2 Agrégation partielle

Cette approche repose sur la comparaison des actions deux à deux puis une synthèse des résul-tats de ces comparaisons (c’est d’ailleurs la façon de synthétiser qui diffère entre les méthodes decette approche). Elle permet de respecter l’incomparabilité, mais au prix de la clarté des résultats.Parmi les méthodes les plus connues d’agrégation partielle ou de surclassement, On cite les famillesELECTRE (Elimination Et Choix Traduisant la Réalité) et Prométhée. Les inconvénients de cetteapproche se résument dans la forme des résultats (Les réponses sont généralement complexes) et lenombre important de comparaisons entre les actions (Pour n actions, il faut effectuer n fois (n-1)comparaisons) [83], [89].

1.6.4.3 Agrégation locale

Contrairement aux deux approches précédentes où l’on suppose que l’ensemble des actions estfini et de dimension raisonnable, cette approche s’applique à des ensembles d’actions d’une trèsgrande dimension voire infinis lorsque les actions varient en continu. Partant d’une solution dedépart, la technique permet de chercher au voisinage de cette solution s’il n’y en a pas de meilleureet ce de manière répétitive. Développées dans le cadre de la programmation mathématique aux


objectifs multiples, ce type de méthode alterne les étapes de recherches des solutions et les étapesd’interaction avec les décideurs [78], [89]. Les principales méthodes d’agrégation locale itérativeexistantes sont : Plm (programmation linéaire multicritères), Stem (Pop), etc. [107], [76].

1.7 Travaux connexesDans le domaine de l’aide à la décision, il existe une variété de systèmes conçus pour traiter

différents types de prise de décision, cependant on regroupe l’aide à la décision en deux grandescatégories :

1. L’aide à la décision mono décideur : un décideur se forge une opinion en fonctiondes informations mises à sa disposition (dont celles issues de l’expertise), ainsi que de sesorientations (valeurs) personnelles.

2. L’aide à la décision multi décideurs : est le fait d’être plusieurs à décider ayant chacun unpoint de vue souvent divergent par rapport aux autres qui peut faire l’objet de la négociation.

La présente étude s’inscrit dans le cadre du deuxième cas, dans ce qui suit, nous allons présenterquelques situations décisionnelles proposées par les auteurs dans des travaux de recherche dans lecadre de l’aide à la décision de groupe dans différents domaines.

Auteurs et références Travail de recherche Domained’application

M.HEMAISSIA,A.ELFALLAH,SEGHROUCHNI,C.LABREUCHE etJ.MATTIOLI [58]

Modélisation des acteurs affectés par la décisionde groupe via la technologie agent. Modélisationdes préférences des acteurs grâce à l’intégrale deChoquet.Définition d’un protocole de négociation multila-térale et multidimensionnel basé sur la médiationpermettant de trouver un consensus acceptablepour un groupe d’agents.

Gestion decrises

S.OUFELLA etD.HAMDADOU [89]

Modélisation des acteurs impactés par la décisionde groupe via le paradigme agent.Identification des préférences des différents ac-teurs à l’aide de la méthode multicritèreELECTRE III.Définition d’un protocole de négociation multila-térale, inspiré du contract Net Protocol suscep-tible d’aider les agents (acteurs) à trouver un ac-cord acceptable qui puisse les satisfaire.

Aménagementdu territoire

D.HAMDADOU etT.LIBOUREL [53]

Proposition d’un système d’aide à la décisionde groupe multicritères pour l’aide au diagnos-tic (DIAG-GDSS), un outil collectif de prise dedécision basé sur un ensemble de critères et deméthodes de diagnostic et un protocole de négo-ciation multilatérale, ajoutée à une méthode mul-ticritères à savoir ELECTRE III pour classifier lesdifférentes méthodes de diagnostic.

Diagnostique in-dustriel


OKUMURA, MIKOTO,FUJITA KATSUHIDE,ITO TAKAYUKI [88]

Proposition d’un système d’aide à la décisionpour traiter une problématique bien spécifiquequi est la conception et le choix d’un parc tout enconservant et protégeant la planète du réchauf-fement climatique. Basé sur les systèmes multiagents, ce système utilise les agents pour obtenirde l’information des utilisateurs, le protocole vaaider à choisir l’espace à attribuer, ce dernier estmulti attributs mais ne propose pas aux utilisa-teurs de se rétracter et de changer leurs préfé-rences.


I.IGOULALENEL.BENYOUCEF etM.TIWARI [62]

Utilisation d’une approche hybride basée sur laméthode Topsis et la mesure de possibilité. L’ex-ploitation de la méthode multicritères TOPSIS(Technique for order of preference by similarityto ideal solution) floue pour l’établissement d’unclassement des alternatives.La recherche de consensus se fait via la théorie despossibilités et des ensembles flous qui permet auxdecideurs ayant des préférences contradictoires detrouver un consensus sur l’ensemble des alterna-tives.

Problème desélection leschaines logis-tiques

F. LANG et A. FINK [70] Proposition d’un système d’aide à la décisionpour la sélection de protocole de négociation(DSS-NPS) qui est basé sur une approche d’ap-prentissage automatique ; un réseau neurologiqueartificiel pour faire des prévisions sur la repré-sentation d’un protocole de négociation pour unscénario donné, qui est censé apprendre des mo-dèles et des connexions entre la représentationd’un protocole et les caractéristiques du protocoleet du scénario de négociation.

Apprentissageautomatique


M.MORGE etP.MANCARELLA [82]

Proposition d’un outil appelé MARGO, qui re-présente une aide pour la prise de décision quali-tative à plusieurs attributs, il propose un méca-nisme basé sur l’argumentation pour la prise dedécision, son travail est basé sur l’approche abs-traite de Dung à l’argumentation annulable [36].Cet outil s’adresse aux applications industriellesen effet MARGO a été employé dans l’ArguGRIDprojet pour faciliter la composition dynamique deressources et de services au sein d’une grille decalcul.Les agents sont associés aux fournisseurset aux demandeurs de services. ils englobent lamachinerie logique pour la prise de décision etsont équipés de fonctionnalités pour la négocia-tion. Les agents décident du service qui permet derépondre aux besoins du client,ils créent, gèrentet rejoignent des organisations virtuelles.

E business

D.HAMDADOU etK.BOUAMRANE [54]

les auteurs font la conception et l’élaboration d’unsystème interactif d’aide multicritères à la déci-sion collective pour la localisation ponctuelle spa-tiale en Aménagement du Territoire (AT) sur uncouplage de deux représentations de la réalité :les Systèmes Multi Agents (SMA) et les Systèmesd’Information Géographique (SIG).Le module SMA est doté d’un protocole de négo-ciation basé sur la médiation et l’Analyse Multi-critères d’Aide à la Décision (AMCD) et exploi-tant les avantages offerts par la théorie des jeux.


Table 1.5 – SADG : Travaux connexes

1.8 ConclusionTout au long de ce chapitre, nous avons présenté l’aide à la décision de groupe et tous les

concepts qui se rapportent à cette discipline. En utilisant des systèmes d’aide à la décision degroupe (GDSS) bien élaborés, les décideurs arrivent à un compromis de bonne qualité assurant unaccord mutuellement acceptable et ce de manière simple, rapide et efficace.Néanmoins, dans un GDSS un conflit peut très rapidement survenir entre la multitude de decideurscausé par les intérêts, préférences et points de vue généralement différents voir même opposésde chacun d’entre eux. Ce genre de conflit est géré dans les systèmes multi agents modélisantparfaitement les GDSS.Dans le chapitre suivant, nous aborderons en détails la négociation dans les systèmes multi agentscelle-ci est une gestion des conflits suscités lorsqu’interviennent plusieurs acteurs pour la prised’une décision. Cette dernière devient plus compliquée lorsqu’il y a plusieurs critères à prendreen considération. Nous présenterons la notion d’agent, tous les aspects de la négociation et lesdifférentes approches de cette dernière.

Chapitre 2

La négociation dans les SystèmesMulti Agents

2.1 IntroductionLa notion d’agent est utilisée dans beaucoup de domaines : sociologie, biologie, psychologie

cognitive, psychologie sociale, etc. Et aussi dans l’informatique où les agents peuvent être humainsou logiciels, un groupe d’agents forme un système multi agents. Les systèmes multi agents sontdevenus, depuis quelques années, la base de nombreux travaux et sont étudiés dans de multiplesdomaines comme l’intelligence artificielle distribuée ou même dans la robotique le point d’étudeprincipal entre les agents, la communication et la coopération. Dans certains systèmes, les agentssont utilisés pour coopérer entre eux et ce pour un but commun mais ce cas n’est pas tout letemps réalisable car il arrive que les agents sont en conflit ce qui fait appel nécessairement à lanégociation.

2.2 Les agents et les systèmes multi agentsLes systèmes multi agents possèdent des propriétés que nous jugeons nécessaire d’introduire.

Nous allons d’abord définir les agents et les systèmes multi agents. En effet, il existe une multitudede définitions de ces derniers dans la littérature, cependant celle de Jacques Ferber [40] à proposdes agents et de Wooldridge [126] à propos des systèmes multi agents ont retenu notre attentioncar elles nous paraissent les plus complètes.

2.2.1 Définition d’agent« Une entité physique ou virtuelle qui est capable d’agir dans un environnement, qui exhibe

un comportement autonome et qui peut communiquer directement avec d’autres agents ». Cetteentité est mue par un ensemble de tendances (sous forme d’objectifs individuels ou d’une fonctionde satisfaction, voire de survie, qu’elle cherche à optimiser). Elle possède des ressources propres,dispose de compétences et offre des services, et enfin le comportement de ces entités tend à satisfaireces objectifs, en tenant compte des ressources et des compétences dont elle dispose, et en fonctionde sa perception, de ses représentations et des communications qu’elle reçoit. [40]

Chapitre 2.La négociation dans les Systèmes Multi Agents 28

2.2.2 Typologie des agentsCette section expose les différentes typologies d’agents selon le type de comportement propre à

chacun. Les agents peuvent être réactifs ou cognitifs et des fois les deux en même temps ce qu’onappelle les agents hybrides. A ces types, s’ajoutent les agents BDI (Belief, Desire, Intention) quiviennent résoudre les inconvénients des agents réactifs et cognitifs.

2.2.2.1 Les agents réactifs

La catégorie des agents réactifs, décrite par R. A. Brooks [19], comprend tous les agents dontla représentation de l’environnement n’est que sub-symbolique. Cela signifie que la représentationprovient uniquement des perceptions de l’agent du monde « visible » à l’instant courant.Il n’y a pas de raisonnement à proprement parler dans cette catégorie d’agents puisque l’on estdans une configuration du type stimulus/action : stimulus–> percept–> action. L’agent réagit auxévènements dans l’environnement mais n’a pas de mémoire et ne peut donc ni prendre le passé encompte, ni prévoir au-delà du court terme. Le principe d’un agent réactif permet la constructionde systèmes composés de nombreux petits agents, qui sont des automates. Les interactions desagents entre eux permettent l’émergence de structures d’une couche d’abstraction supérieure quisont potentiellement observables [71]. Leur conception n’est pas si facile du fait de la difficulté deprévoir les phénomènes d’émergences [49].

2.2.2.2 Les agents cognitifs

Contrairement aux agents réactifs, la catégorie des agents cognitifs comprend tous les agentsdisposant d’une représentation symbolique de leur environnement. Les agents cognitifs sont ca-pables de raisonner sur leur représentation symbolique. Il existe des algorithmes pour manier lessymboles, et donc les représentations symboliques, mais ils sont très complexes et limitent lescapacités de ce type d’agents. Très souvent, cette classe d’agents s’inspire de théories de la cog-nition, principalement humaine. Ce sont ces différentes théories de la cognition qui induisent lescomportements des agents [49].

2.2.2.3 Les agents hybrides

En général, la différence entre des agents réactifs et des agents cognitifs peut être expliquée parle compromis efficacité/complexité. La complexité des systèmes réactifs exige le développement denouvelles théories dans le domaine de la coopération, de la communication et de la compréhensionde nouveaux phénomènes telle que l’émergence [66]. L’architecture hybride est, en quelque sorte, uncompromis entre un agent purement réactif et un agent purement cognitif. Cette vision permet deconcilier les capacités intéressantes des deux types d’agents précédents. Dans ce type d’architecture,les agents sont conçus comme étant composés de niveaux hiérarchiques qui interagissent entre eux.Chaque niveau gère un aspect du comportement de l’agent [23].

– Au plus bas niveau de l’architecture, on retrouve habituellement une couche purement réac-tive, qui prend ses décisions en se basant sur des données brutes en provenance de l’environ-nement.

– La couche intermédiaire fait abstraction des données brutes et travaille plutôt avec une visionqui se situe au niveau des connaissances de l’environnement.

– Une couche supérieure se charge des aspects sociaux de l’environnement, c’est-à-dire duraisonnement tenant compte des autres agents [90].


2.2.2.4 Les agents BDI (Belief, Desire, Intention)

L’architecture BDI est un modèle d’architecture pour les agents basé sur trois concepts, ouattitudes mentales, qui sont la croyance, le désir et 1’intention. Ces trois concepts déterminent larationalité particulière d’un type d’agent que l’on peut qualifier d’intelligent. Pour M. Bratman[18], ces trois concepts sont également centraux dans la théorie de la cognition sur laquelle se base1’architecture BDI, qui émet 1’idée que les intentions jouent un rôle à part entière dans un raison-nement dit pratique basé sur des croyances et des désirs. Ce type de raisonnement pratique permetde limiter les choix qu’un humain ou un agent peut faire à un moment donné. Rao et Georgeff [95]décrivent les trois concepts de cette architecture comme suit [GRO, 13] :

– B pour Belief, ou Croyance en français. Les croyances d’un agent sont tout simplementl’ensemble des connaissances que l’agent a sur son environnement. Le terme connaissanceest abusif car ce sont des informations sur l’environnement qui sont issues des percepts del’agent, et donc dépendent des capteurs. Ces informations peuvent donc ne pas être vraies oucorrectes, mais le cycle cognitif de l’agent lui permet de mettre à jour ces informations pourque ses croyances sur son environnement soient les plus correctes et complètes possibles, par1’intermédiaire de ses perceptions et de ses actions.

– D pour Desire, ou Désir en français. Les désirs d’un agent sont les états que l’agent cherche àatteindre. Ces états peuvent être ceux de l’environnement ou bien ceux de l’agent lui-même.Ces désirs sont l’ensemble des buts décrits dans la théorie résumée plus haut, et sont doncla raison d’être de l’agent basé sur une architecture BDI. Il est intéressant de noter que lesdésirs peuvent être contradictoires (comme vouloir manger et vouloir dormir), auquel cas leraisonnement permettra d’affiner les désirs afin de les rendre consistant.

– I pour Intention. Les intentions sont les choix d’actions décidés à l’issue de chaque cyclecognitif Les désirs ne peuvent être réalisés que si l’agent planifie des actions pour les réaliser,lors du raisonnement. Bien entendu, tous les désirs ne peuvent pas être réalisés au mêmemoment même s’ils sont consistants, et les intentions permettent d’ordonner la satisfactionde ces désirs, ou autrement dit la réalisation des objectifs.

L’architecture BDI permet donc de concevoir des agents dont le comportement est téléonomiquedu fait de l’intégration de la notion d’intentions. Les agents ainsi conçus étant du type cognitif carbasés sur une théorie de la cognition, on peut dire que les agents BDI sont des agents intentionnels[49].

2.2.3 Les systèmes multi agentsWooldridge [126] définit les systèmes multi agents comme suit : « Un ensemble d’agents en

interaction afin de réaliser leurs buts ou d’accomplir leurs tâches. Les interactions peuvent êtredirectes par l’intermédiaires des communications, comme elles peuvent être indirectes à traversl’action et la perception de l’environnement ».

A partir du moment où un système possède plus d’un agent, des interactions guidées par lesbuts, les ressources et les compétences de chaque agent sont possibles, ces interactions ont étéclassifiés en 3 principales catégorie [38] :

1. L’indifférence : pas d’interactions entre les agents du fait qu’ils ont :


– des buts indépendants (compatibles et travails individuels), autrement dit leurs buts nesont pas en conflits.

– des ressources suffisantes.

– des capacités requises.

2. l’antagonisme : un agent est dans une situation d’antagonisme avec un autre si leurs butssont en contradiction ou incompatibles, en d’autre terme si on a deux agents A et B tels que :

but(A)⇒ ¬but(B) (2.1)

Si le but de A est réalisé alors le but de B ne peut pas se réaliser.

3. la coopération : un agent doit coopérer avec d’autres agents du fait :

– qu’il n’est pas capable d’accomplir seul une tâche (il lui manque des ressources et/ou ilne possède pas des capacités).

– que le travail avec les autres est plus efficace.

2.3 La coopérationEn guise de définition pour la coopération, Ferber [40] propose la formule suivante : Coopéra-

tion = collaboration + coordination d’actions + résolution de conflits Il explique que le problèmede la coopération peut se ramener à « qui fait quoi, de quelle manière et avec qui ?».

– La collaboration : consiste à travailler à plusieurs sur un projet, une tâche commune. C’estl’ensemble des techniques permettant à des agents de se répartir des tâches, des informationset des ressources, de manière à réaliser une œuvre commune. Résoudre un problème decollaboration consiste donc à répondre à la question « qui fait quoi ? » par rapport à untravail donné [40].

– La coordination d’actions : c’est l’ensemble des activités supplémentaires qu’il est néces-saire d’accomplir dans un environnement multi agents et qu’un seul agent poursuivant lesmêmes buts n’accomplirait pas [73].

– La résolution de conflits : consiste en la recherche et le choix d’une solution à un affron-tement, plusieurs méthodes pour parvenir à un accord existent dans la littérature.

La résolution de conflit peut être classée en deux grandes familles, celle qui inclut la négociationet une autre qui ne le fait pas.Nous allons décrire, dans la section suivante, la deuxième catégorie et détailler par la suite lanégociation.

2.4 La résolution de conflits n’incluant pas la négociationLes processus des résolutions de conflits qui n’incluent pas la négociation sont très simples

mais ne sont pas très souvent utilisés ou implémentées, c’est pour cela que nous n’aborderons quebrièvement ces méthodes.


2.4.1 Take it or leave it offerEn français « à prendre ou à laisser », Cette forme de résolution de conflit est très primaire,

puisqu’elle consiste à formuler une proposition qui est à prendre ou à laisser par le ou les parti-cipants. Cette méthode se déroule sur un seul tour, sans contre-proposition. C’est celle que l’onrencontre tous les jours pour acheter son pain, par exemple. Elle ressemble aux offres scellées aumeilleur et au second meilleur prix, la différence vient du fait que dans les enchères, le prix estproposé par les acheteurs, tandis que dans le take it or leave it offer, c’est le vendeur qui proposeun prix ferme. Le protocole est donc très simple : le vendeur propose sa ressource (bien, service,etc.) à un prix ferme à un acheteur qui soit accepté, soit refuse. S’il accepte, l’acheteur paie le prixpour obtenir la ressource [120].

2.4.2 One Step ProtocolEn français « Protocole à une étape », Comme son nom l’indique, ce protocole essaie de trouver

un accord entre deux agents en effectuant un seul tour uniquement. Dans le cas de deux agentsseulement, chacun émet sa proposition, et ainsi chacun d’eux dispose de deux propositions (cellequ’il a envoyé et celle qu’il vient de recevoir de l’autre agent). Les agents doivent accepter laproposition qui maximise le produit de leurs utilités, s’il y a une égalité, ils coordonnent pourchoisir une aléatoirement. La meilleure stratégie que peut utiliser un agent est de trouver lesactions qui maximisent le produit des utilités, et à partir de ces actions, choisir celui qui maximisesa propre utilité [12].

2.4.3 Les enchères sans négociationIl existe plusieurs types dont les plus utilisés sont [13] :

– Les offres scellées au meilleur prix : ces enchères sont aussi parfois appelées enchèrespremier prix offres cachées. Chaque participant soumet une offre sans connaitre les offres desautres. Celui qui fait la plus grande, gagne l’objet et paie le montant de son offre.

– Les offres scellées au second meilleur prix ou enchères de Vickrey : ces enchèressont aussi parfois appelées enchères deuxième prix offres cachées. Chaque participant soumetune offre sans connaitre les offres des autres. Celui qui fait la plus grande, gagne l’objet etpaie le montant de la seconde meilleure offre proposée [121].

2.4.4 Les systèmes de voteLe problème de vote s’énonce comme suit : on demande à tous les agents de proclamer leurs

préférences sur un ensemble de candidats, on compte ensuite leurs votes pour trouver le candidatpréféré. Plusieurs méthodes ont été proposées pour déterminer le candidat préféré, certaines sontsimples mais ne reflètent pas les préférences réelles des votants. Quelques exemples de ces méthodessont décrits dans ce qui suit [122] :

– La méthode Condorcet : La méthode Condorcet (ou vote Condorcet) est un système devote dans lequel, l’unique vainqueur est celui, qui comparé tour à tour à tous les autres can-didats, s’avèrerait à chaque fois être le candidat préféré. Chaque électeur classe les candidatspar ordre de préférence. Pour chaque paire de candidats, on détermine le nombre d’électeursayant voté pour l’un ou l’autre. Ainsi pour chaque pair, il y a un candidat vainqueur. Dans laplupart des cas, il y a un unique candidat qui remporte tous ses duels : il s’agit du vainqueurdu scrutin. Dès que le nombre de candidats dépasse deux, on peut se trouver dans ce qu’on


appelle le paradoxe de Condorcet, qui résulte d’une préférence circulaire entre les candidats,cette situation est résolue en utilisant plusieurs méthodes.

– La méthode de Hare : Cette procédure a été proposée par Thomas Hare en 1861, leprincipe général est de déterminer le choix social en éliminant successivement les alternativesles moins désirées [120] :

– Si une alternative est classée première sur au moins la moitié des listes de préférences,alors c’est le choix social et la procédure se termine.

– Si aucune alternative n’est classée première sur au moins la moitié des listes, alors onsélectionne l’alternative classée première sur le moins de listes et on l’enlève de toutesles listes. Si plusieurs alternatives sont à égalité, on les enlève toutes des listes. Lesalternatives qui suivaient celles qui ont été enlevées sur les listes gagnent alors uneplace.

– On recommence la procédure jusqu’à ce qu’une alternative apparaisse en premier sur aumoins la moitié des listes ou si toutes les alternatives restantes apparaissent en premiersur exactement le même nombre de listes.

– La méthode de Borda : dans cette méthode, on procède comme suit :

– Avec x choix, on affecte x points au candidat préféré, x-1 au deuxième candidat préféré,et ainsi de suite.

– Le candidat qui obtient le plus grand nombre de points remporte le vote.

– La Dictature La dictature a pour but de montrer qu’une procédure de choix social n’est pasforcément démocratique. Cette méthode consiste à désigner une personne parmi l’ensembleP et de l’appeler dictateur. Le choix social est alors l’alternative classée première sur la listedu dictateur [120].

– Le Scrutin uninominal majoritaire à un tour (pluralité) Cette méthode simple consisteà nommer choix social, l’alternative étant classée première le plus grand nombre de fois parmiles listes de préférences des votants (majorité relative).C’est le système de vote classique parexcellence utilisé dans les élections politiques pour élire le président du Mexique, du Kenyaou encore de l’Islande (en France, on utilise deux tours) [120].

2.4.5 La délibérationLa délibération est une confrontation de points de vue visant à trancher un problème ou un

choix difficile par l’adoption d’un jugement ou d’une décision réfléchie. Elle peut être effectuéepar un individu seul, mais aussi par un groupe d’individus ou une collectivité [130] Qui selon lecontexte :

– Est bien une discussion entre les parties concernées par l’objet discuté (par exemple lors d’unconseil d’administration), mais qui consiste à effectuer un choix. La délibération est parfoisprécédée ou entrecoupée de phases de négociation, mais nous considérons qu’elle n’est pas enelle-même de la négociation,

– Aboutit à un verdict (d’un juge par exemple). Les parties concernées s’en remettent à uneautre pour trancher, la décision n’est pas forcément une de celles évoquées durant les discus-sions qui ont précédé. On rapprochera ces situations à de l’arbitrage. En SMA, on peut citerle système PERSUADER , [114] qui met en jeu un médiateur.


2.5 La résolution de conflit incluant la négociationDans les sections suivantes, nous allons aborder les différents types de négociation automatique,

elles seront dans un ordre hiérarchique du plus simple, au plus évolué, une telle hiérarchisationpeut se faire grâce au type d’objet que l’on veut négocier (le nombre d’attributs, le niveau deprofondeur, etc.) ou bien grâce au niveau de sémantique des agents qui l’utilisent, mais avant celanous définirons tous ses aspects se rapportant à la négociation.

2.5.1 La négociationAvant d’aborder les différentes méthodes de résolution de conflits, nous abordons quelques

concepts de base de la négociation dans les SMA.

2.5.1.1 Définition

« Negotiation is a process by which a joint decision is made by two or more parties. The partiesfirst verbalise contradictory demands and then move toward agreements » [94]. L’origine de cettedéfinition étant américaine, sa traduction est : « La négociation est un processus par lequel unedécision conjointe est prise par deux parties ou plus. Les parties verbalisent en premier lieu leursexigences et convergent vers un accord final ». La négociation réunit un ensemble de participantset un initiateur et se déroule jusqu’à ce qu’un accord satisfaisant soit atteint ; un pourcentage departicipants.

La définition de Floch [46] nous parait être la plus complète et la plus générale du fait qu’elleaborde toutes les facettes de la négociation :« La négociation est un processus de recherche d’accordsur un objet, entre plusieurs parties ayant des préférences différentes mais susceptibles d’évoluer,et qui implique des interactions permettant de modifier à la fois la plage de possibilités et les pré-férences de chacun sur les possibilités. »

En d’autres termes, la négociation naît donc de préférences différentes (non accord) et n’aboutitpas forcément à un accord. Le résultat est une prise de décision commune des parties sur lesmodalités de l’accord, si la négociation aboutit ; ou un désaccord, si elle échoue.

2.5.1.2 Les éléments de la négociation

Muller dans [84] définit trois éléments fondamentaux dans la négociation :

1. Les langages : ils comportent des primitives de communication pour la négociation, leurssémantiques, et leurs usages dans les protocoles. Les primitives concernent les envois et récep-tions de messages et intègrent des actes illocutoires. La structure de l’objet de la négociationfait appel à un langage de description de l’objet. Le protocole spécifie les séquences possiblesd’actions et les conditions suivant lesquelles une requête peut être effectuée.

2. Les processus de négociation : qui peuvent être, soit des procédures préétablies, soit descomportements. Le processus concerne la proposition de solutions, l’analyse et la révision dessolutions préférables.

3. Les décisions individuelles : qui peuvent être prises en fonction de critères d’utilité, destratégie, de systèmes de préférences, d’une fonction de comparaison et de mise en corres-pondance.

La figure ci-dessous illustre les différents éléments de la négociation et résume les notions définiesdans les sections précédentes.


Figure 2.1 – Les différents éléments d’une négociation et leurs structures

2.5.1.3 Les types de la négociation

Dans la littérature, la négociation est classée en deux grands types, selon la conduite desnégociateurs [46] :

1. La négociation intégrative, (aussi parfois appelée négociation coopérative) conduit géné-ralement à un accord dans lequel les deux parties s’estiment gagnantes (gagnant-gagnant).Les agents prennent en compte les intérêts de chacun dans leur décision : ils poursuiventun but commun et la négociation leur permet de se coordonner. Il s’agit d’une recherchedistribuée dans un espace de solutions.

2. La négociation distributive, (aussi parfois appelée négociation compétitive ou conflic-tuelle) permet de résoudre un conflit. Chaque agent négociateur poursuit des buts individuelset cherche à être le gagnant de l’échange. Chacun campe sur ses positions et la négociation estvue comme une confrontation. L’accord risque d’être gagnant-perdant, voire perdant-perdant.

Simos [112] propose de situer ces deux types de négociation en définissant les limites :

– L’affrontement : seul le rapport de force joue, il y a recherche de la soumission totale del’adversaire.

– L’entente : les interlocuteurs oublient leurs intérêts propres et se retrouvent en situation derésolution de problèmes, c’est-à-dire ils vont rechercher une solution optimale (du point devue mathématique).

2.5.1.4 La notion de protocole

La modélisation des communications entre agents utilise la notion de protocole. Les auteursdans [9] définissent un protocole comme : « l’ensemble des règles qui gouvernent l’interaction ».Les protocoles définissent l’ensemble de séquences valides des messages qui peuvent être échangésentre les agents. Les protocoles peuvent être formalisés à l’aide de différents outils comme, parexemple, les réseaux de PETRI ou les automates état-transition.


2.5.1.5 La taxinomie hiérarchisée des processus de résolution de conflit

Dans ce qui suit, nous présentons les méthodes dites de négociation en les définissant selonleurs types et en précisant la particularité de chacune d’entre elles de la plus simple vers la pluscomplexe. La figure 2.2 regroupe toutes ces méthodes et les classe en deux grandes catégories : lesméthodes qui incluent la négociation et celles n’incluant pas la négociation.

Figure 2.2 – Taxinomie des processus de résolution de conflit

2.5.1.5.1 La négociation simple Elles sont souvent implémentées dans différentes plate-formes que nous ne détaillerons pas du fait qu’elles n’ont pas de rapport direct avec notre thème.Elles ont toutes comme particularité de faire une négociation sur un objet unique et simple (n’aqu’un seul attribut et qu’un seul niveau). Elles sont souvent utilisées comme base pour d’autrestypes de négociation plus complexes. Nous allons citer quelques exemples :

A Le Contract Net Protocol

De nombreux travaux s’appuient sur le modèle général du Contract Net Protocol [113], qui estconsidéré comme le précurseur des travaux en négociation automatique. Il s’agit d’un protocolefondé sur l’échangeur de contrats, qui met en relation un agent : le gestionnaire (manager), avecplusieurs autres agents : les contractants (contractors). Il s’agit de négociation de 1 vers n agents,qui interagissent entre eux.

Un contrat peut être élaboré entre deux participants : un contractant et le gestionnaire. Lecontractant est garant de l’exécution de la tâche et de la transmission de ses résultats au ges-tionnaire. Le gestionnaire, quant à lui, se porte garant de la gestion de la tâche et du traitementdes résultats. C’est pourquoi ce modèle peut être vu comme un protocole d’allocation de tâches


par réseau contractuel. Le Contract Net fait partie des spécifications de la FIPA (Foundation forIntelligent Physical Agents) qui propose également une version itérée [46].

Le protocole se déroule en quatre principales étapes comme suit référence :

1. Annonce de la tâche par le gestionnaire ;

2. Soumission d’une offre par un ou des contractants ;

3. Attribution de la tâche à un contractant par le gestionnaire ;

4. Transmission du message de fin de tâche au gestionnaire par le contractant ;

Le Contract Net est pionnier et constitue une référence parmi les protocoles de négociation. Il a faitl’objet de nombreuses extensions, qui ont apporté des améliorations comme la possibilité d’effectuerdes contre-propositions, des envois d’informations entre agents et l’itération des demandes, etc.

B Le protocole de concession monotone

Ce protocole procède en tours, il suppose que chaque agent i soit doté d’une fonction d’utilitéU telle que référence :

Ui : X → R+0 (2.2)

Où X est l’ensemble des ressources (actions ou choix possibles), qui à chaque ressource possibleaffecte une valeur réelle, plus cette valeur est grande, plus la ressource en question est préférée parl’agent i.Dans le premier tour, tous les agents doivent faire des propositions, et chaque agent est libre defaire n’importe quelle proposition, donc logiquement, chaque agent choisi la proposition qui maxi-mise son utilité (intérêt). Dans les tours ultérieurs, l’identification des agents qui doivent faire uneconcession (faire des propositions) est faite comme suit [12] :

– Dans le cas où deux agents seulement sont impliqués dans la négociation, a proposéune mesure qui évalue l’empressement respectif des agents au risque de conflit (willingnessto risk conflict), et l’agent dont la valeur est la plus petite pour cette mesure doit concéder[126]. En cas d’égalité, les deux concèdent. Cette mesure se calcule en fonction des utilitésdes deux agents comme suit :

Zi = (Ui(xi)− Ui(xj))/Ui(xi) (2.3)

Où xi est la proposition la plus récente faite par l’agent i. Cette stratégie est efficace dans lesens qu’elle mène à un accord qui maximise le produit des utilités [37].

– Dans le cas où plusieurs agents sont impliqués dans la négociation, plusieurs stra-tégies ont été définies pour identifier les agents qui doivent concéder dans un tour donné, ontrouve entre autres : la stratégie du produit croissant des utilités (Product-increasing Stra-tegy) qui choisit l’agent qui a dernièrement fait une proposition dont le produit des utilités(de tous les agents) est le plus faible [37].

Concernant le choix de la ressource en cas de concession, il peut se faire de plusieurs manières, ontrouve entre autres [37] :

– La concession de PARETO : proposer une ressource qui soit aussi bonne pour tous lesautres agents, et strictement mieux pour au moins un d’entre eux.


– La concession Utilitaire : proposer une ressource qui mène à une augmentation dans lasomme des utilités des agents d’une itération à une autre (bien-être social utilitaire)

– La concession Egalitaire : proposer une ressource telle que l’utilité minimale parmi tousles agents augmente d’une itération à une autre (bien-être social égalitaire).

– La concession de NASH : proposer la ressource qui maximise le produit des utilités desagents d’une itération à une autre.

Ces stratégies assurent la convergence du processus de concession vers un accord qui satisfaittout le monde.

– Accord est atteint si et seulement si un agent i fait une proposition Xi qui soit au moinsaussi bonne pour tout autre agent j.

– Un conflit se produit lorsque tous les agents qui doivent concéder dans une itération donnéerefusent de le faire. Un agent refuse de faire une concession parce qu’il n’est pas en mesurede proposer une ressource qui respecte une des méthodes de concession décrites plus haut(concession de Pareto, utilitaire, etc.).

Le protocole se déroule jusqu’à ce qu’un accord soit atteint ou un conflit se produise, dansce dernier cas, la négociation se termine par ce qu’on appelle un accord de conflit. Ce dernier estdéfinit comme suit : on choisit parmi toutes les ressources proposées dans les itérations précédentes,celle qui maximise le produit des utilités des agents.

2.5.1.5.2 Les négociations multi-attributs Les négociations multi-attributs, comme leurnom l’indique, sont des négociations qui impliquent différents attributs devant être négociés. Ellessont directement opposées aux enchères qui n’impliquent qu’un seul attribut : un prix. Cette formede négociation est, cependant, très répandue et à la base de nombreuses variantes de négociation.Un exemple de négociation multi-attributs est la négociation d’une voiture chez un concessionnaire.Le modèle, la motorisation, la couleur et de nombreuses options comme la climatisation, la directionassistée ou encore la présence d’airbags, en plus du prix, seront négociés [120].

A Le protocole de SIAN

Ce protocole de négociation a été conçu au sein de MALE (Multi-Agent Learning Environment)par Sian [109]. Il s’agit de permettre à un système multi agent d’interpréter les événements del’environnement. La perception du système est distribuée et les agents négocient pour adopter uneinterprétation commune de l’environnement. Les agents proposent des hypothèses, et pour chacune,il existe trois phases :

1. Génération de l’hypothèse.

2. Discussion entre les agents pour se mettre d’accord sur l’hypothèse.

3. Intégration de l’accord.

Les agents communiquent via un tableau noir. Les propositions sont inscrites sur le tableauet chaque agent peut les lire, les accepter, les refuser ou les modifier. Ici, les agents ont tous lemême objectif : trouver une bonne interprétation de la situation. Avec sa perception locale del’environnement, chaque agent va proposer des hypothèses. Les agents mettent en commun leurshypothèses, et n’ont pas d’intérêts conflictuels. La discussion aboutit forcément à un accord, quiconsiste en accepter ou retirer l’hypothèse du tableau.


B Le protocole proposé par Sarah Oufella

Ce protocole s’inspire largement du Contrat Net Protocol, il est organisé en tours et est répartientre un ensemble d’agents participants, et un agent coordinateur qui se charge d’orchestrer lanégociation dans son ensemble [89]. Chaque agent participant détient un vecteur trié, selon sespréférences, des actions potentielles, en plus, chaque agent dispose d’un compteur, qui pointe surson choix dans une itération donnée, la valeur de ce compteur s’incrémente à chaque itération.

Dans chaque itération, l’initiateur propose un contrat à tous les participants concernant uneressource donnée, les participants vont soit accepter ce contrat soit le refuser et ceci en se référantà leur vecteur de préférences construit précédemment. Un agent accepte le contrat proposé parl’initiateur s’il correspond à son choix dans l’itération en cours, ou si ce contrat a été précédemmentfait par l’agent. Lorsque l’initiateur reçoit toutes les réponses des participants, il comptabilise lenombre d’agents participants ayant accepté sa proposition. Si ce nombre est supérieur ou égal àun certain seuil alors la négociation est un succès sinon, il doit procéder à une modification ducontrat. En cas où la majorité refuse le contrat proposé, l’initiateur le modifie en s’inspirant despropositions des participants. Il doit établir une synthèse à partir de ce qu’il a reçu lors de la phased’évaluation puis un nouveau cycle commence.

2.5.1.5.3 Les négociations multi-niveaux C’est un type de négociation où le contrat sedécompose en plusieurs ”sous-contrats”, dépendant les uns des autres [30]. La négociation s’effectue,séquentiellement, pour chaque sous- contrat, la réussite globale est atteinte lorsque tous les sous-contrats ont été négociés avec succès.Lorsqu’un sous-contrat est en cours de négociation et qu’aucune solution n’est possible, on effectueun retour arrière pour la négociation du sous-contrat précédent. Par exemple, pour la prise derendez-vous, on peut décomposer le contrat en recherche d’un jour, puis d’une heure dans ce jour[120].

2.5.1.5.4 Les négociations combinées Les négociations combinées sont utilisées lorsqu’unepersonne a besoin d’un ensemble d’objets non disponibles auprès d’un unique vendeur. Il faut alorsnégocier chaque objet (ou sous ensemble d’objets) séparément et avoir un mécanisme de liaisonentre les négociations, car si l’ensemble des objets ne peut être acquis, aucun objet ne doit l’être.De plus, il ne faut obtenir chaque item qu’en un seul exemplaire. Les différentes négociationssont indépendantes les unes des autres, alors que l’ensemble des objets négociés sont typiquementinterdépendants.Les négociations peuvent être de type différent pour chaque objet ou sous-ensemble d’objets. Unexemple type de négociation combinée est la composition d’un voyage. Pour obtenir un voyage,il faut un moyen de transport (par exemple, un vol aller-retour vers la destination choisie) et lesnuits d’hôtel pour la période du voyage [120].

2.5.1.5.5 La négociation à base d’argumentation L’argumentation en intelligence arti-ficielle est un processus cognitif qui repose d’abord sur la construction d’arguments puis sur lasélection des arguments les plus acceptables en fonction de leurs interactions [92].

La négociation par argumentation est une approche qui permet aux agents, de justifier leursoffres et leurs points de vue, de remettre en question les offres des uns et des autres à travers unéchange d’arguments qui leur permettent de s’influencer mutuellement [115]. Cette approche offreune grande flexibilité puisqu’il est possible pour les agents d’exprimer leurs réactions quant au rejetou à l’acceptation des offres proposées, en échangeant des informations explicatives. Par exemple àtravers un argument un agent peut donner les raisons précises pour lesquelles il refuse une offre, ce


qui peut amener son adversaire à modifier ses prochaines propositions en conséquence. De même,un agent peut influencer l’avis de son adversaire et l’amener à accepter une offre en la soutenant(ou justifiant) par un bon argument.

Sycara [114] a souligné l’intérêt de l’argumentation dans les processus de négociation et enparticulier la nécessité d’appuyer les offres par des arguments pendant une négociation.

En effet, une offre soutenue par un bon argument a une meilleure chance d’être acceptée par unagent et peut également amener un agent à dévoiler ses buts, abandonner certains buts et à réviserses préférences. Il existe plusieurs systèmes basés sur l’argumentation dont les plus importants sontles systèmes ANA et PERSUADER [90].

A Le protocole SANP

Le protocole SANP (Speech Act Based Negotiation Protocol) a été définit par Chang et Woo[26]. Il propose une négociation entre deux agents : L’attaquant et le défenseur. L’agent initiant laconversation est appelé l’attaquant : il va tenter de faire accepter sa proposition à son partenaire,appelé le défenseur. Le protocole se décompose en plusieurs phases :

1. Situation de départ : les agents établissent un modèle commun du sujet et estiment si unediscussion est nécessaire.

2. Emission d’une proposition et réception de l’avis : l’attaquant émet sa proposition etle défenseur lui répond par son accord ou son refus.

3. Attaque : si le défenseur refuse la proposition, l’attaquant va émettre ses arguments.

4. Phase tactique : le défenseur va défendre sa position et l’attaquant essayer de la contrer pardes arguments. Ce processus continue jusqu’à ce qu’ils identifient leurs différences et tententde les réduire.

5. Résolution du problème : chaque partie propose un compromis et tente de contrer celuide l’autre.

6. Résultat final : le résultat de la négociation peut être le compromis d’une partie, un com-promis mutuel ou une demande d’arbitrage par une tierce partie.

A chaque phase, correspond un ensemble de stratégies suivant le raisonnement de l’agent.Le protocole est inspiré de la théorie des actes de langage en linguistique et la recherche sur lanégociation en sociologie. Les auteurs se basent sur le Struggle Model et l’Institutional Modeldécrits dans [8].

2.5.1.6 L’approche de la théorie des jeux

La théorie des jeux est l’approche mathématique de l’étude des conflits d’intérêts. Elle a connuun essor important après la publication, en 1944, de l’ouvrage Théorie des jeux et du comportementéconomique de Von Neumann et Morgenstern [124] .

Von Neumann, mathématicien à l’Institut « Advanced Study », et Morgenstern, économisteà l’université de Princeton, sont considérés comme les fondateurs de la théorie des jeux, qui n’adepuis jamais cessé d’évoluer. Le mathématicien John NASH a également été très actif. Les outilsde la théorie des jeux sont aujourd’hui utilisés en économie, et également dans des sciences commela sociologie, la psychologie, la biologie, les sciences politiques, et l’informatique, dans lesquelles


l’étude des situations de conflits est pertinente. Nous allons présenter succinctement, quelquesconcepts de la théorie des jeux.

2.5.1.6.1 Le dilemme du prisonnier C’est une célèbre illustration de l’incompatibilité entrel’intérêt individuel et l’intérêt collectif [46] : Deux individus sont arrêtés par la police et empri-sonnés dans des cellules séparées. La police fait à chacun la même proposition : « Tu as le choixentre dénoncer ton complice ou rester muet. Si tu le dénonces et qu’il te dénonce aussi, vous au-rez chacun deux ans de prison. Si tu le dénonces et que ton complice te couvre, tu sortiras et luiprendra trois ans de prison. Si vous vous couvrez mutuellement, vous prendrez tous les deux un an.»

Dans cette situation, il est clair que si les deux restent muets, ils s’en tireront globalementmieux que si l’un des deux dénonce l’autre. Mais l’un peut être tenté de s’en tirer encore mieuxen dénonçant son complice. Le dilemme est faut-il accepter de couvrir son complice (C commecoopérer) ou le trahir (D comme dénoncer).Il existe des versions itérées du dilemme où un joueur peut se souvenir du comportement de l’autreà son égard et développer une stratégie en rapport (par exemple, si l’adversaire d’un joueur necoopère jamais, son intérêt sera de ne pas coopérer non plus).

C DC 1 an, 1 an 3 ans, 0 anD 0 an, 3 ans 2 ans, 2 ans

Table 2.1 – Les différents niveaux de décision

2.5.1.6.2 L’équilibre de NASH Nash [86] a été le premier à présenter une définition d’unestratégie optimale pour un jeu à plusieurs joueurs, dite équilibre de Nash. L’équilibre de Nashcaractérise la rationalité individuelle. Il s’agit d’une combinaison stratégique où chaque joueurjoue sa meilleure réponse quel que soit le choix de l’adversaire. C’est une stratégie de non regret.Le prisonnier qui dénonce prend au pire deux ans de prison, et au mieux sort de prison. Pour ledilemme du prisonnier simple, D/D est la seule combinaison stratégique en équilibre de Nash.

2.5.1.6.3 La PARETO-Optimalité PARETO, sociologue et économiste, a défini l’optimumde Pareto qui caractérise la rationalité collective. C’est une situation dans laquelle un individu nepeut améliorer sa situation sans détériorer celle d’un autre individu.Les trois issues C/C, C/D, D/C sont Pareto-optimales, car dans chacune, il est impossible d’aug-menter le gain d’un des joueurs sans baisser celui de l’autre.D/D n’est pas Pareto-optimale car il existe une issue préférée par les deux prisonniers : C/C.

2.6 Travaux connexesNous présentons dans cette section une liste non exhaustive de travaux de recherche portant

sur la négociation automatisée au sein des systèmes d’aide à la décision et des systèmes multi agents.


Auteurs Travail de recherche RéférencesJ.BENTAHAR etJ.LABBAN

Les auteurs ont développé un protocole de né-gociation dans un système multi agents basé surl’argumentation persuasive. Les agents doivent sepersuader mutuellement de leurs offres jusqu’à ar-river à un accord ou un échec.

[14]

D.HAMDADOU etT.LIBOUREL

Un protocole de négociation multilatéral inspirédu Contract Net Protocol, exploitant la méthodemulticritères ELECTRE III. Ce protocole inclutun coordinateur et un ensemble de participants,qui tentent de trouver un compromis entre les unensemble de décideur, application : Aménagementdu Territoire.

[53]

N.HADIDI Un protocole de négociation dans les systèmesmulti agents basé sur l’argumentation et sur lathéorie des jeux. Cette négociation n’est pas mul-tilatérale mais bilatérale, on ne distingue quel’agent attaquant et l’agent défenseur.

[51]

F.DELECROIX,M.MORGE etJ-C.ROUTIER

Un jeu de négociation bilatérale dans les systèmesmulti agents inspiré de la concession monotone.Les auteurs proposent un protocole à deux stra-tégies : l’une conciliante et l’autre temporisatrice.La stratégie conciliante mène vers un Pareto-Optimal. Le protocole est mono-attribut

[32]

D.HAMDADOU etK.BOUAMRANE

Un protocole de négociation dans un systèmed’aide à la décision collective inspiré du ContractNet Protocol et de la concession monotone basésur la médiation et l’Analyse Multicritères d’Aideà la Décision (AMCD) à savoir ELECTRE III etELECTRE TRI.

[54]

S.OUFELLA Un protocole de négociation à base d’argumenta-tion dans un système multicritères à la décisionde groupe. Muni d’une base de connaissances oùchaque participant, le protocole est capable de gé-nérer des arguments en faveur de ses alternativespréférées. De plus le rejet ou l’acceptation d’uneoffre sont justifiés.

[90]

Table 2.2 – Protocoles de négociations :Travaux connexes

2.7 ConclusionNous avons présenté dans ce chapitre la négociation dans les systèmes multi agents en pré-

sentant en détails les agents et leurs typologies, nous avons vu qu’ils étaient classés selon leurscomportements en trois grandes catégories et une quatrième hybride. Ensuite, nous avons définila notion de système multi agents comme étant un groupe d’agents en interaction entre eux, cette


interaction peut être à travers la communication qui peut mener à un conflit. Le conflit peut êtrerésolu par plusieurs méthodes, ces méthodes peuvent inclure en entre autres la négociation. A cetitre, nous avons détaillé les différentes méthodes de négociation tout en présentant quelques tra-vaux portant sur la négociation.

Notre objectif, par la présente étude, est de proposer un système d’aide à la décision de groupe etun protocole de négociation utilisant les services web assurant la communication entre les décideursà travers une plateforme de communication.A cet effet, nous aborderons dans le chapitre suivant, en détails, l’architecture orientée services etplus précisément les services web. Nous présenterons l’intérêt de ces derniers, leur fonctionnementainsi que les deux principales architectures en mettant l’accent sur la méthode choisie pour élaborernotre plateforme basée sur la négociation et l’analyse multicritères.

Chapitre 3

Les services web

3.1 IntroductionDe nos jours, avec l’interconnexion des ordinateurs en réseau et en particulier à travers internet,

il devient possible de faire fonctionner des applications sur des machines distantes. L’intérêt d’uneapplication fonctionnant à distance peut à première vue sembler inutile dans la mesure où lesapplications fonctionnent fort bien en local (sur le poste de l’utilisateur), néanmoins une applicationdistante peut répondre aux problématiques suivantes :

– Les données peuvent être présentes uniquement sur le serveur distant (par exemple un cata-logue produit, un classement en temps réel, etc.) ;

– Le serveur distant peut disposer d’une puissance de calcul ou de capacités de stockage dontl’utilisateur local ne dispose pas ;

– L’application distante peut être utilisée simultanément par un grand nombre d’utilisateurset sa mise à jour n’intervient qu’à un seul endroit [152].

Pour toutes ces raisons, une interaction entre des programmes distants peut être utile. L’ar-chitecture orientée service est apparue dans les dernières années pour pallier aux problèmes liésau développement des applications distribuées complexes à partir des entités logicielles appeléesservices. L’utilisation de cette architecture permet la communication et l’intégration de plusieursapplications développées dans des environnements hétérogènes [61]. A ce titre, nous présentonsdans ce chapitre l’émergence de l’architecture orientée service SOA (Service Oriented Architec-ture) et les différents acteurs intervenants dans cette architecture. Nous exposerons, par la suitela technologie des Services Web en détaillant toutes les notions pertinentes relatives aux servicesweb et les deux grandes solutions d’accès aux services web à savoir SOAP (Simple Object AccessProtocol) et REST (REpresentational State Transfer).

3.2 L’architecture orientée service SOASOA est un nouveau style architectural qui facilite l’intégration de plusieurs entités logicielles

en les organisant en ensembles fonctionnels appelées services [91]. L’objectif de cette intégration estde réaliser une fonctionnalité dont l’utilisateur a besoin. Cette architecture repose sur un conceptbasique : la notion de service. Un service est une application définie par un contrat, accessible parune interface et offrant une ou plusieurs fonctionnalités. Les services permettent de communiquervia l’échange de messages afin de cacher l’hétérogénéité des environnements de développements

Chapitre 3.Les services web 44

des applications [91], [75], [29]. L’utilisation de l’architecture orientée service a apporté plusieursavantages tels que :

– Le couplage faible : les acteurs partagent entre eux seulement la description de servicesafin de réduire la dépendance entre les applications.

– La substituabilité : en cas d’une mise à jour d’un tel service (exemple retrait d’un service),la SOA permet de le remplacer facilement.

– Facilité d’intégration des services : permet de masquer l’hétérogénéité des plateformesde développement des services en les représentant comme des boites noires.

– Réutilisabilité : un service peut être combiné avec d’autres services afin de réaliser unecertaine fonctionnalité.

– Facilité des communications externes : le client peut communiquer avec des applicatifsexternes à l’entreprise [61].

3.3 Historique sur les services webAvant l’apparition de l’architecture Orienté service et ainsi la mise en œuvre des services web,

il était difficile de mettre d’accord les acteurs majeurs du logiciel sur un moyen de communicationà distance. Leurs précurseurs s’appellent CORBA (Common Object Request Broker Architecture),initialement utilisé par les systèmes Unix et DCOM (Distributed Component Object Model), sonrival Microsoft. À un niveau plus bas, on trouve RPC (Remote Procedure Call) et, plus près dumonde Java, RMI (Remote Method Invocation) mais ils ont généralement échoué en raison de ladiversité des plateformes utilisées dans les organisations et aussi parce que leur usage n’était pasadapté à Internet (problème de passage à travers des FireWalls). Lorsque HTTP est devenu unstandard, il a également obtenu petit à petit le statut de support de communication universel.À peu près en même temps, XML est devenu un standard officiel lorsque le W3C 1 (World WideWeb Consortium) a annoncé que XML 1.0 pouvait être déployé dans les applications. En 1998, cesdeux ingrédients " HTTP et XML " étaient prêts à travailler ensemble et XML-RPC l’ancêtre desServices Web est créé, c’est un vocabulaire XML décrivant des appels et des réponses de procéduresdistantes (RPC). Sous l’influence de Microsoft, XML-RPC est remanié pour être adapté au mondede la programmation orientée objets et le résultat prend le nom de SOAP (SOAP 1.0, novembre99). En 2000, IBM commença à travailler sur SOAP 1.1 et WSDL fut soumis au W3C en 2001.UDDI a été créé en 2000 par OASIS (Organization for the Advancement of Structured InformationStandards) afin de permettre aux entreprises de publier et de retrouver les services web. AvecSOAP, WSDL et UDDI, les standards étaient désormais en place pour la création de services web[153].

3.4 Les acteurs SOALes acteurs qui sont en interactions dans ce type d’architecture sont représentés dans la figure

suivante [29] :

1. Le World Wide Web Consortium, abrégé par le sigle W3C, est un organisme de standardisation chargé depromouvoir la compatibilité des technologies du World Wide Web


Figure 3.1 – Acteurs et rôles dans l’architecture Orientée Service

– Le fournisseur de service : il représente une personne ou une organisation qui permetd’exposer (publication) la description de son service dans un registre de service afin de lerendre accessible aux utilisateurs potentiels.

– Le registre de service : c’est un répertoire de service (appelé aussi annuaire ou courtierde service). Il permet aux fournisseurs de stocker leurs descriptions et aux consommateursde rechercher et de choisir le service correspondant à son besoin. Ce registre joue un rôleintermédiaire entre le fournisseur et le consommateur de service.

– Le consommateur de service : c’est l’utilisateur de service qui peut être une personne,une application ou un serveur. Il lance une recherche (découverte) dans l’annuaire et s’ilexiste un service qui répond à son besoin, il utilise la description de ce service pour établirune connexion avec son fournisseur afin de l’utiliser (invocation).

3.5 Définition du service webDans la littérature, il existe de nombreuses définitions des services web, nous avons retenu celles

qui nous ont semblées les plus intéressantes et les plus complètes, nous citons celle de W3C, Dicodu net 2 et celle de wikipédia.

3.5.1 Définition du ‘W3C’« Un Service Web est un composant logiciel identifié par une URI, dont les interfaces publiques

sont définies et appelées en XML. Sa définition peut être découverte par d’autres systèmes logiciels.Les services Web peuvent interagir entre eux d’une manière prescrite par leurs définitions, enutilisant des messages XML portés par les protocoles Internet » [153].

3.5.2 Définition de ‘Dico du net’« Une technologie permettant à des applications de dialoguer à distance via Internet indépen-

damment des plateformes et des langages sur lesquels elles reposent ».

3.5.3 Définition ‘Wikipédia’« Un service web est un programme informatique permettant la communication et l’échange de

données entre applications et systèmes hétérogènes dans des environnements distribués". Il s’agitdonc d’un ensemble de fonctionnalités exposées sur internet ou sur un intranet, par et pour des

2. Le Dico du Net est un dictionnaire collaboratif en ligne focalisé sur les e-technologies


applications ou machines, sans intervention humaine, et en temps réel ». Les trois définitions ayantété publiées à différents stade de l’évolution des services Web. Celles-ci peuvent prêter à confusion.Nous pouvons néanmoins donner une définition de façon plus générale. Un service web est unetechnologie permettant à des applications de communiquer entre elles :

– en s’appuyant sur les standards du web (HTTP, XML). indépendamment de l’architecturesur lesquelles elles sont implémentées.

– en échangeant des documents sous le format XML [153].

3.6 Motivation et intérêtUn service Web est un mécanisme qui tend à donner plus d’interactions pour permettre à deux

entités hétérogènes (entreprises, clients, applications, etc.) de dialoguer au travers du réseau Inter-net. Les logiciels écrits dans divers langages de programmation (C #, Visual Basic, Java, etc.), surdiverses plateformes (Linux, Windows, etc.) et avec diverses architectures peuvent employer desservices Web pour échanger des données à travers des réseaux informatiques. Chaque service webdoit pouvoir être découvert et invoqué dynamiquement par les applications. Les aspects purementpratiques n’ont rien de fondamentalement novateurs. Au contraire, l’architecture des services Webs’est imposée (tout comme le langage XML) grâce à sa simplicité, à sa lisibilité et à ses fondationsnormalisées. L’objectif principal des services Web est de faciliter le plus possible l’accès aux appli-cations entre entités et ainsi de simplifier les échanges de données. Cette interopérabilité est due àl’utilisation de normes ouvertes. L’OSI 3 et le W3C sont les comités de coordination responsablesde l’architecture et de standardisation des services Web. Pour améliorer l’interopérabilité entre lesréalisations de service Web, l’organisation WS-I « Web Services Interoperability » a développéune série de profils pour faire évoluer les futures normes impliquées. L’aspect le plus importantdes Services Web est qu’ils reposent sur plusieurs standards qui permettent la structuration desarchitectures. Cette collection de normes et de protocoles est appelée Services Web Protocol Stack.Elle contient entre autre XML et SOAP pour le formatage des données, WSDL pour la descriptiondes services Web et UDDI pour la recherche des services Web nécessaire au bon fonctionnementdes applications. Une des raisons principales pour lesquelles les services Web sont employés sembleêtre qu’ils se fondent sur Internet et HTTP pour fonctionner. Pour comprendre ceci, il faut garderà l’esprit que beaucoup d’organisations se sont protégées en employant des firewalls qui filtrentet bloquent beaucoup de trafic d’Internet pour des raisons de sécurité. Dans ce milieu, beaucoupde ports (voire quasiment tous) sont fermés au trafic entrant et sortant, et les administrateursdes réseaux n’ont pas l’envie de les ouvrir. Il en est un qui par contre est toujours ouvert, celuides navigateurs par lequel transite le protocole HTTP. De cette façon les applications peuventcontinuer à interagir entre elle et ce sans modifier la configuration de sécurité des organisations. Sil’on devait résumer les raisons de la création des services Web, les qualificatifs tels que la simpli-cité des échanges, l’amélioration de la communication entre les applications en seraient les pointsprincipaux. En ajoutant à cela l’interopérabilité des programmes indifféremment de leur langageet de leur plateforme, les services Web nous prouvent une nouvelle fois que leur technologie esttrès attrayante. Le véritable point fort du concept c’est la normalisation des données au travers destandards connus et acceptés par tous.

Quel que soit leurs types, l’utilisation de services web peut avoir plusieurs intérêts dont nouscitons [137] :

– L’exposition de fonctionnalités au travers du réseau : les traitements des opérations desservices web peuvent être invoqués par une requête HTTP, ce qui peut permettre à plusieurs

3. OSI : (Open Systems Interconnection) est un standard de communication entre applications d’un réseau.


applications de consommer ces services web.

– La communication entre des applications et des systèmes hétérogènes : l’utilisation de stan-dards ouverts permet la production et la consommation des services web par différentestechnologies sur différents systèmes d’exploitation.

– Les échanges se font en utilisant l’infrastructure existante puisque les services web sont gé-néralement invoqués en utilisant le protocole HTTP. Ceci permet de facilement passer unfirewall (un dispositif de protection constituant un filtre entre un réseau local et un autreréseau non sûr) pour permettre une invocation depuis l’extérieur. Ceci permet une invocationdepuis l’extérieur en passant facilement un firewall.

– Les services web permettent un couplage faible entre les fonctionnalités exposées et les ap-plications qui les utilisent à tel point que les consommateurs et les producteurs peuvent êtreécrits pour des plateformes ou des langages différents (Java, .Net, PHP, etc.).

– Les services permettent de définir de nouvelles opportunités de business voire même de nou-veaux modèles économiques en permettant de proposer des fonctionnalités à des partenairespar exemple.

3.7 Organisation des services webLa normalisation actuelle autour des Services Web est une organisation complexe qui va bien

au-delà de la simple invocation d’une méthode d’un objet distant. Différents travaux ont ainsidémarré pour permettre d’établir une véritable infrastructure distribuée, capable de satisfaire l’en-semble des besoins d’une application distribuée, aussi bien en termes de normalisation des échangesqu’en termes de services transverses. Cette organisation par comités de normalisation peut êtreschématisée selon le découpage matriciel suivant et comme le montre la figure 3.2 :

– Cette normalisation des services transverses se fait sur trois axes horizontaux [151] :

1. Couche de transport : définition de la structure des messages utilisés par les applica-tions pour se découvrir et dialoguer entre elles. Cette couche est réellement normaliséeet ne souffre d’aucune contestation. Elle s’appuie sur le protocole SOAP pour l’échangedes messages et sur le langage WSDL pour la définition du contrat de l’interface.

2. Couche de sémantique : normalisation des données participant aux échanges selondes critères métier. Les initiatives de définition de la couche de sémantiques des messagessont nombreuses et n’ont pour le moment pas conduit à une quelconque normalisation.Deux types d’organisation sont actuellement ouverts, l’une établie selon les différentscorps de métier, l’autre suivant une approche plus globale autour de consortium telqu’OASIS (Initiateur d’ebXML) ou Rosetta Net.

3. Couche de gestion des processus : standardisation de la gestion des processus mé-tier qui s’étendent sur plusieurs applications disponibles sur Internet. L’orchestrationde transactions B2B (Business to Business) complexes, fondée sur une architecture nor-malisée des messages est aussi une tentative qui n’avance pas assez rapidement et surdes standards non murs.

– Cette normalisation des services transverses se fait aussi sur trois axes verticaux [151] :

1. Service d’annuaire : standardisation des moyens d’accès à un service à partir d’une re-quête portant sur le contenu d’un service ou sur un fournisseur. La première proposition


d’annuaire UDDI aurait dû apporter une solution définitive. Le constat est qu’il n’enest rien et que la trame, trop globale, du projet ne suffit pas à régler cette problé-matique d’échanges entre applications se connaissant. Une deuxième proposition d’an-nuaire, WSInspection, vient concurrencer celle-ci. Moins ambitieuse puisqu’elle consisteen une simple exposition, par agrégation, des services d’une application, elle est toutefoisplus adaptée à cette seconde problématique.

2. Service de sécurité : normalisation des moyens permettant de couvrir les problématiquesd’authentification et de gestion des droits d’accès. La gestion de la sécurité est actuelle-ment le frein le plus important à la mise en place d’architectures distribuées à base deServices Web. Plusieurs organisations sont ouvertes mais aucune n’est réellement accep-tée. Il semblerait que la norme XACML (eXtensible Access Control Markup Language)puisse supplanter SAML (Security Assertion Markup Language) et s’imposer à termecomme standard de sécurité.

3. Service de transaction : normalisation des moyens permettant de garantir l’intégrité destransactions longues impliquant plusieurs Services Web. Le problème reste le même quepour la sécurité. Les standards ne sont pas tout à fait établis. La lutte pour l’obtentiond’une norme est beaucoup plus ouverte que pour celle de la sécurité, même si BTP(Business Transaction Protocol) semble plus soutenu actuellement[151].

La figure 3.2 présente la modélisation de la normalisation des différentes couches des servicesweb :

Figure 3.2 – Architecture en couche des services web

3.8 L’architecture d’un service webPour comprendre le fonctionnement d’une architecture de services Web, il faut commencer

par revoir certains principes. Si l’on reprend la définition de Mark Colan, spécialiste en ServiceWeb and XML chez IBM, les Services Web sont des "applications modulaires basées sur Internetqui exécutent des tâches précises et qui respectent un format spécifique". Ce sont donc des unitéslogiques applicatives qui sont accessibles grâce au protocole Internet. Une définition conceptuelledu terme service Web mettrait en avant les qualités d’une fonctionnalité commerciale présentéepar une entité hétérogène quelconque sur Internet afin de fournir un moyen d’user de ce serviceà distance. Pour l’aspect opérationnel, les services Web ne sont que des applications modulairesqui peuvent être présentées, publiées, situées et invoquées dans un réseau et ce automatiquement.Ainsi, les applications peuvent faire appel à des fonctionnalités situées sur d’autres machines dans


d’autres applications. Au final, on peut affirmer que le but initial d’un service Web est de rendrepossible l’utilisation d’un composant applicatif de façon distribuée. L’apport majeur de ce modèled’échange de données est d’introduire ces services comme des "boîtes noires". En effet, les requêtes-réponses d’un service Web sont administrées dans le contenu de messages dont on sait la forme grâceà des interfaces clairement présentées et sur lesquelles l’implémentation interne du traitement et lelangage employé ne jouent pas au niveau de l’architecture. Grâce à cela, on obtient un haut niveaude modularité et d’interopérabilité. Ce modèle de message permet donc d’oublier la structure, lelangage ou encore la plate-forme qui va porter le service : il suffit juste que le message suive unearchitecture donnée pour qu’il puisse être analysé. Il s’agit maintenant d’identifier chaque acteurde ses services Web et de comprendre comment ils interagissent les uns avec les autres. Les troiséléments les plus importants des services Web comme nous l’avons défini précédemment sont [151] :

1. Les fournisseurs de service,

2. Les annuaires de services et

3. Les consommateurs de service.

– Le fournisseur (ou serveur) crée le service Web et publie toutes ses caractéristiques dansl’annuaire de service.

– L’annuaire rend disponible les interfaces d’accès aux services et donnant le contrat et l’ar-chitecture employée pour permettre les interactions.

– Le consommateur (ou client) quant à lui, accède à l’annuaire pour rechercher les services Webdont il a besoin et avec lui les normalisations à obtenir. Il peut ainsi envoyer ses requêtes auservice désiré et obtenir les réponses qu’il pourra analyser.

La figure suivante montre le fonctionnement de cette architecture :

Figure 3.3 – Cycle de vie des services web

Comme le montre la figure 3.3, cette architecture passe par les étapes suivantes :

1. Le client envoie une requête à l’annuaire de Service pour trouver le service Web dont il abesoin.

2. l’annuaire va lui fournir les descriptions et les URL des services demandés afin de lui permettrede les invoquer.


3. Le client envoie une deuxième requête au serveur pour obtenir le contrat de normalisationde ses données.

4. Le serveur envoie sa réponse sous la forme établie par WSDL en langage XML.

5. Le client peut maintenant rédiger sa requête pour traiter les données dont il a besoin.

6. Le serveur fait les calculs nécessaires suite à la requête du client, et renvoie sa réponse sousla même forme normalisée [151].

3.9 L’architecture étendue des services web SOAP/WSDL/UDDIElle désigne le cadre de services Web qui repose sur SOAP, WSDL et UDDI. Tous trois sont

des technologies basées sur XML, ce qui permet en théorie aux applications de services web de lesutiliser de manière autonome (sans intervention humaine) d’un bout à l’autre des opérations.

3.9.1 Le protocole de communication SOAPC’est un protocole de dialogue par appels de procédures à distance entre objets logiciels. Sa

syntaxe d’utilisation est fondée sur XML et ses commandes sont envoyées sur Internet par l’inter-médiaire du protocole HTTP mais aussi SMTP et POP sous forme de texte structuré. Il permetaux systèmes objets distribués de solliciter et d’obtenir des services rendus par d’autres objets,il est moins lourd à mettre en œuvre que d’autres protocoles et c’est pour cela qu’il est de plusen plus adopté. Le protocole SOAP est une note du Consortium W3C dont Microsoft fait partie,mais qui n’est pas spécifique à Microsoft et Windows. IBM a également participé à l’élaborationde ce protocole. De plus il existe des implémentations Java, et Borland vient déjà d’implémenterSOAP sous Windows dans Delphi 6 et sous Linux avec Kylix. Bien qu’il soit utilisable avec d’autresprotocoles de transport, HTTP est le plus couramment utilisé. Le deuxième standard, XML, utilisépour la structuration des données sous forme de messages est quant à lui le seul utilisé [151].

Beaucoup de définitions normalisées de SOAP ont été proposées. Une particulièrement intéres-sante définit SOAP comme étant une spécification pour une omniprésence, basée sur XML et surdes infrastructures distribuées. En effet [141] :

– Spécification car SOAP est un document qui définit le modèle de communication. L’idée debase est que si les deux parties ont créé des programmes de mêmes spécifications, ils seronten mesure d’interagir de façon transparente.

– Omniprésente car SOAP est défini à un niveau suffisamment élevé d’abstractions que toutsystème d’exploitation et combinaison de langages de programmation peuvent être utiliséspour créer des programmes compatibles SOAP.

– Basé sur XML SOAP est construit sur XML, ce qui signifie que les documents SOAP sontdes documents XML construits en fonction d’un cahier de charges plus strict.

– Infrastructure distribuée SOAP ne précise pas quelles données peuvent être déplacées oubien quels appels de fonctions peuvent avoir lieu sur elle. Les applications construites sur laspécification SOAP peuvent déplacer les données d’un ordinateur A à un ordinateur B et parla suite à une autre application écrite sur la même spécification.


3.9.2 Le langage XMLXML (Extensible Markup Language) est un langage de balisage extensible qui a été mis au point

par le XMLWorking Group sous l’égide du W3C. Les spécifications XML 1.0 sont reconnues commerecommandation par le W3C, ce qui en fait un langage reconnu. XML est un standard qui sertde base pour créer des langages balisés spécialisés ; c’est un « méta langage ». Il est suffisammentgénéral pour que les langages basés sur XML, appelés aussi dialectes XML, puissent être utiliséspour décrire toutes sortes de données et de textes. Il s’agit donc partiellement d’un format dedonnées. Son objectif est, dans un échange entre systèmes informatiques, de transférer, en mêmetemps, des données et leurs structures. Permettant de coder n’importe quel type de donnée, depuisl’échange EDI (Electronic Data Interchange ou Echange de Données Informatisées)[135] jusqu’auxdocuments les plus complexes, son potentiel est de devenir le standard universel et multilingued’échange d’informations. XML Namespaces est une extension de la recommandation XML quipermet de créer des espaces de nommages. Les espaces de noms d’XML permettent de qualifierde manière unique des éléments et des attributs. On sait alors à quel domaine de définition serapporte un objet et comment il doit être interprété, selon sa spécification. Différencier des espacesde noms permet de faire coopérer, dans un même document, des objets ayant le même nom, maisune signification différente, souvent liée à un modèle de contenu différent. Cette spécification estune avancée importante car, à partir du moment où beaucoup de formats s’expriment selon XML,les risques de « collision de noms » deviennent plus importants et cette spécification prend alorstoute son importance [139].

3.9.3 Le langage de description WSDLUn document WSDL (Web Services Description Language) se compose d’un ensemble d’élé-

ments décrivant les types de données utilisés par le service, les messages que le service peut recevoir,ainsi que les liaisons SOAP associées à chaque message. Le schéma ci-dessous illustre la structure dulangage WSDL qui est un document XML, en décrivant les relations entre les sections le constituant[153].

Figure 3.4 – Structure d’un document WSDL

Comme montré dans la figure 3.4 un fichier WSDL contient sept éléments clé :


1. Types : fournit la définition de types de données utilisés pour décrire les messages échangés.

2. Message : représente une définition abstraire (noms et types) des données en cours detransmission.

3. PortTypes : décrit un ensemble d’opérations. Chaque opération à zéro ou un message enentrée, zéro ou plusieurs messages de sortie ou d’erreurs.

4. Binding : spécifie une liaison entre un <portType> et un protocole concret (SOAP, HTTP...).

5. Service : indique les adresses de port de chaque liaison.

6. Port : représente un point d’accès de services défini par une adresse réseau et une liaison.

7. Opération : c’est la description d’une action exposée dans le port.

Le document WSDL peut être divisé en deux parties. Une partie pour les définitions abstraites,tandis que la deuxième contient les descriptions concrètes [153].

1. La description concrète est composée des éléments qui sont orientés vers le client pour leservice physique. Les trois éléments concrets XML présents dans un WSDL sont : <wsdl :ser-vice> ; <wsdl :port> ; <wsdl :binding>.

2. La description abstraite est composée des éléments qui sont orientés vers la descriptiondes capacités du service Web. Ses éléments abstraits définissent les messages SOAP de façontotalement indépendante de la plate-forme et de la langue. Cela facilite la définition d’unensemble de services pouvant être implémentés par différents sites Web. Les quatre élémentsabstraits XML qui peuvent être définis dans un WSDL sont : <wsdl :types> ; <wsdl :mes-sage> ; <wsdl :operation> ; <wsdl :portType>.

3.9.4 L’annuaire des services UDDIL’annuaire des services UDDI (Universal Description Discovery and Integration) est un standard

pour la publication et la découverte des informations sur les services Web. La spécification UDDI estune initiative lancée par ARIBA, Microsoft et IBM. Cette spécification n’est pas gérée par le W3Cmais par le groupe OASIS. La spécification UDDI vise à créer une plate-forme indépendante, unespace de travail (framework) ouvert pour la description, la découverte et l’intégration des servicesdes entreprises. L’annuaire UDDI se concentre sur le processus de découverte de l’architectureorientée services (SOA), et utilise des technologies standards telles que XML, SOAP et WSDL quipermettent de simplifier la collaboration entre partenaires dans le cadre des échanges commerciaux.L’accès au référentiel s’effectue de différentes manières[153].

– Les pages blanches : comprennent la liste des entreprises ainsi que des informations asso-ciées à ces dernières (coordonnées, description de l’entreprise, identifiants.).

– Les pages jaunes : recensent les services Web de chacune des entreprises sous le standardWSDL.

– Les pages vertes : fournissent des informations techniques précises sur les services fournis.

Les entreprises publient les descriptions de leurs services Web en UDDI, sous la forme de fichiersWSDL. Ainsi, les clients peuvent plus facilement rechercher les services Web dont ils ont besoinen interrogeant le registre UDDI. Lorsqu’un client trouve une description de Service Web qui luiconvient, il télécharge son fichier WSDL depuis le registre UDDI. Ensuite, à partir des informationsinscrites dans le fichier WSDL, notamment la référence vers le service Web, le client peut invoquerle service Web et lui demande d’exécuter certaines de ses fonctionnalités.


3.9.5 Les Avantages de l’architecture étendue– Par rapport à tous les autres protocoles de RPC, SOAP est interopérable, ainsi il est indé-pendant des plateformes et langages de programmation.

– le déploiement des applications : Pour communiquer entre deux sociétés via Internet, il est trèssouvent désagréable d’utiliser autre chose que HTTP ou POP/SMTP à cause des Firewalls,qui doivent êtres reconfigurés engendrant ainsi des trous de sécurité. De plus, cela impliquede longues négociations entre administrateurs réseaux [151].

3.9.6 Les inconvénients de l’architecture étendue– En raison du nombre d’informations qu’impose le format XML, SOAP peut alourdir, considé-rablement, les échanges par rapport à des middlewares comme CORBA ou ICE, ce qui n’estpas forcément un handicap quand les volumes de données transités par SOAP sont faiblespar rapport au volume total de données échangées.

– SOAP décrit la manière dont les applications doivent communiquer entre elles, certains consi-dèrent que le couplage reste fort entre le serveur et ses clients.

– Une modification de l’API implique une évolution côté client, contrairement à une architec-ture orientée ressources telle que REST [148].

3.10 L’architecture RESTREST [45] est inventé par Roy T Fielding. Il dit dans sa dissertation : “Architectural Styles and

the Design of Network-based Software Architectures “ : "REpresentational State Transfer évoquel’image du fonctionnement d’une application Web bien construite : un réseau de pages Web (unemachine à états finis virtuelle) où l’utilisateur progresse dans l’application en cliquant sur des liens(transition entre états) ce qui provoque l’affichage de la page suivante (représentant le nouvel étatde l’application) à l’utilisateur qui peut alors l’exploiter" [45]. L’architecture REST est basée surles standards du web et utilise le protocole HTTP pour l’échange de données. Cette architectures’articule autour de « ressources », ainsi chaque composant est une ressource et est accessible parune interface commune en utilisant des méthodes du standard HTTP [137]. Dans une architectureREST, le serveur fournit simplement l’accès aux ressources. Chaque ressource est identifiée par unURI (Uniform Resource Identifier) que le client utilise. On appelle « Restfull Web Services » desservices web basés sur l’architecture REST. Ces services web sont légers, hautement évolutifs etmaintenables. Ils sont couramment utilisés pour créer des API (Application Programming Interface)destinées à des applications web. Le principe des « Restfull Web Services » est qu’ils tirent leursavantages du fait que leur implémentation ne doit respecter quasiment aucune contraintes pourpouvoir fonctionner. En effet, contrairement à SOAP, REST n’est pas un protocole mais bien unstyle d’architecture qui utilise les standards du web, en particulier [141] :

– URI comme syntaxe universelle pour adresser les ressources,

– HTTP un protocole avec un nombre limité d’opérations (verbes) pour agir sur les ressources,

– Les types MIME comme text/xml, text/html, image/jpeg, application/Json, video/mpegpour la représentation des ressources.

– Des liens hypermedia dans des documents HTML, XML ou autres pour représenter à la foisle contenu des informations et la transition entre états de l’application, Même si la réalisation


d’un service web de type REST n’est pas contrainte par des règles dures, elle devrait suivrecertaines lignes directrices afin de coller au mieux à l’architecture REST.

3.10.1 URI et RessourceUn URI (Uniform Resource Identifier), soit littéralement identifiant uniforme de ressource, est

une courte chaîne de caractères identifiant une ressource sur un réseau (par exemple une ressourceWeb) physique ou abstraite, et dont la syntaxe respecte une norme d’Internet mise en place pour leWorld Wide Web. Les URI sont la technologie de base du World Wide Web car tous les hyperliensdu Web sont exprimés sous forme d’URI [141].

3.10.2 Les méthodes HTTP (GET, POST, PUT,etc.)Le deuxième composant de l’architecture REST est le protocole HTTP. Comme le montre la

figure 3.5, ce protocole comporte deux méthodes principales GET et POST et deux manières detransmettre des paramètres, soit dans l’URI, soit dans les données d’un formulaire. L’utilisationde GET est "sûre", c’est à dire que l’état de la ressource ne doit pas être modifié par un GET. Ceciautorise les liens, la mise en cache, les favoris. Il faut donc utiliser GET pour des opérations quiressemblent à des questions ou à des lectures de l’état de la ressource. En revanche, il faut utiliserPOST quand la demande ressemble à une commande, ou quand l’état de la ressource est modifiéou encore quand l’utilisateur est tenu pour responsable du résultat de l’interaction [141].

Figure 3.5 – Cas d’utilisation des Méthode HTTP sur une ressource

Un autre principe de l’architecture REST : le HTTP GET est "sûr", c’est à dire que l’utilisateurou son agent peut suivre des liens sans obligations. La conséquence de l’idempotence du GET (deuxaccès successifs donnent le même résultat) rend l’utilisation du Web plus fiable car un deuxièmeclic sur un lien ne modifie pas le résultat. Le protocole HTTP comporte d’autres commandes moinssouvent utilisées. HEAD qui est un GET qui ne renvoie que les métadonnées, pas les données. PUTet DELETE pour créer ou supprimer une ressource [141].

3.10.3 Les avantages de l’architecture RESTDans [45], Roy Fielding précise les avantages de ce style architectural par rapport à d’autres

styles d’architectures d’applications web. Citons entre autres :

– L’application est plus simple à entretenir, car les liens sont mieux structurés, et de façonuniverselle ; les liens sont le moteur de l’état de l’application.


– L’absence de gestion d’état du client sur le serveur conduit à une consommation de mémoireinférieure, une plus grande simplicité et donc à une capacité plus grande de répondre à ungrand nombre de requêtes simultanées.

– L’absence de gestion d’état du client sur le serveur permet une répartition des requêtes surplusieurs serveurs : une session client n’est pas à maintenir sur un serveur en particulier,ou à propager sur tous les serveurs (Avec des problématiques de fraîcheur de session). Celapermet aussi une meilleure évolutivité et tolérance aux pannes (un serveur peut être ajoutéfacilement pour augmenter la capacité de traitement, ou pour en remplacer un autre).

– L’utilisation du protocole HTTP en tirant partie de son enveloppe et ses entêtes, à l’opposé deSOAP qui ne présuppose pas un protocole : SOAP réinvente un protocole via une enveloppe,des entêtes et un document, à l’intérieur du protocole réseau l’hébergeant (la plupart dutemps HTTP). Il ne bénéficie donc pas des caractéristiques HTTP, gérée par l’infrastructureréseau (notamment le proxy supportant le cache côté serveur pour des performances plusimportantes).

– L’utilisation d’URI comme représentant d’une ressource, permet la mise en place de serveurscache.

3.10.4 Les inconvénients de l’architecture RESTLes principaux inconvénients de REST sont [13] :

– La nécessité pour le client de conserver localement toutes les données nécessaires au bondéroulement d’une requête, ce qui induit une consommation en bande passante réseau plusgrande. S’il est possible de coupler une application web REST à un service extérieur assurantla permanence des données lors de la durée d’une session, par exemple une base de donnéesou un cookie, on pourrait cependant considérer que l’utilisation d’un tel service pour gérerdes données relatives à une session ouverte par le client serait en violation de la philosophiede REST. REST préfèrera l’utilisation de tableaux codés en JavaScript présents dans lamémoire du navigateur client.

– L’utilisation d’un formulaire HTML envoyant ses données avec une méthode comme DELETEne peut être compris par la plupart des navigateurs. Pour pallier ce problème on émulece comportement avec un champ caché qui transmettra le type de méthode d’envoi desdonnées à l’application. Par ailleurs beaucoup d’applications, bien que ne respectant passcrupuleusement toutes les contraintes de l’architecture REST, sont largement inspirées parelle.

3.11 Systèmes utilisant les services webRoy Fielding l’informaticien américain a beaucoup contribué en l’informatique étant un spé-

cialiste du web, il n’est pas étonnant qu’il définisse un style d’architecture simple et clair commeREST. Beaucoup d’applications suivent ce type d’architecture pour la conception de services web,dans cette section nous allons exposer quelques systèmes utilisant les services web de ce type, nousavons sélectionné des applications connues et disponibles sur le web en donnant un exemple deservice web utilisé.


GmailGmail est un service de messagerie gratuit proposé par Google. Les messages reçus sur un

compte Gmail peuvent être lus via un client de messagerie, une application mobile ou avec unnavigateur web. L’API de Gmail tourne autour de 5 aspects principaux : les messages, les libellés,les brouillons, l’historique et les objets.

Requête Description du serviceweb

Source

GET https ://www.googleapis.com/gmail/v1/users/me/messages ?q="in :sent af-ter :2014/01/01 before :2014/01/30"

Cette requête va demander àGmail tous les messages quiont été envoyés entre le 1 jan-vier 2014 et le 30 janvier 2014

Site officielde Gmail[143]

Table 3.1 – Exemple de service web : Gmail

GithubGitHub est une plateforme d’hébergement de code qui est très utilisée par beaucoup de sites

web de toutes les tailles. Leur API REST permet à n’importe quel utilisateur de suivre l’activitéd’un autre utilisateur, de consulter les bugs d’un dépôt et même de créer un dépôt depuis sonapplication.


Source

GET /users/ :username Cette requête permet d’obte-nir les informations concer-nant un utilisateur

Site officielde GitHub[144]

Table 3.2 – Exemple de service web : Github

Weather UndergroundCette API REST expose les données sur le temps et la météo qui peuvent être très utiles dans

beaucoup d’applications, elle fournit un accès facile à ces données et qui peuvent être utiliséesdans d’autres logiciels. Par exemple, si on crée une application qui suggère aux utilisateurs lesvêtements qu’ils devraient porter pour aller courir, on aura besoin de connaître la température, lesconditions météorologiques, quand le soleil se lèvera et se couchera, etc., pour permettre au logicielde faire des prédictions. Créer son propre service météorologique pour recevoir ces informationsserait beaucoup trop long et fastidieux ; utiliser les données de cette API pour sa propre utilisationest donc un très bon choix. Elle permet de donner des informations très pratiques sur n’importequelle ville comme la vitesse du vent, les précipitations, la puissance des rayons UV, etc.



Source

GET http ://api.wunderground.com/api/YourKey/conditions/q/CA/SanFrancisco.json

Cette requête permet d’avoirla météo à San Fransisco

Site of-ficiel deWeather Un-derground[146]

Table 3.3 – Exemple de service web : Weather Underground

InstagramInstagram est une application, un réseau social et un service de partage de photos et de vidéos

appartenant à Facebook, disponible sur plates-formes mobiles de type iOS, Android et WindowsPhone. Instagram est également disponible sur ordinateurs avec des fonctionnalités réduites [136].

L’API d’Instagram permet à l’application de l’utilisateur d’accéder à son compte, aux photos,etc. Voici ci-dessous quelques méthodes qui permettent d’interagir avec un compte utilisateur.


Source

GET /users/user-id Cette requête permet d’avoirles informations d’un utilisa-teur grâce à identifiant

Site officiel

Get /users/search Chercher un utilisateur par lenom

d’Instagram

GET /users/user-id/media/recent Chercher les plus récentes me-dias de l’utilisateur

[145]

Table 3.4 – Exemple de service web : Instagram

3.12 L’aide à la décision et les services webL’aide à la décision est un domaine très en vogue par le fait qu’il aide les décideurs à prendre

une décision ou à mieux décider ce qu’il leur permet de gagner du temps, d’orienter la prise dedécision qui est peut être impossible sans son aide. Nous avons abordé, en détails, dans le chapitre Ice domaine en commençant par la notion de décision pour arriver à un système d’aide à la décisionde groupe quand les décideurs sont nombreux. Dans la réalité, les décideurs ne sont pas toujoursdans le même lieu mais plutôt géographiquement dispersés, la communication est alors nécessairepour pouvoir décider. D’un point de vue opérationnel, l’aide à la décision a connu ces dernierstemps une révolution : l’orientation desktop a évolué vers une orientation web pour faciliter lacommunication entre les décideurs en temps réel, parmi les outils du web il y a les services webproposant tous leurs avantages aux systèmes d’aide à la décision. Un système d’aide à la décisionprofite des avantages des services web quand il suit une architecture client/ serveur, le client peutconsulter n’importe quelle donnée à n’importe quel moment via une simple interface web depuis


n’importe quel terminal connecté, il reste léger quand tous les calculs et opérations résident dansle serveur. Un système d’aide à la décision orienté web est facile à contrôler et à adapter, et peutévoluer en complexité au fur et à mesure. Les données peuvent être encombrantes, les mettre dansle serveur peut être très intéressant et de ce fait le décideur n’a qu’à actualiser ses données enutilisant un service. Nous avons présenté dans la section précédente, quelques systèmes en lignepuissants et connus dans le monde utilisant les services web. Dans ce qui suit, nous allons présen-ter quelques travaux que nous avons recensés qui ne sont pas très nombreux. Il s’agit de quelquessystèmes d’aide à la décision basés sur les services web .

Dans [125], les auteurs ont proposé une plateforme d’aide à la décision géomarketing, met-tant en place un système d’information géographique orienté service web utilisant une gestion desbases de données géographiques (PostgreSQL et son extension PostGIS), un logiciel de calcul sta-tistique (R, et son extension PL/R), et un service de création de cartes géographiques (MapServer).

Nous citons aussi un autre système proposé dans [7] qui a retenu notre attention et qui consisteen un système d’aide à la décision collaborative : une plateforme web-SIG est proposée pour lagestion des risques avec la participation des différentes parties prenantes, en s’appuyant sur lesavantages du web moderne, les technologies géo spatiales. Cette plateforme web a été conçuepour le partage centralisé des informations des risques, où les parties prenantes concernées peuventanalyser les risques, évaluer et sélectionner les mesures de réduction des risques de façon interactiveet collaborative.

3.13 ConclusionNous avons abordé dans ce chapitre les notions fondamentales se rapportant aux services web.

Ces derniers sont des composants logiciels distribués qui offrent des fonctionnalités aux applica-tions au travers du réseau. Ils se divisent en deux grandes familles : services web de type SOAP etservices web de type REST.

Rest et SOAP sont souvent comparés l’un à l’autre dans la conception des applications clientsserveurs mais on oublie de dire qu’ils ne sont pas du même type. En effet, SOAP est un protocoledédié basé exclusivement sur XML tandis que REST est un style d’architecture.

De ce fait, les services web de type REST tirent tout l’avantage des standards bien connusdu web. Les Services Web possèdent une simplicité de mise en œuvre : Ils rendent en effet acces-sibles depuis Internet des fonctionnalités d’une application existante tout en ne modifiant pas enprofondeur le système d’information. Il s’agit de l’ajout de briques supplémentaires. Pour cela, lesServices Web exploitent les standards d’échange Internet. Les services Web avec leurs protocoleset leurs standards avancent de jour en jour vers plus de normalisation.

Dans le prochain chapitre, nous présenterons notre contribution qui consiste à mettre en placeun système d’aide à la décision de groupe destiné à trouver un consensus entre un ensemble dedécideurs dans un contexte multicritères tout en exploitant un protocole de négociation à traversune plateforme de communication utilisant les services web .

Deuxième partie

Contributions

Chapitre 4

Modélisation de l’approcheproposée

4.1 IntroductionDans de ce chapitre, nous présentons notre contribution qui porte sur la proposition d’un mo-

dèle de processus de décision de groupe dans un contexte multicritères et multi décideurs. Lesystème d’aide à la décision de groupe correspondant comporte une plateforme de communicationweb susceptible d’assurer la négociation entre un ensemble de décideurs en conflit. Cette dernièreinclut une méthode d’analyse multicritères pour aider les décideurs à mieux exprimer leurs préfé-rences. La plateforme suggérée répond au modèle à trois niveaux de Desanctis et Gallupe [34] quenous verrons en détail dans ce chapitre. Notre approche s’appuie sur le partage d’informations, lepartage d’avis. . . en assurant la communication par un partage d’informations structurées 1 et nonstructurées 2. Nous présentons, dans ce chapitre, les principaux composants de la plateforme ainsique leurs fonctionnements à travers différents modèles de diagrammes. Nous exposerons, également,les services web que nous avons exploité dans les différents modules composants notre système.

4.2 Objectifs visésNotre objectif, par la présente étude, est de mettre en œuvre une plateforme de communication

dédié à un GDSS multicritères qui permet de gérer le processus décisionnel de groupe, et cepar des fonctionnalités intervenant à divers niveaux du processus. Aussi, nous conformons notreplateforme à la typologie donnée par Desanctis et Gallupe [34] que nous avons cité dans le chapitreI en proposant les options qui traduisent l’intérêt de chacun des trois niveaux à savoir :

Niveau 1 : Les GDSS du premier niveau améliorent la communication entre les décideurs.

Niveau 2 : Les GDSS du deuxième niveau, intègrent les mêmes caractéristiques que ceux dupremier. Ils sont, en plus, dotés de procédures permettant de modéliser et d’agréger lespréférences individuelles afin d’établir un consensus.

Niveau 3 : Les GDSS de niveau 3 permettent, de façon automatisée, de structurer les échangesd’information et la communication sur la base de recommandations émises par des systèmesexperts ou d’experts humains, comme par exemple, les règles à suivre au cours du processusde décision et les méthodes d’aide à la décision à mettre en œuvre, en fonction du contexte.

1. Informations structurées tels que la matrice de performances et les formulaires de vote. . .2. Informations non structurées tels que les échanges de message et d’avis avant la phase de décision.

Chapitre 4.Modélisation de l’approche proposée 61

A ce titre, afin de répondre aux besoins de communication exigés par le niveau 1, nous procédonsà la mise en place de :

– Un système de messagerie,

– Un système d’échange et d’archivage de documents,

– Un système de génération et d’échange de formulaires pour une communication plus struc-turée.

Le niveau 2 de la typologie adoptée recommande de mettre en place des méthodes permettantd’agréger les préférences des décideurs. A cet effet, nous proposons :

– Un système de vote basé sur des formulaires,

– Un protocole de négociation automatisé permettant de mener le groupe vers un consensus.

Finalement, et pour traduire les recommandations du niveau 3 qui ont trait à la structurationdes échanges, notre plateforme donne une place particulière au rôle d’initiateur (ou médiateur) qui ala charge de créer et de gérer le processus décisionnel. Les GDSS étant une extension des systèmesd’aide à la décision, ils doivent procurer une aide individuelle aux décideurs. Nous intégrons,par conséquent, une méthode d’analyse multicritères permettant d’aider chaque décideur à mieuxexprimer ses préférences.

Les niveaux de GDSS selon De-sanctis et Gallup [34]

Le GDSS proposé

Niveau 1– Un système de messagerie,

– Un système d’échange et d’archivage de docu-ments,

– Un système de génération et d’échange de formu-laires pour une communication plus structurée.

Niveau 2

– Un système de vote basé sur des formulaires,

– Un protocole de négociation automatisé permet-tant de mener le groupe vers un

Niveau 3

– Un rôle d’initiateur (ou médiateur) qui a la chargede créer et de gérer le processus décisionnel.

– Une aide individuelle aux décideurs : une méthoded’analyse multicritères permettant d’aider chaquedécideur à mieux exprimer ses préférences.

Table 4.1 – Analogie entre les niveaux du système proposé et ceux proposés par Desanctis etGallup


Un autre objectif de notre travail est de proposer une plateforme distribuée permettant de faireparticiper des décideurs géographiquement éloignés. Afin d’atteindre ce but, la mise en œuvre dela plateforme exploite les technologies du web, et plus spécifiquement la technologie des servicesweb.

Ces derniers permettent de mettre en place des systèmes hautement évolutifs et dont l’inté-gration dans d’autres systèmes hétérogènes est aisée. Notre contribution est d’une importance nonnégligeable, elle s’inscrit parmi les travaux du laboratoire LIO (équipe de recherche : Ingénieriede l’aide multicritères à la décision collective, distribuée et temps réel pour la gestionenvironnementale, le diagnostic médical et la surveillance épidémiologique).

Nous avons vu au cours du chapitre 2 que les services web de type REST reposent naturellementsur les standards du web et présentent l’avantage de la simplicité, c’est par conséquent ce type deservices web qui a été retenu pour l’implémentation de la plateforme.

4.3 Modèle décisionnel proposéLe processus décisionnel est une succession d’étapes dans le temps, suivi par un décideur pour

l’aider à prendre une décision au problème rencontré, il comporte principalement deux étapes : Ladétermination ainsi que la formulation du problème et la résolution du problème.Comme nous l’avons cité dans le chapitre II, le processus proposé par Simon [110] qui est unesource d’inspiration des processus décisionnels par la suite et qui a donné lieu à plusieurs critiquesse décompose en trois grandes étapes : 1) l’information, 2) la conception, 3) le choix.La première phase correspond à l’appréhension et la compréhension du problème. Celle de laconception a pour but de mettre en forme le problème et de rechercher les solutions alternatives.Enfin la dernière phase correspond à la prise de décision en elle-même.D’autres auteurs considèrent un nombre plus important de phases dans le processus de décision.C’est le cas notamment de Russo et Schoemaker [Russo et Schoemaker, 1994] qui suggèrent quatreétapes : 1) le cadrage, 2) la collecte d’informations, 3) la décision, 4) le feed-back.Drucker [35] avance, six étapes dans le processus de décision : 1) la classification du problème pourfaire ressortir à quelle catégorie il appartient, 2) la définition du problème pour en connaître lescauses et les effets, 3) les spécifications permettant de définir les conditions limites pour atteindreles objectifs, 4) la décision permettant de satisfaire aux conditions limites et de remplir les ob-jectifs, 5) le plan d’action en mobilisant les ressources nécessaires et en assignant les tâches auxpersonnels concernés, 6) le feedback pour évaluer la pertinence de la décision ou voir le cas échéantles mesures correctrices à prendre [5].Ces quelques modélisations des phases du processus décisionnel nous font réaliser qu’en fait unprocessus décisionnel doit passer par des étapes séquentielles illustrées dans le Tableau 4.2 parSchwenk [106] comme suit :


Hofer etSchendel[59]

Mintzberg[79]

Glueck[48]

Mazzolini[77]

Modèle géné-ral

1 Identificationde la stratégie.2 Diagnosticd’environne-ment.3 Analyse desressources.4 Analysed’écart.6 Évaluation dela stratégie.7 Choix de lastratégie.

1-Phase d’iden-tification.Reconnaissanced’un besoin dedécision.-Diagnostic.2-Phase d’éla-boration.-Recherche.-Conception.3-Phase dechoix.-Évaluation.-Autorisation.

1-Évaluation2-Choix, phase1 : considérerles solutionsstratégiques3-Choix,phase2 : Choixde la stratégie4- Mise enœuvre5.Évaluation dela stratégie

1-Identificationd’un besoin dedécision2-Recherchede solutionsd’action.3-Analyse dessolutions d’ac-tion.4-Revue e ap-probation.5-Mise enœuvre.

1-Définition dubut,Identificationdu problème.2-Énoncé desolutions straté-giques.3-Évaluationdes choix.4-Mise enœuvre.

Table 4.2 – Les phases des processus de décision, d’après Schwenk

Nous constatons à travers ce tableau que les différents modèles considèrent que le processusde décision commence par l’identification du problème et se termine par la mise en œuvre de lasolution retenue. Mais ce que nous constatons le plus c’est que ces modèles sont destinés à unprocessus décisionnel mono décideur qui fait lui-même la collecte et l’analyse de l’information etla prise de décision. Notre modèle proposé s’inspire largement du modèle proposé au sein de notrelaboratoire LIO par Hamdadou [52], figure 4.1. Il a comme caractéristique d’être multi décideurspuisqu’il fait intervenir plusieurs participants depuis la phase d’identification du problème jusqu’àla dernière phase qui est la prise de décision. La multitude des décideurs implique forcément unconflit dû aux divergences des opinions et des préférences des décideurs. A cet effet, nous intégronsdans notre processus un protocole de négociation permettant d’amener le groupe à une décisionsatisfaisante pour toutes les parties afin d’assurer la résolution du conflit comme montré dans lafigure 4.2 de notre démarche décisionnelle proposée.


Figure 4.1 – Phases et étapes du modèle décisionnel proposé dans [52]


Figure 4.2 – Le modèle décisionnel proposé

1. Phase de structuration et formulation du problème décisionnel : elle a pour objectifl’identification du problème et les choix fondamentaux sur la manière de l’aborder.

– Identifier les critèresLa phase d’identification des critéres est realisée en deux étapes : la première consisteà dresser une liste de critères appelés facteur pour éviter la confusion avec les critèresdéfinitifs , la liste des facteurs doit être aussi complète que possible.

– Identifier les actionsL’dentification de l’ensemble des actions est une étape très sensible dans toute démarched’aide à la decison, en particulier lorsque la méthode d’analyse multicirtères procède paragrégation partielle ,il est très important que l’ensemble des actions soit aussi completque possible car sa modification en court de route peut entrainer la repétition de l’analysemulticritères.

– Identifier les acteursLe concept d’acteur se réfère à une entité concrète, localisée (dans un contexte) ; c’est une


unité d’action et de décision, individuelle ou collective, à laquelle on peut attribuer desressources, une finalité et une stratégie. On peut identifier deux grands types d’acteurs :individuels et collectifs. Les acteurs collectifs sont des groupes ou des organisations.Les organisations peuvent être économiques (entreprise, coopératives, groupement deproducteurs, etc.), politiques (un parti, le conseil municipal, le conseil des anciens d’unecommunauté, etc.), sociales (associations de jeunes, etc.). La multiplicité des acteursrend la négociation territoriale difficile puisque d’un côté nous aurons les acteurs fortsdisposant d’un pouvoir important et de l’autre côté des acteurs faibles qui ont plus dedifficulté à défendre leurs intérêts.

2. La phase d’exploitation du modèle : Sert à effectuer certains types d’analyses sur lemodèle. Dans cette phase, toutes les parties prenantes seront modélisées sous forme d’agentparticipants, à chaque agent participant est associé un poids afin d’exprimer son importanceet l’étendue de son pouvoir lors de la décision .Tous les agents participants peuvent accéderà la matrice d’évaluation afin d’établir leur vecteur de préférences (concernant les différentesressources) via la méthode PROMETHEE II. Après plusieurs tours de négociation, les agentsparticipants arrivent à un consensus qui satisfait toutes les parties prenantes ou une partied’entre elles, c’est l’accord final.

3. la phase de concrétisation et d’évaluation : vise essentiellement l’acceptation socialedu résultat, cependant elle comprend aussi la mise en œuvre de la décision.

4.4 Description du système d’aide à la décision de groupeproposé

Le système d’aide à la décision de groupe proposé comporte,principalement, une plateforme decommunication basée sur des services web. Cette plateforme intègre un protocole de négociationqui exploite dans l’une de ses étapes une méthode d’analyse multicriteres permettant de classerles actions potentielless de chaque agent impliqué dans la prise de décision. Nous allons détaillercette plateforme dans la section suivante mais nous commencons d’abord par identifier les acteurs(agents) concernés dans cette plateforme tout en décrivant le modèle SMA proposé.

4.4.1 Modèle SMALes systemes multi agents representent un paradigme de premier ordre pour l’analyse, la conce-

prion et l’implementation de système composé d’entités autonomes en interaction [41], pouvantcoopérer, communiquer et négocier.Les systèmes multi agents ont pour but de créer une missionde représenter les agents du monde réel en attribuant à chaque agent un rôle. Le modèle proposéimplique deux types d’agents :

– Un agent administrateur : qui s’occupera de la gestion des comptes utilisateurs.

– Un agent utilisateur : représente deux acteurs :

– Un agent initiateur : celui qui s’occupera de créer les sessions décisionnelles

– Un agent décideur : celui qui fait parti d’une session décisionnelle et représente unparticipant à la négociation.


4.4.2 Identification des acteurs concernésA l’authentification, la plateforme reconnait deux rôles d’agents : « agent administrateur »

et « agent utilisateur ». Le rôle d’utilisateur englobe les deux sous-rôles : « agent initiateur» et «agent décideur » (figure 4.3). Ceux-ci sont relatifs à une session et sont appliqués à unutilisateur selon le contexte comme le montre la figure 4.4.

Figure 4.3 – Identification des rôles dans la plateforme

Figure 4.4 – Diagramme montrant la navigation dans les espaces de travail selon le rôle

A l’authentification, si le compte utilisé est celui d’administrateur alors l’utilisateur est dirigévers l’espace dédié à l’administration des comptes. Sinon, l’utilisateur accède à un espace commun


permettant de créer et de consulter les sessions de travail auxquelles il est inscrit autant quedécideur ou initiateur. A partir de cet espace, et lors de l’accès à une session, l’utilisateur se verraappliquer le rôle d’initiateur ou de décideur selon la session. Dans ce qui suit nous exposons lesdétails de conception de la plateforme proposée.

4.4.3 Description de la plateforme de communication proposéeLa plateforme proposée s’articule, principalement, autour de deux sous-systèmes :

1. Le premier sous-système contenant les services web de type REST. Ce système met à ladisposition du client les services web qui assurent toutes les opérations de la plateforme(telles que la négociation ou encore la messagerie) en plus de communiquer avec une couchede persistance des données (base de données relationnelle).

2. Le second sous-système est une application cliente (JavaScript) consommant les services webdu premier système. Seules des données brutes sont échangées entre les deux systèmes (par lebiais de requêtes http), En plus d’interpréter les données et de générer l’interface utilisateur,l’application cliente contient un générateur graphique de formulaires.

La figure 4.5 illustre une vue d’ensemble de la plateforme proposée :

Figure 4.5 – La plateforme de communication proposée : vue d’ensemble


4.4.3.1 Les interactions dans la plateforme

Les interactions au sein de la plateforme sont sur deux niveaux :

– le premier niveau concerne l’interaction d’un utilisateur avec l’application cliente via soninterface,

– le second niveau concerne l’interaction de l’application cliente avec les services web via desrequêtes http.

Dans cette partie du chapitre, nous ne distinguons pas ces deux niveaux, en nous situant dansune perspective globale « utilisateur-plateforme ». Dans le contexte de ce travail nous appelons «session décisionnelle », « session de travail » ou encore simplement « session » ce qui s’apparenteà une réunion. Une session est créée par un utilisateur qui en devient l’initiateur (ou médiateur).Celui-ci constitue le groupe de travail en invitant d’autres utilisateurs qui joueront les rôles dedécideurs. Une session concerne un problème précis qui y sera discuté et pour lequel une solutionde groupe doit être trouvée. La figure 4.6 montre l’attribution des différents modules composantla plateforme relativement aux différents acteurs.

Figure 4.6 – Les acteurs et les modules dans la plateforme

4.4.3.2 Description des modules de la plateforme

Dans ce qui suit, nous décrivons les différents modules qui composent la plateforme [2].


4.4.3.2.1 Service web Authentification

L’authentification précède toute utilisation de la plateforme. Elle permet de confirmer l’identitéd’un utilisateur et son rôle. La plateforme reconnait deux rôles principaux : « administrateur » et« utilisateur ».

4.4.3.2.2 Service web Gestion des comptes utilisateurs

La création des comptes utilisateurs est à la charge de l’administrateur. A la création d’uncompte, l’administrateur peut spécifier si un utilisateur dispose du droit de créer des sessions detravail et d’y inviter d’autres utilisateurs. Si un utilisateur ne dispose pas de ce droit, il ne peutque participer aux sessions auxquelles il est invité.

Figure 4.7 – Diagramme de cas d’utilisation : Gestion comptes utilisateurs

La figure 4.7 présente le diagramme UML de cas d’utilisation correspondant à ce module de laplateforme. Elle illustre comment un administrateur gère les comptes utilisateurs et quelles sontles droits qu’il a sur ces derniers. A cet effet, il peut créer un utilisateur, le modifier, le supprimeret lui attribuer des droits de créer des sessions décisionnelles, toutes ces actions sont réalisées pardes services web.

4.4.3.2.3 Web Gestion des sessions

Un utilisateur qui dispose du droit de créer une session de travail peut créer une nouvelle sessionet y inviter d’autres utilisateurs. Au cours du processus décisionnel, l’acteur qui crée une sessionaura le rôle d’initiateur (ou médiateur), les invités sont des intervenants qui participeront pourleur totalité ou une partie d’entre eux dans la décision finale. Une session peut être paramétrée parl’initiateur. Les rôles d’initiateur et d’intervenant (ou décideur) sont donc dynamiquement affectésà un utilisateur, selon le contexte.


Figure 4.8 – Diagramme de cas d’utilisation : Gestion des sessions

La figure 4.8 présente le diagramme UML de cas d’utilisation correspondant à ce module dela plateforme. Elle illustre les actions qu’effectue un utilisateur pour la gestion des sessions, cesactions sont réalisées par des services web que nous détaillerons plus loin. Dans cette partie, nousdistinguons deux situations :

1. la première situation : Si l’utilisateur ne dispose pas de droits de sessions alors, il n’est qu’unsimple décideur qui a été invité par un initiateur à une session décisionnelle, il peut consulterla liste des sessions auxquelles il participe avec toutes les informations concernant ces sessions.

2. la deuxième situation : l’utilisateur est un agent initiateur, il peut alors créer une ou plusieurssession(s) décisionnelle(s), inscrire des participants à ces dernières, il a, aussi, la possibilitéd’attribuer aux décideurs l’anonymat, il peut décrire le rôle des décideurs et leur attribuerdes poids dans la décision de groupe.

4.4.3.2.4 Service web Messagerie

Le système de messagerie permet aux utilisateurs (décideurs ou initiateur) de diffuser des mes-sages au sein d’une session de travail qui seront visibles à la totalité des participants. La possibilitéd’échanges anonymes est aussi proposée. L’initiateur peut activer ou désactiver l’anonymat à n’im-porte quel moment du processus.


Figure 4.9 – Diagramme de cas d’utilisation : messagerie

La figure 4.9 présente le diagramme UML de cas d’utilisation correspondant à ce module de laplateforme. Elle illustre les actions de messagerie proposées par des services web. Les participants« décideurs » peuvent échanger des messages entre eux en postant un message dans une sessiondécisionnelle comme ils peuvent les lire. Quant à l’agent initiateur, il à la possibilité de bloquer ouautoriser la messagerie.

4.4.3.2.5 Service web Partage de documents

Au cours d’une session de travail, l’initiateur ainsi que les participants ont la possibilité d’échan-ger des documents. Pour ce faire, un utilisateur peut charger un document présent sur sa machine,le décrire puis l’envoyer aux autres utilisateurs. Le document leur sera accessible en téléchargement.


Figure 4.10 – Diagramme de cas d’utilisation : Partage de documents

La figure 4.10 présente le diagramme UML de cas d’utilisation correspondant à ce module dela plateforme. Elle illustre les actions mises à disposition pour assurer le partage de documentsà l’aide des services web. Dans cette partie, chaque utilisateur à la possibilité de charger et deposter un document pour le partager, il peut le décrire dans une section spécifique comme il peuttélécharger un document posté par un autre utilisateur.

4.4.3.2.6 Service web Système de formulaires

Un formulaire est un espace dédié au recueil d’informations. Il peut contenir plusieurs champsde différents types (liste déroulante, choix multiple, choix simple, date. . . etc). Le système de for-mulaires de la plateforme permet à l’initiateur d’une session de créer graphiquement un formulaireet de le diffuser à l’intention des participants. Ceux-ci sont appelés à renseigner ses champs et à leretourner. Les réponses individuelles ainsi qu’un résumé statistique de toutes les réponses sont misà la disposition de l’initiateur. Ce procédé permet en outre l’organisation de compagnes de votes,et constitue plus généralement un support à la consultation des participants et à la récolte de leurspréférences.


Figure 4.11 – Diagramme de cas d’utilisation : Système de formulaires

La figure 4.11 présente le diagramme UML de cas d’utilisation correspondant à ce module dela plateforme. Elle illustre les actions nécessaires pour la gestion de formulaires par les servicesweb. Les actions de l’agent initiateur sont : la création et la diffusion de formulaire ainsi que laconsultation des réponses des participants. Les agents participants « décideurs » peuvent :

– consulter les formulaires envoyés par l’agent initiateur,

– renseigner les informations demandées,

– répondre en envoyant le formulaire.

4.4.3.2.7 Service web Analyse multicritères

Afin de procurer une aide individuelle à la décision, la plateforme met à la disposition desutilisateurs une méthode d’analyse multicritères par agrégation partielle à savoir « PROMETHEEII ». C’est une méthode multicritères qui permet de résoudre la problématique de rangement afinde classer l’ensemble des solutions possibles (actions potentielles) de la « meilleure » vers la « pire».

1. Formulation du problème décisionnel La formulation multicritères du problème déci-sionnel de groupe abordé, dans la présente étude, est définie par le modèle (A, F , E, PS, d,P , Seuil) où :

– A : désigne l’ensemble des actions potentielles envisageables.

– F : est l’ensemble fini des attributs ou critères, généralement conflictuels, à partir des-quels les actions seront évaluées.

– E : est l’ensemble des performances (évaluations) des actions selon chacun des attributsou critères, c’est-à-dire l’ensemble des vecteurs de performances, un vecteur par action.

– PS : L’ensemble des paramètres subjectifs exprimés par le décideur.


– d : Le nombre de décideurs impliqués.

– P : Poids des décideurs

– Seuil : Seuil de négociation

2. Description de la méthode multicritères utilisée

La méthode PROMETHEE II fait intervenir les notions élémentaires de l’analyse multicri-tères, à savoir : un tableau (ou matrice) de performances, un ensemble fini de critères F etun ensemble fini d’actions A La famille PROMETHEE de manière générale associe à chaquecritère un poids exprimant son importance, ainsi qu’une fonction de préférence Pj définie dela manière suivante :Soit pour tout critère j de F :

dj(a, b) = gj(a)− gj(b) (4.1)

tel que a, b ∈ A et ∀ a ∈ A gj(a) est la performane de a pour le critère j.

Pj :

Pj(a, b) = 0 (indifférence entre a et b) si dj(a, b) = 0

Pj(a, b) ˜ 0 (préférence faible de a sur b) si dj(a, b) > 0Pj(a, b)˜ 1(préférence forte de a sur b) si dj(a, b)� 0

Pj(a, b) = 1 (préférence stricte de a sur b) si dj(a, b) ≫ 0

(4.2)

Il existe une infinité de fonctions qui satisfont cette définition. Les auteurs de PROMETHEEont en catégorisé six types qui semblent, selon les auteurs, recouvrir la plupart des besoinsrencontrés dans la réalité. La plupart de ces types sont définis en fonction de deux para-mètres : (p) (seuil de préférence) et (q) (seuil d’indifférence). Le seuil de préférence étantle seuil à partir duquel la différence entre deux actions (i.e : dj(a, b)) est perceptible et faitpréférer l’une à l’autre. Le seuil d’indifférence quant à lui est la plus petite différence qui estsignificative, en dessous de ce seuil il est impossible de départager deux actions. Les seuilsainsi que la fonction de préférences composent ce qu’on appelle les paramètres subjectifsintra-critère et les poids les paramètres subjectifs inter-critères. Nous citons ci-dessous deuxexemple de catégorie (voir [55] pour les autres cas) :

Fonctions linéaires : employée lorsque les seuils d’indifférence et de préférence stricte sontclairement apparents dans les données du problème multicritères posé, un seuil d’indifférence(q) et un seuil de préférence (p) seront utilisés [55].

P (d) :

0 d ≤ q

d− qp− q

q < d ≤ p

1 d > q

(4.3)


Figure 4.12 – Fonction de préférence linéaire [55]

Fonction en V : généralement employée lorsque les données sont telles que les écarts entreelles présentent un caractère continu, ou encore lorsque toutes les valeurs intermédiaires entreles valeurs maximales et minimales de ces écarts sont possibles, seul le seuil de préférence (p)est introduit [55].

P (d) :

0 d ≤ 0d

p0 ≤ d ≤ p

1 d > p

(4.4)

Figure 4.13 – Fonction de préférence en V [55]

La définition pour chaque critère de son poids, de sa fonction de préférence ainsi que desseuils de préférence et d’indifférence traduit ce qu’on appelle communément « l’expressiondes préférence ». Il s’agit de l’étape d’initialisation de la méthode Prométhée.

– La seconde étape consiste à calculer les indices de préférences globaux entre toutes lespaires d’actions. L’indice de préférence global d’une action (a) sur une action (b) estdonné par :

π(a, b) =∑

i∈F wj × Pj(a, b)∑i∈F wj

(4.5)

Où F est l’ensemble des critères, wj le poids du critère j et Pj la fonction de préférencepour le critère j. Cet indice représente le degré de préférence de (a) sur (b) en considérantsimultanément tous les critères. En comparant toutes les actions les unes par rapportaux autres, on obtient ainsi une matrice des degrés de préférences E.A la troisième étape on calcule pour chaque action (a) son flux sortant qui représente ladominance de (a)par rapport aux autres actions, noté Φ+(a) ainsi que son flux entrantqui représente la faiblesse de (a) par rapport aux autres actions Φ−(a) : (4.3) (4.4)


Φ+(a) =∑

b∈A π(a, b)n− 1 (4.6)

Φ−(a) =∑

b∈A π(b, a)n− 1 (4.7)

n nombre d’actions.

– La dernière étape consiste à calculer, pour toute action (a), son flux net noté Φ(a) parla formule :

Φ(a) = Φ+(a)− Φ−(a) (4.8)

Du flux net on déduit les relations suivantes pour toutes paires d’actions a, b :(a) est préférée à (b) ⇔ Φ(a) > Φ(b)(a) est indifférente à (b) ⇔ Φ(a) = Φ(b)

– Le classement final qui est un pré-ordre complet, est obtenu en rangeant les actions surla base de la valeur croissante de leur flux net agrégé.

La figure 4.14 illustre par un diagramme détaillé la démarche d’utilisation de PROMETHEEII [55].


Figure 4.14 – Démarche d’utilisation de PROMETHEE II

3. Pourquoi PROMETHEE II Les méthodes d’analyse multicritères de la famille PROME-THEE sont parmi les méthodes les plus utilisées dans la catégorie des méthodes de surclas-sement. Ceci est dû à un certain nombre d’avantages offerts par ces dernières.


– L’introduction de six fonctions de préférence différentes dans un seul et même processus ;il s’agit d’une extension de critère mais de façon bien formalisée [116].

– La simplicité de l’étape d’exploitation de la méthode.

– La puissance de sa fonction de préférence [55].

– Cette méthode est parvenue à intégrer de façon simple les développements récents dansla modélisation des préférences.

– PROMETHEE, quoique dépourvue d’une base mathématiques, a essayé de combler cemanque en procédant par la systématisation de la fonction de préférence. En effet, ledécideur, ayant à choisir la forme de sa préférence parmi six formes, se sentirait plutôtrassuré.

– La simplicité de PROMETHEE la place sur une bonne position pour être utilisée si oncherche à ranger des actions potentielles et que le décideur ne trouve pas beaucoup depeine à déterminer les poids des critères. Bien souvent cette méthode est sujette à desmodifications ou des extensions [116].

La figure 4.15 présente un pseudo-diagramme UML d’état transition correspondant. Elleillustre les étapes par lesquelles passe l’analyse multicritères par PROMETHEE II. Toutd’abord, chaque décideur doit charger la matrice de performances mise à sa disposition parl’initiateur, ensuite il introduit ses préférences puis il les envoie au système. A partir de cesdonnées, le système exécute la méthode PROMETHEE II, il génère, pour chaque décideur,le rangement effectué par la méthode qui consiste en un classement des actions potentiellesselon ses préférences.

Figure 4.15 – Diagramme d’état transition : Analyse multicritères par PROMETHEE II

4.4.3.2.8 Service web Protocole de négociation

La décision de groupe implique une multiplicité de points de vue, ce qui peut engendrer unconflit concernant les décisions à prendre. Nous avons vu précédemment que le système de for-mulaires permet d’organiser des compagnes de vote. Le vote est, par définition, une méthodepermettant de trancher parmi un groupe en faisant ressortir la préférence majoritaire. Cependant,


dans quelques situations, ce procédé peut créer des situations ambigües qui, si elles ne sont pasidentifiées et prises en charge, conduisent à ne pas prendre la meilleure décision. Pour illustrerce propos, nous prenons l’exemple d’une situation décisionnelle où trois décideurs doivent faire lechoix entre trois actions (ou options) A, B et C. Dans un premier temps, l’initiateur leur proposede faire un choix unique entre ces options. Chaque décideur va donc choisir l’option qu’il penseêtre la meilleure. Dans la figure 4.16, nous reportons les réponses avec un résumé en camembert :l’option A a été choisie par 66% des décideurs, l’option C par 33% des décideurs et finalementl’option B n’a été choisie par aucun décideur. C’est donc l’option A qui remporte le suffrage.[1]

Figure 4.16 – Formulaire choix simple : option A gagnante

Dans un second temps, l’initiateur décide de procéder différemment en demandant aux décideursde sélectionner les options qu’ils jugent acceptable via un formulaire à choix multiple. La figure4.17 reporte les réponses qui sont comme suit : l’option B a été choisie par 100% des décideurs,l’option A par 66% d’entre eux et enfin l’option C par 33% des décideurs.


Figure 4.17 – Formulaire choix multiple : option B gagnante

Dans un groupe de décideurs, l’importance des décideurs n’est pas toujours identique (c’estsouvent une organisation). Dans le cas où le décideur 3 est moins important que les décideurs1 et 2 et qu’au même moment, la préférence de ces derniers pour l’option A est beaucoup plusgrande que pour l’option B, c’est l’option A qui doit être retenue. A contrario, si la préférence desdécideurs 1 et 2 pour l’option A n’est que légèrement supérieure à celle pour l’option B, le sens duconsensus conduirait à choisir l’option B comme décision de groupe, car choisie par la totalité desparticipants. Ceci nous conduit à constater qu’une décision de groupe doit tenir compte de deuxnotions :

– L’importance d’un décideur, que nous pouvons qualifier formellement par un poids.

– Le degré de préférence qu’ont les décideurs vis-à-vis des actions potentielles.

De quelle manière, et qui soit la plus objective possible, un décideur peut-il qualifierses degrés de préférences pour les différentes options ?

Dans un contexte multicritères, l’analyse multicritères fournit des éléments de réponse à cettequestion. En effet, une méthode de la famille Gamma (rangement) nous permet de ranger lesactions de la « la moins bonne » vers la « meilleure » en tenant compte de l’expression despréférences du décideur pour les différents critères. Le rang peut, par exemple, être considérécomme « degré de préférence ». C’est en composant ces différents éléments de réflexion, qu’unprotocole de négociation, basé sur la méthode PROMETHEE II et intégrant les poids des décideurs,


a été proposé dans les travaux au sein de l’équipe de recherche dirigée par Mme HAMDADOU.Nous proposons dans notre travail d’apporter une modification au protocole considéré. En effet,nous intégrons dans l’une de ses étapes une phase de décision individuelle permettant à chaquedécideur de classer ses actions selon ses préférences par la méthode PROMETHEEII et réaliser,par conséquent, le scorage des actions par les formules (4.9) et (4.10) qui sont mentionnées etdétaillées plus loin. L’objectif du protocole de négociation que nous intégrons à la plateforme estde permettre de mener un groupe à un consensus concernant la décision à prendre vis-à-vis unproblème multicritères. A ce titre, nous distinguons deux rôles dans la négociation.

1. Initiateur : C’est celui qui est responsable de la gestion de la négociation et de la modificationde contrat (proposition).

2. Participants : Ce sont tous ceux qui sont concernés par la décision, le but de chacun d’entreeux est que sa ressource (action potentielle) préférée soit choisie.

A Les phases de la négociation

Le protocole de négociation est caractérisé par une suite de messages échangés entre l’initiateuret les différents participants. Il procède en 5 principales phases : la phase d’initialisation, la phasede proposition, la phase d’évaluation, la phase de modification, et enfin la phase de décision.

1. Phase d’initialisation Cette étape désigne le début de la négociation, les participants sontappelés, par l’initiateur, à exprimer leurs préférences concernant les ressources. Chaque par-ticipant effectue un classement des ressources de la meilleure à la moins bonne et l’envoie àl’initiateur.

2. Phase de proposition L’initiateur propose un contrat (proposition d’une ressource donnée)à tous les participants. Ces derniers vont soit accepter ce contrat, soit le refuser selon leurspréférences.

3. Phase d’évaluation Lorsque l’initiateur reçoit toutes les réponses des participants concernantune proposition de contrat, il comptabilise le nombre de participants ayant accepté sa pro-position. Si ce nombre est supérieur ou égal au seuil (fixé au début de la négociation), alorsla négociation est un succès sinon il doit procéder à une modification du contrat.

4. Phase de modification Lors de cette étape, l’initiateur doit faire une modification du contraten s’inspirant des propositions des participants. Il doit reformuler une nouvelle proposition àpartir du vecteur établi par les préférences de tous les participants puis revient à l’étape deproposition.

5. Phase de décision C’est la dernière étape du protocole suggéré. Elle est synonyme de la finde la négociation, une décision est prise par l’initiateur selon les réponses des participantsaux propositions qu’il leur a faites. Il clôture ensuite la négociation soit par un succès soitpar un échec.

B Les caractéristiques du protocole de négociation

Il y a certains aspects qu’il faut prendre en considération pendant la négociation : l’objet de lanégociation, la cardinalité de la négociation, le langage de la négociation, les stratégies des différentsdécideurs. Dans ce qui suit, nous détaillerons ces aspects dans le contexte de notre protocole.


B.1 L’objet de la négociation

Les ressources sont les objets de la négociation. Dans notre cas, ce sont des ressources communes(les actions). Ces ressources vont être négociées tout le long du processus de négociation à traversle protocole jusqu’à ce que l’une d’elle soit choisie comme étant la meilleure ressource pour tousles participants (un accord mutuellement acceptable).

B.2 La cardinalité de la négociation

Cet aspect nous permet de connaitre le déroulement de la négociation et puisque nous avonsun initiateur qui communique avec le reste des participants donc notre cardinalité est de 1 à ndécideurs.

B.3 Le langage de négociation

Le langage de négociation adopté par le protocole proposé, est un échange de messages entrel’agent initiateur et les agents participants appelés primitives. Dans cette optique, on définit desprimitives spécifiques à l’initiateur et d’autres primitives spécifiques aux participants.

B.3.1 Les primitives de l’initiateur

Les messages envoyés par le médiateur sont destinés à tous les acteurs participants. Nous luiassocions, par conséquent, quatre primitives de négociation :

1. REQUEST () : l’initiateur envoie ce message aux participants pour leurs indiquer le débutde la négociation. Chaque participant doit associer à chaque ressource figurant dans sonvecteur de préférence un rang en utilisant une méthode d’analyse multicritères de rangement.

2. PROPOSE () : l’initiateur propose un contrat (proposition d’une ressource (action)) aprèsavoir effectué un scorage de toutes les ressources.

3. CONFIRM () : l’initiateur envoie ce message aux participants pour les informer que lanégociation est terminée avec succès tout en leur indiquant la ressource choisie.

4. FAILURE () : l’initiateur envoie ce message aux participants pour les informer que lanégociation est terminée mais avec échec.

B.3.2 Les primitives des participants

Les messages envoyés par les participants sont uniquement destinés à l’initiateur. Un participantdispose de trois primitives de négociation :

1. INFORM () : les participants envoient ce message à l’initiateur après avoir effectué lerangement des actions et obtenu des vecteurs de préférences par analyse multicritères. Cemessage contient le vecteur de classement des ressources.

2. ACCEPT_PROPOSAL () : ce message est envoyé à l’initiateur, après avoir reçu uneproposition par ce dernier, pour l’informer qu’il accepte la proposition.

3. REJECT_PROPOSAL () : ce message est envoyé à l’initiateur, après avoir reçu uneproposition par ce dernier, pour l’informer qu’il rejette la proposition.


C Les stratégies des décideurs

La négociation se déroule en plusieurs tours jusqu’à ce qu’un compromis qui satisfait la majoritédes agents soit trouvé. L’initiateur fait une proposition aux participants concernant une ressource(action) donnée, ces derniers vont soit accepter soit refuser la proposition. La stratégie du coor-dinateur lui permet de modifier sa proposition dans le cas où les participants n’ont pas été asseznombreux à l’accepter tandis que la stratégie associée aux participants leur permet d’accepter laproposition du coordinateur ou de la refuser.

C.1 Stratégie de l’initiateur

1. Stratégie de début de négociation : Pour commencer la négociation, l’initiateur envoieun message REQUEST à tous les participants.

2. Stratégie de scorage des ressources Après avoir envoyé le message REQUEST, l’ini-tiateur se met en attente de la réception des messages INFORM contenant les vecteurs depréférences des participants. Après réception de ces derniers, l’initiateur effectue un scoragedes ressources pour n’obtenir qu’un seul vecteur de préférence synthétisant ceux de tous lesparticipants.Le score global d’une action représente l’agrégation des préférences de tous les décideursrelativement à cette action, il est calculé selon les étapes suivantes : Pour chaque décideur :calculer les rangs et les flux des actions par la méthode PROMETHEE II.Pour une action i :Wj poids du décideur j.

(a) Score par rang :

score(i) =∑

decideurj

wj × (nbActions+ 1− rang(i)) (4.9)

(b) Score par flux :score(i) =

∑decideurj

wj × fluxnet(i) (4.10)

Remarque : dans la première version du protocole dont nous nous inspirons [53] [54]. Lescore est calculé à partir du rang des actions et non pas à partir du flux net (donné parPROMETHEE II).Nous avons proposé la 2ème alternative (rangement à partir du flux net) afin d’enrichir lanotion de « degré de préférence » et justifions notre choix par l’exemple suivant : Pour deuxactions qui se suivent au sens du rang, nous savons, par leurs rangs, quelle action est meilleuremais pas de « combien ». Le flux net étant, par définition, une indication sur la qualité d’uneaction, il nous semble qu’il permettrait de quantifier les différences avec plus de précision etdans la partie expérimentations nous testons les deux formules.

3. Stratégie de la 1ère proposition : Après avoir effectué le scorage, l’initiateur génère unseul vecteur de préférence en triant les ressources de la meilleure (celle avec le plus grandnombre de points) vers la pire (celle avec le plus petit nombre de points), et envoie comme1ère proposition (à tous les participants) la ressource la mieux classée en utilisant le messagePROPOSE.

4. Stratégie d’évaluation : Après avoir envoyé la 1ère proposition, l’initiateur attend les ré-ponses des participants qui se matérialisent par l’acceptation ou bien le rejet de la proposition


en question, et agit selon les réponses reçues, il évalue les réponses et génère un taux d’ac-ceptation qui correspond au nombre de participants ayant accepté la proposition. Si le tauxd’acceptation est supérieur au seuil de négociation, l’initiateur applique la stratégie de suc-cès de négociation, sinon si le taux est inférieur au seuil de négociation, alors il applique lastratégie de modification, si le nombre de tours maximal est atteint et qu’aucune ressourcen’a été validé alors la négociation est un échec.

5. Stratégie de modification : L’initiateur propose aux participants la ressource suivantedans le vecteur de préférence et applique de nouveau la stratégie de négociation. Il procèdede la même manière dans les prochains tours jusqu’à la fin de la négociation.

6. Stratégie de succès de négociation : L’initiateur envoie un message CONFIRM accom-pagné par la ressource choisie pour annoncer la fin de la négociation avec un succès.

7. Stratégie d’échec de négociation : L’initiateur envoie le message FAILURE aux partici-pants pour les informer que la négociation a échouée.

C.2 Stratégie des participants

1. Stratégie de détermination des préférences des agents participants : Lors de la ré-ception du message REQUEST de la part de l’initiateur, les participants appellent la méthodemulticritères PROMETHEE II pour ranger les actions et générer le vecteur de préférence.

2. Stratégie d’acceptation ou de refus de proposition : A la réception de chaque nouvelleproposition dans un nouveau tour, les participants doivent soit accepter la proposition soitla refuser. Pour pouvoir prendre une décision, un participant (décideur) consulte son vecteurde préférence, en effet, si cette proposition (ressource = action) se trouve dans la premièremoitié de son vecteur de préférence, alors il accepte la proposition en envoyant un messageACCEPT_PROPOSAL, sinon il la rejette en envoyant le message REJECT_PROPOSAL.

3. Stratégie de fin de négociation : La négociation peut se terminer de deux manières, avecun succès ou avec un échec.

Cas de succès : Quand un participant reçoit un message CONFIRM de la part de l’initiateur,alors il saura que la négociation a réussi, il enregistre la proposition retenue et envoie un messageAGREE pour accuser réception à l’initiateur qu’il a bien reçu la proposition.Cas d’échec : Quand le participant reçoit le message FAILURE de la part de l’initiateur, alors ilsaura que la négociation a échoué. Les étapes du protocole sont schématisées et synthétisées parle diagramme de la figure 4.18, et sont décrites dans ce qui suit :


Figure 4.18 – Etapes du protocole de négociation

Les différentes étapes du protocole sont résumées comme suit :

1. L’initiateur charge une matrice de performance, puis l’envoie aux participants.

2. Les participants sont invités à introduire leurs préférences quant aux critères (intra critèreset inter critères).

3. Calcul des scores totaux des actions par les formules (4.9) et (4.10).

4. D’après les scores calculés à l’étape 3, proposer aux décideurs l’action ayant le score le plusélevé n’ayant pas encore été proposée.

5. Chaque décideur a le choix entre accepter ou refuser la proposition reçue en se référant àleurs vecteurs de préférences.

6. Après réception de toutes les réponses de la part des décideurs, l’action proposée est validéesi le taux d’acceptation est supérieur à un seuil défini par l’initiateur. Dans le cas contraire,et si le nombre de tours maximal (définit également par l’initiateur) n’est pas encore atteint,aller à 4. Dans le cas où le nombre de tours maximal est atteint et qu’aucun compromis n’aété trouvé, l’échec est notifié aux utilisateurs.

Les algorithmes suivants résument les étapes du protocole mentionné dans la figure 4.18. Nousproposons deux versions : Algorithme 4.1 et Algorithme 4.2 utilisant respectivement les formules(4.9) et (4.10).

Algorithme 1 : protocole de négociation proposé utilisant le rang des actions

DébutEntrées :A : l’ensemble des actions ;F : la famille des critères ;


MP : la matrice de performance ;Pk : les préférences de chaque décideur (seuil de préférence, seuil d’indifférence, poids des critères) ;D : nbre de décideurs.Wj : le poids du décideur j. j=1, D.Rang : le rang de l’action par rapport aux autres actions donné par PROMETHEE II.Nb_Actions : le nombre d’actions dans MP.Nbre_tours maximal : condition d’arrêt de la négociation.Seuil d’acceptation : c’est le seuil d’acceptation pour valider une action donnée ;Sorties : Décision finale ce qui correspond à l’échec ou le succès de la négociation.1 Etape d’initialisationREQUEST () : l’initiateur lance la négociation et demande le vecteur de préférences de chaquedécideur (rangement des actions par PROMETHEE II) ;PROMETHEE II : Phase d’agrégation Calcul des intensités de préférences ;Calcul des indicateurs de préférences ;PROMETHEE II : Phase d’exploitationCalcul du flux positif ;Calcul du flux négatif ;Calcul du flux net ;INFORM () : chaque décideur envoie le vecteur de préférences généré par PROMETHEE IICalcul du score de chaque action :

score(i) =∑

decideurj

wj × (nb_Actions+ 1− rang(i)) (4.11)

i=1, Nb_Actions et j=1, D.2 Etape de propositionPROPOSE () Proposition de l’action ayant le score le plus élevé.3 Etapes d’évaluationSI (l’action correspond au vecteur de préférences) Alors ACCEPT_PROPOSAL()Sinon REJECT_PROPOSAL()4 Etape de modificationSi [(le taux d’acceptation < seuil d’acceptation) Et (Nbre_tours effectués < Nbre_tours maximal)]Alors PROPOSE ()5 Etape de décisionSi (le taux d’acceptation >= seuil d’acceptation)Alors CONFIRM () // la négociation est un succèsSinonFAILURE ()// la négociation est un EchecSi (Nbre_tours effectués > Nbre_tours maximal)Alors FAILURE ()// la négociation est un échecFin.


Algorithme 2 : protocole de négociation proposé utilisant le flux net des actions

DébutEntrées :A : l’ensemble des actions ;F : la famille des critères ;MP : la matrice de performance ;Pk : les préférences de chaque décideur (seuil de préférence, seuil d’indifférence, poids des critères) ;D : nbre de décideurs.Wj : le poids du décideur j. j=1, D.Nb_Actions : le nombre d’actions dans MP.Nbre_tours maximal : condition d’arrêt de la négociation.Seuil d’acceptation : c’est le seuil d’acceptation pour valider une action donnée ;Sorties : Décision finale ce qui correspond à l’échec ou le succès de la négociation.1 Etape d’initialisationREQUEST () : l’initiateur lance la négociation et demande le vecteur de préférences de chaquedécideur (rangement des actions par PROMETHEE II) ;PROMETHEE II : Phase d’agrégation Calcul des intensités de préférences ;Calcul des indicateurs de préférences ;PROMETHEE II : Phase d’exploitationCalcul du flux positif ;Calcul du flux négatif ;Calcul du flux net ;INFORM () : chaque décideur envoie le vecteur de préférences généré par PROMETHEE IICalcul du score de chaque action :

score(i) =∑

decideurj

wj × fluxnet(i) (4.12)

i=1 et j=1, D.2 Etape de propositionPROPOSE () Proposition de l’action ayant le score le plus élevé.3 Etapes d’évaluationSI (l’action correspond au vecteur de préférences) Alors ACCEPT_PROPOSAL()Sinon REJECT_PROPOSAL()4 Etape de modificationSi [(le taux d’acceptation < seuil d’acceptation) Et (Nbre_tours effectués < Nbre_tours maximal)]Alors PROPOSE ()5 Etape de décisionSi (le taux d’acceptation >= seuil d’acceptation)Alors CONFIRM () // la négociation est un succèsSinonFAILURE ()// la négociation est un EchecSi (Nbre_tours effectués > Nbre_tours maximal)Alors FAILURE ()// la négociation est un échecFin.


D Modélisation du protocole de la négociation

Afin de représenter les interactions entre l’agent initiateur et les agents participants, nous optonspour la modélisation UML, souvent utilisée pour décrire l’interaction des différentes entités. Lafigure 4.19 représente le diagramme de séquence UML associé au processus de négociation proposé[2].

Figure 4.19 – Diagramme de séquences du protocole de Négociation proposé

4.5 la démarche décisionnelle adopté par le système d’aideà la décision

Nous avons jugé utile d’associer à la description du processus décisionnel, un organigramme(figure 4.20) synthétisant les étapes de la démarche décisionnelle adopté par le système d’aide à ladécision de groupe proposé.


Figure 4.20 – La démarche décisionnelle adoptée par le système d’aide à la décision de groupe


4.6 Description des services webComme dit précédemment, la plateforme est composée d’une application cliente utilisant des

services web. Les échanges entre les deux systèmes sont réalisés à l’aide des requêtes http. Lesservices web (de type REST) exposent les fonctionnalités permettant d’interagir avec le systèmed’information et d’exécuter des opérations telle que l’analyse multicritères. La mise en place d’unservice web REST doit prendre en compte trois éléments principaux [2] :

1. Des Uri (Uniform Resource Identifier) pour identifier les ressources. Une application se doitde construire ses URI (et donc ses URL) de manière précise. Il est nécessaire de prendre encompte la hiérarchie des ressources et la sémantique des URL pour les éditer. Nous montronsplus loin chaque Uri des services web utilisé.

2. les méthodes http pour définir l’action : consistent à utiliser les verbes HTTP existantsplutôt que d’inclure l’opération dans l’URI de la ressource. Ainsi, pour une ressource, il ya, principalement, 4 opérations possibles : Get, Post, Put et Delete. Nous montrons leurutilisation dans notre plateforme dans les tableaux résumant nos services web.

3. le type de représentation des données : Les représentations les plus utilisées sont leXML et le JSON. Cependant, un bref comparatif entre ces deux types nous fera préférer lareprésentation JSON. En effet, le XML est plus « verbeux 3 » à expliquer en bas de page quele JSON, ce qui implique un coût sur la taille des données échangées (figure 4.21).

Figure 4.21 – Comparaison taille message JSON – XML

Nous présentons dans ce qui suit les fonctionnalités identifiées par des Uri et des méthodes httpexposées par les services web. Nous donnons aussi le diagramme des classes utilisées pour modéliserle système d’information, et ceci sur plusieurs schémas (ou perspectives) par un souci de lisibilité.’

– Authentification et gestion des utilisateurs :

3. Comporte plus « caractères » que le JSON par conséquent la taille du message est plus grande


Figure 4.22 – Diagramme de classes : perspective = utilisateur

Uri http mé-thode

Méthode exécutée Note

/authenticate GET authenticate() Retourner l’état de vali-dité des informations.

/Users GET getListUsers() Retourner la liste des uti-lisateurs avec le rôle.

POST createUser(User) Créer l’utilisateur avecrôle.

/Users/userId PUT updateUser(userId, User) Mettre à jour l’utilisateur.DELETE removeUser(userId) Supprimer l’utilisateur

userId.

Table 4.3 – Services web d’authentification et gestion des utilisateurs

Remarque : dans ce qui suit tous les Uri sont préfixés par « /decisionsession », les ressourcesà décrire étant des sous-ressources de la ressource « DecisionSession ».

– Service web gestion des sessions :


Figure 4.23 – Diagramme de classes : perspective = Session

Uri http mé-thode


GET getListSession() Retourner la liste des ses-sions.

POST createSession(Session) Créer la session./sessionId GET getSession(sessionId) Retourner la session cor-

respondante.PUT updateSession(sessionId,Session) Mettre à jour la session.DELETE removeSession(sessionId) Supprimer la session.

/sessionId/users GET getSessionUsers(sessionId) Retourner la liste des uti-lisateurs inscrits à la ses-sion

POST addUserToSession(sessionId, UserSes-sion)

Ajouter un utilisateur à lasession

Table 4.4 – Services web de gestion des sessions

– Service web gestion des messages :

Figure 4.24 – Diagramme de classes : perspective = message


Uri http mé-thode


/sessionId /mes-sages

GET getMessages(sessionId) Retourner la liste des mes-sages de la session

POST postMessage(sessionId, userId, Mes-sage)

Poster un message dansla session. L’envoyeur estidentifié par userId : para-mètre dans l’Uri

/sessionId/docu /upload

POST uploadDocument(sessionId, Docu-ment)

Enregistrer le documentenvoyé et créer un messagedans la session avec le do-cument attaché.

/sessionId/download/msgId

GET downloadAttachedDocument (msgId) Envoyer le document at-taché au message “messa-geId”

Table 4.5 – Services web de gestion des documents

– Service web gestion des formulaires :


Figure 4.25 – Diagramme de classes : perspective = formulaire

.


Uri http mé-thode


/sessionId/forms

GET getForms(sessionId) Retourner les formulairesenregistrés dans la session

POST createForm(sessionId, Form,List<User>)

Créer le formulaire etla liste des destinataires.Ajouter le formulaire à lasession. Créer pour chaquedestinataire une réponse(FormResponse) par dé-faut.

/sessionId/forms /for-mId/

PUT updateForm(formId, Form,List<User>)

Mettre à jour le formulaire

DELETE deleteForm(formId) Supprimer le formulaire/sessionId/formresponse

GET getFormResponses(sessionId) Retourner la liste des ré-ponses aux formulaires dela session.

/sessionId/formresponse/respId

PUT updateFormResponse(respId, Form-Response)

Mettre à jour la réponse.

Table 4.6 – Services web de gestion des formulaires

– Service web analyse multicritères :


Figure 4.26 – Diagramme de classes : Analyse multicritères


Uri http mé-thode


/sessionId/amc GET getListAmcInstance(sessionId) Retourner la liste des ins-tances multicritères de lasession (critères, actions etmatrice de performance)

POST createAmcInstance(sessionId, Excel-File)

Créer une instance multi-critères (critères, action etmatrice de performances)à partir d’un fichier Exceldans la session. Créer desparamètres subjectifs pardéfault.

/sessionId/amc /am-cId/subjparams

GET getSubjectiveParams(amcId) Retourner les paramètressubjectifs de l’instance.

PUT updateSubjParams(amcId, Subjective-Params)

Mettre à jours les pa-ramètres subjectifs del’instance amcId. Lan-cer PROMETHEE IIsur l’instance avec lesparamètres mis à jour

/sessionId/amc /am-cId/promethee

GET getPrometheeResults(amcId) Retourner les résultats dePrometheeII sur l’instanceamcId.

Table 4.7 – Services web de l’analyse multicritères

4.7 La Synchronisation des échangesUn aspect important de la plateforme est la gestion de la synchronisation des échanges. En

effet, il est important que les changements et les nouvelles données telles les messages soient ré-percutés auprès des utilisateurs concernés en temps réel. C’est un aspect qui doit d’autant plusêtre explicitement pris en charge dans le contexte d’une application basée sur les standards du web.

En effet, dans un scénario HTTP requête-réponse classique, le client ouvre une connexion puisenvoie une requête HTTP au serveur. Ce dernier renvoie la réponse HTTP appropriée avant defermer la connexion une fois l’échange totalement achevé. L’initiative est toujours du fait du client.Cela pose évidemment problème car le serveur ne peut initier l’échange afin de, par exemple, no-tifier des changements ou envoyer de nouvelles données. Il existe des techniques afin de palier à cemanquement, les plus connues sont : le « Polling » et le « long polling ».

Avec la méthode du « polling » le client envoie périodiquement des requêtes au serveur afinde récupérer de nouvelles données s’il y en a. Après sa réponse, le serveur ferme la connexion etle client devra renvoyer une autre requête après une période de temps. L’inconvénient de cette


technique est clair ; une trop grande sollicitation du serveur pour (selon le cas) un grand nombrede requêtes vaines.

La technique du « long polling » quant à elle repose sur une autre logique. Le client envoieune requête HTTP et le serveur, s’il ne possède pas de nouvelles données, maintient la connexionouverte jusqu’à ce que des données soient disponibles. Celles-ci sont alors envoyées au client puis laconnexion est fermée. Au client de renvoyer une autre requête pour maintenir le processus. Cettetechnique présente l’avantage de réduire le nombre de requêtes envoyées. C’est donc cette techniquequi a été retenue pour la synchronisation des données au sein de la plateforme proposée dans leprésent travail.

4.8 ConclusionNous avons présenté dans ce chapitre notre contribution qui porte sur la proposition d’un

modèle de processus d’aide à la décision de groupe ainsi que les différents éléments de conceptionet de modélisation relatifs à ce modèle. Ce modèle a permis la mise en place d’un système d’aideà la décision multicritères de groupe, il intègre principalement :

– Une plateforme de communication basée service web que nous avons détaillé à travers tousles modules la composant.

– Un système multi agents permettant la modélisation des différents acteurs du processusdécisionnel.

– Un protocole de négociation qui permet de rechercher un compromis satisfaisant les différentsparticipants.

– Une méthode d’analyse multicritères PROMETHEE II intégrée dans le protocole de négo-ciation permettant aux décideurs d’exprimer leurs préférences.

Différents diagrammes de cas d’utilisation ont été présentés ainsi que les détails concernant laméthode d’analyse multicritères choisie (PROMETHEE II) et le protocole de négociation intégré.Dans le chapitre suivant, nous présenterons un cas d’étude dans le domaine de l’aménagement duterritoire. Il s’agit d’aider un ensemble de décideur à choisir un terrain parmi une multitude deterrains satisfaisant un certain nombre de critères pour un projet de construction d’une habitationafin de valider notre modèle proposé et nous accompagnerons le scénario par une discussion desrésultats obtenus.

Chapitre 5

Expérimentation et résultatsobtenus

5.1 IntroductionCe chapitre concerne la description de la mise en œuvre de la plateforme proposée. Nous y

abordons les technologies utilisées et y donnons un aperçu des différents espaces qui la composent.Aussi, nous y déroulons un scénario d’une situation décisionnelle de groupe concernant un problèmedécisionnel multicritères spatial.

5.2 Technologies utiliséesLa mise en œuvre des services web a été faite à l’aide du Framework Jersey 2.x. Jersey est un

Framework open-source, développé par Oracle, écrit en langage Java permettant de développer desservices web selon l’architecture REST suivant les spécifications JAX-RS (spécification Java pourles Restfull web services)[138]. Nous pouvons schématiser notre application web par la figure 5.1.

Figure 5.1 – Echange client web/ Serveur web

Dans la figure 5.1, nous montrons le niveau client de l’application (1), les serveurs (2) et (3)et la base de données (4). Dans ce qui suit, nous spécifions pour chacun de ces composants l’outilutilisé.

Chapitre 5.Expérimentation et résultats obtenus 101

5.2.1 GWTGWT est un ensemble d’outils logiciels permettant de créer et maintenir des applications web

dynamiques mettant en œuvre JavaScript. Le principal avantage de cet outil est que lors de la phasede développement, l’application est écrite en Java de façon classique, dans un environnement dedéveloppement intégré Java, et peut être déboguée avec les outils Java habituels.Une fois l’application prête à être déployée, le compilateur GWT la traduit en pur JavaScript, avecsupport automatique et transparent pour les principaux navigateurs (Internet Explorer, Firefox,Chrome, Safari, Opera). Le code JavaScript généré utilise des techniques d’HTML dynamique[133].

5.2.2 Tomcat 7.0Le rôle du serveur web est de recevoir les requêtes du client et de les traiter pour ensuite lui

répondre. Nous distinguons deux types de serveur : un serveur web (2) et un serveur d’application(3) dans la figure 5.1.Le premier a pour rôle de traiter les requêtes http entrantes et le deuxième d’exécuter les requêteset renvoie la réponse en passant par la consultation d’une base de données si nécessaire (4).

Ces deux serveurs sont complémentaires puisque le serveur d’application ne sait pas traiter unerequête http et le serveur web ne sait pas l’exécuter c’est pourquoi nous avons opté pour Tomcat« un serveur http » car il inclut les deux serveurs.

5.2.3 PostgreSQLLa persistance des données de notre application (4) dans la figure 5.1 est réalisée sur le SGBDR

(Système de Gestion de Base de Données Relationnelle) libre PostgreSQL. PostgreSQL est unsystème de gestion de base de données relationnelle et objet (SGBDRO). C’est un outil libre dis-ponible selon les termes d’une licence de type BSD. Ce système est concurrent à d’autres systèmesde gestion de base de données, qu’ils soient libres (comme MariaDB et Firebird), ou propriétaires(comme Oracle, MySQL, Sybase, DB2, Informix et Microsoft SQL Server).

5.2.4 JadeJADE (Java Agent DEvelopement framework) est une plateforme gratuite, implémentée en

JAVA qui respecte les spécifications FIPA (Foundation of Intelligent Physical Agents) que nousavons utilisé pour modéliser les agents de la négociation.

5.2.4.1 Architecture de JADE

La plateforme JADE est composée de conteneurs d’agents (agent container) qui peuvent êtredistribués sur le réseau (figure 5.2). Les agents vivent dans les conteneurs qui sont des processusjava qui fournissent tous les services nécessaires pour l’hébergement et l’exécution des agents. Laplateforme doit disposer d’un conteneur principal qui représente le point de démarrage, et qui secharge de :

– Gérer la table des conteneurs qui contient la liste ainsi que les adresses de tous les conteneursqui composent la plateforme.

– Gérer la GADT (Global Agent Description Table) qui contient la liste de tous les agentsprésents dans la plateforme, leur statut actuel, et leur localisation.


– Héberger l’AMS (Agent Management System) et DF (Directory Facilitator) qui fournissentla gestion des agents, et le service des pages blanches ainsi que le service des pages jaunesrespectivement.

Figure 5.2 – Architecture de la plateforme JADE

5.2.4.2 Outils de control et de débogage

Les applications multi agents sont, en général, très compliquées. Elles sont souvent distribuéessur plusieurs hôtes avec plusieurs conteneurs et agents, elles sont aussi dynamiques dans le sens oùles agents apparaissent, disparaissent, et migrent d’un conteneur à un autre. Tout ça rend le controlet le débogage une tâche fastidieuse pour le programmeur. JADE offre plusieurs outils graphiquesqui simplifient considérablement le travail du programmeur, on trouve entre autres :

Agent RMA

Le RMA (Remote Management Agent) permet de contrôler le cycle de vie de la plate-forme ettous les agents qui la composent. Plusieurs RMA peuvent être lancés sur la même plate-forme dumoment qu’ils ont des noms distincts, la figure 5.3 présente l’interface graphique de cet agent.

Figure 5.3 – Agent RMA


Agent Dummy

L’outil DummyAgent permet aux utilisateurs d’interagir avec les agents JADE d’une façonparticulière. L’interface permet la composition et l’envoi de messages ACL et maintient une listede messages ACL envoyés et reçus. Cette liste peut être examinée par l’utilisateur et chaque messagepeut être vu en détail ou même édité. Plus encore, le message peut être sauvegardé sur le disqueet renvoyé plus tard. L’interface de l’agent Dummy est illustrée par la figure 5.4.

Figure 5.4 – Agent Dummy

Agent Sniffer

Quand un utilisateur décide d’épier un agent ou un groupe d’agents, il utilise un agent Sniffer.Chaque message partant ou allant vers ce groupe est capté et affiché sur l’interface du sniffer.L’utilisateur peut voir et enregistrer tous les messages, pour éventuellement les analyser plus tard.L’interface de l’agent Sniffer est illustrée par la figure 5.5.


Figure 5.5 – Agent Sniffer

5.3 Espaces d’utilisationNous donnons, dans ce qui suit, un bref aperçu des différents espaces de travail, à savoir :

l’espace administrateur, l’espace initiateur et l’espace décideur.

5.3.1 Espace administrateurL’authentification par le compte administrateur mène à l’espace d’administration des utilisa-

teurs. La figure 5.6 montre cette étape ainsi que les services web utilisés [2].

Figure 5.6 – Authentification par compte administrateur

La figure 5.7 montre l’intervention de l’administrateur dans cet espace et montre aussi lesservices web correspondants à cette étape :

– consulter un utilisateur (Figure 5.7),

– créer un utilisateur (Figure 5.8)

– modifier un utilisateur.


Figure 5.7 – Espace administrateur – consultation des comptes utilisateurs

A la création d’un utilisateur, l’administrateur doit :

– Spécifier les informations usuelles (nom d’utilisateur et mot de passe).

– Spécifier le droit de l’utilisateur à la création de sessions de travail.

– Mettre le compte à l’état actif ou inactif. Un compte en état inactif ne permet pas de seconnecter à la plateforme.

La figure 5.8 montre cette étape ainsi que les services web correspondants [2].

Figure 5.8 – Espace administrateur – création d’un utilisateur

5.3.2 Espace utilisateurToute connexion par un compte non administrateur (figure 5.9) conduit à un espace commun

appelé espace utilisateur. A cette étape, l’utilisateur n’a encore aucun des rôles d’initiateur ou dedécideur. Cet espace permet à l’utilisateur de :

– Consulter les sessions auxquelles participe l’utilisateur autant que décideur ou qu’initiateur(figure 5.10).

– Créer (s’il en possède les droits) une session de travail.

– Sélectionner une session et y accéder.


Figure 5.9 – Authentification avec un compte non administrateur

Figure 5.10 – Espace utilisateur – liste des sessions

5.3.2.1 Création d’une session

Comme montré dans la figure 5.11, un utilisateur disposant du droit de création peut créer unesession de travail selon les étapes suivantes :

– Définir le sujet et introduire un commentaire sur les objectifs de la session. (figure 5.12)

– Activer ou non l’anonymat sur les messages échangés. Cette option peut être modifiée aucours du processus.

– Inscrire des participants.

– Commenter le rôle de chaque participant (décideur) et introduire son poids. Le poids d’unparticipant traduit son importance au sein du groupe, et sera utilisé dans les comptes rendusdes formulaires ainsi que dans le processus de négociation.


Figure 5.11 – Espace utilisateur – Création d’une session et inscription des participants avecattribution des poids

Figure 5.12 – Espace utilisateur : création d’une session

5.3.2.2 Accès à une session

A partir de l’espace commun, un utilisateur peut sélectionner une session à laquelle il est inscritet y accéder. Selon son rôle dans cette session, il sera dirigé vers l’espace initiateur (figure 5.12) oul’espace décideur (figure 5.13). L’espace initiateur permet :

– L’accès à la messagerie et au partage de documents.

– La gestion de l’anonymat.

– La création et diffusion de formulaires.

– La consultation des réponses aux formulaires et des résumés statistiques.

– La création et diffusion d’instances multicritères.

– Le lancement du protocole de négociation.


Figure 5.13 – Espace initiateur : sommaire des réponses de formulaires

L’espace décideur est illustré par la figure 5.13 avec les services web correspondant à cetteétape, il permet :

– L’accès à la messagerie et au partage de documents.

– La consultation des formulaires reçus et l’envoi de réponses.

– La création d’instances multicritères (à titre individuel).

– La réception des instances multicritères envoyées par l’initiateur.

– La participation au protocole de négociation.

Figure 5.14 – Espace décideur choix des critères

5.4 Scénario illustratifAfin de mettre en exergue l’apport de la plateforme dans la décision de groupe, nous allons

dans ce qui suit dérouler un scénario faisant intervenir plusieurs décideurs travaillant à trouver unesolution à un problème décisionnel multicritères et spatial.Le postulat du scénario est le suivant : un groupe fait face à la problématique décisionnelle sui-vante : choix d’un terrain pour la construction d’une habitation.


L’objet de la décision est donc un terrain susceptible de convenir à la construction d’une habi-tation. En effet, notre action portera sur le choix du site le plus adéquat, parmi plusieurs pourla construction d’une habitation. Ainsi, nous disposons de 18 îlots vierges (actions potentielles)pouvant convenir pour cette construction.

5.4.1 Délimitation de la région d’étudeLa région d’étude se trouve dans le canton de Vaud, à environ 15 km au nord de Lausanne. Ses

limites géographiques dans le système de cordonnées suisse sont 532 750-532 500(m) et 158 000-164000 (m). La surface de la région d’étude est de 52 500 km2. Pour le choix de cette région, on s’estinspiré des travaux de Joerin [63], [52] et [54] qui a essentiellement résulté du grand nombre dedonnées spatiales à disposition. La carte géographique relative à la région test est présentée sur lafigure 5.15 :

Figure 5.15 – Zone d’étude

5.4.2 Identification des critères d’adéquation du territoire pour l’habitatLa première étape dans l’élaboration de la liste des critères consiste à identifier tous les fac-

teurs influençant l’adéquation du territoire à l’habitation. Cette identification s’inspire largementdes autres études liées au territoire et s’appuie, principalement, sur la méthode systématique pro-posée par Joerin [63]. L’adéquation du territoire pour l’habitat intègre, pour cette application, septcritères. Le tableau suivant (Tableau 5.1) présente une vue d’ensemble des facteurs considérés dansles critères identifiés.


Critère Type Echelle Facteurs associés Méthode d’évalua-tion

Nuisances Naturel [0,1] Pollutions Atmosphé-riques, Odeurs

Attribution d’une note

Bruit Social [0,1] Autoroutes, Routes, Che-mins de fer


Impacts Social {0,..,6} Eaux souterraines, PlanSectoriel : sites etcontraintes naturelles,paysages à protéger,Forêts


Géotechniqueet risquesnaturels

Naturel {0,..,6} Glissements de terrain Analyse spatiale

Équipements Economique [0,2244] Distance aux équipe-ments : gaz, électricité,eaux, routes

Consultation des ex-perts

Accessibilité Economique [0,15] Durée moyenne des trajetsentre le domicile et le lieude travail

Consultation des ex-perts

Climat Naturel [0,1] Ensoleillement,brouillard, température


Table 5.1 – Identification des critères

La définition ainsi que l’évaluation des critères identifiés par rapport aux différentes actionspotentielles permettent de générer la matrice des performances, illustrée par le tableau (5.2). Cettematrice est gérée par le SIG [63].


Actions Nuisances Bruit Impacts Géotechnique Equipement Access Climat729 1,00 0,99 2 6 1867 10 0,68732 1,00 0,98 2 6 1957 10 0,71737 1,00 0,97 2 6 2047 10 0,70740 1,00 0,97 2 6 2147 10 0,69743 1,00 0,93 2 6 2233 9 0,67745 1,00 0,96 2 6 2185 12 0,84748 1,00 0,67 2 6 2220 9 0,681030 1,00 0,15 4 6 1832 11 0,711033 0,99 0,55 4 6 1906 10 0,741038 0,98 0,27 4 6 2037 10 0,751045 1,00 0,96 4 6 2232 13 0,861046 1,00 0,69 4 6 2186 5 0,781233 1,00 0,62 6 3 1911 10 0,701236 1,00 1,00 6 3 2070 6 0,851239 1,00 1,00 6 3 2142 6 0,851321 1,00 0,98 6 3 1648 10 0,841324 1,00 0,98 6 3 1756 10 0,681326 1,00 0,98 6 3 1821 10 0,83

Table 5.2 – Les différents niveaux de la décision

5.4.3 Identification des différents décideurs impliquésNous supposons aussi que quatre décideurs sont impliqués dans ce processus décisionnel [54] :

– Décideur 1 : association environnementale.

– Décideur 2 : politicien.

– Décideur 3 : économiste.

– Décideur 4 : publique.

Les paramètres subjectifs exprimés, respectivement, par chacun des décideurs sont résumésdans les tableaux suivants (5.3, 5.4, 5.5, 5.6) :

CritèresParamètres Poids P Q V

Nuisances 7.51 0.6 0.3 1Bruit 13.63 0.6 0.3 0.8Impact 13.63 0 0 0Géotechnique 13.63 110 55 220Equipements 17.2 10 5 20Accessibilité 17.2 0.6 0.3 1.2Climat 17.2 0.6 0.3 1.5

Table 5.3 – Paramètres subjectifs exprimés par le décideur 1



Nuisances 17.38 0.5 0.25 1Bruit 29.4 0.6 0.3 1.2Impact 6.16 0.3 0.15 0.6Géotechnique 6.16 90 45 180Equipements 6.16 6 3 12Accessibilité 17.38 0.5 0.25 1Climat 17.38 0.5 0.25 1



Nuisances 4.96 0.7 0.35 1.4Bruit 7.08 0.7 0.35 1.4Impact 17.31 0.6 0.3 1.2Géotechnique 18.93 100 50 200Equipements 18.93 8 4 16Accessibilité 17.52 1 0.5 2Climat 15.27 0.7 0.35 1.4



Nuisances 6.15 0.4 0.2 0.8Bruit 19.57 0.4 0.2 0.8Impact 13.79 0.2 0.1 0.4Géotechnique 13.79 60 30 120Equipements 13.79 4 2 8Accessibilité 16.45 0.6 0.15 0.6Climat 16.45 0.4 0.2 0.8


5.4.4 Description du processus décisionnelUn processus décisionnel de groupe passe généralement par les phases suivantes : la compré-

hension collective du problème, la proposition (ou génération) des solutions et enfin la prise dedécision.

5.4.4.1 Compréhension collective du problème (phase de structuration du problème)

La compréhension du problème passe forcément par une discussion et des échanges d’informa-tion ou de documents entre les membres du groupe. Chaque membre peut intervenir et apporter descompléments d’informations selon son domaine de compétence ce que nous avons appelé l’échanged’informations structurées et non structurées dans le chapitre précèdent.


La plateforme propose un espace de messagerie et un outil de partage de documents.Après un certain temps, jugé suffisant par l’initiateur, celui-ci décide de tester la compréhensiondes décideurs en leur soumettant un formulaire contenant plusieurs QCM ou QCS. Le formulaireest créé grâce au générateur proposé par la plateforme (figure 5.16).

Figure 5.16 – Formulaire sur la compréhension du problème créé grâce au générateur

L’initiateur peut avoir une idée de départ sur les estimations des décideurs sur les critères àpartir du résumé graphique (figure 5.17).

Figure 5.17 – Formulaire - Résumé des réponses

Dans un second temps, l’initiateur décide de relancer la discussion, cette fois ci sur le choix descritères pour l’évaluation des solutions (terrains). Par le biais de la messagerie, l’initiateur récolteles propositions des participants et les synthétise dans un formulaire qu’il leur soumet.


Figure 5.18 – Formulaire – critères à retenir

Après réception des réponses, et d’après les statistiques (figures 5.19 et 5.20), l’initiateur concluten retenant les trois critères (Bruit, Géotechnique et Accessibilité). Cette étape est facultative dansle cas où nous ne voulons pas impliquer tous les critères à la décision.

Figure 5.19 – Formulaire critères à retenir : résumé avec poids des décideurs

Figure 5.20 – Formulaire critères à retenir : résumé sans poids des décideurs

5.4.4.2 Propositions des solutions et phase de décision (phase d’exploitation et d’éva-luation)

– L’initiateur ayant déjà chargé le fichier Excel contenant la matrice de performances et sélec-tionné les participants à solliciter, attend la réception des paramètres subjectifs exprimés parles décideurs pour lancer la méthode multicritères« PROMETHEE II ».

– Chaque participant sélectionné précédemment, reçoit dans son espace la matrice de perfor-mances (figure 5.20) ainsi que des paramètres subjectifs qu’il a exprimés.


Figure 5.21 – Espace décideur – Matrice de performances

Figure 5.22 – Espace décideur – introduction des paramètres subjectifs de tous les décideurs

Simulation du processus de négociation

Une fois le problème décisionnel structuré (Figure 5.22), l’initiateur lance le protocole de négo-ciation. Ce dernier expolite, principalement, le classement des actions fourni par chaque décideuren utilisant PROMETHEE II. L’exécution et les résultats de la méthode PROMETHEE II pourchaque décideur est montré par la Figure 5.23.En plus du classement des actions, le protocole utilise les poids des décideurs et définit commecritère d’arrêt les informations introduites par l’initiateur au lancement (figure 5.23).La méthode PROMETHEE II renvoie aux quatre décideurs le classement des terrains selon leurspréférences (Figure 5.23).


Figure 5.23 – Espace décideur Résultat de la méthode Prométhée II Classement des terrains

Figure 5.24 – Paramétrage du protocole de négociation

– Avant de commencer la négociation, l’initiateur fixe le nombre de tours maximal et le seuild’acceptation, avec possibilité de comptabiliser les réponses de manière pondérée (« userweights »). Figure 5.24.

– Comme nous l’avons expliqué nous avons mis au point deux méthodes de calcul de scoreglobal, une utilise le rang et l’autre le flux.

1. Le résultat du processus utilisant le rang : Les résultats sont donnés en formed’un récapitulatif et d’un tableau proposant un classement des terrains.L’initiateur calcule à présent le score global pour chaque action (Table 5.7) et proposel’action ayant le score le plus élevé dans notre cas c’est l’action 11 (le terrain N11) quiest choisie. Les décideurs acceptent le compromis vu que c’est l’action qui correspondle plus à leurs préférences.

Rang 1 2 3 4 5 6 7 8 9 10 11Action 11 6 13 18 15 4 17 14 16 5 3

score Global 144 136 110 110 106 106 96 94 78 74 64

Table 5.7 – Résultat utilisant le rang [2]


2. Le résultat du processus utilisant le flux net :

Rang 1 2 3 4 5 6 7 8 9 10 11Action 11 6 13 18 15 4 17 14 16 5 3

Degré de préférence 2.74 1.45 0.31 0.22 0.22 0.15 0.09 0.03 -0.04 -0.18 -0.02

Table 5.9 – Résultat utilisant le flux net [2]

– Chaque participant reçoit à un tour i, la meilleure action selon les scores calculéspar le GDSS jusqu’à ce que pour un certain tour, le seuil d’acceptation soit atteintdans notre cas c’est l’action 11 qui est choisie.

– Dans le cas où, pour une action, le seuil d’acceptation est atteint avant d’atteindrele nombre maximum de tours, cette action sera la décision de groupe. Dans le cascontraire, la négociation à aboutit à un échec.

– Par contre, si le nombre de tours maximal n’est pas encore atteint et que l’actionproposée n’est pas accepté alors l’initiateur doit proposer une autre alternative ayantun score élevé selon ses calculs. Nous constatons que l’action proposée est toujoursla même en ce qui concerne le calcul des scores par le rang (Table 5.7) et par le fluxnet (Table 5.8).

5.5 Interprétation des échanges de messages par les agentsLes messages qui ont été échangés entre les agents participants et le coordinateur durant le

processus de négociation ont été visualisés grâce à l’agent Sniffer de JADE (chaque décideur estmodélisé par un agent).La figure 5.25 illustre le processus de négociation du début jusqu’à la fin ensuite nous montronschaque phase du protocole qui apparait dans les échanges entre agents.


Figure 5.25 – Échanges de messages entre l’initiateur et les décideurs pendant la négociation


5.5.1 Phase d’initialisation

Figure 5.26 – Échange entre les agents durant la phase d’initialisation

La figure 5.26 représente la première phase du protocole proposé : l’agent initiateur déclenchela négociation en envoyant aux quatre agents décideurs la matrice de performances et les inviteà lui envoyer leurs préférences. Les agents participants, à leur tour, lui envoient leurs préférences.L’agent initiateur lance PROMETHEE II pour chaque agent décideur.Comme le montre la figure 5.26, l’agent initiateur déclenche la négociation en envoyant la pri-mitive REQUEST (). Chaque agent décideur effectue un classement des terrains via la méthodePROMETHEE II et l’envoie à l’agent initiateur en envoyant INFORM ().


5.5.2 Phase de d’évaluation et de proposition

Figure 5.27 – Échange entre les agents durant la phase de proposition

L’agent initiateur après réception des vecteurs de préférences de la part des quatre agentsparticipants, effectue un scorage total des terrains et envoie le terrain qui correspond au mieux auxpréférences des décideurs, il envoie sa proposition par le biais de la primitive PROPOSE (). Lesagents participants acceptent, dans notre cas, le terrain 11 et envoient leur accord via ACCEPT-PROPOSAL () Comme montré dans la figure 5.27.

5.5.3 Phase de décision

Figure 5.28 – Annonce de la décision finale

Après réception, des réponses des quatre agents participants, il comptabilise le nombre d’ac-ceptation par rapport au seuil qui a été fixé (dans ce scénario à 80%) alors il conclut à un succès.Il envoie la primitive CONFIRM () pour informer les autres agents du succès de la négociationcomme montré dans la figure 28. Dans le cas où la négociation se termine par un échec, l’initiateurnotifie les décideurs de la décision d’échec.

5.6 ConclusionAu terme de ce chapitre, nous avons présenté une simulation du processus décisionnel de groupe

proposé dans un contexte multicritères et multi décideurs.


Nous avons illustré la plateforme de communication réalisée par des services web à travers unsénarion illustratif. Nous avons montré comment l’administrateur y accède et quelles sont les opé-rations qu’il effectue afin de gérer les utilisateurs. Comment les décideurs qu’ils soient initiateurou participants gèrent leurs comptes et contribuent à la décision de groupe.

Nous avons vu les différentes tâches réalisées par les décideurs impliqués à savoir la participa-tion à des sessions décisionnelles, le partage de messages et la participation aux sondages à traversles formulaires de vote. Ensuite nous avons mis l’accent sur un module clé de la plateforme qui estle protocole de négociation et nous l’avons déroulé à travers un scénario portant sur le choix d’unterrain pour la construction d’une habitation. Nous avons déroulé notre exemple selon les troisphases de décision montré dans notre modèle décisionnel décrit dans le chapitre 4.

Les SMA nous ont permis de montrer le plus fidèlement possible les différents acteurs de lanégociation, ces agents sont dotés de la méthode d’analyse multicritères PROMETHEE II, traitantune problématique de rangement permettant de ranger l’ensemble des alternatives de la meilleureà la moins bonne. Les agents sont passés par un processus de négociation bien structuré avant detrouver un compromis.

Conclusion Générale etPerspectives

Face à la mondialisation de l’informatique décisionnelle et à la concurrence grandissante, la prisede décision est devenue cruciale pour les décideurs de différents domaines. Les systèmes d’aide àla décision permettent au décideur individuel de mieux gérer la masse et la complexité de l’infor-mation et aux organisations de mieux coordonner l’activité des décideurs individuels.

L’aide à la décision est un domaine au carrefour de plusieurs disciplines incluant la théorie de ladécision, les sciences politiques, la sociologie, la recherche opérationnelle, l’intelligence artificielle,les systèmes d’information, les méthodes de décision discrètes, etc.

L’aide à la décision n’a pas pour but de se substituer au décideur en lui proposant une solutiontout faite. Elle cherche d’abord à l’éclairer et à le guider vers des décisions qu’il aura la responsa-bilité de prendre. Souvent, nous avons affaire à plusieurs acteurs devant décider avec la contraintede plusieurs critères, cette discipline est appelé l’aide multicritères à la décision de groupe.

Les systèmes d’aide multicritères à la décision de groupe opèrent selon des processus de récolte,d’analyse et d’échange d’information permettant aux différents acteurs concernés par la décisionde construire, renforcer ou modifier leurs préférences.

Ces systèmes prouvent de plus en plus leur efficacité dans la résolution des problèmes com-plexes. Cette efficacité ne peut que s’améliorer en utilisant l’analyse multicritères et en faisantparticiper plusieurs décideurs dans le processus d’aide à la décision.

Dans la présente étude, nous nous sommes intéressés à plusieurs aspects de l’aide à la décisionqui font d’elle une activité complexe.

Le premier aspect, est celui de la multiplicité des décideurs, en effet, une décision, quand elleest collective, est souvent délicate à prendre car elle doit satisfaire plusieurs préférences et pointsde vue ou répondre à des objectifs non toujours concordants.

La décision de groupe nécessite, par conséquent, des phases de confrontation des points de vue,de concertation et de négociation pour arriver à un résultat consensuel. D’une manière générale, ladécision collective implique un grand nombre d’échanges et d’interactions entre les protagonistes,et doit intégrer des mécanismes formalisés ayant pour but de mener le processus décisionnel à laconvergence.

Dans cette optique, notre contribution a été de mettre en place un système d’aide à la décision de


groupe qui se constitue d’une plateforme de communication, intégrant un protocole de négociation.

Le second aspect de complexité concerne la nature des problèmes décisionnels réels qui est biensouvent multicritères. Le cas du critère unique, couvert par les domaines de la recherche opération-nelle comme l’optimisation combinatoire, n’est que rarement rencontré dans la réalité. L’analysemulticritères fournit des outils efficaces pour modéliser et aider à appréhender des problèmes plusréalistes et plus complexes. Ainsi, nous avons jugé intéressant, et même incontournable, d’intégrerdans notre plateforme une méthode d’analyse multicritères. Notre choix s’est porté sur la méthodeProméthée II, car celle-ci permet de prioriser totalement un ensemble d’alternatives en tenantcomptes des préférences quant aux critères.

En dernier lieu, nous constatons que le travail collaboratif a évolué au grès des avancées tech-nologiques, en s’affranchissant des barrières géographiques et temporelles. Ainsi, et dans l’objectifde permettre à des personnes géographiquement séparées de collaborer, nous avons conçu notreplateforme en s’appuyant sur la technologie des services web. Ces derniers tirent tout l’avantagedes standards bien connus du web. A cet effet, la plateforme procède à la persistance de tous leséchanges effectués, les données ainsi non volatiles, peuvent être consultées de manière différée.

Dans ce document, nous avons abordé la problématique à travers quatre chapitres :

Dans le premier chapitre, nous avons décrit les deux dimensions majeures de notre probléma-tique à savoir : l’aide à la décision de groupe et l’aide à la décision multicritères, avant de définirles GDSS et de mettre en relief leurs apports dans le domaine de la décision collective. Dans cechapitre nous avons, également, introduit les concepts de base structurant l’aide multicritères à ladécision. Par la suite, nous avons abordé les aspects multi acteurs (collectifs) et multicritères quipeuvent caractériser la prise de décision.

Dans le second chapitre, nous nous sommes intéressés aux notions d’agents et de systèmes multiagents(SMA), nous avons mis l’accent sur la négociation, mécanisme puissant pour la résolution deconflit et la recherche de consensus satisfaisant pour un groupe d’agents. Nous avons passé en revueles différentes formes de négociation et nous avons conclu par des travaux de recherche relatifs àcette thématique.

A travers le troisième chapitre, nous avons présenté les technologies web, plus précisément lesservices web. Nous avons présenté des définitions en passant par l’intérêt de cette technologie, sonarchitecture ainsi que son fonctionnement. Nous avons mis le point sur les deux grandes famillesexistantes (SOAP et REST) avant de conclure par l’expression justifiée de notre préférence pour lafamille REST comme nous avons estimé important de citer certains systèmes et travaux utilisantles services web.

Dans le chapitre quatre, sont présentées en détails nos principales contributions qui portent surla proposition :

– D’un modèle de processus de décision de groupe dans un contexte multicritères et multidécideurs. Le système d’aide à la décision de groupe correspondant s’articule autour d’uneplateforme de communication web susceptible d’assurer la négociation entre un ensemble dedécideurs en conflit.

– La proposition d’un protocole de négociation basé sur la médiation et l’analyse multicritères


assurée par la méthode « PROMETHE II » afin d’aider les décideurs à mieux exprimer leurspréférences.

Comme nous l’avons mentionné précédemment, notre plateforme répond au modèle à trois ni-veaux [34] répondant aux besoins de communication, par son système de messagerie, son systèmed’échange et d’archivage de documents, et par son système de génération et d’échange de formu-laires pour une communication plus structurée.

Il répond, également, au besoin d’agrégation de préférences par son système de vote basé surdes formulaires et le protocole de négociation automatisé permettant de mener le groupe vers unconsensus.

Et enfin, il répond au besoin de la structuration des échanges, en donnant une place particu-lière au rôle d’initiateur (ou médiateur) qui a la charge de créer et de gérer le processus décisionnelet une aide individuelle aux décideurs : une méthode d’analyse multicritères permettant d’aiderchaque décideur à mieux exprimer ses préférences.

Nous avons aussi répondu à un de nos objectifs qui était de faire participer des décideurs géogra-phiquement éloignés. Afin d’atteindre ce but, nous avons mis en œuvre une plateforme exploitantles services web comme la plupart des plateformes en ligne sur le net.

Notre système est générique interopérable et facilement modifiable par le fait qu’il soit modu-laire, ainsi nous pouvons très facilement dans le futur modifier chaque sous système séparémentselon le besoin.

Nous avons tenté d’enrichir au maximum ce chapitre pour faciliter au lecteur la compréhensionde notre approche pour cela nous avons détaillé notre démarche décisionnelle. Nous avons décrit,en détails, notre plateforme avec ses différents modules ainsi que les différents services web utilisés.Nous avons, également, illustrer les modules de la plateforme par différents diagrammes.

Nous avons décrit notre protocole en expliquant toutes ses étapes, ses stratégies de négociationainsi que son langage.Dans le chapitre cinq, nous avons déroulé un scénario illustratif pour mieux comprendre notreapproche décrite dans la chapitre quatre à travers un cas réel qui est le choix d’un terrain pourune habitation parmi plusieurs terrains dans une région en Suisse.

PerspectivesLes travaux accomplis durant cette thèse ouvrent plusieurs perspectives de travaux futurs.

– Tout d’abord, nous avons l’aspect multicritères où nous pourrons intégrer d’autres méthodesd’analyse multicritères. Ainsi, nous pourrons mettre en place un annuaire consultable etexploitable par les acteurs de la plateforme en leur laissant le choix de sélectionner la méthodeselon la problématique décisionnelle traitée.

– Un autre aspect très important à considérer dans les systèmes en ligne, il s’agit de la sécurité,effectivement la nécessité d’exposer les services web vers l’extérieur ouvre la porte à desproblèmes de sécurité qui est à elle seule un autre domaine de recherche.


– Un point sensible dans les systèmes d’aide à la décision de groupe est à prendre en charge,c’est l’attribution des poids aux différents décideurs. A ce titre, il nous semble intéressantd’intégrer dans la plateforme des méthodes appropriées pour aider le coordinateur à mieuxgérer cette opération.

Troisième partie

Annexes

Annexe A

Les méthodes d’analysemulticritères

A.1 IntroductionLa plupart des problèmes de décision qu’ils soient économiques, industriels, financiers ou poli-

tiques sont de nature multicritère, L’existence d’une pluralité de critères utilisés (coût avantage,coût efficacité) est le signe manifeste de la complexité des problèmes de choix.Les méthodes multicritères sont des outils d’aide à la décision, leur développement a débuté dansle contexte militaire depuis les années 1960 pour deux raisons essentielles : L’amélioration de lagestion et la fourniture des moyens nécessaires pour les soldats. Les méthodes utilisées, à l’époque,sont issues du domaine de recherche opérationnelle. Ces méthodes permettaient d’optimiser unefonction tout en considérant un ensemble de contraintes prédéfinies. Par la suite, ces méthodes ontinvesti d’autres problématiques décisionnelles où le facteur humain a pris une dimension impor-tante.Nous présentons dans cette annexe, de façon synthétique, les méthodes d’analyse multicritères.

A.2 Les méthodes d’aide multicritères à la décisionLes méthodes d’analyse multicritères ou, plus exactement, les méthodes d’aide multicritères à

la décision sont des techniques en plein développement. Par leur manière d’intégrer tout type decritères, ces procédures semblent mieux permettre de se diriger vers un judicieux compromis plutôtqu’un optimum souvent désuet.

A.2.1 Avantages des méthodes multicritèresToute méthode d’analyse multicritère formalise ou modélise la préparation de la décision. Elle

présente deux avantages décisifs :

– L’amélioration de la transparence du processus de décision.

– Une définition, précise et mise en évidence de la responsabilité du décideur.

Bernard ROY [101] caractérise le paradigme multicritères comme étant "un nouveau schémade penser pour comprendre ou agir sur un système", en considérant que :

– Plusieurs critères sont à l’œuvre pour conduire le système ou guider son évolution ;

Chapitre A.Les méthodes d’analyse multicritères 128

– Ces critères sont, au moins localement, conflictuels ;

– Ils permettent des compromis ou invitent à procéder à un arbitrage ;

Un problème multicritères n’est pas mathématiquement bien posé. Il peut être traité selon deuxétats d’esprit différents [76] :

– Introduire des hypothèses restrictives tel que le problème puisse être résolu par une méthode« classique » ; la contrepartie est un décalage de plus en plus important par rapport à laréalité.

– Utiliser une méthode d’analyse multicritère basée sur des modèles bâtis en partie sur deshypothèses mathématiques nécessairement restrictives et en partie sur des informations re-cueillies auprès du décideur.

A.2.2 Le but des méthodes d’analyse multicritèresPuisqu’il ne s’agit pas de la recherche d’un optimum, quel est alors le but des méthodes d’ana-

lyse multicritère ?Pour répondre à cette question, [11] bon rappelle tout d’abord que la recherche en psychologie amontré que le cerveau humain ne peut considérer simultanément qu’un nombre limité d’informa-tions (donc de critères).En conséquence, le but principal des méthodes d’aide à la décision par analyse multicritères est, àson avis, d’aider les décideurs à organiser et synthétiser leurs informations afin qu’ils se sentent àl’aise avec leur prise de décision. Cette finalité est évidemment beaucoup moins ambitieuse que ladétermination de la solution (objectivement) optimale.

A.2.3 Les différentes problématiques en Aide Multicritères à la DécisionLes méthodes d’analyses multicritères peuvent être distinguées ou classées en considérant, tout

d’abord, le type du problème qu’elles affrontent.Roy [100] propose quatre catégories :

1. La problématique Alpha : correspond à la sélection des meilleures actions.

2. La problématique Bêta : est traitée par un tri des différentes actions dans des classesprédéfinies (ex : bonnes, moyennes, mauvaises).

3. La problématique Gamma : a pour objectif de ranger les actions de la meilleure à lamoins bonne.

4. problématique Delta : son objectif est simplement de décrire les actions et leurs consé-quences.

Cette classification des problématiques est illustrée par le tableau suivant [100] :


Problématique Objectifs Résultatα Éclairer la décision par le choix d’un sousensemble

aussi restreint que possible en vue d’un choix finald’une seule action, ce sous ensemble contenant de« meilleures » actions (optimum) ou, à défaut, desactions « satisfaisantes ».

Un choix ou uneprocédure de sélec-tion

β Éclairer la décision par un tri résultant d’une affecta-tion de chaque action à une catégorie, les catégoriesétant définies à priori en fonction de normes ayanttrait à la suite à donner aux actions qu’elles sontdestinées à recevoir.

Un tri ou une pro-cédure d’affectation

γ Éclairer la décision par un rangement obtenu en re-groupant tout ou partie (les « plus satisfaisantes »)des actions en classes d’équivalence, ces classes étantordonnées, de façon complète ou partielle, conformé-ment aux préférences.

Un rangement ouprocédure de clas-sement

δ Éclairer la décision par une description, dans un lan-gage approprié, des actions et de leurs conséquents.

Une description ouune procédure cog-nitive

Table A.1 – Les quatre problématiques de référence

A.3 Classification des méthodes multicritèresLes méthodes d’aide multicritère à la décision peuvent être classées selon la méthode d’agré-

gation utilisée ou selon le type du résultat produit par la méthode (soit choix, rangement, tri oùdescription (Figure 2.3)) [53].

Figure A.1 – Classification des Méthodes Multicritère (MMC)


A.3.1 Les méthodes d’agrégationRoy [102] propose trois familles de méthodes :

– Une famille de méthodes utilisant une agrégation complète.

– Une autre utilisant une agrégation partielle.

– Et une famille de méthodes utilisant une agrégation partielle itérative.

A.3.1.1 Agrégation complète transitive (Approche du critère unique de synthèse)

Il s’agit ici d’évacuer toute situation d’incomparabitité (c.-à-d. rejetant l’incomparabilité) etintroduire toutes les performances dans une seule fonction d’agrégation ou d’utilité (le modèle depréférence s’exprime à travers une fonction unique) en leur attribuant d’éventuels poids [20].Lesprincipales méthodes appartenant à cette approche sont : Multi AttributeUtilityTheory (MAUT),Utilités additifs (UTA), Analytic Hierarchic Process (AHP), La technique de Goal Programming,etc.

A.3.1.2 Agrégation partielle (Approche du surclassement de synthèse)

Cette approche repose sur la comparaison des actions deux à deux, puis une synthèse desrésultats de ces comparaisons est établie, et c’est justement la façon de synthétiser qui différencie lesméthodes de cette famille. Cette approche respecte l’incomparabilité (acceptant l’incomparabilité),mais au détriment de la clarté des résultats. Les principales méthodes ou familles de méthodesappartenant à cette approche sont :

– La famille ELECTRE (Élimination Et Choix Traduisant la Réalité).

– La famille PROMETHEE (Preference Ranking Organization Method for Enrichment Eva-luation).

– ORESTE.

– QUALIFLEX, etc.

A.3.1.3 Agrégation locale (Approche du jugement local interactif avec itérationsessai-erreur)

Cette technique consiste à partir d’une solution de départ, supposée aussi bonne que possible,et voir dans le voisinage, s’il existe une solution mieux qu’elle. En d’autres termes, une solutionde départ est choisie, ensuite, nous sélectionnons un groupe de variantes relativement proche à lasolution de départ, par la suite, nous vérifions s’il n’existe pas de meilleure variante par rapportà celle sélectionnée, ce nouveau choix constitue la solution de départ pour une nouvelle itération[76]. Les principales méthodes appartenant à cette troisième approche : STEM, Point de mireévolutive, Cône d’amélioration. Nous nous intéressons aux méthodes d’agrégation partielle ou desurclassement et pour cela nous donnons dans ce qui suit un aperçu sur les deux familles les plusconnues qui sont Electre et PROMETHEE.

A.4 La famille ELECTRELes méthodes ELECTRE ont été développées par Bernard Roy au début des années 1970. Il

a ainsi initié toute une série de méthodes, dites de surclassement, basées sur des comparaisonsd’actions deux à deux. Celles-ci demandent peu d’informations pour pouvoir être implémentées ;de plus cette information est facilement accessible au décideur.


A.4.1 La méthode ELECTRE IELECTRE I [97] est la plus ancienne des méthodes Electre, elle révèle de la problématique de

choix, dite alpha (α). Celle-ci consiste à chercher dans l’ensemble des actions envisagées, un sousensemble contenant les "meilleures" actions ou à défaut, les actions "les plus satisfaisantes". Lescritères utilisés dans cette méthode, sont francs et il n’y a pas de seuil de veto. Ceci n’autorise quetrois types de relations entre deux actions pour un critère cj donné : aiPak ou aiIak ou akPai. Leprincipal inconvénient de cette méthode, est qu’elle ne propose que rarement une seule «meilleure»action, ce qui peut être parfois gênant car le résultat n’est pas net. On sait que la meilleure actionse trouve dans le noyau, mais cela ne veut pas dire que les autres actions du noyau sont placéesen deuxième et troisième position. Il s’agit plutôt des variantes qui sont difficilement comparablesavec cette meilleure action.

A.4.2 La méthode ELECTRE IILa méthode ELECTRE II [98] rélève de la problématique δ (procédure de classement).Les

résultats obtenus dans ELECTRE II sont plus tranchés que dans la méthode précédente, car il ya presque toujours une meilleure action qui se dégage du classement obtenu. ELECTRE II a pourobjectif, en utilisant les relations d’ordre sur chacun des critères, de classer les variantes depuisles meilleures jusqu’aux moins bonnes, tout en tolérant les exæquo [76]. Les actions ne sont pasqualifiées en fonction de leur valeur propre mais en valeur relative par rapport aux autres actions.Cette méthode utilise, tout comme la méthode ELECTRE I, une vérification de la concordance etde la non-discordance avec l’hypothèse de surclassement aiSak.Une distinction est néanmoins réalisée, afin de mieux respecter les nuances du réel, en introduisantune notion de respect de cette hypothèse de surclassement qui est plus floue, entre la rigidité deELECTRE I et le flou total d’ELECTRE III. On trouve ainsi un surclassement fort aiSFak, quirepose sur des bases solides (certitude forte sur l’hypothèse), et un sur classement faible aiSfak,qui est plus sujet à débattre (certitude faible sur l’hypothèse).Les critères utilisés dans la méthode ELECTRE II sont francs et ne comportent pas de seuil deveto.

A.4.3 La méthode ELECTRE IIITout comme ELECTRE II, ELECTRE III, répond à la problématique de rangement. Cepen-

dant, ELECTRE III ne cherche pas seulement deux espèces de surclassement, les forts et les faibles,mais examine toute une famille qui va du totalement fort au totalement faible ou inexistant, enpassant par toutes les nuances que permet l’échelle continue entre ces deux extrêmes. De plus,ELECTRE III étudie le surclassement tout en se demandant quel en est le degré de crédibilité [55].Comme dans les ELECTRE décrites précédemment, la relation de surclassement fait appel à laconcordance et à la discordance, mais de manière différente ; des seuils sont introduits dans le cal-cul de la concordance, ce qui permet d’introduire en force la notion de structure de préférence descritères d’évaluation. ELECTRE III vise ainsi un rangement des actions exprimant en des termesplus ou moins nuancés les positions relatives des actions en tentant de les départager en classesd’équivalence.

A.4.4 La méthode ELECTRE IVLa méthode ELECTRE IV [99], relève aussi de la problématique δ. Sa démarche d’utilisation

constitue en une simplification de la méthode ELECTRE III par l’abandon de la pondération descritères. Son originalité réside dans le fait qu’il n’y a plus de poids attribués aux critères, seule


une hypothèse de disparité limitée étant fixée. Ce changement fondamental est accompagné d’uneautre grande nouveauté : l’abandon de l’hypothèse de surclassement, qui rend inutiles les notionsde concordance et de discordance.ELECTRE IV utilise comme ELECTRE III, des pseudo-critères (critères flous), c’est à dire descritères associés à un seuil de préférence strict et à un seuil d’indifférence. Cette méthode admetplusieurs versions des types de surclassement entre deux actions.ELECTRE IV se base sur les nuances développées dans ELECTRE III mais simplifie fortement leprocessus d’étude qui s’ensuit.

A.4.5 La méthode ELECTRE ISLa méthode ELECTRE IS [100] est une adaptation de ELECTRE I (problématique alpha)

à la logique floue, permettant d’utiliser des pseudo-critères (le S veut dire seuil). Comme dansELECTRE III, ELECTRE IS utilise les seuils d’indifférence Si, de préférence Sp et de veto Sv.

A.4.6 La méthode ELECTRE TriLa méthode ELECTRE Tri [100] relève de la problématique β (procédure d’affectation) : le

problème est posé en termes d’attribution de chaque action à une catégorie prédéfinie. Des actionsde préférences sont utilisées pour segmenter l’espace des critères en catégories : chaque catégorieest bornée inférieurement et supérieurement par deux actions de référence et chaque action deréférence sert donc à deux catégories, l’une supérieure, l’autre inférieure.Cette méthode suit la procédure d’ELECTRE III jusqu’au calcul des degrés de crédibilité ; l’af-fectation des actions à une catégorie est, bien entendu, spécifique. Pour déceler l’incomparabilité,deux procédures d’affectation distinctes, appelées optimiste et pessimiste, sont nécessaires : elleconsiste à comparer chaque action potentielle avec les actions de référence en commençant par laplus contraignante, respectivement la moins contraignante.Si les deux procédures affectent l’action potentielle à la même catégorie, elle est alors parfaitementcomparable avec les actions de référence ; sinon, en fonction de la différence entre les deux catégo-ries auxquelles elle est attribuée, elle est plus ou moins incomparable. Il existe deux manières dedéfinir l’ensemble des actions de référence :

– La première consiste à choisir des actions de référence parfaitement comparables entre elles :chacune surclasse ou est surclassée par toutes les autres ; on parle alors de segmentationmulticritères simple.

– La seconde consiste à admettre des profils différenciés, partiellement ou complètement in-comparables entre eux ; on parle alors de segmentation multicritères généralisée.

A.5 La famille PROMETHEE

A.5.1 Le principe de la méthode PROMETHEE :Les trois phases de la méthode PROMETHEE : La mise en œuvre de la méthode peut être

ramenée à l’exécution des trois étapes suivantes :

1. Choix de critères généralisés A chaque critère C1, C2,. . . , Cn sera associé un critèregénéralisé choisi sur base d’une fonction de préférence et les effets d’échelle seront éliminés.

2. Détermination d’une relation de surclassement Dans une deuxième phase, il convientde déterminer une relation de surclassement par le biais d’un indice de préférence (parexemple : l’écart maximum entre deux actions) qui quantifiera les préférences du décideur.


3. Évaluation des préférences L’évaluation de la préférence du décideur par la prise encompte des flux entrant et sortant.

A.5.2 Le principe de la méthode PROMETHEEConsiste à établir un processus de comparaison numérique de chaque action par rapport à

toutes les autres actions. Ainsi il est possible de calculer le plus (mérite) ou le moins (démérite) dechaque action par rapport à toutes les autres. Le résultat de cette comparaison permet le classementordonné des actions

A.5.3 La méthode PROMETHEE I : rangement partielLes flux sortant et entrant permettent de ranger les actions de A de façon naturelle. Désignons

par (S+, I+) et (S-, I-) les deux pré ordres induits par ces flux. On sait qu’une action est d’autantmeilleure que son flux sortant est élevé, et que sont flux entrant est faible.

A.5.4 La méthode PROMETHEE II : rangement completOn utilisera Prométhée II si on souhaite disposer d’un rangement complet de toutes les actions.

Ce rangement est obtenu en rangeant les actions dans l’ordre décroissant des flux net Φ. La diffé-rence entre Prométhée I et II : La différence entre les méthodes Prométhée I et II se trouve dans lesdifférences de rangement des actions. Les deux méthodes ont le même cheminement initial, maisleurs buts sont différents. Prométhée I permet de dégager des relations partielles de classement ;alors que Prométhée II fournit un classement de toutes les actions.

A.5.5 PROMETHEE III, alpha : Amplification de la relation d’indiffé-rence

PROMETHEE III est une extension de PROMETHEE II dans laquelle la notion d’indifférenceest amplifiée. En effet, le pré ordre complet PROMETHEE II laisse relativement peu de place auxindifférences, étant donné qu’elles résultent d’égalités entre les flux nets des actions. En pratique,vu le caractère continu des flux de surclassement, ces situations sont rares et, le plus souvent,PROMETHEE fournit un ordre complet sur l’ensemble des actions, sans aucune indifférence. Cettesituation peut paraître paradoxale, en particulier lorsque deux actions ont des flux nets très prochesl’un de l’autre.

A.5.6 PROMETHEE VI : Problèmes aisés ou difficilesLa méthode GAIA permet une classification des problèmes multicritères en problèmes aisés et

difficiles, tout en laissant beaucoup de liberté au décideur. L’outil ainsi mis au point est appeléPROMETHEE VI. Dans le cas où le décideur est à même de fixer des valeurs précises des poidsattribués aux critères, la longueur de l’axe de décision PROMETHEE II permet déjà d’apprécierle degré de difficulté du problème. Dans beaucoup de cas, le décideur hésite à fixer des valeursprécises pour ces poids. Il est conscient de l’importance que les poids peuvent avoir sur le processusdécisionnel.

A.5.7 PROMETHEE V : Problèmes multicritères avec contraintes ad-ditionnelles

Dans certains cas, le problème posé n’est pas de sélectionner une action particulière ou deranger l’ensemble des actions de la meilleure à la moins bonne, mais au contraire de sélectionner


un sous-ensemble d’actions. La problématique n’est plus de type Pα ou Pβ mais d’un type pluscomplexe, noté Pα,θ n. Elle consiste à choisir θ actions parmi n, le nombre θ étant fixé à l’avance,ou à déterminer selon les cas.

A.6 ConclusionIl existe différentes méthodes d’analyse multicritères, chacune proposant des modalités parti-

culières. Elles se différencient surtout en fonction des arbres de décision utilisés pour définir lesensembles de solutions. Dans le contexte des gouvernements régionaux, le choix d’une méthode parrapport à une décision d’aménagement donnée se fait en tenant compte du type de problématiqueétudiée ; des caractéristiques de la base de connaissance sur le territoire, du système d’informationdisponible et des données traitées (biophysiques, socio-économiques) ; du mode de représentationet d’évaluation des phénomènes étudiés et de la limite ou de la portée prévue des actions étudiées.

Annexe B

Les Systèmes Multi Agents

B.1 IntroductionInitialement, le domaine de l’Intelligence Artificielle (IA) cherche surtout à décrire et à résoudre

des problèmes complexes identifiés par des experts. Dans ce domaine, il est possible de construiredes programmes informatiques, capables d’exécuter un nombre important de tâches en centrali-sant « l’intelligence » au sein d’un système unique [10]. Il est cependant difficile d’entrer dans unemême « base », les connaissances, les compétences d’individus totalement différents qui commu-niquent entre eux. L’apport de l’Intelligence Artificielle Distribuée (IAD) permet de « distribuerl’intelligence » entre plusieurs agents.

B.2 Acteur et agentLa distinction entre acteur et agent établie par Ferrand [44] est la suivante : « Un acteur est

un individu ou un groupe d’individus intervenant au sein d’un processus social. Leterme se réfère ici à la réalité sociale. Un agent est une entité conceptuelle participantà un modèle ou un Système Multi-Agent. Le terme se réfère au modèle ou à sonimplémentation. »

B.3 Définition des Systèmes Multi agentsParmi les différentes définitions des systèmes multi agents nous retiendrons celle de Ferber [40]

qui le définit comme un système composé des éléments suivants (Figure 1) :

1. Un Environnement E, c’est-à-dire un espace disposant d’une métrique.

2. Un ensemble d’objets O. Ces objets sont situés, c’est à dire que, pour tout objet, il estpossible, à un moment donné, d’associer une position dans E. Ces objets sont passifs, c’est àdire qu’ils peuvent être perçus, créés, détruits et modifiés par les agents.

3. Un ensemble A d’agents qui sont des objets particuliers, lesquels représentent les entitésactives du système.

4. Un ensemble de relations R qui unissent des objets (et donc des agents) entre eux.

5. Un ensemble d’opérations Op permettant aux agentsA de percevoir, produire, consommer,transformer et manipuler des objets deO.

Chapitre B.Les Systèmes Multi Agents 136

6. Des opérateurs chargés de représenter l’application de ces opérations et la réaction du mondeà cette tentative de modification, que l’on appellera les lois de l’Univers.

Figure B.1 – Représentation d’un agent en interaction avec son environnement et les autres agents

Un système multi-agent (SMA) est un système composé d’un ensemble d’agents, situésdans un certain environnement et interagissant selon certaines relations. Un agent est une entitécaractérisée par le fait qu’elle est, au moins partiellement, autonome. Ce peut-être un processus,un robot, un être humain, etc. [10].

B.4 Architecture des systèmes multi agentsEn reprenant les cinq problématiques précédentes, on peut décrire quelques éléments de l’ar-

chitecture d’un système multi-agent [40].

– Les agents doivent être dotés de systèmes de décisions et de planification. Les théories dela décision sont un domaine à part entière d’étude à ce sujet. Dans la catégorie des interac-tions avec l’environnement, un autre problème récurrent des systèmes d’agents est celui dupathfinding (avec son algorithme le plus connu, l’algorithme A*).

– Les agents doivent être dotés d’un modèle cognitif : Là aussi, plusieurs modèles existent, l’undes plus classiques étant le modèle BDI (Beliefs-Desires-Intentions). Il considère d’une partl’ensemble de croyances (Beliefs) de l’agent sur son environnement, qui sont le résultat deses connaissances et de ses perceptions, et d’autre part un ensemble d’objectifs (Desires).En croisant ces deux ensembles, on obtient un nouvel ensemble d’intentions (Intentions) quipeuvent ensuite se traduire directement en actions.

– Les agents doivent être dotés d’un système de communication. Plusieurs langages spécialisésont vu le jour à cette fin : le Knowledge Query and Manipulation Language (KQML), et plusrécemment, le standard FIPA-ACL (ACL pour Agent Communication Language) créée parla Foundation for Intelligent Physical Agents FIPA.


B.5 Caractéristiques d’un SMAUn SMA peut-être [63] :

– ouvert : les agents y entrent et en sortent librement (ex : un café)

– fermé : l’ensemble d’agents reste le même (ex : un match de football)

– homogène : tous les agents sont construits sur le même modèle (ex : une colonie de fourmis)

– hétérogène : des agents de modèles différents, de granularité différentes (ex : l’organisationd’une entreprise).

B.6 Types d’agentsIl existe un grand nombre de typologies d’agents [40][126] , nous retenons celle fondée sur le

processus de prise de décision de l’agent. Elle distingue trois types d’agents : réactifs, cognitifs oudélibératifs et hybrides. Pour un certain nombre d’auteurs [87] [42] un agent est défini comme étantune entité logicielle d’un système informatique qui possède les caractéristiques suivantes :

– Autonomie

– Flexibilité

– Réactivité

– Proactivité

– Sociabilité

B.6.1 Catégories ou modèles d’agentsOn peut établir une classification des agents en distinguant des agents cognitifs ou des agents

réactifs (figure 2) (figure 3) respectivement [15].

Figure B.2 – Modèle d’agent cognitif


Figure B.3 – Modèle d’agent réactif

Les agents cognitifs sont la plupart du temps intentionnels, c’est-à-dire qu’ils ont des buts fixésqu’ils tentent d’accomplir. On peut cependant trouver parfois des agents dits modules qui, s’ilsont une représentation de leur univers, n’ont pas de buts précis. Ils pourraient servir par exempleà répondre à des interrogations d’autres agents sur l’univers. Les agents réactifs peuvent êtreséparés en agents pulsionnels et tropiques. Un agent pulsionnel aura une mission fixée (par exemple,s’assurer qu’un réservoir reste toujours suffisamment rempli) et déclenchera un comportement s’ilperçoit que l’environnement ne répond plus au but qui lui était affecté (le niveau du réservoir esttrop bas). L’agent tropique, lui, ne réagit qu’à l’état local de l’environnement (il y a de la lumière,je fuis). La source de motivation est dans un cas interne (agents pulsionnels qui ont une "mission"),dans l’autre cas liée uniquement à l’environnement [149].

B.7 Les plateformes SMAComme nous l’avons indiqué, les SMA constituent un instrument conceptuel pour modéliser

des domaines complexes [85]. Cependant le processus de développement reste complexe[126] tantau niveau conception de la distribution et de la communication entre agents, qu’à celui des archi-tectures et de l’implémentation [16]. De nombreuses propositions sont restées conceptuelles sansaboutir à des réalisations pratiques permettant de les valider. Certains modèles sont devenus desSMA opérationnels mais généralement les systèmes qui en résultent sont restés très dépendants deleurs applications d’origine [126]. Ce facteur limite beaucoup la diffusion des SMA.Chaib-Draa et Gageut [24] suggèrent que des outils formels permettraient :

– L’analyse et le raisonnement des SMA,

– La description des SMA

– La spécification et la vérification des propriétés des SMA

– L’élaboration d’une base commune sur laquelle peuvent être construites des théories plusprofondes sur l’action sociale, l’interaction et la coopération.

Ces mêmes auteurs [24] pensent que la logique présente des avantages certains :

– Une utilisation de la logique permet aux concepteurs de SMA de spécifier, de vérifier et deraisonner sur ces systèmes.

– Un langage défini qui identifie des classes d’objets syntaxiquement acceptables.

– Une sémantique bien définie qui attribue à chaque objet une signification formelle.


– Une théorie de la preuve et de la réfutabilité bien définie qui permet d’examiner de nouvellesinférences.

Les outils génériques relèvent de deux soucis principaux, d’une part la réalisation de classesde base traitant d’agents, d’interactions, d’organisations, . . . , d’autre part des outils plus intégrésprenant en charge la coordination entre les différents éléments du système [50]. Actuellement, onobserve une prolifération de plateformes cherchant à répondre à l’ensemble de ces problèmes. Cesplateformes sont conçues [50] :

– Par rapport à un modèle d’agent particulier et orienté vers une communication entre systèmesdistribués (par exemple : ZEUS, MadKit, JACK),

– Par rapport à un domaine d’application (CORMAS),

– Comme agents mobiles (exemple : AGLETS),

– Pour être orientées vers la construction de modèles de simulations (SWARM, CORMAS).Actuellement, on peut regrouper ces environnements de développement en cinq catégories[50] :

1. Les outils pour la simulation qui permettent de fournir un ensemble d’outils et de bi-bliothèques pour faciliter le développement de simulations multi agents.

2. Les outils pour l’implémentation d’architectures d’agents.

3. Les outils pour la conception fondés sur un modèle componentiel.

4. Les outils pour la conception et l’implémentation offrant un ensemble d’utilitaires pourdéfinir un groupe d’agents,

5. Les outils pour la conception, l’implémentation et la validation.

B.8 ConclusionSi de nombreux environnements Multi Agents ont pour objectif de faire coopérer les agents en

vue de la réalisation d’un but commun, d’autres systèmes en revanche utilisent des agents qui ontdes intérêts nécessitant une négociation entre eux. En effet, lorsque plusieurs agents interagissent,des conflits peuvent survenir, ce qui nécessite l’utilisation de mécanismes de résolution de conflits.

Bibliographie

[1] M. ABDELHADI et D. HAMDADOU. Vers un protocole de négociation dans un systèmed’aide multicritères à la décision de groupe. In proceedings of JSSA’16 ; Larache, Maroc,2016.

[2] M. ABDELHADI, D. HAMDADOU, N. MENNI. A Communication Platform for GroupDecision Support System : Based Web Services and Multicriteria Method. Journal of Inter-national Journal of E-Services and Mobile Applications, Volume(10)3, pp 19-41, 2018.

[3] A. ADLA. Aide à la Facilitation pour une prise de Décision Collective : Proposition d’unModèle et d’un Outil. Thèse de Doctorat, Université Paul Sabatier - Toulouse III, France,2010.

[4] M. W. AIKEN,O. R. LIU SHENG, et D.R. VOGEL. Integrating expert systems with groupdecision support systems. Journal of ACM Transactions on information systems, Volume(9)1,pp 75-95, 1991.

[5] J. ALDRIN. Etude des processus de décision dans une organisation complexe : le cas d’uneCCI. Thèse de Doctorat, Université de Lorraine, France, 2012.

[6] R. ANSON. an Experiment Assessing Group Support System and Facilitator Effects on Mee-ting Outcomes. Journal of ManagementScience, Volume(41)2, pp 189-208, 1995.

[7] Z. C. AYE. A Collaborative Web-GIS Based Decision Support Platform for Risk Managementof Natural Hazards. Thèse de Doctorat, Université de Lausanne, Faculté des géosciences etde l’environnement, Suisse, 2016.

[8] T. BALLMER et W. BRENNENSTUHL. Speech act classification : a study in the lexicalanalysis of english speech activity verbs. Editions Springer-Verlag Berlin Heidelberg, 1981.

[9] M. BEER, M. D’INVERNO, M. LUCK, N. JENNINGS, C. PREIST, et M. SCHROEDER.Negotiation in multi-agent systems. Journal of knowledge engineering review, Volume(14)3,pp 285-289, 1981.

[10] A. BEKAIRI et M.BEKHTI. Élaboration d’un système d’aide multicritère à la décision degroupe basé sur la théorie des jeux. Mémoire d’ingénieur, Université d’Oran, Algérie, 2010.

[11] V. BELTON. Multiple criteria decision analysis : practically the only way to choose. EditionsSUniversity of Strathclyde, Strathclyde Business School, 1990.

[12] A. BENABBOU. Vers un système interactif d’aide multicritère à la décision de groupe enaménagement du territoire. Mémoire de Magister, Université d’Oran, Algérie, 2010.

[13] I. BENSAADA. Conception d’un GDSS : Une approche basée sur les web services et lesagents. Mémoire de Master, Université Oran 1 Ahmed Benbella, Algérie, 2012.

[14] J. BENTAHAR et J. LABBAN. An argumentation-driven model for flexible and efficientpersuasive negotiation. Journal of Group Decision and Negotiation, Volume(20)4, pp 411-435, 2011.

[15] F. BERGENTI, A. POGGI A development toolkit to realize autonomous and interoperableagents. In proceedings of the fifth international conference on Autonomous agents. ACM ;Montreal, Canada, 2001.

[16] O. BOISSIER, Z. GUESSOUM et M. OCCELLO. Plateformes de développement de systemesmulti-agents. Journal of l’AFIA, Volume(39), 1999.

[17] N. BOUDRAA. Élaboration d’un système d’aide multicritères à la décision spatiale degroupe : Vers une négociation par argumentation. Mémoire de Magister, Université Oran1Ahmed Benbella, Algérie, 2011.

[18] M. BRATMAN. Intention, plans, and practical reason. Editions Center for the Study ofLanguage and Information, 1987.

[19] R. A. BROOKS. Intelligence without representation. Journal of Artificial intelligence,Volume(47)1-3, pp 139-159, 1991.

[20] R. CAILLET. Analyse multicritere : Étude de comparaison des méthodes existantes en vued’une application en analyse de cycle de vie. Rapport de stage Étudiant, Centre interuniver-sitaire de recherche en analyse des organisations (CIRANO), France, 2003.

[21] G. CHAGNON, F. Nolot. Synthèse de cours et exercices corrigés : XML. Editions Pearson,2007.

[22] G. CHAGNON, F. Nolot. Méthodologie Multicritères d’Aide à la Décision, Synthèse de courset exercices corrigés, Office National des Publications (OPU), ISBN 978-9947-0-4724-8, 2017.

[23] B. CHAIBDRAA, I. JARRAS et B. MOULIN. Systèmes multi-agents : principes généraux etapplications. Journal of agents and system multi-agent : HERMES, Volume(242), pp 1030-1044, 2001.

[24] B. CHAIBDRAA et L. GAGEUT. Aspects formels des Systèmes Multi-Agents. Journal ofOrganisation et applications des systèmes multi-agents. pp 109-132, 2002.

[25] S. CHAKHAR, V. MOUSSEAU, C. PUSCEDU et B. ROY. Decision map for spatial decisionmaking in urbanism planning. In proceedings of ROADEF’2005 ; Tours, France, 2005.

[26] M. CHANG et C.WOO. A speech-act-based negotiation protocol : Design, implementation,and test use. Journal of ACM Transactions on Information Systems, Volume(12)4, pp 360-382, 1994.

[27] M. CHEN, Y. LIOU, C. W. WANG, Y. W. FAN et Y. P. J. CHI. TeamSpirit : Design,implémentation, and évaluation of a Web-based group decision support system. Journal ofDecision Support Systems, Volume(43)4, pp 1186-1202, 2007.

[28] L. CHIDAMBARAM. Relational development in computer supported groups. Journal of Ma-nagement Information Systems Quarterly, Volume(20)2, pp 143-166, 1996.

[29] S. CHOLLET. Orchestration de services hétérogènes et sécurisés. Thèse de Doctorat, univer-sité Joseph Fourrier Grenoble I, France, 2009.

[30] S. E. CONRY, R. A. MEYER et V. R. LESSER. Multistage negotiation in distributed plan-ning. In Readings in distributed artificial intelligence. pp 367-384, 1988.

[31] B. DALY. The influence of face-to-face versus computer mediated communication channelson collective induction. Journal of Accounting, Management and Information Technology,Volume(3)1, pp 1-22, 1993.

[32] F. DELECROIX, M. MORGE et J. C. ROUTIER. Group Support Systems for Strategic Plan-ningRéduire l’arbitraire par la négociation quitte à concéder. Journal of Revue des Scienceset Technologies de l’Information-Série RIA : Revue d’Intelligence Artificielle, Volume(28)4,pp 433-462, 2014.

[33] A. DENNIS. Group Support Systems for Strategic Planning. Journal of Management Infor-mation Systems, Volume(14)1, pp 155-184, 1988.

[34] G.DESANCTIS et R.B.GALLUPE. A foundation for the study of group decision supportsystems. Journal of Management science, Volume(33)5, pp 589-609, 1987.

[35] P. F. DRUCKER. Effective Decisions. Editions Harvard University. Graduate school of bu-siness administration, 1967.

[36] P. M. DUNG. On the acceptability of arguments and its fundamental role in nonmonoto-nic reasoning, logic programming and n-person games. Journal of artificial intelligence, Vo-lume(77)2, pp 321-357, 1995.

[37] U. ENDRISS. Monotonic concession protocols for multilateral negotiation. In proceedings ofAAMAS’2006 ; Hakodate, Japan, 2006.

[38] B. ESPINASSE. Coordination et négociation dans les systèmes multiagents, Notes de cours,Université d’Aix- Marseille, France, 2008.

[39] M. FAVIER. Comment gérer une équipe virtuelle. Une approche par les systèmes d’aide àla décision collective sur Internet. In proceedings of Actes du 3ème Colloque de l’A.I.M ;Strasbourg, France, 1997.

[40] J. FERBER. Les systèmes multi-agents : Vers une intelligence collective. Editions InterEdi-tions, Paris, 1995.

[41] J. FERBER et O. GUTKNECHT. A meta-model for the analysis and design of organizationsin multi-agent systems. In proceedings of ICMAS’1998 ; Paris, France, 1998.

[42] J. FERBER et G. WEISS. Multi-agent systems : an introduction to distributed artificialintelligence. Editions Addison-Wesley, 1999.

[43] A. FERNANDEZ. Les nouveaux tableaux de bord des managers Le projet décisionnel danssa totalité. Éditions d’Organisation, 1999.

[44] N. FERRAND, Y.DEMAZEAU et C. BAEIJS. Systemes multi-agents réactifs pour la réso-lution de problemes spatialisés. Journal of Intelligence Artificielle, Volume(12)1, pp 37-72,1998.

[45] R. T. FIELDING et R. N. TAYLOR. Architectural styles and the design of network-basedsoftware architectures. Editions Irvine, USA : University of California, Irvine, 2000.

[46] C. FLOCH. Cognitive Modeling of interactions during a negotiation process. In proceedingsof ICEIS’2008 ; Barcelone, Espagne, 2008.

[47] R. B. GALLUPE, A. R. DENNIS, W. H.COOPER, J. S. VALACICH, L. M. BASTIANUTTIet J. F. NUNAMAKER Jr. Electronic Brainstorming and Group Size. Journal of Academyof Management, Volume(35)2, pp 350-369, 1992.

[48] W.F. GLUECK. Business policy : Strategy formation and management action. EditionsMcGraw-Hill, 1972.

[49] A. GROULS. Agents et systèmes multi-agents : vers une synthèse de ces concepts. Mémoirede Maitrise, Université du Québec, Montréal, 2013.

[50] Z. GUESSOUM et M. OCCELLO. Environnements de développement. Dans Principes etarchitectures des systèmes multi-agents. Journal of Hermès, Lavoisier, Volume(24)5, pp 177-202, 2001.

[51] N. HADIDI. Unification de l’Argumentation et de la Théorie des Jeux pour la négociationautomatisée. Thèse de Doctorat, Université de Paris Descartes, France, 2012.

[52] D. HAMDADOU. un modèle d’aide à la décision en AT, une approche de négociation et uneapproche multicritères. Thèse de Doctorat, Université Oran1 Ahmed Benbella, Algérie, 2008.

[53] D. HAMDADOU et T. LIBOUREL. A MultiCriteria Group Decision Support System forIndustrial Diagnosis. Journal of INFOCOMP, Volume(10)3, pp 12-14, 2011.

[54] D. HAMDADOU et K. BOUAMRANE. A spatial group decision support system : Couplingnegotiation and multicriteria approaches. Journal of Intelligent Decision Technologies, Vo-lume(10)2, pp 129-147, 2016.

[55] D. HAMDADOU. Méthodologie Multicritères d’Aide à la Décision, Cours et Exercices, OfficeNational des Publications (OPU), ISBN 978-9947-0-4724-8, 2017.

[56] S. HASSAS et M. MORGE. Dynamiques, Couplages et Visions Intégratives des SystèmesMulti-Agents. Journal of Intelligence Artificielle-RSTI série RIA, Volume(28)4, pp 105, 2014.

[57] R. L. HAYEN, A. S. SWABY et Z. HUANG.Use of group support systems in today’s society.Journal of Information Systems, Volume(8)2, pp 120-126, 2007.

[58] M. HEMAISSIA, A. ELFALLAH SEGHROUCHNI, C. LABREUCHE et J. MATTIOLI.A multilateral multiissue negotiation protocol. In proceedings of AAMAS’2007 ; Honolulu,Hawaii, 2007.

[59] C. W.HOFER et D. SCHENDEL. Strategy Formulation : Analytical Concepts. EditionsSouth-Western, 1978.

[60] G. HUBERT. Issues in the design of group decision support systems. Journal of MIS Quar-terly, Volume(8)3, pp 195-204, 1984.

[61] N. IDRISS. Composition automatique des services Web à base des agents coopératifs. Mémoirede Master, Université de Kairouan Tunisie, 2012.

[62] I. IGOULALENE L. BENYOUCEF et M.K. TIWARI. Novel fuzzy hybrid multi-criteriagroup decision making approaches for the strategic supplier selection problem. Journal ofExpert Systems with Applications, Volume(42)7, pp 3342-3356, 2015.

[63] F. JOERIN. Décider sur le territoire : proposition d’une approche par utilisation de SIGet de méthodes d’analyse multicritères. Thèse de Doctorat, École polytechnique fédérale deLausanne, Suisse, 1998.

[64] R. JOHANSEN, D. SIBBET , S. BENSON, A. MARTIN, R. MITTMAN, P. SAFFO. Lea-ding business teams : How teams can use technology and group process tools to enhanceperformance. Editions Addison-Wesley Longman Publishing Co, Inc, 1991.

[65] T. JOLIVEAU, S. GENEVOIS. Travail collaboratif et information géographique pour l’ensei-gnement secondaire. Journal of Revue Internationale de Géomatique, Volume(18), pp 531-548, 2008.

[66] N. KABACHI. Modélisation et apprentissage de la prise de décision dans les organisationsproductives : approche multi-agents. Thèse de Doctorat, Université Jean Monnet et ÉcoleNationale Supérieure des Mines de Saint-Étienne, France, 1999.

[67] D. KAHNEMANN, P. SLOVIC et A. TVERSKY. Jugdments under uncertainty : Heuristicsand biases. Editions Cambridge University Press, 1982.

[68] F. LABORIE. Le concept de salle de décision collective et son application aux processuscomplexes EADS. Thèse de Doctorat, Université Toulouse III, France, 1999.

[69] E. J. LAGREZE. Prefcalc : Évaluation et décision multicritère. Journal of Revue de l’Utili-sateur de l’IBM PC, Volume(3), pp 38-55, 1984.

[70] F. LANG et A. FINK. Learning from the metaheuristics : Protocols for automated negotia-tions. Journal of Group Decision et Negotiation, Volume(24)2, pp 299-332, 2015.

[71] D. LESTEL, B. GRISON et A. DROGOUL. Les agents réactifs et le vivant dans une pers-pective d’évolution coopérative. Journal of Intellectica, Volume(19)2, pp 73-90, 1994.

[72] P. LÉVINE, J-C. POMEROL. Systèmes interactifs d’aide à la décision et systèmes experts.Editions Hermès, 1990.

[73] T. W. MALONE. What is coordination theory et how can it help design cooperative worksystems ?. In proceedings of ACM conference on Computer-supported cooperative work, LosAngeles, CA, USA, 1990.

[74] G. M. MARAKAS. Decision support system in the twenty first century. Editions PrenticeHall, 1999.

[75] A. C. MARIN. Une approche orientée domaine pour la composition de services. Thèse deDoctorat, Université Joseph Fourier Grenoble I, France, 2008.

[76] L. Y. MAYSTRE, J. PICTET et J. SIMOS. Méthodes multicritères ELECTRE : description,conseils pratiques et cas d’application à la gestion environnementale. Editions PPUR pressespolytechniques, 1994.

[77] R. MAZZOLINI. How strategic decisions are made. Journal of Long Range Planning, Vo-lume(14)3, pp 85-96, 1981.

[78] S. B. MENA. Introduction aux méthodes multicritères d’aide à la Décision. Journal of Bio-technologie, Agronomie, Société et Environnement, Volume(4)2, pp 88-93, 2000.

[79] H. MINTZBERG. Strategy-making in three modes. Journal of California management review,Volume(16)2, pp 44-53, 1973.

[80] H. MINTZBERG, Henry, D. RAISINGHANI et A. THEORET. The structure of" unstructu-red" decision processes. Journal of Administrative science quarterly, Volume(21)2, pp 246-275,1976.

[81] S. M. MIRANDA et R. P. BOSTROM Meeting facilitation : process versus content interven-tions. Journal of Management information systems, Volume(15)4, pp 89-114, 1999.

[82] M. MORGE et P. MANCARELLA, Arguing over goals for negotiation : Adopting anassumption-based argumentation decision support system. Journal of Group Decision andNegotiation, Volume(23)5, pp 979-1012, 2014.

[83] V. MOUSSEAU. Méthodes de surclassement, Notes de Cours pour DEA Méthodes Scienti-fique de Gestion, 2003.

[84] H. J. MULLER. Negotiation principles in Foundations of Distributed Artificial IntelligenceGMP O’Hare, NR Jennings. Journal of John Wiley and Sons, Volume(51), pp 211-229, 1996.

[85] J. P. MULLER. The design of intelligent agents : a layered approach. Editions SpringerScience & Business Media, 1996.

[86] Jr. NASH et F. JOHN. The bargaining problem. Journal of Econometrica : Journal of theEconometric Society, Volume(18)2, pp 155-162, 1950.

[87] G. MP. O’HARE, N. R. JENNINGS et N. JENNINGS. Foundations of distributed artificialintelligence. Editions John Wiley & Sons, 1996.

[88] M. OKUMURA, K. FUJITA et T. ITO. An implementation of collective collaboration sup-port system based on automated multi-agent negotiation. Journal of In Complex AutomatedNegotiations : Theories, Models, and Software Competitions, Volume(435), pp 125-141, 2013.

[89] S. OUFELLA, D. HAMDADOU et K. BOUAMRANE. Conception d’un système interactifd’aide à la décision collective en localisation spatiale. In proceedings of CIIA’2009 ; Saida,Algérie, 2009.

[90] S. OUFELLA. Élaboration d’un système d’aide multicritère à la décision spatiale de groupe :négociation par argumentation. Thèse de Doctorat, Université Oran1 Ahmed Benbella, Al-gérie, 2018.

[91] P. M. PAPAZOGLOU et W. J. VAN DEN HEUVEL. Service oriented architectures : ap-proaches, technologies and research issues. Journal of The VLDB, Volume(16)3, pp 389-415,2007.

[92] S. PARSONS, C. SIERRA et N. JENNINGS. Agents that reason and negotiate by arguing.Journal of Logic and computation, Volume(8)3, pp 261-292, 1998.

[93] J. PISSARRA et J. C. JESUINO, Idea generation through computer-mediated communica-tion : The effects of anonymity. Journal of Managerial Psychology, Volume(20)3, pp 275-292,2005.

[94] D. G. PRUITT. Negotiation behavior. Editions Academic Press Elsevier, 1981.

[95] A. S. RAO, M. P. GEORGEFF. The semantics of intention maintenance for rational agents.In proceedings of 14th International Joint Conference on Artificial Intelligence IJCAI’95 ;San Francisco, CA, USA, 1995.

[96] N. ROMANO, J. F. NUNAMAKER, R. BRIGGS, et D. D. MITTLEMAN. Distributed gssfacilitation and participation : Field action research. In proceedings of the 32nd AnnualHawaii International Conference, 1999.

[97] B. ROY Classement et choix en présence de points de vue multiples : La méthode ELECTRE.Journal of Revue Française d’informatique et de Recherche Opérationnelle, Volume(8), pp57-75, 1968.

[98] B. ROY Problems and methods with multiple objective functions. Journal of Mathematicalprogramming, Volume(1)1, pp 239-266, 1971.

[99] B. ROY, J. C. HUGONNARD. Ranking of suburban line extension projects on the Parismetro system by a multicriteria method. Journal of Politiques et Management Public, Vo-lume(16A)4, pp 301-312, 1982.

[100] B. ROY Méthodologie multicritère d’aide à la décision. Journal of Politiques et ManagementPublic, Volume(4)3, pp 138-140, 1985.

[101] B. ROY. Des critères multiples en recherche opérationnelle : pourquoi ?. Editions North-Holland, 1988.

[102] B. ROY, D. BOUYSSOU. Aide multicritère à la décision : méthodes et cas. Editions Econo-mica Paris, France, 1993.

[103] B. ROY. Réflexions sur le thème quête de l’optimum et aide à la décision. Notes de cours,Université de Paris Dauphine, France, 2000.

[104] J. E. RUSSO et P. J. H. SHOEMAKER. Les chausses trappes de la decision. Editions d’or-ganisation, 1994.

[105] D. K. SCHNEIDER. Modélisation de la démarche du décideur politique dans la perspectivede l’intelligence artificielle. Thèse de Doctorat, Université de Genève, Suisse, 1996.

[106] C. R. SCHWENK. Effects of planning aids and presentation media on performance and af-fective responses in strategic decision-making. Journal of Management Science, Volume(30)3,pp 263-272, 1984.

[107] A. SHARLIG. Décider sur plusieurs critères : panorama de l’aide à la décision multicritères.Editions PPUR presses polytechniques, 1985.

[108] G. J. SHAW User satisfaction in group support systems research : a Meta-analysis of experi-mental results. In proceedings of the 31st Annual Hawaii International Conference on SystemSciences ; Hawaii, 1998.

[109] S. S. SIAN. Adaptation based on cooperative learning in multi-agent systems. Journal ofDecentralized AI, Volume(2), pp 257-272, 1991.

[110] H. SIMOS. Centralization vs. decentralization in organizing the controller’s department : Aresearch study and report. Editions Controllership Foundation, 1954.

[111] H. SIMOS. The new science of management decision. Editions prentice-hall. EnglewoodCliffs, NJ, 1977.

[112] J. SIMOS. Evaluer l’impact sur l’environnement : Une approche originale par l’analyse mul-ticritère et la négociation. Journal of Géographie physique et Quaternaire, Volume(47)1, pp126-127, 1990.

[113] R. G. SMITH. The contract net protocol : High-level communication and control in a distribu-ted problem solver. Journal of IEEE Transactions on computers, Volume(12), pp 1104-1113,1991.

[114] K. SYCARA. Multiagent compromise via negotiation. Journal of distributed artificial intel-ligence, Volume(2), pp 119-139, 1989.

[115] K. SYCARA. Persuasive argumentation in negotiation. Journal of Theory and decision, Vo-lume(28)3, pp 203-242, 1990.

[116] B. TAIBI. L’analyse Multicritère comme outil d’aide à la décision : Application de la méthodePROMETHEE. Mémoire de Magister, Université Abou Bekr Belkaid Tlemcen, Algérie. 2010.

[117] M. TILLE. Choix de variantes d’infrastructures routières : méthodes multicritères. Thèse deDoctorat, École Polytechnique Fédérale De Lausanne, Suisse, 2000.

[118] D. TRENTESEAUX. Conception d’un système de pilotage distribuè, supervisè et multicritérepour les systèmes automatisé de production. Thèse de Doctorat, Institut National Polytech-nique de Grenoble-INPG, France, 1996.

[119] J. S. VALACICH, A. R. DENNIS et J. F. NUNAMKER. A Conceptual Framework of Anony-mity in Group Support Systems. In proceedings of the 25th Hawaii International Conferenceon Systems Sciences, Hawaii ; 1992.

[120] M. H. VERRONS. GeNCA : un modèle général de négociation de contrats entre agents. Thèsede Doctorat, Université des Sciences et Technologie de Lille, France, 2004.

[121] W. VICKREY. Counterspeculation, auctions, and competitive sealed tenders. Journal of fi-nance, Volume(16)1, pp 8-37, 1961.

[122] J. M. VIDAL. Fundamentals of Multiagent Systems : Using NetLogo Models. Unpublished,2006.

[123] P. VINCKE et B. ROY. Theory of games and economic behavior. Editions Université deBruxelles, 1989.

[124] J. VON NEUMANN et O. MORGENSTERN. Theory of games and economic behavior.Editions Princeton university press, 1944.

[125] S. WILLART et M. CALCIU, Construction d’un Service Web d’Aide à la Décision Geo-Marketing à partir d’Outils OpenSource. In proceedings of Colloque Etienne Thil 2012 ; Lille,France, 2012.

[126] M. WOOLDRIGE et N. R. JENNINGS. Intelligent agents : Theory and practice. Journal ofThe knowledge engineering review, Volume(10)2, pp 115-152, 1995.

[127] M. WOOLDRIDGE. An introduction to multiagent systems. Editions John Wiley and Sons,2009.

WEBOGRAPHIE

Webographie

[128] Site de l’unige, "systèmes d’aide à la décision". https://tecfa.unige.ch/tecfa/publicat/schneider/these-daniel/wmwork/www/phd_112.html, Consulté en 2016.

[129] Wikipédia, "Décision". https://fr.wikipedia.org/wiki/D%C3%A9cision, 2015.

[130] Wikipédia, "Délibération". https://fr.wikipedia.org/wiki/DC3%A9lib%C3A9ration,Consulté en 2017.

[131] W. HOUSER, J.GRIFFINET et C. HAGE, "EDI Meets the Internet 1865". http://www.ietf.org/rfc/rfc1865.txt,January1996, Consulté en 2017.

[132] Wikipédia, "Extensible Markup Language". https://fr.wikipedia.org/wiki/Extensible_Markup_Language, Consulté en 2017.

[133] Wikipédia, "Google Web Toolkit". https://fr.wikipedia.org/wiki/Google_Web_Toolkit, Consulté en 2018.

[134] Le site de Jean Paul FIGER, "Historique de Rest". https://www.figer.com/Publications/SOA.htm#historique-de-rest, Consulté en 2017.

[135] Wikipédia, "Hypertext Transfer Protocol". https://fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol, Consulté en 2017.

[136] Wikipédia, "Instagram". https://fr.wikipedia.org/wiki/Instagram, Consulté en 2018.

[137] Le site Tutorials Point, "Introduction au Restful". http://www.tutorialspoint.com/restful/restful_introduction.htm, Consulté en 2017.

[138] Wikipédia, "Jersey". https://fr.wikipedia.org/wiki/Jersey_(framework), Consulté en2018.

[139] Site de l’institut numérique, "Les services Web". http://www.institut-numerique.org/12-les-services-web-51f7a7f9c2daa, Consulté en 2017.

[140] Wikipédia, "Prise de décision". https://fr.wikipedia.org/wiki/Prise_de_d%C3A9cision, Consulté en 2015.

[141] Le site de Jean Paul FIGER, "Rest". http://http://www.figer.com/publications/REST.htm, Consulté en 2017.

[142] Le site de Jean-Michel DOUDOUX, "Service web". http://www.jmdoudoux.fr/java/dej/chap-service-web.htm, Consulté en 2017.

[143] Site de développement de Gmail, "Service Web de Gmail". https://developers.google.com/gmail/api/?hl=en, Consulté en 2018.

[144] Site de développement de Github, "Service Web de Github". https://developer.github.com/, Consulté en 2018.

[145] Site de développement de Instagram, "Service Web de Instagram". https://www.instagram.com/developer/, Consulté en 2018.

[146] Site de développement de Wunderground, "Service Web de Wunderground".https://developer.github.com/https://www.programmableweb.com/api/weather-underground-wunderground, Consulté en 2018.

https://tecfa.unige.ch/ tecfa/publicat/schneider/these-daniel/wmwork/www/phd_112.html

https://tecfa.unige.ch/ tecfa/publicat/schneider/these-daniel/wmwork/www/phd_112.html

https://fr.wikipedia.org/wiki/D%C3%A9cision

https://fr.wikipedia.org/wiki/DC3%A9lib%C3A9ration

http ://www.ietf.org/rfc/rfc1865.txt, January 1996

http ://www.ietf.org/rfc/rfc1865.txt, January 1996

https://fr.wikipedia.org/wiki/Extensible_Markup_Language

https://fr.wikipedia.org/wiki/Extensible_Markup_Language

https://fr.wikipedia.org/wiki/Google_Web_Toolkit

https://fr.wikipedia.org/wiki/Google_Web_Toolkit

https://www.figer.com/Publications/SOA.htm#historique-de-rest

https://www.figer.com/Publications/SOA.htm#historique-de-rest

https://fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol

https://fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol

https://fr.wikipedia.org/wiki/Instagram

http://www.tutorialspoint.com/restful/restful_introduction.htm

http://www.tutorialspoint.com/restful/restful_introduction.htm

https://fr.wikipedia.org/wiki/Jersey_(framework)

http://www.institut-numerique.org/12-les-services-web-51f7a7f9c2daa

http://www.institut-numerique.org/12-les-services-web-51f7a7f9c2daa

https://fr.wikipedia.org/wiki/Prise_de_d%C3A9cision

https://fr.wikipedia.org/wiki/Prise_de_d%C3A9cision

http : //http://www.figer.com/publications/REST.htm

http : //http://www.figer.com/publications/REST.htm

http://www.jmdoudoux.fr/java/dej/chap-service-web.htm

http://www.jmdoudoux.fr/java/dej/chap-service-web.htm

https://developers.google.com/gmail/api/?hl=en

https://developers.google.com/gmail/api/?hl=en

https://developer.github.com/

https://developer.github.com/

https://www.instagram.com/developer/

https://www.instagram.com/developer/

https://developer.github.com/https://www.programmableweb.com/api/weather-underground-wunderground

https://developer.github.com/https://www.programmableweb.com/api/weather-underground-wunderground

WEBOGRAPHIE

[147] Wikipédia, "Simple Mail Transfer Protocol". https://fr.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol, Consulté en 2017.

[148] Wikipédia, "SOAP". https://fr.wikipedia.org/wiki/SOAP, Consulté en 2016.

[149] Wikipédia, "Systèmes multi agents". https://fr.wikipedia.org/wiki/Syst%C3%A8me_multi-agents, Consulté en 2018.

[150] Le site open SoftTeam, "Technologie web services". http://www.softeam.fr/technologies_web_services.php, Consulté en 2017.

[151] Site de l’univesité UNICE Sophia ANTIPOLIS, "Web services". http://deptinfo.unice.fr/twiki/pub/Linfo/Organisation%20Rapports/rapport-WebServices.pdf, Consultéen 2016.

[152] Le site comment ça marche, "web service". https://www.commentcamarche.com/contents/1244-web-services, Consulté en 2017.

[153] Le site open classroom, "web service". https://openclassrooms.com/courses/les-services-web, Consulté en 2017

https://fr.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol

https://fr.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol

https://fr.wikipedia.org/wiki/SOAP

https://fr.wikipedia.org/wiki/Syst%C3%A8me_multi-agents

https://fr.wikipedia.org/wiki/Syst%C3%A8me_multi-agents

http : //www.softeam.fr/technologies_web_services.php

http : //www.softeam.fr/technologies_web_services.php

http://deptinfo.unice.fr/twiki/pub/Linfo/Organisation%20Rapports/rapport-WebServices.pdf

http://deptinfo.unice.fr/twiki/pub/Linfo/Organisation%20Rapports/rapport-WebServices.pdf

https://www.commentcamarche.com/contents/1244-web-services

https://www.commentcamarche.com/contents/1244-web-services

https://openclassrooms.com/courses/les-services-web

https://openclassrooms.com/courses/les-services-web

WEBOGRAPHIE

DOI: 10.4018/IJESMA.2018070102

International Journal of E-Services and Mobile ApplicationsVolume 10 • Issue 3 • July-September 2018

Copyright©2018,IGIGlobal.CopyingordistributinginprintorelectronicformswithoutwrittenpermissionofIGIGlobalisprohibited.

19

A Communication Platform for Group Decision Support System:Based Web Services and Multicriteria MethodMounya Abdelhadi, Department of Computer Science, University of Oran 1, Ahmed Ben Bella, Laboratory LIO, Algeria

Djamila Hamdadou, Department of Computer Science, University of Oran 1, Ahmed Ben Bella, Laboratory LIO, Algeria

Nabil Menni, Department of Computer Science, University of Oran 1, Ahmed Ben Bella, Laboratory LIO, Algeria

ABSTRACT

Inagroupdecisionsupportsystem,thevariousdecision-makershavetheirowninformation,constrains,decisionstrategies,preferences,andobjectiveswhicharegenerallynotsharedorcommunicated.Thisimpliesthatthegroupdecisionprocessisdistributedbetweenthedifferententitiesimplicatedandimpactedbyvariousgroupmembers’characteristics.Solutiontothisproblemistofindadecisionthatwouldbeacceptabletoallthedecision-makers,followingthenecessityofanegotiationprocessthatallowstheelaborationofacommonagreementforagroupthatfacesaconflictonthedecisiontotake.Inthecurrentstudy,theauthorsproposetoestablishacommunicationplatformforagroupdecisionsupportsystem(GDSS)basedonwebservices,incorporatingamulticriteriaanalysismethodsandanegotiationprotocol.

KEyWoRDSDecision Support, Group Decision Support System (GDSS), Multicriteria Analysis, Negotiation Protocol, Promethee II, Web Services

1. INTRoDUCTIoN

Decision-makingreferstotheselectionofthebestsolutionamongseveralpossibilities,whichrequiresevaluatingthesepossibilitiesregardingtoseveralcriteria.Thecaseofthesinglecriteriaisnotusefulinreal-worldsettings.MulticriteriaDecisionSupportaimstohandlethisissueandallowsdecision-makerstocreateahierarchicalrepresentationofasetofsolutionsbasedontheirimportanceaccordingto thedifferentcriteria.Due to theirefficiency,multicriteriadecisionsupportmethodsareoftenintegratedthecurrentdecisionsupportsystems.However,thesesystemsmustadapttotherealityofgroupdecisionmaking,andextendingtowhatiscalledasGroupDecisionSupportSystems(GDSS).

Collegialityindecision-makingmaybeexplicitlyrequiredbythetypeofproblembeingaddressedorbecauseofastructuralchoice.Inbothcases,thedecisionalprocessmulti-makershavetoresulttoadecisionthathasconsensuswithinthegroupofdecision-makers.Therefore,aGDSShastoprovidemechanismstofacilitatetheconfrontationofviewsandallowsguidingagrouptowardsasolution

International Journal of E-Services and Mobile ApplicationsVolume 10 • Issue 3 • July-September 2018

20

thatismutuallyacceptable.Moreover,collaborativeworkingeneralhasevolvedconsiderablybyexploitingalltheadvantagesofnewtechnologies.Agroupshouldnolongerbegatheredinoneplacetowork.GDSShastobealignedtothislogicandallowgeographicallydisperseddecision-makerstohandletheirtasks.

Inordertorespondtoalltheserequirements,theauthorsproposeanegotiationprotocoltomanagetheconflictsbetweendecision-makerswhich is integrated intowithamulticriteriamethod.Theauthors’contributionthroughthisstudyconsistsofdesigningandimplementingacommunicationplatformthatallowgeographicallydispersedecision-makerstoparticipateandresolveadecisionproblem.Thisplatformprovidesalsotheinteroperabilityrequiredforfutureintegrationwithothersystemsandapplications,justifyingthewebservicesuse.Inordertoachievethisgoal,web-servicestechnologyisusedtoimplementtheproposedplatform.

Section2,presentabriefdescriptionofthemajorworkongroupdecisionsupportandrelatedissues.Section3focusesontheauthors’contribution.Section4isdedicatedtoprovideadetaileddescriptionoftheproposedsystem,whichincludesthenegotiationprotocolandthemulticriteriamethodused(PrometheeIIinthiscase).Section5definesthewebservices.Section6isdedicatedtoarealcasestudy.Finally,section7concludesthediscussionbyhighlightingthelimitationsoftheproposedsystemandsomeconsiderationsforfutureresearch.

2. RELATED WoRK

Inthedomainofdecisionsupport,thereisavarietyofsystemsdesignedtotreatdifferenttypesofdecision-making.However,thedecisionsupportisgroupedintotwobroadcategories:(i)Thesingle-actordecisionsupport-Adecision-makerformsanopinionbasedontheinformationavailabletohim(nottheexpertise),aswellashispersonalorientations(values),and(ii)Themulti-actordecisionsupport-Severalactorsdecidewithtogetheronanissue,withpersonalviewsoftendivergentcomparedtoothers,whichoftenrequiresthenegotiationprocess.

Inthecontextofsingle-actordecisionsupport,severaldecisionsupportsystemsinTP(TerritoryPlanning)havecaughtattention.Joering(1997)proposesystemMEDUSATfor locating thesiteofawaste treatmentplant inTunisia.MEDUSATcombinesaGIS toolallowing thecreationofhomogenousareasdeterminedfromspatialdataandcommonland(constitutingasimilarityindex);theseareasconstituteasetofpossiblesolutions.Bensaidetal.(2007)useMulticriteriaanalysisasatoolfordecisionmakingforspatiallocalizationofareasunderheavyhumanpressure.Inthesamearea,Čančer(2012)introducestheuseofthe5Ws&Htechnique,whichisthecreativeproblem-solvingtechniquebasedonwho,what,when,where,whyandhowquestions,fortheestablishingofthecriteriaweightsinmulti-criteriadecision-making.AcasestudywaspresentedattheUniversityofNaama,Algeria in the samework.Variousdecision support systems rich in spatial toolsandmulticriteriaanalysismethodshavebeendevelopedformanagementanddecisionmakinginterritorialproblemsHamadouche(2011).AllthesesystemsintegrateinvariouslevelsmulticriteriaanalysistoolscoupledwithGIS,buttheyconsiderthecriteriaasindependentandunabletomodelanyinteractionbetweenthem.

Therefore, traditional decisional models adapted to the single decision-maker case are notconsistent with the organizational reality. Group decision support, or multi-participant decision,treatsprocesses,inwhichmultipledecision-makersareinvolved.AccordingtoSmoliarandSprague(2002),decisionprocessesinorganizationsusuallyinvolveseveralactorsinteractingwitheachother.Indeed,GroupDecisionSupporthasbeenthesubjectofseveralresearchworks.TheworkpresentedbytheHemaissia(2008)hasbeenconductedinordertoprovideasolutiontogroupdecisionproblemsencounteredincrisismanagementapplications,especiallythedistributedallocationproblems.Inthisoptic,theauthorshavedefinedmultidimensionalandmultilateralnegotiationprotocolsbasedoncooperation.Morge&Mancarella(2014)proposedamulti-attributequalitativedecisionsupporttoolcalledMARGO; it isbasedonanabstractapproach forcancellableargumentationofDung

21 more pages are available in the full version of this

document, which may be purchased using the "Add to Cart"

button on the product's webpage:

www.igi-global.com/article/a-communication-platform-for-

group-decision-support-system/206225?camid=4v1

This title is available in InfoSci-Digital Marketing, E-Business,

and E-Services eJournal Collection, InfoSci-Networking,

Mobile Applications, and Web Technologies eJournal

Collection, InfoSci-Journals, InfoSci-Journal Disciplines

Business, Administration, and Management, InfoSci-Journal

Disciplines Computer Science, Security, and Information

Technology, InfoSci-Select. Recommend this product to your

librarian:

www.igi-global.com/e-resources/library-

recommendation/?id=162

Related Content

Technical Audit of an Electronic Polling Station: A Case StudyHector Alaiz-Moreton, Luis Panizo-Alonso, Ramón A. Fernandez-Diaz and Javier

Alfonso-Cendon (2011). International Journal of E-Services and Mobile Applications

(pp. 16-30).

www.igi-global.com/article/technical-audit-electronic-polling-station/55495?camid=4v1a

Evaluating Information Systems with Continuous Assurance ServicesRui Pedro Marques, Henrique Santos and Carlos Santos (2016). International Journal

of Information Systems in the Service Sector (pp. 1-15).

www.igi-global.com/article/evaluating-information-systems-with-continuous-assurance-services/153982?camid=4v1a

http://www.igi-global.com/article/a-communication-platform-for-group-decision-support-system/206225?camid=4v1

http://www.igi-global.com/article/a-communication-platform-for-group-decision-support-system/206225?camid=4v1

http://www.igi-global.com/e-resources/library-recommendation/?id=162

http://www.igi-global.com/e-resources/library-recommendation/?id=162

http://www.igi-global.com/article/technical-audit-electronic-polling-station/55495?camid=4v1a

http://www.igi-global.com/article/technical-audit-electronic-polling-station/55495?camid=4v1a

http://www.igi-global.com/article/evaluating-information-systems-with-continuous-assurance-services/153982?camid=4v1a

http://www.igi-global.com/article/evaluating-information-systems-with-continuous-assurance-services/153982?camid=4v1a

User-Centric Identity, Trust and PrivacyJean-Marc Seigneur and Christian Damsgaard Jensen (2007). Trust in E-Services:

Technologies, Practices and Challenges (pp. 293-322).

www.igi-global.com/chapter/user-centric-identity-trust-privacy/30462?camid=4v1a

Evaluating the Effects of Service Quality, Customer Satisfaction, and Service

Value on Behavioral Intentions with Life Insurance Customers in IndiaRajat Gera, Sanjiv Mittal, Dharminder Kumar Batra and B Prasad (2017).

International Journal of Service Science, Management, Engineering, and Technology

(pp. 1-20).

www.igi-global.com/article/evaluating-the-effects-of-service-quality-customer-satisfaction-and-service-value-on-behavioral-intentions-with-life-insurance-customers-in-india/182512?camid=4v1a

http://www.igi-global.com/chapter/user-centric-identity-trust-privacy/30462?camid=4v1a

http://www.igi-global.com/chapter/user-centric-identity-trust-privacy/30462?camid=4v1a

http://www.igi-global.com/article/evaluating-the-effects-of-service-quality-customer-satisfaction-and-service-value-on-behavioral-intentions-with-life-insurance-customers-in-india/182512?camid=4v1a



Résumé

Dans un système d'aide à la décision de groupe, les

différents décideurs disposent de leurs propres

informations, contraintes, stratégies de décision, préférences

et objectifs qui ne sont généralement pas partagés ou

communiqués. Cela implique que le processus de décision

du groupe est réparti entre les différentes entités impliquées

et impactées par les caractéristiques des différents membres

du groupe. La solution à ce problème est de trouver une

décision qui serait acceptable pour tous les décideurs selon

leurs préférences, suite à la nécessité d'un processus de

négociation qui permet l'élaboration d'un accord commun

pour un groupe confronté à un conflit sur la décision à

prendre. Dans la présente thèse, nous proposons d'établir

une plateforme de communication pour un système d'aide à

la décision de groupe (GDSS) utilisant les services Web, et

intégrant un protocole de négociation basé sur la médiation

et l’analyse multicritères.

Mots clés :Aide à la décision ; Système d’aide à la décision de groupe (GDSS);

Analyse multicritères; Protocole de négociation; PROMETHEE II;

Services web; Rest; Systèmes multi agents; Plateforme;

Communication.

Documents

THÈSE - univ-oran1.dz