TH5010 PDF

THÈSE
En vue de l’obtention du diplôme de
Doctorat LMD
Spécialité : Informatique De La Répartition et Aide à la
Décision (IRAD)
Présentée par : Mounya ABDELHADI
Élaboration d’un modèle de négociation

par les web services dans un système
d’aide multicritères à la décision de
groupe
Soutenue publiquement devant le jury composé de :04/03/2019
M.Mohammed Fayçal KHELFI Pr, Université Oran1 Ahmed BENBELLA Président

M.Mustapha Kamel ABDI MCA, Université Oran1 Ahmed BENBELLA Examinateur
M.Larbi SEKHRI Pr, Université Oran1 Ahmed BENBELLA Examinateur
M.Abdelmalek AMINE Pr, Université Tahar Moulay Saida Examinateur
M. Mohammed BENYETTOU Pr, Université USTO Mohamed Boudiaf Examinateur
Mme. Djamila HAMDADOU Pr, Université Oran1 Ahmed BENBELLA Directrice de Thèse
I
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 ob-
jectifs 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 per-
met 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.
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 own
information, constrains, decision strategies, preferences, and objectives which are ge-
nerally not shared or communicated. This implies that the group decision process is
distributed between the different entities implicated and impacted by various group
members’ characteristics. Solution to this problem is to find a decision that would be
acceptable to all the decision-makers, following the necessity of a negotiation process
that allows the elaboration of a common agreement for a group that faces a conflict
on 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 agents
system.
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 avancer
et le courage pour avoir accompli ce modeste travail.
Mes vifs remerciements s’adressent en premier lieu à ma directrice de thèse madame Djamila
HAMDADOU, Professeur à l’université Oran1 Ahmed BENBELLA, une femme remarquable pour
m’avoir proposé ce sujet, dirigé mes travaux, pour sa gentillesse, sa disponibilité, ses conseils, son
aide 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ésider
ce 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 nous
a donnée durant notre cursus. Je tiens à remercier, chaleureusement, Monsieur Mustapha Kamel
ABDI, 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’USTO
Mohamed Boudiaf, et Monsieur Abdelmalek AMINE, Professeur à l’université Dr Tahar Moulay
Saida, 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 je
n’aurai jamais pu continuer.
Une tendre et particulière pensée va à mon mari que je remercie infiniment qui a tout fait pour
me 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 particulier
Amina 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êve
jusqu’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 8
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 L’Aide à la Décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1 La décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.2 Les niveaux de la décision . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.3 La typologie de la décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.4 Les acteurs de l’aide à la décision . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.5 Le processus décisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Les Systèmes d’Aide à la Décision (SAD) . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.1 La taxinomie des SAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 l’aide à la décision de groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.2 Le processus de prise de décision . . . . . . . . . . . . . . . . . . . . . . . . 14
1.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) . . . . . . . . . . . . . . . . . 15
1.5.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5.2 La structure d’un SADG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.3 L’architecture générale d’un processus de décision de groupe . . . . . . . . 16
1.5.4 Les intérêts des GDSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5.5 La typologie des GDSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.6 L’aide à la décision multicritères . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.6.1 Définition de l’aide à la décision multicritères . . . . . . . . . . . . . . . . . 20
1.6.2 Vocables associés à l’analyse multicritères . . . . . . . . . . . . . . . . . . . 20
1.6.3 Démarche générale d’une méthode Multicritères . . . . . . . . . . . . . . . 22
1.6.4 Classification des différentes méthodes d’Analyse Multicritères . . . . . . . 23
1.7 Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
TABLE DES MATIÈRES VII
2 La négociation dans les Systèmes Multi Agents 27

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Les agents et les systèmes multi agents . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.1 Définition d’agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.2 Typologie des agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.3 Les systèmes multi agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 La coopération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4 La résolution de conflits n’incluant pas la négociation . . . . . . . . . . . . . . . . 30
2.4.1 Take it or leave it offer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.2 One Step Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.3 Les enchères sans négociation . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.4 Les systèmes de vote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.5 La délibération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5 La résolution de conflit incluant la négociation . . . . . . . . . . . . . . . . . . . . 33
2.5.1 La négociation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6 Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3 Les services web 43

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 L’architecture orientée service SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3 Historique sur les services web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4 Les acteurs SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5 Définition du service web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5.1 Définition du ‘W3C’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5.2 Définition de ‘Dico du net’ . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5.3 Définition ‘Wikipédia’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.6 Motivation et intérêt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.7 Organisation des services web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.8 L’architecture d’un service web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.9 L’architecture étendue des services web SOAP/WSDL/UDDI . . . . . . . . . . . . 50
3.9.1 Le protocole de communication SOAP . . . . . . . . . . . . . . . . . . . . . 50
3.9.2 Le langage XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.9.3 Le langage de description WSDL . . . . . . . . . . . . . . . . . . . . . . . . 51
3.9.4 L’annuaire des services UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.9.5 Les Avantages de l’architecture étendue . . . . . . . . . . . . . . . . . . . . 53
3.9.6 Les inconvénients de l’architecture étendue . . . . . . . . . . . . . . . . . . 53
3.10 L’architecture REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.10.1 URI et Ressource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.10.2 Les méthodes HTTP (GET, POST, PUT,etc.) . . . . . . . . . . . . . . . . 54
3.10.3 Les avantages de l’architecture REST . . . . . . . . . . . . . . . . . . . . . 54
3.10.4 Les inconvénients de l’architecture REST . . . . . . . . . . . . . . . . . . . 55
3.11 Systèmes utilisant les services web . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.12 L’aide à la décision et les services web . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.13 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
TABLE DES MATIÈRES VIII
II Contributions 59
4 Modélisation de l’approche proposée 60
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 Objectifs visés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3 Modèle décisionnel proposé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4 Description du système d’aide à la décision de groupe proposé . . . . . . . . . . . . 66
4.4.1 Modèle SMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4.2 Identification des acteurs concernés . . . . . . . . . . . . . . . . . . . . . . . 67
4.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 . . . . . . . . . 89
4.6 Description des services web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.7 La Synchronisation des échanges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5 Expérimentation et résultats obtenus 100

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.1 GWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.2.2 Tomcat 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.2.3 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.2.4 Jade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.3 Espaces d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.3.1 Espace administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.3.2 Espace utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.4 Scénario illustratif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.4.1 Délimitation de la région d’étude . . . . . . . . . . . . . . . . . . . . . . . . 109
5.4.2 Identification des critères d’adéquation du territoire pour l’habitat . . . . . 109
5.4.3 Identification des différents décideurs impliqués . . . . . . . . . . . . . . . . 111
5.4.4 Description du processus décisionnel . . . . . . . . . . . . . . . . . . . . . . 112
5.5 Interprétation des échanges de messages par les agents . . . . . . . . . . . . . . . . 117
5.5.1 Phase d’initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.5.2 Phase de d’évaluation et de proposition . . . . . . . . . . . . . . . . . . . . 120
5.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 127
A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
A.2 Les méthodes d’aide multicritères à la décision . . . . . . . . . . . . . . . . . . . . 127
A.2.1 Avantages des méthodes multicritères . . . . . . . . . . . . . . . . . . . . . 127
A.2.2 Le but des méthodes d’analyse multicritères . . . . . . . . . . . . . . . . . . 128
A.2.3 Les différentes problématiques en Aide Multicritères à la Décision . . . . . 128
A.3 Classification des méthodes multicritères . . . . . . . . . . . . . . . . . . . . . . . . 129
A.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

A.4.2 La méthode ELECTRE II . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
A.4.3 La méthode ELECTRE III . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
A.4.4 La méthode ELECTRE IV . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
A.4.5 La méthode ELECTRE IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
A.4.6 La méthode ELECTRE Tri . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
A.5 La famille PROMETHEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
A.5.1 Le principe de la méthode PROMETHEE : . . . . . . . . . . . . . . . . . . 132
A.5.2 Le principe de la méthode PROMETHEE . . . . . . . . . . . . . . . . . . . 133
A.5.3 La méthode PROMETHEE I : rangement partiel . . . . . . . . . . . . . . 133
A.5.4 La méthode PROMETHEE II : rangement complet . . . . . . . . . . . . . 133
A.5.5 PROMETHEE III, alpha : Amplification de la relation d’indifférence . . . 133
A.5.6 PROMETHEE VI : Problèmes aisés ou difficiles . . . . . . . . . . . . . . . 133
A.5.7 PROMETHEE V : Problèmes multicritères avec contraintes additionnelles . 133
A.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
B Les Systèmes Multi Agents 135

B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
B.2 Acteur et agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
B.3 Définition des Systèmes Multi agents . . . . . . . . . . . . . . . . . . . . . . . . . . 135
B.4 Architecture des systèmes multi agents . . . . . . . . . . . . . . . . . . . . . . . . . 136
B.5 Caractéristiques d’un SMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
B.6 Types d’agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
B.6.1 Catégories ou modèles d’agents . . . . . . . . . . . . . . . . . . . . . . . . . 137
B.7 Les plateformes SMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
B.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Bibliographie 140
Bibliographie 140
Webographie 148
Liste des figures
1.1 Processus de décision de Simon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2 Taxinomie des SAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.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 . . . . . . . . . . . . . 34

2.2 Taxinomie des processus de résolution de conflit . . . . . . . . . . . . . . . . . . . . 35
3.1 Acteurs et rôles dans l’architecture Orientée Service . . . . . . . . . . . . . . . . . 45

3.2 Architecture en couche des services web . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3 Cycle de vie des services web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4 Structure d’un document WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.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] . . . . . . . . . . . . . . 64

4.2 Le modèle décisionnel proposé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3 Identification des rôles dans la plateforme . . . . . . . . . . . . . . . . . . . . . . . 67
4.4 Diagramme montrant la navigation dans les espaces de travail selon le rôle . . . . 67
4.5 La plateforme de communication proposée : vue d’ensemble . . . . . . . . . . . . . 68
4.6 Les acteurs et les modules dans la plateforme . . . . . . . . . . . . . . . . . . . . . 69
4.7 Diagramme de cas d’utilisation : Gestion comptes utilisateurs . . . . . . . . . . . . 70
4.8 Diagramme de cas d’utilisation : Gestion des sessions . . . . . . . . . . . . . . . . 71
4.9 Diagramme de cas d’utilisation : messagerie . . . . . . . . . . . . . . . . . . . . . . 72
4.10 Diagramme de cas d’utilisation : Partage de documents . . . . . . . . . . . . . . . 73
4.11 Diagramme de cas d’utilisation : Système de formulaires . . . . . . . . . . . . . . 74
4.12 Fonction de préférence linéaire [55] . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.13 Fonction de préférence en V [55] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.14 Démarche d’utilisation de PROMETHEE II . . . . . . . . . . . . . . . . . . . . . 78
4.15 Diagramme d’état transition : Analyse multicritères par PROMETHEE II . . . . 79
4.16 Formulaire choix simple : option A gagnante . . . . . . . . . . . . . . . . . . . . . 80
4.17 Formulaire choix multiple : option B gagnante . . . . . . . . . . . . . . . . . . . . . 81
4.18 Etapes du protocole de négociation . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.19 Diagramme de séquences du protocole de Négociation proposé . . . . . . . . . . . 89
4.20 La démarche décisionnelle adoptée par le système d’aide à la décision de groupe . 90
4.21 Comparaison taille message JSON – XML . . . . . . . . . . . . . . . . . . . . . . 91
4.22 Diagramme de classes : perspective = utilisateur . . . . . . . . . . . . . . . . . . . 92
4.23 Diagramme de classes : perspective = Session . . . . . . . . . . . . . . . . . . . . . 93
4.24 Diagramme de classes : perspective = message . . . . . . . . . . . . . . . . . . . . 93
4.25 Diagramme de classes : perspective = formulaire . . . . . . . . . . . . . . . . . . . 95
4.26 Diagramme de classes : Analyse multicritères . . . . . . . . . . . . . . . . . . . . . 97
LISTE DES FIGURES XI
5.1 Echange client web/ Serveur web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.2 Architecture de la plateforme JADE . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.3 Agent RMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.4 Agent Dummy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.5 Agent Sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.6 Authentification par compte administrateur . . . . . . . . . . . . . . . . . . . . . . 104
5.7 Espace administrateur – consultation des comptes utilisateurs . . . . . . . . . . . 105
5.8 Espace administrateur – création d’un utilisateur . . . . . . . . . . . . . . . . . . 105
5.9 Authentification avec un compte non administrateur . . . . . . . . . . . . . . . . . 106
5.10 Espace utilisateur – liste des sessions . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.11 Espace utilisateur – Création d’une session et inscription des participants avec at-
tribution des poids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.12 Espace utilisateur : création d’une session . . . . . . . . . . . . . . . . . . . . . . . 107
5.13 Espace initiateur : sommaire des réponses de formulaires . . . . . . . . . . . . . . 108
5.14 Espace décideur choix des critères . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.15 Zone d’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.16 Formulaire sur la compréhension du problème créé grâce au générateur . . . . . . 113
5.17 Formulaire - Résumé des réponses . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.18 Formulaire – critères à retenir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.19 Formulaire critères à retenir : résumé avec poids des décideurs . . . . . . . . . . . 114
5.20 Formulaire critères à retenir : résumé sans poids des décideurs . . . . . . . . . . . 114
5.21 Espace décideur – Matrice de performances . . . . . . . . . . . . . . . . . . . . . . 115
5.22 Espace décideur – introduction des paramètres subjectifs de tous les décideurs . . 115
5.23 Espace décideur Résultat de la méthode Prométhée II Classement des terrains . . 116
5.24 Paramétrage du protocole de négociation . . . . . . . . . . . . . . . . . . . . . . . 116
5.25 Échanges de messages entre l’initiateur et les décideurs pendant la négociation . . 118
5.26 Échange entre les agents durant la phase d’initialisation . . . . . . . . . . . . . . . 119
5.27 Échange entre les agents durant la phase de proposition . . . . . . . . . . . . . . . 120
5.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 136
B.2 Modèle d’agent cognitif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
B.3 Modèle d’agent réactif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Liste des tableaux
1.1 Les différents niveaux de la décision . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Matrice de performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3 Importance (poids) des critères . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4 Différents calculs effectués par la méthode . . . . . . . . . . . . . . . . . . . . . . 22
1.5 SADG : Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1 Les différents niveaux de décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.2 Protocoles de négociations :Travaux connexes . . . . . . . . . . . . . . . . . . . . . 41
3.1 Exemple de service web : Gmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.2 Exemple de service web : Github . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3 Exemple de service web : Weather Underground . . . . . . . . . . . . . . . . . . . . 57
3.4 Exemple de service web : Instagram . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1 Analogie entre les niveaux du système proposé et ceux proposés par Desanctis et
Gallup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2 Les phases des processus de décision, d’après Schwenk . . . . . . . . . . . . . . . . 63
4.3 Services web d’authentification et gestion des utilisateurs . . . . . . . . . . . . . . 92
4.4 Services web de gestion des sessions . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.5 Services web de gestion des documents . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.6 Services web de gestion des formulaires . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.7 Services web de l’analyse multicritères . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.1 Identification des critères . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

5.2 Les différents niveaux de la décision . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.3 Paramètres subjectifs exprimés par le décideur 1 . . . . . . . . . . . . . . . . . . . 111
5.7 Résultat utilisant le rang [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.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écision
ADG Aide à la Décision de Groupe
AHP Analytic Hierarchy Process
API Application Programming Interface
AT Aménagement du Territoire
AMCD Analyse MultiCritères à la Décision
B2B Business to Business
BDD Base De Données
BDI Belief Desire Intention
BEEP Blocks Extensible Exchange Protocol
BTP Business Transaction Protocol
CORBA Common Object Request Broker Architecture
DCOM Distributed Component Object Model
DIAG Aide au Diagnostic de Groupe
DS Decision Support System
DSS-NPS Système d’Aide à la Décision pour la Sélection de Protocole de Négociation
ELECTRE ELimination Et Choix Traduisant la REalité
FTP File Transfer Protocol
IBM International Business Machines
ICE Internet Communications Engine
ID Informatique Décisionnelle
iOS iPhone Operating System
GDSS Group Support Decision System
GWT Google Web Toolkit
HP Hewlett-Packard Company
HTTP HyperText Transfer Protocol
HTTPS L’HyperText Transfer Protocol Secure
HTML HyperText Markup Language
JAX-RS Java API for RESTful Web Services
JSON JavaScript Object Notation
LIO Laboratoire d’Informatique d’Oran
MALE Multi-Agent Learning Environment
MAUT Multi Attribut Utility Theory
MIME Multipurpose Internet Mail Extensions
OASIS Organization for the Advancement of Structured Information Standards
OSI Open Systems Interconnection
PHP Hypertext Preprocessor
PLM programmation linéaire multicritères
POP Post Office Protocol
PROMETHEE Preference Ranking Organisation Method for Enrichment Evaluations
Liste des abréviations XIV
QCM Questionnaire à Choix Multiples

QCS Questionnaire à Choix Simples
REST Representational State Transfer
RMI Remote Method Invocation
RPC Remote Procedure Call
RSS Rich Site Summary
SAD Système d’Aide à la Décision
SAML Security Assertion Markup Language
SANP Speech Act Based Negotiation Protocol
SGBDR Système de Gestion de Base de Données Relationnelle
SIAD Systèmes d’Information et Aide à la Décision
SIG Systèmes d’Information Géographique
SMA Système Multi Agents
SMTP Simple Mail Transfer Protocol
SOA Architecture Orientée Services
SOAP Simple Object Access Protocol
SSL Secure Sockets Layer
TCP Transmission Control Protocol
TLS Transport Layer Security
TOPSIS Technique for Order of Oreference by Similarity to Ideal Solution
UDDI Universal Description Discovery and Integration
UML Unified Modeling Language
URI Uniform Resource Identifier
URL Uniform Resource Locator
UTA UTilités Additives
UUCP Unix-to-Unix Copy
UV Ultra Violet
W3C World Wide Web Consortium
WS Web Service
WSDL Web Services Description Language
WS-I Web Services-Interoperability
XACML eXtensible Access Control Markup Language
XHTML Extensible HyperText Markup Language
XSLT eXtensible Stylesheet Language Transformations
XML eXtensible Markup Language
Introduction Générale
Contexte de l’étude
Dans 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 à un
niveau stratégique, tactique ou opérationnel. Néanmoins, quelle que soit leur complexité, elles sont
toujours engendrées selon le même processus décisionnel de base : tout d’abord, il faut identifier le
problème, ensuite le résoudre en collectant l’information, puis l’analyser et aboutir à la création de
solutions potentielles, et pour finir, il faut opérer un choix sur ces dernières (renoncer aux autres
possibilités).
Pour prendre une décision importante, le (ou les) décideur doit recourir à une aide qui peut
intervenir à 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 éventuellement
subjective et généralement non experte du décideur. Par ailleurs, dans le cadre d’une décision de
groupe, il y a le risque que les décideurs ne se mettent pas d’accord rapidement (ou même pas du
tout) 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 pour
formaliser 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’un
domaine donné.
L’aide à la décision ne résout pas le problème décisionnel seulement, mais, procure une aide au
décideur afin qu’il clarifie ses idées et exprime au mieux ses préférences. Elle peut être un ensemble
d’opérations qui facilitent la tâche de prise de décision en simplifiant ou en raccourcissant le chemin
cognitif 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écisionnel
sont nombreux. Ce domaine est né lorsque les organisations ont réalisé que la décision à un seul
dé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 un
environnement 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 et
l’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 de
dé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 vue
opérationnel, l’aide à la décision a connu ces derniers temps une révolution : l’orientation desktop
a é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 évoluer
en complexité au fur et à mesure. Les services web sont des outils permettant la communication
et 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’information
entre clients, fournisseurs, partenaires commerciaux et leurs différentes plates-formes, les services
web sont des programmes informatiques permettant la communication et l’échange de données
entre 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 services
web facilitent l’intégration d’applications tierces permettant d’offrir de nombreuses applications
accessibles à distance.
Problématique
Les 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 dans
certains 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édits
de consultation et d’expression ainsi que des outils de travail collaboratifs permettant de nouveaux
types 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 aspects
multicritères et multi-décideurs.
L’aspect multicritères apparait naturellement dans les problèmes décisionnels, car, prendre une
décision implique forcément de faire un choix entre plusieurs alternatives en se basant sur un certain
nombre 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 individu
isolé mais plutôt d’un groupe d’individus pouvant avoir des points de vue différents, voir même
conflictuels. 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 des
points de vue comme la négociation ou le vote. Les systèmes d’aide à la décision de groupe ou
GDSS (Group Support Decision System) sont une extension des systèmes d’aide à la décision, qui
prennent 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é de
données et d’information, ainsi qu’en fournissant des outils d’agrégation des différents points de
vue 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 unique
n’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 aux
différents critères.
De par leur efficacité, les méthodes d’aide multicritères à la décision ont largement intégré les
systè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’aide
multicritè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. Elle
consistera en des outils soit de support de tâche collective et de communication, soit de résolution
de 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ème
traité ou être une conséquence d’un choix structurel. Dans les deux cas, le processus décisionnel
multi-décideurs doit aboutir à une décision qui fait consensus au sein du groupe. Ainsi, un système
d’aide à la décision de groupe GDSS doit fournir des mécanismes qui facilitent la confrontation des
points 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 endroit
pour pouvoir travailler. Les GDSS doivent s’inscrire dans cette logique et permettre à des décideurs
gé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écideurs
ayant 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 ?
Contributions
Afin 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, notre
travail 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 de
faire 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 plus
spécifiquement la technologie des services web. 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.
Les services web de type REST reposent naturellement sur les standards du web et présentent
l’avantage de la simplicité, par conséquent, ce type de services web a été retenu pour la mise en
place 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ème
d’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, nous
en 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 la
médiation et l’agrégation multicritères (PROMETHEE II), permettant de dégager un compromis
entre les décideurs.
Plan du document
Pour 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 nous
avons 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 aux
systèmes d’aide à la décision de groupe. Nous concluons le chapitre par les travaux existants
dans 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, les
diffé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 web

A 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 architecture
détaillée ainsi que le fonctionnement des services web. Les principaux types de services sont
décrits dans ce chapitre. Les travaux les plus significatifs utilisant les services web sont passés
en revue.
Deuxième partie : Contributions
– Chapitre 4 : La modélisation de l’approche proposée

Ce 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 correspondant
s’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ée
par son architecture globale et son fonctionnement en décrivant chacun des modules la
composant 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 à mieux
exprimer leurs préférences.
– Chapitre 5 : l’expérimentation et résultats obtenus

Nous 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 Introduction
La 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 au
travers de biais systématiques [67].
Toutefois, dans la vraie pratique ceci n’est applicable que pour les problèmes familiers, nous
nous retrouvons rapidement dans la difficulté de prendre une décision une fois confrontés à de
nouvelles 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 qui
serve de fondations aux applications décisionnelles : un nouveau secteur informatique est en plein
expansion c’est « l’aide à la décision ».
1.2 L’Aide à la Décision

ROY [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, les
objectifs, 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 le
problème décisionnel, mais, procure une aide au décideur afin qu’il clarifie ses idées et exprime au
mieux 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". Cette
approche monocritère suppose que le système soit suffisamment simple pour qu’il soit possible
d’é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érentes
notions se rapportant à l’aide de la décision que nous décrivons dans ce qui suit [12] :
1.2.1 La décision
La 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 choix
entre plusieurs alternatives » [105] ;
Mintzberg [79], définit la décision, qu’elle soit individuelle ou collective, comme « L’engagement
dans 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 changement
de l’environnement (comportement réactif) ou au désir de saisir une opportunité et ainsi changer
l’environnement (comportement d’anticipation).
Dans le même sens, [43] a défini la décision par : « Décider, c’est prendre des risques certes
mais 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 buts
et 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ême
indissociable du contexte global du processus de prise de décision [118].
1.2.2 Les niveaux de la décision

La 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). Les
dé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 niveau
de décision.
2. Le niveau tactique : engage l’organisation à moyen terme (de 2 à 5 ans). Les décisions sont
prises par les encadrements supérieurs. Ces décisions sont peu fréquentes, peu prévisibles, la
simulation 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 niveau
concerne 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érationnelle

Domaine de la déci- Relations avec Gestion des res- Utilisation des ressource dans
sion l’environnement sources le processus de transforma-
tion
Horizon de temps Long terme Moyen terme Court terme
Effet de la décision Durable Bref Très bref
Réversibilité de la Nulle Faible Forte
décision
Procédure de déci- Non program- Semi program- Programmable
sion mable mable
Niveau de la prise Direction géné- Directions fonc- Chefs de services, chefs d’ate-
de décision rale tionnelles lier
Nature des informa- Incertaines et Presque com- Complètes et endogènes
tions exogènes plètes et endo-
gènes
Table 1.1 – Les différents niveaux de la décision
1.2.3 La typologie de la décision

Selon [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 souvent
qualitatives et pas fiables, donc difficilement formalisable et le processus décisionnel ne peut
pas être modélisé tel qu’il est, il faut le décomposer en sous modéliser au moins une partie
du 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écision

En 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’AD
vise à résoudre en l’assistant pour mieux exprimer ses préférences vis-à-vis d’une situation
donnée.
2. L’homme d’étude (l’informaticien, l’analyste) : c’est celui qui prend en charge l’AD, il
doit à 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, conditionne
directement 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 dans
le processus par l’image que d’autres acteurs se font de ses valeurs et plus concrètement de
son 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 dans
une négociation et de rechercher une action compromis.
7. Le Médiateur : intervient en vue d’aider les décideurs (ou les négociateurs) à rechercher
une action compromis.
8. L’Arbitre (juge) : intervient en se substituant aux acteurs dans la recherche d’une action
compromis.
1.2.5 Le processus décisionnel

L’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 à la
ré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 processus
de Simon (le plus célèbre des processus décisionnels disponibles dans la littérature) et qui opère
en 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 informations

né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, donc
tout 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 à restreindre
l’ensemble des possibilités au sous-ensemble des possibilités sélectionnées, répondant le mieux
aux exigences d’une décision correcte.
– Evaluation : en regard des trois phases précédentes, de la solution provisoirement retenue

comme satisfaisante, cette phase peut amener à la réactivation de l’une des trois phases
pré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écideurs
et aux organisations de mieux gérer la masse et la complexité de l’information, de la structurer
et de l’utiliser pour produire des nouvelles connaissances, ainsi les organisations peuvent mieux
coordonner l’activité des décideurs.
1.3.1 La taxinomie des SAD

Mê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 dans
ses tâches de prise de décision, en se concentrant simplement sur la phase choix du processus
décisionnel. Donc ces types de SAD ne pouvaient aider à résoudre que des problématiques
dé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 SAD
comme 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écisionnelles
mal structurées.
– Dernièrement, l’aspect social, c’est-à-dire l’échange de l’information dans une organisation

ainsi 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 groupe

La 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ésultat
et en réalité elles avaient besoin de véritables décisions issues de compromis entre les intérêts et
points de vue de plusieurs decideurs concernés par cette décision.
1.4.1 Définitions
L’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és
de 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 et
visuelles, planifiées ou opportunistes, où des personnes acceptent de se rassembler pour un objectif
commun, 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 notamment
de l’ingénierie, des sciences de l’information et des sciences de gestion [64], [96]. Elle comporte sept
dimensions :
1. Le groupe de personnes définit l’aspect collectif. La décision n’est pas le fait d’un seul
individu, 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 choix
entre 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 aux
définitions de la collaboration et de la coordination. Il s’agit du partage de l’objectif final
entre 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 englobe

en partie les échanges opportunistes, imprévus et informels.
6. La dimension temporelle bornée (« une période de temps définie ») est primordiale car
elle induit un début et une fin à l’activité. Il peut s’agir d’une activité informelle de quelques
minutes 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 ou
plusieurs sites [17].
1.4.2 Le processus de prise de décision

Le 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 : le
groupe 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 étapes
suivantes [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 groupe

Parmi 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 de
groupe concerne surtout l’organisateur de la prise de décision (appelé aussi facilitateur, médiateur
ou bien initiateur) et les experts dans la prise de décision (les participants) [27] :
1. Le facilitateur
Le facilitateur est une composante clé dans le processus de prise de décision de groupe, c’est
un 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 fonctionnement
de 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 participants
Les 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 coordination
des 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 quelle
technologie d’aide. Dans le contexte du système d’aide à la décision de groupe, la structure
de groupe, la taille du groupe, les rôles, les buts, les conflits individuels et les motivations
sont des exemples de telles variable [3].
1.5 Les systèmes d’aide à la décision de groupe (SADG)

1.5.1 Définition
Les 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és
dans le processus décisionnel. [13]
Concrètement, ce sont des environnements informatiques interactifs qui favorisent un effort

concerté et coordonné d’une équipe de décideurs vers l’achèvement de tâches collectives de prise de
décision. Ils font évoluer la prise de décision collectivement en facilitant l’échange et l’utilisation
d’informations par les membres du groupe d’un côté, et l’interaction entre le groupe et le système
d’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 combinaison
d’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 les

réunions de groupe. »
1.5.2 La structure d’un SADG

Un 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 stations
spécialisées, affichage de groupe, surface de travail configurée, éclairage modifiable, etc.) aux
salles de réunion ordinaires (à condition que chaque participant ait son PC portable) en
passant par les salles de vidéo-conférence.
2. Des outils : incluant certains supports pour les différentes phases du processus décisionnel
tels que la génération d’idées, l’évaluation et le classement des solutions alternatives, le vote
et 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 dernier

dans l’élaboration de l’ordre du jour de la réunion et dans l’utilisation des outils appropriés
pour les activités collectives.
1.5.3 L’architecture générale d’un processus de décision de groupe

Le 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 qui
s’engagent ainsi à accepter le résultat qui en découle, d’évaluer des solutions préconisées en regard
des points de vue retenus, de mettre en application les règles sur lesquelles les participants se sont
mis d’accord et de s’enquérir de l’adéquation des recommandations. Les observations empiriques
et leur confrontation avec des études existantes permettent de soutenir que les processus de prise
de 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éunions
en :
– Fixant avec concertation de tous les participant la date et l’heure de la réunion pour
s’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 (avec
réservation automatique de la salle de réunion ou des salles de téléconférence également
si le besoin y est).
– Informant les participants de l’objet de la réunion (la problématique) afin qu’ils puissent
faire 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 maintenant
de faire travailler de manière asynchrone, sans les réunir et sans qu’elles aient besoin
de 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) permet

de 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ées
et essaye de les amener vers un consensus qui satisfait toutes les partis, elle est réalisée au
travers :
– 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 solutions
préconisées dans la phase précédente en regard des points de vue retenus puis de valider la
dé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 la

décision qui a été prise et d’évaluer son impact sur la problématique [13].
1.5.4 Les intérêts des GDSS

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 [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 techniques
pour structurer l’analyse de décision et gérer systématiquement le modèle, le temps, le choix ou le
contenu de la discussion [34].
Les GDSS sont de plus en plus populaire en raison de leur capacité à améliorer l’interaction entre
les membres d’un groupe et d’augmenter sa productivité. Ils offrent une alternative intéressante
aux environnements traditionnels de réunion « face-à-face ». Les managers les trouvent plus utiles
car 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 effet
d’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 non
conventionnelles ou moins communes [93].
2. La communication parallèle : un GDSS permet à chacun de «parler» et «penser» en

parallèle. En effet, dans une réunion traditionnelle, les participants doivent suivre le locuteur
et ne peuvent pas prendre le temps de réfléchir. De plus, chaque personne n’a que quelques
minutes pour exprimer ses idées. Un GDSS permet à tous les participants de s’exprimer en
parallèle et pendant toute la durée de la réunion. De cela découle une participation accrue
et une synergie de groupe [57].
3. L’automatisation de la tenue des dossiers : un GDSS peut automatiquement enregistrer

les commentaires, votes et autres informations partagées par un groupe. Cela permet aux
participants de ne plus avoir à se souvenir mentalement de ce qui a été dit ou de prendre des
notes.
En utilisant un GDSS, les membres du groupe peuvent discuter un problème, échanger des
idées, évaluer les solutions alternatives, voter et choisir une solution, imprimer des rapports et
accomplir tout autre travail collaboratif. Les GDSS sont censés améliorer la performance du groupe
en améliorant le processus de prise de décision. A ce titre, les GDSS offrent au groupe plusieurs
avantages :
– Les GDSS peuvent améliorer la participation et la compréhension et atténuer les conflits

interpersonnels contre productifs [81] ;
– La fragmentation du temps peut également être réduite par les GDSS puisque les participants
peuvent faire des contributions simultanément [33]. Les personnes travaillent sur le système
en parallèle. Nous parlons de parallélisme de la communication [39]. Ainsi, il est possible de
générer des solutions innovatrices et créatives, d’obtenir plusieurs idées en circulation et de
les 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 aucune
dominance 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 plus
grand 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 relations
entre les participants dans le contexte de la prise de décision collective [6], [28] et, selon [119], une
décision de plus grande qualité [17].
1.5.5 La typologie des GDSS

DeSanctis 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 du
premier, sont en plus dotés de procédures permettant de modéliser et d’agréger les préférences
individuelles afin d’établir un consensus. Remarquons que les GDSS de ces niveaux font
souvent 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 des
systèmes experts ou d’experts humains, comme par exemple, les règles à suivre au cours du
processus de décision et les méthodes d’aide à la décision à mettre en œuvre, en fonction du
contexte.
1.6 L’aide à la décision multicritères

La 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 militaire
depuis les années 1960 pour deux raisons essentielles : L’amélioration de la gestion et la fourniture
des 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 en
considérant un ensemble de contraintes prédéfinies. Par la suite, ces méthodes ont investi d’autres
problé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ères

D’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 de
décision où plusieurs critères souvent contradictoires, doivent être pris en compte, elle permet de
modéliser de la manière la plus fidèle possible les préférences d’un expert, une telle modélisation
permet ensuite la construction d’outils adaptés et capables d’assister ou de remplacer un décideur
sur des problèmes complexes ».
1.6.2 Vocables associés à l’analyse multicritères

Dans 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 de
cette discipline parlent plutôt des actions potentielles qui sont les éléments qui vont faire l’objet de
la comparaison. Dans les différentes formes, en fonction de la procédure retenue : Action potentielle
est une action provisoirement jugée possible par un des intervenants au moins ou présumée telle
par 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 terme
gj (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 Roy
et Bouyssou [102] est très simple : quand les conséquences de deux actions sont identiques
pour l’ensemble des critères en présence, il doit exister une relation d’indifférence entre ces
deux actions [102].
2. Cohérence : il doit y avoir une cohérence entre les préférences locales de chaque critère
et les préférences globales. C’est-à-dire que si une action a est égale à une action b pour
tous les critères sauf un où elle lui est supérieure, ceci signifie que l’action a est globalement
supé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 conditions
pré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éments
suivants :
– 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. Ils
peuvent être classifiés en deux catégories [55] paramètres inter critères et paramètres intra critères.
– Paramètres inter critères

Ce sont des paramètres utilisés pour évaluer l’importance relative de chaque critère, on parle
souvent 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 Autonomie

Performance 1 5 2
Design 1/5 1 1/3
Autonomie 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 de
l’importance relative de chaque critère.
Remarque : La performance du produit est beaucoup plus importante que le design. La
matrice 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 Poids

Performance 0.58 0.56 0.6 0.58
Design 0.11 0.11 0.11 0.11
Autonomie 0.29 0.33 0.3 0.31
Somme 1.7 9 3.33
Table 1.4 – Différents calculs effectués par la méthode
– Paramètres intra critères

Ils formalisent pour, chaque critère, l’appréciation subjective de leurs valeurs. Ils comprennent
le 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 de
l’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érence
et 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 seuil
est dépassé sur un critère, alors l’action ne peut être prise en considération. Il définit
donc une situation intolérable pour un des décideurs. Il s’exprime par l’écart maximum
acceptable autour de la valeur de l’évaluation [55].
1.6.3 Démarche générale d’une méthode Multicritères

La 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 liste
des actions potentielles qui vont rentrer en concurrence. Cette liste n’est pas exhaustive et
dé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 est
exprimé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 et
chaque 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 des
critères. Pour définir une solution (action) qui fait émerger une préférence commune (jouit
globalement 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ères

Les 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 une
seule fonction mathématique monotone (à sens d’évaluation unique). A partir des évaluations des
différents critères, la fonction d’optimisation résultante dite d’utilité ou d’agrégation, produit donc
une valeur unique évaluant globalement la solution [mena, 00] La somme ou moyenne pondérée
de notes est l’exemple le plus connu de ces techniques. Elle présente comme défauts, graves ou
non selon la situation, une compensation possible entre critères (notes) et une forte sensibilité aux
changements 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 approche
conviennent bien aux problèmes dont les critères sont indépendants, autrement dit, lorsque tous
les critères interagissent sur la décision finale. Comme exemple de cette approche on peut citer
plusieurs 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 de
cette 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 familles
ELECTRE (Elimination Et Choix Traduisant la Réalité) et Prométhée. Les inconvénients de cette
approche se résument dans la forme des résultats (Les réponses sont généralement complexes) et le
nombre 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 est
fini et de dimension raisonnable, cette approche s’applique à des ensembles d’actions d’une très
grande dimension voire infinis lorsque les actions varient en continu. Partant d’une solution de
départ, la technique permet de chercher au voisinage de cette solution s’il n’y en a pas de meilleure
et 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 étapes
d’interaction avec les décideurs [78], [89]. Les principales méthodes d’agrégation locale itérative
existantes sont : Plm (programmation linéaire multicritères), Stem (Pop), etc. [107], [76].
1.7 Travaux connexes

Dans 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 grandes
catégories :
1. L’aide à la décision mono décideur : un décideur se forge une opinion en fonction

des informations mises à sa disposition (dont celles issues de l’expertise), ainsi que de ses
orientations (valeurs) personnelles.
2. L’aide à la décision multi décideurs : est le fait d’être plusieurs à décider ayant chacun un
point 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ésenter
quelques situations décisionnelles proposées par les auteurs dans des travaux de recherche dans le
cadre de l’aide à la décision de groupe dans différents domaines.
Auteurs et références Travail de recherche Domaine

d’application
M.HEMAISSIA, Modélisation des acteurs affectés par la décision Gestion de
A.ELFALLAH, de groupe via la technologie agent. Modélisation crises
SEGHROUCHNI, des préférences des acteurs grâce à l’intégrale de
C.LABREUCHE et Choquet.
J.MATTIOLI [58] Définition d’un protocole de négociation multila-
térale et multidimensionnel basé sur la médiation
permettant de trouver un consensus acceptable
pour un groupe d’agents.
S.OUFELLA et Modélisation des acteurs impactés par la décision Aménagement
D.HAMDADOU [89] de groupe via le paradigme agent. du territoire
Identification des préférences des différents ac-
teurs à l’aide de la méthode multicritère
ELECTRE 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.
D.HAMDADOU et Proposition d’un système d’aide à la décision Diagnostique in-
T.LIBOUREL [53] de groupe multicritères pour l’aide au diagnos- dustriel
tic (DIAG-GDSS), un outil collectif de prise de
décision basé sur un ensemble de critères et de
mé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 les
différentes méthodes de diagnostic.
OKUMURA, MIKOTO, Proposition d’un système d’aide à la décision Aménagement

FUJITA KATSUHIDE, pour traiter une problématique bien spécifique du territoire
ITO TAKAYUKI [88] qui est la conception et le choix d’un parc tout en
conservant et protégeant la planète du réchauf-
fement climatique. Basé sur les systèmes multi
agents, ce système utilise les agents pour obtenir
de l’information des utilisateurs, le protocole va
aider à choisir l’espace à attribuer, ce dernier est
multi attributs mais ne propose pas aux utilisa-
teurs de se rétracter et de changer leurs préfé-
rences.
I.IGOULALENE Utilisation d’une approche hybride basée sur la Problème de
L.BENYOUCEF et méthode Topsis et la mesure de possibilité. L’ex- sélection les
M.TIWARI [62] ploitation de la méthode multicritères TOPSIS chaines logis-
(Technique for order of preference by similarity tiques
to ideal solution) floue pour l’établissement d’un
classement des alternatives.
La recherche de consensus se fait via la théorie des
possibilités et des ensembles flous qui permet aux
decideurs ayant des préférences contradictoires de
trouver un consensus sur l’ensemble des alterna-
tives.
F. LANG et A. FINK [70] Proposition d’un système d’aide à la décision Apprentissage
pour la sélection de protocole de négociation automatique
(DSS-NPS) qui est basé sur une approche d’ap-
prentissage automatique ; un réseau neurologique
artificiel pour faire des prévisions sur la repré-
sentation d’un protocole de négociation pour un
scénario donné, qui est censé apprendre des mo-
dèles et des connexions entre la représentation
d’un protocole et les caractéristiques du protocole
et du scénario de négociation.
M.MORGE et Proposition d’un outil appelé MARGO, qui re- E business

P.MANCARELLA [82] 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 de
décision, son travail est basé sur l’approche abs-
traite de Dung à l’argumentation annulable [36].
Cet outil s’adresse aux applications industrielles
en effet MARGO a été employé dans l’ArguGRID
projet pour faciliter la composition dynamique de
ressources et de services au sein d’une grille de
calcul.Les agents sont associés aux fournisseurs
et aux demandeurs de services. ils englobent la
machinerie logique pour la prise de décision et
sont équipés de fonctionnalités pour la négocia-
tion. Les agents décident du service qui permet de
répondre aux besoins du client,ils créent, gèrent
et rejoignent des organisations virtuelles.
D.HAMDADOU et les auteurs font la conception et l’élaboration d’un Aménagement
K.BOUAMRANE [54] système interactif d’aide multicritères à la déci- du territoire
sion collective pour la localisation ponctuelle spa-
tiale en Aménagement du Territoire (AT) sur un
couplage de deux représentations de la réalité :
les Systèmes Multi Agents (SMA) et les Systèmes
d’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 Conclusion
Tout 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 de
groupe (GDSS) bien élaborés, les décideurs arrivent à un compromis de bonne qualité assurant un
accord 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 decideurs
causé par les intérêts, préférences et points de vue généralement différents voir même opposés
de chacun d’entre eux. Ce genre de conflit est géré dans les systèmes multi agents modélisant
parfaitement les GDSS.
Dans le chapitre suivant, nous aborderons en détails la négociation dans les systèmes multi agents
celle-ci est une gestion des conflits suscités lorsqu’interviennent plusieurs acteurs pour la prise
d’une décision. Cette dernière devient plus compliquée lorsqu’il y a plusieurs critères à prendre
en considération. Nous présenterons la notion d’agent, tous les aspects de la négociation et les
différentes approches de cette dernière.
Chapitre 2
La négociation dans les Systèmes

Multi Agents
2.1 Introduction
La 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 humains
ou logiciels, un groupe d’agents forme un système multi agents. Les systèmes multi agents sont
devenus, depuis quelques années, la base de nombreux travaux et sont étudiés dans de multiples
domaines comme l’intelligence artificielle distribuée ou même dans la robotique le point d’étude
principal entre les agents, la communication et la coopération. Dans certains systèmes, les agents
sont utilisés pour coopérer entre eux et ce pour un but commun mais ce cas n’est pas tout le
temps réalisable car il arrive que les agents sont en conflit ce qui fait appel nécessairement à la
négociation.
2.2 Les agents et les systèmes multi agents

Les 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 multitude
de définitions de ces derniers dans la littérature, cependant celle de Jacques Ferber [40] à propos
des agents et de Wooldridge [126] à propos des systèmes multi agents ont retenu notre attention
car 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 ». Cette
entité est mue par un ensemble de tendances (sous forme d’objectifs individuels ou d’une fonction
de 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 à satisfaire
ces objectifs, en tenant compte des ressources et des compétences dont elle dispose, et en fonction
de 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 agents

Cette 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’on
appelle les agents hybrides. A ces types, s’ajoutent les agents BDI (Belief, Desire, Intention) qui
viennent 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 dont
la représentation de l’environnement n’est que sub-symbolique. Cela signifie que la représentation
provient 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 est
dans 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é en
compte, ni prévoir au-delà du court terme. Le principe d’un agent réactif permet la construction
de systèmes composés de nombreux petits agents, qui sont des automates. Les interactions des
agents entre eux permettent l’émergence de structures d’une couche d’abstraction supérieure qui
sont potentiellement observables [71]. Leur conception n’est pas si facile du fait de la difficulté de
pré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 agents
disposant 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 les
symboles, et donc les représentations symboliques, mais ils sont très complexes et limitent les
capacité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 les
comportements 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 par
le compromis efficacité/complexité. La complexité des systèmes réactifs exige le développement de
nouvelles théories dans le domaine de la coopération, de la communication et de la compréhension
de nouveaux phénomènes telle que l’émergence [66]. L’architecture hybride est, en quelque sorte, un
compromis entre un agent purement réactif et un agent purement cognitif. Cette vision permet de
concilier 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 vision
qui se situe au niveau des connaissances de l’environnement.
– Une couche supérieure se charge des aspects sociaux de l’environnement, c’est-à-dire du

raisonnement 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, ou
attitudes mentales, qui sont la croyance, le désir et 1’intention. Ces trois concepts déterminent la
rationalité 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 base
1’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 permet
de 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 simplement
l’ensemble des connaissances que l’agent a sur son environnement. Le terme connaissance
est abusif car ce sont des informations sur l’environnement qui sont issues des percepts de
l’agent, et donc dépendent des capteurs. Ces informations peuvent donc ne pas être vraies ou
correctes, mais le cycle cognitif de l’agent lui permet de mettre à jour ces informations pour
que ses croyances sur son environnement soient les plus correctes et complètes possibles, par
1’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 donc
la raison d’être de l’agent basé sur une architecture BDI. Il est intéressant de noter que les
désirs peuvent être contradictoires (comme vouloir manger et vouloir dormir), auquel cas le
raisonnement 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 cycle
cognitif 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ême
moment même s’ils sont consistants, et les intentions permettent d’ordonner la satisfaction
de 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éonomique
du fait de l’intégration de la notion d’intentions. Les agents ainsi conçus étant du type cognitif car
basé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 agents

Wooldridge [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 être
directes par l’intermédiaires des communications, comme elles peuvent être indirectes à travers
l’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 les
buts, 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 ne
sont 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 buts
sont 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 il
ne possède pas des capacités).
– que le travail avec les autres est plus efficace.
2.3 La coopération
En 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ème
de 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’est
l’ensemble des techniques permettant à des agents de se répartir des tâches, des informations
et des ressources, de manière à réaliser une œuvre commune. Résoudre un problème de
collaboration consiste donc à répondre à la question « qui fait quoi ? » par rapport à un
travail 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 les
mê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égociation
et 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 la
négociation.
2.4 La résolution de conflits n’incluant pas la négociation

Les 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 que
brièvement ces méthodes.
2.4.1 Take it or leave it offer

En 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’on
rencontre tous les jours pour acheter son pain, par exemple. Elle ressemble aux offres scellées au
meilleur et au second meilleur prix, la différence vient du fait que dans les enchères, le prix est
proposé par les acheteurs, tandis que dans le take it or leave it offer, c’est le vendeur qui propose
un 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 prix
pour obtenir la ressource [120].
2.4.2 One Step Protocol

En 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 agents
seulement, chacun émet sa proposition, et ainsi chacun d’eux dispose de deux propositions (celle
qu’il a envoyé et celle qu’il vient de recevoir de l’autre agent). Les agents doivent accepter la
proposition qui maximise le produit de leurs utilités, s’il y a une égalité, ils coordonnent pour
choisir une aléatoirement. La meilleure stratégie que peut utiliser un agent est de trouver les
actions qui maximisent le produit des utilités, et à partir de ces actions, choisir celui qui maximise
sa propre utilité [12].
2.4.3 Les enchères sans négociation

Il 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ères
premier prix offres cachées. Chaque participant soumet une offre sans connaitre les offres des
autres. 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ères
sont aussi parfois appelées enchères deuxième prix offres cachées. Chaque participant soumet
une offre sans connaitre les offres des autres. Celui qui fait la plus grande, gagne l’objet et
paie le montant de la seconde meilleure offre proposée [121].
2.4.4 Les systèmes de vote

Le 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 candidat
préféré. Plusieurs méthodes ont été proposées pour déterminer le candidat préféré, certaines sont
simples mais ne reflètent pas les préférences réelles des votants. Quelques exemples de ces méthodes
sont décrits dans ce qui suit [122] :
– La méthode Condorcet : La méthode Condorcet (ou vote Condorcet) est un système de

vote 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 candidats
par ordre de préférence. Pour chaque paire de candidats, on détermine le nombre d’électeurs
ayant voté pour l’un ou l’autre. Ainsi pour chaque pair, il y a un candidat vainqueur. Dans la
plupart des cas, il y a un unique candidat qui remporte tous ses duels : il s’agit du vainqueur
du 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, le
principe général est de déterminer le choix social en éliminant successivement les alternatives
les 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 on
sélectionne l’alternative classée première sur le moins de listes et on l’enlève de toutes
les listes. Si plusieurs alternatives sont à égalité, on les enlève toutes des listes. Les
alternatives qui suivaient celles qui ont été enlevées sur les listes gagnent alors une
place.
– On recommence la procédure jusqu’à ce qu’une alternative apparaisse en premier sur au
moins la moitié des listes ou si toutes les alternatives restantes apparaissent en premier
sur 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 pas
forcément démocratique. Cette méthode consiste à désigner une personne parmi l’ensemble
P et de l’appeler dictateur. Le choix social est alors l’alternative classée première sur la liste
du 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 parmi
les listes de préférences des votants (majorité relative).C’est le système de vote classique par
excellence utilisé dans les élections politiques pour élire le président du Mexique, du Kenya
ou encore de l’Islande (en France, on utilise deux tours) [120].
2.4.5 La délibération
La 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ée
par un individu seul, mais aussi par un groupe d’individus ou une collectivité [130] Qui selon le
contexte :
– Est bien une discussion entre les parties concernées par l’objet discuté (par exemple lors d’un
conseil d’administration), mais qui consiste à effectuer un choix. La délibération est parfois
précédée ou entrecoupée de phases de négociation, mais nous considérons qu’elle n’est pas en
elle-même de la négociation,
– Aboutit à un verdict (d’un juge par exemple). Les parties concernées s’en remettent à une
autre 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 citer
le système PERSUADER , [114] qui met en jeu un médiateur.
2.5 La résolution de conflit incluant la négociation

Dans 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érarchisation
peut se faire grâce au type d’objet que l’on veut négocier (le nombre d’attributs, le niveau de
profondeur, etc.) ou bien grâce au niveau de sémantique des agents qui l’utilisent, mais avant cela
nous définirons tous ses aspects se rapportant à la négociation.
2.5.1 La négociation
Avant 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 parties
first verbalise contradictory demands and then move toward agreements » [94]. L’origine de cette
définition étant américaine, sa traduction est : « La négociation est un processus par lequel une
décision conjointe est prise par deux parties ou plus. Les parties verbalisent en premier lieu leurs
exigences et convergent vers un accord final ». La négociation réunit un ensemble de participants
et un initiateur et se déroule jusqu’à ce qu’un accord satisfaisant soit atteint ; un pourcentage de
participants.
La définition de Floch [46] nous parait être la plus complète et la plus générale du fait qu’elle
aborde toutes les facettes de la négociation :« La négociation est un processus de recherche d’accord
sur 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’aboutit
pas forcément à un accord. Le résultat est une prise de décision commune des parties sur les
modalité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, leurs
sé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égociation
fait appel à un langage de description de l’objet. Le protocole spécifie les séquences possibles
d’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 des
comportements. Le processus concerne la proposition de solutions, l’analyse et la révision des
solutions préférables.
3. Les décisions individuelles : qui peuvent être prises en fonction de critères d’utilité, de
straté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éfinies
dans 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 des
né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 poursuivent
un but commun et la négociation leur permet de se coordonner. Il s’agit d’une recherche
distribué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 individuels
et cherche à être le gagnant de l’échange. Chacun campe sur ses positions et la négociation est
vue 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 de

l’adversaire.
– L’entente : les interlocuteurs oublient leurs intérêts propres et se retrouvent en situation de

résolution de problèmes, c’est-à-dire ils vont rechercher une solution optimale (du point de
vue mathématique).
2.5.1.4 La notion de protocole
La modélisation des communications entre agents utilise la notion de protocole. Les auteurs
dans [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és
entre les agents. Les protocoles peuvent être formalisés à l’aide de différents outils comme, par
exemple, 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 selon
leurs types et en précisant la particularité de chacune d’entre elles de la plus simple vers la plus
complexe. La figure 2.2 regroupe toutes ces méthodes et les classe en deux grandes catégories : les
mé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’a
qu’un seul attribut et qu’un seul niveau). Elles sont souvent utilisées comme base pour d’autres
types 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 est
considéré comme le précurseur des travaux en négociation automatique. Il s’agit d’un protocole
fondé sur l’échangeur de contrats, qui met en relation un agent : le gestionnaire (manager), avec
plusieurs 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. Le

contractant 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 traitement
des 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 for
Intelligent 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 fait
l’objet de nombreuses extensions, qui ont apporté des améliorations comme la possibilité d’effectuer
des 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 → R0+ (2.2)
Où X est l’ensemble des ressources (actions ou choix possibles), qui à chaque ressource possible
affecte une valeur réelle, plus cette valeur est grande, plus la ressource en question est préférée par
l’agent i.
Dans le premier tour, tous les agents doivent faire des propositions, et chaque agent est libre de
faire 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 une
concession (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 (willingness
to 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és
des 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 le
sens 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é, on
trouve 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, on
trouve entre autres [37] :
– La concession de PARETO : proposer une ressource qui soit aussi bonne pour tous les
autres agents, et strictement mieux pour au moins un d’entre eux.
– La concession Utilitaire : proposer une ressource qui mène à une augmentation dans la
somme 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 tous
les 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 des
agents d’une itération à une autre.
Ces stratégies assurent la convergence du processus de concession vers un accord qui satisfait
tout le monde.
– Accord est atteint si et seulement si un agent i fait une proposition Xi qui soit au moins
aussi bonne pour tout autre agent j.
– Un conflit se produit lorsque tous les agents qui doivent concéder dans une itération donnée
refusent de le faire. Un agent refuse de faire une concession parce qu’il n’est pas en mesure
de 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, dans
ce dernier cas, la négociation se termine par ce qu’on appelle un accord de conflit. Ce dernier est
dé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 leur

nom l’indique, sont des négociations qui impliquent différents attributs devant être négociés. Elles
sont directement opposées aux enchères qui n’impliquent qu’un seul attribut : un prix. Cette forme
de 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 direction
assisté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 de
l’environnement. La perception du système est distribuée et les agents négocient pour adopter une
interpré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 tableau
et chaque agent peut les lire, les accepter, les refuser ou les modifier. Ici, les agents ont tous le
même objectif : trouver une bonne interprétation de la situation. Avec sa perception locale de
l’environnement, chaque agent va proposer des hypothèses. Les agents mettent en commun leurs
hypothèses, et n’ont pas d’intérêts conflictuels. La discussion aboutit forcément à un accord, qui
consiste 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éparti
entre un ensemble d’agents participants, et un agent coordinateur qui se charge d’orchestrer la
négociation dans son ensemble [89]. Chaque agent participant détient un vecteur trié, selon ses
préférences, des actions potentielles, en plus, chaque agent dispose d’un compteur, qui pointe sur
son 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 une
ressource 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é par
l’initiateur s’il correspond à son choix dans l’itération en cours, ou si ce contrat a été précédemment
fait par l’agent. Lorsque l’initiateur reçoit toutes les réponses des participants, il comptabilise le
nombre 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 du
contrat. En cas où la majorité refuse le contrat proposé, l’initiateur le modifie en s’inspirant des
propositions des participants. Il doit établir une synthèse à partir de ce qu’il a reçu lors de la phase
d’é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 se

dé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 effectue
un retour arrière pour la négociation du sous-contrat précédent. Par exemple, pour la prise de
rendez-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’une
personne a besoin d’un ensemble d’objets non disponibles auprès d’un unique vendeur. Il faut alors
négocier chaque objet (ou sous ensemble d’objets) séparément et avoir un mécanisme de liaison
entre 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égociations
sont indépendantes les unes des autres, alors que l’ensemble des objets négociés sont typiquement
interdépendants.
Les négociations peuvent être de type différent pour chaque objet ou sous-ensemble d’objets. Un
exemple 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 les
nuits 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 la
sé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 leurs
offres 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 offre
une grande flexibilité puisqu’il est possible pour les agents d’exprimer leurs réactions quant au rejet
ou à 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 en

particulier 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 un
agent et peut également amener un agent à dévoiler ses buts, abandonner certains buts et à réviser
ses préférences. Il existe plusieurs systèmes basés sur l’argumentation dont les plus importants sont
les 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 la
conversation 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 une
discussion est nécessaire.
2. Emission d’une proposition et réception de l’avis : l’attaquant émet sa proposition et

le 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 par

des arguments. Ce processus continue jusqu’à ce qu’ils identifient leurs différences et tentent
de les réduire.
5. Résolution du problème : chaque partie propose un compromis et tente de contrer celui

de 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 la
négociation en sociologie. Les auteurs se basent sur le Struggle Model et l’Institutional Model
dé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 connu
un 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’a
depuis jamais cessé d’évoluer. Le mathématicien John NASH a également été très actif. Les outils
de la théorie des jeux sont aujourd’hui utilisés en économie, et également dans des sciences comme
la 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, quelques
concepts 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é entre

l’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 choix
entre 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 lui
prendra 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 globalement
mieux que si l’un des deux dénonce l’autre. Mais l’un peut être tenté de s’en tirer encore mieux
en dénonçant son complice. Le dilemme est faut-il accepter de couvrir son complice (C comme
coopé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 ne
coopère jamais, son intérêt sera de ne pas coopérer non plus).
C D
C 1 an, 1 an 3 ans, 0 an
D 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’une
stratégie optimale pour un jeu à plusieurs joueurs, dite équilibre de Nash. L’équilibre de Nash
caractérise la rationalité individuelle. Il s’agit d’une combinaison stratégique où chaque joueur
joue 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 le
dilemme 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’optimum

de Pareto qui caractérise la rationalité collective. C’est une situation dans laquelle un individu ne
peut 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 connexes

Nous 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érences

J.BENTAHAR et Les auteurs ont développé un protocole de né- [14]
J.LABBAN gociation dans un système multi agents basé sur
l’argumentation persuasive. Les agents doivent se
persuader mutuellement de leurs offres jusqu’à ar-
river à un accord ou un échec.
D.HAMDADOU et Un protocole de négociation multilatéral inspiré [53]
T.LIBOUREL du Contract Net Protocol, exploitant la méthode
multicritères ELECTRE III. Ce protocole inclut
un coordinateur et un ensemble de participants,
qui tentent de trouver un compromis entre les un
ensemble de décideur, application : Aménagement
du Territoire.
N.HADIDI Un protocole de négociation dans les systèmes [51]
multi agents basé sur l’argumentation et sur la
théorie des jeux. Cette négociation n’est pas mul-
tilatérale mais bilatérale, on ne distingue que
l’agent attaquant et l’agent défenseur.
F.DELECROIX, Un jeu de négociation bilatérale dans les systèmes [32]
M.MORGE et multi agents inspiré de la concession monotone.
J-C.ROUTIER 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
D.HAMDADOU et Un protocole de négociation dans un système [54]
K.BOUAMRANE d’aide à la décision collective inspiré du Contract
Net 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 et
ELECTRE TRI.
S.OUFELLA Un protocole de négociation à base d’argumenta- [90]
tion dans un système multicritères à la décision
de groupe. Muni d’une base de connaissances où
chaque participant, le protocole est capable de gé-
nérer des arguments en faveur de ses alternatives
préférées. De plus le rejet ou l’acceptation d’une
offre sont justifiés.
Table 2.2 – Protocoles de négociations :Travaux connexes
2.7 Conclusion
Nous 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 leurs
comportements en trois grandes catégories et une quatrième hybride. Ensuite, nous avons défini
la 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 être
résolu par plusieurs méthodes, ces méthodes peuvent inclure en entre autres la négociation. A ce
titre, 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 et
un 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 et
plus précisément les services web. Nous présenterons l’intérêt de ces derniers, leur fonctionnement
ainsi que les deux principales architectures en mettant l’accent sur la méthode choisie pour élaborer
notre plateforme basée sur la négociation et l’analyse multicritères.
Chapitre 3
Les services web
3.1 Introduction
De 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’une
application fonctionnant à distance peut à première vue sembler inutile dans la mesure où les
applications fonctionnent fort bien en local (sur le poste de l’utilisateur), néanmoins une application
distante 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 dont
l’utilisateur local ne dispose pas ;
– L’application distante peut être utilisée simultanément par un grand nombre d’utilisateurs
et 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és
au développement des applications distribuées complexes à partir des entités logicielles appelées
services. L’utilisation de cette architecture permet la communication et l’intégration de plusieurs
applications développées dans des environnements hétérogènes [61]. A ce titre, nous présentons
dans 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 suite
la technologie des Services Web en détaillant toutes les notions pertinentes relatives aux services
web et les deux grandes solutions d’accès aux services web à savoir SOAP (Simple Object Access
Protocol) et REST (REpresentational State Transfer).
3.2 L’architecture orientée service SOA

SOA 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 est
de réaliser une fonctionnalité dont l’utilisateur a besoin. Cette architecture repose sur un concept
basique : la notion de service. Un service est une application définie par un contrat, accessible par
une interface et offrant une ou plusieurs fonctionnalités. Les services permettent de communiquer
via 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é plusieurs
avantages tels que :
– Le couplage faible : les acteurs partagent entre eux seulement la description de services
afin 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 plateformes

de 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 une
certaine fonctionnalité.
– Facilité des communications externes : le client peut communiquer avec des applicatifs
externes à l’entreprise [61].
3.3 Historique sur les services web

Avant 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), son
rival Microsoft. À un niveau plus bas, on trouve RPC (Remote Procedure Call) et, plus près du
monde Java, RMI (Remote Method Invocation) mais ils ont généralement échoué en raison de la
diversité des plateformes utilisées dans les organisations et aussi parce que leur usage n’était pas
adapté à Internet (problème de passage à travers des FireWalls). Lorsque HTTP est devenu un
standard, 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 Wide
Web Consortium) a annoncé que XML 1.0 pouvait être déployé dans les applications. En 1998, ces
deux ingrédients " HTTP et XML " étaient prêts à travailler ensemble et XML-RPC l’ancêtre des
Services Web est créé, c’est un vocabulaire XML décrivant des appels et des réponses de procédures
distantes (RPC). Sous l’influence de Microsoft, XML-RPC est remanié pour être adapté au monde
de la programmation orientée objets et le résultat prend le nom de SOAP (SOAP 1.0, novembre
99). 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 Information
Standards) afin de permettre aux entreprises de publier et de retrouver les services web. Avec
SOAP, WSDL et UDDI, les standards étaient désormais en place pour la création de services web
[153].
3.4 Les acteurs SOA

Les 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é de
promouvoir 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 permet

d’exposer (publication) la description de son service dans un registre de service afin de le
rendre accessible aux utilisateurs potentiels.
– Le registre de service : c’est un répertoire de service (appelé aussi annuaire ou courtier

de service). Il permet aux fournisseurs de stocker leurs descriptions et aux consommateurs
de rechercher et de choisir le service correspondant à son besoin. Ce registre joue un rôle
intermé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’il
existe un service qui répond à son besoin, il utilise la description de ce service pour établir
une connexion avec son fournisseur afin de l’utiliser (invocation).
3.5 Définition du service web

Dans 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, Dico
du 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, en
utilisant 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’agit
donc 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 une
technologie permettant à des applications de communiquer entre elles :
– en s’appuyant sur les standards du web (HTTP, XML). indépendamment de l’architecture

sur lesquelles elles sont implémentées.
– en échangeant des documents sous le format XML [153].
3.6 Motivation et intérêt

Un 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.), sur
diverses plateformes (Linux, Windows, etc.) et avec diverses architectures peuvent employer des
services Web pour échanger des données à travers des réseaux informatiques. Chaque service web
doit pouvoir être découvert et invoqué dynamiquement par les applications. Les aspects purement
pratiques n’ont rien de fondamentalement novateurs. Au contraire, l’architecture des services Web
s’est imposée (tout comme le langage XML) grâce à sa simplicité, à sa lisibilité et à ses fondations
normalisé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 responsables
de l’architecture et de standardisation des services Web. Pour améliorer l’interopérabilité entre les
ré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 important
des Services Web est qu’ils reposent sur plusieurs standards qui permettent la structuration des
architectures. 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 description
des services Web et UDDI pour la recherche des services Web nécessaire au bon fonctionnement
des 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 filtrent
et bloquent beaucoup de trafic d’Internet pour des raisons de sécurité. Dans ce milieu, beaucoup
de ports (voire quasiment tous) sont fermés au trafic entrant et sortant, et les administrateurs
des réseaux n’ont pas l’envie de les ouvrir. Il en est un qui par contre est toujours ouvert, celui
des navigateurs par lequel transite le protocole HTTP. De cette façon les applications peuvent
continuer à interagir entre elle et ce sans modifier la configuration de sécurité des organisations. Si
l’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 points
principaux. En ajoutant à cela l’interopérabilité des programmes indifféremment de leur langage
et de leur plateforme, les services Web nous prouvent une nouvelle fois que leur technologie est
très attrayante. Le véritable point fort du concept c’est la normalisation des données au travers de
standards connus et acceptés par tous.
Quel que soit leurs types, l’utilisation de services web peut avoir plusieurs intérêts dont nous
citons [137] :
– L’exposition de fonctionnalités au travers du réseau : les traitements des opérations des

services 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érentes
technologies 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 un
firewall (un dispositif de protection constituant un filtre entre un réseau local et un autre
réseau non sûr) pour permettre une invocation depuis l’extérieur. Ceci permet une invocation
depuis 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 partenaires
par exemple.
3.7 Organisation des services web

La 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 ainsi
dé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 échanges
qu’en termes de services transverses. Cette organisation par comités de normalisation peut être
sché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ée
et ne souffre d’aucune contestation. Elle s’appuie sur le protocole SOAP pour l’échange
des 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 selon
des critères métier. Les initiatives de définition de la couche de sémantiques des messages
sont 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érents
corps de métier, l’autre suivant une approche plus globale autour de consortium tel
qu’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’orchestration
de 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 sur
des 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’en
est 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 consiste
en une simple exposition, par agrégation, des services d’une application, elle est toutefois
plus adaptée à cette seconde problématique.
2. Service de sécurité : normalisation des moyens permettant de couvrir les problématiques
d’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 de
Services 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 à terme
comme standard de sécurité.
3. Service de transaction : normalisation des moyens permettant de garantir l’intégrité des
transactions longues impliquant plusieurs Services Web. Le problème reste le même que
pour la sécurité. Les standards ne sont pas tout à fait établis. La lutte pour l’obtention
d’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 services
web :
Figure 3.2 – Architecture en couche des services web
3.8 L’architecture d’un service web

Pour 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 Service
Web and XML chez IBM, les Services Web sont des "applications modulaires basées sur Internet
qui exécutent des tâches précises et qui respectent un format spécifique". Ce sont donc des unités
logiques applicatives qui sont accessibles grâce au protocole Internet. Une définition conceptuelle
du terme service Web mettrait en avant les qualités d’une fonctionnalité commerciale présentée
par 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 modulaires
qui 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 rendre
possible l’utilisation d’un composant applicatif de façon distribuée. L’apport majeur de ce modèle
d’é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 le
langage employé ne jouent pas au niveau de l’architecture. Grâce à cela, on obtient un haut niveau
de modularité et d’interopérabilité. Ce modèle de message permet donc d’oublier la structure, le
langage ou encore la plate-forme qui va porter le service : il suffit juste que le message suive une
architecture donnée pour qu’il puisse être analysé. Il s’agit maintenant d’identifier chaque acteur
de 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 dans
l’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 Web
dont il a besoin et avec lui les normalisations à obtenir. Il peut ainsi envoyer ses requêtes au
service 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 a
besoin.
2. l’annuaire va lui fournir les descriptions et les URL des services demandés afin de lui permettre
de les invoquer.
3. Le client envoie une deuxième requête au serveur pour obtenir le contrat de normalisation
de 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 sous
la même forme normalisée [151].
3.9 L’architecture étendue des services web SOAP/WSDL/UDDI

Elle 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 les
utiliser de manière autonome (sans intervention humaine) d’un bout à l’autre des opérations.
3.9.1 Le protocole de communication SOAP

C’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 permet
aux 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 plus
en 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’élaboration
de ce protocole. De plus il existe des implémentations Java, et Borland vient déjà d’implémenter
SOAP sous Windows dans Delphi 6 et sous Linux avec Kylix. Bien qu’il soit utilisable avec d’autres
protocoles 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 sur
des infrastructures distribuées. En effet [141] :
– Spécification car SOAP est un document qui définit le modèle de communication. L’idée de
base est que si les deux parties ont créé des programmes de mêmes spécifications, ils seront
en mesure d’interagir de façon transparente.
– Omniprésente car SOAP est défini à un niveau suffisamment élevé d’abstractions que tout
système d’exploitation et combinaison de langages de programmation peuvent être utilisés
pour créer des programmes compatibles SOAP.
– Basé sur XML SOAP est construit sur XML, ce qui signifie que les documents SOAP sont
des 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 ou
bien quels appels de fonctions peuvent avoir lieu sur elle. Les applications construites sur la
spécification SOAP peuvent déplacer les données d’un ordinateur A à un ordinateur B et par
la suite à une autre application écrite sur la même spécification.
3.9.2 Le langage XML

XML (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 comme
recommandation par le W3C, ce qui en fait un langage reconnu. XML est un standard qui sert
de base pour créer des langages balisés spécialisés ; c’est un « méta langage ». Il est suffisamment
général pour que les langages basés sur XML, appelés aussi dialectes XML, puissent être utilisés
pour décrire toutes sortes de données et de textes. Il s’agit donc partiellement d’un format de
données. Son objectif est, dans un échange entre systèmes informatiques, de transférer, en même
temps, des données et leurs structures. Permettant de coder n’importe quel type de donnée, depuis
l’échange EDI (Electronic Data Interchange ou Echange de Données Informatisées)[135] jusqu’aux
documents les plus complexes, son potentiel est de devenir le standard universel et multilingue
d’échange d’informations. XML Namespaces est une extension de la recommandation XML qui
permet de créer des espaces de nommages. Les espaces de noms d’XML permettent de qualifier
de manière unique des éléments et des attributs. On sait alors à quel domaine de définition se
rapporte un objet et comment il doit être interprété, selon sa spécification. Différencier des espaces
de noms permet de faire coopérer, dans un même document, des objets ayant le même nom, mais
une signification différente, souvent liée à un modèle de contenu différent. Cette spécification est
une 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 alors
toute son importance [139].
3.9.3 Le langage de description WSDL

Un 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 du
langage 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 de
transmission.
3. PortTypes : décrit un ensemble d’opérations. Chaque opération à zéro ou un message en

entré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 le
service 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 description
des capacités du service Web. Ses éléments abstraits définissent les messages SOAP de façon
totalement indépendante de la plate-forme et de la langue. Cela facilite la définition d’un
ensemble de services pouvant être implémentés par différents sites Web. Les quatre éléments
abstraits 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 UDDI

L’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 est
une initiative lancée par ARIBA, Microsoft et IBM. Cette spécification n’est pas gérée par le W3C
mais par le groupe OASIS. La spécification UDDI vise à créer une plate-forme indépendante, un
espace de travail (framework) ouvert pour la description, la découverte et l’intégration des services
des entreprises. L’annuaire UDDI se concentre sur le processus de découverte de l’architecture
orientée services (SOA), et utilise des technologies standards telles que XML, SOAP et WSDL qui
permettent 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 standard
WSDL.
– 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 fichiers
WSDL. Ainsi, les clients peuvent plus facilement rechercher les services Web dont ils ont besoin
en interrogeant le registre UDDI. Lorsqu’un client trouve une description de Service Web qui lui
convient, il télécharge son fichier WSDL depuis le registre UDDI. Ensuite, à partir des informations
inscrites dans le fichier WSDL, notamment la référence vers le service Web, le client peut invoquer
le 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ès
souvent 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 implique
de 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’est
pas forcément un handicap quand les volumes de données transités par SOAP sont faibles
par 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 REST

REST [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 évoque
l’image du fonctionnement d’une application Web bien construite : un réseau de pages Web (une
machine à é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 état
de l’application) à l’utilisateur qui peut alors l’exploiter" [45]. L’architecture REST est basée sur
les standards du web et utilise le protocole HTTP pour l’échange de données. Cette architecture
s’articule autour de « ressources », ainsi chaque composant est une ressource et est accessible par
une interface commune en utilisant des méthodes du standard HTTP [137]. Dans une architecture
REST, le serveur fournit simplement l’accès aux ressources. Chaque ressource est identifiée par un
URI (Uniform Resource Identifier) que le client utilise. On appelle « Restfull Web Services » des
services web basés sur l’architecture REST. Ces services web sont légers, hautement évolutifs et
maintenables. 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 leurs
avantages du fait que leur implémentation ne doit respecter quasiment aucune contraintes pour
pouvoir fonctionner. En effet, contrairement à SOAP, REST n’est pas un protocole mais bien un
style 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/mpeg

pour la représentation des ressources.
– Des liens hypermedia dans des documents HTML, XML ou autres pour représenter à la fois
le 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 suivre
certaines lignes directrices afin de coller au mieux à l’architecture REST.
3.10.1 URI et Ressource

Un 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 ressource
Web) physique ou abstraite, et dont la syntaxe respecte une norme d’Internet mise en place pour le
World Wide Web. Les URI sont la technologie de base du World Wide Web car tous les hyperliens
du 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 de
transmettre des paramètres, soit dans l’URI, soit dans les données d’un formulaire. L’utilisation
de GET est "sûre", c’est à dire que l’état de la ressource ne doit pas être modifié par un GET. Ceci
autorise les liens, la mise en cache, les favoris. Il faut donc utiliser GET pour des opérations qui
ressemblent à des questions ou à des lectures de l’état de la ressource. En revanche, il faut utiliser
POST 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’utilisateur
ou son agent peut suivre des liens sans obligations. La conséquence de l’idempotence du GET (deux
accès successifs donnent le même résultat) rend l’utilisation du Web plus fiable car un deuxième
clic sur un lien ne modifie pas le résultat. Le protocole HTTP comporte d’autres commandes moins
souvent utilisées. HEAD qui est un GET qui ne renvoie que les métadonnées, pas les données. PUT
et DELETE pour créer ou supprimer une ressource [141].
3.10.3 Les avantages de l’architecture REST

Dans [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çon
universelle ; 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émoire
inférieure, une plus grande simplicité et donc à une capacité plus grande de répondre à un
grand nombre de requêtes simultanées.
– L’absence de gestion d’état du client sur le serveur permet une répartition des requêtes sur
plusieurs 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). Cela
permet 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é de
SOAP 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 du
temps HTTP). Il ne bénéficie donc pas des caractéristiques HTTP, gérée par l’infrastructure
réseau (notamment le proxy supportant le cache côté serveur pour des performances plus
importantes).
– L’utilisation d’URI comme représentant d’une ressource, permet la mise en place de serveurs
cache.
3.10.4 Les inconvénients de l’architecture REST

Les principaux inconvénients de REST sont [13] :
– La nécessité pour le client de conserver localement toutes les données nécessaires au bon
déroulement d’une requête, ce qui induit une consommation en bande passante réseau plus
grande. S’il est possible de coupler une application web REST à un service extérieur assurant
la permanence des données lors de la durée d’une session, par exemple une base de données
ou un cookie, on pourrait cependant considérer que l’utilisation d’un tel service pour gérer
des données relatives à une session ouverte par le client serait en violation de la philosophie
de REST. REST préfèrera l’utilisation de tableaux codés en JavaScript présents dans la
mémoire du navigateur client.
– L’utilisation d’un formulaire HTML envoyant ses données avec une méthode comme DELETE
ne peut être compris par la plupart des navigateurs. Pour pallier ce problème on émule
ce comportement avec un champ caché qui transmettra le type de méthode d’envoi des
données à l’application. Par ailleurs beaucoup d’applications, bien que ne respectant pas
scrupuleusement toutes les contraintes de l’architecture REST, sont largement inspirées par
elle.
3.11 Systèmes utilisant les services web

Roy 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 comme
REST. 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, nous
avons sélectionné des applications connues et disponibles sur le web en donnant un exemple de
service web utilisé.
Gmail
Gmail 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 un
navigateur 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 service Source

web
GET https ://www.googleapis.com/gmail/ Cette requête va demander à Site officiel
v1/users/me/messages ?q="in :sent af- Gmail tous les messages qui de Gmail
ter :2014/01/01 before :2014/01/30" ont été envoyés entre le 1 jan- [143]
vier 2014 et le 30 janvier 2014
Table 3.1 – Exemple de service web : Gmail
Github
GitHub 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 son
application.

web
GET /users/ :username Cette requête permet d’obte- Site officiel
nir les informations concer- de GitHub
nant un utilisateur [144]
Table 3.2 – Exemple de service web : Github
Weather Underground
Cette 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ées
dans d’autres logiciels. Par exemple, si on crée une application qui suggère aux utilisateurs les
vêtements qu’ils devraient porter pour aller courir, on aura besoin de connaître la température, les
conditions météorologiques, quand le soleil se lèvera et se couchera, etc., pour permettre au logiciel
de faire des prédictions. Créer son propre service météorologique pour recevoir ces informations
serait beaucoup trop long et fastidieux ; utiliser les données de cette API pour sa propre utilisation
est donc un très bon choix. Elle permet de donner des informations très pratiques sur n’importe
quelle ville comme la vitesse du vent, les précipitations, la puissance des rayons UV, etc.

web
GET http ://api.wunderground.com/api/ Cette requête permet d’avoir Site of-
YourKey/conditions/q/CA/SanFrancisco. la météo à San Fransisco ficiel de
json Weather Un-
derground
[146]
Table 3.3 – Exemple de service web : Weather Underground
Instagram
Instagram 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 Windows
Phone. 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.

web
GET /users/user-id Cette requête permet d’avoir
les informations d’un utilisa- Site officiel
teur grâce à identifiant
Get /users/search Chercher un utilisateur par le d’Instagram
nom
GET /users/user-id/media/recent Chercher les plus récentes me- [145]
dias de l’utilisateur
Table 3.4 – Exemple de service web : Instagram
3.12 L’aide à la décision et les services web

L’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 de
décision qui est peut être impossible sans son aide. Nous avons abordé, en détails, dans le chapitre I
ce domaine en commençant par la notion de décision pour arriver à un système d’aide à la décision
de groupe quand les décideurs sont nombreux. Dans la réalité, les décideurs ne sont pas toujours
dans le même lieu mais plutôt géographiquement dispersés, la communication est alors nécessaire
pour pouvoir décider. D’un point de vue opérationnel, l’aide à la décision a connu ces derniers
temps une révolution : l’orientation desktop a é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
profite des avantages des services web quand il suit une architecture client/ serveur, le client peut
consulter 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 dans
le 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 dans
le serveur peut être très intéressant et de ce fait le décideur n’a qu’à actualiser ses données en
utilisant un service. Nous avons présenté dans la section précédente, quelques systèmes en ligne
puissants 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 quelques
systè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 des
bases 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 consiste
en un système d’aide à la décision collaborative : une plateforme web-SIG est proposée pour la
gestion des risques avec la participation des différentes parties prenantes, en s’appuyant sur les
avantages du web moderne, les technologies géo spatiales. Cette plateforme web a été conçue
pour le partage centralisé des informations des risques, où les parties prenantes concernées peuvent
analyser les risques, évaluer et sélectionner les mesures de réduction des risques de façon interactive
et collaborative.
3.13 Conclusion
Nous 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 et
services web de type REST.
Rest et SOAP sont souvent comparés l’un à l’autre dans la conception des applications clients
serveurs mais on oublie de dire qu’ils ne sont pas du même type. En effet, SOAP est un protocole
dé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 connus
du 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 en
profondeur le système d’information. Il s’agit de l’ajout de briques supplémentaires. Pour cela, les
Services Web exploitent les standards d’échange Internet. Les services Web avec leurs protocoles
et leurs standards avancent de jour en jour vers plus de normalisation.
Dans le prochain chapitre, nous présenterons notre contribution qui consiste à mettre en place
un système d’aide à la décision de groupe destiné à trouver un consensus entre un ensemble de
décideurs dans un contexte multicritères tout en exploitant un protocole de négociation à travers
une plateforme de communication utilisant les services web .
Deuxième partie
Contributions
Chapitre 4
Modélisation de l’approche
proposée
4.1 Introduction
Dans 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. Le
système d’aide à la décision de groupe correspondant comporte une plateforme de communication
web susceptible d’assurer la négociation entre un ensemble de décideurs en conflit. Cette dernière
inclut 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] que
nous verrons en détail dans ce chapitre. Notre approche s’appuie sur le partage d’informations, le
partage d’avis. . . en assurant la communication par un partage d’informations structurées 1 et non
structurées 2 . Nous présentons, dans ce chapitre, les principaux composants de la plateforme ainsi
que 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és

Notre 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 ce
par des fonctionnalités intervenant à divers niveaux du processus. Aussi, nous conformons notre
plateforme à la typologie donnée par Desanctis et Gallupe [34] que nous avons cité dans le chapitre
I 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 du
premier. Ils sont, en plus, dotés de procédures permettant de modéliser et d’agréger les
préférences individuelles afin d’établir un consensus.
Niveau 3 : Les GDSS de niveau 3 permettent, de façon automatisée, de structurer les échanges
d’information et la communication sur la base de recommandations émises par des systèmes
experts ou d’experts humains, comme par exemple, les règles à suivre au cours du processus
de 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 permettant

d’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 structuration
des échanges, notre plateforme donne une place particulière au rôle d’initiateur (ou médiateur) qui a
la charge de créer et de gérer le processus décisionnel. Les GDSS étant une extension des systèmes
d’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 à mieux
exprimer ses préférences.
Les niveaux de GDSS selon De- Le GDSS proposé

sanctis et Gallup [34]
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 charge

de créer et de gérer le processus décisionnel.
– Une aide individuelle aux décideurs : une méthode

d’analyse multicritères permettant d’aider chaque
décideur à mieux exprimer ses préférences.
Table 4.1 – Analogie entre les niveaux du système proposé et ceux proposés par Desanctis et
Gallup
Un autre objectif de notre travail est de proposer une plateforme distribuée permettant de faire
participer des décideurs géographiquement éloignés. Afin d’atteindre ce but, la mise en œuvre de
la plateforme exploite les technologies du web, et plus spécifiquement la technologie des services
web.
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 non
négligeable, elle s’inscrit parmi les travaux du laboratoire LIO (équipe de recherche : Ingénierie
de l’aide multicritères à la décision collective, distribuée et temps réel pour la gestion
environnementale, 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 naturellement
sur les standards du web et présentent l’avantage de la simplicité, c’est par conséquent ce type de
services 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 : La
dé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 une
source d’inspiration des processus décisionnels par la suite et qui a donné lieu à plusieurs critiques
se 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 la
conception 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 pour
faire ressortir à quelle catégorie il appartient, 2) la définition du problème pour en connaître les
causes et les effets, 3) les spécifications permettant de définir les conditions limites pour atteindre
les 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 aux
personnels concernés, 6) le feedback pour évaluer la pertinence de la décision ou voir le cas échéant
les mesures correctrices à prendre [5].
Ces quelques modélisations des phases du processus décisionnel nous font réaliser qu’en fait un
processus décisionnel doit passer par des étapes séquentielles illustrées dans le Tableau 4.2 par
Schwenk [106] comme suit :
Hofer et Mintzberg Glueck Mazzolini Modèle géné-

Schendel[59] [79] [48] [77] ral
1 Identification 1-Phase d’iden- 1-Évaluation 1-Identification 1-Définition du
de la stratégie. tification. 2-Choix, phase d’un besoin de but,
2 Diagnostic Reconnaissance 1 : considérer décision Identification
d’environne- d’un besoin de les solutions 2-Recherche du problème.
ment. décision. stratégiques de solutions 2-Énoncé de
3 Analyse des -Diagnostic. 3-Choix, d’action. solutions straté-
ressources. 2-Phase d’éla- phase2 : Choix 3-Analyse des giques.
4 Analyse boration. de la stratégie solutions d’ac- 3-Évaluation
d’écart. -Recherche. 4- Mise en tion. des choix.
6 Évaluation de -Conception. œuvre 4-Revue e ap- 4-Mise en
la stratégie. 3-Phase de 5.Évaluation de probation. œuvre.
7 Choix de la choix. la stratégie 5-Mise en
stratégie. -Évaluation. œuvre.
-Autorisation.
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 processus
de décision commence par l’identification du problème et se termine par la mise en œuvre de la
solution retenue. Mais ce que nous constatons le plus c’est que ces modèles sont destinés à un
processus décisionnel mono décideur qui fait lui-même la collecte et l’analyse de l’information et
la prise de décision. Notre modèle proposé s’inspire largement du modèle proposé au sein de notre
laboratoire LIO par Hamdadou [52], figure 4.1. Il a comme caractéristique d’être multi décideurs
puisqu’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 un
conflit dû aux divergences des opinions et des préférences des décideurs. A cet effet, nous intégrons
dans notre processus un protocole de négociation permettant d’amener le groupe à une décision
satisfaisante pour toutes les parties afin d’assurer la résolution du conflit comme montré dans la
figure 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 objectif

l’identification du problème et les choix fondamentaux sur la manière de l’aborder.
– Identifier les critères

La 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ères
définitifs , la liste des facteurs doit être aussi complète que possible.
– Identifier les actions
L’dentification de l’ensemble des actions est une étape très sensible dans toute démarche
d’aide à la decison, en particulier lorsque la méthode d’analyse multicirtères procède par
agrégation partielle ,il est très important que l’ensemble des actions soit aussi complet
que possible car sa modification en court de route peut entrainer la repétition de l’analyse
multicritères.
– Identifier les acteurs
Le 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 des

ressources, 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 de
producteurs, etc.), politiques (un parti, le conseil municipal, le conseil des anciens d’une
communauté, etc.), sociales (associations de jeunes, etc.). La multiplicité des acteurs
rend la négociation territoriale difficile puisque d’un côté nous aurons les acteurs forts
disposant d’un pouvoir important et de l’autre côté des acteurs faibles qui ont plus de
difficulté à défendre leurs intérêts.
2. La phase d’exploitation du modèle : Sert à effectuer certains types d’analyses sur le

modèle. Dans cette phase, toutes les parties prenantes seront modélisées sous forme d’agent
participants, à chaque agent participant est associé un poids afin d’exprimer son importance
et 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érentes
ressources) via la méthode PROMETHEE II. Après plusieurs tours de négociation, les agents
participants arrivent à un consensus qui satisfait toutes les parties prenantes ou une partie
d’entre elles, c’est l’accord final.
3. la phase de concrétisation et d’évaluation : vise essentiellement l’acceptation sociale

du 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 groupe

proposé
Le système d’aide à la décision de groupe proposé comporte,principalement, une plateforme de
communication basée sur des services web. Cette plateforme intègre un protocole de négociation
qui exploite dans l’une de ses étapes une méthode d’analyse multicriteres permettant de classer
les actions potentielless de chaque agent impliqué dans la prise de décision. Nous allons détailler
cette 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 SMA

Les 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], pouvant
coopérer, communiquer et négocier.Les systèmes multi agents ont pour but de créer une mission
de 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 un
participant à la négociation.
4.4.2 Identification des acteurs concernés

A 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 à un
utilisateur 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 que
décideur ou initiateur. A partir de cet espace, et lors de l’accès à une session, l’utilisateur se verra
appliquer le rôle d’initiateur ou de décideur selon la session. Dans ce qui suit nous exposons les
détails de conception de la plateforme proposée.
4.4.3 Description de la plateforme de communication proposée

La 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 à la
disposition 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 couche
de persistance des données (base de données relationnelle).
2. Le second sous-système est une application cliente (JavaScript) consommant les services web
du premier système. Seules des données brutes sont échangées entre les deux systèmes (par le
biais 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 son
interface,
– le second niveau concerne l’interaction de l’application cliente avec les services web via des
requêtes http.
Dans cette partie du chapitre, nous ne distinguons pas ces deux niveaux, en nous situant dans
une 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 de
décideurs. Une session concerne un problème précis qui y sera discuté et pour lequel une solution
de groupe doit être trouvée. La figure 4.6 montre l’attribution des différents modules composant
la 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’un

compte, l’administrateur peut spécifier si un utilisateur dispose du droit de créer des sessions de
travail et d’y inviter d’autres utilisateurs. Si un utilisateur ne dispose pas de ce droit, il ne peut
que 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 la

plateforme. Elle illustre comment un administrateur gère les comptes utilisateurs et quelles sont
les droits qu’il a sur ces derniers. A cet effet, il peut créer un utilisateur, le modifier, le supprimer
et lui attribuer des droits de créer des sessions décisionnelles, toutes ces actions sont réalisées par
des 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 session
et y inviter d’autres utilisateurs. Au cours du processus décisionnel, l’acteur qui crée une session
aura le rôle d’initiateur (ou médiateur), les invités sont des intervenants qui participeront pour
leur totalité ou une partie d’entre eux dans la décision finale. Une session peut être paramétrée par
l’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 de

la plateforme. Elle illustre les actions qu’effectue un utilisateur pour la gestion des sessions, ces
actions sont réalisées par des services web que nous détaillerons plus loin. Dans cette partie, nous
distinguons deux situations :
1. la première situation : Si l’utilisateur ne dispose pas de droits de sessions alors, il n’est qu’un
simple décideur qui a été invité par un initiateur à une session décisionnelle, il peut consulter
la 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 plusieurs
session(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 attribuer
des 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 la

plateforme. 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 session
décisionnelle comme ils peuvent les lire. Quant à l’agent initiateur, il à la possibilité de bloquer ou
autoriser 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 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 de
poster un document pour le partager, il peut le décrire dans une section spécifique comme il peut
té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 champs
de 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 formulaire
et de le diffuser à l’intention des participants. Ceux-ci sont appelés à renseigner ses champs et à le
retourner. 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 leurs
préférences.
Figure 4.11 – Diagramme de cas d’utilisation : Système de formulaires

la plateforme. Elle illustre les actions nécessaires pour la gestion de formulaires par les services
web. Les actions de l’agent initiateur sont : la création et la diffusion de formulaire ainsi que la
consultation 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 des
utilisateurs une méthode d’analyse multicritères par agrégation partielle à savoir « PROMETHEE
II ». C’est une méthode multicritères qui permet de résoudre la problématique de rangement afin
de 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, P S, 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 attributs
ou critères, c’est-à-dire l’ensemble des vecteurs de performances, un vecteur par action.
– P S : 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 et
un ensemble fini d’actions A La famille PROMETHEE de manière générale associe à chaque
critère un poids exprimant son importance, ainsi qu’une fonction de préférence Pj définie de
la 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 (a, b) = 0 (indif f érence entre a et b) si dj (a, b) = 0

 Pj (a, b) ˜ 0 (préf érence f aible de a sur b) si dj (a, b) > 0

Pj : (4.2)


 Pj (a, b)˜ 1(préf érence f orte 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
Il existe une infinité de fonctions qui satisfont cette définition. Les auteurs de PROMETHEE
ont en catégorisé six types qui semblent, selon les auteurs, recouvrir la plupart des besoins
rencontré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 étant
le seuil à partir duquel la différence entre deux actions (i.e : dj (a, b)) est perceptible et fait
préférer l’une à l’autre. Le seuil d’indifférence quant à lui est la plus petite différence qui est
significative, en dessous de ce seuil il est impossible de départager deux actions. Les seuils
ainsi que la fonction de préférences composent ce qu’on appelle les paramètres subjectifs
intra-critère et les poids les paramètres subjectifs inter-critères. Nous citons ci-dessous deux
exemple 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 sont
clairement 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].


 0 d ≤ q

d − q
P (d) : q < d ≤ p (4.3)

 p−q


1 d >q
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 entre
elles présentent un caractère continu, ou encore lorsque toutes les valeurs intermédiaires entre
les valeurs maximales et minimales de ces écarts sont possibles, seul le seuil de préférence (p)
est introduit [55].


 0 d ≤ 0

d
P (d) : 0 ≤ d ≤ p (4.4)

 p


1 d >p
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 des
seuils de préférence et d’indifférence traduit ce qu’on appelle communément « l’expression
des 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 les
paires d’actions. L’indice de préférence global d’une action (a) sur une action (b) est
donné par :
P
i∈F wj × Pj (a, b)
π(a, b) = P (4.5)
i∈F wj
Où F est l’ensemble des critères, wj le poids du critère j et Pj la fonction de préférence

pour le critère j. Cet indice représente le degré de préférence de (a) sur (b) en considérant
simultanément tous les critères. En comparant toutes les actions les unes par rapport
aux 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 la
dominance de (a)par rapport aux autres actions, noté Φ+ (a) ainsi que son flux entrant
qui représente la faiblesse de (a) par rapport aux autres actions Φ− (a) : (4.3) (4.4)
P
+ b∈A π(a, b)
Φ (a) = (4.6)
n−1
P
− π(b, a)
b∈A
Φ (a) = (4.7)
n−1
n nombre d’actions.
– La dernière étape consiste à calculer, pour toute action (a), son flux net noté Φ(a) par
la 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 sur
la 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 PROMETHEE

II [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 dans
la modélisation des préférences.
– PROMETHEE, quoique dépourvue d’une base mathématiques, a essayé de combler ce
manque en procédant par la systématisation de la fonction de préférence. En effet, le
décideur, ayant à choisir la forme de sa préférence parmi six formes, se sentirait plutôt
rassuré.
– La simplicité de PROMETHEE la place sur une bonne position pour être utilisée si on
cherche à ranger des actions potentielles et que le décideur ne trouve pas beaucoup de
peine à déterminer les poids des critères. Bien souvent cette méthode est sujette à des
modifications ou des extensions [116].
La figure 4.15 présente un pseudo-diagramme UML d’état transition correspondant. Elle

illustre les étapes par lesquelles passe l’analyse multicritères par PROMETHEE II. Tout
d’abord, chaque décideur doit charger la matrice de performances mise à sa disposition par
l’initiateur, ensuite il introduit ses préférences puis il les envoie au système. A partir de ces
donné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 potentielles
selon 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 un
conflit 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éthode
permettant 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 pas
identifiées et prises en charge, conduisent à ne pas prendre la meilleure décision. Pour illustrer
ce propos, nous prenons l’exemple d’une situation décisionnelle où trois décideurs doivent faire le
choix entre trois actions (ou options) A, B et C. Dans un premier temps, l’initiateur leur propose
de 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 finalement
l’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écideurs
de sélectionner les options qu’ils jugent acceptable via un formulaire à choix multiple. La figure
4.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’est
souvent une organisation). Dans le cas où le décideur 3 est moins important que les décideurs
1 et 2 et qu’au même moment, la préférence de ces derniers pour l’option A est beaucoup plus
grande que pour l’option B, c’est l’option A qui doit être retenue. A contrario, si la préférence des
décideurs 1 et 2 pour l’option A n’est que légèrement supérieure à celle pour l’option B, le sens du
consensus conduirait à choisir l’option B comme décision de groupe, car choisie par la totalité des
participants. Ceci nous conduit à constater qu’une décision de groupe doit tenir compte de deux
notions :
– 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 qualifier
ses 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 à cette
question. En effet, une méthode de la famille Gamma (rangement) nous permet de ranger les
actions de la « la moins bonne » vers la « meilleure » en tenant compte de l’expression des
pré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’un
protocole 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 à chaque
dé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 et
détaillées plus loin. L’objectif du protocole de négociation que nous intégrons à la plateforme est
de permettre de mener un groupe à un consensus concernant la décision à prendre vis-à-vis un
problè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 modification

de contrat (proposition).
2. Participants : Ce sont tous ceux qui sont concernés par la décision, le but de chacun d’entre
eux 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’initiateur
et les différents participants. Il procède en 5 principales phases : la phase d’initialisation, la phase
de 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 sont
appelé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 leurs
préférences.
3. Phase d’évaluation Lorsque l’initiateur reçoit toutes les réponses des participants concernant
une 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), alors
la 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 contrat
en 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 de
proposition.
5. Phase de décision C’est la dernière étape du protocole suggéré. Elle est synonyme de la fin
de la négociation, une décision est prise par l’initiateur selon les réponses des participants
aux propositions qu’il leur a faites. Il clôture ensuite la négociation soit par un succès soit
par 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 la

négociation, la cardinalité de la négociation, le langage de la négociation, les stratégies des différents
dé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 à travers
le protocole jusqu’à ce que l’une d’elle soit choisie comme étant la meilleure ressource pour tous
les 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 avons
un initiateur qui communique avec le reste des participants donc notre cardinalité est de 1 à n
décideurs.
B.3 Le langage de négociation
Le langage de négociation adopté par le protocole proposé, est un échange de messages entre
l’agent initiateur et les agents participants appelés primitives. Dans cette optique, on définit des
primitives 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 lui
associons, par conséquent, quatre primitives de négociation :
1. REQUEST () : l’initiateur envoie ce message aux participants pour leurs indiquer le début
de la négociation. Chaque participant doit associer à chaque ressource figurant dans son
vecteur 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ès

avoir effectué un scorage de toutes les ressources.
3. CONFIRM () : l’initiateur envoie ce message aux participants pour les informer que la
né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 la
né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 participant
dispose de trois primitives de négociation :
1. INFORM () : les participants envoient ce message à l’initiateur après avoir effectué le

rangement des actions et obtenu des vecteurs de préférences par analyse multicritères. Ce
message contient le vecteur de classement des ressources.
2. ACCEPT_PROPOSAL () : ce message est envoyé à l’initiateur, après avoir reçu une

proposition 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 une

proposition 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é assez
nombreux à l’accepter tandis que la stratégie associée aux participants leur permet d’accepter la
proposition 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 envoie

un 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 de
préférences des participants. Après réception de ces derniers, l’initiateur effectue un scorage
des ressources pour n’obtenir qu’un seul vecteur de préférence synthétisant ceux de tous les
participants.
Le score global d’une action représente l’agrégation des préférences de tous les décideurs
relativement à 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 :

X
score(i) = wj × (nbActions + 1 − rang(i)) (4.9)
decideurj
(b) Score par flux : X

score(i) = wj × f luxnet(i) (4.10)
decideurj
Remarque : dans la première version du protocole dont nous nous inspirons [53] [54]. Le
score est calculé à partir du rang des actions et non pas à partir du flux net (donné par
PROMETHEE II).
Nous avons proposé la 2ème alternative (rangement à partir du flux net) afin d’enrichir la
notion de « degré de préférence » et justifions notre choix par l’exemple suivant : Pour deux
actions qui se suivent au sens du rang, nous savons, par leurs rangs, quelle action est meilleure
mais pas de « combien ». Le flux net étant, par définition, une indication sur la qualité d’une
action, il nous semble qu’il permettrait de quantifier les différences avec plus de précision et
dans 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 un

seul vecteur de préférence en triant les ressources de la meilleure (celle avec le plus grand
nombre de points) vers la pire (celle avec le plus petit nombre de points), et envoie comme
1ère proposition (à tous les participants) la ressource la mieux classée en utilisant le message
PROPOSE.
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 taux
d’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 la
stratégie de modification, si le nombre de tours maximal est atteint et qu’aucune ressource
n’a été validé alors la négociation est un échec.
5. Stratégie de modification : L’initiateur propose aux participants la ressource suivante

dans le vecteur de préférence et applique de nouveau la stratégie de négociation. Il procède
de 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éthode
multicritè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 nouvelle

proposition dans un nouveau tour, les participants doivent soit accepter la proposition soit
la refuser. Pour pouvoir prendre une décision, un participant (décideur) consulte son vecteur
de préférence, en effet, si cette proposition (ressource = action) se trouve dans la première
moitié de son vecteur de préférence, alors il accepte la proposition en envoyant un message
ACCEPT_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, avec

un 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 message
AGREE 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 il
saura que la négociation a échoué. Les étapes du protocole sont schématisées et synthétisées par
le 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ères
et 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ée
si 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. Nous
proposons 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ébut
Entré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’initialisation
REQUEST () : l’initiateur lance la négociation et demande le vecteur de préférences de chaque
dé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’exploitation
Calcul 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 II
Calcul du score de chaque action :
X
score(i) = wj × (nb_Actions + 1 − rang(i)) (4.11)
decideurj
i=1, Nb_Actions et j=1, D.

2 Etape de proposition
PROPOSE () Proposition de l’action ayant le score le plus élevé.
3 Etapes d’évaluation
SI (l’action correspond au vecteur de préférences) Alors ACCEPT_PROPOSAL()
Sinon REJECT_PROPOSAL()
4 Etape de modification
Si [(le taux d’acceptation < seuil d’acceptation) Et (Nbre_tours effectués < Nbre_tours maximal)]
Alors PROPOSE ()
5 Etape de décision
Si (le taux d’acceptation >= seuil d’acceptation)
Alors CONFIRM () // la négociation est un succès
Sinon
FAILURE ()// la négociation est un Echec
Si (Nbre_tours effectués > Nbre_tours maximal)
Alors FAILURE ()// la négociation est un échec
Fin.
Algorithme 2 : protocole de négociation proposé utilisant le flux net des actions
Début
Entré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’initialisation
REQUEST () : l’initiateur lance la négociation et demande le vecteur de préférences de chaque
dé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’exploitation
Calcul 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 II
Calcul du score de chaque action :
X
score(i) = wj × f luxnet(i) (4.12)
decideurj
i=1 et j=1, D.
2 Etape de proposition
PROPOSE () Proposition de l’action ayant le score le plus élevé.
3 Etapes d’évaluation
SI (l’action correspond au vecteur de préférences) Alors ACCEPT_PROPOSAL()
Sinon REJECT_PROPOSAL()
4 Etape de modification
Si [(le taux d’acceptation < seuil d’acceptation) Et (Nbre_tours effectués < Nbre_tours maximal)]
Alors PROPOSE ()
5 Etape de décision
Si (le taux d’acceptation >= seuil d’acceptation)
Alors CONFIRM () // la négociation est un succès
Sinon
FAILURE ()// la négociation est un Echec
Si (Nbre_tours effectués > Nbre_tours maximal)
Alors FAILURE ()// la négociation est un échec
Fin.
D Modélisation du protocole de la négociation
Afin de représenter les interactions entre l’agent initiateur et les agents participants, nous optons
pour la modélisation UML, souvent utilisée pour décrire l’interaction des différentes entités. La
figure 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 à la
dé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 web

Comme 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. Les
services web (de type REST) exposent les fonctionnalités permettant d’interagir avec le système
d’information et d’exécuter des opérations telle que l’analyse multicritères. La mise en place d’un
service web REST doit prendre en compte trois éléments principaux [2] :
1. Des Uri (Uniform Resource Identifier) pour identifier les ressources. Une application se doit
de construire ses URI (et donc ses URL) de manière précise. Il est nécessaire de prendre en
compte la hiérarchie des ressources et la sémantique des URL pour les éditer. Nous montrons
plus loin chaque Uri des services web utilisé.
2. les méthodes http pour définir l’action : consistent à utiliser les verbes HTTP existants
plutôt que d’inclure l’opération dans l’URI de la ressource. Ainsi, pour une ressource, il y
a, principalement, 4 opérations possibles : Get, Post, Put et Delete. Nous montrons leur
utilisation 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 le
XML et le JSON. Cependant, un bref comparatif entre ces deux types nous fera préférer la
représentation JSON. En effet, le XML est plus « verbeux 3 » à expliquer en bas de page que
le 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 http
exposées par les services web. Nous donnons aussi le diagramme des classes utilisées pour modéliser
le 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é- Méthode exécutée Note

thode
/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 avec
rô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

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- Ajouter un utilisateur à la
sion) session
Table 4.4 – Services web de gestion des sessions
– Service web gestion des messages :
Figure 4.24 – Diagramme de classes : perspective = message


thode
/sessionId /mes- GET getMessages(sessionId) Retourner la liste des mes-
sages sages de la session
POST postMessage(sessionId, userId, Mes- Poster un message dans
sage) la session. L’envoyeur est
identifié par userId : para-
mètre dans l’Uri
/sessionId POST uploadDocument(sessionId, Docu- Enregistrer le document
/docu /upload ment) envoyé et créer un message
dans la session avec le do-
cument attaché.
/sessionId GET downloadAttachedDocument (msgId) Envoyer le document at-
/download taché au message “messa-
/msgId geId”
Table 4.5 – Services web de gestion des documents
– Service web gestion des formulaires :

Figure 4.25 – Diagramme de classes : perspective = formulaire
.

thode
/sessionId GET getForms(sessionId) Retourner les formulaires
/forms enregistrés dans la session
POST createForm(sessionId, Form, Créer le formulaire et
List<User>) la liste des destinataires.
Ajouter le formulaire à la
session. Créer pour chaque
destinataire une réponse
(FormResponse) par dé-
faut.
/sessionId PUT updateForm(formId, Form, Mettre à jour le formulaire
/forms /for- List<User>)
mId/
DELETE deleteForm(formId) Supprimer le formulaire
/sessionId GET getFormResponses(sessionId) Retourner la liste des ré-
/formresponse ponses aux formulaires de
la session.
/sessionId PUT updateFormResponse(respId, Form- Mettre à jour la réponse.
/formresponse Response)
/respId
Table 4.6 – Services web de gestion des formulaires
– Service web analyse multicritères :

Figure 4.26 – Diagramme de classes : Analyse multicritères


thode
/sessionId/amc GET getListAmcInstance(sessionId) Retourner la liste des ins-
tances multicritères de la
session (critères, actions et
matrice de performance)
POST createAmcInstance(sessionId, Excel- Créer une instance multi-
File) critères (critères, action et
matrice de performances)
à partir d’un fichier Excel
dans la session. Créer des
paramètres subjectifs par
défault.
/sessionId GET getSubjectiveParams(amcId) Retourner les paramètres
/amc /am- subjectifs de l’instance.
cId/subjparams
PUT updateSubjParams(amcId, Subjective- Mettre à jours les pa-
Params) ramètres subjectifs de
l’instance amcId. Lan-
cer PROMETHEE II
sur l’instance avec les
paramètres mis à jour
/sessionId GET getPrometheeResults(amcId) Retourner les résultats de
/amc /am- PrometheeII sur l’instance
cId/promethee amcId.
Table 4.7 – Services web de l’analyse multicritères
4.7 La Synchronisation des échanges

Un 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 puis
envoie une requête HTTP au serveur. Ce dernier renvoie la réponse HTTP appropriée avant de
fermer 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 à ce
manquement, 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 afin
de récupérer de nouvelles données s’il y en a. Après sa réponse, le serveur ferme la connexion et
le 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 nombre
de requêtes vaines.
La technique du « long polling » quant à elle repose sur une autre logique. Le client envoie
une requête HTTP et le serveur, s’il ne possède pas de nouvelles données, maintient la connexion
ouverte jusqu’à ce que des données soient disponibles. Celles-ci sont alors envoyées au client puis la
connexion est fermée. Au client de renvoyer une autre requête pour maintenir le processus. Cette
technique présente l’avantage de réduire le nombre de requêtes envoyées. C’est donc cette technique
qui a été retenue pour la synchronisation des données au sein de la plateforme proposée dans le
présent travail.
4.8 Conclusion
Nous 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 conception
et 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 tous
les modules la composant.
– Un système multi agents permettant la modélisation des différents acteurs du processus

décisionnel.
– Un protocole de négociation qui permet de rechercher un compromis satisfaisant les différents

participants.
– 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 la
mé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 du
territoire. Il s’agit d’aider un ensemble de décideur à choisir un terrain parmi une multitude de
terrains satisfaisant un certain nombre de critères pour un projet de construction d’une habitation
afin de valider notre modèle proposé et nous accompagnerons le scénario par une discussion des
résultats obtenus.
Chapitre 5
Expérimentation et résultats
obtenus
5.1 Introduction
Ce 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ème
décisionnel multicritères spatial.
5.2 Technologies utilisées

La 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 des
services web selon l’architecture REST suivant les spécifications JAX-RS (spécification Java pour
les 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’outil
utilisé.
Chapitre 5.Expérimentation et résultats obtenus 101
5.2.1 GWT
GWT 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 phase
de développement, l’application est écrite en Java de façon classique, dans un environnement de
dé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, avec
support 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.0

Le 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êtes
et 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 une
requê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 PostgreSQL
La 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 un
systè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èmes
de 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 Jade
JADE (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 nous
avons 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 être
distribués sur le réseau (figure 5.2). Les agents vivent dans les conteneurs qui sont des processus
java qui fournissent tous les services nécessaires pour l’hébergement et l’exécution des agents. La
plateforme doit disposer d’un conteneur principal qui représente le point de démarrage, et qui se
charge de :
– Gérer la table des conteneurs qui contient la liste ainsi que les adresses de tous les conteneurs
qui composent la plateforme.
– Gérer la GADT (Global Agent Description Table) qui contient la liste de tous les agents
présents dans la plateforme, leur statut actuel, et leur localisation.
– Héberger l’AMS (Agent Management System) et DF (Directory Facilitator) qui fournissent

la gestion des agents, et le service des pages blanches ainsi que le service des pages jaunes
respectivement.
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ées
sur 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 control
et le débogage une tâche fastidieuse pour le programmeur. JADE offre plusieurs outils graphiques
qui 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 et

tous les agents qui la composent. Plusieurs RMA peuvent être lancés sur la même plate-forme du
moment 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çon
particulière. L’interface permet la composition et l’envoi de messages ACL et maintient une liste
de messages ACL envoyés et reçus. Cette liste peut être examinée par l’utilisateur et chaque message
peut être vu en détail ou même édité. Plus encore, le message peut être sauvegardé sur le disque
et 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’utilisation

Nous 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 administrateur

L’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 les
services 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 se
connecter à 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 utilisateur

Toute 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 de
dé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 une
session 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 au
cours du processus.
– Inscrire des participants.
– Commenter le rôle de chaque participant (décideur) et introduire son poids. Le poids d’un
participant traduit son importance au sein du groupe, et sera utilisé dans les comptes rendus
des formulaires ainsi que dans le processus de négociation.
Figure 5.11 – Espace utilisateur – Création d’une session et inscription des participants avec
attribution 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 inscrit
et y accéder. Selon son rôle dans cette session, il sera dirigé vers l’espace initiateur (figure 5.12) ou
l’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 illustratif

Afin 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 une
solution à 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 pour
la 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’étude

La 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-164
000 (m). La surface de la région d’étude est de 52 500 km2. Pour le choix de cette région, on s’est
inspiré des travaux de Joerin [63], [52] et [54] qui a essentiellement résulté du grand nombre de
données spatiales à disposition. La carte géographique relative à la région test est présentée sur la
figure 5.15 :
Figure 5.15 – Zone d’étude
5.4.2 Identification des critères d’adéquation du territoire pour l’habitat

La 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 largement
des 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, sept
critères. Le tableau suivant (Tableau 5.1) présente une vue d’ensemble des facteurs considérés dans
les critères identifiés.
Critère Type Echelle Facteurs associés Méthode d’évalua-

tion
Nuisances Naturel [0,1] Pollutions Atmosphé- Attribution d’une note
riques, Odeurs
Bruit Social [0,1] Autoroutes, Routes, Che- Attribution d’une note
mins de fer
Impacts Social {0,..,6} Eaux souterraines, Plan Attribution d’une note
Sectoriel : sites et
contraintes naturelles,
paysages à protéger,
Forêts
Géotechnique Naturel {0,..,6} Glissements de terrain Analyse spatiale
et risques
naturels
Équipements Economique [0,2244] Distance aux équipe- Consultation des ex-
ments : gaz, électricité, perts
eaux, routes
Accessibilité Economique [0,15] Durée moyenne des trajets Consultation des ex-
entre le domicile et le lieu perts
de travail
Climat Naturel [0,1] Ensoleillement, Attribution d’une note
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 actions
potentielles permettent de générer la matrice des performances, illustrée par le tableau (5.2). Cette
matrice est gérée par le SIG [63].
Actions Nuisances Bruit Impacts Géotechnique Equipement Access Climat

729 1,00 0,99 2 6 1867 10 0,68
732 1,00 0,98 2 6 1957 10 0,71
737 1,00 0,97 2 6 2047 10 0,70
740 1,00 0,97 2 6 2147 10 0,69
743 1,00 0,93 2 6 2233 9 0,67
745 1,00 0,96 2 6 2185 12 0,84
748 1,00 0,67 2 6 2220 9 0,68
1030 1,00 0,15 4 6 1832 11 0,71
1033 0,99 0,55 4 6 1906 10 0,74
1038 0,98 0,27 4 6 2037 10 0,75
1045 1,00 0,96 4 6 2232 13 0,86
1046 1,00 0,69 4 6 2186 5 0,78
1233 1,00 0,62 6 3 1911 10 0,70
1236 1,00 1,00 6 3 2070 6 0,85
1239 1,00 1,00 6 3 2142 6 0,85
1321 1,00 0,98 6 3 1648 10 0,84
1324 1,00 0,98 6 3 1756 10 0,68
1326 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és

Nous 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és
dans les tableaux suivants (5.3, 5.4, 5.5, 5.6) :
Paramètres
Poids P Q V
Critères
Nuisances 7.51 0.6 0.3 1
Bruit 13.63 0.6 0.3 0.8
Impact 13.63 0 0 0
Géotechnique 13.63 110 55 220
Equipements 17.2 10 5 20
Accessibilité 17.2 0.6 0.3 1.2
Climat 17.2 0.6 0.3 1.5
Table 5.3 – Paramètres subjectifs exprimés par le décideur 1

Paramètres
Poids P Q V
Critères
Nuisances 17.38 0.5 0.25 1
Bruit 29.4 0.6 0.3 1.2
Impact 6.16 0.3 0.15 0.6
Accessibilité 17.38 0.5 0.25 1
Climat 17.38 0.5 0.25 1
Paramètres
Poids P Q V
Critères
Nuisances 4.96 0.7 0.35 1.4
Bruit 7.08 0.7 0.35 1.4
Impact 17.31 0.6 0.3 1.2
Accessibilité 17.52 1 0.5 2
Climat 15.27 0.7 0.35 1.4
Paramètres
Poids P Q V
Critères
Nuisances 6.15 0.4 0.2 0.8
Bruit 19.57 0.4 0.2 0.8
Impact 13.79 0.2 0.1 0.4
Accessibilité 16.45 0.6 0.15 0.6
Climat 16.45 0.4 0.2 0.8
5.4.4 Description du processus décisionnel

Un 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 de
dé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 des
compléments d’informations selon son domaine de compétence ce que nous avons appelé l’échange
d’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éhension
des décideurs en leur soumettant un formulaire contenant plusieurs QCM ou QCS. Le formulaire
est 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 des
critères pour l’évaluation des solutions (terrains). Par le biais de la messagerie, l’initiateur récolte
les 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 conclut
en retenant les trois critères (Bruit, Géotechnique et Accessibilité). Cette étape est facultative dans
le 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 par
les 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écideur
en utilisant PROMETHEE II. L’exécution et les résultats de la méthode PROMETHEE II pour
chaque 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 comme
critè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 leurs
pré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 seuil

d’acceptation, avec possibilité de comptabiliser les réponses de manière pondérée (« user
weights »). Figure 5.24.
– Comme nous l’avons expliqué nous avons mis au point deux méthodes de calcul de score
global, 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 forme

d’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 propose
l’action ayant le score le plus élevé dans notre cas c’est l’action 11 (le terrain N11) qui
est choisie. Les décideurs acceptent le compromis vu que c’est l’action qui correspond
le plus à leurs préférences.
Rang 1 2 3 4 5 6 7 8 9 10 11
Action 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 11
Action 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és
par le GDSS jusqu’à ce que pour un certain tour, le seuil d’acceptation soit atteint
dans 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’atteindre
le nombre maximum de tours, cette action sera la décision de groupe. Dans le cas
contraire, la négociation à aboutit à un échec.
– Par contre, si le nombre de tours maximal n’est pas encore atteint et que l’action
proposée n’est pas accepté alors l’initiateur doit proposer une autre alternative ayant
un score élevé selon ses calculs. Nous constatons que l’action proposée est toujours
la même en ce qui concerne le calcul des scores par le rang (Table 5.7) et par le flux
net (Table 5.8).
5.5 Interprétation des échanges de messages par les agents

Les 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 est
modélisé par un agent).
La figure 5.25 illustre le processus de négociation du début jusqu’à la fin ensuite nous montrons
chaque 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éclenche
la 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éthode
PROMETHEE 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 agents
participants, effectue un scorage total des terrains et envoie le terrain qui correspond au mieux aux
préférences des décideurs, il envoie sa proposition par le biais de la primitive PROPOSE (). Les
agents 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égociation
comme montré dans la figure 28. Dans le cas où la négociation se termine par un échec, l’initiateur
notifie les décideurs de la décision d’échec.
5.6 Conclusion
Au 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 un
sé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 initiateur
ou 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 à travers
les formulaires de vote. Ensuite nous avons mis l’accent sur un module clé de la plateforme qui est
le protocole de négociation et nous l’avons déroulé à travers un scénario portant sur le choix d’un
terrain pour la construction d’une habitation. Nous avons déroulé notre exemple selon les trois
phases 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 la
négociation, ces agents sont dotés de la méthode d’analyse multicritères PROMETHEE II, traitant
une 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 de
trouver un compromis.
Conclusion Générale et
Perspectives
Face à la mondialisation de l’informatique décisionnelle et à la concurrence grandissante, la prise

de 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 la

dé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 solution
tout 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 contrainte
de 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écision
de 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 faisant
participer 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écision
qui font d’elle une activité complexe.
Le premier aspect, est celui de la multiplicité des décideurs, en effet, une décision, quand elle
est collective, est souvent délicate à prendre car elle doit satisfaire plusieurs préférences et points
de 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, la
dé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 à la
convergence.
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 bien
souvent 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’analyse
multicritères fournit des outils efficaces pour modéliser et aider à appréhender des problèmes plus
réalistes et plus complexes. Ainsi, nous avons jugé intéressant, et même incontournable, d’intégrer
dans notre plateforme une méthode d’analyse multicritères. Notre choix s’est porté sur la méthode
Prométhée II, car celle-ci permet de prioriser totalement un ensemble d’alternatives en tenant
comptes 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’objectif
de permettre à des personnes géographiquement séparées de collaborer, nous avons conçu notre
plateforme en s’appuyant sur la technologie des services web. Ces derniers tirent tout l’avantage
des 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éfinir
les GDSS et de mettre en relief leurs apports dans le domaine de la décision collective. Dans ce
chapitre nous avons, également, introduit les concepts de base structurant l’aide multicritères à la
décision. Par la suite, nous avons abordé les aspects multi acteurs (collectifs) et multicritères qui
peuvent 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 multi
agents(SMA), nous avons mis l’accent sur la négociation, mécanisme puissant pour la résolution de
conflit et la recherche de consensus satisfaisant pour un groupe d’agents. Nous avons passé en revue
les 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 les
services web. Nous avons présenté des définitions en passant par l’intérêt de cette technologie, son
architecture ainsi que son fonctionnement. Nous avons mis le point sur les deux grandes familles
existantes (SOAP et REST) avant de conclure par l’expression justifiée de notre préférence pour la
famille REST comme nous avons estimé important de citer certains systèmes et travaux utilisant
les services web.
Dans le chapitre quatre, sont présentées en détails nos principales contributions qui portent sur
la proposition :
– D’un modèle de processus de décision de groupe dans un contexte multicritères et multi

décideurs. Le système d’aide à la décision de groupe correspondant s’articule autour d’une
plateforme de communication web susceptible d’assurer la négociation entre un ensemble de
dé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 leurs
pré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ème
d’é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é sur
des formulaires et le protocole de négociation automatisé permettant de mener le groupe vers un
consensus.
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écisionnel
et une aide individuelle aux décideurs : une méthode d’analyse multicritères permettant d’aider
chaque 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 exploitant
les 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ément
selon le besoin.
Nous avons tenté d’enrichir au maximum ce chapitre pour faciliter au lecteur la compréhension
de 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égociation
ainsi que son langage.
Dans le chapitre cinq, nous avons déroulé un scénario illustratif pour mieux comprendre notre
approche décrite dans la chapitre quatre à travers un cas réel qui est le choix d’un terrain pour
une habitation parmi plusieurs terrains dans une région en Suisse.
Perspectives
Les 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éthodes
d’analyse multicritères. Ainsi, nous pourrons mettre en place un annuaire consultable et
exploitable par les acteurs de la plateforme en leur laissant le choix de sélectionner la méthode
selon 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 à des
problè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éressant
d’intégrer dans la plateforme des méthodes appropriées pour aider le coordinateur à mieux
gérer cette opération.
Troisième partie
Annexes
Annexe A
Les méthodes d’analyse

multicritères
A.1 Introduction
La 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é dans
le contexte militaire depuis les années 1960 pour deux raisons essentielles : L’amélioration de la
gestion 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 une
fonction tout en considérant un ensemble de contraintes prédéfinies. Par la suite, ces méthodes ont
investi 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écision

Les 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 de
critères, ces procédures semblent mieux permettre de se diriger vers un judicieux compromis plutôt
qu’un optimum souvent désuet.
A.2.1 Avantages des méthodes multicritères

Toute 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éma
de 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 à la
réalité.
– Utiliser une méthode d’analyse multicritère basée sur des modèles bâtis en partie sur des
hypothè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ères

Puisqu’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 a
montré 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 la
détermination de la solution (objectivement) optimale.
A.2.3 Les différentes problématiques en Aide Multicritères à la Décision

Les 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 classes
prédéfinies (ex : bonnes, moyennes, mauvaises).
3. La problématique Gamma : a pour objectif de ranger les actions de la meilleure à la

moins 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 Un choix ou une
aussi restreint que possible en vue d’un choix final procédure de sélec-
d’une seule action, ce sous ensemble contenant de tion
« meilleures » actions (optimum) ou, à défaut, des
actions « satisfaisantes ».
β Éclairer la décision par un tri résultant d’une affecta- Un tri ou une pro-
tion de chaque action à une catégorie, les catégories cédure d’affectation
étant définies à priori en fonction de normes ayant
trait à la suite à donner aux actions qu’elles sont
destinées à recevoir.
γ Éclairer la décision par un rangement obtenu en re- Un rangement ou
groupant tout ou partie (les « plus satisfaisantes ») procédure de clas-
des actions en classes d’équivalence, ces classes étant sement
ordonnées, de façon complète ou partielle, conformé-
ment aux préférences.
δ Éclairer la décision par une description, dans un lan- Une description ou
gage approprié, des actions et de leurs conséquents. une procédure cog-
nitive
Table A.1 – Les quatre problématiques de référence
A.3 Classification des méthodes multicritères

Les 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égation

Roy [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é) et

introduire toutes les performances dans une seule fonction d’agrégation ou d’utilité (le modèle de
préférence s’exprime à travers une fonction unique) en leur attribuant d’éventuels poids [20].Les
principales 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 des
résultats de ces comparaisons est établie, et c’est justement la façon de synthétiser qui différencie les
mé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éthodes
appartenant à 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érations

essai-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 solution
de départ est choisie, ensuite, nous sélectionnons un groupe de variantes relativement proche à la
solution 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 de
surclassement et pour cela nous donnons dans ce qui suit un aperçu sur les deux familles les plus
connues qui sont Electre et PROMETHEE.
A.4 La famille ELECTRE

Les 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 comparaisons
d’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 I

ELECTRE 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 sous
ensemble contenant les "meilleures" actions ou à défaut, les actions "les plus satisfaisantes". Les
critères utilisés dans cette méthode, sont francs et il n’y a pas de seuil de veto. Ceci n’autorise que
trois types de relations entre deux actions pour un critère cj donné : aiPak ou aiIak ou akPai. Le
principal 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 action
se trouve dans le noyau, mais cela ne veut pas dire que les autres actions du noyau sont placées
en deuxième et troisième position. Il s’agit plutôt des variantes qui sont difficilement comparables
avec cette meilleure action.
A.4.2 La méthode ELECTRE II

La 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 y
a presque toujours une meilleure action qui se dégage du classement obtenu. ELECTRE II a pour
objectif, en utilisant les relations d’ordre sur chacun des critères, de classer les variantes depuis
les meilleures jusqu’aux moins bonnes, tout en tolérant les exæquo [76]. Les actions ne sont pas
qualifié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 et
de 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 introduisant
une notion de respect de cette hypothèse de surclassement qui est plus floue, entre la rigidité de
ELECTRE I et le flou total d’ELECTRE III. On trouve ainsi un surclassement fort aiSFak, qui
repose 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 de
veto.
A.4.3 La méthode ELECTRE III

Tout 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, en
passant 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 à la
concordance 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 des
critères d’évaluation. ELECTRE III vise ainsi un rangement des actions exprimant en des termes
plus ou moins nuancés les positions relatives des actions en tentant de les départager en classes
d’équivalence.
A.4.4 La méthode ELECTRE IV

La 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 des
critè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’une
autre grande nouveauté : l’abandon de l’hypothèse de surclassement, qui rend inutiles les notions
de concordance et de discordance.
ELECTRE IV utilise comme ELECTRE III, des pseudo-critères (critères flous), c’est à dire des
critères associés à un seuil de préférence strict et à un seuil d’indifférence. Cette méthode admet
plusieurs versions des types de surclassement entre deux actions.
ELECTRE IV se base sur les nuances développées dans ELECTRE III mais simplifie fortement le
processus d’étude qui s’ensuit.
A.4.5 La méthode ELECTRE IS

La 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 dans
ELECTRE 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 Tri

La 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 actions
de préférences sont utilisées pour segmenter l’espace des critères en catégories : chaque catégorie
est bornée inférieurement et supérieurement par deux actions de référence et chaque action de
ré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 : elle
consiste à comparer chaque action potentielle avec les actions de référence en commençant par la
plus contraignante, respectivement la moins contraignante.
Si les deux procédures affectent l’action potentielle à la même catégorie, elle est alors parfaitement
comparable 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 de
dé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 segmentation
multicritè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ère
gé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 convient

de déterminer une relation de surclassement par le biais d’un indice de préférence (par
exemple : 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 en

compte des flux entrant et sortant.
A.5.2 Le principe de la méthode PROMETHEE

Consiste à é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) de
chaque action par rapport à toutes les autres. Le résultat de cette comparaison permet le classement
ordonné des actions
A.5.3 La méthode PROMETHEE I : rangement partiel

Les 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’autant
meilleure que son flux sortant est élevé, et que sont flux entrant est faible.
A.5.4 La méthode PROMETHEE II : rangement complet

On 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 les
différences de rangement des actions. Les deux méthodes ont le même cheminement initial, mais
leurs 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érence
est amplifiée. En effet, le pré ordre complet PROMETHEE II laisse relativement peu de place aux
indiffé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. Cette
situation peut paraître paradoxale, en particulier lorsque deux actions ont des flux nets très proches
l’un de l’autre.
A.5.6 PROMETHEE VI : Problèmes aisés ou difficiles

La 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 poids
attribués aux critères, la longueur de l’axe de décision PROMETHEE II permet déjà d’apprécier
le degré de difficulté du problème. Dans beaucoup de cas, le décideur hésite à fixer des valeurs
précises pour ces poids. Il est conscient de l’importance que les poids peuvent avoir sur le processus
dé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 de
ranger 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 plus
complexe, noté Pα,θ n. Elle consiste à choisir θ actions parmi n, le nombre θ étant fixé à l’avance,
ou à déterminer selon les cas.
A.6 Conclusion
Il 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 les
ensembles de solutions. Dans le contexte des gouvernements régionaux, le choix d’une méthode par
rapport à 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’information
disponible et des données traitées (biophysiques, socio-économiques) ; du mode de représentation
et 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 Introduction
Initialement, 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 construire
des 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 une
mê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 « distribuer
l’intelligence » entre plusieurs agents.
B.2 Acteur et agent

La 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. Le
terme 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 à son
implémentation. »
B.3 Définition des Systèmes Multi agents

Parmi 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 est
possible, à 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és
actives 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és
dans 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 agents

En 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 de
la 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 du
pathfinding (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’un
des plus classiques étant le modèle BDI (Beliefs-Desires-Intentions). Il considère d’une part
l’ensemble de croyances (Beliefs) de l’agent sur son environnement, qui sont le résultat de
ses 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) qui
peuvent ensuite se traduire directement en actions.
– Les agents doivent être dotés d’un système de communication. Plusieurs langages spécialisés
ont vu le jour à cette fin : le Knowledge Query and Manipulation Language (KQML), et plus
récemment, le standard FIPA-ACL (ACL pour Agent Communication Language) créée par
la Foundation for Intelligent Physical Agents FIPA.
B.5 Caractéristiques d’un SMA

Un 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’organisation

d’une entreprise).
B.6 Types d’agents

Il 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 ou
délibératifs et hybrides. Pour un certain nombre d’auteurs [87] [42] un agent est défini comme étant
une 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’agents

On 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és
qu’ils tentent d’accomplir. On peut cependant trouver parfois des agents dits modules qui, s’ils
ont 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 être
sé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’il
perçoit que l’environnement ne répond plus au but qui lui était affecté (le niveau du réservoir est
trop 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 SMA

Comme 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] tant
au 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 sans
aboutir à des réalisations pratiques permettant de les valider. Certains modèles sont devenus des
SMA opérationnels mais généralement les systèmes qui en résultent sont restés très dépendants de
leurs 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 plus
profondes 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 de

raisonner 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 nouvelles
inférences.
Les outils génériques relèvent de deux soucis principaux, d’une part la réalisation de classes
de base traitant d’agents, d’interactions, d’organisations, . . . , d’autre part des outils plus intégrés
prenant en charge la coordination entre les différents éléments du système [50]. Actuellement, on
observe une prolifération de plateformes cherchant à répondre à l’ensemble de ces problèmes. Ces
plateformes sont conçues [50] :
– Par rapport à un modèle d’agent particulier et orienté vers une communication entre systèmes
distribué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 pour
définir un groupe d’agents,
5. Les outils pour la conception, l’implémentation et la validation.
B.8 Conclusion
Si 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 ont
des 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ème

d’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 Group

Decision 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’un
Modè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 group
decision 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’une
CCI. 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 Management
of Natural Hazards. Thèse de Doctorat, Université de Lausanne, Faculté des géosciences et
de l’environnement, Suisse, 2016.
[8] T. BALLMER et W. BRENNENSTUHL. Speech act classification : a study in the lexical

analysis 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 de

groupe 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. Editions
SUniversity of Strathclyde, Strathclyde Business School, 1990.
[12] A. BENABBOU. Vers un système interactif d’aide multicritère à la décision de groupe en

amé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 les
agents. 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 efficient
persuasive 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 interoperable

agents. 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 systemes

multi-agents. Journal of l’AFIA, Volume(39), 1999.
[17] N. BOUDRAA. Élaboration d’un système d’aide multicritères à la décision spatiale de

groupe : Vers une négociation par argumentation. Mémoire de Magister, Université Oran1
Ahmed Benbella, Algérie, 2011.
[18] M. BRATMAN. Intention, plans, and practical reason. Editions Center for the Study of
Language 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 vue
d’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 cours

et 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 et

applications. 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 of

Organisation 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 decision
making 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 of
Decision 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 channels
on 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 Sciences
et 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 support
systems. 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 of

AAMAS’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 organizations
in multi-agent systems. In proceedings of ICMAS’1998 ; Paris, France, 1998.
[42] J. FERBER et G. WEISS. Multi-agent systems : an introduction to distributed artificial

intelligence. Editions Addison-Wesley, 1999.
[43] A. FERNANDEZ. Les nouveaux tableaux de bord des managers Le projet décisionnel dans
sa 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-based

software architectures. Editions Irvine, USA : University of California, Irvine, 2000.
[46] C. FLOCH. Cognitive Modeling of interactions during a negotiation process. In proceedings

of ICEIS’2008 ; Barcelone, Espagne, 2008.
[47] R. B. GALLUPE, A. R. DENNIS, W. H.COOPER, J. S. VALACICH, L. M. BASTIANUTTI
et J. F. NUNAMAKER Jr. Electronic Brainstorming and Group Size. Journal of Academy
of Management, Volume(35)2, pp 350-369, 1992.
[48] W.F. GLUECK. Business policy : Strategy formation and management action. Editions
McGraw-Hill, 1972.
[49] A. GROULS. Agents et systèmes multi-agents : vers une synthèse de ces concepts. Mémoire
de Maitrise, Université du Québec, Montréal, 2013.
[50] Z. GUESSOUM et M. OCCELLO. Environnements de développement. Dans Principes et

architectures 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égociation

automatisé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 une
approche 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 for

Industrial Diagnosis. Journal of INFOCOMP, Volume(10)3, pp 12-14, 2011.
[54] D. HAMDADOU et K. BOUAMRANE. A spatial group decision support system : Coupling

negotiation 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, Office

National des Publications (OPU), ISBN 978-9947-0-4724-8, 2017.
[56] S. HASSAS et M. MORGE. Dynamiques, Couplages et Visions Intégratives des Systèmes

Multi-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. Editions

South-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émoire
de Master, Université de Kairouan Tunisie, 2012.
[62] I. IGOULALENE L. BENYOUCEF et M.K. TIWARI. Novel fuzzy hybrid multi-criteria

group decision making approaches for the strategic supplier selection problem. Journal of
Expert 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 SIG
et de méthodes d’analyse multicritères. Thèse de Doctorat, École polytechnique fédérale de
Lausanne, 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 enhance
performance. 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 organisations

productives : approche multi-agents. Thèse de Doctorat, Université Jean Monnet et École
Nationale Supérieure des Mines de Saint-Étienne, France, 1999.
[67] D. KAHNEMANN, P. SLOVIC et A. TVERSKY. Jugdments under uncertainty : Heuristics

and biases. Editions Cambridge University Press, 1982.
[68] F. LABORIE. Le concept de salle de décision collective et son application aux processus
complexes 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 work
systems ?. In proceedings of ACM conference on Computer-supported cooperative work, Los
Angeles, CA, USA, 1990.
[74] G. M. MARAKAS. Decision support system in the twenty first century. Editions Prentice
Hall, 1999.
[75] A. C. MARIN. Une approche orientée domaine pour la composition de services. Thèse de
Doctorat, 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 presses
polytechniques, 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 an

assumption-based argumentation decision support system. Journal of Group Decision and
Negotiation, 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 Intelligence

GMP 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 Springer
Science & Business Media, 1996.
[86] Jr. NASH et F. JOHN. The bargaining problem. Journal of Econometrica : Journal of the
Econometric Society, Volume(18)2, pp 155-162, 1950.
[87] G. MP. O’HARE, N. R. JENNINGS et N. JENNINGS. Foundations of distributed artificial

intelligence. 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 Automated
Negotiations : Theories, Models, and Software Competitions, Volume(435), pp 125-141, 2013.
[89] S. OUFELLA, D. HAMDADOU et K. BOUAMRANE. Conception d’un système interactif

d’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 gss

facilitation and participation : Field action research. In proceedings of the 32nd Annual
Hawaii 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), pp
57-75, 1968.
[98] B. ROY Problems and methods with multiple objective functions. Journal of Mathematical
programming, Volume(1)1, pp 239-266, 1971.
[99] B. ROY, J. C. HUGONNARD. Ranking of suburban line extension projects on the Paris
metro 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 Management

Public, 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 perspective

de 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 System
Sciences ; Hawaii, 1998.
[109] S. S. SIAN. Adaptation based on cooperative learning in multi-agent systems. Journal of

Decentralized AI, Volume(2), pp 257-272, 1991.
[110] H. SIMOS. Centralization vs. decentralization in organizing the controller’s department : A

research study and report. Editions Controllership Foundation, 1954.
[111] H. SIMOS. The new science of management decision. Editions prentice-hall. Englewood
Cliffs, 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, pp
126-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éthode
PROMETHEE. 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 de

Doctorat, École Polytechnique Fédérale De Lausanne, Suisse, 2000.
[118] D. TRENTESEAUX. Conception d’un système de pilotage distribuè, supervisè et multicritére

pour 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 Conference
on Systems Sciences, Hawaii ; 1992.
[120] M. H. VERRONS. GeNCA : un modèle général de négociation de contrats entre agents. Thèse
de 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é de
Bruxelles, 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 of

The 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é en

2018.
[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.
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
WEBOGRAPHIE
International Journal of E-Services and Mobile Applications
Volume 10 • Issue 3 • July-September 2018
A Communication Platform for

Group Decision Support System:
Based Web Services and Multicriteria Method
Mounya 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
In a group decision support system, the various decision-makers have their own information, constrains,
decision strategies, preferences, and objectives which are generally not shared or communicated. This
implies that the group decision process is distributed between the different entities implicated and
impacted by various group members’ characteristics. Solution to this problem is to find a decision
that would be acceptable to all the decision-makers, following the necessity of a negotiation process
that allows the elaboration of a common agreement for a group that faces a conflict on the decision
to take. In the current study, the authors propose to establish a communication platform for a group
decision support system (GDSS) based on web services, incorporating a multicriteria analysis methods
and a negotiation protocol.
Keywords
Decision Support, Group Decision Support System (GDSS), Multicriteria Analysis, Negotiation Protocol,
Promethee II, Web Services
1. INTRODUCTION
Decision-making refers to the selection of the best solution among several possibilities, which requires
evaluating these possibilities regarding to several criteria. The case of the single criteria is not useful
in real-world settings. Multicriteria Decision Support aims to handle this issue and allows decision-
makers to create a hierarchical representation of a set of solutions based on their importance according
to the different criteria. Due to their efficiency, multicriteria decision support methods are often
integrated the current decision support systems. However, these systems must adapt to the reality of
group decision making, and extending to what is called as Group Decision Support Systems (GDSS).
Collegiality in decision-making may be explicitly required by the type of problem being addressed
or because of a structural choice. In both cases, the decisional process multi-makers have to result to
a decision that has consensus within the group of decision-makers. Therefore, a GDSS has to provide
mechanisms to facilitate the confrontation of views and allows guiding a group towards a solution
DOI: 10.4018/IJESMA.2018070102

Copyright © 2018, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.

19
International Journal of E-Services and Mobile Applications
Volume 10 • Issue 3 • July-September 2018
that is mutually acceptable. Moreover, collaborative work in general has evolved considerably by
exploiting all the advantages of new technologies. A group should no longer be gathered in one place
to work. GDSS has to be aligned to this logic and allow geographically dispersed decision-makers
to handle their tasks.
In order to respond to all these requirements, the authors propose a negotiation protocol to manage
the conflicts between decision-makers which is integrated into with a multicriteria method. The
authors’ contribution through this study consists of designing and implementing a communication
platform that allow geographically disperse decision-makers to participate and resolve a decision
problem. This platform provides also the interoperability required for future integration with other
systems and applications, justifying the web services use. In order to achieve this goal, web-services
technology is used to implement the proposed platform.
Section 2, present a brief description of the major work on group decision support and related
issues. Section 3 focuses on the authors’ contribution. Section 4 is dedicated to provide a detailed
description of the proposed system, which includes the negotiation protocol and the multicriteria
method used (Promethee II in this case). Section 5 defines the web services. Section 6 is dedicated
to a real case study. Finally, section 7 concludes the discussion by highlighting the limitations of the
proposed system and some considerations for future research.
2. RELATED WORK
In the domain of decision support, there is a variety of systems designed to treat different types of
decision-making. However, the decision support is grouped into two broad categories: (i) The single-
actor decision support - A decision-maker forms an opinion based on the information available to
him (not the expertise), as well as his personal orientations (values), and (ii) The multi-actor decision
support - Several actors decide with together on an issue, with personal views often divergent compared
to others, which often requires the negotiation process.
In the context of single-actor decision support, several decision support systems in TP (Territory
Planning) have caught attention. Joering (1997) propose system MEDUSAT for locating the site
of a waste treatment plant in Tunisia. MEDUSAT combines a GIS tool allowing the creation of
homogenous areas determined from spatial data and common land (constituting a similarity index);
these areas constitute a set of possible solutions. Bensaid et al. (2007) use Multicriteria analysis as
a tool for decision making for spatial localization of areas under heavy human pressure. In the same
area, Čančer (2012) introduces the use of the 5Ws & H technique, which is the creative problem-
solving technique based on who, what, when, where, why and how questions, for the establishing of
the criteria weights in multi-criteria decision-making. A case study was presented at the University
of Naama, Algeria in the same work. Various decision support systems rich in spatial tools and
multicriteria analysis methods have been developed for management and decision making in territorial
problems Hamadouche (2011). All these systems integrate in various levels multicriteria analysis tools
coupled with GIS, but they consider the criteria as independent and unable to model any interaction
between them.
Therefore, traditional decisional models adapted to the single decision-maker case are not
consistent with the organizational reality. Group decision support, or multi-participant decision,
treats processes, in which multiple decision-makers are involved. According to Smoliar and Sprague
(2002), decision processes in organizations usually involve several actors interacting with each other.
Indeed, Group Decision Support has been the subject of several research works. The work presented
by the Hemaissia (2008) has been conducted in order to provide a solution to group decision problems
encountered in crisis management applications, especially the distributed allocation problems. In
this optic, the authors have defined multidimensional and multilateral negotiation protocols based
on cooperation. Morge & Mancarella (2014) proposed a multi-attribute qualitative decision support
tool called MARGO; it is based on an abstract approach for cancellable argumentation of Dung
20
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 Study

Hector 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 Services

Rui 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
User-Centric Identity, Trust and Privacy
Jean-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 India
Rajat 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
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.

TH5010 PDF

Transféré par

Droits d'auteur :

Formats disponibles

TH5010 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TH5010 PDF

Transféré par

Droits d'auteur :

Formats disponibles

THÈSE

En vue de l’obtention du diplôme de

Présentée par : Mounya ABDELHADI

Élaboration d’un modèle de négociation

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

M.Mohammed Fayçal KHELFI Pr, Université Oran1 Ahmed BENBELLA Président

Dans un système d’aide à la décision de groupe, les différents décideurs disposent

noindent Mots clés Aide à la décision, Système d’aide à la décision de groupe

Key-words Decision Support, Group Decision Support System (GDSS), Multicri-

« Étudiez comme si vous deviez vivre toujours,

Liste des figures X

Liste des tableaux XII

Liste des abréviations XIII

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

2 La négociation dans les Systèmes Multi Agents 27

3 Les services web 43

5 Expérimentation et résultats obtenus 100

Conclusion Générale et Perspectives 122

III Annexes 126

A.4.1 La méthode ELECTRE I . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

B Les Systèmes Multi Agents 135

1.1 Processus de décision de Simon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Les différents éléments d’une négociation et leurs structures . . . . . . . . . . . . . 34

3.1 Acteurs et rôles dans l’architecture Orientée Service . . . . . . . . . . . . . . . . . 45

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

5.1 Echange client web/ Serveur web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

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

1.1 Les différents niveaux de la décision . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Les différents niveaux de décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.1 Exemple de service web : Gmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.1 Identification des critères . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

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

QCM Questionnaire à Choix Multiples

– Recherche d’informations pertinentes.

– Organisation des informations.

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

– Activation ordonnée de connaissances.

– Représentations spatiales et ou temporelles.

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]

Le croisement de certaines disciplines de l’AD entre elles représente un obstacle, et en particu-

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

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

– Comment réaliser un système d’aide à la décision de groupe générique interopérable et faci-

– Compréhension collective du problème,

– Génération des solutions,

– L’échange de messages entre participants.

– L’échange et archivage de documents.

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

– 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.

La deuxième partie (Contributions) décrit notre contribution en deux chapitres la modéli-

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

– Chapitre 1 : L’aide à la décision de groupe (SADG)

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

– Chapitre 3 : Les services web

– Chapitre 4 : La modélisation de l’approche proposée

– La proposition d’un modèle de processus de décision de groupe dans un contexte mul-

– Chapitre 5 : l’expérimentation et résultats obtenus