Thème de thèse: Modèles multi agents pour la prise de décision … · 2015-05-05 · Nowadays...

Table des matières

Thèse

Thèse de doctorat en Informatique

Présentée par :

NACHET Bakhta

Option : Informatique

Thème :

Modèle multi-agents pour la

conception de systèmes d’aide à la

décision collective

Devant le jury :

Mr BELDJILALI B., Professeur, U. Oran es-senia Président

Mr ADLA A., Professeur, U. Oran es-senia Directeur de thèse

Mr BENYETTOU A., Professeur, USTO Examinateur

Mr BOUAMRANE K., Professeur, U. Oran es-senia Examinateur

Mr LASKRI M.T., Professeur, U. Annaba Examinateur

Mr BELKADI K., Maitre de Conférences A, USTO Examinateur

Année 2013-2014

Table des matières

ii

Résumé Aujourd’hui les organisations sont devenues de plus en plus complexes ce qui a compliqué la tâche de prise de

décisions. En effet, ces situations exigent une intervention rapide et efficace d’experts qui ne sont pas forcément

disponibles.

Dans ce travail, nous nous intéressons aux décisions complexes au sens de [SIMO 77] et qui doivent être prises

dans un cadre collectif. Nous proposons de concevoir et de développer un Système d’aide à la Décision de

Groupe (GDSS) où un groupe de décideurs (participants),qui peuvent ne pas se trouver dans un même endroit,

sont guidés par un facilitateur qui énonce le problème de décision et dirige une session de prise de décision

selon le processus d’aide à la décision de groupe défini dans[ADLA 10]. Les performances du groupe de

décideurs ainsi que la qualité de la décision qui sera choisie dépendent de la qualité des échanges

d’informations, de connaissances et de points de vue au sein du groupe. Pour cela, le système doit garantir la

gestion des espaces privés et publiques des participants. Il doit aussi garantir le déroulement efficace et complet

du processus suivi.

Par ailleurs, les systèmes multi-agents (SMA) sont des systèmes qui se basent sur le partage des connaissances

et des compétences sur plusieurs agents lesquels doivent s’organiser et coordonner leurs actions afin de réaliser

l’objectif global du système. Ils sont fondés sur des modèles d’interaction complexes qui se traduisent par des

stratégies de résolution comme la coopération, la coordination, la négociation. Ces systèmes sont de plus en

plus utilisés dans la résolution de problèmes complexes. Leur principe de modularité permet de diminuer la

complexité de conception du système global et d’améliorer sa maintenance.

Nous adoptons une approche de modélisation par les agents pour la conception et le développement d’un

système d’aide à la décision collaborative. De plus, chaque participant est assisté d’un système d’aide à la

décision coopératif, modélisé également par les agents.

Mots clés : Aide à la décision, SIAD, Prise de décision collaborative, SIAD coopératif, GDSS, SMA.

Abstract

Nowadays organizations become more and more complex and decision making more complicated. In fact, these

situations require quick and efficient intervention of experts who are not necessarily usually available.

In this work, we are interested in complex decisions as defined in [SIMO 77] which must be taken in collectively.

We propose to design and develop a Group Decision Support System (GDSS) where a group of decision-makers

(participants) who could be geographically dispersed, are guided by a facilitator who words the decision

problem and manage decision-making session according to the group decision process defined in [ADLA

10].The performances of the group of decision-makers as well as the quality of the chosen decision depend on

the quality of information exchanges of information, knowledge and points of view among the group. To this end,

the system must manage participants’ public and private spaces. It must also guarantee the efficient and full

execution of followed process.

Moreover, Multi-Agents Systems (SMA) are systems are based on the distribution of knowledge and competences

over several agents who must be organized and coordinate their actions to realize the whole objective of the

system. They are based on complex models of interaction which are expressed in terms of solving strategies as

collaboration, coordination, and negotiation. These systems are more and more used in the complex problems

solving. Their modularity principle allows reducing the design general system and evolving its maintenance.

We adopt a modelling approach based on agents to design and develop collaborative decision support system.

Besides, every participant is supported by a cooperative decision support system, modelled as well with the

agents.

Keywords : Decision Support, DSS, Collaborative Decision making, Cooperative DSS, GDSS, MAS.

Table des matières

iii

Remerciements

Tout d‟abord je remercie tout particulièrement Monsieur Adla Abdelkader de m‟avoir proposé

ce thème de recherche, de m‟avoir guidé dans l‟élaboration de ce travail à travers la direction

de ma thèse ainsi que pour tous ses précieux conseils. Je tiens à lui exprimer ma profonde

gratitude.

Aussi, je souhaite exprimer toute ma reconnaissance à Monsieur Beldjilali Bouziane

Professeur au département d‟informatique à l‟université d‟Oran pour l‟honneur qu‟il me fait

en acceptant de présider le jury de ma soutenance.

Mes vifs remerciements vont également vers tous les membres du jury :

Monsieur Benyettou Abdelkader Professeur au département d‟informatique à

l‟université USTO,

Monsieur Bouamrane Karim Professeur au département d‟informatique à l‟université

d‟Oran,

Monsieur Laskri Mohamed Tayeb Professeur au département d‟informatique à

l‟université de Annaba,

Monsieur Belkadi Khaled Professeur au département d‟informatique à l‟université

USTO,

qui m‟ont honoré par leurs acceptations de bien vouloir consacrer de leur temps à évaluer ce

modeste travail et à participer à ce jury.

Table des matières

iv

Table des matières

Introduction générale………………………………………………………………. 1

Chapitre 1. Aide à la décision……………………………………………………... 5

1.1 Introduction ……………………………………………………………………….… 6

1.2 Décision ……………………………………………………………………………… 7

1.2.1 Définition d‟une décision ……………………………………………………… 7

1.2.2 Typologie des décisions ……………………………………………………...... 7

1.2.2.1 Le niveau de structuration ……...………………………………………….. 7

1.2.2.2 Niveau d‟activité managériale ……………………………………………… 9

1.2.3 Les modèle de décision ………………………………………………………... 9

1.2.3.1 Les modèles normatifs ……………………………………………………… 9

1.2.3.2 Les modèles descriptifs …………………………………………………….. 10

1.2.4 Processus de décision ………………………………………………………….. 10

1.2.4.1 Modélisation du processus décisionnel …………………………………….. 10

1.2.4.2 Éléments constituants le modèle de décision ……………………………… 11

1.3 Système Interactif d‟Aide à la Décision: (SIAD) ……………………………………. 12

1.3.1 Définitions ……………………………………………………………………... 12

1.3.1.1 Aide à la décision…………………………………………………………… 12

1.3.1.2 "Interactif"………………………………………………………………….. 12

1.3.1.3 SIAD ………………………………………………………………………. 12

1.3.2 Fonctionnalités des SIAD ……………………………………………………… 14

1.3.3 Architectures générales d‟un SIAD …………………………………………… 15

1.3.4 Typologies des Systèmes d'aide à la décision ………………………………..... 16

1.3.4.1 Classification fonction de la quantité d‟informations manipulées…………. 17

1.3.4.2 Classification en fonction du niveau de décision ………………………….. 17

1.3.4.3 Classification en fonction de l'envergure de la décision …………………… 17

1.3.4.4 Classification en fonction du niveau conceptuel du système………………..18

1.3.5. Systèmes d‟aide à la décision coopératifs …………………………………….. 18

1.4 La prise de décision en groupe……………………………………………………….. 20

1.4.1 Définitions ……………………………………………………………………... 20

1.4.2 Le groupe ………………………………………………………………………. 21

Table des matières

v

1.4.3 Les techniques de prise de décision de groupe ………………………………… 22

1.4.3.1 Le brainstorming ………………………………………………………….... 22

1.4.3.2 Technique de prise de décision consensuelle ……………………………… 23

1.4.3.3 Technique NGT (Nominal Group technique) ……………………………… 23

1.4.3.4 La méthode Delphi ……………………………………………………….. 23

1.4.3.5 La méthode « Policy Delphi » ……………………………….…………… 23

1.4.4 Le processus de prise de décision ……………………………………………… 23

1.4.4.1 La phase de Pré-décision « Pre-meeting » ………………………………… 24

1.4.4.2 La phase de Décision « During meeting » …………………………………. 25

1.4.4.2.1 Génération des solutions alternatives ………………………………... 25

1.4.4.2.2 Organisation des alternatives ………………………………………… 25

1.4.4.2.3 Évaluation des alternatives ………………………………………….. 25

1.4.4. 2.4 Décision/ Choix d‟une solution …………………………………….. 26

1.4.4.3 Phase de post-décision « Post-meeting » ………………………………….. 26

1.4.5 Le GDSS (Group Decision Support System)…………………………………. 26

1.4.5.1 Définition ………………………………………………………………….. 26

1.4.5.2 Typologies des GDSS …………………………………………………….. 28

1.4.5.3 Les GDSS distribués ………………………………………………………. 28

1.4.5.3.1 Architectures des GDSS distribués ……………………………..…… 28

1.4.5.3.2 Les GDSS basés sur le Web …………………………………………. 31

1.4.5.4 Aide à la facilitation de la prise de décision collective ……………….. 31

1.4.6 Outils d‟aide à la prise de décision de groupe ………………………………… 31

1.5 Conclusion …………………………………………………………………………… 33

Chapitre 2. Les systèmes Multi-Agents ……………………………………….. 35

2.1 Introduction ………………………………………………………………………….. 36

2.2 Pourquoi s‟intéresser aux systèmes multi-agents ? ………………………………….. 36

2.3 Le concept d‟agent …………………………………………………………………... 37

2.3.1 Définitions d‟agent ………..…………………………………………………… 37

2.3.2 Les Typologies des agents ……………………………………………….…….. 38

2.3.2.1 Agents cognitifs …………………………………………………………….. 39

2.3.2.1.1 Les caractéristiques d‟un agent intelligent ….……………………….. 39

2.3.2.2 Agents réactifs ……………………………………………………………... 41

2.3.2.3 Les agents BDI (Beliefs, Desirs, Intentions) ……………………………..... 42

2.3.2.4 Agents hybrides ou mixtes ………………………………………………… 43

2.3.2.4.1 Architecture à organisation modulaire ………………………………. 43

2.3.2.4.2 Le modèle d‟architecture d'agents DIMA (Développement

et Implémentation de systèmes Multi-Agents)…………………... 44

2.3.3 Structure d‟un agent ………………………………………………………..… 44

2.4 Les systèmes multi agents ……………………………………………………………. 45

2.4.1 Définitions ……………………………………………………………….…….. 45

2.4.2 L‟environnement ……………………………………………………………..... 46

2.4.3 Les caractéristiques d‟un système multi-agents ……………………………….. 47

2.5 L‟interaction …………………………………………………………………………. 47

Table des matières

vi

2.5.1 La Communication …………………………………………………………….. 48

2.5.1.1 La communication indirecte ……………………………………………….. 48

2.5.1.2 La communication directe …………………………………………………. 49

2.5.1.2.1 Les langages de communication multi-agents ………………………... 50

2.5.2 La coopération ………………………………………………………………….. 51

2.5.3 La coordination ……………………………………………………………….... 51

2.5.4 L‟organisation …………………………………………………………………... 52 2.5.5 La négociation ………………………………………………………………………….. 53

2.6 L‟émergence ………………………………………………………………………… 54

2.7 Typologies des systèmes multi-agents …………………………………………….... 56

2.7.1 Système multi-agents ouvert/fermé ………………………………………..….. 56

2.7.2 Système multi-agents homogène/hétérogène ………………………………….. 57

2.8 Méthodes de conception de systèmes multi-agents …………………………………. 57

2.8.1 AAII ……………………………………………………………………………. 57

2.8.2 DESIRE ……………………………………………………………………….. 57

2.8.3 Aalaadin ……………………………………..………………………………… 58

2.8.4 Cassiopée ……………………………………………………………………….. 58

2.8.5 MAS-CommonKADS ………………………………………………………….. 59

2.8.6 GAIA …………………………………………………………………………… 59

2.8.7 Voyelles ………………………………………………………………………… 59

2.8.8 ADELFE ….......................................................................................................... 60

2.9 Les plates formes de développement des systèmes multi-agents ……………………. 60

2.9.1 Madkit ………………………………………………………………………….. 61

2.9.2 AgentBuilder…………………………………………………………………… 61

2.9.3 Jade …………………………………………………………………………….. 62

2.10 Conclusion ………………………………………………………………………….. 63

Chapitre 3. L’Aide à la Décision Collaborative et

les Systèmes Multi-Agents ……………………….. 64

3.1 Introduction …………………………………………………………………………..65

3.2 Les domaines d‟applications des systèmes multi-agents……………………………... 65

3.3 Distribution des systèmes multi-agents………………………………………………. 67

3.3.1 Les Systèmes multi-agents physiquement distribués…………………………... 67

3.3.2 Les problèmes posés par la distribution physique

des systèmes multi-agents………………………………………… 68

3.4 Application des SMA dans le domaine de l'aide à la décision collaborative………… 68 3.4.1 Apports des systèmes multi-agents au domaine

de l‟d‟aide à la décision collaborative…………………. 69

3.4.2 Topologies des systèmes d‟aide à la décision collaborative à base d‟agents….. 70

3.5 Quelques systèmes d‟aide à la décision à base d‟agents …………………………….. 70

Table des matières

vii

3.5.1 Systèmes de simulation………………………………………………………… 71

3.5.1.1 Modélisation d‟une chaîne logistique distribuée…………………………… 71

3.5.1.2 SMAG : Aide à la décision appliquée à la gestion de l‟eau………………... 73

3.5.2 Systèmes de résolution de problèmes................................................................... 76

3.5.2.1 Un système multi-agent pour l‟aide à la décision d‟un Collectif …………... 76

3.5.2.2 Aide à la décision et à la négociation en aménagement du territoire……….. 78

3.5.2.3 ANYMAS : Aide à la décision en temps réel………………………………. 80

3.6 Conclusion……………………………………………………………………………. 82

Chapitre 4. Proposition d’une architecture

d’un système d’aide à la décision Collaborative ……… 83

4.1 Introduction …………………………………………………………………………. 84

4.2 Spécification du GDSS……………………………………………………………… 84

4.3 Modélisation du GDSS à base d‟agents ……………………………………………. 87

4.3.1 Méthodologie adoptée…………………………………………………………. 87

4.3.2 Conception préliminaire ……………………………………………………….. 88

4.3.2.1 Les agents ………………………………………………………………… 88

4.3.2.2 Les cas d‟utilisation ……………………………………………………….. 89

4.3.2.2.1 Côté participant ………………………………………………….... 90

4.3.2.2.2 Côté facilitateur ………………………………………………….... 91

4.3.2.2.3 Côté administration ………………………………………………... 92

4.3.2.3 Architecture générale su SMA …………………………………………….. 92

4.3.3 Conception détaillée ……………………………………… …………….......... 93

4.3.3.1 Les interactions ……………………………………………………………. 93

4.3.3.1.1 Les chronogrammes ………………………………………………. 94

4.3.3.1.2 Les protocoles d‟interaction ……………………………………..... 98

4.3.3.2 Organisation ……………………………………………………………….. 100

4.3.3.2.1 Structure organisationnelle du facilitateur …………………………. 100

4.3.3.2.2 Structure organisationnelle du participant …………………………. 101

4.3.3.2.3 L‟organisation générale au sein du SMA ………………………….. 101

4.3.3.3 Les agents …………………………………………………………..……… 102

4.3.3.4 L‟environnement …………………………………………………………... 103

4.3.3.4.1 Présentation topographique du système …………………………… 103

4.3.3.4.2 Les objets passifs ……………………………………………........... 103

4.3.4 Les diagrammes de comportement …………………………………………….. 105

4.4 Modélisation du SIAD coopératif à base d‟agents ………………………………….. 105

4.4.1 Spécification du SIAD coopératif……………………………………………… 105

4.4.1.1 Architecture ……………………………………………………………….. 105

4.4.1.2 Fonctionnement …………………………………………………………… 106

4.4.2 Approche Multi-Agents …………………..…………………………………… 107

4.4.2.1 Architecture Générale du Système ……………………………………….... 107

4.4.2.2 Le Système Multi-Agents Réactif (SMAR) ...……………………………… 109

4.4.2.2.1 Architecture du SMAR…………………………………………….. 109

4.4.2.2.1.1 Les agents…………………………………………………….. 110

Table des matières

viii

4.4.2.2.1.2 L‟environnement……………………………………………… 110

4.4.2.2.1.3 Le contrôle……………………………………………………. 110

4.4.2.2.2 Fonctionnement du SMAR………………………………………… 111

4.4.2.3 L‟agent observateur …………………………………………………………112

4.4.2.4 Le Système Multi-Agents Cognitif (SMAC)……………………………….. 112

4.4.2.4.1 L‟architecture du SMAC……………………………………………113

4.4.2.4.1.1 L‟environnement……………………………………………… 113

4.4.2.4.1.2 L‟organisation…………………………………………………114

4.4.2.4.1.3 Les agents du SMAC…………………………………………. 114

4.4.2.4.1.4 Fonctionnement et comportement des agents………………… 116

4.5 Conclusion……………………………………………………………………………. 120

Chapitre 5. Application …………………………………………………………… 121

5.1 Présentation de l‟application ………………………………………………………… 122

5.2 Environnement de programmation ……...…………………………………………… 122

5.3 Conclusion ……… …………………………………………………………………... 127

Conclusion générale et perspectives…………………………………………….. 128

Bibliographie ………………………………………………………………………..... 131

Annexes………………………………………………………………………………… 140

Annexe 1 …………………………………………………………………………………. 141

Annexe 2 …………………………………………………………………………………. 150

Liste des figures

ix

Liste des figures

Figure 1.1 Modélisation du processus décisionnel IDC de Simon [SIM 77] .............. 11

Figure 1.2 Structure d‟un SIAD selon Sprague et Carlson [SPRA 82] ...................... 15

Figure 1.3 Structure d‟un SIAD selon Maracas [MARA 03] …................................. 16

Figure 1.4 Modèle du processus de prise de décision collective ................................. 24

Figure 1.5 Architecture d‟un GDSS centralisé ............................................................ 39

Figure 1.6 Architecture d‟un GDSS décentralisé……………………………………. 30

Figure 1.7 Architecture d‟un GDSS hybride .............................................................. 30

Figure 2.1 Fonctionnement d‟un agent selon [DEMA 96] ....................................... 39

Figure 2.2 Architecture réactive de subsomption

(Robots explorateurs de Mars [STEE 89] ................................................ 41

Figure 2.3 Architecture d‟un agent BDI [WOOL 99] ………………………………. 42

Figure 2.4 Architecture d‟un agent hybride [BOIS 96] …………............………….. 43

Figure 2.5 Architecture d‟un agent hybride de DIMA [GUES 02] ............................ 44

Figure 2.6 Représentation d‟un système Multi-agents selon Ferber [FERB 95] ……. 46

Figure 2.7 Communication par tableau noir ................................................................ 48

Figure 2.8 Communication par envoi de messages ..................................................... 49

Figure 3.1 Structure multi-agents d‟un NEV ……………………………………….. 72

Figure 3.2 Architecture fonctionnelle de SMAC ..………………………………….. 74

Figure 4.1 Architecture d‟un système d‟aide à la décision

de groupe distribué [ADLA 07]………………………………………….. 85

Figure 4.2 Modèle du processus de prise de décision collective [ADLA 07]……….. 86

Figure 4.3 Architecture générale du système multi agents d‟aide à la décision

collaborative…........................................................................................... 92

Figure 4.4 Chronogramme sollicitation des participants ……………………………. 94

Figure 4.5 Chronogramme du processus de démarrage d‟aide à la décision ………... 95

Figure 4.6 Chronogramme de génération des solutions ...................................……… 95

Figure 4.7 Chronogramme de l‟organisation des alternatives ..................................... 96

Figure 4.8 Chronogramme de l‟évaluation des alternatives ........................................ 96

Figure 4.9 Chronogramme de la décision .................................................................... 97

Liste des figures

x

Figure 4.10 Chronogramme de la post décision ............................................................ 97

Figure 4.11 Structure organisationnelle du facilitateur ................................................. 101

Figure 4.12 Structure organisationnelle du participant................................................... 101

Figure 4.13 Cycle de base de fonctionnement d‟un agent cognitif .............................. 102

Figure 4.14 Architecture générale d‟un agent ............................................................... 105

Figure 4.15 Architecture d‟un SIAD coopératif selon [ADLA 07] ………………….. 106

Figure 4.16 Architecture globale du SIAD coopératif à base d‟agents ........................ 108

Figure 4.17 Processus de résolution du problème d‟aide à la décision ………………. 109

Figure 4.18 Architecture générale du SMAC ………………………………………… 110

Figure 4.19 Organigramme de fonctionnement du SMAR …………………………. 111

Figure 4.20 La représentation UML du modèle AGR [TRAN 08] ............................... 113

Figure 4.21 Structure organisationnelle du SMAC selon le modèle AGR .................... 114

Figure 4.22 Architecture générale du Système Multi Agents Cognitif (SMAC) .......... 115

Figure 4.23 Diagramme d‟activité des agents du groupe de coopération ...................... 118

Figure 4.24 Diagramme d‟activité des agents du groupe exécutant ............................. 119

Figure 5.1 Architecture générale de l‟application ………………………………....... 123

Figure 5.2 Consultation par le facilitateur de l‟état de connexion des participants...... 123

Figure 5.3 Invitation du participant à participer à la réunion ....................................... 124

Figure 5.4 Envoi par le facilitateur des paramètres du problème ................................ 124

Figure 5.5 Génération des solutions par le participant.................................................. 125

Figure 5.6 Epuration des solutions et choix du type d‟évaluation .............................. 125

Figure 5.7 Evaluation des alternatives par le participant.............................................. 126

Figure 5.8 Rapport de fin de réunion .......................................................................... 126

Figure 5.9 Les interactions entre agents délivrées par l‟agent sniffer ......................... 177

Annexe 2 :

Figure 1 Le graphe de tâches/méthodes de l‟exemple considéré ............................. 153

Figure 2 L‟espace des solutions généré à partir de l‟exemple …………………...... 155

Liste des tableaux

xi

Liste des tableaux

Tableau 1.1 Méthodes et techniques de prise de décision [ESPI 09] ................. 8

Tableau 1.2 Quatre combinaisons des systèmes d‟aide à la décision

de groupe [GRUD 94] .................................................................. 27

Tableau 4.1 Les relations entre les agents de la structure

organisationnelle du facilitateur ..................................................... 101

Tableau 4.2 Les relations entre les agents de la structure

organisationnelle du participant ...................................................... 101

Tableau 4.3 Les relations entre les agents des deux structures

Organisationnelles .......................................................................... 102

Introduction générale

1


La prise de décision est un acte qui est souvent pratiqué par les humains. En effet, nous

sommes tous confrontés à des situations dans lesquelles une prise de décision est

nécessaire. Mais, il est clair que souvent nos décisions ne nécessitent pas des processus

de réflexions complexes car, généralement, il suffit d‟une heuristique, d‟une expérience

passée ou parfois même d‟une intuition pour décider. Mais dans d‟autres situations, la

prise de décision est plus difficile. Cela est du à plusieurs facteurs :

une complexité structurelle des décisions ;

un grand nombre d‟alternatives du à la complexité du problème ;

l‟impact de la décision prise peut être important, il peut être d‟ordre

économique, politique, organisationnel, environnemental, etc. ;

la nécessité de la rapidité dans la prise de décision, c‟est le cas des urgences

médicales, ou militaires, ou encore le diagnostic des installations industrielles.

Les Systèmes Informatiques d‟Aide à la Décision (SIAD) ont été développés afin

d‟assister le décideur dans sa tâche. Les SIAD ou bien en anglais Decision Support

Systems (DSS) ont été d‟abord introduits par l‟école anglosaxone. L‟un des premiers

auteurs à les avoir cités est Scott Morton [MORT 71], il a introduit la notion de

Systèmes de Décision et de Gestion (Management Decision Systems). Les SIAD

désignent aussi les Systèmes Interactifs d‟Aide à la Décision, car l‟interaction avec le

décideur y occupe une place prépondérante. Les SIAD ont pour but de procurer une

aide au décideur plutôt que de le remplacer. Plusieurs chercheurs se sont intéressés à ce

domaine [SPRA 82] [TURB 95] [MARA 03] ce qui a conduit à des SIAD d‟abord

interactifs puis intelligents.

Comme les SIAD sont dédiés aux tâches semi structurées, l‟interaction est d‟un apport

considérable car elle se base sur l‟implication de l‟humain conjointement avec le

traitement des informations par l‟ordinateur, contrairement aux situations structurées

où les solutions et procédures sont complètement automatisables.


2

Pour rendre ces systèmes intelligents, il a été introduit une ou des bases de

connaissances avec des moteurs d‟inférence. L‟intelligence peut concerner le

raisonnement dans la prise de décision, ou bien dans l‟interaction entre l‟homme et la

machine. De ce fait, les machines sont devenues plus performantes et donc pouvaient

supporter la coopération avec le décideur. Un système est dit coopératif s‟il est doté de

capacités supplémentaires afin de coopérer avec son utilisateur. La Coopération dans ce

cas consiste, en le partage des tâches à réaliser entre l‟utilisateur et le système.

Par ailleurs, certaines situations exigent que la décision ne soit pas prise par un seul

individu, mais plutôt dans un cadre de concertation et de sollicitation collective.

Lorsque le problème à résoudre est divisé en sous-tâches qui seront affectées

séparément à des participants, la prise de décision dans ce cas revêt un aspect de

coopération dite homme-homme entre les participants. Mais, cela n‟empêchera pas que

chaque décideur peut être aidé par un SIAD coopératif individuel (coopération

homme/machine) dans la tâche qui lui est affectée. Lorsque, à priori, il n‟y a aucune

répartition des tâches entre les décideurs qui participent collectivement à chaque étape

du processus d‟aide à la décision, et, que ce dernier amènera le groupe vers une

décision commune ou consensuelle, la décision dans ce cas est prise dans un contexte

de collaboration entre les décideurs.

Le processus de prise de décision collective engage un groupe de personnes qui peuvent

être dans un même endroit ou bien réparti sur plusieurs endroits, en même moment ou à

des moments différents. La tendance actuelle est que les décideurs sont

géographiquement éloignés. En effet, la mondialisation a instauré un changement dans

les structures organisationnelles ainsi que dans les attitudes des managers qui se

retrouvent devant de nouveaux défis. Cette nouvelle situation est caractérisée par les

points suivants :

l‟évolution des technologies de l‟information qui a permis à des individus

éloignés géographiquement de partager des données et des idées ;

la distribution des organisations à travers la planète ;

une plus forte compétition ;

l‟ouverture du marché international.

En conséquence, la prise de décision exige que les outils décisionnels prennent en

charge des processus d‟aide à la décision collective où les membres du groupe seront

impliqués dans une décision coopérative ou collaborative.

Contribution

Le présent travail s’intègre dans le contexte des systèmes d’aide à la décision

collaborative. Cette dernière est considérée en deux dimensions : la dimension

collective et la dimension individuelle.

La dimension collective concerne l’aspect collaboratif car elle consiste à procurer une

aide à la décision collective où chaque participant est engagé dans chaque étape du

processus de prise de décision. Il n’y a pas de partage de tâches entre les participants.

Nous proposons, dans ce cadre, un modèle d‘architecture à base d’agents d’un GDSS

(Groupe Decision Support System). Le groupe de décideurs qui s’engagent dans une


3

prise de décision peuvent être géographiquement éloignés. Ils suivent un processus de

prise de décision collective qui est guidé par un facilitateur. Un tel système est

caractérisé par une forte composante interactionnelle qui nécessite une coordination

rigoureuse entre le facilitateur et les décideurs.

La dimension individuelle concerne l’aspect coopératif de la décision car elle consiste à

procurer une aide à la décision à un décideur expert dans un domaine donné et à qui on

propose la résolution d’un problème particulier. La résolution du problème suit un

processus d’aide à la décision préétabli qui se base sur la décomposition du problème

en tâches et sous-tâches. La coopération dans ce cas est de type homme/machine. En

effet, le décideur à des connaissances et des compétences, mais la machine peut aussi

être dotée de connaissances et de compétences qui permettent un partage de tâches

entre les deux acteurs et ainsi aboutir à une mise en œuvre d’une coopération. Nous

proposons, dans ce cadre, une architecture d’un SIAD individuel. Ce système est

composé de deux systèmes multi-agents, le premier est réactif (appelé SMAR) et le

second est cognitif (appelé SMAC). Le premier système est chargé de trouver toutes les

solutions possibles au problème posé en entrée, chaque solution est composée des sous

tâches qui peuvent être affectées au décideur ou bien à la machine (le système). Le

second système se chargera d’exécuter la solution choisie dans un cadre de coopération

entre le décideur et le système, selon la stratégie de coopération choisie.

Nous avons utilisé les Systèmes Multi-Agents (SMA) comme modèles de conception

pour les deux systèmes. En effet, les SMA offrent de nombreux avantages pour leur

conception et leur développement. Ils consistent à distribuer les traitements complexes

sur des agents de moindre complexité. Le problème consiste à trouver une bonne

décomposition des traitements, puis de mettre en œuvre une bonne coordination qui

puisse assurer la coopération des agents dont l’objectif commun est d’accomplir

l’exécution du processus d’aide à la décision collective.

Notre document est organisé comme suit :

Chapitre 1 :

Le premier chapitre constitue une présentation générale de l‟aide à la décision. Nous

présentons, d‟abord les notions de décision, de processus décisionnel et de l‟aide à la

décision. Cet historique sur l‟aide à la décision est étendu pour couvrir un domaine de

recherche en vogue qu‟est la prise de décision de groupe en raison des changements

organisationnels des entreprises et de la globalisation. Nous présentons un état de l‟art

sur les systèmes d‟aide à la décision de groupe (GDSS) et les GDSS distribués en

particulier. Nous montrons aussi l’intérêt et les spécificités de deux notions importantes

dans ce domaine qui sont : la coopération et collaboration.

Chapitre 2 :

Dans ce chapitre, nous introduisons le paradigme multi-agents. Nous exposons les

aspects architecturaux ainsi que les méthodologies de développement. Les Systèmes

multi-agents constituent une solution appropriée et une approche efficace pour la

résolution de problèmes complexes. Aussi, nous soutenons l’idée que cette approche

peut être efficace pour la prise en charge des problèmes multi acteurs et distribués

comme les GDSS.


4

Chapitre 3 :

Dans le troisième chapitre, nous exposons les domaines d’application de la technologie

agent et décrivons quelques systèmes d’aide à la décision à base d’agents afin de

présenter la démarche adoptée par les systèmes multi-agents pour l’aide à la décision.

Aussi, au travers de cette revue des systèmes développés dans la littérature, nous

situons notre contribution dans le domaine de l’aide à la décision collaborative.

Chapitre 4 :

Nous présentons notre contribution qui consiste en la conception d’un système d’aide à

la décision collaborative. Ce dernier intègre deux dimensions : la première est

collective et la seconde est individuelle. La première dimension est matérialisée par un

système d’aide à la décision de groupe (GDSS). Ce dernier supporte la collaboration

d’un groupe de décideurs géographiquement éloignés. La deuxième dimension, quant à

elle, est matérialisée par un Système Interactif d’Aide à la Décision (SIAD) coopératif,

la coopération étant de type homme/machine.

Chapitre 5 :

Un exemple d‟application à la gestion des défauts de mise en service du système de la

combustion des chaudières est décrit dans le chapitre cinq pour illustrer la faisabilité

et l‟applicabilité de notre proposition.

La conclusion de ce mémoire nous permet de dresser les perspectives des travaux sur

lesquels nous pensons nous investir dans le futur. En effet, la conception et le

développement des systèmes d‟aide à la décision ont fortement évolué ces dernières

années. Cependant, de nombreux progrès sont encore nécessaires dans le domaine de

la modélisation agents afin de pouvoir supporter le processus de prise de décision

dans son ensemble dans les organisations.

CHAPITRE I

AIDE À LA DECISION

Chapitre I. Aide à la Décision

6

1.1 Introduction

L'être humain est souvent confronté à des problèmes pour lesquels une prise de décision

est nécessaire. Cette dernière est souvent prise sur la base de nos intuitions ou encore

selon nos expériences passées. Seulement, cette décision n'est pas toujours facile à

prendre car il peut s‟agir d‟un problème complexe pour lequel la décision recherchée

peut engendrer des conséquences relativement importantes. Par conséquent, une

mauvaise décision peut couter cher et parfois même être fatale. Par exemple, lorsqu‟il

s‟agit de la gestion des risques technologiques ou naturels, il devient nécessaire de

prendre en compte une quantité importante de données et de connaissances de

différentes natures et qualités, et pour cela, les gestionnaires ont de plus en plus recours

à l‟informatique pour se doter d‟outils puissants d‟aide à la décision.

Cependant, il devient nécessaire de formaliser ce genre de problèmes afin de garantir

une meilleure prise de décision tout en étant efficace. L'efficacité signifie prendre des

décisions rapidement en explorant toutes les éventualités. Par ailleurs, le critère de coût

d‟exécution de la décision doit aussi être pris en compte dans le choix de la décision.

Aussi, il est inadéquat d'adopter une stratégie d'essai-erreur pour gérer une organisation.

Il faudra plutôt utiliser des systèmes d‟aide à la décision qui permettent d'évaluer la

situation, et de fournir les diverses alternatives et leurs impacts.

La prise de décision est un processus cognitif complexe qui se base sur des hypothèses

d‟origine rationnelles et/ou irrationnelles. Ce processus est activé lorsque nous

ressentons le besoin d'agir alors qu‟il se présente pour nous un choix parmi un ensemble

d‟alternatives. Préférer une action plutôt qu‟une autre, choisir au hasard peuvent être le

résultat d'une prise de décision. Mais, dans certains domaines, la prise de décision

rationnelle est exigée car les conséquences peuvent être vitales. Par exemple dans le

domaine médical, la prise de décision intervient dans l'établissement du diagnostic dont

dépendent la prescription du traitement et le suivi du patient. Cependant, dans d‟autres

situations où une action rapide est obligatoire ou encore lorsque toutes les informations

ne sont pas disponibles les experts peuvent privilégier leur intuition.

Par ailleurs, selon le contexte et l‟environnement de la prise de décision, celle-ci peut

concerner soit un seul décideur soit un groupe. Dans ce dernier cas, on parle de prise de

décision collective ou en groupe. Dans ce genre de situations, le processus de décision

doit, en plus, assurer la coordination entre les actions des différents décideurs et, afin

d‟aboutir à une décision collective, il doit aussi fournir des fonctionnalités d‟intégration

des différentes propositions des décideurs.

Dans ce chapitre, nous présentons le domaine de la prise de décision. Nous l‟abordons

d‟abord sous le volet de la décision, en précisant ses différents aspects comme les

typologies, les modèles et le processus de décision. Puis, nous nous intéressons aux

Systèmes Interactifs d'Aide à la Décision (SIAD). Dans ce contexte, nous présentons

leurs fonctionnalités, leurs différentes architectures ainsi que les SIAD coopératifs.

Nous passons ensuite à l‟aspect collectif de la prise de décision, nous définissons

d‟abord la prise de décision collective, puis nous passons en revue les techniques et

outils de prise de décision collective. Aussi, nous décrivons le processus de prise de

décision collective, ainsi que les systèmes d‟aide à la décision de groupe (GDSS). Nous

terminons le chapitre par une conclusion.


7

1.2 Décision

1.2.1 Définition d’une décision

Il existe plusieurs définitions de la décision :

« Une décision est une action qui est prise pour faire face à une difficulté ou répondre à

une modification de l‟environnement, c‟est à dire, pour résoudre un problème qui

se pose à l‟individu ou à l‟organisation » [LEVI 89].

« Une décision c‟est le résultat d‟un processus mental qui choisit une parmi plusieurs

alternatives mutuellement exclusives» [HOLT 89].

Une décision est aussi définie comme "un choix entre plusieurs alternatives", ou encore

par "le fait qu'elle concerne aussi le processus de sélection de buts et d'alternatives". [SCHN 94]

Une décision est souvent vue comme le fait d‟un individu isolé (« le décideur »)

exerçant un choix entre plusieurs possibilités d‟actions à un moment donné [ROY 00].

D‟une manière générale, la décision peut être définie comme étant l‟action de décider

après délibération, et que l‟acteur exerce un rôle important. Ce n‟est donc pas un acte

élémentaire et simple, mais c‟est plutôt l‟aboutissement de tout un processus de

décision.

1.2.2 Typologie des décisions

Les décisions peuvent être classées en plusieurs niveaux.

1.2.2.1 Le niveau de structuration

La classification de SIMON [SIMO 77] propose deux types de décisions : les décisions

programmées et les décisions non programmées appelées aussi « les décisions bien

structurées », et « les décision peu structurées» (voir le tableau 1.1).

1) Décisions bien structurées (Décisions programmables)

Ce sont des décisions répétitives et routinières, pour lesquelles et une procédure peut

être définie afin de les effectuer, ce qui évite d‟avoir à les reconsidérer chaque fois

qu‟elles se présentent. Les techniques d‟optimisation via la programmation

mathématique et la programmation linéaire sont utilisées. Leurs modèles consistent à

avoir plusieurs variables reliées par une équation mathématique, et il s‟agit de maximiser

l‟une d‟entre elles. Dans cette classe de décisions, la machine prend l‟avantage sur

l‟homme.

De nombreux problèmes dans les organisations peuvent s‟analyser en termes de

décision bien structurée. Par exemple, l‟allocation de ressources (agent, temps,

personnes, espace, équipement, affectation d‟employés ou d‟équipements à des travaux

etc.). Dans ce cas, un décideur doit allouer des ressources peu abondantes pour des


8

activités variées afin d‟optimiser un objectif mesurable. La solution est aussi la meilleure

possible, elle découle après application des modèles précédemment cités.

2) Décisions peu (ou non) structurées (Décisions non programmables)

Ce sont des décisions pour lesquelles aucune procédure spécifique n‟est définie pour les

effectuer, soit parce qu‟elles sont nouvelles, non structurées ou bien inhabituelles.

Résoudre un problème de décision non structurée nécessite de faire appel à l‟intuition et

au savoir-faire du décideur qui est l‟élément prépondérant du couple homme/machine.

Ce genre de problèmes possède les caractéristiques suivantes : Premièrement, leur

résolution est fortement dépendante des préférences, des jugements, de l'intuition et de

l'expérience du décideur. Deuxièmement, les objectifs poursuivis lors de la prise de

décision sont nombreux, en conflit et fortement dépendants de la perception de

l'utilisateur. La recherche d'une solution pour ce genre de problèmes implique un

mélange de recherche d'informations, de formulation du problème, de calcul et de

manipulation de données.

Dans cette classe de décisions, l‟un des aspects les plus importants est que l‟homme

prend l‟avantage sur la machine contrairement aux problèmes structurés. Le décideur

peut adopter une stratégie progressive avec des retours arrière. Aussi, il est nécessaire

de lui fournir des méthodes et des outils afin de l‟assister lors de sa résolution du

problème de décision.

Une situation de décision est dite complexe si elle a les caractéristiques suivantes :

On ne peut pas modéliser tout le processus de décision ;

La phase de recherche d‟information est difficile ;

L‟identification du problème nécessite une réelle expertise.

Traditionnelles Modernes

Décision

programmables

L‟habitude.

La routine.

Procédure

opérationnelle/standardisée.

Recherche opérationnelle

- les modèles,

- l‟analyse mathématique,

- la simulation par ordinateur.

Le traitement informatique des

données par programmes

(algorithmes)

Décisions

non

programmables

Le jugement.

L‟intuition, la créativité.

Les règles empiriques.

La sélection et la

formation des décideurs.

Les techniques heuristiques de

résolution de problèmes et leur

informatisation (intelligence

artificielle, systèmes experts,

programmation sous

contraintes, etc.).

Le traitement informatique de

traitement de connaissance à

partir de données (entrepôt et

fouille de données).

Tableau 1.1 : Méthodes et techniques de prise de décision [ESPI 09]


9

Les Systèmes Interactif d‟Aide à la Décision (SIAD) (en anglais Décision Support

System (DSS)), sont conçus pour résoudre ces problèmes de décision peu ou mal

structurées. Toutefois, en pratique, il n'existe pas de dichotomie entre les problèmes

structurés et les problèmes non structurés mais un continuum du degré de structuration

allant des moins structurés aux plus structurés [GARL 96], [ESPI 09].

1.2.2.2 Niveau d’activité managériale

Les décisions peuvent aussi être classées selon le niveau managérial. En effet,

les niveaux se distinguent par la nature des activités qui s‟y déroulent. Ce qui influe sur

le type des décisions que les décideurs sont amenés à prendre. On distingue trois types

d‟activités :

1) Activité de régulation : il s'agit de problèmes bien définis, assez aisément

quantifiables et souvent de nature technique. Ces problèmes ont été résolus par la

recherche opérationnelle classique dont la programmation linéaire est l'exemple

type de méthodes utilisées. Exemple de problèmes : gestion de stocks,

planification et optimisation hebdomadaire de la production, ordonnancement de

tâches, etc.

2) Activité de pilotage : concerne les problèmes de complexité intermédiaire

comme l'élaboration du planning d'un nouveau projet, des modalités

d'implantation d'une nouvelle unité de production, etc. Ces problèmes font

apparaître des objectifs conflictuels, des difficultés pour recueillir des données

précises et quantifiables, des aspects d'incertitude et de risques, etc.

3) Activité de planification stratégique : traite des problèmes complexes où la

décision est orientée vers la réalisation d'un but général, souvent à long terme et

dont certains aspects sont souvent mal définis et mal quantifiés. Il s'agit ici du

niveau de décision le plus élevé qui concerne le premier responsable de

l‟entreprise, par exemple, la création et l'implantation d'une nouvelle usine, ou

encore l‟établissement d'une politique de création d'emplois par un haut

responsable.

1.2.3 Les modèles de décision

Les modèles de décision reposent généralement sur des hypothèses de rationalité des

décideurs et des solutions possibles. On distingue deux types de modèles : Les modèles

normatifs et les modèles descriptifs. Pour les modèles normatifs, la solution proposée est la

meilleure et il est possible de le prouver. Tandis que pour les autres, seules des solutions assez

bonnes ou satisfaisantes sont fournies [GARL 96] [LEBA 03].

1.2.3.1 Les modèles normatifs

Ils fournissent la solution optimale. Dans ce type de modèles, tout l‟espace de recherche

est exploré. On peut citer trois catégories de modèles normatifs :

1) Enumération complète : ces modèles cherchent la meilleure solution parmi un

ensemble relativement petit d'alternatives. Les principales méthodes sont les

tables, les arbres de décision et l'analyse multicritère.


10

2) Optimisation via des algorithmes : il s‟agit de trouver la meilleure solution

parmi un ensemble important voire même infini d'alternatives, en utilisant un

processus d'amélioration pas-à-pas. Les principales méthodes sont la

programmation linéaire, la programmation linéaire en nombre entier, la

programmation convexe et la programmation multi-objectifs qui est une variante

de la programmation linéaire pour plusieurs fonctions (critères) à optimiser

simultanément.

3) Optimisation via des formules analytiques : c‟est une optimisation qui

recherche la meilleure solution en une seule étape en utilisant une formule

analytique.

1.2.3.2 Les modèles descriptifs

Ils donnent une solution satisfaisante en explorant une partie des solutions. Parmi les

modèles descriptifs, nous citons trois catégories :

1) La simulation : c‟est une technique qui permet de mener des expériences de

prise de décision en observant les caractéristiques d‟un système donné sous

différentes configurations. Cette technique permet d‟aboutir à une solution en

choisissant la meilleure parmi les alternatives évaluées.

2) La prédiction : cette technique permet de prévoir les conséquences des

différentes alternatives selon des modèles de prédiction. Les modèles markoviens

font partie des méthodes les plus connues de cette catégorie. La prédiction

fournit une assez bonne solution ou une solution satisfaisante.

3) Les heuristiques : elles permettent d‟atteindre une solution satisfaisante à

moindre coût en utilisant les techniques de la programmation heuristique et les

systèmes à base de connaissances. Ces méthodes sont plutôt utilisées pour des

problèmes complexes et mal structurés où la détermination de solutions peut

entraîner un coût et un temps élevés.

1.2.4 Processus de décision

1.2.4.1 Modélisation du processus décisionnel

Le processus de décision consiste en la détermination des étapes à suivre par un décideur

afin d‟arriver à opter pour une décision comme solution à un problème posé. En 1960

Simon propose le modèle IDC décomposant le processus de décision en trois étapes

(Intelligence – Design – Choice) ou en français «Information – Conception – Choix». En

1977, ce même chercheur a revu son modèle en lui ajoutant une quatrième étape

(Review) « Evaluation ». Cette dernière peut être vue comme une étape d‟évaluation du

processus afin de valider ou non la décision à appliquer (voir figure 1.1). Depuis, ce

modèle reste à ce jour une référence pour la modélisation de la décision.

1. Recherche d‟information (Intelligence) : c'est une phase d‟identification du

problème. Il s‟agit d‟identifier les objectifs ou buts du décideur et de définir le


11

problème à résoudre. Pour cela, il est nécessaire de rechercher les informations

pertinentes en fonction des préoccupations du décideur.

2. Conception et formulation (Design) : c'est une phase de modélisation proprement

dite. Le décideur construit des solutions et imagine des scénarios. Cette phase

aboutit aux différents chemins possibles à la résolution du problème.

3. Choix d‟un mode d‟action (Choice) : c‟est une phase de sélection d'un mode

d'action particulier, c'est-à-dire la prise d‟une décision.

4. Contrôle ou évaluation (Review) : cette phase permet d‟évaluer la solution

choisie (la décision prise). Elle peut amener à un retour arrière vers l‟une des

trois phases précédentes ou, au contraire, à la validation de la solution.

1.2.4.2 Éléments constituants le modèle de décision

Les décisions ne sont pas prises après avoir posé le problème et collecté toutes les

informations, mais progressivement durant un long processus d‟action et de

planification [ADLA 07]. En effet, pour tout processus décisionnel, on développe un

modèle de décision. Ce dernier est constitué de généralement cinq éléments :

1. Le décideur : un individu ou un groupe chargé de prendre une décision

particulière.

Figure 1.1 : Modélisation du processus décisionnel IDC de Simon [SIMO 77]

Information

Conception

Choix

Découvrir le problème

Modélisation et calculs

Choisir parmi les alternatives

Vérifier que la solution est

conforme aux attentes

Validation

Evaluation

Fin

Oui Non


12

2. Un ensemble d‟entrées au processus décisionnel : ce sont des modèles de

données numériques ou qualitatives pour interpréter ces données, l‟expérience

avec des ensembles de données similaires, des situations de décisions similaires,

des contraintes associées à la prise de décision, etc.

3. Le processus de décision lui-même : un ensemble d‟étapes, plus ou moins bien

comprises, pour transformer les entrées en sorties sous forme de décisions.

4. Un ensemble de sorties du processus décisionnel incluant les décisions elles-

mêmes.

5. Et, idéalement un ensemble de critères pour évaluer les décisions produites par

le processus par rapport à l‟ensemble des besoins, des problèmes ou des objectifs

de la décision.

D'une manière générale, la prise de décision est considérée comme étant : tout

processus mental à la suite duquel tout individu, placé devant plusieurs alternatives

mutuellement exclusives, choisit l‟une d‟entre elles. Certaines décisions sont faciles à

prendre. Cependant, il existe des décisions complexes qui requièrent le suivi d‟un

processus décisionnel associé à une aide au décideur durant ce processus. Cette aide est

procurée par les SIAD.

1.3 Système Interactif d’Aide à la Décision (SIAD)

1.3.1 Définitions

1.3.1.1 Aide à la décision

L‟aide à la décision est définie comme étant « L‟activité de celui qui, prenant appui sur

des modè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 acteur dans un

processus de décision. Elé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 ces acteurs se trouvent placés d‟autre part » [ROY 00]

1.3.1.2 "Interactif"

"Interactif" avait un sens fort dans les années 70, car il s‟opposait à “saisie par cartes

perforées”, “traitement par lot”. Aujourd‟hui, les accès à la machine sont des

transactions interactives homme/machine. Un SIAD est interactif parce qu‟il laisse le

contrôle à l‟utilisateur ou au décideur pour choisir ou décider du modèle à appliquer lors

de l‟étape suivante.

1.3.1.3 Les SIAD

L‟un des premiers auteurs à les avoir introduits est Scott Morton en 1971 [MORT 71]. Ce

dernier a introduit les Systèmes de Décision de Gestion MDS (Management Decision

Systems) ou encore DSS (Decision Support Systems). Ces systèmes fournissent aux

décideurs une aide dans le processus de prise de décision même dans des situations


13

complexes et mal structurées. Ils sont devenus effectifs à la fin des années 70 où divers

outils d‟aide à la décision sont devenus opérationnels. Ces derniers, ont en commun la

fonction d‟aide à la décision et ont pris l‟appellation de Système Interactif d‟Aide à la

Décision (SIAD). Ils permettent d‟évaluer une situation, les diverses alternatives et leurs

impacts. Ils offrent aussi au décideur une ergonomie de grande qualité, un accès enrichi

à l‟information et une gestion plus efficace de sa complexité, pour finalement l‟aider à

prendre la meilleure décision.

L'expression systèmes interactifs d'aide à la décision désigne des systèmes qui aident

mais ne remplacent pas le décideur. L'aide généralement interactive ou semi-automatisée

permet au décideur d'avoir accès aux données et de tester différents choix possibles pour

la résolution du problème à traiter [DAVI 86], et ce contrairement aux situations

structurées où les solutions et procédures sont complètement automatisables.

De nombreuses définitions ont été proposées dans la littérature:

Une des définitions les plus citées des systèmes d‟aide à la décision est celle de Keen et

Scott-Morton [KEEN 78] «Les systèmes d‟aide à la décision font coupler les ressources

intellectuelles des individus avec les capacités de l‟ordinateur pour améliorer la qualité

des décisions. C‟est un système informatique d‟aide aux décideurs qui traite des

problèmes semi-structurés ».

Sprague et Carlson [SPRA 82] ont défini les SIAD comme étant des systèmes

informatisés et interactifs qui aident les décideurs en utilisant des données et des

modèles pour résoudre des problèmes mal structurés. Cette définition introduit les

termes données et modèles qui définissent une architecture des SIAD proposée par ces

auteurs.

«Les SIAD sont des systèmes informatiques supportant la prise de décision». [FINL 94]

«Un SIAD est un logiciel conçu pour faciliter la préparation d'informations pertinentes

sur la base desquelles une décision motivée peut être prise. Donc, c‟est un ensemble de

moyens informatiques organisés pour améliorer le processus décisionnel. Ces systèmes

fourniraient un cadre normatif à la démarche devant aboutir à une prise de décision».

[PROB 84]

«Un SIAD est un système , ayant pour but l'aide à la résolution de problèmes et à la prise

de décision; il est composé de base(s) de données, de modèles et d'outils spécialisés

permettant de gérer, d'analyser et de comparer des données, provenant d'autres systèmes

d'information de différentes unités internes ou de bases de données externes à une

organisation»1.

Selon Turban [TURB 93], un système d‟aide à la décision est un système d‟information

automatisé, interactif, flexible, adaptable et spécifiquement développé pour aider à la

résolution d‟un problème de décision non structuré et améliorer la prise de

décision. Il utilise des données, fournit une interface utilisateur simple et autorise

1 http: //dictionnaire.sensagent.com/syst%C3%A8me+interactif+d'aide+%C3% A0+lad % C3 %A9cis

ion/fr-fr/


14

l‟utilisateur à développer ses propres idées ou points de vue. Il peut utiliser des

modèles standards ou spécifiques, supporter les différentes phases du processus de

la prise de décision et inclure une base de connaissances. Cette définition porte à la

fois sur les fonctionnalités du système ainsi que sur son architecture.

D‟une manière générale, un SIAD est un système informatique qui doit aider un

décideur à suivre un processus d‟aide à la décision. C‟est grâce à l‟interactivité qui est à

la base de la coopération des deux partenaires (le système et l‟utilisateur) que le SIAD

accomplira le rôle pour lequel il a été conçu.

Ce sont des systèmes qui utilisent les ordinateurs pour :

assister les décideurs au cours du processus de décision concernant des tâches

semi structurées,

aider plutôt que remplacer le jugement des décideurs,

améliorer la qualité de la prise de décision plutôt que l‟efficacité.

De nombreux SIAD ont été développés pour des secteurs aussi variés que les

télécommunications, le transport urbain [BELM 05], aérien et ferroviaire, la santé,

l'ordonnancement, la gestion de projet, l‟aménagement de territoires [FERR 03] etc. De

ce fait, les SIAD peuvent être appliqués aux domaines où l‟activité humaine nécessite un

processus de décision élaboré.

1.3.2 Fonctionnalités des SIAD

Diverses fonctions sont attribuées aux SIAD :

1. Ils doivent apporter principalement une aide pour les problèmes peu ou mal

structurés en connectant ensemble des jugements humains et des informations

calculées.

2. Ils doivent posséder une interface simple et conviviale afin d'éviter que l'usager

ne soit perdu devant la complexité du système.

3. Ils doivent fournir une aide pour différentes catégories d'utilisateurs ou différents

groupes d'utilisateurs.

4. Ils doivent supporter des processus interdépendants ou séquentiels.

5. Ils doivent être adaptatifs dans le temps. Le décideur doit être capable de

supporter des conditions qui changent rapidement et d'adapter le SIAD pour

faire face aux nouvelles situations. Un SIAD doit être suffisamment flexible pour

que le décideur puisse ajouter, détruire, combiner, changer et réarranger les

variables du processus de décision ainsi que les différents calculs, fournissant

ainsi une réponse rapide à des situations inattendues.

6. Ils doivent laisser le contrôle de toutes les étapes du processus de décision au

décideur pour que celui-ci puisse remettre en cause à tout moment les

recommandations faites par le SIAD. Un SIAD doit aider le décideur et non se

substituer à lui.


15

7. Ils doivent utiliser des modèles. La modélisation permet d'expérimenter

différentes stratégies sous différentes conditions. Ces expériences peuvent

apporter de nouvelles vues sur le problème et un apprentissage.

8. Les SIAD les plus avancés utilisent un système à base de connaissances qui

apporte notamment une aide efficace et effective dans des problèmes nécessitant

une expertise.

9. Ils doivent permettre la recherche heuristique.

10. Ils ne doivent pas être des outils de type boite noire. Le fonctionnement d'un

SIAD doit être fait de manière à ce que le décideur le comprenne et l'accepte.

1.3.3 Architectures générales d’un SIAD

Comme il existe plusieurs définitions pour les SIAD, il existe de même plusieurs

architectures. Sprague et Carlson [SPRA 82] ont défini les SIAD en termes de données

et de modèles pour résoudre des problèmes mal structurés. Ils ont proposé

l‟architecture suivante des SIAD (voir figure 1.2).

Cette architecture est composée d‟une interface Homme/Machine, d‟un Système

Gestionnaire de Base de Données (SGBD) incluant la Base de Données ainsi qu‟un

Système Gestionnaire de Base de Modèles (SGBM) incluant une Base de Modèles.

Un système basé sur cette architecture possède des capacités interactives qui

permettent d‟impliquer l‟utilisateur dans la résolution de problèmes non

programmés, mal structurés ou semi structurés.

Dans [FORG 02], les auteurs ont proposé une architecture conceptuelle pour des

systèmes supportant la prise de décision sur Internet. En effet, ils proposent une

architecture de SIAD intelligents I-DMSS (Intelligent Decision-Making Support

Systems) capables de supporter toutes les phases du processus de décision d‟une manière

continue, intégrée et complète. Le principal attrait de cette définition est de mettre

l‟accent sur le processus de décision. En effet, les auteurs proposent différentes

sortes d‟aide selon les différentes étapes du processus [MORA 12].

SGBD

Interface

SGBM

Décideu

r

Figure 1.2 : Structure d’un SIAD selon Sprague et Carlson

[SPRA 82]


16

Marakas dans [MARA 03] a introduit une nouvelle architecture pour les SIAD (figure

1.3). Il considère que les composants d‟un SIAD peuvent être généralement

classifiés en cinq parties distinctes : le système de gestion de base de données (SGBD),

le système de gestion de base de modèles (SGBM), le système de gestion de base de

connaissances (SGBC), l‟interface utilisateur et les utilisateurs.

Un système gestionnaire de base de données (SGBD) stocke, organise, trie et

remonte les données pertinentes pour un contexte particulier de décision.

Un système gestionnaire de base de modèles (SGBD) possède un rôle

similaire au système gestionnaire de base de données excepté qu‟il organise,

trie, stocke les modèles quantitatifs de l‟organisation.

Un système gestion de base de connaissances utilise un moteur d‟inférence pour

accomplir des tâches relatives à la reconnaissance de problèmes , à la

génération de solutions finales ou intermédiaires, ainsi que des fonctions

relatives à la gestion du processus de résolution de problème.

Une interface utilisateur, un élément clé dans l‟architecture du système global.

Utilisateur ou décideur, il fait partie intégrante du processus de résolution de

problème.

Nous remarquons que cette architecture comprend en plus un moteur d‟inférence qui

supporte le raisonnement dans la prise de décision. Ce raisonnement est basé aussi

sur la modélisation de la connaissance relative au problème à résoudre. Ces SIAD sont

dits Intelligents ou SIAD à Base de connaissances. Relativement à l‟architecture des

SIAD proposée par Sprague et Carlson, l‟intégration du système à base de

connaissances est soit au niveau du système gestionnaire de base de données, soit

dans le système gestionnaire de base de modèles soit dans l‟interface

homme/machine. Le choix est guidé par le besoin d‟apporter une aide selon le type de

raisonnement de la prise de décision : raisonnement orienté données, raisonnement

orienté modèles, raisonnement orienté interfaces.

1.3.4 Typologies des Systèmes d'aide à la décision

Il existe plusieurs classifications de SIAD. Nous allons en présenter quatre : une

classification en fonction de la quantité des informations manipulées, une deuxième

classification en fonction du niveau de la décision impliquée, une troisième

classification en fonction de l'envergure de la décision et une quatrième classification en

fonction du niveau conceptuel du système.

Figure 1.3 : Structure d’un SIAD selon Maracas [MARA

03]

I n

t e

r f a

c e

Décideur

SGBD

SGBM

SGBC


17

1.3.4.1 Classification en fonction de la quantité d’informations manipulées

Power cité dans [ADLA 07], distingue entre des SIAD d‟entreprise et ceux de bureau :

Un SIAD d‟entreprise est relié à de larges entrepôts de données et sert à

plusieurs gestionnaires dans l‟entreprise.

Un SIAD simple utilisateur ou de bureau est un petit système qui réside dans

un PC d‟un gestionnaire individuel.

1.3.4.2. Classification en fonction du niveau de décision

Lévine et Pomerol [LEVI 89] distinguent quatre types de systèmes décisionnels selon le

niveau de décision impliqué par un SIAD:

Executive Information System (EIS) : Un EIS est un système spécialement conçu

pour répondre aux besoins de la haute direction d‟une entreprise et qui lui est

exclusivement réservé. L‟intérêt des EIS est de faciliter l‟accès aux informations

pertinentes en permettant de naviguer de la synthèse au détail. Le but étant de

confronter ces informations aux objectifs recherchés.

Executive Support System (ESS) : Un ESS permet non seulement l‟accès aux

données critiques, mais intègre également l‟analyse de ces données. Cela signifie

que pour qu‟un EIS soit considéré comme un ESS, il faut qu‟il offre la possibilité

de supporter également les phases de conception et de choix. Un ESS permet,

outre la navigation et le croisement multidimensionnel, de traiter des volumes

importants, d‟assurer l‟intégration d‟informations d‟origine diverses et de gérer

des hiérarchies et des agrégats. [GHOM 08]

Decision Support System (DSS) : c'est un système interactif qui aide le décideur

à exploiter les données et les modèles pour trouver une solution à un problème

non structuré et à analyser l'effet d'éventuels changements de l'environnement

sur l'organisation. Le but du DSS est d'aider à la décision et non pas de remplacer

le décideur. Il doit permettre de faire de la planification stratégique, ainsi que de

la budgétisation à long terme. [GHOM 08]

Planning Support System (PSS) : il permet de faire une analyse de la faisabilité

des procédures ou décisions retenues. Il fournit donc au décideur une assistance

intelligente.

1.3.4.3 Classification en fonction de l'envergure de la décision

Lorsqu'on ne prend en compte que l'envergure de la décision, les SIAD peuvent être

classés en trois catégories [VOLL 04] :

Le SIAD opérationnel : il évite la surcharge mentale de l‟opérateur en lui

proposant des solutions permettant de faire face rapidement à des situations

complexes. Cet automate, qui relève des systèmes experts, n‟équipe que ceux des


18

opérateurs qui peuvent avoir à résoudre des problèmes très difficiles sous la

contrainte de l‟urgence.

Le SIAD de gestion : il présente aux responsables opérationnels les indicateurs et

alarmes quotidiens utiles au pilotage du travail des opérateurs (respect des

normes de qualité, charge de travail des ressources). Un SIAD de gestion devrait

équiper tout processus de production.

Le SIAD stratégique : il présente aux dirigeants des séries chronologiques

périodiques. Il fournit au comité de direction une évaluation partagée et précoce

des indicateurs essentiels.

1.3.4.4 Classification en fonction du niveau conceptuel du système

Utilisant le mode d'assistance comme critère, Power dans [POWE 02] distingue entre

quatre types génériques de systèmes d‟aide à la décision :

un SIAD centré données met en relief l‟accès à et la manipulation d‟une série

temporelle de données internes à l‟organisation et quelquefois de données

externes ;

un SIAD orienté modèle met en relief l‟accès à et la manipulation d‟un modèle

de simulation, d‟optimisation, financier et statistique. Un SIAD orienté Modèle

utilise des données et des paramètres fournis par les utilisateurs pour aider les

décideurs à analyser une situation, mais n‟est pas nécessairement centré sur les

données ;

les SIAD dirigés par la connaissance (knowledge-driven DSS) fournissant

l'expertise de résolution des problèmes stockée comme faits, règles ou

procédures.

un SIAD orienté documents fournit une expertise de résolution de problèmes

spécialisés, stockés comme des faits, des règles, des procédures ou dans des

structures similaires ;

un SIAD orienté communication supporte plus qu‟une personne travaillant sur

une tâche partagée.

Dans cette dernière catégorie, on retrouve les systèmes d‟aide à la décision de groupe

(appelés GDSS : Group Decision Support Systems) qui prennent une position

prépondérante dans l‟organisation. En effet, de nos jours, la décision est plus considérée

comme une activité de groupe, ce qui a amené les organisations à constituer des équipes

virtuelles de décideurs géographiquement éloignés pour collaborer à une variété de

tâches.

1.3.5 Systèmes d’aide à la décision coopératifs

La coopération peut être située à différents niveaux lors de la réalisation de

systèmes coopératifs [ADLA 07] :


19

1. La coopération homme/machine : les systèmes coopératifs de ce niveau sont

dotés de capacités supplémentaires afin de guider l‟utilisateur dans son

processus de résolution de problèmes. Dans les processus décisionnels, l‟un des

aspects les plus importants est que l‟homme prend l‟avantage sur la machine

contrairement aux problèmes structurés. Rendre un SIAD coopératif, c‟est le

doter de capacités supplémentaires afin de coopérer avec son utilisateur et de le

guider dans son processus de résolution de problèmes. Coopérer dans ce cas,

signifie en particulier distribuer les tâches à réaliser entre l‟utilisateur et le

système. La tâche qui fait l‟objet de la coopération doit faire l‟objet d‟un

découpage en sous tâches cohérentes. La répartition des tâches entre les deux

agents (utilisateur, système) est faite dynamiquement, en fonction des

performances de chacun des deux agents et de la charge du travail de

l‟opérateur. Par ailleurs, ces systèmes sont caractérisés par des interactions

homme/machine à travers des interfaces adaptatives intelligentes.

2. La coopération homme-homme médiatisée : les systèmes coopératifs de ce

niveau possèdent en eux-mêmes des fonctionnalités capables de supporter la

coopération. Dans un cadre général, une décision est dite coopérative lorsqu‟elle

implique plusieurs acteurs. Ce processus de construction collective de la

décision doit être géré comme un projet avec des rencontres réelles entre

les différents décideurs et des dates de retour pour des sous tâches. Ces systèmes

dits SCAD (Systèmes collaboratifs d’aide à la décision) ou GDSS (Systèmes

d’aide à la décision de groupe) doivent supporter les concepts de

communication, de coordination et de coopération entre les différents acteurs

concernés. Pour cela, ils doivent comporter les composants suivants [ZARA 05] :

a) Un outil de communications interpersonnelles : une infrastructure comme

Internet permet de mettre en œuvre des outils de communication

(messagerie, forums de discussions, etc.).

b) Un outil de gestion des tâches : Il assure la répartition des tâches en sous

tâches ainsi que l‟affectation de rôles ou d‟agents à ces tâches. C‟est cette

entité qui permet une coopération entre divers utilisateurs ou entre la

machine et les utilisateurs.

c) Un outil de capitalisation des connaissances : capitaliser les connaissances

des décideurs impliqués dans les processus de décision afin que chacun

puisse y faire référence si nécessaire. Les décideurs impliqués dans des

processus de prise de décision distribuée et asynchrone pourront être

supportés par cet outil en réutilisant des solutions existantes par

exemple ou simplement des parties de solutions déjà établies.

d) Un outil d‟Interaction Homme/Machine dynamique : cet outil doit être plus

évolué que celui des SIAD traditionnels. Il doit prendre en considération

des contraintes relatives à la charge cognitive de l‟utilisateur lors de

l‟exécution d‟une tâche, des contraintes relatives à la résolution du problème

global.

Les systèmes SCAD ou GDSS rentrent dans le cadre des de Systèmes d‟Information

Coopératifs et utilisent des Systèmes Coopératifs à Base de Connaissance. Ils


20

s‟inscrivent donc dans le cadre de l‟évolution effectués sur les CSCW (Computer

Supported Cooperative Work). Ils sont au centre de notre contribution ; nous leur

consacrons les sections suivantes pour une description plus détaillée.

1.4 La prise de décision en groupe

Dans certaines situations les décisions ne sont pas prises par un seul individu. Même si

la responsabilité de la prise de décision incombe à un seul individu, la décision peut être

prise dans un cadre de concertation et de sollicitation collective. Le processus de prise

de décision collective engage un groupe de personnes qui peuvent être dans un même

endroit ou bien réparties sur plusieurs endroits, en même moment ou à des moments

différents. La prise de décision en groupe est un processus utilisé par la plupart des

organisations et à différents niveaux hiérarchiques. Elle consiste à discuter des choix

possibles avec un groupe afin de déterminer une solution finale. La décision est dans ce

cas l‟aboutissement du processus de décision. Lorsque le problème à résoudre est divisé

en sous-tâches différentes qui seront affectées à des participants individuels, la prise de

décision dans ce cas n‟est pas seulement collective, mais inclue en plus un aspect de

coopération entre les participants.

Les systèmes qui supportent la prise de décision de groupe (GDSS) renferment des

outils de travail de groupe supportés par des outils de travail coopératifs assisté par

ordinateur (TCAO, CSCW en anglais). L‟aide à la décision de groupe permet à des

groupes soit d‟aboutir à une solution commune, dans ce cas il s‟agit de GDSS (Group

Decision Support System) [JELA 87], soit de fonctionner dans un contexte de

négociation dans ce cas on parle de NDSS (Negotiation Decision Support System) [ESPI

97].

1.4.1 Définitions

Beaucoup de chercheurs se sont intéressés à la prise de décision collective, nous citons

les suivants :

Marakas dans [MARA 99] définit la prise de décision collective comme 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.

Laborie dans [LABO 06] définit l‟activité de prise de décision collective comme : «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 ».

Dans le domaine de recherche dédié à l‟informatique et aux outils collaboratifs, la

décision collaborative est associée à un processus "argumentatif" où chaque participant

doit tenir compte des autres collaborants pour comprendre les contraintes et les solutions

au problème posé, les intérêts et les priorités de chacun [KARA 01].

Dans le domaine des systèmes multi-agents, une prise de décision collaborative est

définie comme étant associée à un groupe d‟agents distribués qui coopèrent pour


21

atteindre des objectifs supérieurs aux capacités individuelles des agents. Une prise de

décision collaborative est généralement associée à un mode de raisonnement distribué

selon lequel un groupe d‟agents travaillent en collaboration via un espace commun de

recherche [PANZ 02].

Seguy dans [SEGU 08] a définit la décision collaborative par : une décision collaborative

est associée à un processus, traduisant ainsi une succession d‟étapes intermédiaires

conduisant un groupe d‟acteurs à une décision. Une décision collaborative est l‟activité

d‟un groupe d‟acteurs travaillant ensemble, avec un objectif commun, tout en partageant

des ressources et des moyens de communication.

La prise de décision collective peut être définie comme étant un engagement d‟un

groupe de décideurs dans un processus de prise de décision. Ce groupe peut être réparti.

Les acteurs peuvent avoir des points de vue différents qu‟ils peuvent argumenter. Ils

peuvent avoir un espace de travail privé, mais doivent avoirs le moyen de communiquer

pour partager un espace de travail public.

1.4.2 Le groupe

Le groupe est un ensemble de personnes qui se réunissent et qui s‟engagent dans un

processus de décision collaborative. Mais, se réunir ne veut pas dire que les membres du

groupe doivent être dans un même endroit. En effet, ils peuvent être dispersés

géographiquement mais ils possèdent le moyen de communiquer.

Le groupe possède plusieurs caractéristiques :

Typologie du groupe : Dans [ADLA 10], Il y a trois manières selon lesquelles le

travail de groupe peut être organisé:

Groupe interactif : les membres d‟un groupe interactif communiquent

entre eux et s‟efforcent de poursuivre leur tâche. Dans une réunion

face-à-face, seule une personne du groupe peut proposer son idée à un

instant donné, car les membres du groupe ne peuvent prêter attention

qu‟à une seule personne à la fois. Le groupe interactif peut tirer avantage

des synergies sociales, toutefois, des tractations entre les membres peuvent

causer une déperdition du processus.

Groupe nominal : dans un groupe nominal, les membres du groupe

travaillent séparément sur la même tâche et un des résultats est choisi

comme le produit du groupe. Evidemment, les membres d‟un groupe

nominal ne bénéficient pas des synergies sociales de groupes larges,

mais d‟un autre coté, ils ne sont pas impactés par des effets indésirables

du travail interactif tels l‟arrêt de production ou l‟appréhension

d‟évaluation. Un groupe nominal peut aussi être utilisé pour fournir un

processus d‟anonymat pour les membres du groupe.

Equipe : un travail d‟équipe combine des aspects à la fois du travail de

groupe interactif et nominal. Le groupe de travail est divisé en équipes

(typiquement 2-5 personnes), qui travaillent séparément. Les équipes


22

sont de tailles assez réduites pour ne pas subir les déperditions de

processus des groupes larges, mais assez large pour tirer profit des synergies

sociales. Cependant, les équipes peuvent subir les tractations entre membres

comme dans les groupes de travail interactifs.

La taille du groupe : Certaines recherches ont montré que la taille optimale d‟un

groupe sans support technologique est de 3 à 5 personnes. En effet, cette taille du

groupe favorise le nombre d‟idées générées par personne et supporte mieux les

discussions informelles. Cependant dans certains cas, lorsque le problème

requiert une grande expertise, un nombre plus important de personnes devient

nécessaire. Lorsqu‟un GDSS est utilisé, il faudra tester le système pour définir la

taille optimale du groupe car cela dépend de la nature du problème et aussi de la

façon avec laquelle les participants réagissent avec le système.

L‟anonymat : L‟anonymat n‟est pas nécessaire dans une réunion de prise de

décision collective. Toutefois, dans certains cas, il peut y avoir un intérêt de

permettre aux participants d'exprimer leurs opinions librement sans être

influencés par les autres membres du groupe (leurs responsables par exemple).

Mais, cela peut présenter l‟inconvénient d‟être la source de démotivation de la

part des participants ou encore de création de conflits dans la mesure où les

participants peuvent employer des expressions désobligeantes.

Composition du groupe : Les acteurs qui interviennent lors d‟un processus

d‟aide à la décision de groupe sont de deux types : les participants ou encore

les experts dans la prise de décision, et le facilitateur appelé aussi le médiateur ou

initiateur [CHEN 05].

Le facilitateur : c‟est un membre du groupe. C‟est l‟acteur qui a pour rôle de

superviser le processus de prise de décision collective. D‟abord, il lance et

prépare les différentes phases du processus. Il définit ensuite la

problématique de la décision et organise le groupe des décideurs. Il a la

responsabilité de faire converger le processus de prise de décision. Il se

charge aussi de diffuser les résultats aux participants à la fin de la

session de prise de décision. Il est donc responsable du processus complet

et de son achèvement, à savoir la décision.

Les participants : ce sont les autres acteurs du groupe autre que le

facilitateur. Ils représentent les experts dans la prise de décision. Les

participants sont d‟abord invités à la réunion. Lors de la réunion, ils

reçoivent la problématique de la part du facilitateur. Leurs rôles est de

participer à la session de prise de décision collective. Pour cela, ils

produisent des idées et des commentaires qu‟ils partagent avec les autres

participants. L‟activité des participants est coordonnée par le facilitateur.

1.4.3 Les techniques de prise de décision de groupe

1.4.3.1 Le brainstorming


23

Le brainstorming [BEAC 97] est une méthode conçue pour la génération d‟un maximum

d‟idées possibles dans les réunions de groupe. Cette technique est basée sur une

succession de votes des experts afin de classer les solutions proposées lors du

brainstorming et d‟aboutir à la meilleure solution après plusieurs tours de vote.

1.4.3.2 Technique de prise de décision consensuelle

La technique de prise de décision consensuelle peut suivre les sessions initiales

d‟un brainstorming ou être utilisée seule. Son but principal est de trouver la solution

optimale à un problème. Ceci est réalisé par le vote d‟un groupe d‟experts pour une

solution (ou une idée) préférée [DIEN 04].

1.4.3.3 Technique NGT (Nominal Group Technique)

La taille du groupe et les différences de statuts ou d‟expertises entre les membres

peuvent parfois rendre difficile la gestion d‟une séance de brainstorming (conflit,

inhibition des réponses, influences sociales). La technique du groupe nominal permet

de pallier ces problèmes [TURB 98]. Elle permet au facilitateur de recueillir de

l‟information auprès de plusieurs experts tout en évitant les aspects négatifs du travail

dans un groupe : les membres du groupe se réunissant mais travaillant

indépendamment les uns des autres

1.4.3.4 La méthode Delphi

Cette technique permet le travail à distance, sans réunion entre les participants [AMOS

08] [CLAY 97]. Le travail se fait par correspondance entre plusieurs participants et

un coordinateur qui centralise les réponses. Cette méthode consiste à poser une série

de questions à un cercle permanent de personnes plusieurs fois de suite. Le but final

est de rassembler plusieurs avis d‟experts sur un sujet précis, de mettre en évidence

des convergences d‟opinions et de dégager un éventuel consensus.

La méthode Delphi, favorise la convergence des opinions autour de valeurs

centrales, est particulièrement bien adaptée pour préparer le consensus nécessaire à

certaines prises de décision.

1.4.3.5 La méthode « Policy Delphi »

La technique Policy Delphi [WAND 04] est un outil d‟analyse plutôt qu‟un mécanisme

permettant la prise de décision. Elle ne recherche pas à tout prix un consensus entre les

experts, mais vise plutôt à recenser le plus grand nombre d‟alternatives possibles.

Elle représente donc un palliatif lorsqu‟on ne parvient pas à un consensus ou à une

convergence totale entre les avis des différents experts. L‟avantage de cette méthode est

que son procédé permettra de tenir compte de tous les avis, qu‟ils soient

majoritaires ou qu‟ils soient minoritaires

1.4.4 Le processus de prise de décision

Afin de maitriser la prise de décision collective et contrôler les activités des différents

acteurs qui participent dans ce travail collaboratif, la conception d‟un modèle est

nécessaire. Comme pour les SIAD, ce modèle spécifie et organise les différentes phases

qui constituent le processus de prise de décision collective.


24

Le processus de prise de décision collective que nous considérons dans le présent travail

est celui de Adla [ADLA 10]. Le modèle est composé de trois phases : (1) Pré-décision ;

(2) Décision ; et (3) Post-décision. Ce processus est illustré par la figure 1.4.

La phase « Pré-décision » permet d‟explorer et d‟ouvrir l‟espace de décision, la

dernière phase « Post-décision » referme cet espace. Quant à la seconde phase

«Décision», elle comprend quatre étapes cognitives principales. Ces dernières,

constituent les éléments constructeurs de tout processus de prise de décision dont

le modèle de Simon (1977) pour la prise de décision individuelle. Les quatre étapes

sont : la génération des alternatives, l‟organisation des alternatives, l‟évaluation des

alternatives, et la décision ou le choix de la solution.

1) La phase de Pré-décision « Pre-meeting »

Nous identifions deux éléments majeurs marquant cette phase :

1) La compréhension partagée de l‟espace de décision : Il s‟agit d‟une part de la

prise en compte commune de l‟espace de prise de décision ; ce qui consiste en

l‟ensemble des caractéristiques que la solution devra satisfaire et l‟ensemble

des contraintes pour la concevoir et, d‟autre part, de la compréhension par


25

chacun des acteurs engagés dans le processus de prise de décision collective du

rôle attribué à chacun, des ressources disponibles pour arriver à la décision,

des moyens technologiques disponibles ou encore de l‟organisation des tâches à

réaliser.

2) La création d‟un référentiel opératif commun : le référentiel opératif commun

consiste principalement en les connaissances et un vocabulaire partagé par les

participants. Ce terrain commun permet l‟échange des idées et des connaissances

et définit un espace d‟échange compris par tous les membres, ce qui facilitera

le travail du groupe.

1.2) La phase de Décision « During meeting »

Génération des solutions alternatives

Il s‟agit d‟une phase de raisonnement personnel qui aboutit à une production de

solutions. Ces dernières sont ensuite soumises à l‟ensemble des acteurs. Cette

dynamique de réflexions privées puis de regroupement implique des mécanismes de

communication et d‟échange entre le groupe et l‟individu. Pour cela, il doit y avoir un

espace privé propre à chacun des participants et un espace public dans lequel le

groupe pourra collaborer. Plusieurs outils de génération de solutions existent qui

permettent aux participants d‟introduire et de faire partager leurs idées, opinions

ou informations : Brainstorming électronique, NGT et Delphi . Ces outils supportent

des réflexions divergentes dans le processus de résolution.

Organisation des alternatives

Suite à la génération des alternatives, le groupe des participants gère un ensemble de

solutions. Ces dernières peuvent être redondantes ou bien contenir des similarités. Alors

au cours de la phase organisation des alternatives, le facilitateur pourra fusionner des

alternatives ou bien supprimer celles qui sont similaires. C‟est donc une phase

d‟épuration qui aboutit à un ensemble de solutions épurées et consolidées. Le facilitateur

est responsable de cette consolidation, mais il peut faire participer les décideurs et les

impliquer en leur demandant de proposer des suggestions de consolidation.

Evaluation des alternatives

Après l‟achèvement de la phase d‟organisation des alternatives le facilitateur sollicite les

participants pour une évaluation des alternatives retenues. Dans un premier temps,

chaque acteur de la prise de décision va évaluer les options de solutions proposées

avant d‟entrer dans une phase de négociation commune. L‟évaluation personnelle des

décideurs va faire appel à des méthodes d‟estimation ou d‟évaluation selon des

pondérations propres à chacun. Trois méthodes ou modes d‟estimation sont mises à

disposition du décideur :

o Le mode d‟évaluation analytique : plusieurs méthodes peuvent être utilisées. Le

participant évalue chaque alternative par une valeur sur une échelle de 1 à 10, ce

qui permet la réduction du nombre de ces alternatives. Les résultats d‟évaluation

du groupe et les écarts standards peuvent être visualisés par les participants. Ou


26

bien, le participant évalue les alternatives en votant par oui/non sur chaque

alternative. Les alternatives favorables sont celles qui comptabilisent le plus

grand nombre de oui. L‟évaluation multicritère permet aux participants

d‟utiliser un ensemble de critères pondérés pour évaluer un ensemble

d‟alternatives.

o Le mode d‟évaluation comparative : les participants utilisent un outil de

classement qui leur permet de déplacer les alternatives pour leur changer de

classement.

o Le mode d‟évaluation analogique : consiste à comparer une solution

précédente (acceptée ou non) proposée par le facilitateur avec la solution

courante dans le but de l‟évaluer. Au niveau de cette méthode d‟évaluation

plusieurs techniques peuvent être appliquées, ces dernières sont citées dans

[ADLA 10].

Décision/Choix d’une solution

Cette phase suit celle de l‟évaluation des alternatives. Elle doit vérifier les deux

contraintes suivantes : d‟abord, elle doit correspondre à une réponse dans le cadre pour

lequel elle a été conçue (objectifs, contraintes, ressources, critères d‟évaluation). Aussi,

elle doit être notifiée aux participants. Ces derniers doivent être conscients des

modifications apportées et des décisions prises, même s‟ils n‟étaient pas

directement impliqués dans le processus de décision. Cette démarche permet de

préserver la validité du référentiel opératif commun.

1.3) Phase de Post-décision « Post-meeting »

Les sessions relatives à l‟exécution du processus d‟aide à la prise de décision collective

peuvent être stockées dans une mémoire organisationnelle. Cette dernière pourra servir

comme outil de capitalisation de connaissances. Lorsqu‟un nouveau problème est

identifié, on cherchera au niveau de cette mémoire un problème qui lui est analogue et

de cette manière on utilisera l‟expérience passée pour proposer une solution sans

déclencher le processus d‟aide à la décision. De plus, cette trace des sessions déjà

passées peut servir comme moyen d‟évaluation. Par exemple, on pourra évaluer le

rendement des participants relativement aux types de problèmes posés, ce qui permettra

de cerner le profil des participants.

1.4.5 Le GDSS (Group Decision Support System)

1.4.5.1 Définition

Dans la littérature, il existe plusieurs définitions relatives au GDSS [DESA 87] [ZARA

05] [ADLA 07]. Parmi ces définitions, nous citons la suivante : « Les Systèmes d'aide à

la décision de Groupe (GDSS) sont étroitement liés au DSS, ils facilitent la

résolution de problèmes non structurés et semi-structurés par un groupe de

décideurs travaillant ensemble telle une équipe. 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 et font évoluer la prise de

décision collectivement en facilitant l‟échange et l‟utilisation d‟informations par les


27

membres du groupe d‟un coté, et l‟interaction entre le groupe et le système d‟un

autre coté. » [ADLA 07]

Les GDSS sont issus d‟un courant américain. De Sanctis G., Gallupe R., Vogel M.

et Nunamaker J., ont initié le développement de ces systèmes à l‟université de

Tucson, Arizona, USA. Le courant de pensée européen concernant ces systèmes est

dirigé par Liam Bannon [BANN 89]. L‟approche est issue du mouvement Computer

Supported Cooperative Work (CSCW). Les GDSS utilisent des infrastructures de

communication ainsi que des modèles quantitatifs et heuristiques d‟aide à la

décision. Ces systèmes étaient initialement installés dans une salle dédiée. Ce type

de salle requiert un arrangement physique des ordinateurs. Les caractéristiques d‟un tel

type de salle sont les suivantes :

chaque participant travaille sur un ordinateur,

un facilitateur (leader) coordonne la session d‟utilisation du système,

la salle offre un large écran que tous les utilisateurs peuvent voir,

les ordinateurs sont connectés en réseau et utilisent une architecture

client/serveur,

Une session d‟utilisation s‟organise en général de la manière suivante (selon la

technique de DELPHI) :

brainstorming en ligne (forum de discussion),

organisation des différentes idées grâce au facilitateur et à l‟écran

principal,

tri des différents items,

votes individuels sur les décisions à prendre puis agrégation des votes par

le logiciel,

rapport automatique de session d‟utilisation.

Les GDSS peuvent être utilisés aussi bien en mode synchrone et non distribué où tous

les participants se trouvent dans la salle dédiée à l‟utilisation du système qu‟en mode

asynchrone et distribué via Internet (pour plus de détails sur ces systèmes voir aussi

[DESA 87] [GRUD 94]). Le tableau 1.2 présente les systèmes d‟aide à la décision de

groupe relativement à l‟espace et le temps.

Même temps Différents temps

Même lieu Salles de décision

Tableau blanc,

Ecran partagé, Chat

Différents lieux

Vidéoconférence,

EMS,

GDSS distribué

synchrone

GDSS distribué

asynchrone,

SIAD coopératif

Tableau 1.2 : Quatre combinaisons des systèmes d‟aide à la décision de groupe [GRUD 94]

La limite essentielle de ce type d‟outils pour la décision coopérative réside dans le

manque de dynamicité de l‟outil. En effet, les tâches et les rôles ne sont pas

dynamiquement affectés. L‟apport principal de ce type d‟outil réside dans l‟agrégation

des préférences des différents décideurs et surtout dans l‟aide au vote ainsi que la

possibilité de faire participer chacun des membres du groupe de manière anonyme.


28

1.4.5.2 Typologies des GDSS

De Sanctis et Gallupe dans [DESA 87] distinguent trois types de GDSS correspondant

aux trois niveaux d‟évolution que ces auteurs ont mis en évidence :

La fonction essentielle des GDSS du premier niveau est d‟améliorer la

communication entre les décideurs.

Les GDSS du deuxième niveau possèdent les mêmes caractéristiques que

ceux du premier niveau, mais 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.

Les GDSS de niveau trois permettraient de façon automatisée de structurer les

échanges d‟information et la communication sur la base de

recommandations émises par des experts. 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.

Quelque soit son niveau d‟évolution, un GDSS intègre différentes fonctions qui

sont respectivement la collecte, le partage et l‟analyse de l‟information.

1.4.5.3 Les GDSS distribués

Actuellement le contexte de la prise de décision a beaucoup évolué. En effet, l‟avancé

technologique en terme de TIC (Technologie de l’Information et de Communication) et

la mondialisation ont engendré de nouvelles exigences qu‟il faudra obligatoirement

considérer. Cette nouvelle situation se caractérise par l‟accroissement de la quantité

d‟informations qui circulent, ainsi que sa diversité. Aussi, la concurrence entre les

organisations exige des prises de décisions efficaces et rapides. D‟un autre côté,

l‟évolution a influé sur les organisations. Ces dernières sont souvent réparties sur

plusieurs sites, ce qui implique la prise en charge de ce nouveau facteur de répartition de

décideurs et de données sur plusieurs endroits de la planète.

Ces environnements nouveaux et dynamiques nécessitent de nouveaux outils d‟aide à la

décision de groupe, les GDSS distribués. Ces derniers tentent de dépasser la contrainte

de l‟éloignement des experts en offrant des outils d‟interaction et de partage de données

et de connaissances afin de répondre au besoin de prise de décisions pertinentes et

rapides.

1.4.5.3.1 Architectures des GDSS distribués

Architecture centralisée

Les prises de décision sont dans ce cas centralisées dans un centre

coordinateur qui est hiérarchiquement supérieur et qui possède l‟ensemble des

informations nécessaires transmises par les centres qu‟il supervise (voir la figure

1.5).

Le principal avantage des systèmes centralisés est leur simplicité, qui est

un facteur important pour le développement de DSS (temps de développement

court et meilleure maniabilité). En outre, la topologie centralisée permet un

contrôle aisé sur les données et les utilisateurs du DSS. En revanche, une


29

telle approche ne permet pas d‟illustrer le caractère distribué des décisions

que l‟on rencontre dans une architecture industrielle quelconque. Par conséquent,

il n‟y a aucune tolérance aux fautes, aucune indépendance du lieu et une faible

extensibilité. Aussi, l‟architecture repose sur une source centrale de

synchronisation. Bien souvent, le rôle de coordination centrale est dévolu à la

base de données. Cet élément représente un point central susceptible de rendre

le système particulièrement fragile et de mettre tout le système hors-service

face à une défaillance du composant central que cela soit local (comme

une panne matérielle) ou externe (comme une panne réseau).

Architecture décentralisée

Cette approche prend en charge le caractère distribué des décisions. Les

systèmes décentralisés (voir figure 1.6) ont des caractéristiques opposées à

celles des systèmes centralisés. Ils sont tolérants aux fautes (dans une

certaine mesure), indépendants du lieu et extensibles. En effet, l‟extension

du système peut être réalisée par l‟ajout de nouveaux composants sans

devoir suspendre le fonctionnement de l‟ensemble. De même, la réplication

des composants importants entre les différents nœuds permet d‟assurer une

certaine capacité de tolérance aux fautes. En revanche elle demande la mise au

point de méthodes spécifiques de gestion pour assurer une cohérence globale

des différents choix. Le principal désavantage de cette topologie réside

dans la difficulté à connaître et à maîtriser l‟état du système.


30

Architecture hybride

Les topologies hybrides sont parfois utilisées pour traiter des cas relatifs à

la synchronisation de données, la réplication de données ou équilibrage de

la charge, mais celles-ci restent fortement basées sur des architectures

centralisées traditionnelles. De plus, de telles topologies hybrides montrent

qu‟elles sont peu utiles dans des situations extrêmes.

Afin de résoudre ces problèmes, la topologie hybride isole quelques

composants jugés «centraux » à l‟architecture dans un anneau (figure 1.7).

De cette manière, ces composants sont clairement identifiés et donc plus

faciles à administrer. Afin de ne pas mettre en danger l‟ensemble du système

en cas de panne de l‟un de ces composants centraux, une certaine

redondance des fonctionnalités et des connections est prévue.


31

1.4.5.3.2 Les GDSS basés sur le Web

Les systèmes d'aide à la décision de groupe basé sur le web sont des systèmes fondés

sur les technologies du web où les utilisateurs accèdent avec des navigateurs du

web via la connexion Internet. Le web est un moyen naturel qui supporte la

collaboration, la prise de décision et la communication entre des équipes distribuées.

Cependant, peu de GDSS à base du web sont disponibles en raison de la difficulté de

construire d‟applications. En effet, le support de la communication interpersonnelle

dans les technologies de collaboration à base du web est limité aux forums de

discussion, l'e-mail, la messagerie instantanée et les outils de conférence audiovisuels.

Les outils d‟aide aux équipes distribuées qui ont été empiriquement testés sont

principalement des systèmes de conférences asynchrones. Ces systèmes ne supportent

pas explicitement les processus de prise de décision et ne fournissent pas souvent d'outils

pour l'évaluation des options alternatives.

1.4.5.4 Aide à la facilitation de la prise de décision collective

Le facilitateur joue un rôle clé dans le processus de prise de décision. De ce fait, il est

souhaitable qu‟il détienne une expertise et une expérience dans la facilitation des

réunions de prise de décision. Il lance et prépare les phases du processus de prise

de décision. Il définit la problématique de la décision et organise le groupe des

décideurs. Sa tâche consiste aussi à modérer les participants et leurs interactions dans

la réalisation des tâches en vue de faire émerger les résultats de la réunion. Il doit

aussi diffuser les résultats aux participants à la fin de la session de prise de décision. Il

motive et guide les participants, particulièrement, dans les environnements distribués où

il est difficile pour les utilisateurs de se voir et d‟interagir. Il gère aussi la transition entre

les phases du processus de prise de décision. Pour assurer sa tâche convenablement, il

est utile d‟utiliser des outils d‟aide à la facilitation. Dans les organisations virtuelles,

l‟utilisation des GDSS est intéressante pour améliorer les décisions en termes de

rapidité dans la prise de décision et de qualité de la décision prise. Pour cela, il faudra

doter le décideur d‟une aide à la décision, et le facilitateur d‟une aide à la facilitation.

Surtout en ce qui concerne la facilitation, car un facilitateur humain hautement qualifié

n'est pas toujours disponible. En ce qui concerne notre projet, nous nous sommes basés

sur la modélisation de l‟aide à la facilitation telle qu‟elle a été présentée dans [ADLA 10].

1.4.6 Outils d’aide à la prise de décision de groupe

Le développement des Technologies de l‟Information et des téléCommunications

(TIC) a favorisé l‟émergence d‟outils d‟aide à la prise de décision puis de nouveaux

types de système appelés systèmes d‟aide à la décision de groupe (GDSS) ou

encore Multi-participant Decision Support Systèmes (MDSS). Ces systèmes permettent

à plusieurs décideurs éventuellement dispersés géographiquement, d‟interagir entre eux

en même temps afin d‟atteindre des objectifs communs.

Il existe des outils qui assistent les utilisateurs (le facilitateur ou bien les participants)

dans le processus de prise de décision collective. Parmi ces outils on trouve :


32

Des logiciels de brainstorming électronique ou de brainwriting2, des outils de votes

collectifs, d‟analyse multicritères, de matrice de consensus, de pondération des

décisions, de génération et d‟annotation des idées, etc.

Dans le contexte de l‟aide à la décision collective coopérative, les premiers

systèmes développés sont : Co-oP3

[BUI 86] et MEDIATOR [JARK 87].

L‟environnement de discussion dans Co-oP est coopératif et distant. Le

système offre une variété de facilités de communication, allant de la messagerie

électronique (e-mail) aux outils de communication de groupe structurés (tels

que Delphi et NGT), et les modèles d‟aide à la décision multicritères pour

l‟échange d‟informations.

MEDIATOR est aussi un GDSS. Il peut être appliqué dans des cas où la situation

devient peu conviviale. Dans un tel cas, le contrôle d‟accès aux données

privées, les représentations de problèmes et des outils pour l‟aide à la

négociation sont nécessaires. Dans MEDIATOR, le groupe est constitué

d‟agents humains, d‟agents machines et inclut un médiateur humain. Le rôle

du médiateur est d‟aider les participants à établir une représentation

commune du problème et, en empruntant une attitude de compromis et de

consensus, de trouver une solution acceptable. La communication est réalisée au

travers des structures de manipulation des données (ceci est similaire au concept

des architectures de tableau noir en IA).

D‟autres outils sont apparus par la suite nous citons :

GroupSystems a été développé à l'Université d'Arizona et a évolué d'un premier

système créé vers la fin des années 1970 appelées ISDOS (Information System

and Optimization System) et rebaptisé plus tard PLEXSYS [NUNA 97]. Alors que

le plus premier système mettait l‟accent sur les tâches d‟analyse et de conception,

vers 1986 le logiciel a été largement révisé pour fournir une aide générale en

faveur d'une large variété de tâches de groupe, et a été rebaptisé GroupSystem.

Le logiciel est conçu comme une boite outils supportant quatre domaines: “(1)

Exploration et génération d'idée, (2) Organisation d'idée, (3) Priorisation et

évaluation alternative et, (4) outils fournissant des méthodologies formelles pour

supporter le développement et l‟évaluation” [WAGN 93]. GroupeSystem a connu

un succès commercial et a été largement utilisé par de nombreuses organisations.

Il a acquis de loin la part de marché dominante pour le logiciel GSS et a aussi été

utilisé par beaucoup de chercheurs [AGRE 05], [DENN 93], [DEVR 06], [NUNA

97]. GroupSystems, la compagnie, offre maintenant trois produits :

GroupSystems I & II et ThinkTank.

Decision Explorer4 est un outil conçu pour gérer les informations qualitatives qui

entourent des situations complexes ou incertaines. Il permet de capter en détail

2

Est une variante de la technique du « Brainstorming ». Il s‟agit de produire par écrit et de façon

anonyme, une liste exhaustive d‟idées, de problèmes, et de solutions par rapport à un thème, une situation,

un problème donné. 3 Co-oP : A Group Decision Support System for Cooperative Multiple Criteria Group Decision Making.

4 Banxia Software Ltd. web site. Decision Explorer R_main page, July 14 (2009)

http://www.banxia.com/dexplore/overviewof-decision-explorer.html

http://www.banxia.com/dexplore/overviewof-


33

des pensées et des idées, de les explorer et obtenir une nouvelle compréhension

et réflexion. Decision Explorer a été développé pendant plusieurs années par les

académiciens des universités de Bath et Strathclyde et maintenant par Banxia

Software Ltd. Le résultat final d'utilisation de Decision Explorer est une carte

visuelle de la structure probleme/situation, i.e. les éléments et leurs relations tels

qu‟ils sont perçus par le group. Cela permet une compréhension largement

partagée du problème et mène souvent à un consensus autour d'une issue future.

Bien qu‟il adopte une approche différente d‟aide à la prise de décision de

groupe, comme GroupeSystems, c'est un outil général qui peut être appliqué à

une large variété de problèmes et de situations [ACKE 05].

Meetingworks a évolué d'un projet de doctorat au début des années 1980 [LEWI

07]. Alors que la version initiale (appelé Facilitateur) implémentait un seul

processus de réunion, la Technique de Groupe Nominale, les dernières versions

sont devenues plus complexes et ont inclus une boite à outils constituée de

plusieurs modules logiciels qui pourraient être combinés de façon souple pour

correspondre à une tâche de groupes. Bien qu‟il a été distribué à un grand

nombre d'universités à des fins de recherche, il a été aussi commercialisé au

début des années 1990 et depuis, il a été utilisé constamment pour l‟aide à la

prise de décision de groupe dans beaucoup d‟organisations.

TCBWorks, est l‟un des systèmes GDSS basées sur le web de la première

génération [DENN 96]. Il a été conçu pour permettre aux membres d'une équipe

d‟interagir, de discuter des options de solutions et prendre des décisions.

TCBWorks a utilisé les technologies web de première génération pour

développer des GDSS basés sur le web. TCBWorks a combiné la discussion

structurée et la prise de décision multicritères dans un outil et ne supporte pas

explicitement de processus de prise de décision de groupe.

Un produit supplémentaire appelé GroupIntelligence est un outil de reporting

basé sur le web dédié pour les produits GroupSystems. Par conséquent,

GroupSystems a été utilisé exclusivement dans les environnements de salle de

décision face à face avec les réseaux d'ordinateurs fonctionnant sous Windows.

1.5 Conclusion

Dans ce chapitre, nous avons abordé le domaine de l‟aide à la décision, nous avons

commencé par donner une vue globale sur les principes de la théorie de la

décision. Les systèmes interactifs d‟aide à la décision, produits de premières génération

des recherches dans ce domaine, sont décrits en termes de fonctionnalités, structures et

classification. Ensuite, nous avons présenté l‟aide à la décision de groupe. En effet,

l‟évolution des structures organisationnelles due principalement à des enjeux

économiques a favorisé la participation collective dans la prise de décision et de ce fait

l‟apparition des SIAD de groupe (GDSS). Ces derniers fondés sur les concepts de

groupe, coopération et collaboration sont privilégiés relativement à la séparation et à

l‟isolement d‟où l‟utilisation nécessaire des outils de TCAO. Les SIAD coopératifs

exploitent la coopération homme-machine pour supporter l‟utilisateur dans sa tâche de

prise de décision, en mettant en évidence le rôle primordial de l‟utilisateur dans ce

processus. Les GDSS quant à eux, fournissent un soutien aux décideurs durant le


34

processus décisionnel et mettent en œuvre des collecticiels et outils de collaboration

souvent dans des contextes distribués. Ils sont donc conçus pour fournir des réponses

rapides et faciliter la prise de décisions grâce à l‟apport de nombreux outils :

brainstorming, votes, pondération des décisions, génération et annotation des idées,

etc. Les GDSS peuvent être centralisés ou distribués. Mais l‟évolution des TIC à

favorisé l‟approche distribué en faisant participer les individus géographiquement

dispersés dans le processus d‟aide à la décision collective.

Les systèmes d‟aide à la décision de groupe distribués sont par essence coopératifs ou

collaboratifs et, à ce titre, la technologie agent, et en particulier, les systèmes multi-

agents s‟apprêtent particulièrement à leur développement. Nous consacrons le chapitre

suivant à la présentation des systèmes multi-agents.

CHAPITRE II

LES SYSTEMES MULTI-AGENTS

Chapitre II. Les Systèmes Multi-Agents

36

2.1 Introduction

Les systèmes d‟Intelligence Artificielle (IA) sont devenus complexes relativement à

l‟évolution des domaines d‟application comme l‟aide à la décision, la conduite des

processus industriels etc. En effet, l‟approche classique de l‟IA qui considère le

comportement intelligent du système dans un seul agent a montré ses limites. Par

conséquent, l‟Intelligence Artificielle Distribuée (IAD) est apparue vers la fin des

années 1970 [HEWI 77]. L‟IAD propose une nouvelle vision de la conception des

systèmes et considère la modélisation du raisonnement sur la base de la distribution des

connaissances sur plusieurs entités.

Les Systèmes Multi-agents sont une branche de L‟IAD. Ils sont apparus dans le courant

des années 80. Ils sont à la connexion de plusieurs domaines en particulier de

l‟intelligence artificielle, des systèmes informatique distribués et du génie logiciel

[JARR 02]. Les systèmes multi-agents s‟intéressent à la résolution de problèmes

complexes en se basant sur la distribution de la connaissance et des compétences sur un

ensemble d‟entités autonomes. Par ailleurs, ces entités s‟appuient sur une organisation

ainsi que des interactions qui leurs confèrent un comportement global cohérent et

collectif. Ce dernier se traduit par la coopération, la résolution de conflits, la négociation

etc. Dans ce genre de système, un comportement global performant peut aussi être

produit par émergence à partir du comportement local d‟entités moins performantes.

C‟est le cas de l‟étude des organisations sociales des insectes tels que les fourmis, les

abeilles et les termites. Les SMA sont particulièrement utiles, pour résoudre des

problèmes et concevoir des systèmes qui sont physiquement et/ou fonctionnellement

distribués.

Dans ce chapitre, nous allons tenter de cerner le domaine des systèmes multi-agents.

Nous l‟abordons d‟abord sous l‟aspect « agent » en présentant les caractéristiques

relatives à cette unité de base du système multi-agents. Puis, nous passons à la

dimension collective du système en présentant les caractéristiques telles que la

coopération, la coordination, l‟organisation, la négociation etc. Nous terminons le

chapitre par quelques méthodes de conception ainsi que les plates-formes de

développement des systèmes multi-agents.

2.2 Pourquoi s’intéresser aux systèmes multi-agents ?

Les systèmes multi-agents sont particulièrement appropriés lorsqu‟on s‟intéresse aux

systèmes complexes. En effet, ils permettent de reproduire le fonctionnement global

d‟un système complexe à partir des entités qui le compose et de leurs interactions

[JAMO 05]. C‟est un nouveau niveau d‟abstraction qui permet d‟exprimer une

application en termes d‟agents autonomes qui jouent des rôles et rendent des services

dans une organisation [GLEI 08].

Le développement de l‟informatique en termes de puissance des machines, l‟évolution

des réseaux particulièrement le Web et l‟augmentation de la masse d‟informations à

traiter et à stocker ont engendré des besoins en applications assez complexes. En

général, ces dernières sont physiquement et fonctionnellement distribuées. Les systèmes

multi-agents répondent à ce genre d‟applications, ils permettent la conception modulaire

du système. Les modules peuvent être répartis sur plusieurs machines. Un module est

plus simple à concevoir qu‟un programme monolithique. De plus, la maintenance du

système est plus facile, l‟amélioration d‟un traitement est localisé en général au niveau


37

d‟un (ou d‟un sous ensemble d‟) agent (s). L‟approche par les systèmes multi-agents

propose des solutions robustes et capables de s‟adapter dans des environnements qui

peuvent être aussi imprévisibles que l‟Internet. Par ailleurs, le problème de ce genre de

systèmes réside dans la coordination et la gestion des interactions entre les agents. C‟est

la maitrise de ces interactions qui permettra aux agents qui sont autonomes, souvent

hétérogènes, mais fonctionnant dans un environnement commun de réaliser une

fonction cohérente dans un cadre collectif et de former ainsi un système.

2.3 Le concept d’agent

Les systèmes multi-agents, comme leur nom l‟indique, sont des systèmes constitués de

plusieurs agents. Nous commençons d‟abord par définir la notion d‟agent.

Le concept d‟agent a été l‟objet de plusieurs études durant plusieurs décennies dans

différentes disciplines. Le terme agent est un terme générique qui se rapporte à

différentes entités. Il a été utilisé dans les systèmes à base de connaissances biologiques

(les agents associés sont appelés agents biologiques), des robots autonomes, des

logiciels informatiques et leurs composants qu‟ils soient intégrés dans des systèmes

d‟exploitation ou des systèmes informatiques complexes, le langage naturel et d‟autres

domaines de l‟intelligence artificielle. Mais, aussi dans des disciplines comme la

philosophie et la psychologie.

Dans la littérature, on trouve une multitude de définitions d‟agents. Elles se ressemblent

toutes, mais diffèrent selon le type d‟application pour laquelle est conçu l‟agent. Aussi,

avec l‟avènement des nouvelles technologies et l‟expansion de l‟Internet, ce concept a

été encore associé à plusieurs nouvelles applications comme agent ressource, agent

courtier, assistant personnel, agent interface, agent ontologique, etc. [FRAN 96] [JARR

02] [FIKE 71].

2.3.1 Définitions d’un agent

Différentes définitions d‟un agent sont données le monde de l‟intelligence artificielle

distribuée. Il est donc nécessaire, pour avoir une bonne vision de ce concept, de

présenter plusieurs d‟entre elles.

Selon Ferber [FERB 95] « un agent est une entité autonome, réelle ou abstraite, qui est

capable d'agir sur elle-même et sur son environnement et qui, dans un univers multi-

agents, peut communiquer avec d'autres agents, et dont le comportement est la

conséquence de ses observations, de ses connaissances et des interactions avec les

autres agents ». Il le définit aussi comme étant « une entité physique ou virtuelle

évoluant dans un environnement dont il n‟a qu‟une représentation partielle et sur

lequel il peut agir. Un agent est capable de communiquer avec d‟autres agents et est

doté d‟un comportement autonome. Un agent possède généralement des accointances

qui sont l‟ensemble des agents avec lesquels il communiquent ou bien interagit ».

Selon Yves Demazeau [DEMA 96], « un agent est une entité réelle ou virtuelle dont le

comportement est autonome, évoluant dans un environnement qu‟il est capable de

percevoir et sur lequel il est capable d‟agir et d‟interagir avec les autres agents ».


38

Ces définitions abordent aussi l‟interaction qui, comme nous le verrons dans la suite de

ce chapitre, est le moteur des systèmes multi-agents. En effet, l‟interaction suppose la

présence d‟agents capables de communiquer, de collaborer et d‟agir.

Jennings, Sycara et Wooldridge [JENN 98] ont proposé la définition suivante : « Un

agent est un système informatique, situé dans un environnement, et qui agit d‟une façon

autonome et flexible pour atteindre les objectifs pour lesquels il a été conçu. »

Les notions “situé”, “autonome” et “flexible” sont définies comme suit :

1) situé : l‟agent est capable d‟agir sur son environnement à partir des entrées

sensorielles qu‟il reçoit de ce même environnement. Exemples: systèmes de

contrôle de processus, systèmes embarqués, etc.,

2) autonome : l‟agent est capable d‟agir sans l‟intervention d‟un tiers (humain ou

agent) et contrôle ses propres actions ainsi que son état interne;

3) flexible : l‟agent dans ce cas est capable de répondre à temps. Pour cela, l‟agent

doit être capable de percevoir son environnement et élaborer une réponse dans

les temps requis.

Pour Wooldridge [WOOL 99], un agent est un système informatique capable d‟agir de

manière autonome et flexible dans un environnement. Par flexibilité on entend :

1) Réactivité : un système réactif maintient un lien constant avec son

environnement et répond aux changements qui y surviennent.

2) Pro-activité : un système proactif (aussi appelé téléonomique) génère et satisfait

des buts. Son comportement n‟est donc pas uniquement dirigé par des

événements. L‟agent doit avoir un comportement opportuniste et être capable de

prendre l‟initiative au “bon” moment.

3) Capacités sociales : la dimension sociale implique que l‟accent est mis sur le

groupe plutôt que sur l‟agent individuel. Elle propose d‟organiser le système en

une société d‟agents. Dans un tel système les agents sont capables d‟interagir et

de coopérer entre eux.

Presque toutes ces définitions abordent une notion essentielle : l‟autonomie. En effet, ce

concept est au centre de la problématique des agents. L‟autonomie est la faculté d‟avoir

ou non le contrôle de son comportement sans l‟intervention d‟autres agents ou d‟êtres

humains. Une autre notion importante abordée par ces définitions concerne la capacité

d‟un agent à communiquer avec d‟autres agents. Par ailleurs, ces définitions sont le

résultat de différentes approches de conception de système multi-agents. En effet,

chaque approche se base sur un type particulier d‟agent.

2.3.2 Les typologies des agents

Un agent évolue dans un environnement, il doit être en mesure de recevoir des

informations de cet environnement par des récepteurs, et d‟agir sur ce même

environnement par des effecteurs, suivant un comportement décidé selon le raisonnement

de l‟agent. L‟agent est caractérisé par son architecture et son comportement.

L‟architecture reste liée au point de vue du concepteur, à la manière d‟assembler les

différentes parties de l‟agent afin que ce dernier puisse accomplir ce qui est attendu de

lui. Selon les architectures et les capacités, les agents sont classés en plusieurs types qui

les qualifient de cognitifs, réactifs ou hybrides.


39

La figure 2.1 illustre l‟architecture simplifiée d‟un agent en termes de composants

fonctionnels.

2.3.2.1 Agents cognitifs

Les agents à capacités cognitives proviennent d‟une métaphore du modèle humain. Ces

agents possèdent une représentation explicite de leur environnement, des autres agents

et d‟eux-mêmes [DEMA 90] [JENN 92] [FERB 95].

Les agents cognitifs ont la particularité d‟avoir la composante décision c'est-à-dire le

raisonnement assez développée. Ainsi, ils disposent d‟une base de connaissances

comprenant les diverses informations liées à leurs domaines d‟expertise et à la gestion

des interactions avec les autres agents et leur environnement. De plus, l‟interaction

permet aux agents de communiquer, de collaborer et d‟agir. De ce fait, ils sont

capables de prendre des décisions à partir des informations dont ils disposent et

de planifier leurs actions à l'avance. Ils possèdent en général des plans explicites leur

permettant d‟accomplir leurs buts. Ils sont structurés en société où il règne une véritable

organisation sociale. Dans ce cas, ils peuvent coopérer en cordonnant leurs activités et

peuvent parfois négocier pour résoudre des conflits. Le travail le plus représentatif de

cette famille d‟agents porte sur le modèle BDI (Beliefs, Desirs, Intentions) [BRAT 87]

voir la partie 3.2.3.

2.3.2.1.1 Les caractéristiques d’un agent intelligent

Les approches de conception d‟agents sont variées et en perpétuelle évolution. Toutefois,

nous pouvons identifier quelques caractéristiques qu‟un agent doit posséder pour qu‟il

puisse être qualifié d‟agent intelligent. Il est clair qu‟un agent ne doit pas posséder toutes

ces caractéristiques en même temps, mais il suffit qu‟il soit doté de certaines d‟entre elles

pour qu‟il puisse être considéré comme intelligent ou bien cognitif :

1) Autonomie : l‟agent doit pouvoir prendre des initiatives et agir sans

l'intervention d'un tiers (humain ou agent) et contrôler ses propres actions ainsi

que son état interne. Car ce qui distingue fortement un agent d‟un autre type de

logiciel c‟est l‟objectif qu‟il possède et qui lui permet d‟être autonome ;

Composante

Décision

Composante

Perception

Environnement

Figure 2.1 : Fonctionnement d‟un agent selon [DEMA 96]

Composante

Exécution

(Action)

Agent


40

2) Situation : l'agent est capable d'agir sur son environnement à partir des entrées

sensorielles qu'il reçoit de ce même environnement ;

3) Interactivité : L‟agent doit pouvoir exercer des actions sur son environnement

et réciproquement ;

4) Réactivité : l'agent doit être capable de percevoir son environnement et

d'élaborer une réponse dans le temps requis. L‟agent perçoit son environnement

qui peut être l‟utilisateur à travers une interface graphique, un ensemble

d‟agents, etc. Il doit répondre dans les temps impartis aux changements qui

surviennent sur cet environnement. Par exemple un agent de sauvegarde doit

exécuter sa tâche suite à un événement survenu dans son environnement et qui

lui demande de sauvegarder ;

5) Proactivité : un système proactif génère et satisfait des buts. Son comportement

n‟est donc pas uniquement dirigé par des événements. Il doit avoir un

comportement opportuniste, et donc, être capable de prendre l'initiative au bon

moment ;

6) Capacité d’apprendre : un agent aura la capacité d‟apprendre s‟il sait acquérir

de la connaissance, de l‟information ou des habitudes :

7) Capacité sociale : les agents s‟entraident pour l‟accomplissement de leurs

tâches. Pour cela, ils doivent posséder des capacités sociales qui leurs confèrent

la possibilité de jouer des rôles et d‟interagir dans le contexte de ces rôles ;

8) Coordination : l‟agent est capable de coordonner ses actions par rapport à un

utilisateur ou un autre agent ;

9) Compétition : l‟agent est capable d‟agir dans un environnement où d‟autres

agents interviennent. Le but est le même pour tous les agents présents mais un

seul l‟atteindra, les autres échoueront.

10) Mobilité : généralement on parle de deux types de mobilité d‟agent : la mobilité

relative ou bien par requête et la mobilité réelle. Dans le cas du premier type, il

n‟y a pas un réel déplacement de l‟agent. Celui-ci lance une succession de

requêtes à destination des différents serveurs. C‟est le cas des agents de

recherche, tel que Copernic5 qui interroge différents moteurs de recherches afin

de fournir à l‟utilisateur une synthèse des différents résultats. Dans le second

cas, le processus agent se déplace sur le réseau d‟un serveur à un autre. Le code

de l‟agent est transporté et ses données aussi. Ensuite, il continue son exécution

sur la nouvelle machine ;

11) Délégation : l‟agent accomplit un ensemble de tâches à la demande d‟un

utilisateur ou d‟un autre agent ;

12) Communication : l‟agent a des capacités d‟interaction. Cette dernière peut être

avec l‟utilisateur au moyen d‟interface utilisateur ou bien inter-agents. Dans ce

5 http://www.copernic.com.


41

deuxième cas, cela suppose que l‟agent est doté de connaissances sur autrui (les

accointances) ainsi que des capacités de communication basées sur un langage

de communication commun à tous les agents comme FIPA-ACL ou KQML

(voir la partie 2.5.1.2.1).

2.3.2.2 Agents réactifs

Les agents à capacités réactives ne disposent que d'un protocole et d'un langage de

communication réduit, ils n'ont pas une représentation explicite de leur environnement

et ne sont pas capables de tenir compte de leurs actions passées. Ils ne possèdent pas de

moyen de mémorisation. Ils ne peuvent répondre qu‟à la loi de stimulus/action. En

effet, dès qu‟ils perçoivent une modification de leur environnement, ils répondent par

une action programmée. Ils sont constamment en état de veille sur les changements de

leur environnement. Leurs actions rapides et non réfléchies sont similaires à des

réflexes. Ainsi, ce n'est pas au niveau de l'individu que les agents réactifs sont

intéressants, mais au niveau de la population et des capacités d'adaptation et

d'évolution qui émergent des interactions entre ses membres [FERB 94]. Ces agents

ont des capacités de raisonnement très limitées, mais leurs interactions permettent

l'émergence d'une intelligence collective.

Les caractéristiques d‟un agent réactif peuvent être définies par les points suivants:

1) La prise de décision d‟un agent est réalisée à travers un ensemble de modules

comportementaux correspondant à la tâche à réaliser. Chaque comportement est

implémenté sous la forme de la règle suivante : situation → action ;

2) Lorsque plusieurs comportements peuvent être déclenchés à un instant donné, la

résolution de conflits peut être assurée par l‟arrangement des modules d‟action

dans une hiérarchie de subsomptions [BROO 86] selon différentes couches où

les hauts niveaux peuvent inhiber les niveaux inférieurs.

Les travaux sur ces agents s‟intéressent plus à la modélisation d‟une société d‟agents

qu‟à l‟agent lui-même et tirent leurs sources des sciences de la nature. L‟exemple le

plus célèbre est celui de la fourmilière étudié par Alexis Drogoul [DROG 93].


42

2.3.2.3 Les agents BDI (Beliefs, Desirs, Intentions)

Ce type d‟agents fait partie de la classe plus large des agents cognitifs. En effet, dans le

cadre du raisonnement pratique qui est un raisonnement orienté vers la prise en compte

des états mentaux, les chercheurs ont développé l‟architecture BDI [BRAT 87] [BOIS

96], (de l’anglais Belief, Desire, Intention pour croyance, désir, et intention), une

architecture bâtie autour du raisonnement pratique. Ces agents sont généralement

représentés par un “état mental” ayant les attitudes mentales suivantes:

1) Les croyances : Ce que l‟agent connaît de son environnement.

2) Les désirs : Les états possibles envers lesquels l‟agent peut vouloir s‟engager.

3) Les intentions : Les états envers lesquels l‟agent s‟est engagé, et envers lesquels

il a engagé des ressources.

Un agent BDI doit donc mettre à jour ses croyances avec les informations qui lui

proviennent de son environnement, décider quelles options lui sont offertes, filtrer ces

options afin de déterminer de nouvelles intentions et poser ses actions au vu de ses

intentions. Le processus de décision permet de sélectionner les actions à effectuer pour

atteindre ses objectifs. Dans ces modèles, le processus se décompose en deux phases :

La première est appelée phase de délibération, elle consiste à fixer certains buts. La

seconde correspond à une phase de planification, elle consiste à définir la manière

d‟atteindre ces buts.

Dans ce modèle, les intentions sont importantes. Elles guident la planification, elles

limitent aussi les délibérations et elles influencent les croyances futures sur lesquelles se

base le raisonnement. L‟équilibre entre ces différents aspects représente l‟une des clés

de la conception d‟agents BDI. Cependant, le compromis entre la poursuite d‟une

intention ou son abandon est une fonction particulièrement difficile à concevoir.


43

Le modèle BDI est intéressant non seulement par ce qu‟il est intuitif, mais aussi par ce

qu‟il fournit une bonne décomposition fonctionnelle qui identifie clairement les sous-

systèmes nécessaires à la conception d‟un agent. Toutefois, la principale difficulté reste

toujours l‟implémentation efficace de ces sous-systèmes [PICA 04a].

2.3.2.4 Agents hybrides ou mixtes

Dès le début des années 90, on s‟est rendu compte que les systèmes réactifs et les

systèmes cognitifs ne pouvaient convenir à la résolution de tous les problèmes. Chacun

de ces deux types de systèmes convient à certains types de problèmes et moins bien

pour d‟autres. Dés lors, les chercheurs ont essayé de combiner les deux approches afin

d‟obtenir une architecture hybride [CHAI 94], [FERG 92], [JARR 02].

2.3.2.4.1 Architecture à organisation modulaire

Dans ce cas, un agent est composé de plusieurs couches arrangées selon une hiérarchie.

La plupart des architectures considèrent que trois couches suffisent amplement.

Dans ce contexte un agent est composé de trois couches arrangées selon une hiérarchie:

1) La première au plus bas niveau de l‟architecture est une couche purement

réactive, qui prend des décisions en se basant sur des données brutes en

provenance des senseurs.

2) La deuxième est la couche intermédiaire qui fait abstraction des données brutes

et travail avec une vision qui se situe au niveau des connaissances de

l‟environnement.

3) La troisième est la couche supérieure qui se charge des aspects sociaux de

l‟environnement c'est-à-dire du raisonnement en tenant compte des autres

agents. La figure 2.4 illustre l‟architecture d‟un agent hybride.

Les agents hybrides sont des agents ayant des capacités cognitives et réactives. Ils

conjuguent en effet la rapidité de réponse des agents réactifs ainsi que les capacités de

raisonnement des agents cognitifs. Les architectures ASIC [BOIS 96] utilisée pour le

traitement numérique d‟images, ARCO [RODR 94] créée dans le cadre de la robotique

collective et ASTRO [OCCE 98] développée pour être utilisée dans les systèmes multi-

agents soumis à des contraintes de type temporelles en sont des exemples. Pour illustrer

le mode de conception et de développement utilisé dans ce type d‟architecture, nous

présentons dans ce qui suit le modèle d‟architecture d‟agents DIMA


44

2.3.2.4.2 Le modèle d’architecture d'agents DIMA (Développement et

Implémentation de systèmes Multi-Agents)

Les agents hybrides à organisation modulaire combinent des propriétés cognitives et

réactives généralement logées dans des modules différents. Ce type d'architecture pose

le problème du contrôle à deux niveaux : la coordination classique entre agents, et la

coordination entre modules au sein même de l'agent [GUES 96] [GUES 02]. Il est de ce

fait difficile d‟utiliser cette architecture pour concevoir un agent dont le comportement

est très simple (réactif).

Ces architectures hybrides ne résolvent pas le problème de granularité. Elles ne

permettent pas la conception de systèmes multi-agents dont la granularité des agents est

variable. Pour pallier ce problème, Guessoum dans [GUES 02] a proposé un modèle

d‟architecture qui dépasse la dichotomie classique, le modèle d‟architecture d'agents

DIMA. L‟auteur propose de décomposer chaque agent en différents composants. Un

agent peut ainsi avoir un ou plusieurs composants qui peuvent être réactifs ou cognitifs

(voir Figure 2.5). La modularité offre ainsi plusieurs avantages à cette architecture :

1) Possibilité de définir des agents à granularité variable.

2) Possibilité de définir des agents à structure adaptative. Chaque agent peut

dynamiquement changer ses composants ainsi que les relations entre ces

différents composants.

3) Possibilités d‟intégrer différents modèles d‟agents.

4) Possibilité de définir des bibliothèques de composants réutilisables.

Ainsi, le modèle d‟architecture d‟agents proposé par Guessoum [GUES 02] dans la plate-

forme DIMA peut être vu comme un modèle „ouvert‟, une proposition d‟agent minimal

est faite permettant, par étapes successives, d‟ajouter des fonctionnalités fournies par les

différentes bibliothèques de la plate-forme. Chaque agent est un composant simple ou

composite [MEUR 01] qui gère l‟interaction de l‟agent avec son environnement et qui

représente son comportement interne. L‟environnement regroupe tous les autres agents

ainsi que les entités qui ne sont pas des agents.

2.3.3 Structure d’un agent

Ferber [FERB 95] propose une structure générale qu‟un agent possède tel que : le savoir

faire, les croyances, le contrôle, l‟expertise et la communication.


45

1) Le savoir faire : c‟est une interface permettant la déclaration des connaissances

et des compétences de l‟agent. Il permet aussi, la sélection des agents à solliciter

pour une tache donnée ;

2) Les croyances : ce que l‟agent connaît du monde (la représentation de son

environnement, les autres agents et lui-même). On préfère parler de croyances

au lieu de connaissances car dans un système multi-agents les connaissances que

l‟agent a sur lui même et sur les autres agents ne sont pas nécessairement

objectives. Cependant, la formalisation de ces connaissances sera à la base de la

conception de tout système multi-agents car elle détermine en grande partie le

comportement « intelligent » des agents ;

3) Le contrôle : la connaissance du contrôle dans un agent est représentée par les

buts, les intentions, les plans et les tâches qu‟il possède ;

4) L’expertise : c‟est la connaissance sur la résolution du problème. C‟est la base

de règles par exemple pour un système expert ;

5) La communication : pour que deux personnes puissent communiquer, ils

doivent parler la même langue. Dans le cas des agents, le même principe

s‟impose c‟est pourquoi la création d‟un langage commun à tous les agents

s‟imposait pour assurer une bonne communication et une bonne coordination

d‟actions. Ce langage n‟est autre que l‟ensemble de primitives connues par

chaque entité et dont l‟ensemble constitue un contrôle de communication.

2.4. Les systèmes multi-agents

2.4.1 Définitions

G. Weiss dans [WEIS 99], a défini l‟intelligence artificielle distribuée comme étant

l‟étude, la conception et la réalisation de systèmes multi-agents qu‟il présente comme

étant des systèmes dans lesquels des agents intelligents interagissent et poursuivent un

ensemble de buts ou réalisent un ensemble d‟actions.

Dans la littérature il existe plusieurs définitions des systèmes multi-agents, nous

présentons quelques unes afin de montrer les différents aspects des SMA et les

caractéristiques les plus importantes.

« Les systèmes multi-agents mettent en œuvre un ensemble de concepts et de techniques

permettant à des logiciels hétérogènes ou à des parties de logiciels, appelées « agents »

de coopérer suivant des modes complexes d‟interaction. Ils sont destinés à travailler

ensemble afin de résoudre des problèmes qui dépassent leurs capacités ou connaissances

individuelles et profitent des divers rôles de chacun des agents du système » [FERB 95].

Ferber [FERB 95] a aussi défini un système multi-agents comme étant un système

composé des éléments suivants :

1) Un environnement E, c‟est à dire un espace disposant généralement d‟une

métrique ;


46

2) Un ensemble d‟objet O situés, c‟est à dire pour tout objet, il est possible, à un

moment donné, d‟associer une position dans E. de plus, 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ération Op, permettant aux agents de A de percevoir, produire,

consommer, transformer et manipuler des objets de O ;

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 appelle les lois de

l‟univers.

« Un système multi-agent est un système distribué composé d‟un ensemble d‟agents.

Contrairement aux systèmes d‟IA qui simulent dans une certaine mesure les capacités

du raisonnement humain, les SMA sont conçus et implantés idéalement comme un

ensemble d‟agents interagissants, le plus souvent, selon des modes de coopération, de

concurrence ou de coexistence » [JARR 02].

Un agent qui fait tout serait difficile à créer, à maintenir et il aurait des temps de

réponses assez faibles. C‟est de là que découle l‟intérêt des systèmes multi-agents.

Un système multi-agents est un ensemble d‟agents réactifs ou cognitifs, réels ou virtuels

qui fonctionnent collectivement au sein d‟un environnement commun. Ce dernier, doit

permettre aux agents de percevoir, d‟interagir et d‟agir.

2.4.2 L’environnement

Dans un système multi-agents, on appelle environnement l‟espace commun aux agents

du système. Un environnement peut être [WOOL 00] :


47

1) Accessible/inaccessible (observable/non observable) : Accessible si un agent

peut, à l‟aide des primitives de perception, déterminer l‟état de l‟environnement

et ainsi procéder, par exemple, à une action. Si l‟environnement est inaccessible

alors il faut que l‟agent soit doté de moyens de mémorisation afin d‟enregistrer

les modifications qui ont survenues ;

2) Déterministe/non Déterministe : selon que l‟état futur de l‟environnement ne

soit, ou ne soit pas, fixé que par son état courant et les actions de l‟agent. Dans

un environnement déterministe, une action a un effet unique garanti ;

3) Discret/continu : discret si le nombre des actions faisables et des états de

l‟environnement est fini.

2.4.3 Les caractéristiques d’un système multi-agents

Un SMA est généralement caractérisé par :

1) Chaque agent possède des informations et/ou des capacités de résolution de

problèmes limitées, ainsi chaque agent a un point de vue partiel ;

2) Il n‟y a pas de contrôle global du système multi-agents. Mais, dans le cas du

contrôle centralisé, il peut exister une entité qui a une vue globale de l‟activité

du système et qui a la charge de contrôler tout le système ;

3) Les données et les connaissances sont décentralisées.

Les agents d‟un système multi-agents n‟ont pas une vision globale du système. Ils n‟ont

qu‟une vision limitée de leur environnement et des autres agents. Chacun ne renferme

qu‟une partie de la connaissance et qu‟une partie des compétences du système. Ils

doivent être dotés de mécanismes comme la communication, la coopération, la

coordination, une certaine organisation etc. afin de parvenir à une résolution collective

du problème.

2.5. L’interaction

Une interaction est une mise en relation dynamique de deux ou plusieurs agents par le

biais d‟un ensemble d‟actions réciproques. C‟est grâce à l‟interaction que le SMA est vu

comme un tout et non pas comme un ensemble d‟entités indépendantes. Pour un agent,

interagir avec un autre constitue à la fois la source de sa puissance et l‟origine de ses

problèmes [FERB 95]. Interagir permet à un agent de partager des informations et des

services afin d‟atteindre ses buts et d‟éviter les conflits. Une interaction, si elle est

entamée, elle doit se dérouler correctement et se terminer également correctement. C‟est

pour cela que les interactions sont structurées selon des schémas typiques appelés

protocoles.

Les protocoles d‟interaction permettent aux agents d‟échanger des messages structurés

et de contrôler l‟échange de ces messages et ainsi faciliter leur coordination. Un

protocole d‟interaction spécifie des règles qui doivent être respectées par les agents

durant une conversation, et définit ainsi pour chaque étape les types de messages qui


48

peuvent être envoyés. En suivant un protocole, un agent interprète les messages d‟une

conversation un par un, en changeant son propre état à chaque étape, et exploite le

protocole pour produire le prochain message de la conversation [TRAN 08].

On distingue généralement différentes situations d‟interactions entre les agents : la

communication, la coopération, la négociation et la coordination.

2.5.1 La communication

La communication est un des éléments importants du système multi-agents. C‟est

l‟élément de base de toute interaction. Elle permet l‟échange des informations entre

deux agents. En communiquant, les agents peuvent échanger des informations et

coordonner leurs activités. Aussi, c‟est grâce à la communication que les différents

protocoles d‟interaction sont exécutés. Les agents peuvent interagir en communiquant

directement entre eux par envoi de messages voire même par l‟établissement de

conversations structurées entre eux, ou bien en agissant sur leur environnement. Par

conséquent, la communication entre agents peut être une communication directe ou

indirecte.

2.5.1.1 La communication indirecte

Elle est utilisée par les agents réactifs. Elle se fait à travers l‟environnement ou bien par

le biais d‟un tableau noir.

1) Dans une communication par environnement, les agents laissent des traces ou

des signaux qui seront perçus par les autres agents. Dans ce genre de

communication, il n‟y a pas de destinataire bien défini.

2) La communication par tableau noir est une communication par partage

d‟information par le biais d‟une mémoire partagée accessible par l‟ensemble des

agents : le tableau noir. Elle est composée de trois éléments : les connaissances,

le tableau noir, et le mécanisme de contrôle. Dans ce type de communication, les

agents ne communiquent pas directement entre eux, mais les interactions se

déroulent via l‟environnement au moyen d‟un espace de travail partagé. Ils

peuvent, ainsi, écrire des messages, insérer des résultats partiels de leurs calculs

et obtenir de l‟information. Le tableau noir est en général partitionné en

plusieurs niveaux qui sont spécifiques à l‟application [JARR 02].


49

2.5.1.2 La communication directe

Elle est propre aux agents cognitifs, car, ces derniers relativement aux agents réactifs,

ont des connaissances sur eux-mêmes et sur autrui. Ils ont aussi des connaissances sur

leurs accointances, ainsi que des intentions et des compétences communicationnelles

qui leur permettent d‟envoyer des messages à un ou plusieurs agents et d‟interpréter les

messages reçus de la part des autres agents (voir la figure 2.8).

Depuis les années cinquante, la théorie dominante, aussi bien en philosophie du langage

qu'en linguistique computationnelle, est la théorie des actes de langage qui a été

développée par Austin [AUST 62]. Elle est appliquée aux systèmes multi-agents via les

langages de communication des agents. La communication directe se base sur trois

éléments essentiels :

1) Le langage de communication : il permet de structurer les messages échangés

entre les agents. Les langages de communication les plus utilisés et les plus

connus sont KQML (Knowledge Query and Manipulating Langage) [FINI 95] et

FIPA-ACL (Agent Communication Language de FIPA6) [FIPA 99]. Ils sont basés

sur la théorie des actes de langages [AUST 62].

2) L‟ontologie : elle sert à fournir un vocabulaire et une terminologie

compréhensible par tous les agents. Cette sémantique sera régie par des règles et

des contraintes qui permettront de définir un consensus sur le sens des termes

contenus dans les messages.

3) Les mécanismes de communication : ils permettent de stocker, rechercher et

adresser les messages aux agents. Ces mécanismes sont présents dans les plates

formes multi-agents comme Jade (Java Agent DEvelopement framework) [BELL

06] ou MadKit [GUTK 00a] [GUTK 00b].

Un acte de langage renferme trois composantes :

1) La composante locutoire : elle concerne la syntaxe du message, le medium

(écrit, oral, etc.) et les qualités de transmission (voix en colère, typographie,

etc.).

6 FIPA: Foundation for Intelligent Physical Agents. http://www.fipa.org.

http://www.fipa.org/


50

2) La composante illocutoire : elle concerne le contenu sémantique qui représente

aussi la force illocutoire ou performative. Avec le même contenu propositionnel,

on peut former différentes illocutions. Exemple : avec le contenu propositionnel

« il fait beau », nous pouvons former les illocutions suivantes : affirmer (il fait

beau), questionner (est ce qu‟il fait beau ?), promesse (je te promets qu‟il fera

beau), etc.

3) La composante perlocutoire : il s‟agit des effets que le message illocutoire a sur

le destinataire ce qui se traduit par des effets sur ses actions, ses croyances etc.

Exemple : prévenir (cela risque d‟exploser), conséquence sur l‟interlocuteur

(peur, fuite etc.).

2.5.1.2.1 Les langages de communication multi-agents

Les agents doivent communiquer pour pouvoir agir dans un environnement commun et

éventuellement résoudre des problèmes. La communication inter-agent exige la

compréhension mutuelle des agents entre eux. D‟où, la nécessité d‟un langage commun

à l‟ensemble des agents. Les deux langages de communication multi-agents les plus

répandus sont KQML (Knowledge Query and Manipulating Langage) [FINI 95] et

FIPA-ACL (Agent Communication Language de FIPA) [FIPA 99].

Le langage KQML est un langage qui supporte la communication inter agents. C‟est

un langage basé sur les actes de langage. Il possède une quarantaine de performatifs et

de règles qui régissent les comportements des agents l‟échange des messages entre eux.

Les performatifs sont des commandes qui ont une certaine ressemblance avec des

verbes utilisés de façon performative dans le langage naturel. Les types de messages de

KQML sont par exemple des assertions (“ask”, “tell”), instructions de routage de

l‟information (“forward” et “broadcast”), commandes persistantes (“subscribe”,

“monitor”), commandes qui permettent aux agents consommateurs de demander à des

agents intermédiaires de trouver les agents fournisseurs pertinents (“advertise”,

“recommend”, “recruit” et “broker”) [JARR 02] [FINI 95].

Toutefois, certaines critiques ont été reprochées à KQML par Cohen et Levesque cité

dans [BERG 05]. elles sont relatives principalement à la sémantique des performatifs et

des attributs des messages qui n‟a jamais été vraiment bien définie de manière

rigoureuse ce qui a conduit à des interprétations divergentes. Aussi, on a remarqué que

l‟ensemble des performatifs malgré qu‟il soit vaste et parfois redondant souffre de

l‟absence de certains performatifs, comme les promessifs (promesse de faire quelque

chose à un agent, et de gérer ces promesses).

Quant au langage FIPA-ACL ou ACL, il a été développé par la FIPA, un organisme qui

s‟occupe de la standardisation des communications entre agents. FIPA-ACL comme

KQML est aussi basé sur la théorie des actes de langage et a bénéficié grandement des

résultats de recherche de KQML. Si, toutefois, les deux langages se rapprochent au

niveau des actes de langage, FIPA-ACL est plus riche au niveau de la sémantique

[JARR 02]. Il a été développé pour répondre aux critiques faites à KQML. Il possède

une vingtaine de performatifs.


51

2.5.2 La coopération

Ferber dans [FERB 95] a défini la coopération par « On dira que plusieurs agents

coopèrent, ou encore qu‟ils sont en situation de coopération, si l‟une de ces deux conditions

est vérifiée :

1) L‟ajout d‟un nouvel agent permet d‟accroitre différentiellement les

performances du groupe ;

2) L‟action des agents sert à éviter ou à résoudre des conflits potentiels ou actuels».

Il a ensuite ajouté « C‟est parce qu‟ils coopèrent que les agents peuvent accomplir plus

que la somme de leurs actions, mais c‟est aussi à cause de leur multitude qu‟ils doivent

coordonner leurs actions et résoudre des conflits ».

Dans [DURF 89], les auteurs ont proposé quatre buts génériques pour établir la

coopération dans un groupe d‟agents :

1) augmenter le taux de finalisation des tâches grâce au parallélisme,

2) augmenter le nombre de tâches réalisables grâce au partage de ressources

(information, expertise, dispositifs physiques, etc.),

3) augmenter les chances de finaliser des tâches en les dupliquant et en utilisant

éventuellement des modes de réalisation différents,

4) diminuer les interférences entre tâches en évitant les interactions négatives.

La coopération est la forme générale de l‟interaction. Elle est nécessaire quand un agent ne

peut pas atteindre ses buts sans l‟aide des autres agents. Elle représente la forme

d‟interaction qui s‟intéresse à la manière de répartir le travail, et par conséquent,

l‟allocation de tâches entre plusieurs agents. La coopération peut être statique, et donc la

répartition des tâches est faite dès la conception du système multi-agents. Comme elle

peut être dynamique, et c‟est un processus de coopération adéquat qui est mis en œuvre

entre les agents [KAMO 07]. Dans ce dernier cas, la répartition des tâches s‟effectue par

des mécanismes d‟offre et de demande. Elle est réalisée soit par un agent coordinateur

qui centralise les offres et les demandes soit de manière distribuée.

D‟un point de vue général, la coopération peut être vue comme une attitude

intentionnelle. Dans ce cas, les agents s‟engagent dans une activité collective après

avoir identifié et adopté un but commun. Aussi, elle peut résulter à partir d‟une activité

automatique d‟un ensemble d‟agents réactifs, mais interprétée à posteriori par un

observateur extérieur au système multi-agents.

2.5.3 La coordination

Plusieurs définitions de la coordination sont données dans la littérature. Nous citons la

suivante : La coordination est définie comme l‟acte de gérer les interdépendances des

différentes activités exécutées pendant la réalisation d‟un but. Les interdépendances

regroupent les pré-requis (résultat d’une activité nécessaire à une autre activité), le

partage des ressources et la simultanéité (il existe une synchronisation entre l’exécution

des activités) [MALO 90]. Suivant cette définition, la coordination est à la base de la


52

coopération, elle se rapporte à la coordination des actions, au partage des ressources et à

la parallélisation des actions.

La coordination est nécessaire pour améliorer et maintenir cohérent le fonctionnement

global du système. Dans le cas de la coopération par exemple, les agents travaillent

collectivement à la résolution d‟un problème, ils peuvent utiliser les mêmes ressources

et/ou contribuer dans la résolution d‟une partie du problème. Pour cela, ils doivent

accomplir les tâches liées au problème à résoudre et coordonner leurs actions. Les

tâches de coordination ne sont pas directement liées à la résolution du problème mais

permettent au système multi-agents de fonctionner d‟une manière efficace. Ce qui

permet au système de résoudre le problème collectivement, de gagner en temps

d‟exécution, d‟éviter les conflits entre agents et de diminuer autant que possible les

interactions entre les agents, ce qui augmente les performances du système.

2.5.4 L’organisation

Un système multi-agents est un système constitué d'un ensemble d'agents qui

fonctionnent dans un environnement à partir duquel ils perçoivent et dans lequel ils

agissent. Les agents sont engagés dans une activité collective qui exige d‟eux d‟interagir

et de collaborer. Cette situation pose le problème de l'organisation sociale. Aussi, dans

une société, le mot organisation consiste à la fois en l'action de structurer et au

résultat de cette action qui est le modèle ou la structure statique.

Une définition classique de l‟organisation a été donnée par Morin [MORI 77] :

« L‟organisation peut être définie comme un agencement de relations entre composants

ou individus qui produit une unité (ou système) dotée de qualités inconnues au niveau

des composants ou individus. L‟organisation lie de façon interrelationnelle des

éléments, événements ou individus divers qui dès lors deviennent les composants d‟un

tout. Elle assure solidarité et solidité relative, donc, assure au système une certaine

possibilité de durée en dépit de perturbations aléatoires ».

Gutknecht dans [GUTK 01] relève l‟importance de l‟organisation dans les systèmes

multi-agents en citant : « Une partie importante d‟un système multi-agents peut être

décrite déjà au niveau organisationnel avant de l‟envisager au niveau individuel par les

modèles de connaissance ou de contrôle. » Dans ce sens, l‟organisation peut contribuer

autant qu‟outil de conception dans les systèmes multi-agents.

Du point de vue de la réflexion sur la distribution des tâches et de l‟interaction

cohérente entre les agents dans la résolution de problèmes distribués ou dans un système

multi-agents, Gasser [GRAS 89] le voit comme un problème d‟organisation qui se traduit

par décider quel agent fera quoi et quand.

Ferber [FERB 95] aborde l‟organisation dans le sens d‟établir un certain ordre entre les

agents en citant : « Dans les systèmes multi- agents, l‟organisation décrit le cadre dans

lequel les agents, les ressources, les tâches et les buts coexistent. Lorsqu‟on parle

d'organisation, on suppose qu'il existe un ensemble d'entités et dont les différents

éléments sont subordonnés entre eux dans un ensemble solidaire et dans une activité

convergente. L'organisation nécessite donc un certain ordre entre entités éventuellement

hétérogènes, lequel concourt à la cohérence du tout».


53

Selon les capacités cognitives des agents, l‟organisation dans un système multi-agents

peut être considérée sous deux aspects : le premier considère que la société d'agents

adopte une dynamique collective, alors qu'aucun agent de la société n'est capable de

“penser” cette dynamique. L‟organisation dans ce cas émerge du comportement des

agents, les travaux de Drogoul rentrent dans ce cadre [DROG 93]. Le deuxième aspect

considère a priori une organisation des agents qui possèdent des capacités sociales et

forment une société d‟agents. Cette organisation se base sur la structuration des

activités relativement aux rôles attribués à chacun des agents.

Certains chercheurs ont mis l’accent sur la notion de rôles que les agents doivent jouer

au sein d’une organisation [MULL 00] et [BOUR 92]. Muller dans [MULL 00] a défini

l‟organisation en termes de rôle, relation et organisation. Il cite « La modélisation des

organisations sociales dans les systèmes multi-agents introduit les notions de rôle,

relation et organisation. Cette modélisation est en principe indépendante des agents qui

vont effectivement jouer ces rôles et à travers eux le fonctionnement des organisations

modélisées ». Muller soutient l‟idée qu‟un agent ne joue pas qu‟un seul rôle, mais il

peut jouer de multiples rôles selon les groupes sociaux dans lesquels il est impliqué. Par

conséquent, un agent doit être modélisé par l‟ensemble des rôles qu‟il peut avoir.

Un rôle est l‟abstraction d‟un comportement ou d‟un modèle de conduite, rattaché à un

statut et pouvant interagir avec d‟autre rôles. Une relation entre rôles est l‟abstraction

d‟une interaction récurrente entre ces rôles. Une organisation dans ce contexte est un

ensemble de rôles et de relations entre ces rôles qui réalisent une fonction globale.

L‟organisation est un concept important dans les systèmes multi-agents. Beaucoup de

travaux ont été réalisé dans ce cadre. Il en ressort deux axes principaux, le premier

considère que l‟agent est la source de la structure sociale, il peut jouer des rôles, assurer

des comportements relatifs à ses rôles et parfois même jouer plusieurs rôles et

appartenir à plusieurs groupes différents. Le deuxième axe considère l‟agent comme

faisant partie d‟une communauté supportant une certaine structure organisationnelle. De

plus, l‟organisation n‟est pas toujours statique, elle peut être dynamique. De ce fait, il

faudra s‟intéresser aux phénomènes nouveaux qui peuvent être engendrés comme

l‟émergence ou la réorganisation.

2.5.5 La négociation

La négociation désigne la stratégie de résolution qui utilise le dialogue pour parvenir à

un accord visant à résoudre des conflits de croyances ou de buts. Les conflits de

croyances sont produits par l‟existence de contradictions entre les croyances des

différents agents. Ils sont dus au fait que les agents possèdent des connaissances

incomplètes voire erronées [BOUR 92].

La négociation est un processus de communication d'un groupe d'agents permettant

d'atteindre un accord mutuellement accepté [ESPI 10] et de résoudre leur conflit en

défendant leurs points de vue respectifs pour arriver à un compromis, en partageant des

ressources limitées ou encore en coordonnant leurs actions. La négociation est basée sur

des protocoles qui assignent des rôles aux agents. Chaque agent impliqué dans la

négociation exécute le protocole avec le rôle qui lui est assigné.

En l‟absence de négociation, d‟autres solutions sont possibles. Ces dernières sont moins

performantes que la négociation, par exemple la décision est prise d‟une façon


54

autoritaire par un agent qui a l‟autorité de décider. La méthode du vote peut aussi être

utilisée pour résoudre des problèmes de conflits.

Il existe trois types de négociation dans les SMA :

1) La négociation par allocation de tâches : Ce type de négociation fait appel au

protocole « Contract-Net » qui est un protocole de négociation entre deux types

d'agents, le contractant et le gestionnaire. Le gestionnaire commence par

annoncer les sous-tâches aux agents qui doivent faire des propositions selon

leurs capacités à exécuter ces sous-tâches. Le gestionnaire rassemble ensuite

toutes les propositions qu‟il a reçues, puis affecte la tâche à l‟agent ayant fait la

meilleure proposition.

2) La négociation heuristique : La négociation heuristique permet aux agents de

dépasser la phase d‟acceptation et de refus des propositions en fournissant des

réactions utiles. Ces réactions peuvent prendre deux formes :

o la critique sur l‟acceptation ou le refus d‟exécuter une tâche.

o Ou bien, la contre proposition qui consiste en une proposition alternative

donnée par l‟agent en réponse à une proposition.

3) La négociation par argumentation : Une négociation commence toujours par

une proposition qui peut être une offre ou une demande. Cette étape est

suivie par un échange d‟illocutions qui peuvent être l‟émission de contre-

propositions ou d‟arguments de persuasion. Enfin, une illocution de fin de

processus est invoquée, par exemple : acceptation, refus.

2.6 L’émergence

L‟émergence est un concept qui est souvent lié aux systèmes multi-agents dont les

agents sont réactifs. Elle est généralement considérée comme un phénomène qui

caractérise le comportement global d‟un système résultant des actions locales et des

interactions entre les agents de ce même système. Plusieurs auteurs se sont intéressés à

ce phénomène dans le cadre de la conception des SMA réactifs. Ces systèmes

permettent de modéliser des phénomènes, notamment sociaux, dans lesquels se produit

une émergence de structure ou de fonction [DROG 93] [PICA 04c] [MULL 98] [MULL

02] [GECH 05] [MRJE 97].

Dans ce genre de systèmes l‟architecture des agents n‟est pas complexe relativement

aux agents cognitifs, mais l‟intelligence du SMA émergera du comportement collectif.

Le résultat est généralement observé par un observateur extérieur au système, car les

agents qui sont réactifs n'ont pas la capacité d'identifier des comportements globaux. Ce

résultat observé consiste en une structure émergente. Cette dernière, peut se traduire

sous deux formes non nécessairement exclusives. La première, en termes d‟agents, dans

ce cas, c‟est la position des agents qui est déterminante. On parle aussi d‟auto-

organisation des agents. La seconde, en termes d‟environnement, où une structure

topologique qui est construite par les agents. Cette structure est la conséquence des

interactions entre les agents et/ou via l‟environnement ainsi que la résolution du

problème par les agents. Par exemple, dans les colonies d‟insectes sociaux, c‟est la

multiplicité des interactions et leur caractère stochastique qui vont permettre


55

d‟obtenir, par auto-organisation et émergence de structures, des propriétés collectives

robustes et adaptatives, souvent assimilables à de véritables comportements de

résolution collective de problèmes [DROG 93].

Muller dans [MULL 02] a défini l‟émergence dans les SMA par : « Un phénomène est

émergent si :

1) Il y a un ensemble d‟entités en interaction dont la dynamique est exprimée dans

un vocabulaire ou théorie D distincte du phénomène émergent à produire,

2) La dynamique de ces entités interagissantes produit un phénomène global qui

peut être un état structuré stable ou même la trace d‟exécution,

3) Ce phénomène global peut être observé et décrit dans un vocabulaire ou théorie

D‟ distincte de la dynamique sous-jacente.

Pour que le dernier point soit possible, le phénomène global doit être globalement perçu

et, donc, inscrit sur un support. Dans les systèmes naturels, l‟environnement joue ce rôle

important de médium d‟inscription. ». Muller [MULL 02] souligne la nécessité d‟un

couplage du processus avec le niveau d‟observation du processus. Nous distinguons

deux classifications de l‟émergence.

Selon le niveau d‟observation du processus, l‟émergence peut forte ou faible :

1) Emergence forte : Les agents sont partie prenante du processus tout en observant

ce dernier. Les agents doivent être dotés de capacités qui leur permettent

d‟identifier un phénomène et de le décrire. Ceci suppose que chaque agent soit

doté d‟une capacité d‟observation et que son champ d‟observation soit

suffisamment large pour identifier le phénomène dans sa globalité [PHAN 04].

C‟est donc une façon de faire de la résolution de problèmes par des agents. Au

niveau micro, les agents réalisent leurs activités rationnellement, compte tenu

des informations partielles sur leur environnement. Mais, ils suivent aussi un

modèle social qui garantit au niveau macro l‟apparition d‟une fonction collective

adéquate compte tenu des contraintes environnementales.

2) Emergence faible : Un exemple naturel est la planification d‟un chemin par les

fourmis. Les entités en interaction sont ici les fourmis. Une fourmi qui porte de

la nourriture à son nid dépose une trace de phéromone dont la dissipation produit

un gradient d‟odeur qui est perçu par les fourmis. Le phénomène global est le va

et vient des fourmis. Seul un observateur de la colonie de fourmis peut décrire ce

phénomène global en termes de chemin. Les interactions entre les fourmis et

l‟environnement ne sont pas exprimées en termes de chemin (théorie D‟, selon la

définition de Muller dans [MULL 02]) de nature géométrique, mais en terme de

gradient local de phéromones (théorie D dans [MULL 02]) de nature chimique.

Les fourmis produisent une structure stable et globale qui devient un chemin aux

yeux de l‟observateur. Le phénomène global n‟existant que pour l‟observateur,

car aucune fourmi n'a une carte des parcours possibles, ni un moyen d‟évaluer

les temps de trouver le chemin le plus court. On parle d‟émergence faible ou

émergence de premier ordre [MULL 02].

Selon la nature de l‟émergent, l‟émergence peut être une auto-organisation, de structure

ou de propriétés :


56

1) Auto-organisation : Dans le cas, par exemple d‟un système multi-agents ouvert,

il est nécessaire de lui donner les moyens d‟adapter son organisation afin de

satisfaire au mieux ses objectifs. En effet, si par exemple un agent qui a une

tâche bien précise venait à quitter l‟organisation, il faudra trouver un autre agent

pour le remplacer ou assumer, en plus de ses propres tâches, celles qui étaient

assignées à l‟agent partant. Par adapter on entend agir sur les agents ou la

structure organisationnelle afin de réorganiser le travail [FOIS 96], c‟est l‟auto-

organisation. L‟adaptation est le but principal de l‟auto-organisation [JAMO 05].

2) L‟émergence de structure : C‟est lorsque des phénomènes non programmés et

non présents à un instant t=0 naissent de la confrontation d‟un environnement

actif et d‟une activité structurée entre les différents éléments qui composent un

système. Le degré de complexité de cette structure émergente va bien au-delà de

celle de ses composants et augmente au fur et à mesure que le système s‟auto-

organise [JAMO 05] [DROG 93].

3) Emergence de propriétés : Elle fait référence à la rétro-propagation. En effet, une

auto-organisation se doit d‟intégrer des mécanismes de régulation afin de veiller

à la cohérence du système. Le système agit ainsi comme une commande

adaptative. La rétro-propagation, de par les mécanismes de régulation qui lui

sont inhérents, assure une meilleure stabilité du système. Les propriétés, qui

émergent du système, agissent donc comme des contraintes modulant le

comportement de chacun des composants [JAMO 05].

2.7 Typologies des systèmes multi-agents

L‟importance de l‟approche système multi-agents s‟est développée considérablement

rendant les systèmes d‟information de plus en plus distribués et à grande échelle. On

distingue différents types de systèmes multi-agents.

2.7.1 Système multi-agents ouvert/fermé

Un système multi-agents ouvert [VERC 00] partage les caractéristiques des systèmes

ouverts. Les entités élémentaires du système, i.e. les agents, n‟ont pas la possibilité

d‟avoir une représentation complète de l‟environnement, tandis que le système dans sa

globalité doit être modulaire et extensible. La modularité concerne le fait que le système

multi-agents est composé de plusieurs sous-systèmes mis en relation. Ces sous-systèmes

ont chacun leur propre mode de fonctionnement. L‟extensibilité se traduit par le fait que

le système multi-agents supporte l‟ajout et le retrait dynamique d‟éléments. A l‟inverse,

le qualificatif fermé signifie que l‟ensemble des agents qui compose le système reste le

même. Certaines applications comme le e-commerce nécessitent des systèmes multi-

agents ouverts où les agents y entrent et en sortent librement.

2.7.2 Système multi-agents homogène/hétérogène

Un système multi-agents homogène est composé d‟agents homogènes. Deux agents ont

cette particularité s‟ils sont identiques du point de vue de leurs modèles et de leurs

architectures. Le qualificatif hétérogène est utilisé pour préciser que le système multi-

agents est composé d‟agents différents du point de vue de leurs modèles et de leurs

architectures.


57

2.8 Méthodes de conception de systèmes multi-agents

Le développement de systèmes multi-agents nécessite l‟application de méthodes et

d‟outils qui permettent leur réalisation. La littérature fait état d‟une multitude de

méthodes de développement orientées agent.

Une méthode de conception est constituée d‟un processus de développement et de

notations permettant la modélisation ainsi que des outils d‟aide à la conception, à la

vérification et/ou au suivi du processus [BOOC 92] [PICA 04c]. L‟intérêt d‟une méthode

pour les SMA consiste en la proposition d‟une démarche qui permettra au concepteur

d‟être guidé afin de passer d‟un cahier des charges à une implémentation et de pouvoir

gérer le cycle de vie global d‟une application. A cet effet, les chercheurs dans ce

domaine se sont basés sur des modèles, méthodes et outils déjà existants. Suite à cela,

une panoplie de méthodes de conception de systèmes multi-agents ont vu le jour [GUTK

01] [PICA 04c] [JARR 02] [GLEI 08]. Ces méthodes peuvent être classées selon trois

axes :

1) Les extensions d‟approches orientées objets : comme AAII, Gaia, Aalaadin,

ADELFE.

2) Les approches dérivées de l‟ingénierie de la connaissance : DESIRE, MAS-

CommonKADS.

3) Le troisième axe, consiste en les méthodes moins classiques qui proposent de

prendre dès le départ un point de vue centré sur la notion de système multi-

agents, ce qui permet d‟éviter de passer sous silence les aspects sociaux ou

d‟émergence de comportement comme “Voyelles” et CASSIOPÉE.

Nous présentons dans ce qui suit quelques méthodes de conception SMA les plus

usuelles [PICA 04a] [SABA 01] et [GLEI 08].

2.8.1 AAII

AAII [KINN 96] signifie Australian Artificial Intelligence Institute Methodology. Elle a

été notamment développée par Kinny et ses collègues pour la gestion du trafic aérien.

Elle est dédiée à la conception d‟agents BDI. Son processus de conception suit deux

axes, l‟un externe et l‟autre interne. La vision externe consiste en quatre étapes qui

aboutissent à la définition des classes d‟agents avec les instances nécessaires. La vision

interne consiste à élaborer la structure ainsi que le comportement des agents sur la base

de l‟identification des interactions. Ce processus de conception se caractérise par sa

simplicité qui met l‟accent surtout sur la phase analyse. Quant à l‟aide à l‟identification

des agents, aucun support de conception ou de développement n‟est spécifié.

2.8.2 DESIRE

DESIRE [BRAZ 97], qui signifie DEsign and Specification of Interacting REasoning

framework, une méthode directement issue de l‟ingénierie des connaissances. DESIRE

manipule les structures de connaissances, les décompositions de tâches, les échanges

d‟information, l‟ordonnancement et la délégation de tâches. La couverture du processus

de DESIRE est assez limitée car ne faisant référence qu‟à la phase de conception. De

plus, aucun processus qui puisse guider le concepteur pas-à-pas n‟est fourni, seulement

des instructions indépendantes.


58

2.8.3 Aalaadin

Aalaadin [FERR 98] est un cadre de développement de systèmes multi-agents. Cette

méthode représente surtout un environnement de prototypage et d‟exécution idéal pour

des agents reposant sur les notions de groupe et de rôle, grâce au modèle AGR.

Le méta-modèle UML7 (Unified Modeling Language) d‟AGR indique qu‟un agent joue

des rôles au sein de groupes. Un agent peut avoir plusieurs rôles et appartenir à

plusieurs groupes. Le rôle est une notion fonctionnelle abstraite, spécifique à un groupe

et pouvant être joué par plusieurs agents. Un rôle est caractérisé par son unicité (vraie

ou fausse), ses compétences (ou services), et ses capacités afin de remplir son rôle. Un

groupe est un ensemble d‟agents ayant des points communs et qui peuvent

communiquer. La communication est interdite entre agents de groupes différents pour

des raisons de sécurité.

Aalaadin propose un processus en trois phases :

1) Phase d‟analyse : qui permet d‟identifier et de définir les mécanismes de

coordination et d‟interaction entre les entités ;

2) Phase de conception : qui consiste à identification les groupes et les rôles

dans des diagrammes de structures organisationnelles. Les protocoles

d‟interactions entre rôles sont aussi décrits dans des diagrammes

organisationnels ;

3) Phase de réalisation : commence par le choix de l‟architecture d‟agent. Le

modèle AGR peut s‟adapter à n‟importe quel contexte, mais la plateforme

Madkit [GUTK 00b] reste la plus adéquate car cette plate forme a été conçue

spécialement pour supporter cette architecture organisationnelle.

Toutefois, la modélisation graphique d‟une organisation suivant AGR n‟exploite que

l‟aspect organisationnel du système. Il n‟y a aucun moyen de spécifier le comportement

interne et computationnel des agents, ce qui la rend insuffisante à elle seule de pouvoir

représenter tous les aspects multi-agents (agent, interaction, environnement et

organisation).

2.8.4 Cassiopée

Cassiopée, développée par Collinot et Drogoul [COLL 98], est l‟une des méthodes les

plus originales car elle est issue du domaine de la simulation multi-agents. C‟est l‟une

des méthodes bottom-up, ou ascendantes, qui part des actions nécessaires à l‟obtention

d‟une tâche globale pour arriver à la définition des rôles organisationnels et structures

collectives.

Dans Cassiopée, la spécification des comportements des agents repose principalement

sur deux types de graphes : les graphes de couplage des comportements élémentaires, et

les graphes d‟influences. Ce sont des graphes de type états/dépendances. Les nœuds

représentent les états possibles d‟un agent, et les arcs spécifient des dépendances entre

les états comme par exemple la coopération. Ce processus de modélisation se limite aux

7 http://www.uml.org/


59

phases d‟analyse et au début de la conception, c'est-à-dire à la définition des états

internes. Comme pour AAII, ceci implique une totale liberté d‟implémentation. Il est à

noter que cette méthode a été utilisée dans un seul contexte, celui des robots

footballeurs.

2.8.5 MAS-CommonKADS

La méthode MAS-CommonKADS [IGLE 98] est une extension de CommonKADS qui

ajoute, à des techniques venant des méthodes orientées objet, des techniques de

conception des protocoles dans le but de modéliser les agents et les interactions entre

eux. Cette méthode comprend plusieurs modèles : le modèle de l‟agent, le modèle de

tâche, le modèle d‟organisation, le modèle de communication, le modèle d‟expertise, et

le modèle de conception.

MAS-CommonKADS a été plusieurs fois exploitée dans la conception de systèmes de

gestion de réseaux ou de systèmes multi-experts. Souvent, les agents déployés sont à

forte granularité compte-tenu de l‟approche adoptée orientée connaissances.

2.8.6 GAIA

Gaia [WOOL 00] est une extension des approches d‟ingénierie logicielle classiques.

C‟est une méthode de la seconde génération, par opposition à la première génération

que formaient AAII ou DESIRE. Elle est donc plus complète et bénéficie, de plus, d‟une

large reconnaissance dans le domaine multi-agents.

Les ressources disponibles sur GAIA sont assez limitées. Elle requiert une solide

maîtrise de la logique temporelle, ce qui est aussi le cas de DESIRE. Ceci la rend plutôt

difficile à adopter. GAIA est limitée aux applications à agents à forte granularité, peu

nombreux, et avec une organisation statique. De plus, GAIA ne couvre pas la phase

d‟implémentation.

2.8.7 Voyelles

L‟approche Voyelles de Demazeau [DEMA 01] est une méthode de haut niveau très

souvent citée dans la documentation car reposant sur des principes purement multi-

agents. Elle se base sur la décomposition de la vue d‟un système suivant cinq

dimensions (ou lettres) : Agent, Environnement, Interaction, Organisation et

Utilisateurs.

La méthode Voyelles repose sur des principes purement multi-agents. Elle identifie

quatre dimensions de modélisation multi-agents, dont l‟organisation qui est vue comme

la contrainte structurante du système multi-agents. L‟organisation n‟est pas un résultat

émergent de l‟activité du système, mais un moyen pour lui d‟atteindre son but. Dans

cette méthode, la priorité est la liberté totale de choix ce qui est toutefois problématique

lorsque l‟on veut concevoir des systèmes. Le problème réside dans le fait de savoir

quels modèles utiliser, comment décomposer son problème, ou quels outils choisir.

Toutefois, certains travaux qui se sont basés sur cette méthode peuvent être d‟un apport

considérable.


60

2.8.8 ADELFE

La méthode ADELFE (Atelier de DEveloppement de Logiciel à Fonctionnalité

Emergente) [PICA 04b] est dédiée à la conception de systèmes multi-agents adaptatifs.

Les logiciels adaptatifs sont utilisés lorsque l‟environnement est imprévisible ou le

système à construire est ouvert. Le processus d‟ADELFE s‟inscrit dans le Rationnal

Unified Process (ou RUP) qui est un processus issu de l‟ingénierie orientée objet. Les

agents modélisés par ADELFE sont coopératifs. Ils ignorent le but global du système

mais ils cherchent à réaliser leurs buts locaux tout en essayant d‟être coopératifs entre

eux. L‟activité de l‟agent se base sur un ensemble de règles de coopération qui lui

permettent d‟identifier et de résoudre des situations non coopératives (NCS) et identifie

une taxonomie des NCS qui dépendent du contexte d‟application. ADELFE utilise un

outil graphique qui supporte la notation UML (Unified Modeling Language) et AUML

(Agent UML) pour la représentation des protocoles d‟interaction.

ADELFE se caractérise par l‟absence de l‟aspect organisationnel, et donc, l‟absence de

structure organisationnelle, règles d‟organisation, rôle etc. Le concepteur doit exprimer

sa structure organisationnelle sous forme de règles de coopération propres à chaque

agent. De plus, l‟absence du concept « rôle » rend moins flexible la définition du

comportement de l‟agent.

Les méthodes issues des extensions des techniques orientées objets (OO) ont pour

avantage d‟être familières au concepteur et donc leur apprentissage est plus ou moins

facile. Toutefois, les concepts OO ne permettent pas de modéliser les caractéristiques

intrinsèques des agents (autonomie, communication complexe etc.). Si les méthodes

issues des extensions des méthodes à base de connaissances permettent de mieux

prendre en compte l‟état interne des agents, en revanche les modèles qui en découlent

sont complexes. Par ailleurs, les méthodes qui prennent dès le départ l‟aspect multi-

agents du système, et qui considèrent aussi dés le départ la dimension sociale et

l‟émergence de comportement sont très intéressantes. Mais, l‟inconvénient de ces

méthodes réside dans leur spécification incomplète, c‟est à dire de l‟analyse à

l‟implémentation. Ceci conduit les concepteurs à imiter dans leurs démarches les

travaux déjà réalisés et documentés au niveau de certaines thèses.

Finalement, il n‟existe pas de méthode parfaite qui guide le concepteur de l‟analyse à

l‟implémentation. Aussi, il aurait été intéressant d‟avoir des plateformes d‟exécution

associées à des méthodes de conception, ce qui n‟est pas le cas jusqu‟à présent.

2.9 Les plates-formes de développement des systèmes multi-agents

Une plate-forme de développement des systèmes multi-agents est une infrastructure de

logiciels utilisée comme environnement pour le déploiement et l'exécution d'un

ensemble d'agents. Elle devrait fournir des fonctionnalités confortables pour créer et

tester des agents, elle peut être vue comme une collection de services offerts aux

développeurs, mais également aux agents en exécution. Cependant, une plate-forme est

un environnement d'exécution pour un agent dans le sens qu'elle devrait permettre de

créer, exécuter et supprimer des agents. D‟autre part, une plateforme devrait agir en tant

qu‟un médiateur entre le système d'exploitation et les applications (agents). Il existe

différentes catégories de plates-formes multi-agents, elles rassemblent des outils de


61

natures très différentes pour une certaine généricité et réutilisation dans le

développement de SMA :

1) Plate-forme de simulation : reproduit l‟environnement ou le comportement d‟un

système complexe afin d‟en étudier la dynamique (Cormas, Geamas, Mice,

Swarm, Starlogo, Netlogo, etc.).

2) Plate-forme d‟exécution : propose des outils d‟implémentation à partir de

modèles particuliers (Jade, Jack, ABE-IBM).

3) Plate-forme de développement : sert de support à une méthodologie en

fournissant des outils pour assister une démarche de conception (Adelphe,

AgentBuilder, Madkit, etc.)

Il existe un certain nombre de plates-formes fournies comme logiciels libres. Parmi ces

dernières, il y en a quelques unes qui sont plus connues pour avoir été utilisées dans le

développement de plusieurs applications : Jade, Mace, Zeus, AgentBuilder et Madkit

pour les agents cognitifs, et Sworm pour les agents réactifs. Il faut noter que cette liste

n'est pas exhaustive. Et qu'il existe d'autres plates-formes qui ont été utilisées avec

beaucoup de succès pour la mise en œuvre de diverses applications.

2.9.1 Madkit

MadKit8 (Multi-Agents Developpement Kit) est une plate-forme de développement de

systèmes multi-agents destinée au développement et à l‟exécution de systèmes multi-

agents et plus particulièrement à des systèmes multi-agents fondés sur des critères

organisationnels (groupe et rôle). MadKit n‟impose aucune architecture particulière aux

agents. Il est ainsi possible de développer aussi bien des applications avec des agents

réactifs que des agents cognitifs et communicationnels, et même de faire interagir

aisément tous ces types d‟agents.

Ainsi, cela permet aux développeurs d‟implémenter l‟architecture de leur choix. MadKit

est écrite en Java et fonctionne en mode distribué de manière transparente à partir d'une

architecture "peer to peer" sans nécessiter de serveur dédié. Il est ainsi possible de faire

communiquer des agents à distance sans avoir à se préoccuper des problèmes de

communication qui sont gérés par la plateforme.

2.9.2 AgentBuilder

AgentBuilder9 est une plate-forme multi-agents développée en Java qui présente des

outils graphiques permettant la conception d'agents intelligents. Le comportement des

agents se fait à partir du modèle BDI et du langage AGENT-0. Le langage de

communication utilisé par les agents est KQML. AgentBuilder est composé d'une

interface graphique et d'un langage orienté agent permettant de définir des croyances,

des engagements et des actions. Un éditeur de protocoles permet de générer au moins

leurs squelettes sous forme de diagrammes à états finis simples. Plusieurs rôles peuvent

y être définis, toutefois la notion de rôle est ici faible dans la mesure où le diagramme à

états finis est global au protocole. Le parallélisme et la synchronisation ne peuvent y

8 Gutknecht. O, “ MadKit User's Guide”, dans “http://cyber.felk.cvut.cz/gerstner/dai /repository/demos/

barcelona/ASD-12/madkit-2.0/doc /userguide/t1.html

9 http://www.agentbuilder.com/

http://cyber.felk.cvut.cz/gerstner/dai%20/repository/demos/%20barcelona/ASD-12/madkit-2.0/




62

être représentés. Elle permet également de définir des ontologies et des protocoles de

communications inter-agents.

La plateforme AgentBuilder est considérée comme un outil complexe qui demande des

efforts d'apprentissage importants et de bonnes connaissances dans le domaine des

systèmes multi-agents pour être utilisée de façon performante.

2.9.3 Jade

JADE10

(Java Agent DEvelopment) est une plate-forme multi-agents développée en

JAVA, par F. Bellifemine et A. Poggy, G. Rimassa, P. Turci pour la société CSELT

(Italie) en 1999. JADE est conforme à la norme FIPA. La plate-forme fournit des

services génériques d‟accueil, d‟identification et de communication entre agents. Ces

services sont :

1) L’AMS (Agent Management System) : c‟est en quelque sorte le cœur de la plate-

forme FIPA. Il enregistre les agents actifs, gère leurs identités et garde trace de

leurs états.

2) Le DF (Directory Facilitator) : est un service d‟annuaire permettant d‟identifier

les services utilisateurs sur une plate-forme.

3) L’ACC (Agent Communication Channel) : est un agent particulier chargé de

contrôler les messages entres les différents agents issus de plates-formes FIPA

(ou encore non-FIPA) éventuellement distantes. De ce fait, il offre un service

fiable et précis pour le routage des messages. De plus, il assure l‟interopérabilité

entre les différentes plateformes.

Une plate-forme multi-agents Jade est composée de plusieurs réceptacles (containers)

d'agents. La distribution de ces réceptacles à travers un réseau d'ordinateurs est permise.

Chaque réceptacle d'agents est un environnement multi-threads d'exécution composé

d'un thread d'exécution pour chaque agent, en plus des threads créés à l'exécution par le

système RMI pour envoyer des messages. Un seul récipient est principal, c‟est celui qui

contient les agents et la plate-forme (l‟AMS, l‟ACC et le DF).

La plate-forme offre une interface graphique utilisateur (GUID) pour la gestion à

distance des agents. La communication entre les agents et l'interface (GUI) et toute la

communication entre cette interface et l'AMS est faite par FIPA-ACL. Deux outils

graphiques sont disponibles : 1) L‟agent Dummy qui a pour rôle d‟inspecter les

échanges de messages entre agents, et permet d‟éditer, d‟écrire, d‟envoyer, de recevoir

et de sauvegarder des messages en FIPA-ACL. 2) L‟agent Sniffer qui donne une

interface graphique pour afficher les échanges de messages entre les différents groupes

d‟agents en utilisant une notation proche d‟UML.

10

Plate-forme JADE: Java Agent Development Framework, 2000.http://jade.cselt.it/

http://jade.cselt.it/


63

2.10 Conclusion

L‟avènement de l‟Intelligence Artificielle et la conception des SMA ont beaucoup

impactés le développement de systèmes complexes. Les SMA proposent, en effet, des

architectures évoluées qui permettent de pallier les insuffisances de ces systèmes d‟une

façon générale. L‟amélioration se traduit principalement en termes de coût et de

simplicité de conception. Ils ont l‟avantage de supporter des modèles d‟interaction

comme : la coopération, la coordination et la négociation. Nous avons passé en revue

différentes méthodologies de développement des SMA, ainsi que quelques plates

formes de développement.

Dans le chapitre suivant, nous nous focalisons sur l‟utilisation de la technologie agent et

l‟intégration des agents dans les systèmes d‟aide à la décision collaborative et nous

présenterons quelques produits dans ce domaine.

CHAPITRE III

L’AIDE à LA DECISION COLLABORATIVE

ET LES SYSTEMES MULTI-AGENTS

Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents

65

3.1 Introduction

L‟architecture multi-agents est généralement plus facile à mettre en œuvre pour les

infrastructures complexes. En effet, elle garantit une flexibilité du modèle qui prend en

compte la modularité du système réel. En outre, ce type d‟architecture est efficace

lorsqu‟une architecture centralisée ne peut être mise en place du fait de l‟indépendance

des acteurs qui la compose.

Par ailleurs, la généralisation des réseaux, la coopération entre plusieurs composants

logiciels au sein d‟environnements hétérogènes et distribués ainsi que le développement

d‟Internet ont ouvert la voie à de nouvelles applications SMA. Dans le domaine

d‟Internet, les agents intelligents sont de plus en plus utilisés pour offrir le meilleur

service aux utilisateurs comme la recherche intelligente, l‟assistance, le commerce

électronique etc. Pareillement, la technologie agents a remplacé les modèles

traditionnels pour la conception d‟applications réparties et coopératives et/ou

collaboratives. Cet intérêt pour les SMA est dû essentiellement au fait qu‟une telle

approche permet [ELFE 06]:

la décomposition et la répartition des connaissances et des mécanismes de

traitement dont l‟unité de base est l‟agent ;

la dynamicité du contrôle de résolution d‟un problème distribué caractérisée par

l‟organisation dynamique et l‟affectation des tâches modifiables en cours de

résolution ;

l‟aptitude à traiter des problèmes simultanés et potentiellement corrélés avec des

optimisations éventuelles ;

l‟adaptabilité et la possibilité d‟apprentissage des agents qui leur confèrent la

capacité de résister à des environnements évolutifs et/ou instables.

Nous présentons, dans ce chapitre, un panorama d‟applications des systèmes multi-

agents dans le domaine de l‟aide à la décision et une classification des systèmes

développés. De plus, nous décrivons quelques systèmes développés dans la littérature.

3.2 Les domaines d’applications des systèmes multi-agents

Les systèmes multi-agents étant issus du domaine de l'intelligence artificielle distribuée,

ils permettent de modéliser des applications où une modélisation classique est

inadéquate, et où le système est souvent naturellement distribué. Si un problème n'est

pas naturellement distribué, on peut choisir de le distribuer pour des raisons de

simplification. Depuis les premières expériences, les systèmes multi-agents ont été

utilisés pour construire une grande diversité d‟applications. Celles-ci vont des

applications simples, comme les assistants de courrier électronique, aux systèmes

complexes, comme le contrôle du trafic aérien. Un aspect intéressant pour l‟application

de la technologie d‟agents est précisément que le concept d‟agent permet d‟une façon

naturelle de modéliser une gamme de systèmes aussi ample et avec des besoins aussi

divers.

Les systèmes multi-agents peuvent être appliqués à plusieurs domaines :

Assistance : les agents assistants sont utilisés pour la recherche d‟information dans le

web par exemple, ainsi que comme assistants de courrier électronique. Ils sont aussi

utilisés pour la collecte d‟information ou l‟exécution d‟action pour le compte d‟un


66

utilisateur. Des agents qui cherchent à faire des réservations dans des hôtels ou bien qui

cherchent des opportunités intéressantes de voyages pour des utilisateurs en sont des

exemples.

Des systèmes multi-agents de décision : l‟exemple type est celui du domaine des

télécommunications où le réseau est modélisé par un système multi-agents. Les agents

représentent les différents composants du réseau. Le système doit gérer l‟allocation des

ressources limitées comme les connexions. Le mécanisme de décision utilisé par les

agents peut être un mécanisme économique, comme celui de la vente aux enchères ou

bien celui basé sur l‟argumentation [LUCK 04].

Des systèmes multi-agents pour la simulation : ce sont des simulations qui servent à

analyser un système global à partir d‟interactions locales entre les membres d‟une

société d‟agents. La simulation à base d‟agents est utilisée pour modéliser certains

domaines du monde réel. Elle est aussi utilisée dans le cas des systèmes complexes. Ces

derniers, sont des systèmes où les techniques de modélisation classique sont

difficilement utilisables. En effet, ils renferment un grand nombre de paramètres qui

sont parfois incomplètement définis pour pouvoir être pris en compte. L'approche

multi-agents permet alors d'avoir recours à une modélisation distribué qui simplifie

alors le problème. Mais, la difficulté du concepteur est de trouver la bonne distribution

ainsi que les bons mécanismes de coordination et d‟interaction afin de reproduire le

système réel. Les agents dans ce cas peuvent représenter des animaux dans un

écosystème, des véhicules dans la circulation etc. Comme exemple on peut citer la

simulation d'une fourmilière [DROG 93]. En effet, lors de ses travaux, Alexis

Drogoul a modélisé une fourmilière en utilisant des agents. Il a montré que l'on

pouvait obtenir un but global qui était la survie de la fourmilière sans jamais

avoir programmé cet élément dans le système mais uniquement à partir de l'interaction

des agents par émergence organisationnelle.

Applications industrielles : les systèmes multi-agents sont utilisés pour la simulation

des chaînes logistiques [KHOU 11]. Par exemple, le système Holonic Manufacturing

System (HMS) de [GRUV 03] dans le domaine de la fabrication qui a pour rôle la de

standardiser l‟architecture technologique des systèmes industriels ouverts, distribués,

intelligents, autonomes et coopératifs et, l‟interface OASIS dans le contrôle aérien

[JENN 98] qui est un système de contrôle du trafic aérien de l‟aéroport de Sydney.

Chaque avion est considéré comme un agent qui est créé lorsque l‟appareil s‟approche

de l‟aéroport.

Systèmes d’Aide à la Décision : Les Systèmes d'Aide à la Décision (SAD) sont utilisés

dans de nombreux domaines. Ils ont pour objectif d'aider le décideur dans sa tâche

en lui fournissant tous les éléments pertinents pour une prise de décision. Cela

consiste très souvent à extraire de l'information depuis de multiples sources et à la

traiter. Les systèmes multi-agents sont bien adaptés pour ce genre de traitement de

l'information qui peut revêtir diverses formes et provenir de diverses sources [KHOU

11]. En effet, il faut pouvoir traiter efficacement l'ensemble des éléments obtenus pour

les présenter à l'utilisateur. Aussi, l‟approche à base d‟agents permet la mise en œuvre

des principes de négociation et de coopération qui sont très adaptés à ce domaine. Dans

le cas des systèmes d‟aide à la décision multi utilisateurs, le système multi-agents peut

être déployé sur le web afin d‟interconnecter les agents qui sont physiquement répartis.

Le concept d‟agent mobile permet la mobilité des agents à travers le réseau.


67

Applications au commerce électronique : le domaine du commerce électronique

(e-commerce) est un domaine qui permet de favoriser les transactions

commerciales sur le web. Ce domaine utilise les ressources mises à disposition par

Internet pour rapprocher les acteurs commerciaux. Le développement du réseau Internet

et son utilisation de plus en plus généralisée a favorisé l‟expansion des applications du

e-commerce. Les systèmes multi-agents apportent beaucoup à ce domaine car les agents

mobiles sont utilisés pour migrer et aller chercher l‟information à partir de différents

sites web. Puis, cette information diverse est fusionnée. Dans certains cas, les agents

analysent cette information pour la présenter à l‟utilisateur sous une forme de réponse

assez précise relativement à une requête telle que les informations comparatives entre

produits ou encore une étude qualitative concernant un produit donné.

Applications médicales : les systèmes multi-agents sont utilisés dans le domaine

médical pour le suivi des patients. Dans [HAYE 88], le système GUARDIAN a pour but de

gérer les soins des patients d‟une unité chirurgicale de soins intensifs. Il est basé sur une

structure hiérarchique composée de trois types d‟agents. Les agents de perception/action

sont responsables de l‟interface du système. Les agents en charge du raisonnement

organisent le processus de prise de décision. L‟agent de contrôle, est l‟agent de haut

niveau, il assure le contrôle du système.

Applications dans le domaine du divertissement : les systèmes multi-agents ont aussi

été exploités dans le domaine des jeux vidéo où le concept d‟agent a été utilisé pour

réaliser des animaux artificiels qui évoluent dans des univers virtuels [GRAN 98] [GUIL

13].

3.3 Distribution des systèmes multi-agents

3.3.1 Les Systèmes multi-agents physiquement distribués

De nombreux systèmes informatiques sont physiquement distribués sur plusieurs

machines. Dés lors que ces systèmes sont conçus selon le paradigme agent, il devient

nécessaire d‟avoir recours à un système multi-agents physiquement distribué [HALP 95].

Ce genre de systèmes permettre à des agents présents sur des machines distantes de

travailler ensemble de façon similaire à des agents regroupés sur une même machine. La

seule restriction que l‟on doit admettre est celle du coût de communication entre agents.

En effet, lorsque les agents sont éloignés physiquement les uns des autres, le coût de

communication s‟accroit rapidement [DUVA 01].

La distribution physique des SMA se justifie essentiellement dans deux types

d‟applications :

1) Les applications où il est nécessaire d‟avoir recours à une répartition de la

charge. Il s‟agit d‟applications qui fonctionnent avec un très grand nombre

d‟agents comme celles de simulation d‟écoulement de fluides ou de particules et

de simulation d‟écosystèmes comme les fourmilières [DROG 93], bancs de

poisson, etc.

2) Les applications qui sont naturellement distribuées comme celles qui concernent

les systèmes multi utilisateurs où les acteurs interviennent depuis des endroits

physiquement distants. Dans cette catégorie, nous retrouvons les applications

d‟aide à la décision collectives.


68

3.3.2 Les problèmes posés par la distribution physique des systèmes multi-agents

Un système multi-agents physiquement distribué peut fonctionner selon deux modes :

1) Le système est considéré comme étant distribué. Dans ce cas, il est nécessaire

que les agents aient des capacités de communication assez performantes pour

que les messages envoyés d‟un agent à un autre puissent localiser l‟agent

destinataire relativement à la machine dans laquelle il se trouve.

2) Le système est constitué d‟un ensemble d‟agents mobiles. Dans ce cas, les

agents ont la possibilité de migrer d‟une machine vers une autre. Le problème de

la localisation des machines cibles reste le même que le premier mode. Il

s‟ajoute à cela le problème de l‟exécution de l‟agent mobile dans la machine

hôte.

Lorsque les agents sont distribués, ils se trouvent sur des machines différentes. Mais

cela n‟empêche pas que ces agents ont besoin de communiquer. La communication

entre ces agents est nécessaire pour les raisons suivantes :

Les agents font partie d‟applications différentes et se sollicitent les uns les

autres. Par exemple, dans le cas du e-commerce, les utilisateurs sont connectés

via des interfaces qui utilisent des agents existants localement. Ces derniers,

sollicitent les services d‟autres agents se trouvant sur d‟autres machines.

Il peut s‟agir d‟une même application mais qui doit être répartie sur plusieurs

sites. C‟est le cas, par exemple, des systèmes d‟aide à la décision collective où

chaque utilisateur est relié au système via un réseau et interagit avec le système

via une interface. Mais, le fonctionnement du système nécessite la

communication entre les différents agents, ceux qui sont locaux à la machine de

l‟utilisateur avec ceux qui se trouvent sur d‟autres machines du réseau.

3.4 Application des SMA dans le domaine de l'aide à la décision collaborative

Le développement des réseaux et surtout de l‟internet ont conduit à la généralisation de

l‟utilisation de la messagerie électronique, des forums de discussions, etc. Pareillement,

les entreprises, en se dotant d‟outils issus du travail coopératif assisté par ordinateur

(TCAO) comme les workflow et les groupeware, se sont inscrites dans un courant de

restructuration des organisations traditionnelles centralisées pour aller vers des

organisations distribuées au niveau desquelles les acteurs sont physiquement éloignés.

Cette notion d‟entreprise distribuée et de travail de groupe distribué a contribué à

l‟émergence de prise de décision collaborative distribuée, puisque les acteurs ne se

trouvent pas forcément dans un même lieu. En effet, lorsque le domaine de la prise de

décision est assez spécialisé, les acteurs qui sont des experts dans ce cas, se trouvent

généralement dans des endroits différents de la planète.

Les systèmes multi-agents qui s‟intéressent à la modélisation du comportement d‟entités

distribués dans un environnement proposent des organisations assez intéressantes qui

supportent le travail de groupe. Par ailleurs, le développement des plateformes multi-

agents qui s‟exécutent sur le net, a permis la distribution des agents sur des sites

géographiquement éloignés. De ce fait, les systèmes multi-agents peuvent être un outil

de modélisation de ces organisations en proposant des modèles organisationnels qui


69

prennent en charge le processus de décision collaborative ainsi que la distribution des

acteurs sur des sites éloignés.

Néanmoins, la problématique multi-agents est assez complexe dans ce contexte. En

effet, alors que dans les systèmes multi-agents classiques, la composante sociale et les

modèles afférents portent sur les agents eux-mêmes, dans ce cas, du fait de la finalité

d‟assistance à un processus social humain, les agents vont manipuler deux types de

représentations sociales distinctes mais interdépendantes : un modèle de la société

d‟agents et un modèle de la société d‟acteurs [FERR 03].

3.4.1 Apports des systèmes multi-agents au domaine de l’d’aide à la

décision collaborative

La distribution permet de diminuer la complexité des problèmes à résoudre en

décomposant le système en plusieurs sous systèmes. Ce qui permet une bonne

adaptation aux changements de l‟environnement extérieur, ainsi qu‟une maintenance

aisée du système. Choisir une architecture distribuée dans le contexte des systèmes

d‟aide à la décision collaborative est motivée par les caractéristiques suivantes :

La taille des bases de connaissances est importante lorsque les sources de

connaissances sont multiples et parfois conflictuelles. Ce qui est le cas de la décision

collaborative où un groupe de décideurs collaborent ensemble et mettent en commun

leurs expertises qui peuvent parfois être contradictoires.

Une architecture distribuée et modulaire facilite la maintenance du système. En effet,

l‟extension du système est réalisée par l‟ajout de nouvelles fonctionnalités qui seront

matérialisées par l‟ajout de nouveaux agents. De plus, la modularité du système permet

d‟accroitre la fiabilité de l‟ensemble et de gérer les défaillances sans remettre en cause

la construction globale. Il faut développer à la fois la distribution et l‟intégration des

compétences pour que les différents agents autonomes puissent coopérer et accroitre

ainsi les capacités du système.

Durfee dans [DURF 87] a distingué entre quatre modes de distribution :

1) Une distribution spatiale qui concerne l‟emplacement spatial des agents, des

connaissances etc.

2) Une distribution fonctionnelle qui détermine le rôle des agents au sein de la

société.

3) Une distribution temporelle qui s‟explique dans le cas d‟une expertise qui peut

être disponible ou non à un moment donné.

4) Une distribution logique qui concerne le degré d‟indépendance logique entre les

différentes parties de la connaissance disponible.

Dans le cas des systèmes d‟aide à la décision collaborative, il existe au moins deux

distributions : 1) La distribution spatiale, puisque les acteurs sont géographiquement

distribués et, 2) La distribution fonctionnelle permettant de concevoir un système multi-

agents qui représente une société organisée d‟agents en affectant un rôle fonctionnel à

chacun d‟eux. De plus, dans la conception à base d‟agents, ce n‟est pas toujours

pratique de penser la distribution fonctionnelle de façon bijective en affectant chaque

fonction à un seul agent. En effet, parfois, il est préférable qu‟une certaine fonction du


70

système soit assurée par une structure organisationnelle formée d‟un ensemble d‟agents

dont le fonctionnement global réalise la fonction.

3.4.2 Topologies des systèmes d’aide à la décision collaborative à base d’agents

Selon la distribution spatiale, nous distinguons deux topologies des systèmes d‟aide à la

décision :

1) Un système d‟aide à la décision collaborative à base d‟agents centralisé au

niveau d‟une même machine. Dans ce cas, les acteurs (décideurs et facilitateur)

peuvent intervenir d‟une manière asynchrone ;

2) Un système utilisant un réseau local ou un intranet qui est un réseau d'une

organisation particulière. Dans ce cas, les participants utilisent des stations de

travail autour de ce réseau local. Les acteurs peuvent intervenir d‟une manière

synchrone à partir de leurs terminaux. C‟est le cas par exemple des GDSS

traditionnel co-localisés dans la même salle.

Cependant, il devient nécessaire de décentraliser le système d‟aide à la décision

collaborative dès que l‟une des conditions suivantes est réunie :

les décideurs se trouvent dans des endroits différents et, qu‟il est impossible ou

bien couteux de les réunir en face-à-face dans une même salle ;

le problème de la prise de décision est urgent et doit être résolu rapidement.

C‟est le cas des problèmes comportant un risque ou bien un danger, ou encore

lorsque l‟impact économique est important ;

aux fins de préserver l‟anonymat exigé par certains participants.

3.5 Quelques systèmes d’aide à la décision à base d’agents

En ingénierie des systèmes collectifs artificiels, Nils Ferrand [FERR 03] a classifié les

systèmes en trois sous-classes : la simulation de systèmes complexes, la résolution de

problèmes et le développement d‟agents autonomes pour des systèmes d‟information

ouverts et distribués.

La simulation de systèmes complexes repose sur un principe d‟analogie

structurelle entre les agents artificiels et les objets du système source. Le

système conçu représente une image artificielle du système source, qui peut soit

valider des hypothèses locales par observation des processus émergents, soit

servir de laboratoire virtuel pour tester des hypothèses comportementales.

La Résolution de problèmes consiste à construire un système collectif artificiel

qui pourra résoudre collectivement le problème posé. De nombreux travaux ont

montré qu‟il n‟était pas du tout nécessaire d‟utiliser des agents très compliqués

pour parvenir à cette fin. En effet, parfois, à partir d‟un ensemble d‟agents à

comportement individuels simples, émerge un comportement collectif intelligent

et complexe. C‟est dans cette catégorie qu‟on trouve les systèmes d‟aide à la

décision collective ou collaborative.

Les Agents autonomes en environnement ouvert évoluent sur les réseaux et

effectuent un certain nombre de tâches. Ces agents vivent dans un

environnement constitué de serveurs d‟informations, ils communiquent et


71

interagissent avec d‟autres agents et éventuellement des utilisateurs humains ;

c‟est le cas des agents assistants ou prospecteurs.

Dans ce qui suit, nous allons présenter quelques systèmes d‟aide à la décision à base

d‟agents développés dans la littérature afin d‟illustrer l‟utilisation et l‟intégration de la

technologie agent dans les systèmes d‟aide à la décision collaborative et de pouvoir

situer notre contribution.

3.5.1 Systèmes de simulation

3.5.1.1 Modélisation d’une chaîne logistique distribuée

Dans [KHOU 11], l‟auteur présente un système multi-agents de décision et de simulation

dans le domaine industriel, appliqué au pilotage des chaînes logistiques. L‟auteur définit

la chaine logistique ainsi : « une chaîne logistique consiste en toutes les étapes

impliquées directement ou indirectement dans la satisfaction de la requête d‟un client.

La chaîne logistique inclut non seulement le fabricant et ses fournisseurs, mais aussi les

transporteurs, les centres d‟entreposage les détaillants et les clients eux-mêmes. De ce

fait, une chaine logistique est composée de tous les partenaires qui interviennent dans la

réalisation d‟un produit donné. Chacun des partenaires est libre dans sa prise de

décision, il peut accepter ou refuser une demande d‟un de ses partenaires ». Les

fonctions d‟une chaîne logistiques sont les suivantes :

l‟approvisionnement en matière premières ;

la production de biens physiques et de services ;

le stockage de matières ;

la distribution et le transport ;

la vente aux clients.

L‟objectif de ce système est de permettre une meilleure cohérence dans les prises de

décisions au niveau local de l‟entreprise, mais aussi au niveau global dans toute la

chaîne logistique.

L‟aspect négociation est aussi considéré dans ce système. Ainsi, la négociation se

déclenche lorsque se produit une divergence entre deux partenaires d‟une chaîne

logistique. Cette divergence est relative aux quantités demandées, aux dates de livraison

souhaitées ou aux coûts. L‟un des objectifs de ce système est d‟augmenter la

performance de la négociation en optimisant le temps mis en œuvre pour aboutir à un

consensus.

La distribution de la chaîne logistique signe que le contrôle est distribué dans la mesure

où chaque entreprise qui compose la chaîne logistique est libre de prendre ses propres

décisions. Chaque entreprise du réseau est représentée par un nœud d‟entreprise

virtuelle (NEV). Chaque NEV est formé par trois sous structures de décision : la sous

structure de négociation des ventes, la sous structure de négociation des plannings de

production et la sous structure dédiée à la négociation de l‟achat/approvisionnement.

Chaque sous structure est modélisée par un agent de type réflexe car les actions à

entreprendre sont prédéfinies, d‟où la création de trois agents.


72

L‟Agent Négociateur des Ventes (ANV): il prend en charge les procédures de

ventes du NEV. Lorsqu‟une demande d‟un client arrive, l‟agent de négociation

de ventes est activé. Il peut soit répondre par lui-même à la demande soit

s‟appuyer sur les deux autres agents de la structure pour lui apporter les réponses

nécessaires à la prise de décision.

L‟Agent Négociateur des Plannings (ANP) : le rôle de cet agent est la gestion et

la négociation des plannings de production du NEV. Il est en contact avec les

autres agents de la structure. L‟activation de cet agent se fait par des flux

d‟information des deux autres agents ou bien par l‟intervention d‟un décideur

humain.

L‟Agent de Négociation des Achats (ANA) : les agents de ce type prennent en

charge la négociation des achats et des approvisionnements de l‟entreprise aussi

bien en composants qu‟en prestations de services telles que la sous-traitance ou

le transport. Ils sont en contact avec l‟ANP et l‟ANV ainsi qu‟avec les

fournisseurs de l‟entreprise. L‟activation de cet agent se produit lorsqu‟un flux

d‟information lui est adressé. Ces flux peuvent être : une demande de fourniture

de ressource par l‟ANP, une proposition de fourniture d‟un nouveau produit par

un fournisseur, une demande de prestation de service pour le transport ou une

modification d‟un approvisionnement.

Chaque entreprise n‟a qu‟une vision partielle de la chaîne logistique. Elle est

uniquement en contact avec ses clients et ses fournisseurs directs. Il existe donc, dans la

chaîne logistique, des clients et fournisseurs potentiels qui ne sont pas connus par

l‟entreprise.

Afin de pallier à cette vision restreinte qu‟a l‟entreprise de son environnement, une

structure complémentaire basée sur un agent à simple réflexe nommée Agent de

Facilitation de négociations (NFA) est utilisée. Il est utilisé comme un intermédiaire

entre les différents partenaires de la chaîne logistique distribuée. Cet agent virtuel est

présent sur chaque niveau de la chaîne logistique. Le NFA permet de faciliter les


73

échanges entre partenaires d‟une même chaine logistique. Il peut être aussi utilisé pour

la recherche de nouveaux fournisseurs comme pour la recherche de nouveaux clients

pour une entreprise.

3.5.1.2 SMAG : Aide à la décision appliquée à la gestion de l’eau

L'aménagement du territoire, le développement durable, la préservation de

l'environnement, la gestion des ressources renouvelables sont autant des problématiques

de long terme auxquelles les décideurs souhaitent faire face avec le plus d'éléments

objectifs leur permettant de rationaliser et d'expliciter leurs choix. Pour répondre à ce

besoin d'outils d'aide la décision, de nombreuses recherches ont été orientées vers la

modélisation et la simulation des systèmes complexes. Ces modèles prennent en compte

les dimensions environnementales, économiques et sociales de la réalité. Ils permettent

de mieux comprendre le fonctionnement du monde et d‟anticiper les changements

prévisibles. Dans [URBA 07], l‟auteur a réalisé un Système Multi-Agents Géographique

(SMAG) au niveau duquel il propose d‟utiliser une approche hybride fondée sur un

Système Multi-Agents couplé à un Système d‟Informations Géographiques (SIG).

« Un SIG est un ensemble organisé de matériels informatiques, de logiciels, de données

géographiques et de personnel capable de saisir, stocker, mettre à jour, manipuler,

analyser et présenter toutes formes d'informations géographiquement référencées

[DEBL 94]». Les systèmes d'informations géographiques sont utilisés dans les domaines

de gestion de réseaux, du cadastre, de l‟urbanisme, de l‟aménagement du territoire et la

protection de l'environnement. Ce sont des systèmes qui décrivent un objet selon sa

position géographique à la surface de la Terre. Ils peuvent aussi servir à produire des

cartes pour répondre à des besoins spécifiques : organisation de tournées, circuits

touristiques, prévention des incendies etc. De plus, un SIG peut fournir une aide à la

décision. Les SIG répondent à des questions de type : comment les objets sont répartis

dans l‟espace étudié et quelles sont leurs relations ?

La plupart des modèles utilisés par les logiciels qui prennent en compte les activités

humaines reposent sur des statistiques globales et donc l‟influence locale des acteurs

n‟est pas mise en valeur. De plus, les différents acteurs composant le système possèdent

chacun sa logique comportementale qui s‟explique par l'existence de buts propres.

Ainsi, par exemple, les hôteliers sont guidés par des critères économiques, ils ne

prennent en compte l‟évolution des ressources en eau que sur la période où ils prévoient

de rentabiliser leurs investissements. La perspective d‟un tarissement de la ressource à

un horizon plus lointain ne les concerne pas dans leur logique d'investissement à court

terme. Ce qui n‟est pas le cas des habitants qui sont sensibles à une surexploitation de la

ressource qui n‟assurerait pas la pérennité de leur communauté au delà d‟un horizon

donné.

L‟autonomie de comportement dont font preuve les acteurs du système est précisément

une caractéristique des agents qui est absente dans une approche orientée objet. Toutes

les parties prenantes peuvent être une source de contrôle du système, le contrôle étant

décentralisé et distribué. Cette caractéristique est un élément spécifique des modèles

multi-agents qui les différencie des modèles orientés objets où la source de contrôle est

unique et centralisée.


74

En abordant le système réel selon une approche multi-agents, les phénomènes sont

"individualisés" et encapsulés au sein d'entités autonomes. Cette encapsulation permet

de prendre facilement en compte des phénomènes, des connaissances et des modèles

issus de domaines scientifiques différents qu'il serait plus difficile d'intégrer au sein d'un

modèle centralisé.

L'architecture SMAG permet de prendre en compte l'ensemble des étapes de la

construction d'un logiciel d'aide à la décision hybride SMA-SIG : de l'étude du système

réel à l'interface de contrôle des expérimentations. Les différents modules fonctionnels

composant l'architecture permettent de :

Relever des données géographiques sur le terrain grâce au "module SIG" ;

Construire un modèle informatique orienté multi-agents du système réel en

utilisant les primitives de modélisation et l'environnement de développement du

module SMA. C'est la fonction qui est assurée par le sous-module appelé "Saisie

Nouveau Modèle" ;

Gérer les modèles multi-agents développés avec le module fonctionnel "SG

Base de Modèles" dédié à la gestion des modèles inclus dans le module SMA ;

Simuler et générer des données expérimentales à partir des modèles multi-agents

en utilisant le moteur de simulation "Simulateur SMA" intégré au module SMA ;

Conduire les expérimentations à partir des scénarii et des interventions des

décideurs en cour de simulation en utilisant un module dédié "Gestion des

Intrants" qui est connecté au moteur de simulation multi-agents ;

Créer et gérer des scénarii à l'aide des fonctionnalités standards du "module

SIG".


75

L'environnement du modèle multi-agents SMAG est un environnement décentralisé,

l'espace est représenté par une grille. Chaque portion de l'espace est représentée par une

instance d‟un agent réactif. Le comportement de l'agent Parcelle simule le

comportement hydrologique d'une portion de la grille. A chaque cellule est associé un

agent réactif qui simule le couvert en prenant en compte l'évaporation et le

ruissellement.

La modélisation du climat est faite par un agent réactif climatique qui contrôle le climat

régnant sur chacune des parcelles (températures et précipitations) en fonction de

l'altitude, du jour de l'année et des caractéristiques du climat. Le modèle climatique

utilise des approximations linéaires pour lier les températures et les précipitations à

l'altitude.

Pour la modélisation de l'influence anthropique, le modèle a été simplifié pour ne

prendre en compte que trois types d'agents :

Les agents situés de type Forage alimentent le réseau. Un agent situé Forage

alimente un seul agent Citerne, sa capacité quotidienne de pompage est limitée ;

Les agents situés Citerne stockent l'eau provenant de ces forages avant de la

distribuer à leurs abonnés. Une citerne est alimentée par un forage et alimente

ses abonnés jusqu'à ce qu'elle soit vide ;

Les agents communicants WaterCompany gèrent les citernes. Ces agents

disposent de la possibilité d'émettre des consignes de restriction en cas de risque

de rupture d'alimentation et ont le pouvoir de police de l'eau. Ces agents

permettent de simuler le rôle de la puissance publique ou d'une entreprise de

distribution des eaux à but lucratif.

Quant à la modélisation des consommateurs, elle est réalisée à travers les deux agents

suivants :

Les agents de type Foyer sont toujours présents dans le système, ils représentent

la population autochtone. Leur consommation d'eau dépend du nombre de

personnes présentes, du prix de l'eau, du jour dans l'année et de la température ;

Les infrastructures touristiques absorbent de grande quantité d'eau pendant les

saisons estivales. Ces infrastructures sont représentées dans ce modèle par des

agents de type Hôtel. Leur consommation dépend de leur standing, de leur

nombre de chambre, du jour de l'année et de la température.

L'implémentation du modèle s'est faite à l‟aide de la plateforme CORMGIS. Les

données géographiques sont intégrées dans le SMA grâce au module SIG de

CORMGIS. Le système informatique d'aide à la décision est initialisé en utilisant des

bases de données qui décrivent précisément le système étudié : topographie, sols,

habitats, couvert végétal, agriculture, industrie, secteur touristique et réseau

hydrographique. Le module fonctionnel "Gestion des Extrants" de la plateforme

CORMGIS analyse ces données pour les transmettre ensuite au SMA. Ce dernier sert

comme outil de simulation. Les résultats de la simulation sont analysés par le module

"gestion des extrants" de la plateforme CORMGIS. Ces expérimentations sont

conservées dans le SIG pour une éventuelle utilisation.


76

3.5.2 Systèmes de résolution de problèmes

3.5.2.1 Un système multi-agent pour l’aide à la décision d’un Collectif

Dans [LEBA 03], il a été réalisé un système multi-agents pour l‟aide à la décision d‟un

collectif. La décision concerne la prévision de la distribution d‟eau sur un ensemble

d‟acteurs concernés par la consommation de cette ressource limitée.

Le système proposé est fondé sur un modèle multi-agents et adopte l‟approche

« voyelle ». Deux types d‟agents sont définis :

1. Des agents cognitifs représentés par les agents Agriculteurs et l‟agent

Fournisseur d‟eau. Ils comportent plusieurs modules, des connaissances de soi

et des autres, un module de décision permettant à l‟agent de choisir entre

différentes stratégies correspondant à un ensemble de règles permettant aux

agents d‟atteindre leurs buts, un module de communication entre les différents

agents et une mémoire des échanges avec les autres Agriculteurs et le

Fournisseur d‟eau. Chaque agent agriculteur possède des connaissances et des

stratégies. Le Fournisseur d‟eau a pour rôle la distribution de l‟eau disponible

aux agriculteurs en tenant compte des réserves à faire pour les autres usages et

notamment les problèmes environnementaux.

2. Des agents réactifs représentés par l‟agent Climat, les agents Cultures et l‟agent

Collecteur ou distributeur d‟informations. L‟agent Climat joue un rôle important

dans ce modèle car il régule les quantités d‟eau utilisées chaque année ainsi que

le rendement des cultures. Cet agent est caractérisé par des informations

relatives à une année donnée comme par exemple la fréquence de pluviométrie,

taux de l‟humidité, etc. et, une procédure de calcul qui détermine le climat de

façon aléatoire pour chaque année de simulation. Toutefois, l‟utilisateur peut

modifier le climat d‟une ou plusieurs années pour examiner, par exemple, les

conséquences de la succession de trois années très sèches. Chaque agent Culture

est caractérisé par un ensemble de données telles que, par exemple, la prime à

l‟hectare ou les charges à l‟hectare. Des procédures de calcul selon la loi en

vigueur déterminent le rendement en fonction de l‟eau allouée et du type

d‟année. Des modèles de culture ont été mis au point par les agronomes. L‟agent

Collecteur ou Centre d‟information permet de faire la synthèse des résultats de

chaque agriculteur et de la mettre à la disposition de l‟ensemble des

Agriculteurs. Le centre d‟information reçoit des informations de chaque

Agriculteur telles que, le type d‟Agriculteur (maïsiculteur ou céréalier), sa

surface, son assolement, sa surface irriguée, le rendement des cultures en sec et

en irriguées, l‟eau consommée ou encore ses résultats économiques. Le Centre

de Gestion traite ces informations pour chaque Agriculteur. Il classe les

exploitations en trois groupes par résultat décroissant. Cette information est

visible par l‟ensemble des Agriculteurs.

L‟environnement contient les objets et l‟ensemble des agents modélisés. Les agents sont

capables d‟agir sur cet environnement à partir des entrées sensorielles qu‟ils reçoivent

de ce même environnement. Ainsi, l‟agent Climat, une fois déterminé, va permettre à

l‟agent Culture d‟utiliser la méthode permettant de calculer le rendement en fonction de


77

l‟année climatique. Ce rendement permettra aux agents Agriculteurs de calculer leurs

résultats économiques.

Les agents ont des buts individuels. La satisfaction d‟un agent agriculteur, qui obtient

une grande quantité d‟eau, entraîne l‟insatisfaction d‟autres agents agriculteurs. Aussi,

les ressources peuvent être insuffisantes, ce qui conduit à des conflits entre agents.

Le Protocole de négociation est réalisé entre deux types d‟agents. D‟une part, celui qui

émet une demande (agent A) et celui qui a le rôle de décideur pour l‟allocation de la

ressource (agent D) d‟autre part. Les agents ont chacun des stratégies et des objectifs à

atteindre. Pour cela, il est nécessaire qu‟il y ait des échanges avec les autres agents pour

obtenir une partie de la ressource désirée.

Le modèle renferme un grand nombre d‟agents demandeurs et un agent qui partage la

ressource en fonction des disponibilités et de la réglementation testée. Chaque agent

demandeur a son propre objectif à atteindre. L‟agent décideur a pour rôle de partager au

mieux la ressource en tenant compte de l‟ensemble des demandes des agents. Cet agent

décideur reçoit toutes les informations provenant de l‟ensemble des agents. Il peut, par

exemple, faire une proposition en tenant compte du comportement des agents

demandeurs. Ainsi, l‟agent décideur possède une vision centralisée pour résoudre les

conflits d‟usage de la Ressource

Une structure organisationnelle a été définie par un ensemble d‟agents caractérisés par

des rôles, ainsi que par des relations abstraites qui existent entre ces rôles. Dans ce

système l‟organisation structure les agents en groupes, hiérarchies et relations.

Les simulations réalisées avec le prototype utilisent une population d‟Agriculteurs ayant

des comportements différents dans le choix des années de référence qu‟ils prennent pour

calculer leur demande en eau auprès du fournisseur ainsi qu‟un fournisseur d‟eau qui

utilise des règles d‟arbitrage pour répondre à chacune des demandes formulées par les

agriculteurs, compte tenu des disponibilités initiales de la ressource. La simulation se

déroule sur plusieurs années. De manière générale, le système évolue selon la demande

en eau et la disponibilité d‟eau déterminée par le climat de l‟année.

Chaque année est décomposée en plusieurs phases :

Une phase initiale : une phase initiale détermine la séquence des types d‟années

climatiques et la population initiale d‟Agriculteurs ;

Une phase de négociation : les agents Agriculteurs déterminent en fonction de

leur comportement, la quantité initiale d‟eau d‟irrigation à négocier auprès du

Fournisseur d‟eau sans connaître, à l‟évidence, le climat à venir. Ils envoient

cette demande au Fournisseur d‟eau ;

L'agent Fournisseur d‟eau récapitule l‟ensemble des demandes et les traitent,

puis propose par message à chaque Agriculteur un volume d‟eau. Si l‟ensemble

des demandes est inférieur à sa capacité à fournir, la négociation s‟arrête. Dans

le cas contraire, les propositions du Fournisseur d‟eau sont fonction de la règle

d‟allocation d‟eau testée. Pour une simulation, une seule règle est appliquée. Elle

est définie par l‟utilisateur, ce qui peut amener les Agriculteurs à accepter ou

refuser cette proposition. Le processus s‟arrête quand toute l‟eau a été attribuée

ou lorsqu‟il n‟y a plus de nouvelles demandes de la part des Agriculteurs ;


78

Une phase de jeu de la nature : Le climat est tiré au hasard. Les agents cultures

déterminent la méthode à utiliser pour calculer les rendements en fonction du

climat et de l‟eau apportée. Cette méthode est rendue visible pour l‟ensemble

des agents, ce qui permet à chaque Agriculteur de calculer son rendement ;

Une phase de synthèse des résultats : en fin de campagne, les Agriculteurs

récoltent leurs cultures et établissent leur revenu de l‟année.

La simulation, et plus particulièrement la simulation multi-agents, permet de représenter

la multiplicité des acteurs, la diversité de leurs comportements et les interactions entre

ceux-ci. Pour un scénario de règles d‟application donné concernant la régulation sur

l‟eau, elle permet d‟en envisager les conséquences selon différents critères :

économique, environnemental, durabilité, etc. La multiplication des scénarios conduit

alors à avoir un ensemble de scénarios conséquences parmi lesquels les négociateurs

humains feraient un choix. L‟analyse multicritère s‟est avérée donc une aide

appréciable.

3.5.2.2 Aide à la décision et à la négociation en aménagement du territoire

Dans [FERR 03], l‟auteur présente un travail qui rentre dans le cadre de la décision en

aménagement du territoire. L‟aménagement de territoires est un domaine qui vise

globalement à ordonner dans l‟espace des implantations et des activités humaines en

fonction d‟un ensemble de contraintes et d‟objectifs sociaux, économiques et

environnementaux). Ce sont problèmes spatialisés qui utilisent une “carte” (au sens

topologique) de référence, dotée en général d‟une métrique, et qui permet donc de

localiser et de mesurer à la fois les données, les contraintes et les solutions éventuelles.

Le système réalisé est un système d‟aide à la décision et à la négociation en

aménagement du territoire. D‟abord, un système pour l‟aide à la localisation

d‟infrastructures linéaires a été développé suivi par un prototype de système d‟aide à la

négociation de projets en aménagement. Les deux systèmes ont été réalisés à base

d‟agents.

1. SMAALA : Aide à la Localisation d’Aménagements

SMAALA recherche donc les fuseaux de moindre impact vérifiant les contraintes.

L‟impact est évalué point par point à partir des cartes de sensibilité et des pondérations.

Des cartes de pondérations descriptives des responsabilités territoriales des acteurs (par

exemple : un maire décide pour sa commune) sont considérées. Celles-ci constituent des

cartes de systèmes de décision. SMAALA permet d‟analyser la sensibilité d‟une

solution à la variation du paramètre, c‟est à dire d‟observer comment évolue la

représentation spatiale des solutions en fonction d‟un changement de point de vue de

l‟acteur.

SMAALA ne remplace pas l‟expert ; il l‟assiste dans son interaction avec le décideur.

Les cartes de sensibilité sont donc toujours produites « manuellement ». Elles sont

numérisées et adaptées pour entrer dans SMAALA. L‟utilisateur fixe les contraintes

morphologiques sur la structure du projet et, il donne le point de départ et d‟arrivée de

l‟infrastructure, et un ensemble de pondération des critères. La fonction essentielle de

SMAALA est alors de donner l‟ensemble des fuseaux possibles à l‟intérieur du

territoire. Il peut aussi donner les fuseaux un par un. Il permet de tester des alternatives

par rapport aux points de départ et d‟arrivée. Enfin, il permet de tester la variation des


79

fuseaux trouvés en fonction du système de pondération. Les fuseaux trouvés sont

fournis avec une statistique sur leur impact par critère et leur longueur qui induit en

particulier leur coût.

Pour résoudre ce problème spatialisé avec un système multi-agents réactifs, ce dernier

consiste en un ensemble agents dotés de capacités d‟interaction entre eux et avec les

données externes du problème (informations de référence). Ces agents évoluent, en

fonction de leur état actuel, de ce qu‟ils reçoivent du problème et de ce que leur

communiquent les autres agents. Chaque agent est construit de façon à résoudre

localement une partie du problème spatial. Leurs interactions sociales contraignent la

forme globale de la solution. La solution est finalement perçue par le concepteur comme

un état stable global du système.

La trajectoire du fuseau est décomposée en un ensemble d‟agents qui constituent le

«groupe». La structure étant linéaire, les agents sont simplement repérés

structurellement par leur numéro dans la chaîne. Les points de départ et d‟arrivée de la

ligne sont supposés donnés aux bords verticaux (« est » et « ouest ») du territoire. Avec

cette hypothèse, on convient que la ligne ne « revient pas en arrière ». Dès lors, on

contraint chaque agent (« pylône ») à se maintenir dans une trame verticale (Nord - Sud)

perpendiculaire à la direction générale de la ligne. Leur position spatiale est donc

simplement donnée par leur latitude.

2. SANPA : Aide à la Négociation de Projets en Aménagements

SANPA (Système d’Aide à la Négociation de Projets en Aménagements) a pour objectif

de faciliter la construction, l‟échange et la confrontation de représentations spatiales

partagées, c‟est-à-dire permettre aux acteurs d‟échanger des idées, opinions et attentes

autour d‟un espace et de produire ainsi des décisions. Ce système s‟inscrit dans le

contexte de la décision spatiale collaborative. Il s‟agit particulièrement, d‟un outil

facilitant la négociation entre acteurs éventuellement distants par opposition à une

assistance aux réunions souvent asynchrones (il n‟y a pas de “temps” fixé pour la

négociation) et peu contraints (chacun peut agir à sa guise sans se conformer à des

cadres qui seraient imposés par l‟extérieur). C‟est donc un espace de confrontation pour

tous les acteurs qui ne participent pas au processus institutionnel de décision. Le

système peut aussi servir de médiateur entre les décideurs finaux et les autres acteurs.

SANPA a aussi permis de démontrer certaines propriétés des systèmes multi-agents

entre autres une communauté d‟assistance à un processus collaboratif humain.

La méthodologie de conception « voyelle » a été adoptée pour la conception de ce

système :

1) L‟Utilisateur : c‟est un ensemble d‟individus dont l‟organisation et la

communication sont la finalité du projet.

2) L‟Environnement : l‟environnement du SMA est constitué par : Les données

générales sur le projet (cartes, Bases de Données spatiales, données structurelles,

liste des participants, informations techniques) et le reste des informations

accessibles dans le monde du web.

3) Les Agents :

L‟Agent Projet (AP) : il est indépendant des acteurs, gère le projet,

maintient la cohérence et coordonne l‟ensemble. Il est au service des


80

autres pour gérer l'information. L'AP ne doit pas négocier d'actions avec

les autres agents, il a pour tâche de conseiller, informer et prescrire.

Les Agents Assistants (AA) : ils sont attachés à un acteur. Ils constituent

le noyau de SANPA. Fondamentalement, ils doivent servir simplement

de médium. Mais, en fonction du contexte, ils peuvent enrichir, orienter

et même remplacer l'acteur.

Les Agents SMAALA (AS) : ils sont gestionnaires de noyaux SMAALA.

Les Agents « objets géographiques » (GéOA) : de type réactifs, ils sont

utilisés par les AS.

4) Les Interactions : les messages entre agents constituent les interactions

principales. Les GéOA interagissent entre eux et sont contrôlés par les AS.

3.5.2.3 ANYMAS : Aide à la décision en temps réel

Dans les systèmes d‟aide à la décision qui exploitent des systèmes d‟informations

distincts, se pose le problème de l‟extraction de l‟information pertinente par rapport à

une situation donnée dans des délais contraints. Aussi, certaines situations requièrent

des prises de décision dans l‟urgence ou du moins avant des échéances temporelles

fixées. Lorsque toute l‟information disponible à propos d‟une situation donnée ne peut

être extraite avant l‟échéance impartie, une des solutions est d‟avoir recours aux

techniques anytime. Dans ce contexte, [DUVA 01] a proposé un système d‟aide à la

décision à base d‟agents dont le comportement est anytime. L‟acquisition de

comportement s‟est fait à deux niveaux :

1) Le niveau local : c‟est le niveau agents. Ces derniers sont dotés d‟un

comportement anytime.

2) Le niveau global : c‟est le niveau système multi-agents qui doit lui aussi avoir le

comportement anytime.

L‟architecture modulaire de DIMA a été choisie comme architecture de base des agents.

Elle est ensuite augmentée de modules supplémentaires pour réaliser une architecture

anytime. Les agents de coordination temporelle possèdent un module qui fonctionne

comme une fonction de seuil. Lorsque le seuil en nombre de messages échangés est

atteint par un agent, les agents concernés par la communication doivent se synchroniser

afin de lancer la réification d‟un seul agent de coordination temporelle. Un groupe

d‟agents fortement liés par des communications est créé alors autour de ce nouvel agent.

Pour un agent donné, lorsque sa fonction de seuil lui indique que ses communications

ont dépassé ce seuil, il aura alors deux possibilités :

1. Adhérer à un groupe existant, si dans son réseau d‟accointances (les agents avec

qui il communique) un ou plusieurs agents se sont déjà regroupés au tour d‟un

agent de coordination temporelle.

2. Réifier un nouvel agent de coordination temporelle et fonder ainsi un nouveau

groupe.

Lorsqu‟un agent est amené à résoudre un problème, il fait appel à d‟autres agents. Il

peut obtenir une réponse dont la qualité n‟est pas optimale. Dans le cas des agents

anytime, la qualité du résultat est indirectement une fonction de la qualité des éléments

que l‟on a fournis à cette fonction en entrée. Lors d‟un processus de résolution de


81

problème ou de calcul d‟une solution on utilise des agents de coordination. Ces derniers

sont rattachés à de petits groupes d‟agents très fortement liés par leurs communications

et qui sont soumis au phénomène de composition d‟algorithmes anytime.

Le système ANYMAS est dédié à la gestion de marchandises : Les clients souhaitent

passer des commandes auprès d‟un ensemble de fournisseurs alors que les acteurs

(clients et fournisseurs) sont distribués.

Le fournisseur est un SMA. Il est composé de :

L‟agent stock : il a pour charge de gérer le stock du fournisseur. Il scrutera l‟état

du stock et, lorsque cela est nécessaire, il réalimente le stock. Il prend en compte

aussi les délais de livraison. Cet agent est autonome.

L‟agent commande : il a pour charge de traiter les commandes. Il fonctionne en

environnement distribué.

Un agent relation publique : il répond aux questions éventuelles des clients

Le client est un SMA. Il est formé de :

Des agents requêtes : les clients effectuent des interrogations sur les systèmes

d‟information mis à leur disposition grâce aux agents requêtes. Ces agents ont

un comportement anytime avec la possibilité d‟évoluer en milieu distribué.

L‟agent interface : il contrôle les interfaces des clients et redirige les réponses

vers les requêtes concernées.

Un agent commande : il a la charge de communiquer avec son homologue coté

fournisseur.

Les objets de l‟application :

Les produits : ils sont caractérisés par leurs noms, prix, et quantités. Ils servent à

alimenter les bases de données stock.

Les commandes : sont des éléments échangés entre les clients et les fournisseurs

aux moyens d‟agents de commandes. Ces derniers échangent des messages et

traitent des commandes. Le traitement d‟une commande par un agent coté

fournisseur consiste à vérifier la disponibilité du produit en stock, puis effectuer

la commande, c'est-à-dire, mettre à jour la base de données stock et la base de

données commandes. Cette dernière consiste à reprendre les différents éléments

de la commande ainsi que la date. Ces éléments peuvent âtre utilisés par les

agents de stock pour gérer le stock des fournisseurs.

Discussion

Les systèmes multi-agents offre des possibilités de modélisations appropriés aux

différents domaines d‟applications : la gestion d‟une chaine logistique, gestion de l‟eau,

l‟aménagement de territoire et de projets collectifs. Les systèmes qui en résultent sont

des simulateurs fondés souvent sur la négociation pour amener les collectifs à la prise

d‟une décision commune et parfois consensuelle. La topologie décentralisée est souvent

la caractéristique intrinsèque de ces systèmes étant données que les applications

modélisées se produisent dans au sein d‟entreprises étendues et multi-sites.

Le processus de décision sous-jacent renferme différentes techniques telles que le vote,

Delphi, NGT et prend en compte l‟aspect incertain, trait de certains domaines de

gestion. Différentes approches sont adoptées pour la conception de tels systèmes telles


82

que la méthodologie « voyelle » où les composants (Environnement, Interaction, Agents

et Objets) sont parfaitement mis en évidence.

3.6 Conclusion

Nous avons présentés, dans ce chapitre, quelques travaux de développement de SMA

dans le domaine de l‟aide à la décision, et en particulier, l‟aide à la décision

collaborative. Ceci nous a permis de prendre conscience des différents problèmes de

conceptions, des choix adoptés et, de situer et de mettre en évidence notre contribution

relativement à ces travaux dans ce domaine. L‟étude de l‟état de l‟art, nous a permis de

classifier les diverses propositions relevées dans la littérature en deux classes

principales :

1. Les systèmes de simulation (simulateurs),

2. Les systèmes de résolution de problèmes (résolveurs).

Les systèmes de simulation reposant sur des architectures à base d‟agents modélisent le

fonctionnement d‟un système donné. L‟objectif de cette catégorie de systèmes est de

permettre l‟évaluation des performances du système global relativement à des tests

particuliers. Ils sont aussi utilisés comme des outils de prédiction. A ce titre, le système

est soumis à des situations fictives potentielles et probables. Ces dernières sont crées en

changeant des données et des paramètres. L‟observation du comportement du système

permettra aux décideurs d‟anticiper dans la réflexion de la prise de décision lorsque des

situations analogues se présenteront dans la réalité. Ceci permettra d‟éviter des risques

qui peuvent être conséquents dans les domaines économiques, environnementaux,

gestion de crise, etc.

Les systèmes de résolution de problèmes, quant à eux, sont caractérisés par l‟objectif

visé qui est la résolution d‟un problème particulier d‟aide à la décision. Ce problème est

une décision à prendre par des décideurs étant donnée une situation. Dans cette classe

de systèmes, nous retrouvons surtout des systèmes d‟aide à la négociation. Cette

dernière est généralement réalisée sur un poste de travail, mais dans certains cas le

système est distribué.

Le chapitre suivant est consacré au développement de notre contribution. Nous

projetons de modéliser une architecture à base d‟agents pour l‟aide à la décision

collaborative. Le processus implique un groupe de décideurs répartis et engagés dans

des sessions d‟aide à la décision et dont l‟objectif est d‟atteindre une décision collective.

CHAPITRE IV

PROPOSITION D’UNE ARCHITECTURE

D’UN SYSTEME D’AIDE à LA DECISION

COLLABORATIVE

Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative

84

4.1 Introduction

La décision collective considérée dans ce travail est celle qui est élaborée par un groupe

de participants suivant un processus d‟aide à la décision de groupe. L‟objectif des

membres du groupe est de faire émerger une décision consensuelle. Cette dernière est

l‟aboutissement d‟une dynamique interactionnelle et d‟échanges de points de vue entre

les membres du groupe. Le GDSS est un moyen automatisé dédié au travail de groupe

avec la particularité de supporter l‟aide à la décision [ZARA 05] [SOUB 96].

Relativement à un SIAD, le GDSS doit en plus gérer les interactions nécessaires à la

concertation et à l‟échange d‟information entre les membres du groupe afin de faire

converger le groupe vers une « bonne » décision. Pour ce faire, il se doit de :

coordonner les actions des participants et du facilitateur,

fournir aux participants les informations nécessaires.

La coopération est située à deux niveaux lors de la réalisation du système collaboratif :

niveau participant et niveau groupe. Pour cela, deux types de coopération sont mis en

œuvre :

Coopération Homme /Machine où le système doit pouvoir jouer le rôle de

collaborateur avec le décideur, c‟est à dire intégrer l‟utilisateur dans le processus

de résolution de problème, pour pouvoir offrir une action coordonnée à celle du

décideur. Elle est mise en œuvre à travers notre proposition d‟un SIAD

Coopératif.

Coopération homme-homme médiatisée où le GDSS distribué doit être capable

de créer et de soutenir une bonne dynamique de groupe. Celui-ci doit donc

contribuer à faire disparaître la virtualité de présence des participants. Le travail

doit idéalement se dérouler aussi naturellement qu‟en co-présence.

Au niveau de cette partie, nous proposons une architecture à base d‟agents d‟un GDSS

distribué. Nous avons adopté approche de conception fondée sur les SMA où chaque

acteur sera représenté par une structure organisationnelle d‟agents. Cette dernière,

permettra le partage des connaissances et des tâches entre les différents agents, ce qui

réduira la complexité du système. Ces différents agents devront coopérer afin d‟assister

l‟utilisateur dans les tâches de résolution de problème, de coordination avec les autres

agents et de collaboration avec les autres utilisateurs. Les SMA contribuent

significativement en fournissant des modèles, des méthodologies de conception et des

plates-formes d‟exécution distribuées comme MADKIT [GUTK 00], JADE (Java Agent

DEvelopment framework) [BELL 06], etc.

4.2 Spécification du GDSS

Nous considérons la structure du GDSS distribué développée dans [ADLA 07] (voir

figure 4.1). Nous nous mettons dans un contexte tel que les acteurs sont dispersés

géographiquement. Il existe deux types d‟acteurs : le facilitateur (le manager ou encore

l‟initiateur) et les décideurs (les participants).


85

1) Le facilitateur : son activité consiste à faire participer dans le cadre d‟une

démarche collaborative un groupe de participants ;

2) Les participants : le système est constitué d‟au moins deux participants. Ce sont

les experts décideurs qui constituent le groupe.

Ce système doit permettre à un facilitateur de présenter un problème de prise de

décision collective. Les participants qui sont géographiquement éloignés peuvent

d‟abord intégrer le groupe puis participer à la résolution collective du problème posé

(tâche à résoudre). Dans le contexte de ce travail, les participants ont tous le même rôle.

Ils doivent proposer une solution au problème posé par le facilitateur. L‟activité de

prise de décision est caractérisée par des sessions de collaboration synchrones, au cours

desquelles les participants agissent simultanément et depuis des points d‟accès

distribués.

CI-DSS : Système d‟aide à la décision coopératif spécifique (propre à chaque décideur)

GF-DSS : Système d‟aide à la décision coopératif du facilitateur

Système d‟aide à la décision de groupe : Outils GDSS :

Le modèle du processus de prise de décision considéré est celui Simon [SIMO 77]

[TURB 93] [LEVI 89], étendu et adapté à la prise de décision de groupe par Adla [ADLA

07]. Ce modèle se compose de trois phases (voir figure 4.2) :

La phase de pré-décision : à ce niveau il s‟agit de définir les bases ainsi que les

objectifs du processus. Ce sont l‟ensemble des contraintes ainsi que l‟ensemble

des caractéristiques que la solution devra satisfaire.

La phase décision : est composée de 4 étapes :

o La génération des options de solutions : les différentes options de

solutions sont générées par les participants puis portées à la

connaissance du groupe.


86

o L‟organisation des solutions alternatives : il s‟agit de détecter puis de

traiter l‟occurrence de redondance et synonymie dans l‟ensemble des

alternatives proposées.

o L‟évaluation des solutions alternatives : à ce niveau, différentes

méthodes d‟estimation et d‟évaluation sont utilisées afin de confronter

les différents points de vue des participants.

o La décision : la solution retenue résulte des étapes précédentes. Elle doit

être notifiée aux différents acteurs. Aussi, elle doit vérifier les

contraintes et l‟objectif posés au cours de la phase de pré-décision.

La phase de post décision : il s‟agit principalement de garder la trace des

décisions passées. A cet effet, une mémoire organisationnelle (base de cas) est

mise à jour.

Dans le contexte de notre travail, nous considérons qu‟au niveau de la phase décision et

particulièrement lors de la génération des alternatives, le participant peut être assisté par

un SIAD coopératif.


87

4.3 Modélisation du GDSS à base d’agents

4.3.1 Méthodologie adoptée

Il existe diverses démarches de conception de systèmes multi-agents. Le choix de l‟une

d‟entre elles pour la conception d‟une application dépend des choix conceptuels que le

concepteur décide de suivre et mettre en œuvre dans son application. Nous avons

adopté l‟approche « voyelle » de l‟équipe MAGMA [DEMA 95]. Cette approche est

fondée sur la décomposition d‟un système multi-agents en quatre éléments (A, E, I,

O): Agent, Environnement, Interaction et Organisation.

Pour mener à bien cette décomposition, une phase d‟analyse (une conception

préliminaire) est requise. Celle-ci doit identifier les 4 composants ou briques du

système et mettre l‟accent sur la fonction globale du système. Cette décomposition

permet de modulariser le système multi-agents. Cette modularité se situe au niveau des

modèles multi-agents, plutôt qu‟au niveau des agents et des compétences d‟agents, ce

qui permet de simplifier la construction du système. Dans la phase conception, il s‟agit

d‟exprimer chaque composant du système avec un modèle conceptuel. Ensuite, intégrer

les différents modèles pour représenter le SMA dans sa globalité [NACH 11b,11c],

[NACH 13], [NACH 14].

1. Agents : cette partie regroupe les éléments nécessaires à la construction des

agents à savoir leur modèle, leur architecture et leur implémentation.

2. Environnement : représente le milieu dans lesquels sont plongés les agents. Il

est généralement spatial dans la plupart des applications multi-agents.

3. Interactions : qui concernent les infrastructures, les langages et les protocoles

d‟interaction entre agents, depuis de simples interactions physiques à des

interactions langagières par actes de langage.

4. Organisation : structure les agents en groupes, hiérarchies, relations, etc.

L‟organisation décrit le cadre dans lequel les agents, les ressources, les tâches et

les buts coexistent. Elle assure donc un certain ordre entre entités

éventuellement hétérogènes, lequel concourt à la cohérence du tout [FERB 95].

Le système multi-agent obtenu est ainsi défini:

SMA = Agents + Environnement + Interactions + Organisation

Les fonctionnalités du système multi-agents sont plus que la somme des fonctionnalités

des agents qui le composent. Ce sont les fonctionnalités individuelles des agents

enrichies des fonctionnalités qui résultent de la valeur ajoutée par le système multi-

agents lui-même, parfois appelée intelligence collective.

Fonction(SMA) = ∑ Fonction(Agents) + Fonction collective

Par ailleurs, les systèmes multi-agents peuvent être considérés à un niveau d‟abstraction

plus élevé des entités multi-agents. C‟est le principe de la récursivité :

SMA* = SMA.


88

4.3.2 Conception préliminaire

L‟étude du processus de prise de décision collective en vue d‟une modélisation par les

SMA a montré que les agents doivent être cognitifs car ils doivent posséder des

compétences et un savoir afin de réaliser la tâche qui leur a été affectée.

4.3.2.1 Les agents

Nous avons défini deux agents pour chaque utilisateur :

un agent assistant, et

un agent coordinateur du processus de prise de décision.

De plus, pour le facilitateur, un agent organisateur est défini et aura la charge

d‟organiser les alternatives. Les différents agents du système sont :

L’agent AF : c‟est l‟agent Assistant du Facilitateur, il gère l‟interface entre le

système et le facilitateur. Il doit fournir des caractéristiques ergonomiques qui

procurent un environnement de travail et de communication confortable. Il assure un

espace de travail privé pour le facilitateur et un espace public pour le groupe. Il permet

aussi au facilitateur de communiquer à n‟importe quel moment avec les membres du

groupe en dehors du processus de prise de décision, c'est-à-dire, il permet d‟établir les

communications avec les autres utilisateurs du système par l‟intermédiaire de leurs

agents assistants. Cette dernière fonctionnalité permet d‟alléger le système multi-agents

en simplifiant les interactions car les interactions du processus de prise de décision

passent entre le coordinateur et les collaborateurs et les autres interactions se passent

seulement entre agents assistants. Cela réduit la complexité du système et permet une

gestion aisée des interactions. Aussi, en collaboration avec le facilitateur, il sollicite le

bon groupe de participants (selon le profil des participants et selon le type de la

décision) puis établit l‟agenda de la réunion.

L’agent AD : c‟est l‟agent Assistant du Décideur (participant), c‟est en quelque sorte

le secrétaire du participant. Il représente l‟interface entre le participant et le système.

Lorsque le facilitateur lance un appel à la réunion par l‟intermédiaire de son agent

assistant AF, l‟AD évalue l‟annonce et propose une réponse à l‟acteur participant (selon

sa disponibilité, ses compétences etc.). C‟est l‟acteur participant qui décide de la

participation ou non à la réunion. L‟AD permet de démarrer une session de travail, il

permet aussi de gérer un espace privé pour le participant ainsi qu‟un autre espace public

pour le travail en groupe. L‟AD assure aussi une fonction de communication d‟une part

avec les autres participants par le biais de leurs AD, et d‟autre part avec le facilitateur

par le biais de l‟AF. Ce canal de communication passe seulement par les agents

assistants (AD et AF) et n‟interfère pas avec les interactions relatives au processus

d‟aide à la décision du groupe. Aussi, lorsque le participant est en situation de

génération des solutions, il peut faire appel au DSS (système coopératif d‟aide à la

décision propre au participant) par l‟intermédiaire de l‟AD.

L’agent ACR : c‟est l‟Agent CooRdinateur du processus de prise de décision. Il est

l‟agent central du processus de la prise de décision. Il est en contact avec la structure du

participant. Il est supervisé par le facilitateur par l‟intermédiaire de l‟AF.

Son rôle est d‟assurer le bon déroulement des différentes phases du processus de

décision de groupe. L‟AF démarre le processus de prise de décision de groupe. L‟ACR


89

doit superviser ce processus. Il guide les différentes phases d‟activités collectives. Pour

cela, il interagit avec les agents collaborateurs des participants. Il affiche les

informations requises en cas de besoin. Il sait qui a proposé quoi, mais il doit aussi

savoir préserver l‟anonymat demandé par certains participants. Il a donc une vision

globale sur le déroulement du processus de prise de décision de groupe. Aussi, après la

phase d‟évaluation des alternatives, le résultat envoyé par l‟AOR ou Agent

ORganisateur (une liste des alternatives épurée et classée) est reçu par l‟agent ACR. Ce

dernier, selon l‟agenda établi lors de la phase pré-décision, précise la méthode

dévaluation à considérer puis envoie aux participants la liste des options de solutions

traitées avec la méthode d‟évaluation considérée.

L’agent AC : c‟est l‟Agent Collaborateur. Il assure le bon déroulement du processus

d‟aide à la décision de groupe côté participant. Les seules interactions qu‟il gère avec la

structure du facilitateur sont celles avec l‟ACR. Il ne communique pas directement avec

les agents des autres participants, ni avec les autres agents du facilitateur autre que

l‟ACR. Le rôle de cet agent est consacré seulement à la gestion des interactions

permettant la collaboration du participant dans le processus d‟aide à la décision de

groupe.

L’agent AOR : c‟est l‟Agent ORganisateur. L‟AOR est sollicité par l‟ACR lors de la

phase d‟organisation des alternatives. L‟AOR a les connaissances sur le domaine dans

lequel est appliqué le processus de prise de décision. Lors de la phase de génération des

alternatives l‟ACR s‟assure que les participants émettent leurs propositions dans les

délais accordés par le facilitateur, suite à cela une phase d‟organisation des alternatives

démarre. Cette tâche est assurée par l‟AOR qui doit avoir les compétences nécessaires

pour cela. Son rôle est d‟épurer les alternatives de tout ce qui est synonymie, répétition

et contradiction. L‟AOR ne sait pas qui a proposé quoi, il n‟a pas de vision sur le

groupe. Il émet les résultats à l‟ACR lequel, dans le cas où le facilitateur approuve,

poursuit le processus.

L’agent ASYST: c‟est l‟Agent SYSTème. Il a pour tâche de contrôler les connexions

et déconnexions à l‟application des différents utilisateurs. Il se charge de créer les

comptes des facilitateurs et des participants. Lors d‟une réunion, il indiquera tous les

acteurs présents et signalera à l‟AF toute déconnexion d‟un participant du système au

cours du processus. La déconnexion d‟un participant au cours du processus de prise de

décision peut être :

o volontaire : le participant peut avoir un empêchement qui le rend

indisponible pour la suite de la session.

o involontaire : coupure de courant, panne machine ou système, etc.

4.3.2.2 Les cas d’utilisation

Les cas d‟utilisation (use cases) sont la première étape UML d‟analyse d‟un système.

Ils ont pour rôle de recueillir, d‟analyser et d‟organiser les besoins, et de recenser les

grandes fonctionnalités d‟un système. Ils décrivent les interactions du système avec

l‟utilisateur [SIGA 05]. Ils permettent de concevoir et de construire un système adapté

aux besoins de l‟utilisateur. Ils mettent en évidence les relations fonctionnelles entre les

acteurs et le système étudié. C'est donc une vue du système depuis son environnement

extérieur.


90

Plus précisément, un cas d‟utilisation décrit une séquence d‟actions réalisées par le

système qui produit un résultat observable pour un acteur. Un acteur, au sens UML,

représente le rôle d'une entité externe (utilisateur humain ou non) interagissant avec le

système. Il est à noter qu'un utilisateur peut être amené à jouer plusieurs rôles vis-à-vis

du système et à ce titre être modélisé par plusieurs acteurs. Nous avons opté pour une

description textuelle des cas d‟utilisation.

4.3.2.2.1 Côté participant

Connexion d’un participant : quant un participant se connecte à l‟application,

l‟agent ASYST se charge de l‟identifier. S‟il n‟a pas été sollicité pour une participation

par le facilitateur, il aura une interface (la page web de l‟application) qui l‟informe de

son état « non sollicité ». Dans le cas où le participant a été contacté par téléphone ou

par e-mail en lui précisant l‟heure de la réunion, cela veut dire qu‟il fait partie du

groupe qui doit participer au processus d‟aide à la décision. Sa connexion à

l‟application conduit à la création de l‟agent AD dans le système multi-agents. L‟agent

AF est informé de sa connexion par l‟ASYST et lui envoie la demande de participation

à réunion de prise de décision. Le participant analyse cette demande de participation et

décide de continuer le processus ou bien de se déconnecter.

Début du travail : le participant indique à l‟AD qu‟il accepte de participer à la

session de prise de décision. L‟agent AD prévient l‟AF de cette décision. Une fois la

totalité (ou une majorité ou un nombre seuil) des participants sollicités a répondu à

l‟appel de la réunion, la phase de pré-décision est lancée.

Génération des options solutions : lorsque l‟AD présente au participant la

formulation du problème envoyé par l‟ACR, le participant choisit soit de générer une

solution directement, ou bien de consulter les décisions prises dans le passé, ou encore

d‟activer son propre DSS qui lui permet une génération coopérative des options de

solutions.

Demande d’évaluation des options des solutions : lorsque l‟AOR a fini sa tâche

d‟organisation des alternatives (des propositions des participants), il envoie le résultat à

l‟agent ACR. Ce dernier, applique l‟agenda précisé par l‟AF ainsi que les paramètres de

cette résolution dont la méthode d‟évaluation des alternatives. Par la suite, l‟ACR

envoie les alternatives organisées dans le format de la méthode d‟évaluation considérée

aux différents agents AC.

Evaluation des options de solutions : une fois l‟agent AC d‟un participant reçoit la

demande d‟évaluation de l‟agent ACR, il la transmet à l‟agent AD de son participant

qui la présente dans son interface au participant. Ce dernier évalue puis renvoie sa

proposition à l‟ACR par l‟intermédiaire de l‟AC qui gère le temps alloué à cette phase

puis renvoie la proposition à l‟ACR. L‟ACR collecte toutes les propositions, procède

ensuite à une analyse, puis communique avec le facilitateur par l‟intermédiaire de l‟AF

pour décider du choix d‟une solution. Dans le cas où le choix n‟est pas possible, l‟ACR

relance la phase d‟évaluation avec une autre méthode d‟évaluation. Dans le cas

contraire, on relance le processus d‟aide à la décision collective à partir de la phase

génération des options de solutions.


91

Fin du travail d’un participant: le participant informe l‟AD qu‟il veut terminer une

session. L‟AD signale à l‟ASYST la déconnexion du système. L‟ASYST informe l‟AF

de cette déconnexion. Ce dernier vérifie l‟état de la résolution. Si le processus est

terminé alors l‟AF prend acte de cette terminaison de session. Dans le cas où le

processus n‟est pas encore terminé, l‟AF vérifie si le processus de prise de décision

peut continuer sans ce participant, dans ce cas, il prend acte de la fermeture de sa

session. Dans le cas contraire, on reporte la réunion en proposant éventuellement un

autre rendez vous, puis on informe l‟ensemble des participants présents de la fermeture

de la session et l‟application sera fermée.

4.3.2.2.2 Côté facilitateur

Connexion du facilitateur : différentes personnes peuvent jouer le rôle de

facilitateur dans différentes sessions de prises de décision de groupe. Pour cela, le

système doit reconnaitre chacun d‟eux par son identifiant ainsi qu‟un mot de passe.

Mais, lors d‟une session un seul facilitateur est autorisé à se connecter.

Lorsqu‟un facilitateur se connecte, l‟ASYST doit le reconnaitre et lui permettre l‟accès

au système. Puis, un agent AF est créé ainsi que les deux agents ACR et AOR. L‟agent

AF permet au facilitateur de démarrer le processus de prise de décision et lui présente

aussi une aide à la facilitation au cours de chacune des phases de prise de décision.

Début du travail : le facilitateur introduit sa requête d‟aide à la décision. L‟AF tente

(en utilisant ses connaissances dans ce domaine) de catégoriser cette décision. S‟il

réussit, il présente le résultat au facilitateur qui peut approuver ou bien re-catégoriser la

décision. Si une décision est nouvelle pour le système, alors c‟est au facilitateur de lui

fixer le groupe des participants, l‟agenda et ses différents paramètres. Dans le cas où

c‟est une catégorie qui existe dans le système, alors l‟AF est en mesure de proposer le

groupe des participants, l‟agenda qui lui convient ainsi que ses différents paramètres de

facilitation. La main est donnée au facilitateur pour approuver ou bien modifier ces

informations.

Contacter les participants : une fois que les participants concernés sont contactés

par e-mail ou bien par téléphone en leur précisant la date et l‟heure de la réunion, au

moment de la réunion l‟AF attend la connexion des participants. Une fois le quorum de

démarrage atteint, l‟AF envoie la requête de participation aux membres du groupe qui,

au bout d‟un délai préalablement fixé, ils doivent tous donner leur réponse quant à la

participation à la réunion. Suite à ces réponses, l‟AF présente le nombre des

participants et leurs identités (dans le cas où l‟anonymat n‟est pas exigé par le

participant) au facilitateur. Le processus de prise de décision de groupe peut alors

démarrer.

Lancement du processus de prise de décision : dés que le problème est défini et les

participants présents et prêts à participer, le facilitateur active le lancement du

processus de prise de décision. Les agents ACR et AOR sont créés et initialisés avec les

connaissances et les données relatives au problème posé. Puis, l‟ACR envoie le

problème aux ACs des différents participants.

Communication entre deux utilisateurs : Deux utilisateurs participant/participant

ou bien participant/facilitateur peuvent communiquer par l‟intermédiaire d‟une fenêtre


92

de dialogue (textuelle). Pour établir une communication, un utilisateur (participant ou

facilitateur) doit choisir un autre utilisateur dans la liste des utilisateurs présents lors

d‟une session de prise de décision de groupe. L‟agent assistant de l‟utilisateur initiateur

de la communication demande à l‟agent assistant du correspondant de communiquer.

En cas d‟acceptation, l‟agent du correspondant peut échanger des messages sinon la

communication est coupée. Il faut signaler que le système permet à un participant de

garder l‟anonymat, et par conséquent, il n‟apparaitra pas explicitement dans la liste.

Ses coordonnées seront masquées et la communication avec cet utilisateur sera

impossible.

4.3.2.2.3 Côté administration

Ce cas d‟utilisation est aux frontières du processus d‟aide à la décision car il

n‟intervient pas directement mais contrôle la présence des acteurs qui composent le

groupe lors d‟une session. En effet, lors du lancement de l‟application, l‟ASYST reçoit

la liste des participants par l‟AF. Dés qu‟un participant se connecte, il vérifie ses

paramètres (identifiant et mot de passe) pour lui donner ou lui refuser l‟autorisation

d‟accès. Aussi lorsque l‟application est déjà lancée, il a pour tâche de contrôler la

présence des participants. Ainsi, il doit signaler un participant qui quitte l‟application

(panne de machine ou interruption de la connexion ou bien arrêt volontaire du

participant). Ce départ est signalé à l‟AF qui en coopération avec le facilitateur décide

soit d‟arrêter le processus de prise de décision, soit de continuer en signalant à l‟ACR le

départ du participant en question.

4.3.2.3 Architecture générale du SMA

La figure 4.3 illustre l‟architecture générale du SMA. Sur cette figure nous avons

considéré un groupe d‟utilisateurs qui participent à une session de prise de décision

collective. Ce groupe est composé d‟un facilitateur et de deux participants.


93

AD : Agent Assistant du Décideur (participant)

AC : Agent Collaborateur

DSS : SIAD Coopératif relatif au participant

BDD : regroupe les différentes Bases De Données du facilitateur

BC : Base de Cas

AF : Agent Assistant du Facilitateur

ACR : Agent CooRdinateur

AOR : Agent ORganisateur

: Lien entre utilisateur et le système

: Lien entre les agents d‟une même structure organisationnelle

: Lien de collaboration entre agents appartenant à des structures organisationnelles différentes

: Lien entre agents assistants

: Lien d‟utilisation d‟objets (DSS/BDD/BC)

Cette architecture présente les agents déjà identifiés ainsi que les relations qui existent

entre eux. Ces relations ont été déduites à partir de l‟expression des cas d‟utilisation

déjà établis précédemment. Nous avons aussi mentionné les objets appartenant à

l‟environnement du système. Il s‟agit du DSS (SIAD coopératif) relatif au participant et

des bases de données relatives au facilitateur. Le DSS (SIAD coopératif) est le système

d‟aide à la décision propre à chaque participant, il peut être sollicité par l‟AD.

La base de données du facilitateur est constituée de deux bases principales :

1) Une base de données d‟aide à la facilitation, elle structure :

Les données relatives aux participants : ces données informent l‟AF sur le

profil des participants et donc serviront à la formation des groupes.

les données relatives à la tâche à résoudre : ces données seront exploitées par

l‟AF afin d‟établir l‟agenda relativement à la tâche à résoudre. Aussi, ces

données permettent de catégoriser la tâche à résoudre, ce qui servira à

préciser les profils des participants adéquats.

2) Une base de données historique ou base de cas : elle sert à rechercher un cas

similaire à la tâche proposée à la résolution avant de se lancer dans le processus

d‟aide à la décision du groupe.

4.3.3 Conception détaillée

Au niveau de cette phase, il s‟agit de concevoir formellement les différents éléments

qui composent le SMA. Comme nous utilisons la méthodologie « Voyelle », il faudra

donc définir le système multi-agents en termes de briques (A, E, I, O). Au niveau de la

conception préliminaire nous avons déjà identifiés tous les agents du système ainsi que

leurs rôles respectifs. Aussi, comme les interactions représentent un élément clé dans

notre système, alors pour la conception détaillée, nous avons opté pour l‟ordre de

décomposition suivant : ((I, O), A, E).

4.3.3.1 Les interactions

Nous présentons les interactions sous forme de chronogrammes. Toutefois, nous

précisons que nous n‟avons considéré que les interactions qui rentrent dans le cadre du


94

processus d‟aide à la décision de groupe. Par conséquent, nous n‟avons pas considéré

celles qui se passent entre agents assistants, celles si sont considérées comme des

interactions informelles entre les participants mais qui peuvent être utiles à

l‟aboutissement du processus.

4.3.3.1.1 Les chronogrammes

La phase pré-décision :

Sollicitation des participants :

1. Suite à la proposition d‟une tâche à résoudre, l‟acteur Facilitateur sollicite l‟AF.

Selon le type de la tâche et les profils des participants, l‟AF propose une liste de

participants. Les profils des participants potentiels sont déjà stockés dans la base

de données ;

2. L‟AF envoie au facilitateur la liste des participants pour approbation ;

3. Le facilitateur consulte la liste des participants. Il peut supprimer ou bien ajouter

de nouveaux participants. Il envoie ensuite la liste modifiée ou non à l‟AF ;

4. Une fois la liste établie, les participants sont contactés par courrier électronique

ou bien par téléphone par le facilitateur.

5.

Démarrage du processus d‟aide à la décision :

Le décideur qui accepte de participer à la réunion, démarre l‟application à la date et

l‟heure prévue. Il se voit attribuer le droit d‟assister par ASYST.

1. Le facilitateur active l‟AF afin de démarrer le processus d‟aide à la décision.

L‟AF établi l‟agenda ainsi que les ressources disponibles ;

2. L‟AF envoie au facilitateur ses propositions. Le facilitateur peut approuver ou

bien procéder à des modifications puis envoie le résultat à l‟AF ;

3. L‟AF envoie à l‟ACR les participants présents ainsi que les paramètres

d‟initialisation de la tâche à résoudre afin de démarrer la phase de décision ;

4. L‟ACR envoie la tâche à résoudre aux AC des participants composant le groupe.

Facilitateur AF 1

2

3 Interaction Homme/Agent

Figure 4.4 : Chronogramme sollicitation des participants


95

La phase de décision :

Génération de solutions :

1. L‟AC envoie la tâche à résoudre à l‟AD ;

2. L‟AD renvoie la tâche au participant ;

3. Le participant propose une solution. L‟élaboration de la solution est soit fournie

directement par le participant, soit générée par le participant en coopération

avec son DSS ;

4. L‟AD envoi ensuite la solution à l‟AC qui l‟analyse par rapport à l‟ensemble

des contraintes et des caractéristiques que la solution devra satisfaire et qui ont

été précisées lors de la phase de pré-décision ;

5. L‟AC envoie à l‟ACR la solution dans le cas où elle est validée ;

6. La solution est retournée à l‟AD dans le cas contraire ;

7. L‟AD la renvoie au participant.

Organisation des alternatives :

1. L‟ACR active l‟AOR pour une éventuelle proposition d‟épuration des

alternatives ;

2. L‟AOR retourne le résultat de son exécution à l‟ACR ;

3. L‟ACR envoie ces résultats à l‟AF ;

4. L‟AF envoie les décisions épurées au facilitateur ;

5. Le facilitateur peut approuver ou bien procéder à des modifications puis envoie

le résultat à l‟AF ;

6. Les alternatives organisées sont ensuite envoyées par l‟AF à l‟ACR.

Figure 4.5 : Chronogramme du processus de démarrage d‟aide à la décision

Facilitateur AF ACR

1

2 3

AC

Interaction Homme/Agent

Interaction Agent/Agent 4

Figure 4.6 : Chronogramme de génération des solutions

ACR AC

1

3

AD

5

Participant

6

2

7

4


Interaction Agent/Agent


96

Evaluation des alternatives :

1. L‟ACR envoie la liste des solutions dans le format d‟une méthode d‟évaluation ;

2. L‟AC informe l‟AD de la demande d‟évaluation ;

3. L‟AD présente l‟évaluation au participant ;

4. Le participant renvoie le résultat de l‟évaluation des alternatives à l‟AD ;

5. L‟AD le transmet à l‟AC pour coordonner avec l‟ACR ;

6. L‟AC envoie l‟évaluation à l‟ACR qui collecte les évaluations de tous les

participants pour une éventuelle prise de décision.

La décision :

1. L‟ACR élabore la décision, puis l‟envoie à l‟AF ;

2. L‟AF envoie la décision au facilitateur ;

3. Le facilitateur juge la décision (confirmation ou modification),

4. L‟AF renvoie la décision consultée par le facilitateur à l‟ACR ;

5. L‟ACR diffuse la décision aux AC ;

6. L‟AC informe l‟AD de la décision ;

7. Ensuite l‟AD présente la décision au participant.



ACR AOR

1

3

2

4

6

Figure 4.7 : Chronogramme de l‟organisation des alternatives

5

AF

Facilitateur

ACR

2

3

1

6

Figure 4.8 : Chronogramme de l‟évaluation des alternatives

4 5



AC AD Participant


97

Phase de post-décision :

Clôture du meeting :

1. Le facilitateur envoie à l‟AF un message de terminaison du processus de

décision ;

2. L‟AF informe les agents qui appartiennent à sa structure ainsi que les agents AC

des participants et leurs envoie un rapport de fin de réunion. Les agents de sa

structure (l‟ACR et l‟AOR) vont soit s‟arrêter soit se réinitialiser pour entamer

une nouvelle session de prise de décision ;

3. Les agents AC informent les agents AD et les participants (en leur présentant le

rapport de fin de réunion envoyé par l‟AF) ;

4. Les agents AOR et ACR envoie la confirmation de l‟arrêt ou la réinitialisation

du processus de prise de décision ;

5. Le participant confirme à l‟AD l‟arrêt ou la réinitialisation du processus de

décision. L‟AD transmet l‟information à l‟AC ;

6. L‟AC confirme ensuite à l‟AF la fin du processus de prise de décision ;

7. L‟AF informe le facilitateur de la fin effective du processus de prise de décision.

Le facilitateur décidera à ce moment là l‟arrêt de l‟application et la déconnexion

des acteurs ou bien le redémarrage d‟une nouvelle session de prise de décision.

Figure 4.9 : Chronogramme de la décision

AF ACR

2

1

5

Facilitateur

3

AC

Participant

AD

6 7


Interaction Agent/Agent 4



1

2

2

2

Figure 4.10 : Chronogramme de la post décision

AF AOR ACR

Facilitateur

Participant

3

4

4

5

5

6

7

3

AC

AD


98

4.3.3.1.2 Les protocoles d’interaction

Nous venons de présenter dans la partie précédente les interactions entre les agents

humains et artificiels sous forme de chronogrammes. Une interaction entre des agents

d‟un système multi-agents est construite par un enchaînement de messages

communicationnels que ces agents échangent entre eux. Selon le type de modélisation,

cette interaction peut être établie de deux manières [JARR 06] :

Construite par l‟agent sous forme d‟un plan de communication au moment où il en a

besoin pour réaliser sa tâche. Ainsi, l‟interaction est émergente car elle n‟est pas

définie a priori. Les connaissances et les buts des agents régissent l‟interaction en

spécifiant le message à envoyer (acte de communication, agents destinataires, le

contenu du message, etc.).

Conforme à un enchaînement de messages spécifié à l‟avance. Les règles qui

régissent l‟échange de messages forment le protocole d‟interaction. De plus, le

protocole d‟interaction définit le type des messages qui doivent être échangés. L‟agent

doit se conformer aux règles de communication dictées dans le protocole. Comparée à

la première approche, l‟interaction basée sur les protocoles d‟interaction ne nécessite

pas de structure complexe au sein de l‟agent. Ainsi, un protocole d‟interaction spécifie

un ensemble limité de réponses possibles pour un type spécifique de messages.

Pour la modélisation des interactions, nous avons adopté la deuxième approche. A titre

d‟illustration, nous présentons dans cette section quelques protocoles d‟interaction.

Nous formulons chaque protocole sous forme d‟automates à états finis pour chacun des

agents concernés par ce protocole. Dans cette représentation les arcs représentent un

envoi ou une réception de messages.

Protocole de formulation du groupe :

L‟agent AF

Protocole de génération des alternatives :

L‟agent ACR

Init 1

Réception de la

demande de

formation du

groupe à partir

du facilitateur.

Envoi du groupe

proposé au

facilitateur.

Fin

Init 1 2 3

Demande de la

génération des

alternatives de

la part de l’AF

Envoi aux ACs

la demande de

générations des

alternatives

Fin

Réception des

alternatives à

partir des ACs

Envoi du

résultat à l’AF.


99

L‟agent AC

L‟agent AD

Protocole de l’organisation des alternatives :

L‟agent ACR

L‟agent AOR

Protocole de l’évaluation des alternatives :

L‟agent ACR

Init 1 2 3

Réception à

partir de

l’ACR de la

demande de

génération des

alternatives.

Envoi à l’AD

la demande de

générations des

alternatives

Fin

Reçoit le

résultat à

partir de l’AD

Envoi du

résultat à

l’ACR.

Init 1 Fin

Envoi à l’AC de la

demande

d’évaluation.

Réception à

partir des AC

des alternatives

évaluées.

Init 1

Réception à partir de l’ACR

de la demande de

l’organisation des alternatives.

Envoi du résultat

à l’ACR.

Fin

Init 1

Réception à partir de l’AC de

la demande de génération des

alternatives.

Envoi du

résultat à l’AC.

Fin

Envoi du

résultat à l’AF.

Init 1 2

3

Réception à partir de l’AF

de la demande de

l’organisation des

alternatives.

Envoi à l’AOR

la demande de

l’organisation

des alternatives

Réception du

résultat à partir

de l’AOR

4

Fin Réception du

résultat à

partir de l’AF


100

L‟agent AC

L‟agent AD

4.3.3.2 L’Organisation

Au niveau de la phase de conception préliminaire des agents, nous avons adopté

l‟approche cognitive. Cette dernière considère que l‟organisation est fixée a priori.

Ainsi, l‟effort est surtout mis au niveau de la modélisation du raisonnement distribué et

sur les mécanismes interactionnels. Par conséquent, nous considérons que

l‟organisation des agents est statique car les liens d‟autorité et de communication entre

agents peuvent être complètement définis pendant la phase de conception du système.

Ces liens servent à établir un moyen de contrôle global de la société d‟agents et

conduisent le système à la résolution du problème de prise de décision collective.

L‟organisation des agents consiste en la modélisation des relations qui existent entre

ces agents. Les agents doivent disposer d‟une représentation de ces relations pour

communiquer [BAEI 98]. Pour cela, nous devons modéliser les mécanismes qui vont

permettre de supporter l‟organisation de ce groupe d‟agents. Suite à notre analyse

organisationnelle du GDSS, nous avons identifié deux structures d‟agents, l‟une du

facilitateur et l‟autre du participant.

4.3.3.2.1 Structure organisationnelle du facilitateur

Elle est composée de trois agents : AF, ACR et AOR. L‟agent ACR qui est un agent

coordinateur principal du processus de prise de décision, communique avec les deux

autres agents de sa structure organisationnelle. Mais, entre l‟AF et l‟AOR il n y ‟a pas

de communication directe. L‟organisation au sein de cette structure est définie par le

type des communications établies entre les agents.

Réception des

résultats de

l’évaluation à

partir des AD.

Init 1 2 3

Réception à

partir de l’ACR

de la demande

d’évaluation des

alternatives.

Envoi aux AD

de la demande

d’évaluation des

alternatives.

Fin

Envoi du

résultat à

l’ACR.

Init 1 Fin

Réception à partir de

l’AC de la demande

d’évaluation.

Envoi à l’AC

du résultat de

l’évaluation.


101

AF ACR AOR

AF C

ACR C, S C

AOR S

C : Relation de

communication

S : Relation de

subordination

Tableau 4.1 : Les relations

entre les agents de la

structure organisationnelle

du facilitateur.

4.3.3.2.2 Structure organisationnelle du participant

Elle est composée de 2 agents : AD et l‟AC. L‟agent AC qui est un agent coordinateur

au sein de cette structure organisationnelle communique avec l‟AD. L‟organisation au

sein de cette structure est définie par le type des communications établies entre les

agents.

AD AC

AD C, S

AC C, S

C : Relation de communication

S : Relation de subordination

Tableau 4.2 : Les relations entre les

agents de la structure organisationnelle

du participant.

4.3.3.2.3 L’organisation générale au sein du SMA

Les deux structures organisationnelles définies précédemment ne sont pas

indépendantes car il existe des relations communicationnelles entre elles. En effet, les

relations de dialogue entre utilisateurs sont matérialisées par des communications entre

agents assistants. Mais les communications relatives au processus d‟aide à la décision

collective sont matérialisées par les relations qui existent entres les deux agents

coordinateurs : l‟ACR coordinateur principal entre le facilitateur et l‟ensemble des

participants, et l‟AC coordinateur relativement à un participant.


102

Le tableau suivant résume les relations possibles entre les agents des différentes

structures organisationnelles :

AF ACR AOR AC AD

AF C C

ACR C, S C C

AOR S

AC S, C C, S

AD C C, S C

C : Relation de communication ; S : Relation de subordination

Tableau 4.3 : Les relations entre les agents des deux structures organisationnelles.

4.3.3.3 Les agents

Les agents du système sont ceux déjà définis au niveau de la conception préliminaire :

AF, AD, ACR, AC et AOR. Suivant la spécification du comportement des agents, nous

remarquons que les agents doivent disposer de moyens de communication ainsi que des

capacités de raisonnement. Pour cela, ils doivent être cognitifs.

Le fonctionnement des agents cognitifs est représenté par le processus en boucle

suivant : Perception/Décision/Action.

Dans notre cas, la perception et l‟action correspondent respectivement à la réception et

à l‟envoi de messages synchrones. La décision consiste en la réalisation des tâches que

l‟agent doit accomplir. Elle dépend des états internes de l‟agent et des messages reçus.

La figure 4.14 représente le modèle d‟architecture d‟un agent.

Perception Délibération Action

Figure 4.13 : Cycle de base de fonctionnement d‟un agent cognitif


103

Tous les agents du système ne communiquent qu‟avec leurs pairs sauf les agents

assistants l‟AF et l‟AD qui communiquent en plus avec l‟utilisateur.

4.3.3.4 L’environnement

4.3.3.4.1 Présentation topographique du système

Le système que nous projetons de développer est un GDSS. Ce système doit assurer

l‟exécution du processus d‟aide à la décision collective avec l‟hypothèse que les acteurs

impliqués dans le processus de prise de décision sont géographiquement éloignés. Ces

derniers agissent simultanément et depuis des points d‟accès distribués en utilisant le

réseau internet. Donc, le système doit posséder la localisation des participants ainsi que

de leurs agents sur des ordinateurs reliés au réseau Internet.

4.3.3.4.2 Les objets passifs

La base de données : nous présentons la base de données sous forme de

diagrammes de classes UML.

o Partie de la base de données relative aux profils utilisateurs et l‟agenda :

Concernant les profils des participants, nous supposons que les tâches à résoudre sont

classées par catégorie et que chaque profil est associé à au moins une catégorie. Ceci

permettra de déterminer les participants potentiels à la résolution collective, étant

donnée une tâche à résoudre.

Pour l‟élaboration de l‟agenda, nous considérons que :

1. un seul type d‟agenda correspond à chaque catégorie de tâches ;


104

2. à chaque agenda correspond un ensemble de phases et à chaque phase

correspond un ensemble de méthodes possibles.

o Partie de la base de données relative au rapport de clôture : elle

comprend :

1. les mécanismes de gestion de l‟anonymat des participants,

2. la relation entre la tâche proposée et la décision choisie.


105

La base des cas : lorsqu‟une tâche à résoudre est proposée par le facilitateur, le

système doit alors chercher d‟abord dans une base de cas un cas similaire. Si le cas

similaire existe cela voudrait dire que la tâche à résoudre admet déjà une solution. Dans

ce cas, le GDSS peut ne pas être sollicité. Si aucun cas similaire n‟est présent dans la

base des cas, cela voudrait dire que la tâche à résoudre nécessiterait le GDSS pour sa

résolution. Lorsque cette tâche est résolue, elle doit intégrer la base de cas afin de

l‟enrichir, former ainsi l‟historique des tâches résolues et capitaliser ainsi le savoir de

l‟organisation.

La recherche d‟un cas similaire dans la base des cas suppose :

L‟enrichissement de la base des cas progressivement au fur et à mesure de

l‟exploitation du système.

L‟existence d‟un mécanisme de recherche d‟information et de détection de cas

similaires.

4.3.4 Les diagrammes de comportement

Afin de formaliser la coordination dans les comportements des différents agents, nous

avons adopté le diagramme d‟activité d‟UML. Les diagrammes de comportement sont

présentés en annexe 1.

4.4 Modélisation du SIAD coopératif à base d’agents

Notre approche de modélisation se fonde sur l‟application des systèmes multi-agents

hybrides pour proposer un modèle d‟un système informatique d‟aide à la décision (SIAD)

coopératif :

Hybride, car l‟architecture du SIAD proposée n‟est pas formée d‟un seul SMA,

mais elle s‟articule autour de deux SMA : l‟un réactif (formé seulement d‟agents

réactifs) et l‟autre cognitif.

Coopératif : car la prise de décision est assurée par la coopération du décideur

(utilisateur) et de la machine.

4.4.1 Spécification du SIAD coopératif

4.4.1.1 Architecture

Nous considérons les SIAD coopératifs tels qu‟ils sont définis dans [ADLA 07] et

l‟architecture à base de modèles qui y est proposée (voir figure 4.15). Ces derniers

doivent supporter la coopération décideur/machine et assurer une coopération avec le

décideur qui doit toujours être prioritaire relativement à la machine. En effet, le processus

de prise de décision repose sur le savoir faire et les compétences du décideur. Le système

tout en étant capable de faire le choix d‟une stratégie de décision et parfois même de sa

mise en œuvre, doit permettre au décideur d‟intervenir à tout moment afin de modifier les

caractéristiques du processus de prise de décision.


106

Trois modèles, tous nécessaires à la conception d‟un SIAD, compose l‟architecture : un

modèle de l‟application (MCA), un modèle de la coopération (MCC) et un modèle des

utilisateurs (MCU). Le MCA représente la connaissance du système sur le domaine

d‟expertise et s‟articule autour de trois bases : base de données (BDD), base de modèles

(BM) et base de connaissances (BC). Le MCC décrit comment la coopération s‟effectue

entre les différents agents (système/utilisateur) tandis que le MCU spécifie les profiles

utilisateurs (connaissances, buts, etc. que le système possède sur les utilisateurs).

4.4.1.2 Fonctionnement

Suivant le paradigme tâche-méthodes [WILL 94], le problème à résoudre est modélisé en

une hiérarchie de tâches et de méthodes. Le principe est de décomposer les tâches

complexes en sous tâches. A chaque sous-tâche, au moins une méthode est associée pour

la réaliser. Une tâche associe à un ensemble d‟entrées, paramètres manipulés par la tâche,

un ensemble de méthodes. Une décomposition récursive en sous-tâches de plus en plus

élémentaires avec l‟ordre de leur exécution, conduit à un enchaînement de méthodes,

dont l‟exécution mène à la résolution du problème correspondant.

Une tâche est définie par les composants suivants :

Nom : le nom de la tâche.

Par : la liste de paramètres manipulées par la tâche.

Objectif : le but de la tâche.

Méthodes : la liste des méthodes réalisant la tâche.

Une méthode décrit une manière de réaliser une tâche. Elle est définie par une association

entre un ensemble d‟entrées (la tâche réalisée par la méthode) et un ensemble de sorties

(résultats ou effets produits ou déduits par l‟application réussie de la méthode). Une

méthode caractérise un mécanisme ou un savoir faire qu‟il est possible de mettre en

œuvre pour atteindre un but particulier. Les méthodes peuvent être de deux types :

1- méthodes de décomposition permettant de diminuer la complexité des tâches ;


107

2- méthodes terminales qui expriment le fait que la tâche en entrée est non

décomposable et ne fera pas l‟objet de coopération, elle est donc mono acteur.

Une méthode est définie par les caractéristiques principales suivantes :

Nom : le nom de la méthode

En-tête : la tâche réalisée par la méthode

Contrôle : contrôle de l‟ordre d‟exécution des sous-tâches

Sous-tâche : l‟ensemble des sous-tâches issues de la décomposition. Dans le cas ou la

méthode est terminale, elle n‟a pas de sous tâches. Ce champ est remplacé par la nature

de l‟action qui réalise la tâche.

La décomposition du problème en tâches et sous tâches permet d‟une part de résoudre le

problème à différents niveaux d‟abstraction et d‟autre part de lui associer une stratégie de

résolution. Une telle décomposition présente l‟avantage d‟une gestion efficace du

processus de résolution et l‟établissement d‟une coopération entre le système et

l‟utilisateur lors de l‟exécution du plan d‟actions.

Dans cette perspective, assurer la coopération système/décideur, reviendrait à réaliser une

répartition des tâches entres les deux acteurs. Il arrive parfois qu‟une tâche soit

redondante (elle peut être réalisée par les deux agents), dans ce cas des indications sont

données afin d‟attribuer la tâche à l‟un seulement des deux acteurs ce qui définit le mode

de coopération. La coopération passe par la décomposition du problème à résoudre en un

ensemble de tâches à distribuer entre le système et le décideur. A cet effet, nous

utiliserons la hiérarchie de tâches et de sous-tâches ainsi que les méthodes associées pour

les réaliser [ADLA 07].

4.4.2 Approche Multi-Agents

L‟aide à la décision est un processus complexe, c‟est le cas par exemple de la

maintenance des grands complexes industriels. Cette complexité s‟exprime par le fait que

le nombre de tâches est important. Aussi, les tâches peuvent être décomposables

moyennant plusieurs méthodes. Le nombre de paramètres en entrée est important. Les

paramètres en entrée ne sont pas tous connus. Le décideur introduit les paramètres dont il

dispose, il peut ne pas pouvoir évaluer tous ces paramètres ou bien certains paramètres

nécessiteraient du temps pour leur évaluation. Le problème sujet à une prise de décision

pourrait admettre plusieurs solutions possibles, mais elles ne sont pas toutes valides et/ou

pertinentes. Une solution est non valide si l‟arbre qui la représente contient des feuilles

qui ne constituent pas des tâches terminales. Dans la perspective d‟aborder ces aspects et

présenter des solutions satisfaisantes, nous proposons une approche multi-agents [NACH

09], [ADLA 11], [NACH 11a,11d].

4.4.2.1 Architecture Générale du Système

L‟analyse du SIAD coopératif considéré nous conduit à diviser fonctionnellement le

système en deux sous-systèmes :

3- Le premier est dédié à la recherche d‟un graphe de tâches et sous-tâches

représentant l‟ensemble des solutions possibles au problème posé ;


108

4- Le deuxième est chargé de l‟exécution d‟une solution parmi l‟ensemble des

solutions potentielles de manière coopérative entre le système et le décideur.

Dans notre proposition, nous avons modélisé chaque sous-système fonctionnel (module)

par un système multi-agents.

Pour la conception du premier sous-système, nous avons opté pour un SMA de type

réactif, appelé SMAR, en raison de leurs caractéristiques d‟auto-organisation,

d‟émergence de solutions, de robustesse, d‟adaptabilité et de simplicité de conception des

agents dans la résolution de problème. Aussi, les systèmes auto-organisés sont par

essence même tolérant aux fautes [JAMO 05] et donc particulièrement indiqués lorsque

l‟on recherche pour un problème complexe toutes les solutions possibles. Le SMAR est

composé d‟un ensemble d‟agents (tâches) réactifs ayant des comportements simplistes. Il

a, comme entrée, le problème à résoudre et les différents paramètres et produit le ou les

graphes de tâches et sous tâches en sortie.

Le second système aura pour charge l‟exécution de la solution fournie en sortie du

premier sous-système. Nous proposons de le modéliser par un SMA de type cognitif,

appelé SMAC, en adoptant l‟approche AGR (Agent Groupe Rôle) [GUTK 01].

L‟approche utilisant le modèle AGR organise les agents dans des groupes. Au sein de

chaque groupe, l‟organisation est assurée par des rôles que peuvent jouer les agents. Le

rôle est lié au comportement de l‟agent et sert à contrôler ses interactions au sein du

groupe selon les services qu‟il pourra fournir. De notre point de vue, ces notions de

groupes et de rôles des agents dans les groupes s‟adaptent avec la spécification du

second sous-système considéré dans notre projet. Ainsi, le concept de rôle d‟AGR est

exploité et mis en correspondance avec les rôles des deux acteurs participant dans la

coopération du SIAD.

Ainsi l‟architecture générale à base d‟agents du système d‟aide à la décision coopératif

est constituée d‟un Système Multi-Agents Réactif (appelé SMAR) couplé à un Système

Multi-Agents Cognitif (appelé SMAC). La figure 4.16 illustre l‟architecture de notre

système.


109

Un graphe de tâches et de sous tâches est une possible solution au problème à résoudre.

Comme les agents n‟ont ni connaissances ni compétences pour analyser les différentes

solutions, un agent „observateur‟ est introduit afin d‟analyser l‟ensemble des solutions et

de choisir (ou bien de participer dans le choix) une solution pertinente parmi les solutions

valides. Il cherchera aussi la (ou les) meilleure(s) solutions. Une seule de ces solutions est

fournie au SMAC qui l‟exécutera dans un contexte coopératif entre le système et le

décideur. L‟organigramme du processus de résolution du problème d‟aide à la décision

est présenté dans la figure 4.17.

4.4.2.2 Le Système Multi-Agents Réactif (SMAR)

4.4.2.2.1 Architecture du SMAR

L‟architecture du SMAR est illustrée par la figure 4.18.


110

4.4.2.2.1.1 Les agents

Nous considérons un seul type d‟agent les agents tâches décomposables. Ils représentent

les tâches décomposables du graphe tâche-méthode.

Un agent ne connaît que les agents avec lesquels il est lié par des relations de spécificité,

il n‟a pas de vision globale des autres agents du système. Un agent tâche ne peut créer de

liens de spécificité avec d‟autres agents que suite à l‟application d‟une méthode de

décomposition. Lorsqu‟un agent est activé cela signifie qu‟il existe un autre agent tâche

« générique » qui a engendré son activation suite à l‟application d‟une de ses méthodes.

Cette dernière contient l‟agent spécifique parmi ses relations. Par suite, l‟agent tâche

(spécifique) doit chercher parmi ses méthodes celle qu‟il faudra appliquer. Un agent

tâche activé peut avoir plusieurs méthodes candidates. Une méthode candidate est celle

dont les paramètres sont vérifiés. Dans le cas où, pour un agent tâche donné, plusieurs de

ses méthodes sont candidates, le problème en cours de résolution admettrait plusieurs

solutions et l‟agent tâche génèrera un sous graphe tâches/méthodes contenant plusieurs

plans d‟action.

4.4.2.2.1.2 L’environnement

L‟environnement est constitué de deux parties, l‟une pour la perception et l‟autre pour

l‟action. La première partie est constituée d‟un tableau noir où les paramètres sont

représentés par des variables contenant des valeurs quantitatives ou qualitatives. Les

agents sont individuellement sensibles à certains de ces paramètres qui déclenchent leurs

exécutions. La deuxième partie représente l‟environnement d‟action. C‟est dans ce

dernier que les agents agissent individuellement et collectivement pour construire

l‟espace des solutions. Cette partie de l‟environnement est constituée d‟un tableau noir

contenant la matrice M des tâches et les méthodes associées. C‟est dans ce tableau noir

où se déroulera la résolution collective du problème.

4.4.2.2.1.3 Le contrôle

L‟activation des agents au cours du processus de résolution se fait par le biais du

contrôleur du tableau noir. Ce dernier a pour rôle de coordonner les actions des différents

agents et d‟éviter les conflits d‟accès au tableau noir.


111

4.4.2.2.2 Fonctionnement du SMAR

Le fonctionnement du SMAR est constitué des trois étapes suivantes :

1- Introduction du problème : la spécification du problème implique la

désignation d‟une tâche. C‟est la tâche initiale, elle doit être obligatoirement

une tâche décomposable. Pour cette tâche initiale, l‟agent tâche décomposable

correspondant est désigné.

2- Introduction des différents paramètres liés au problème : L‟introduction des

paramètres initialise toutes les tâches concernées par ces paramètres.

3- L‟exécution du SMA : elle démarre à partir de la tâche racine donnée par la

spécification du problème. L‟agent tâche correspondant évalue ses différentes

méthodes, il doit y avoir au moins une méthode applicable. Pour sa (ou ses)

méthode(s) applicable (s) l‟agent va marquer la (ou les) case(s) concernée(s)

dans la matrice ainsi que les cases des tâches qui correspondent à ses sous

tâches. Pour chacune de ses méthodes appliquées, l‟ensemble des sous tâches

issues de cette décomposition est précisé dans l‟ordre de leur exécution. Par

suite, cet agent active les différents agents liés les méthodes appliquées. Cette

activation des agents se fait par interactions inter-agents (agent-agent). Les

agents activés consultent le tableau noir. Chaque agent, correspondant aux

tâches dont les cases ont été marquées dans la matrice, sera activé. Il s‟exécute

et évalue ses différentes méthodes. Pour chacune des méthodes jugées

déclenchables, il met à jour la matrice tableau noir et permet ainsi au

processus de se réitérer.

Le rôle du contrôleur est de coordonner les actions des différents agents lors du

remplissage de la matrice M. Pour cela, il gère la liste (L) des agents qui doivent mettre à

jour la matrice M. Pour éviter les conflits d‟accès à la matrice M, un contrôle

hiérarchique est adopté, et ainsi, nous tirons profit de la formulation structurée du

problème (tâche initiale) par décomposition en sous tâches (sous problèmes). De ce fait,

la priorité est accordée aux agents de niveau supérieur dans la hiérarchie. Cette façon de

faire réduit les conflits entre les agents car à chaque cycle un seul sous-ensemble d‟agents

est pris en compte où la priorité est donnée à celui du premier arrivé dans la liste. La

figure 4.19 présente l‟organigramme de fonctionnement du SMAR. Nous notons que les

détails algorithmiques du remplissage de la matrice M sont présentés au niveau de

l‟annexe 2.


112

4.4.2.3 L’agent observateur

L‟agent observateur a pour rôle d‟exploiter les sorties du SMA réactif. Il doit ainsi

traduire l‟espace des solutions (la matrice M) en un graphe tâches/méthodes. Ce dernier

est un sous graphe du graphe tâches/méthodes global relatif au domaine considéré. Ceci,

permettra à l‟utilisateur de comprendre les résultats du SMAR et il pourra aussi les

comparer avec le graphe global de tâches et de sous tâches. Aussi, cela permettra à

l‟agent observateur de pouvoir analyser les différentes solutions et de les comparer

éventuellement usant des algorithmes de parcours, de calcul de profondeur etc. Le

fonctionnement de l‟agent observateur est détaillé au niveau de l‟annexe 2.

4.4.2.4 Le Système Multi-Agents Cognitif (SMAC)

Le SMAR a pour rôle de produire toutes les solutions possibles au problème posé en

entrée. L‟agent observateur analyse ses solutions et en collaboration avec le décideur une

solution est fournie comme entrée au SMAC. Le SMAC a pour tâche d‟exécuter cette

solution de manière coopérative entre le système et le décideur. Donc, le rôle du SMAC


113

est de partager efficacement les tâches entre le système et l‟utilisateur. La conception du

SMAC est fondée sur le modèle AGR [GUTK 01].

Le Modèle organisationnel Agents /Groupes/Rôles (AGR)

La conception du SMAC est fondée sur le modèle AGR [GUTK 01]. Le modèle

organisationnel AGR (Agent, Groupe, Rôle) [GUTK 04] est l'évolution du modèle

AALAADIN. La figure 4.20 décrit la représentation UML du modèle AGR. Dans ce

modèle, l'organisation s'articule autour des notions d'agent, de groupe et de rôle.

Agent : dans ce modèle, un agent est une entité capable d'agir et de communiquer, qui

peut jouer un ou plusieurs rôles dans un ou plusieurs groupes. Il n'existe aucune

contrainte sur la structure interne de l'agent. L‟agent peut être réactif ou intelligent.

Groupe : le groupe est la notion primitive de regroupement d‟agents. Chaque agent peut

être membre d‟un ou plusieurs groupes. Le groupe est utilisé pour diviser l'organisation

en groupant des agents dont l'activité se rejoint. Deux agents peuvent communiquer

uniquement s'ils appartiennent au même groupe.

Rôle : un rôle est une représentation abstraite d‟une fonction, d‟un service ou d‟une

identification d‟un agent au sein d‟un groupe. Chaque agent peut avoir plusieurs rôles, un

même rôle peut être tenu par plusieurs agents, et les rôles sont locaux aux groupes.

4.4.2.4.1 L’architecture du SMAC

4.4.2.4.1.1 L’environnement

L‟environnement est l‟espace où évoluent les agents. Il est composé des objets passifs

que les agents utilisent pour l‟accomplissement de leurs tâches. Ces objets représentent

les différents modèles et bases de données utilisés par les agents. Ce sont :

1- Les Modèles de Contrôle de la Coopération (MCC) : ils renferment tous les

modèles de coopération qui définissent chacun une stratégie de coopération ;

2- Les Modèles de Conceptuels des Utilisateurs (MCU) : ils représentent les

profils des utilisateurs qui précisent les compétences des décideurs ;

Agent

Rôle Groupe

1..* 1..*

1..*

* * Joue Est membre de

S‟exerce au sein

Figure 4.20 : La représentation UML du modèle AGR [TRAN 08]


114

3- Le Modèle Conceptuel de l‟Application (MCA) : défini autour des trois bases :

Base De Données (BDD), Base de Modèles (BM) et Base de Connaissances

(BC).

4.4.2.4.1.2 L’organisation

Les agents sont organisés selon le modèle AGR. Ainsi, les agents sont organisés dans des

groupes. Au sein de chaque groupe, l‟organisation est assurée par des rôles que peuvent

jouer les agents. Le rôle est lié au comportement de l‟agent et sert à contrôler ses

interactions au sein du groupe selon les services qu‟il pourra fournir. Le SMAC du SIAD

coopératif est composé de 7 rôles répartis en deux groupes (voir figure 4.21). Le critère

de formation du groupe que nous avons utilisé est l‟existence d‟un mécanisme de

communication commun au sein d‟un groupe.

1- Le groupe de coopération

Le premier groupe du modèle AGR est le groupe de coopération, il est composé de 3

agents cognitif: AS (Agent aSsistant), AGP (Agent Gestionnaire de la cooPération) et

APP (Agent aPPlication).

2- Le groupe exécutant

Le deuxième groupe du modèle AGR est le groupe exécutant, il est composé des agents

suivants : l‟APP (Agent aPPlication), l‟AI (Agent de recherche d’Informations), l‟AM

(Agent de recherche de Modèles), et l‟AR (Agent Raisonnement).

4.4.2.4.1.3 Les agents du SMAC

Tous les agents du système sont cognitifs. Chaque agent dispose d‟une base de

connaissances comprenant l‟ensemble des informations et des savoir-faire nécessaires à

la réalisation de sa tâche et à la gestion des interactions avec les autres agents et avec son

environnement. La figure 4.22 illustre l‟architecture générale du SMAC.


115

1- Le groupe de coopération

Le groupe de coopération est composé de 3 agents cognitifs: AS, AGP et APP.

L’agent AS (Agent aSsistant) : est un agent assistant, il assiste l‟utilisateur dans ses

différentes tâches.

L’agent AGP (Agent Gestionnaire de la cooPération) : son but est de gérer la

coopération entre l‟utilisateur et le système dans la résolution du problème de prise de

décision. Il assure toujours le même rôle dans le groupe.

L’agent APP (Agent aPPlication) : il appartient aux deux groupes d‟agents mais avec

des rôles différents. Dans ce premier groupe c‟est le représentant du groupe exécutant. Il

matérialise le savoir faire automatisable de l‟acteur participant. Son rôle est de veiller à

l‟exécution des tâches automatisées c'est-à-dire, celles qui sont affectées aux systèmes.

2- Le groupe exécutant

Le deuxième groupe est le groupe exécutant, il est composé de 4 agents : APP, AI, AM et

AR. Ces agents ont pour rôles :

L’agent APP : l‟Agent aPPlication participe dans ce deuxième groupe avec un autre

rôle, c‟est le coordinateur des actions automatisables. Ces dernières sont classées en trois

catégories (selon l‟approche par les modèles du SIAD considéré Cf. 4.4.1.1 de ce même

chapitre) : 1) les actions de recherche d‟information, 2) les actions de calcul, statistique

etc. et 3) les actions de raisonnement. L‟APP à pour rôle de coordonner entre les trois


116

autres agents présents dans ce groupe afin de résoudre la partie du problème qui lui a été

affectée par l‟AGP. Au sein de ce groupe l‟APP ne change pas de rôle.

L’agent AI : l‟Agent recherche d‟Information est dédié à la recherche d‟information

dans la Base de Données de l‟application.

L’agent AM : l‟Agent recherche de Modèles recherche, identifie et exécute des

modèles. Pour cela il exploite la Base des Modèles de l‟application.

L’agent AR : l‟Agent Raisonnement a pour rôle l‟exploitation de la Base de

Connaissances lors de l‟exécution des tâches de raisonnement.

4.4.2.4.1.4 Fonctionnement et comportement des agents

Nous présentons dans ce qui suit la coordination dans les comportements des différents

agents, puis nous l‟explicitons à l‟aide des diagrammes d‟activités d‟UML. Etant donné

un sous graphe tâches/sous tâches (plan d‟action) délivré par l‟agent observateur en

concertation avec le décideur, ce diagramme spécifie le rôle des différents agents dans

l‟exécution de ce plan.

-1 Comportement des agents du groupe de coopération

L’agent AS : est un Agent aSsistant, il assiste l‟utilisateur dans ses différentes tâches, il

renferme entre autres le modèle de l‟utilisateur de l‟architecture du SIAD coopératif

considéré dans ce travail. Aussi, il :

Gère l‟interface utilisateur selon le profile de l‟utilisateur.

Assiste le décideur lors de l‟identification du problème. Il peut y avoir une ontologie

du domaine qui permettra la traduction d‟une expression informelle du problème en une

description formelle et structurée.

Permet de fixer (selon les choix du décideur) le mode de coopération et par

conséquent les rôles attribués au décideur et au système, et

Lance et initialise l‟agent AGP.

L’agent AGP : c‟est l‟Agent Gestionnaire de la cooPération, il a pour charge de gérer la

coopération entre l‟utilisateur et le système, dans la résolution du problème de prise de

décision. Il assure toujours le même rôle dans le groupe. Il commence par lancer l‟agent

APP. Ce dernier représente le système dans le groupe. L‟agent AGP initialise l‟agent

APP avec le rôle qui lui correspond dans le mode de coopération. Il précise aussi le rôle

de l‟agent AS, en faisant la correspondance entre le rôle joué par l‟acteur « décideur »

dans la coopération homme-machine et celui que doit assurer l‟AS au niveau du groupe

du modèle AGR. Ensuite, l‟AGP lance l‟exécution à partir de la tâche racine de l‟arbre

des tâches et de sous tâches communiqué par l‟agent observateur. Cet arbre de tâches et

de sous tâches représente l‟ensemble des actions que doivent exécuter les agents.

Le problème de prise de décision est décomposé en tâches qu‟il faudra distribuer entre le

système et l‟utilisateur selon les compétences de chacun. Les tâches distribuées ne sont

pas forcément atomiques. En effet, l‟agent APP peut se voir attribuer une tâche dont il a

la compétence de gérer sans pour cela qu‟elle soit atomique. Il reçoit donc la branche de

l‟arbre qu‟il sait exécuter en coordonnant entre les différentes actions automatisables et


117

en gérant la solution partielle du problème. Ceci permet d‟augmenter l‟efficacité du

système en diminuant le nombre de messages envoyés entre l‟AGP et l‟APP. De plus,

cela permet de réduire la complexité du problème puisque la coordination est partagée

entre les deux agents AGP et APP et n‟incombe pas totalement à l‟AGP.

Certaines tâches terminales peuvent être réalisées par les deux agents coopératifs. Dans

ce cas, l‟attribution de ces tâches aux agents artificiels : APP et AS prend en compte le

rôle de chacun des deux agents dans la coopération. Cela veut dire que le mode de

coopération en cours d‟exécution lève l‟ambiguïté sur l‟affectation des tâches aux deux

agents acteurs dans la coopération. Ainsi, les conflits qui pourraient survenir lors de

l‟affectation des tâches aux agents sont résolus par la fonction des rôles que peuvent jouer

les agents coopératifs.

Aussi, lorsqu‟un mode de coopération n‟aboutit pas à la résolution du problème, l‟AGP

propose au décideur un nouveau mode de coopération et une réaffectation de rôles aux

deux agents.

L’agent APP : c‟est l‟Agent aPPlication, il représente le savoir faire automatisable de

l‟acteur participant. L‟APP coopère avec l‟acteur participant pour l‟exécution d‟une tâche

donnée en utilisant un mode de coopération donné. Son rôle est de veiller à l‟exécution

des tâches automatisées. Selon le mode de coopération choisi, l‟APP est initialisé par

l‟AGP avec un rôle adéquat. Lorsque le mode de coopération change, l‟APP change de

rôle et, par conséquent, de compétence et de comportement. L‟APP peut assurer plusieurs

rôles au sein de ce groupe.

L‟AGP gère la coopération entre l‟utilisateur et le système, dans la résolution du

problème de prise de décision. Il démarre l‟exécution de la décision en affectant à chaque

acteur de la coopération la tâche qu‟il lui est destiné. Après exécution de leurs tâches

respectives, les agents APP et AS communiquent les solutions partielles à l‟AGP. Ce

dernier les intègre d‟une façon incrémentale et forme progressivement la solution globale.

Il est le seul agent qui a une vision globale de la solution.

Diagrammes d’activité des agents du groupe de coopération :


118

2- Comportement des agents du groupe exécutant

L‟agent APP a pour rôle d‟assurer le bon déroulement de l‟exécution des tâches

automatisées : 1) en activant l‟agent concerné par la tâche à exécuter, et 2) en assurant la


119

coordination entre les agents AI, AM et AR, tout en contrôlant l‟enchaînement des

différentes actions exécutées, dans le cas où la tâche est décomposable. Le résultat

(solution partielle) est ensuite transmis à l‟AGP par l‟intermédiaire de l‟APP du groupe

de coopération. L‟AGP intègre ensuite cette solution partielle dans la solution globale.

Diagrammes d’activité des agents du groupe exécutant :


120

4.5 Conclusion

Dans ce chapitre, nous avons présenté l‟architecture d‟un système d‟aide à la décision

collaborative. Cette architecture considère l‟aide à la décision à deux niveaux:

Une collaboration entre les membres du groupe (facilitateur et participants) : Nous

avons proposé une modélisation d‟un GDSS distribué par un système multi-agents en

adoptant la méthodologie « Voyelle ». L‟intérêt de cette approche réside dans la

spécialisation des agents pour exécuter des tâches différentes (assistance, coordination,

organisation des alternatives etc.), ainsi que l‟application des protocoles d‟interaction qui

régissent l‟exécution du processus d‟aide à la décision collective. Nous définissons notre

SMA comme étant centré interaction, car les protocoles d‟interaction représentent une

partie prépondérante du système. Aussi, le fait d‟avoir adopté une telle structure

organisationnelle pour les agents permet de consacrer certains agents seulement à la

gestion des protocoles d‟interaction, comme l‟agent ACR (coté facilitateur) et les agents

AC (coté participants). De notre point de vue, cela est d‟un apport considérable, car

l‟ACR est en quelque sorte le gestionnaire de tous les protocoles d‟interaction.

Une coopération homme/machine : Nous avons proposé un modèle d‟architecture d‟un

SIAD coopératif hybride à base d‟agents. La mise en œuvre d‟un SIAD coopératif

décideur-système, où le premier peut à tout moment prendre le contrôle et diriger le

processus de résolution, n‟est pas chose aisée. C‟est dans ce contexte que nous avons

proposé une architecture d‟un SIAD coopératif hybride à base d‟agents. Ce système est

composé de deux systèmes multi-agents. Le premier réactif (appelé SMAR) a pour rôle

de rechercher tous les plans d‟action (solutions) étant donné une spécification d‟un

problème. Le deuxième est cognitif (appelé SMAC) qui a pour rôle d‟assurer une

exécution d‟un plan d‟action dans un cadre coopératif entre le système et la machine.

L‟avantage du SMAR se trouve dans la simplicité du comportement de ses agents réactifs

(tâches). L‟émergence dans ce système consiste en une émergence de structure. C‟est la

structure d‟arbre qui représente un ensemble de solutions possibles au problème posé.

L„avantage de l‟approche proposée par rapport à celle qui consiste à considérer un seul

agent cognitif qui recherche l‟ensemble des solutions (tel un système expert par exemple)

réside dans le fait qu‟au niveau de notre approche les tâches sont indépendantes et

accessibles directement. C'est-à-dire, lorsque le SMAC termine son exécution, si de

nouveaux paramètres apparaissent alors le décideur peut les réintroduire et demander au

SMAC de poursuivre son exécution. Seules les tâches concernées vont mettre à jour la

matrice M et ainsi enrichir l‟espace des solutions. Dans le cas d‟une conception mono-

agent la réexécution de tout le système est obligatoire. Le SMAC est fondé sur le modèle

AGR, son efficacité réside dans la réduction de la complexité du problème puisque la

coordination est partagée entre les deux agents représentants les deux groupes : l‟AGP du

groupe coopératif, et l‟APP du groupe exécutant. Aussi, il en résulte une diminution du

nombre de messages envoyés entre les agents. En outre, le SMAC matérialise les

différents modèles de l‟architecture du SIAD coopératif à base de modèles considérée

précédemment.

CHAPITRE V

APPLICATION

Chapitre V. Application

122

5.1 Présentation de l’application

Nous avons expérimenté notre modèle sur un système de diagnostic de pannes du

système de gestion de la combustion des chaudières au niveau d‟une usine pétrolière

(GLZ).

Le système de gestion de la combustion des chaudières est un système numérique de

contrôle de commande introduit au niveau du complexe GLZ. Il constitue un des

systèmes les plus critiques pour le bon fonctionnement de l‟usine. Le personnel

exploitant se retrouve souvent confronté à des situations qui imposent une réaction

rapide de prise de décision. Lorsqu‟une panne survient, elle peut être signalée

automatiquement par une alarme (grâce au capteur mis en place) ou relevée directement

sur site par l‟opérateur d‟exploitation (cas de défectuosité du capteur où aucune alarme

n‟est déclenchée mais la chaudière ne fonctionne pas). C‟est surtout dans ce dernier

cas, qu‟une aide à la prise de décision est nécessaire.

Traditionnellement, l‟ingénieur d‟exploitation tente de résoudre le problème

localement. Si aucune solution satisfaisante ne peut être atteinte, l‟ingénieur

d‟exploitation prend contact avec d‟autres ingénieurs d‟exploitation de l‟entreprise

mère et, selon les situations, peut même faire appel au technicien de la compagnie

constructeur de la chaudière (généralement située à l‟étranger) et prévoir des

réunions face-à-face dont il assurera l‟animation pour rechercher une solution au

problème. Ce genre de situation condamne l‟usine à un fonctionnement en mode

dégradé (sous-régime) sinon à l‟arrêt en attendant la résolution du problème.

Aux fins de supporter l‟ingénieur d‟exploitation, le système d‟aide à la décision de

groupe distribuée fondé sur une architecture agent, que nous proposons dans cette

contribution, permettraient à l‟ingénieur d‟exploitation de superviser la résolution de

problème et d‟assumer un rôle de (facilitateur) et aux membres du groupe (les

ingénieurs d‟exploitation de l‟entreprise mère, le technicien constructeur) de participer

à la résolution du problème à tout moment, tout en étant géographiquement éloignés.

5.2 Environnement de programmation

Pour l‟implémentation, nous avons utilisé la plateforme JADE (Java Agent

DEvelopment Framework) [BELL 06]. La figure 5.1 présente l‟architecture générale de

l‟application. Chaque machine héberge un conteneur (container). La machine du

facilitateur héberge le conteneur principal (qui contient l‟AMS : Agent Management

System et le DF : Director Facilitator) qui enregistre les autres conteneurs. Les

machines des participants héberge chacune un conteneur. Pour permettre la connexion

des utilisateurs au système, un site Internet doit être réalisé. Ce site doit être hébergé sur

un serveur http. Chaque agent s‟exécute dans un conteneur qui lui fournit son

environnement d‟exécution. Un agent est implémenté par un thread en JAVA selon

l‟API JADE. Il exécute des actions qui représentent son comportement (behavior).


123

Les interactions entre les agents sont effectuées suivant des protocoles d‟interaction.

Chaque protocole étant composé d‟un ensemble de messages. Les messages sont

exprimés dans le langage FIPA-ACL [FIPA 99]. L‟envoi ou la réception d‟un message

par un agent provoque l‟exécution d‟actions qui font partie du comportement de cet

agent. Au sein de la plateforme, les communications se font par la méthode RMI

(Remote Method Invocation) de java entre les machines virtuelles.

Comme l‟application est au stade de prototypage, nous l‟avons réalisé sur un réseau

local. Le facilitateur, au travers de l‟application, peut consulter la base de données des

participants afin de sélectionner un groupe de participants. Ces derniers sont

sélectionnés selon leurs profils relativement à la panne. Le contact se fait d‟abord par

mail ou par téléphone. Un rendez-vous est fixé afin de participer à la réunion de prise

de décision. Lorsque le moment de la réunion arrive, le facilitateur consulte les

participants qui sont connectés à l‟application (voir figure 5.2). Lorsque le nombre des

participants connectés atteint un certain quorum (deux dans notre cas), le processus

d‟aide à la décision de groupe est lancé par le facilitateur.


124

1) Phase de pré-décision :

Le facilitateur invite les participants qui doivent renvoyer la confirmation de

participation (voir figure 5.3). Puis, le facilitateur envoie les paramètres du problème

qui sont l‟agenda ainsi que la tâche à résoudre (voir figure 5.4).

2) Phase de décision :

Une étape de génération des options est lancée. Chacun des participants génère une

ou plusieurs propositions de solutions au problème posé par le facilitateur (voir

figure 5.5). Ces solutions sont ensuite envoyées au facilitateur. Ce dernier les

collecte, puis exécute une étape d‟organisation de ces solutions alternatives (voir

figure 5.6). Cette étape est assurée par l‟agent organisateur qui épure les solutions

alternatives redondantes. Le résultat est ensuite envoyé au facilitateur qui choisit une

méthode d‟évaluation et lance l‟étape d‟évaluation des solutions alternatives.


125

Les participants évaluent les solutions alternatives localement, puis chacun d‟eux

envoie le résultat au facilitateur. A ce moment là, le facilitateur déduit la décision puis

la notifie aux participants. Dans le cas contraire, il redémarre le processus d‟aide à la

décision de groupe ou bien arrête le processus (voir figure 5.7).


126

3) Phase de post décision :

Dans le cas où une décision découle du processus, un rapport de fin de réunion est

établi (voir figure 5.8).

L‟agent sniffer mémorise toutes les interactions entre les agents. Le facilitateur peut

visualiser ces interactions afin de contrôler le déroulement du processus d‟aide à la

décision de groupe. La figure 5.9 illustre une partie des interactions délivrées par cet

agent.


127

5.3 Conclusion

L‟implémentation du système a été réalisée sous la plateforme JADE. Celle-ci permet

la création d‟agents cognitifs et l‟implémentation des systèmes distribués. JADE

favorise aussi le contrôle des protocoles d‟interaction, ce qui permet au facilitateur (ou

bien l‟administrateur du système) de contrôler le bon déroulement des protocoles

d‟interaction grâce à l‟agent sniffer qui visualise l‟enchainement des messages (et les

messages eux même) échangés entre les différents agents du système. Il représente

donc une vérification interactive de la correction des protocoles.

Nous pourrons développer le rapport final de la session de prise de décision afin de

l‟intégrer à une mémoire organisationnelle sous la forme de base de cas. Celle-ci est

constituée de tous les problèmes résolus par le passé (cas) en vue de capitaliser la

connaissance experte et l‟expérience acquise dans l‟organisation. L‟exploitation de la

base de cas servira à rechercher un cas similaire à la tâche proposée pour la résolution

avant de se lancer dans le processus d‟aide à la décision du groupe. Aussi, l‟étape

d‟organisation des solutions alternatives serait plus intéressante si l‟agent organisateur

était doté de plus de connaissances et d‟un comportement plus élaboré afin de détecter

les cas de similarité et redondance ainsi que les cas d‟alternatives contradictoires

générées par les participants.

Conclusion générale

L’objectif de ce travail était de concevoir une architecture d’un système d’aide à la

décision collaboratif à base d’agents. Ce dernier, considère un groupe de décideurs qui

participent à une prise de décision synchrone et collaborative. Néanmoins, il ne fallait

pas négliger l’aide à la décision individuelle. En effet, le décideur qui participe à la prise

de décision collective peut avoir besoin d’une aide individuelle dans la phase de

génération de solutions à proposer dans le cadre collectif. Dans ce contexte, nous avons

proposé deux architectures pour deux systèmes d’aide à la décision à base d’agents :

Le premier considère le niveau collectif où nous avons proposé une architecture

d’un GDSS distribué à base d’agents.

Le deuxième considère le niveau individuel où nous avons proposé une

architecture d’un SIAD coopératif à base d‟agents.

Concernant le premier système, nous avons proposé une architecture d’un GDSS

distribué à base d’agents. En effet, les GDSS sont un moyen automatisé dédié au travail

de groupe avec la particularité de supporter l‟aide à la décision [ADLA 10], [MARA 03]

et [ZARA 05]. Ils trouvent leur intérêt dans les systèmes complexes où la décision ne

doit pas être prise par une seule personne, mais par concertation de plusieurs experts ou

décideurs. De plus, le facteur temps est important dans des situations où des décisions

doivent être prises dans des délais très courts. Relativement aux SIAD, les GDSS sont

déployés dans des situations plus complexes car ils doivent supporter la prise de

décision collective, en plus de la gestion du groupe des participants. Le système, que

nous avons conçu, est un GDSS distribué à base d‟agents. Pour cela, nous avons utilisé

la méthodologie VOYELLE.

L‟architecture du SMA proposée contient deux structures organisationnelles, l‟une du

facilitateur et l‟autre relative à chacun des décideurs impliqués dans la résolution


129

collective. La mise en relation de ces différentes structures est supportée par internet. Le

système multi-agents conçu gère les interactions entre les participants à la réunion

d‟aide à la décision de groupe. L‟implémentation du système a été réalisée sous la

plateforme JADE, puisqu‟elle permet la création d‟agents cognitifs et permet

l‟implémentation des systèmes distribués.

L‟intérêt de l‟approche à base d‟agents dans la conception du GDSS réside dans la

spécialisation des agents pour exécuter des tâches différentes (assistance, coordination,

épuration des alternatives etc.). Ainsi que, dans la structuration des interactions qui

régissent l‟exécution du processus d‟aide à la décision collaborative entre les acteurs en

spécifiant un protocole régissant chaque interaction. De ce fait, nous définissons notre

SMA comme étant orienté interaction, car les protocoles d‟interaction représentent une

partie importante du système.

L‟apport de notre approche réside aussi, dans l‟organisation des connaissances et la

distinction entre les connaissances factuelles (relatives au domaine particulier sur lequel

on applique l‟aide à la décision) des connaissances opératoires (qui prennent en charge

le processus d‟aide à la décision indépendamment du domaine d‟application). De ce fait,

le système que nous développons ne dépend pas d‟un problème particulier. Sa structure

permet sa mise à jour par des données relatives au domaine considéré.

L‟utilisation des plateformes multi-agents permet de visualiser en temps réels les

échanges échangés au sein du SMA. Ces derniers, peuvent être archivés ce qui permet

de disposer d'une mémoire structurée des échanges. Le prototype a été réalisé avec la

plateforme JADE. Il permet de structurer les messages échangés entre les agents et

d‟exécuter ainsi les différents protocoles de communication.

Concernant le SIAD coopératif, nous avons utilisé les systèmes multi-agents pour

modéliser un système interactif d‟aide à la décision coopératif. Ce dernier prend en

charge la coopération de deux agents le décideur (l‟utilisateur) et la machine pour

résoudre un problème de prise de décision. Le but est de tirer profit des capacités du

décideur et de la machine.

La coopération dans les SIAD doit supporter la gestion de stratégies de coopération qui

est construite à base de modes de coopération. Nous avons étudié différentes méthodes

de conception de SMA. L‟idée présentée dans ce travail est la conception du SIAD en

SMA en associant deux SMA l‟un réactif (SMAR) et l‟autre cognitif (SMAC). Le

SMAR prend en charge la production des différents plans d‟action (solutions) possibles

pour la résolution du problème posé, en considérant les différents paramètres relatifs à

ce problème. L‟agent observateur collabore avec le décideur pour choisir le meilleur

plan à présenter en entrée du SMAC. Ce dernier, considère le plan d‟action en entrée et

prend en charge la coopération homme/machine pour résoudre le problème d‟aide à la

décision.

L‟avantage du SMAR réside dans la simplicité du comportement de ses agents réactifs

(les agents tâches). L‟émergence dans ce système consiste en une émergence de

structure. Aussi, le fait de considérer une tâche comme un agent réactif permet le

déclenchement de son exécution indépendamment des autres tâches qui lui sont

hiérarchiquement supérieur dans le graphe tâches/méthodes. Ceci est très utile dans des


130

domaines complexes, comme la maintenance des complexes industriels où les

problèmes sont introduits sous forme de paramètres.

Le SMAC a été conçu à base du modèle AGR, son efficacité réside dans la réduction de

la complexité du problème, puisque la coordination est partagée entre les deux agents

représentant de chaque groupe : l‟AGP du groupe coopératif, et l‟APP du groupe

exécutant. Aussi, il en résulte une diminution du nombre de messages envoyés entre les

agents.

Tout au long de notre présentation, nous avons souligné plusieurs points qui font

émerger des perspectives d‟approfondissement et d‟extension pour le développement

d‟un environnement intégré pour la prise de décision collective, notamment

l‟implémentation de SIAD coopératifs renfermant l‟expertise de chaque décideur,

l‟établissement du rapport final et l‟aide élaborée à l‟organisations des solutions

alternatives.

Dans cette perspective, la plateforme Madkit [Gut, 00] serait un bon moyen pour le faire

puisqu‟elle supporte le modèle AGR et intègre une grande variété d'architectures

d'agents et de modèles de communication. De plus, l‟élaboration du rapport final de

session de décision est d‟une grande utilité afin de l‟utiliser comme base de cas qui

servira à rechercher un cas similaire à la tâche proposée pour la résolution avant de se

lancer dans le processus d‟aide à la décision du groupe. Aussi, l‟étape d‟organisation ou

d‟épuration des alternatives serait plus intéressante si l‟agent organisateur est doté de

plus de connaissances et d‟éventuellement d‟une ontologie du domaine. Aussi, le

comportement de cet agent doit être plus complexe afin de détecter les similitudes, les

redondances ainsi que les cas de contradiction des alternatives. Dans ce dernier cas, un

protocole de négociation pourrait être développé et intégré au niveau du processus

d‟aide à la décision collective. Nous tenons à signaler que le fait d‟avoir prévu pour

chaque décideur deux agents l‟un assistant et l‟autre coordinateur, permet au système de

supporter différents protocoles d‟interaction. En effet, l‟agent assistant a pour tâche

d‟assister le décideur dans la prise de décision. Et, l‟agent coordinateur se chargera de la

gestion des différents protocoles d‟interaction. Dans le système actuel, il se charge de

gérer les interactions du processus d‟aide à la décision collaborative, mais nous

projetons dans les perspectives de ce travail de le doter de capacités supplémentaires

afin de supporter le protocole de négociation en cas de conflit entre les décideurs. Il peut

même gérer des groupes dans le groupe. En effet, lors d‟une aide à la décision de groupe

collaborative, un décideur peut solliciter un autre groupe afin de coopérer ensemble

dans la phase de génération des alternatives.

Par ailleurs, nous pouvons prendre l‟aspect mobilité des agents. En effet, les acteurs

peuvent être dotés d‟agents informationnels qui migrent à travers le web pour chercher

l‟information nécessaire. Aussi, les agents pourront être dotés d‟autonomie. En effet,

dans le système actuel les agents sont organisés de façon à se partager les différentes

tâches dont l‟exécution réalise la fonction globale du système. Mais, ils assurent surtout

le respect des protocoles d‟interaction. Rendre les agents plus autonomes, signifie que

ces derniers peuvent dans le cas idéal remplacer les acteurs et s‟engager dans un

processus d‟aide à la décision collaborative. Pour cela, ils doivent disposer de

connaissances du domaine et de compétences pour assurer le rôle d‟un décideur ou du

facilitateur.

BIBLIOGRAPHIE

Bibliographie

132

[ACKE 05] : Ackermann. F, Franco. LA, Gallupe. B & Parent. M, (2005) GSS for multi-organizational

collaboration: reflections on processand content. Group Decis Negotiation 14(4):307–331

[ADLA 07] : Adla. A, (2007), «Architecture Coopérative pour L‟Aide à la Décision de groupe

Distribuée », Thèse de Doctorat d‟Etat. Université d‟Oran Es-Sénia.

[ADLA 10] : Adla. A, (2010), « Aide à la Facilitation pour une prise de Décision Collective : Proposition

d‟un Modèle et d‟un Outil », Thèse de Doctorat. Université de Toulouse, France.

[ADLA 11] : Adla. A, & Nachet. B, (2011), “Modelling Cooperation DSS with Hybrid Agents”, EWG-

DSS London-2011 Wokshop at Birbeck, Univ.London.

[AGRE 05] : Agres. A, De Vreed. G & Briggs. R, (2005), “A tale of two cities: case studies of group

support systems transition”, Group Decis Negotiation 14(4):267–284.

[AMOS 08] : Amos. T, & Pearse. N, “Pragmatic Research Design: an Illustration of the Use of the Delphi

Technique”, The Electronic Journal of Business Research Methods Volume 6 Issue 2 2008, pp. 95 –

102.

[AUST 62] : citée dans [DEVR 06]

[BAEI 98] : Baeijs. C, (1998), “Fonctionnalité Emergente dans une Société d‟Agents Autonomes“, Thèse

de Doctorat. Université de Grenoble, France.

[BANN 89] : Bannon. L. J, & Schmidt. K, (1989), "CSCW: Four Characters in Search of a Context", 1st

European Conference on Computer Supported Cooperative Work (ECSCW ‟89), London, UK, p.

358-372.

[BEAC 97] : Beach. A, (1997), “Tthe psychology of decision making, people in organisations”, Sage

Publications Inc., California.

[BELL 06] : Bellifemine. F, & all, (2006), “Jade programmer‟s guide”.http ://jade.cselt.it/ doc/

programmersguide.pdf.

[BELM 05] : Belmonte. M. V, & Fernandez. A (2005), « Agent Coordination for Bus Fleet

Management », ACM Symposium on Applied Computing.

[BERG 05] : Bergeron. M, (2005), "Spécification, modélisation et analyse du dialogue entre agents par

l‟intermédiaire des engagements sociaux », mémoire pour l‟obtention du grade de Maître és

sciences, Université de Laval, Canada.

[BOIS 96]: Boissier. O, & Demazeau. Y, (1996), “ Asic: An architecture for social and individual control

and its application to computer vision.”, In John W. Perram and Jean-Pierre Müller, editor,

Distributed Software Agents and Applications, 6th European Workshop on Modelling Autonomous

Agents - MAAMAW ‟94, volume 1069, pages 1–18, Denmark. Springer.

[BOUR 92] : Bouron. T, (1992), “structure de communication et d‟organisation pour la coopération dans

un univers multi-agents”, thèse de doctorat université de paris 6, France.

[BRAT 87] : Bratman. M, (1987), “Intention, plans, and practical reason”. Harvard University Press.

[BRAZ 97] : Brazier. F.M.T, Dinin-kepliczb. M, Jennings. N.R, & Treur. J, (1997), “DESIRE: Modelling

Multi-Agent Systems”, in a Compositional Formal Framework. International Journal of Cooperative

Information Systems, 6(1):64–94.

[BROO 86] : Brooks. A & Rodney. A, (1986) “Rrobust layered control system for a mobile robot”,

IEEE Journal of Robotics and Automation pp. 14–23.

[BUI 86] : Bui. T.X, & Jarke. M, (1986), « Communications Design for Co-oP: A Group Decision

Support System », ACM Trans. Office Information Systems, Vol. 4, N° 2, pp. 81-103.

Bibliographie

133

[CHAI 94] : cité dans [JARR 02].

[CHEN 05] : Chen. M, Liou. Y, Wang. C.W, Fan. Y.W, & Chi. Y.P.J, (1005), “TeamSpirit: Design,

implementation, and evaluation of Web-based group decision support system”. Elsevier B.V.,

Decision Support System.

[CLAY 97] : Clayton. M,J, (1997) “Delphi: a Technique to Harness Expert Opinion for Critical Decision-

Making Tasks in Education”. Educational Psychology, Vol. 17, Issue 4, pp 373-386.

[COLL 98] : Collinot. A, & Drogoul. A, (1998), « La méthode de conception multi-agent CASSIOPEE :

application à la robotique collective ». Revue d‟intelligence artificielle, 12(1):125–147.

[DAVI 86] : Davis. G.B, Olson. M. H, Ajenstat. J, & Peaucelle. J.-L, (1986), “Systèmes d'information

pour le management », Volume 1 et 2, Montréal, édition G. Vermette.

[DEBL 94] : De Blomac. F, ARC/INFO, (1994), "Concepts et applications en géomatique", Editions

Hermès Sciences, Paris.

[DEMA 90] : cité dans [GUES 02].

[DEMA 95] : Demazeau. Y, 1995, “ From interactions to collective behavior in agent-based systems”. In

European Conference on Cognitive Science, Saint-Malo France.

[DEMA 96]: Demazeau. Y, & Costa. A. R, (1996), “Populations and organisations in open multi-agent

systems”, In 1st Symposium on Parallel and Distributed AI, Hyderabad, India.

[DEMA 01] : Demazeau. Y, (2001), « Voyelles », Mémoire d‟habilitation à diriger des recherches, INP

Grenoble.

[DENN 93] : Dennis. A & Gallupe. R, (1993), “A history of group support systems empirical research:

lessons learnt and future directions”, In: Jessup L, Valacich J (eds) Group support systems – new

perspectives. Macmillan, New York, NY, pp 59–76.

[DENN 96] : Dennis. A, Quek. F & Pootheri. S, (1996), “Using the Internet to implement support for

distributed decision making”, in: P. Humphreys, L. Bannon, A. McCosh, P. Migliarese, J-C.

Pomerol (Eds.), Implementing Systems for Supporting Management Decisions: Concepts, Methods

and Experiences, Chapman & Hall, London, pp. 139– 159.

[DESA 87] : Desanctis. G & Gallupe. B, (1987), “A foundation for the study of group decision support

systems”, management science, vol. 33, no. 5. [DEVR 06] : De Vreede. G, Kolfschoten. G & Briggs. R, (2006), “ThinkLets: a collaboration engineering

pattern language”, Int J ComputApplTechnol 25(2/3):140–154.

[DIEN 04] : Dien. R, Corby. O, Gandon. F, Giboin. A, Golebiowska. J, Matta. N & Ribiere. M, (2004),

"knowneldge Management", Edition Dunod, Paris.

[DROG 93] : Drogoul. A, (1993), « De la simulation multi-agents à la résolution collective de problèmes.

Une étude de l'émergence de structures d'organisation dans les systèmes multi-agents », Thèse de

l'Université Paris 6, France.

[DURF 87] : Durfee. E, & Lesser. V, (1987), «Using Partial Global Plans to Coordinate Distibuted

Problem Solving”, Dans le Proceedings of the 10th IJC AI, pages 875-883, Milan, Italy.

[DURF 89] : cité dans [JARR 02].

[DUVA 01] : Duvallet. C, (2001), « Des systèmes d‟aide à la décision temps réel et distribués:

modélisation par agents », Thèse de doctorat, Université du Havre.

Bibliographie

134

[ELFE 06] : El Fellah Seghrouchni..A, (2006), « Systèmes multi-agents.Dans Encyclopédie de

l‟informatique et des systèmes d‟information », Edition Vuibert Informatique.

[ESPI 97] : Espinasse. B, Picolet. G, & Chouraqui. E, (1997), "Negotiation support systems: a multi-

criteria and multi-agent approach" European Journal of Operational Research Vol 103, pp. 389-409.

[ESPI 09] : Espinasse. B, (2009), « Introduction aux Systèmes Interactifs d‟Aide à la Décision(SIAD) »,

support de cours, l'Université d'Aix-Marseille.

[ESPI 10] : Espinasse. B (2010), « Coordination, coopération et négociation dans les SMA », support de

cours, université d'Aix-Marseille, France.

[FERB 94] : Ferber. J, (1994), “Reactive Multi-Agent Systems: Principles and Applications”. In

Fundamcntals of Distributcd Artificial Intclligcnce, Vol. Nick Scnnings (Ed.), North Holland.

[FERB 95] : Ferber. J, (1995), « Les systèmes multi-agents vers une intelligence collective» InterEditions,

Paris.

[FERB 98] : Ferber. J, & Gutknecht. O, (1998), “Alaadin : a meta-model for the analysis and design of

organizations in mutli-agent systems”, In Y. Demazeau, editor, ICMAS‟98, pages 128–135, Paris.

[FERG 92] : cité dans [JARR 02].

[FERR 98] : Ferrand. N, & Deffuant. G, (1998), « Trois apports potentiels des approches " multi-agents "

pour l‟aide à la décision publique », Colloque Gestion des territoires ruraux - connaissances et

méthodes pour la décision publique, Clermont-Ferrand, France.

[FERR 03] : Ferrand. N, (2003), “Modèles Multi-Agents pour l‟Aide à la Décision et la Négociation en

Aménagement du Territoire”, thèse de doctorat, université Joseph Fourier, France.

[FIKE 71] : Fikes. R, & Nilsson. N, (1971), “ strips: A new approach to the application of theorem

proving to problem solving”. Artificial Intelligence, 2(3/4):189-208.

[FINI 95] : Finin. T, Labrou. Y, & May.J, (1995), “KQML as an agent communication language” in

Computer Science and Electrical Engineering, University of Maryland Baltimore County Baltimore

MD USA.

[FINL 94] : Finlay. P, (1994), “Introducing Decision Support Systems”, Oxford: Blackwell.

[FIPA 99] : (1997), “Foundation for Intelligent Physical Agent. Part 1 : Agent Management ». Version

1.2.

[FOIS 96] : cité dans [JAMO 05].

[FORG 02] : cité dans [ZARA 05]

[FRAN 96] : Franklin. S, & Graesser. A. C, (1996), “Is it an agent, or just a program?: A taxonomy for

autonomous agents”. In conference of the Third International Workshop on Agent Theories,

Architectures and Languages (ATAL‟96), pages 21–35.

[GRAN 98] : Grand. S, & Cliff. D, (1998), “Creatures: Entretainment software agents with artificial life”,

Autonomous Agents and Multi-Agent Systems.1(1).

[GARL 96] : Garlatti. S, (1996), “Tutorial: Multimédia et systèmes d'aide à la décision en situation

complexe”, in 43th meeting of the eurpean working group "Multicriteria Aid for Decisions", Brest.

[GECH 05]: Gechter. F, & Simonin. O, (2005), « Conception de SMA Réactifs pour la Résolution de

Problèmes : une approchebasée sur l‟Environnement », JFSMA‟05. Volume 8, pages 1 à 13.

http://wwwlisc.clermont.cemagref.fr/activite_recherche/projets/Projets_en_cours/MultiAgents/Papiers/ConfGT98.htm

http://wwwlisc.clermont.cemagref.fr/activite_recherche/projets/Projets_en_cours/MultiAgents/Papiers/ConfGT98.htm

Bibliographie

135

[GHOM 08] : Ghomari. A,R, (2008), " Approche Méthodologique d‟Acquisition de Connaissances

Agrégées à base d‟Agents cognitifs coopérants pour les systèmes d‟aide à la décision stratégiques ",

thèse de doctorat d‟état, Ecole nationale Supérieure en Informatique, Alger.

[GLEI 08] : Gleizes. MP, Bernon. C, Migeon. F, & Picard. G, (2008), « Méthodes de développement de

systèmes multi-agents », Génie logiciel N° 86.

[GRAS 89] : Gasser. L, & Huhns. M.N, (1989), « Distributed Artificial Intelligence », Vol. 2, Pitman

Publishing-Morgan Kaufman.

[GRUD 94] : Grudin. J, (1994), « Computer-Supported Cooperative Work: Its history and

participation ». IEEE Computer, Vol. 27, N° 5, pp. 19-26.

[GRUV 03] : Gruver. W.A, Kotak. D.B, & Leeuwen. E.H, Norrie. D.H, (2003), "Holonic manufacturing

systems : Phase 2.Holonic and Multi Agent Systems for Manufacturing", International Conference

on Industrial Applications of Holonic and Multi Agent Systems, HoloMAS, Prague.

[GUES 96] : Guessoum. Z, (1996), “Un environnement de développement de systèmes multi-agents”,

Thèse de doctorat, Université de Paris 6, France.

[GUES 02] : Guessoum. Z, Meurisse. T & Briot. J.P, (2002), « Construction modulaire d'agents et de

systèmes multi-agents adaptatifs en DIMA». Laboratoire d‟informatique de Paris VI (LIP6).

[GUIL 13] : Guillaume. A, (2013),« Une approche multi-agents pour le développement d‟un jeu vidéo »,

Mémoire en vue de l‟obtention du grade de Maître ès sciences, Département d‟informatique et de

recherche opérationnelle, Université de Montréal, Canada.

[GUTK 00a] : Gutknecht. O, Ferber. J, & Michel. F, (2000), « Madkit : Une expérience d'architecture de

plate-forme multi-agents générique », JFIADSMA'OO : 8èmes Journées Francophones

d'Intelligence Artificielle et Systèmes Multi-Agents, France, pp. 223-236.

[GUTK 00b] : Gutknecht. O, & Ferber. J, (2000), “The MADKIT agent platform architecture.”, In

Thomas Wagner and Omer F. Rana, editors, Agents Workshop on Infrastructure for Multi-Agent

Systems, volume 1887 of Lecture Notes in Computer Science, pages 48–55. Springer.

[GUTK 01] : Gutknecht. O, (2001), « Proposition d‟un modèle organisationnel générique de systèmes

multi-agents Examen de ses conséquences formelles, implémentatoires et méthodologiques », Thèse

de doctorat, Université de Montpelier II, France.

[HALP 95] : cité dans [DUVA 01].

[HAYE 88] : Hayes-Roth. F, Erman. L, Fouse. S, Lark. J. S, & Davidson. J, (1988), “ABE: a Cooperative

Operating System and Development Environment.” In Readings in Distributed Artificial

Intelligence, A. Bond et L. Gasser (Ed.), Morgan Kaufman.

[HOLT 89] : Holtzman. S, (1989), “intelligent decision systems reading, Massachusetts”. addison-wesley.

[IGLE 98] : Iglesias. C.A, Garijo. M, Gonzalez. J.C, & Velasco. J.R, (1998), “ Analysis and design of

multiagent systems using MAS-CommonKADS”.

[JAMO 05] : Jamont. J.P, (2005), «DIAMOND: Une approche pour la conception de systèmes multi-

agents embarqués», thèse de doctorat, INP de Grenoble, France.

[JARK 87] : Jarke. M, Jelassi. M.T, &. Shakun. M.F, (1987), « MEDIATOR: Towards a negotiation

support system», European Journal of Operational research, Vol. 31, pp. 314-334.

[JARR 02] : Jarras. I, & Chaib-draa. B, (2002), « Aperçu sur les systèmes multiagents ». Série

scientifique. Centre interuniversitaire de recherche en analyse des organisations. Montréal, Canada.

[JARR 06] : Jarraya. T, (2006), « Réutilisation des protocoles d‟interaction et Démarche orientée modèles

pour le développement multi-agents », université de Reims, France.

Bibliographie

136

[JELA 87] : Jelassi. M. T, & Beauclair. R. A, (1987), "An integrated framework for group decision

support systems design" Information & Management, Vol. 13, pp. 143-153.

[JENN 92] : cité dans [GUES 02].

[JENN 98] : Jennings. N. R., Wooldridge. M, & Sycara. B, (1998), “A roadmap of agent research and

development”. Int Journal of Autonomous Agents and Multi-Agent Systems, 1(1):7- 38.

[KAMO 07] : Kamoun. M.A, (2007), « Conception d‟un système d‟information pour l‟aide au

déplacement multimodal : Une approche multi-agents pour la recherche et la composition des

itinéraires en ligne», thèse de doctorat, UST de Li, France.

[KARA 01] : Karacapilidis. N & Papadias. D (2001) : "Computer supported argumentation and

collaborative decision making: the HERMES system", Information Systems, 26 (4), p. 259-277.

[KEEN 78] : Keen. P, & Scott-Morton. M, (1978), “Decision Support Systems: an organizational

perspective”, Addison-Wesley Publishing.

[KHOU 11] : Khouider. S, (2011), « Outils d‟aide à la décision pour la prise de commandes imprévues »,

thèse de doctorat, université de Paul Verlaine de Metz, France.

[KINN 96] : Kinny. D, Georgeff. M, & Rao.A, (1996), “A Methodology and Modelling Technique for

Systems of BDI agents”, W. Van de VELDE et J. W. PERRAM, éditeurs: Agents Breaking Away :

Proceedings of the Seventh European Workshop on Modelling Autonomous Agents in aMultiAgent

World, volume 1038 de Lecture Notes in Artificial Intelligence (LNAI), pages 51–71. Springer-

Verlag.

[LABO 06] : Laborie. F, (2006) : « Le concept de salle de décision collective et son application aux

processus complexes EADS », Thèse de doctorat, Université Paul Sabatier, Toulouse (France).

[LEBA 03] : Le bars. M, (2003), « Un Simulateur Multi-Agent pour l‟Aide à la Décision d‟un Collectif :

Application à la gestion d‟une Ressource Limitée Agro-environnementale », Thèse de doctorat.

Université Paris IX-Dauphine, France.

[LEVI 89] : Lévine. P, & Pomerol. J, (1989), « Systèmes interactifs d‟aide à la décision et systèmes

experts », Editions Hermès.

[LEWI 07] : Lewis. L, Bajwa. D, Pervan. G, King. V & Munkvold. B, (2007) “A cross-regional

exploration of barriers to the adoption and use of electronic meeting systems”, Group Decision

Negotiation, 16: 381–398.

[LUCK 04] : Luck. M, McBurney. P, & Preist. C, (2004), “A Manifesto for Agent Technology : Towards

Next Generation Computing”, Autonomous Agents and Multi Agent Sytems, 9, 203-252.

[MALO 90] : Malone. T.W, & Crowston. K, (1990), “What is coordination theory and how it can help

design cooperative”, work systems proceedings of the Conferen ce on Computer-Supported

Cooperative Work, Tora Bikson and frank Halasz editors, pp. 357-370.

[MARA 99] : Marakas. G.M, (1999), “Decision Support Systems in the Twenty-first Century”, Prentice-

Hall : Upper Saddle River, NJ.

[MARA 03] : Marakas. G, (2003), “Decision Support Systems In the 21st Century”, Second Edition,

Prentice Hall.

[MEUR 01] : Meurisse. T, & Briot. J.P, (2001), « Une approche à base de composants pour la conception

d‟agents. », TSI vol. 20 n°4, Numéro thématique Réutilisabilité.

Bibliographie

137

[MORA 12] : Mora. M, Forgionne. G, Gupta. J, Cervantes. F & Gelman. O, (2012), "Intelligent Decision-

Making Support Systems. A Strategic Research Agenda", Journal of Decision Systems, vol 14,

pp.179-196.

[MORI 77] : Morin. E, (1977), « La méthode : la nature de la Nature. », Le Seuil.

[MORT 71] : Morton. S, (1971), “ Management Decision Systems : Computer-based Support for Decision

Making”, In MA : Division of Research, Graduate School of Business Administration, Boston :

Harvard, Etats-Unis.

[MRJE 97] : Mrjean. K, (1997), « Emergence et SMA », JFIADSMA, Nice, p. 323-342. France.

[MULL 98] : Muller. J, (1998), « vers une méthodologie de conception de systèmes multi-agents de

résolution de problèmes par émergence », JFIADSMA 98, p. 355-371.

[MULL 00] : Muller. J, (2000), « Modélisation organisationnelle en systèmes multi-agents », Cours :

Septième École d‟été de l‟ARCo , Bonas, 10-21 juillet.

[MULL 02] : Muller. J.P, (2002), « Des systèmes autonomes aux systèmes multi-agents: Interaction,

émergence et systèmes complexes », Rapport présenté pour l‟obtention de l‟Habilitation à Diriger

les Recherches en Informatique, Université Montpellier, France.

[NACH 09] : Nachet. B, & Adla. A, (2009), “Un Modèle Multi-Agents pour l‟Aide à la Décision

Coopérative», 4ème Atelier sur les Systèmes Décisionnels ( ASD‟ 09) 10 -11 novembre à Jijel,

Algérie.

[NACH 11a] : Nachet. B, Sekhri. L, & Adla. A, (2011), « Un Système Intelligent d'Aide à la Décision

Basé sur un Système Multi-Agent Coopératif », ICIST, Tebessa en Algérie.

[NACH 11b] : Nachet. B, Ould Mahraz. A, & Adla. A (2011) : “Multi-Agents Model for Distributed

Group Decision Support Systems”, Proceedings of the EWG-DSS / DASIG Paris, France.

[NACH 11c] : Nachet. B, Adla. A, & Ould Mahraz. A, (2011), « Modélisation d‟un GDSS distribué par un

Système Multi-Agents », Conférence Internationale des Systèmes Complexes (CISC), université de

Jijel en Algérie.

[NACH 11d] : Nachet. B, & Adla. A, (2011), “A Framework for Agent-Enabled Cooperative Intelligent

DSS”, International Transactions on Systems Science and Applications, Vol. 7, No. 1/2, November,

pp. 126-139.

[NACH 13] : Nachet. B & Adla. A, (2013), “An agent based model for group decision support systems”

The Mediterranean Journal of Computers and Networks. Vol 9 N°4, 607-616.

[NACH 14] : Nachet. B & Adla. A, (2014), “An agent-based distributed collaborative decision support

system”, Intelligent Decision Technologies. Vol 8 N°1, 15–34.

[NUNA 97] : Nunamaker. J, Briggs .R, Mittleman. D, Vogel. D, & Balthazard. P, (1997) “Lessons from a

dozen years of group support systems research: a discussion of lab and field findings”, J Manage

InfSyst 13(3):163–207.

[OCCE 98] : Occello. M, & Demazeau. Y, (1998), “Modelling decision making systems using agents for

cooperation in a real time constraints”, In 3rd IFAC Symposium on Intelligent Autonomous

Vehicles, volume 1, pages 51–56, Madrid, Spain.

[PANZ 02] : Panzarasa. P, Jennings. N. R, & Norman. T. J, (2002), "Formalising collaborative decision-

making and practical reasoning in multi-agent systems", Journal of Logic and Computation, 12 (1),

p. 55-117.

[PICA 04a] : Picard. G, (2004), «Etude de l‟émergence comportementale d‟un collectif de robots par auto-

organisation coopérative.», Rapport de DEA, Université Paul Sabatier de Toulouse III.

Bibliographie

138

[PICA 04b] : Picard. G, & Gleizes. M.P, (2004), “ The ADELFE Methodology - Designing adaptive

Cooperative Multi-Agent Systems, volume Methodologies and Software Engineering for Agent

Systems", chapter Chapter 8, pages 157–176. Kluwer.

[PICA 04c] : Picard. G, (2004), « Méthodologie de développement de systèmes Multi-Agents adaptatifs et

conception de logiciels à fonctionnalité émergente. », thèse de doctorat, Université Paul Sabatier de

Toulouse III, France.

[PHAN 04] : Phan. P, (2004), « L‟émergence dans les Systèmes Multi-Agents (SMA). Modéliser et

interpréter l‟émergence avec des SMA : réflexions préliminaires sur l‟identification et la

représentation des phénomènes émergents dans les sciences économiques sociales », Leibniz-imag,

ICI, Université de Bretagne Occidentale & ENST de Bretagne, France.

[POWE 02] : Power. D. J, (2002), « Decision support systems : conepts and resources for managers »,

westprot, Conn, Quorum Books.

[PROB 84] : Probst. A. R, (1984), « Les systèmes d'aide à la décision: rôle, structure et évolution », Revue

Gestion: p. 13-19.

[RODR 94] : Rodriguez. M, (1994), « Modélisation d‟un agent autonome: Approche constructiviste de

l‟architecture de contrôle et de la représentation de connaissances », thèse de doctorat, Université de

Neufchâtel, France.

[ROY 00] : Roy. B, (2000), "Réflexions sur le thème : quête de l‟optimum et aide à la décision", Cahier

du Lamsade n° 167. Université Paris-Dauphine, France.

[SABA 01] : Sabas. A, (2001): « Systèmes Multi-Agents : une analyse comparative des méthodologies de

développement. Vers la convergence des méthodologies de développement et la standardisation des

plateformes SMA », Université des Trois-Rivières, Québec, Canada.

[SCHN 94] : Schneider. D.K, (1994), " Modélisation de la démarche du décideur politique dans la

perspective de l'intelligence artificielle", thèse de l‟université de Genève, Suisse.

[SEGU 08] : SEGUY. A, (2008), « Décision collaborative dans les systèmes distribués : application à la e-

maintenance», thèse de doctorat de l‟université de Toulouse (France).

[SIGA 05] : Sigaud. O, (2005), « Introduction à la modélisation orientée objets avec UML », polycopié,

laboratoire LIP6, université paris 6.

[SIMO 77] : Simon. H. A, (1977), “The new science of management decision”, Prentice Hall, New Jersey,

Etats Unis.

[SOUB 96] : Soubie. J-L, Buratto. F, & Chabaud. C, (1996), « La conception de la coopération et la

coopération dans la conception », [Section] : Coopération et conception, auteur du livre de

Terssac. G, & Friedberg. E, éd. (Eds). - Toulouse : Octarès.

[SPRA 82] : Sprague. R, & Carlson. E, (1982), “Building Effective Decision Support Systems”, Prentice-

Hall, Inc, Englewood Cliffs.

[STEE 89] : Steels. L, (1989), « Cooperation between Distributed Agents through Self-Organisation », in

Decentralized A.I., Elsevier North-Holland, Amsterdam.

[TRAN 08] : Tranier. J, (2008), « Vers une vision intégrale des systèmes multi-agents : Contribution à

l‟intégration des concepts d‟agent, d‟environnement, d‟organisation et d‟institution », thèse de

doctorat, université de Montpellier II, France.

[TURB 93] : Turban. E, (1993), "Decision Support and Expert Systems", Macmillan Publishing

Company.

Bibliographie

139

[TURB 95] : Turban. E, (1995), “Decision Support and Expert Systems”, Macmillan, New York (USA).

[TURB 98] : Turban. E, & Aronson. J.E, (1998), “decision support systems and intelligent systems”,

prentice-hall international inc., London.

[URBA 07] : Urbani. D, (2007), « Elaboration d'une approche hybride SMA-SIG pour la définition d'un

système d'aide à la décision; application à la gestion de l'eau », université de corse Pasquale Paoli,

France.

[VERC 00] : Vercouter. L, (2000), « Conception et mise en œuvre de systèmes multi-agents ouverts et

distribués », Thèse de doctorat, Université de Jean Monnet et Ecole des Mines de Saint-Etienne,

France.

[VOLL 04] : Volle. M, (2004) "Fonctionnement d‟un Système Informatique d‟Aide à la Décision

(SIAD)", Revue des Nouvelles Technologies de l‟Information (RNTI-E-2), Extraction et Gestion

des Connaissances, Cépadues Editions, Paris, France.

[WAGN 93] : Wagner. G, Wynne .B & Mennecke .B, (1993), “ group support systems facilities and

software”, In: Jessup LM, Valacich JS (eds) Group support systems: new perspectives. Macmillan,

New York, NY, pp 8–55.

[WAND 04] : Wanda. L & Tena. B, (2004), "The DELPHI technique : a research strategy for career and

technical education", Journal of Career and Technical Education, Vol. 20, No. 2, Spring, 55-67.

[WEIS 99] : Weiss. G, (1999), “Multiagent systems and distributed artificial intelligence”, In Weiss,

G.,editor, Multiagent systems : A modern approach to Distributed Artificial Intelligence. MIT

Press.

[WILL 94] : Willamoski. J, (1994), « Modélisation de tâches pour la résolution de problèmes en

coopération système-utilisateur », Thèse de l‟université Joseph Fourier - Grenoble 1, France.

[WOOL 99] : Wooldridge. M, (1999), “Intelligent agents. InWeiss, G., editor, Multiagent systems : A

modern approach to Distributed Artificial Intelligence”, MIT Press.

[WOOL 00] : Woolddridge. M, Jennings. N.R, & Kinny. D, (2000), “The Gaia methodology for agent-

oriented analysis and design.”, Journal of Autonomous Agents and Multi-Agent Systems, Vol. 3.

[ZARA 05] : Zaraté. P, (2005), « Des Systèmes Interactifs d‟Aide à la Décision Aux Systèmes Coopératifs

d‟Aide à la Décision : Contributions conceptuelles et fonctionnelles». Habilitation à Diriger des

Recherches, institut national polytechnique de Toulouse, France.

ANNEXES

Annexe1

141

Annexe 1

Les diagrammes de comportements des agents du GDSS

1 La phase de pré-décision

1.1 Diagramme de comportements de l’activité « Proposition du groupe des

participants »

Le facilitateur assisté par son agent assistant AF sélectionne parmi les utilisateurs inscrits ceux

dont le profil correspond à la catégorie de la tâche proposée à la résolution.

1.2 Diagramme de comportements de l’activité « Contact du groupe de participants »

Annexe1

142

Le facilitateur contacte le groupe de participants sélectionné. Chaque participant doit se

connecter et donner son accord pour la participation.

1.3 Diagramme de comportements de l’activité « Planification de l’agenda et définition

des ressources »

Avant de lancer le processus d‟aide à la décision collaborative, le facilitateur doit établir un

agenda de la réunion. L‟agenda définit les phases et les méthodes qui organisent les activités du

groupe formé par les participants potentiels.

Pour assister le facilitateur dans cette tâche, les problèmes (ou tâches à résoudre) sont

catégorisés. A chaque catégorie de tâche correspond un agenda (les activités du groupe). Dans

le cas où la tâche à résoudre ne se trouve pas dans la base déjà établie, l‟agenda est précisé par

le facilitateur.

Annexe1

143

2 La phase de décision

2.1 Diagramme de comportements de l’activité « Génération des alternatives »

Le facilitateur supervise les activités des participants à la résolution d‟un problème. Au niveau

de cette phase, chaque participant peut être assisté par son système coopératif d‟aide à la

décision. Les décideurs envoient ensuite leurs solutions au facilitateur en vue de les organiser.

Annexe1

144

2.2 Diagramme de comportements de l’activité « Organisation des alternatives »

Une fois que tous les participants ont répondu, une phase d‟organisation des alternatives

démarre. L‟organisation des solutions se fait par l‟agent AOR qui a les compétences et les

connaissances pour cela. L'organisation d'idée est considérée comme un processus convergent

parce qu'elle combine des idées dans des catégories, ayant pour résultat une liste plus courte ou

moins diverse. Pour cela, l‟agent AOR doit avoir les moyens de développer des stratégies

d‟organisation, ainsi que des moyens pour catégoriser les solutions. Une fois les alternatives

organisées par l‟AOR, le facilitateur doit confirmer ou bien modifier l‟organisation.

Annexe1

145

2.3 Diagramme de comportements de l’activité « Evaluation des alternatives »

Le facilitateur sélectionne une méthode, parmi celles retenues dans l‟agenda, elle s‟applique sur

toute la liste des solutions proposées. Les participants reçoivent une nouvelle liste de solutions

proposées plus organisée et moins diverse, et doivent évaluer chaque solution en utilisant la

méthode d‟évaluation sélectionnée par le facilitateur.

Annexe1

146

2.4 Diagramme de comportements de l’activité « Le choix »

Suite à l‟étape évaluation des alternatives, une solution est retenue. C‟est la décision du groupe

qui doit être notifiée aux participants.

Annexe1

147

3 Phase de post décision

3.1 Diagramme de comportements de l’activité « Présentation de la solution et

discussion »

Après avoir sélectionné la solution finale par le facilitateur, cette étape présente aux participants

la solution qui a été choisie par le groupe pour le problème posé par le facilitateur au début de

la réunion. La discussion peut amener à une compréhension plus profonde du problème.

Annexe1

148

3.2 Diagramme de comportements de l’activité « Le rapport de clôture »

Le rapport est un moyen de sauvegarde qui enregistre le déroulement de la réunion et les

informations rassemblées pendant chaque étape du meeting comme l‟agenda, la génération des

idées avec les commentaires, l‟organisation des idées, l‟évaluation et le choix de le solution

finale avec l‟analyse et la discussion effectuée pendant le meeting. Le rapport sera une

référence et un document pour les personnes qui veulent consulter le déroulement de la réunion,

les différentes idées proposées, le mode d‟évaluation choisi, les conflits entre les participants

ainsi que leurs analyses et commentaires.

A la fin, le facilitateur peut terminer le processus de décision en clôturant le meeting. Comme il

peut aussi passer à une autre résolution tâche en relançant le processus d‟aide à la décision de

groupe.

Annexe1

149

Annexe 2

150

Annexe 2

1 Processus de remplissage de la matrice M (initialisation)

Une matrice M[m,n] est considérée tel que :

- m est le nombre de tâches décomposables et non décomposables,

- n est le nombre de toutes les méthodes,

- i est l'indice des tâches (i:= 1 à m) et j est l'indice des méthodes (j:= 1à n).

1- Initialisation de la matrice: Tous les éléments de la matrice sont initialisés à -1.

2- Mise à jour de la matrice: La tâche initiale, qui correspond au problème à

résoudre, désignée en entrée implique l'activation de l'agent Ti lui correspondant.

Ce dernier évalue ses méthodes dont une au moins est déclenchable. Pour les

méthodes déclenchables, l'agent Ti met à jour la matrice comme suit:

M[i,x] 0; x { mt } ensemble des méthodes déclenchables de l'agent

Ti.

Pour toute méthode déclenchable (mt) de l'agent Ti, il lui correspond une

colonne x: M[y,x] ordre; y { sa } ensemble des sous tâches activées

de l'agent Ti.

ordre est le rang de la tâche lors de l'exécution de la méthode.

Pour chaque sous tâche marquée, représentée par une ligne marquée d'au moins un rang,

il lui correspond un agent à activer. L'activation de ce dernier par l‟agent Ti déclenche

son exécution. Le résultat est l'ensemble des méthodes déclenchables avec les sous

tâches correspondantes. Après avoir terminé son exécution, l'agent s'inscrit dans une

liste d'attente (L) pour attendre son tour afin de mettre à jour de la matrice.

Lorsque la liste L devient vide, cela voudrait dire que le SMAR a convergé et que la

résolution du problème est terminée. La matrice M renferme à ce moment là l‟ensemble

des solutions possibles au problème donné en entrée.

Dans ce cas, ce n'est pas une réorganisation des agents qui émerge suite à l'exécution du

SMAR puisque les agents ne se réorganisent pas, les liens entre eux ne changent pas et

la relation de "méthode" qui lie chaque agent tâche décomposable avec les agents

"tâche" qui le décompose reste stable. Mais, les agents réactifs participent plutôt

ensemble à la construction de l'espace des solutions (la matrice M). Donc, c'est cet

espace de solutions qui émerge suite à l'activité du SMA réactif relativement à un

problème posé.

L‟analyse de ces résultats se fera par l‟agent observateur. Ce dernier doit d‟abord

traduire l‟espace des solutions sous forme d‟un arbre de tâches et de sous tâches. Ceci,

Annexe 2

151

permettra à l‟utilisateur de comprendre les résultats du SMAR et il pourra aussi les

comparer avec le graphe global de tâches et de sous tâches. Aussi, cela permettra à

l‟agent observateur de pouvoir analyser les différentes solutions et de les comparer

éventuellement usant des algorithmes de parcours, de calcul de profondeur etc.

Afin d'optimiser le traitement de création de l'espace des solutions, nous avons constitué

deux matrices: la matrice Tâche T et la matrice Méthode MT. Ces deux matrices sont

crées et remplies au moment du remplissage de la matrice M :

1- La matrice T de dimension (k, 2) (k étant le nombre de tâches marquées de la

matrice M). Un élément T[i, 1] représente l'identifiant d'une tâche marquée dans

M et T[i, 2] représente le nombre de méthodes déclenchables de cette même

tâche.

2- La matrice MT de dimension (h, 2) (h étant le nombre total des méthodes

déclenchables représentées dans la matrice M). Un élément MT[j,1] représente

l'identifiant d'une méthode déclenchable et MT[j, 2] représente le nombre de

sous tâches obtenues par application de cette méthode.

2 Fonctionnement de l’agent observateur

2.1 Processus de construction du graphe tâches/méthodes

La construction du graphe de tâches/méthodes est réalisée par la création dynamique et

progressive des différents maillons jusqu'à ce que toutes les tâches marquées dans M

soient créées en tant que maillons. L'espace des solutions est un arbre dont les nœuds

modélisent des maillons du type : ID : (Identifiant du nœud), F : pointeur vers le

premier maillon fils, S : pointeur vers le maillon frère suivant. Le processus de

construction de l‟espace des solutions est:

La tâche initiale (problème posé) représente le point d'entrée à la matrice M à partir

duquel commence le processus de création de l'espace des solutions :

1- Le maillon racine (ID, F, Nil) : ID : identifiant de la tâche racine, F : pointeur

vers la première méthode candidate appliquée par cette tâche et Nil est la valeur

du deuxième pointeur (nœud frère) car la tâche racine n‟a pas de tâche de même

profondeur ;

2- Les maillons correspondants aux méthodes candidates de la tâche initiale: Le

(les) maillon(s) (ID, F, S) : ID : identifiant de la méthode appliquée, F : pointeur

vers le maillon de la première sous tâche et S : pointeur vers le maillon de la

méthode suivante s‟il existe d‟autres méthodes à appliquer ;

3- Les maillons correspondants aux sous tâches : Le (les) maillon(s) (ID, F, S) :

ID : identifiant de la tâche qui est la sous-tâche relative à la méthode qui l‟a

activée, F : pointeur vers le maillon qui contient la première méthode appliquée

par cette tâche et S : pointeur vers le maillon de la sous-tâche suivante dans

l‟ordre de la décomposition.

Pour chaque sous tâche marquées au niveau de la matrice M, le processus sus-décrit est

réitéré. Le processus s'arrête lorsque toutes les tâches marquées sont traitées.

Annexe 2

152

2.2 Processus d’analyse du graphe tâches/sous tâches

Le processus d‟analyse est le suivant :

1- Parcourir l‟espace à partir de la tâche d‟entrée ou la tâche racine (c‟est la

première tâche décomposable qui a servie à la spécification du problème) ;

2- Epurer l‟ensemble des solutions : supprimer de l‟espace des solutions celles qui

n‟aboutissent pas. Ces dernières sont les arbres de tâches/méthodes dont les

feuilles ne sont pas toutes des tâches terminales ;

3- Parmi les solutions valides, choisir « une bonne solution ». Pour ce faire, les

critères de choix doivent être définis : Cela peut être la solution la plus rapide

(en termes de temps), la solution avec le moins de tâches etc. Aussi, les

différentes solutions peuvent présenter des méthodes qui sont “déclenchables”

mais pas pertinentes car pas assez bien adaptées au problème. Pour cela, le

rôle du décideur est primordial dans le choix de la meilleure solution.

2.3 Création du graphe tâches/méthodes

Création du maillon correspondant à la tâche racine

La tâche initiale est mémorisé, son identifiant est ID=IDti.

1- Parcourir la matrice M pour localiser la ligne i/ i=IDti, ainsi que l‟élément

M(IDti,j)=0. L‟indice j correspond à l‟identifiant d‟une méthode (IDm)

déclenchable par la tâche IDti ;

2- Accéder à la matrice T et rechercher T[IDti,1], puis consulter T[IDti,2].

T[IDti,2]=n est le nombre de méthodes déclenchables (mentionnées dans M par

la valeur 0) ;

3- Créer le maillon de la tâche racine.

Création des autres maillons du graphe tâches/méthodes

Pour i:=1 à n faire (pour chaque méthode)

1- Créer le maillon de la méthode (ID,F,S) tel que: ID=IDm (F=adresse de la

première sous tâche, S= nil).

2- Accéder à la matrice M et rechercher M[IDm,1] (/IDm est l'identifiant de la

méthode), puis consulter M[IDm,2]. T[IDm,2]=nt est le nombre de sous tâche de

cette méthode.

3- Pour y:= 1 à nt faire (pour chaque sous tâche)

- Localiser dans l'ordre les tâches de la méthode en cours. L'ordre est

mentionné au niveau de M.

- Créer le maillon de la sous tâche en cours: (ID,F,S) tel que: ID=

identifiant de la sous tâche (on le reconnait à partie de M) (F= nil (car pas

encore d'adresse des méthodes déclenchables de cette sous tâche, S=

pointe vers le maillon suivant ou bien nil si c'est la dernière sous tâche.

Finfaire

Annexe 2

153

- aussi, on réalise le lien entre le maillon de la méthode avec la première

sous tâche créée.

Finfaire

A la fin de l‟exécution, l‟espace des solutions est traduit sous forme d‟un arbre qui

contient l‟ensemble des sous arbres tel que chacun d‟eux représente une solution au

problème posé. Cet espace renferme toutes les solutions possibles au problème à

résoudre. Toute solution est une structure d‟arbre tel que les profondeurs paires sont les

tâches et les profondeurs impaires sont les méthodes. Il reste à les parcourir et à les

valider.

2.4 Exemple

Le graphe tâches/méthodes

Nous avons pris comme exemple le graphe tâches/méthodes suivant :

Annexe 2

154

L'état de la matrice M après exécution de tous les agents réactifs activés:

M1 M2 M3 M4 M5 M6

T1 0 0 -1 -1 -1 -1

T2 1 -1 -1 0 -1 -1

T3 2 1 -1 -1 0 -1

T4 3 -1 -1 -1 -1 -1

T5 -1 2 -1 -1 -1 -1

T6 -1 -1 -1 -1 -1 -1

T7 -1 -1 -1 -1 -1 -1

T8 -1 -1 -1 1 1 -1

T9 -1 -1 -1 2 2 -1

T10 -1 -1 -1 -1 3 -1

T11 -1 -1 -1 -1 -1 -1

T12 -1 -1 -1 -1 -1 -1

Les deux matrices T et MT après exécution de tous les agents réactifs activés:

La matrice T des tâches

avec le nombre de

méthodes déclenchables

pour chaque tâche.

La matrice MT des

Méthodes avec Le nombre

de sous tâches pour chaque

méthode.

Tâches

(ID)

Nbre de

méthodes

Méthodes

(ID)

Nbre de

sous

tâches

1 2 1 3

2 1 2 2

3 1 4 2

4 0 5 3

5 0

8 0

9 0

10 0

L'espace des solutions construit par l‟agent observateur :

Annexe 2

155

Thème de thèse: Modèles multi agents pour la prise de décision … · 2015-05-05 · Nowadays...

Documents

Transcript of Thème de thèse: Modèles multi agents pour la prise de décision … · 2015-05-05 · Nowadays...