Post on 19-Mar-2020
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
Introduction générale
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.
Introduction générale
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
Introduction générale
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.
Introduction générale
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.
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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]
Chapitre I. Aide à la Décision
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.
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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/
Chapitre I. Aide à la Décision
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.
Chapitre I. Aide à la Décision
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]
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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] :
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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.
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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.
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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.
Chapitre I. Aide à la Décision
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.
Chapitre I. Aide à la Décision
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 :
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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
Chapitre I. Aide à la Décision
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
Chapitre II. Les Systèmes Multi-Agents
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 ».
Chapitre II. Les Systèmes Multi-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.
Chapitre II. Les Systèmes Multi-Agents
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
Chapitre II. Les Systèmes Multi-Agents
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.
Chapitre II. Les Systèmes Multi-Agents
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].
Chapitre II. Les Systèmes Multi-Agents
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.
Chapitre II. Les Systèmes Multi-Agents
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
Chapitre II. Les Systèmes Multi-Agents
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.
Chapitre II. Les Systèmes Multi-Agents
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 ;
Chapitre II. Les Systèmes Multi-Agents
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] :
Chapitre II. Les Systèmes Multi-Agents
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
Chapitre II. Les Systèmes Multi-Agents
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].
Chapitre II. Les Systèmes Multi-Agents
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.
Chapitre II. Les Systèmes Multi-Agents
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.
Chapitre II. Les Systèmes Multi-Agents
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
Chapitre II. Les Systèmes Multi-Agents
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».
Chapitre II. Les Systèmes Multi-Agents
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
Chapitre II. Les Systèmes Multi-Agents
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
Chapitre II. Les Systèmes Multi-Agents
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 :
Chapitre II. Les Systèmes Multi-Agents
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.
Chapitre II. Les Systèmes Multi-Agents
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.
Chapitre II. Les Systèmes Multi-Agents
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/
Chapitre II. Les Systèmes Multi-Agents
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.
Chapitre II. Les Systèmes Multi-Agents
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
Chapitre II. Les Systèmes Multi-Agents
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/
Chapitre II. Les Systèmes Multi-Agents
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/
Chapitre II. Les Systèmes Multi-Agents
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
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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.
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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.
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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.
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-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
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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.
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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".
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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.
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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 ;
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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
Chapitre III. Aide à la Décision Collaborative et les Systèmes Multi-Agents
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).
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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 Homme/Agent
Interaction Agent/Agent
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Interaction Homme/Agent
Interaction Agent/Agent
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
Interaction Homme/Agent
Interaction Agent/Agent
AC AD Participant
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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 Homme/Agent
Interaction Agent/Agent 4
Interaction Homme/Agent
Interaction Agent/Agent
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
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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 ;
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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 ;
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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é ;
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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]
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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.
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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 :
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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 :
Chapitre IV. Proposition d‟une architecture d‟un système d‟aide à la décision collaborative
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).
Chapitre V. Application
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.
Chapitre V. Application
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.
Chapitre V. Application
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).
Chapitre V. Application
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.
Chapitre V. Application
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
Conclusion générale
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
Conclusion générale
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.
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