REALISATION D’UN WEB-DSS A BASE D’AGENTS …theses.univ-oran1.dz/document/TH3236.pdfMr ABDI Mustapha Kamel Maître de Conférence à l’Université d’Oran (Président) Mr BOUAMRANE

FACULTE DES SCIENCES DEPARTEMENT D’INFORMATIQUE

MEMOIRE

Présenté par : Melle BESSEDIK IMENE

Pour obtenir

LE DIPLOME DE MAGISTER

Spécialité : Informatique Option : Informatique et Automatique

Intitulé :

REALISATION D’UN WEB-DSS A BASE D’AGENTS POUR

LA GESTION DE PRODUCTION DYNAMIQUE

Soutenu le : / / Devant le jury composé de : Mr ABDI Mustapha Kamel Maître de Conférence à l’Université d’Oran (Président) Mr BOUAMRANE Karim Maître de Conférence à l’Université d’Oran (Encadreur) Mme TAGHEZOUT Noria Maître de Conférence à l’Université d’Oran (Co-encadreur) Melle BOURENANE Malika Maître de Conférence à l’Université d’Oran (Examinatrice) Mr EL BERRICHI Zakaria Maître de Conférence à l’Université de Sidi Bel Abbès (Examinateur)

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE MINISTERE DE L’ENSEIGNEMENT SUPERIEUR DE LA

RECHERCHE SCIENTIFIQUE UNIVERSITE D’ORAN

Remerciements

Merci Allah, Le Tout Puissant.

Je tiens à exprimer ma profonde reconnaissance à Monsieur BOUAMRANE Karim, Maître de Conférence à l’Université d’Oran, qui a encadré mon travail pour l’obtention du diplôme de magister, pour sa disponibilité, pour l’aide et les conseils qu’il m’a prodigués et pour la confiance qu’il m’a témoignée tout au long de sa réalisation.

Je tiens à exprimer ma sincère double gratitude à Madame TAGHEZOUT Noria, Maître de Conférence à l’Université d’Oran, pour ses conseils, son aide précieuse et ses remarques qui ont permis d’améliorer la qualité de ce document.

Je remercie vivement Monsieur ABDI Mustapha Kamel, Maître de Conférence à l’Université d’Oran, de me faire l’honneur de présider le jury de ce mémoire.

J’adresse mes remerciements à Mademoiselle BOURENANE Malika, Maître de Conférence à l’Université d’Oran, d’avoir accepté de prendre connaissance de ce travail et pour avoir bien voulu consacrer de leur temps à l’évaluer et à siéger à cette soutenance.

Un grand merci à Monsieur EL BERRICHI Zakaria, Maître de Conférence à l’Université « Djilali el yabès » de Sidi Bel Abbès, de m’avoir fait l’honneur d’être membre de jury de ce mémoire et de l’intérêt qu’il a porté à ce travail.

Je remercie enfin tous ceux qui m’ont encouragé et soutenu par leur amitié.

Je dédie le fruit de mon travail A ma mère, mes sœurs et mon frère,

A ma grand-mère, une pensée toute particulière ainsi que mes oncles A ma tante « Nouria », son mari et ses enfants,

A mon irremplaçable père qui nous a subitement quitté, laissant derrière lui un grand vide difficile à combler.

A ma très chère et regrettée tante qui était ma protection et mon pilier. A tous mes collègues de travail et amies.

Table des matières

1 Intoduction générale .............................................................................. 01

1 Introduction ................................................................................................................. 04 2 Définition de la fonction Gestion de Production ......................................................... 04 3 Objectifs de la Gestion de Production ......................................................................... 06 4 Typologie des Systèmes Productifs ............................................................................. 06

4.1 Typologie en fonction de l’organisation du flux de production ........................... 06 4.1.1. La production unitaire ....................................................................................... 07 4.1.2. La production en série ....................................................................................... 07 4.1.3. La production continue ...................................................................................... 07

4.2 Typologie en fonction de la politique de fabrication ............................................ 08 4.2.1. Production à la commande ................................................................................ 08 4.2.2. Production sur stock .......................................................................................... 08 4.2.3. Production mixte ............................................................................................... 08

5 Caractéristiques des Systèmes Automatisés de production ......................................... 08 5.1 Flexibilité .............................................................................................................. 08 5.2 Réactivité .............................................................................................................. 10 5.3 Pro-activité ............................................................................................................ 10 5.4 Robustesse ............................................................................................................ 10 5.5 La performance des Systèmes de Production ....................................................... 11

5.5.1 Définition de la performance globale ................................................................. 11 6 Décomposition du système de production .................................................................. 11 7 Typologie décisionnelle en gestion de production ...................................................... 13 8 Ordonnancement de la production .............................................................................. 14

8.1 Le problème d’ordonnancement ........................................................................... 14 8.2 Objectifs de l’ordonnancement ............................................................................. 16 8.3 Concepts de base .................................................................................................. 16 8.4 Notion de Pilotage ................................................................................................ 17 8.5 Pilotage et Ordonnancement ................................................................................. 19 8.6 Méthodes d’ordonnancement ............................................................................... 19

8.6.1. Simulation ......................................................................................................... 19 8.6.2. Résolution de problèmes par agents .................................................................. 20 8.6.3. Les Contraintes .................................................................................................. 20 8.6.4. Qualité de la solution ......................................................................................... 20

9 Conclusion ................................................................................................................... 21

Table des matières

1 Introduction ................................................................................................................. 22 2 Décision et aide à la décision ...................................................................................... 22

2.1 Décision ................................................................................................................ 22 2.2 Processus de décision ........................................................................................... 24 2.3 Aide à la décision ................................................................................................. 25

3 Les Systèmes Interactifs d’Aide à la Décision (SIAD) ............................................... 26 3.1 Définitions ............................................................................................................ 26 3.2 Structure d’un Système Interactif d’Aide à la Décision (SIAD) .......................... 27

4 Informatique décisionnelle .......................................................................................... 29 4.1 Le Data Warehouse .............................................................................................. 29 4.2 Datamart ............................................................................................................... 30 4.3 OLAP (On Line Analytical Processing) ............................................................... 30 4.4 DataWeb ............................................................................................................... 30 4.5 Datamining ........................................................................................................... 30

5 Classification des Systèmes Interactifs d’Aide à la Décision (SIAD) ........................ 31 5.1 Classification au niveau utilisateur ....................................................................... 31 5.2 Classification au niveau conceptuel ..................................................................... 31 5.3 Classification au niveau système .......................................................................... 32

6 Les systèmes Interactifs d’aide à la décision à base de Web (Web-based DSS) ........ 33 6.1 Définitions d’un SIAD à base de Web (Web-based DSS) ................................... 33 6.2 Les travaux de recherche récents dans le SIAD à base de Web (Web-based DSS).. …………………………………………………………………………………...35

6.2.1. Architectures et technologies ............................................................................ 35 6.2.2. Applications et réalisations ............................................................................... 36

7 Technologies Web ....................................................................................................... 38 7.1 Définitions ............................................................................................................ 38

7.1.1. Internet .............................................................................................................. 38 7.1.1.1 Les protocoles d’Internet ........................................................................... 38

7.1.2. World Wide Web .............................................................................................. 38 7.2 Termes rattachés au Web ...................................................................................... 39

7.2.1. Ressource du Web ............................................................................................. 39 7.2.2. HTTP ................................................................................................................. 39 7.2.3. HTML ................................................................................................................ 39 7.2.4. Document HTML .............................................................................................. 39 7.2.5. Serveur Web ...................................................................................................... 39 7.2.6. Navigateur Web ................................................................................................. 40 7.2.7. Page Web ........................................................................................................... 40

Table des matières

7.2.8. Editeur HTML ................................................................................................... 40 7.2.9. Site Web ............................................................................................................ 40 7.2.10. Adresse Web ................................................................................................... 40 7.2.11. Hébergeur Web ............................................................................................... 40 7.2.12. Agence Web .................................................................................................... 40 7.2.13. Annuaire Web ................................................................................................. 40 7.2.14. Portail Web ...................................................................................................... 40 7.2.15. Service Web .................................................................................................... 41

7.3 Les bases du Web ................................................................................................. 41 7.3.1. Architecture Client-Serveur .............................................................................. 41 7.3.2. URL ................................................................................................................... 43 7.3.3. Hypertexte et Topologie du Web ...................................................................... 43

7.4 La technologie du Web ......................................................................................... 44 7.4.1. HTTP ................................................................................................................. 44 7.4.2. HTML ................................................................................................................ 45 7.4.3. Feuilles de style CSS ......................................................................................... 46 7.4.4. XML .................................................................................................................. 46 7.4.5. JavaScript/DOM ................................................................................................ 46 7.4.6. CGI et Perl ......................................................................................................... 47 7.4.7. PHP .................................................................................................................... 48 7.4.8. ASP .................................................................................................................... 48 7.4.9. ActiveX ............................................................................................................. 48 7.4.10. Flash ................................................................................................................ 49 7.4.11. AJAX ............................................................................................................... 49 7.4.12. Servlet .............................................................................................................. 49 7.4.13. JSP (Pages JavaServer) ................................................................................... 50

8 Conclusion ................................................................................................................... 50

1 Introduction ................................................................................................................. 51 2 La notion d’agents ....................................................................................................... 51

2.1 Intelligence Artificielle Distribuée ....................................................................... 51 2.2 Définitions d’agents .............................................................................................. 52 2.3 Structure générale d’un agent ............................................................................... 53

2.3.1. Perception .......................................................................................................... 54 2.3.2. Action ................................................................................................................ 54

2.4 Typologie des agents ............................................................................................ 54

Table des matières

2.4.1. Agent réactif ...................................................................................................... 54 2.4.2. Agent cognitif .................................................................................................... 55 2.4.3. Architecture hybride .......................................................................................... 55 2.4.4. Agents autonomes ............................................................................................. 55 2.4.5. Agents sociaux .................................................................................................. 55 2.4.6. Agents mobiles .................................................................................................. 56 2.4.7. Agents adaptatifs ............................................................................................... 56 2.4.8. Agents flexibles ................................................................................................. 56 2.4.9. Agents du Web .................................................................................................. 57

3 Les Systèmes Multi-Agents ........................................................................................ 57 3.1 Définition des Systèmes Multi-Agents (SMA) .................................................... 57 3.2 Décomposition du SMA ....................................................................................... 59 3.3 Interactions entre les agents .................................................................................. 59

3.3.1. L’interaction par la communication .......................................................... 60 3.3.2. L’interaction par la coopération d’agent .......................................................... 61 3.3.3. L’interaction par la négociation entre ressources ............................................. 62

3.4 Protocoles d’interaction ........................................................................................ 62 3.4.1. Protocoles de Coordination ............................................................................... 62 3.4.2. Protocoles de Coopération ................................................................................ 63 3.4.3. Protocoles de Négociation ................................................................................. 63

3.5 Domaines d’application des SMA ........................................................................ 64 3.5.1. Applications industrielles .................................................................................. 64 3.5.2. Autres applications ............................................................................................ 64

3.6 Plates-formes de développement de SMA ............................................................ 65 4 Conclusion ................................................................................................................... 65

1 Introduction ................................................................................................................. 67 2 Contribution ................................................................................................................ 67 3 Architecture générale .................................................................................................. 68 4 Fonctionnement du modèle ......................................................................................... 68 5 Les structures des agents ............................................................................................. 71

5.1 Structure de l’Agent Analyseur (AA) ................................................................... 71 5.2 Structure de l’Agent Proposition (AP) ................................................................. 72 5.3 Structure de l’Agent Ressource (AR) ................................................................... 72 5.4 Structure de l’Agent Production (APr) ................................................................. 73

Table des matières

5.5 Structure de l’Agent Coordinateur (AC) .............................................................. 73 6 La Coordination ........................................................................................................... 74 7 Syntaxe des requêtes échangée entre agents ............................................................... 74 8 Langage de communication entre agents .................................................................... 75

8.1 Envoi de messages ................................................................................................ 75 8.2 Contenu des messages .......................................................................................... 75 8.3 Syntaxe des messages ........................................................................................... 76 8.4 Exemple de primitives .......................................................................................... 77

8.4.1. Requêtes Order .................................................................................................. 77 8.4.2. Requêtes What-is ............................................................................................... 77

8.5 Algorithme de Coordination ................................................................................. 77 9 Conclusion ................................................................................................................... 79

1 Introduction………………………………………………………………………….80 2 La technologie J2EE .................................................................................................... 80

2.1 les fonctions couvertespar J2EE ........................................................................... 81 2.1.1. Technologies du niveau client ........................................................................... 81 2.1.2. Technologies du niveau intermédiaire .............................................................. 82 2.1.3. Autres technologies J2EE .................................................................................. 82

3 L’environnement de développement ........................................................................... 83 3.1 Choix de langage de programmation .................................................................... 83 3.2 JBuilder : environnement de développement intégrant Java ................................ 84

4 La plate forme JADE ................................................................................................... 84 4.1 Breve description de JADE .................................................................................. 84 4.2 La norme FIPA ..................................................................................................... 84 4.3 Architecture logicielle de la plate-forme JADE .................................................. 85 4.4 Langage de communication de la plate-forme JADE ........................................... 86

5 Exemple d’application ................................................................................................. 87 5.1 Création d’un nouveau projet ............................................................................... 87 5.2 Affectation des ressources au projet ..................................................................... 88 5.3 Traitement de l’évènement panne ......................................................................... 91

5.3.1. Exécution des ressources ................................................................................... 91 5.3.2. Provocation de panne de quelques ressources ................................................... 91

5.4 Résolution de panne .............................................................................................. 94 6 Conclusion ................................................................................................................... 99

Table des matières

Conclusion Générale & Perspectives ........................................ 100

Références Bibliographiques ..................................................... 102

Table des figures

FIG. 1.1— Les flux informationnels et physiques .............................................................. 06 FIG. 1.2— Vision systématique d’un système de production ............................................. 12 FIG. 1.3 — Classification hiérarchique de décisions [Anthony, 1965], [Bitran et Tirupati, 1993] .................................................................................................................................... 13 FIG. 1.4 — Structure d’objectifs [Grabot, 1998] ................................................................ 16 FIG. 1.5 — Les Fonctions de Pilotage ................................................................................ 18

FIG. 2.1— Modèle du processus de décision de Simon [Simon, 1977] ............................. 25 FIG. 2.2— Structure d’un SIAD selon Sprague [Sprague et Carlson, 1982] ..................... 27 FIG. 2.3— Structure d’un SIAD basé sur la connaissance selon Marakas [Marakas, 2003] ………………………………………………………………………………………..28 FIG. 2.4— Technologie Client-Serveur .............................................................................. 41 FIG. 2.5— Architecture Client-Serveur .............................................................................. 42 FIG. 2.6— Architecture Client-Serveur du Web ................................................................ 42 FIG. 2.7— Topologie du Web ............................................................................................ 44

FIG. 3.1— Évolution vers l’IAD ........................................................................................ 51 FIG. 3.2— Exemple d’agent ............................................................................................... 53 FIG. 3.3— Structure générale d’un agent ........................................................................... 54 FIG. 3.4— Exemple de Système Multi-Agents (SMA) ..................................................... 58 FIG. 3.5 — Représentation imagée d’un agent en interaction avec son environnement et les autres agents [Ferber, 1995] ......................................................................................... 58

Table des figures

FIG. 3.6 — Mode de communication par tableau noir ....................................................... 60 FIG. 3.7 — Mode de communication par envoie de messages : (a) Diffusion, (b) Point à Point .................................................................................................................................... 61

FIG. 4.1— Architecture générale ....................................................................................... 68 FIG. 4.2— Scénario échangé entre les agents (diagramme de séquence) .......................... 69 FIG. 4.3— Communication entre les agents ...................................................................... 70 FIG. 4.4— Structure d’Agent Analyseur (AA) .................................................................. 71 FIG. 4.5— Structure d’Agent Proposition (AP) ................................................................. 72 FIG. 4.6— Structure d’Agent Coordinateur (AC) .............................................................. 73 FIG. 4.7— Primitive “Order” ............................................................................................. 77 FIG. 4.8 — Primitive “What-is” ......................................................................................... 77 FIG. 4.9 — Algorithme de Coordination………………………………………….............78

FIG. 5.1— Architecture générale du J2EE………………………………………………..80 FIG. 5.2— Principe de fonctionnement du J2EE………………………………………....81 FIG. 5.3— fonctionnement d’une JSP ................................................................................ 82 FIG. 5.4 — Architecture logiciel de La plate-forme JADE ............................................... 86 FIG. 5.5 — Création d’un nouveau projet .......................................................................... 88 FIG. 5.6 — L’enregistrement d’un nouveau projet ............................................................ 88 FIG. 5.7 — Affectation des ressources au projet (Imprimante) ......................................... 89 FIG. 5.8 — Détails sur les ressources de type « imprimante » .......................................... 89 FIG. 5.9 — Affectation des ressources au projet (Ordinateurs_Portables) ........................ 90 FIG. 5.10 — Détails sur les ressources de type « Ordinateur Portable » ........................... 90 FIG. 5.11 — Exécution des ressources ............................................................................... 91 FIG. 5.12 — Provocation de panne .................................................................................... 92 FIG. 5.13 — Détails sur la panne ....................................................................................... 92

Table des figures

FIG. 5.14 — Diagnostic de panne des imprimantes ........................................................... 93 FIG. 5.15 — Diagnostic de panne des Ordinateurs _Portables .......................................... 93 FIG. 5.16 — Linterface de l’Agent Production (APr) ........................................................ 94 FIG. 5.17 — L’interface de l’Agent Analyseur (AA) ........................................................ 94 FIG. 5.18 — L’interface de l’Agent Coordinateur (AC) .................................................... 95 FIG. 5.19 — L’interface de l’Agent Ressource (AR) ........................................................ 95 FIG. 5.20 — Exemple des pages web ................................................................................ 96 FIG. 5.21 — Résultat de recherche (succés) ...................................................................... 96 FIG. 5.22 — Résultat de recherche (échec) ........................................................................ 97 FIG. 5.23 — Linterface de l’Agent Proposition (AP) ........................................................ 97 FIG. 5.24 — Dépannage des imprimantes ......................................................................... 98 FIG. 5.25 — Interaction entre les agents (plate forme JADE) ........................................... 98

Introduction Générale

Page 1

Le pilotage d’un système de production doit assurer l’organisation des ressources, dans le temps et dans l’espace, afin de satisfaire les objectifs assignés. Les méthodes de planification traditionnelles, prédictives, déclinées le long d’une structure relativement stable et figée, ont longtemps constitué la voie principale de rationalisation de la production. De profondes et rapides modifications ont affecté à la fois le contexte technologique et économique dans lequel évoluent les entreprises.

Sur le plan technique, l’arrivée massive à partir des années 80, de nouvelles technologies reposant sur l’utilisation de l’électronique et de l’informatique ont modifié sensiblement le contour des emplois et des compétences opérationnelles requises. Elle a aussi profondément modifié la valeur des compétences en accordant un intérêt de plus grand à la capacité des acteurs à s’adapter aux évolutions et à intégrer de nouvelles techniques. Les connaissances ont ainsi perdu une partie de leur pérennité pour devenir le support de base nécessaire à toute évolution.

Sur le plan économique, les modifications de l’environnement, qui devient de plus en plus incertain et turbulent, entraînent de grandes difficultés pour les entreprises à établir des prévisions fiables. L’uniformisation quasi mondiale des moyens techniques de production, corrélée à des capacités de communication qui contribuent à limiter le problème des distances (autant dans le transfert des informations que des produits), a conduit à la globalisation des marchés et à la recherche de nouveaux critères de différentiation des produits, tel que la qualité, la capacité d’innovation, etc.

La notion de réactivité (temps réel) est ainsi apparue comme principe de pilotage pour répondre rapidement et intelligemment aux sollicitations de son environnement et aux aléas affectant ses processus opérationnels.

Pour accroître leur réactivité, les entreprises ont ainsi dû repenser leurs modes de gestion et d’organisation. L’accélération des processus décisionnels et la nécessité d’adapter en permanence le pilotage du système de production ont été concomitantes à la mise en place de structure décentralisée supervisée et à un décloisonnement des activités opérationnelles.

La forte évolution caractérisant le système technique contemporain impose désormais aux entreprises, d’une part de savoir répondre de plus en plus rapidement à de nouveaux problèmes, et d’autre part d’être capable, pour conserver leur niveau de performance, d’anticiper ces problèmes. La gestion des aléas devient ainsi, à coté de celle des événements une des nouvelles exigences du pilotage des systèmes de production.


Page 2

Contribution

Pendant les dix dernières années, le Web est devenu une partie importante et culturellement acceptée de l’analyse d’information, de collection, de diffusion, de livraison et de stockage d’environnement des individus, des entreprises, des gouvernements et d’autres organisations.

On peut définir le Web comme un accès rapide et facile à une grande sélection d’informations, des services de traitement transactionnel, des matériaux d’étude et des possibilités d’aide à la décision. Cette édition spéciale des Systèmes d’Aide à la Décision se concentre étroitement sur la recherche liée aux Systèmes d’Aide à la Décision à base de Web (Web-based DSS).

Notre étude se concentre sur les questions suivantes :

− Comment devrait une entreprise, étant donné un ensemble d’attributs industriels, utiliser la technologie Web pour décrire les attributs qui possèdent des propriétés incomplètes et incertaines ?

− Comment une entreprise devrait-elle inciter des règles d’allocation de ressource d’une grande base de données de production ?

− Comment une entreprise devrait-elle utiliser ces règles pour créer l’allocation de ressource optimale telle que le retard d’ordres peut être minimisé ?

La solution à ces questions doit être l’utilisation d’un Système d’Aide à la Décision à base de Web (Web-based DSS).

Parmi les travaux de recherche réalisés dans le cadre des Systèmes d’Aide à la Décision et les Systèmes d’Aide à la Décision à base de Web, nous nous sommes inspirés par le prolongement des travaux réalisés dans [Taghezout, 2008].

La contribution principale de cette thèse consiste à proposer un SIAD à base d’agents et à intégrer une technologie Web, son principe est d’aider les décideurs dans la prise de décision par l’accès à l’information sur le Web. Plusieurs agents sont prévus pour faciliter la recherche des ressources de substitution ainsi que l’accès à ces ressources. [Bessedik et Taghezout, 2009] Comme deuxième contribution, on va intégrer le protocole de coordination dans un Web-DSS à base d’agents en ajoutant un agent coordinateur. [Bessedik et Taghezout, 2010].

Organisation de la thèse

Ce mémoire est organisé en cinq chapitres :


Page 3

CHAPITRE 1 présente un état de l’art de définitions et de concepts de base autour des sytèmes de production et de leur gestion. Il rappelle ensuite les concepts de base et les outils de résolution associés aux problèmes d’ordonnancement.

CHAPITRE 2 constitue une repré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 suivi d’une description des Systèmes Interactifs d’Aide à la Décision (SIAD), leur évolution vers l’Informatique Décisionnelle pour les systèmes orientés données et l’évolution des SIAD vers les SIAD à base de Web pour conclurer par une description des technologies Web.

CHAPITRE 3 est consacré à l’étude des systèmes multi-agents et leurs applications.

CHAPITRE 4 présente notre contribution dans le domaine de l’aide à la décision. Nous commençons d’abord par la proposition de l’architecture de notre modèle, son fonctionnement, la communication entre agents et la structure de chaque agent. Le chapitre est terminé par la spécification des règles de coordination entre les agents et la description des actes de communication.

Le CINQUIÈME CHAPITRE propose une mise en œuvre informatique de l’ensemble des concepts présentés dans ce mémoire, pour illustrer la faisabilité de l’approche proposée et présenter la structure logicielle que nous avons développée.

La conclusion de ce mémoire nous permet de dresser le bilan des résultats obtenus et énumérer quelques perspectives futures.

Chapitre 1 Gestion de Production Dynamique

Page 4

1. Introduction

Actuellement, toute entreprise se doit être plus performante et d’avoir un niveau supérieur, sur le plan technique et économique, aux entreprises concurrentes. L’amélioration de la gestion de production est à la base de toute recherche dans le domaine de la productivité à accroître [Afnor, 1988]. La productivité est la clef de la survie et du développement des entreprises industrielles. La loi du marché nécessite une remise en cause des produits fabriqués et il n’est plus possible d’investir d’importantes sommes pour élaborer puis vendre un produit fini figé. Les modifications, améliorations ou transformations de produits, sont de plus en plus communes et la notion de flexibilité est fortement liée à cette évolution. La concurrence exige que l’entreprise se dote d’un système de production efficace qui réagisse rapidement aux contraintes du monde environnant et en particulier aux exigences et évolutions du marché.

Aujourd’hui, la fonction Production est l’une des fonctions importantes de l’entreprise, dont l’objectif est de produire des biens et des services, afin de dégager une rémunération du capital engagé, qui pourra être ou non réaffecté à de nouveaux investissements.

Le problème d’ordonnancement consiste à organiser dans le temps la réalisation d’un ensemble de tâches, compte tenu de contraintes temporelles (délais, contraintes d’enchaînement, etc.) et de contraintes portant sur l’utilisation et la disponibilité des ressources requises par les tâches [Lopez, 2001].

L’informatique permet d’avoir un outil d’aide à la décision et aussi aux planifications de la production. Cette planification est d’autant plus efficace que l’algorithme d’ordonnancement qu’elle utilise est performant. Le but étant d’atteindre un ordonnancement optimal qui répartit au mieux la charge de travail et tient compte des diverses contraintes de la production [Akrout, 2001].

Dans ce chapitre, nous présentons les différentes étapes de la gestion de production. Dans un premier temps, nous décrirons la fonction gestion de production et ses objectifs, puis nous présenterons les différents types des systèmes de production. Nous aborderons ensuite les caractéristiques des systèmes de production qui doivent être prises en compte. Enfin, nous décrivons les problèmes d’ordonnancement avec leurs contraintes.

2. Définition de la fonction Gestion de Production

Un problème d’ordonnancement consiste à affecter des tâches aux ressources et à décider de leur répartition dans le temps, de manière à optimiser un critère ou à trouver un compromis entre plusieurs critères [Esquirol, 1999].

Comme l’indique [Vincent, 2003] dans son ouvrage, pour pouvoir donner une définition de la gestion de production, il faut d’abord définir ce que l’on entend par la production. La production consiste en une transformation de ressources (humaines ou matérielles) en vue de la création de biens ou services :


Page 5

- La production d’un bien s’effectue par une succession d’opérations consommant des ressources et transformant les caractéristiques de la matière. Un exemple classique est la production de voitures.

- La production d’un service s’effectue par une succession d’opérations consommant des ressources sans qu’il n’y ait nécessairement transformation de matière. Des exemples classiques sont la mise à disposition de produits aux consommateurs (la vente), le traitement de dossier (par un notaire), la maintenance d’équipements.

On peut alors définir la gestion de production comme suit :

Définition 1

La gestion de la production consiste en la recherche d’une organisation efficace de la production des biens et services. La gestion de production consiste donc à l’obtention d’un produit donné dont les caractéristiques sont connues en mettant en œuvre un minimum de ressources. En gestion de production, on considérera, généralement, comme données les caractéristiques du produit que sont :

la définition du produit; le processus de fabrication; et la demande à satisfaire.

Définition 2

La gestion de la production consisterait à dire que c'est un ensemble de processus qui permet de mener à bien la fabrication de produits à partir d'un ensemble de données et de prévisions. En fait, la gestion de production regroupe un ensemble de problèmes liés à la production tels que la gestion des données, la planification et le contrôle (suivi) de la production, la gestion des stocks, la prévision, etc. L'ordonnancement, thème central de cette étude, est donc une fonction liée aux autres fonctions de la gestion de production et à tous les autres aspects inhérents au bon fonctionnement d'un atelier. [Taghezout, 2008]

Le rôle de la gestion de production est, d’organiser et de piloter le fonctionnement des processus physiques mis en œuvre dans l’entreprise, afin d’assurer une meilleure utilisation des moyens humains, physiques et technologiques disponibles, et de satisfaire au mieux l’objectif global de production défini en terme de quantités à fabriquer avec une qualité demandée, et des délais à respecter [Trentesaux, 1996].

Cette définition présente la gestion de production comme une fonction qui doit tenir compte de nombreuses contraintes et objectifs diversifiés selon leurs natures, dans le but de piloter l’ensemble des moyens de production : Contraintes décrites en termes d’utilisation efficace des moyens disponibles : ressources humains ou matérielles, et objectifs définis en terme global de délai de qualité et de coût.

L’automatisation est le moyen le plus courant qui permet d’obtenir une gestion performante de la production.


Page 6

Selon [Courtois, 1995] l’objectif principal de la gestion de production est de gérer les flux de matières et d'informations par rapport aux objectifs prioritaires définis par la direction générale de l'entreprise. Le schéma suivant montre l'ensemble des flux que gère, totalement ou partiellement, la gestion de production.

FIG. 1.1— Les flux informationnels et physiques

3. Objectifs de la Gestion de Production

Les principaux objectifs de la gestion de production, pour qu’elle soit efficace, peuvent

être considérés de la manière suivante [Vacher, 2000] :

Le respect des délais,

La minimisation des stocks intermédiaires,

L’optimisation de l’utilisation des moyens.

4. Typologie des Systèmes de Production

4.1. Typologie en fonction de l’organisation du flux de production

Dans cette typologie on peut distinguer trois types de production, sachant que l’on pourrait trouver de nombreux types intermédiaire. Ce genre de classification a été largement abordé dans la littérature par [Bénassy, 1987], [Crouhy et Greif, 1991] et plus récemment par [Courtois et al., 2006].


Page 7

4.1.1. La production unitaire

Elle consiste à produire un seul produit sur commande du client. Il n'existe pas de stock de produit fini. Une fois fabriqué, le produit est directement livré au client. Dans ce mode de production, les produits fabriqués répondent à des besoins précis manifestés par les clients. Le mode de production unitaire est pratiqué dans la production de certains types de produits :

- très onéreux (avions, locomotives, navires...)

- ayant des caractéristiques bien définies qui répondent à un besoin précis (meubles...)

- complexes (montage d'usine ou d'atelier...).

4.1.2. La production en série

Elle consiste à fabriquer un grand nombre d'articles identiques dont la conception et les caractéristiques ont déjà été définitivement établies. Le processus de fabrication est découpé en opérations élémentaires et répétitives permettant de produire plusieurs fois le même article. La production en série est une production pour le stock. La dimension de la série dépend de deux facteurs : la technologie et la demande.

Il existe deux types de production en série :

• La production en grande série

Les quantités à produire sont importantes et la diversité des produits est limitée. Dans ce cas l’utilisation de chaînes de fabrication est très rentable. Lorsque la chaîne est équilibrée, le taux d’utilisation des ressources est élevé et le temps d’attente par les produits en cours de fabrication est généralement faible.

• La production en petite et moyenne série

C’est le cas de la plupart des Petites et Moyennes Entreprises (PME) pour lesquelles la diversité des produits et le faible volume des demandes ne permettent pas une spécialisation des moyens de production. L’ordonnancement, dans ce cas, joue un rôle primordial pour optimiser l’utilisation des ressources et minimiser les pertes de temps.

4.1.3. La production continue

La différence entre la production en série et la production continue est d’ordre technologique. Dans la première, le produit passe, pendant sa fabrication, par des opérations distinctes séparées les unes des autres. Par contre, dans la production continue, le produit circule en flux continu et subit des transformations physiques et/ou chimiques.


Page 8

Ce type de systèmes concerne surtout les industries dont la production nécessite la manipulation de matières liquides ou gazeuses (produit pétrolier, semoule, ...).

4.2. Typologie en fonction de la politique de fabrication

Dans ce cadre on trouve en général trois classes : la production à la commande, la production sur stock et la production mixte.

4.2.1. Production à la commande

Elle concerne les produits coûteux, spéciaux ou prototypes. Dans ce cas, le produit n’est pas disponible au moment de la commande et nécessite un délai de réalisation. De plus, le prix n’est pas fixé, il se négocie en même temps que les délais, à la commande. Exemples: immeubles, navires.

4.2.2. Production sur stock

Elle concerne des produits peu coûteux ou d’usage général, qui sont fabriqués en grande quantité. Le produit est disponible immédiatement à la vente, à un prix fixé par catalogue. La production est souvent une production de masse ou une production par lot économique. Exemples: électroménagers, matériel hi-fi.

4.2.3. Production mixte

Cette production est un dérivé de la production à la commande. Afin de diminuer les délais de réalisation, les produits sont conçus de telle manière qu’il est possible de fabriquer des sous-ensembles suivant une politique de production sur stock et ne conserver la personnalisation du produit final par assemblage de ces sous-ensembles qu’au moment de la commande. Toutes les entreprises qui souhaitent améliorer leurs performances vis à vis de leurs clients tendent à choisir, de plus en plus, ce type de production. Exemples: lotisseurs, navigation de plaisance etc.

5. Caractéristiques des Systèmes Automatisés de production

Le contexte économique dans lequel les entreprises évoluent aujourd’hui nécessite des systèmes de production basés sur des principes, ayant des nouvelles caractéristiques, telles que la flexibilité, la réactivité, la pro-activité et la robustesse.

5.1. Flexibilité

De nos jours la flexibilité des systèmes de production est devenue primordiale à cause de la croissance continue de l’automatisation industrielle. Elle est considérée comme une possibilité pour un décideur de pouvoir à tout moment reconsidérer ses choix de manière à maintenir l’optimale de sa décision [Dagoumau, 2000].


Page 9

La flexibilité d’un système de production se caractérise par sa capacité d’adaptation à la production des nouveaux produits pour lesquels le système n’a pas été étudié. Cela suppose une adaptation totale du système de production au produit courant (de la distribution des flux discrets de composants aux opérations qu’effectuent les moyens de production sur le produit).

Plusieurs types de flexibilité [Abrudan, 1996], [Adamou, 1997] ont été mis en évidence suivant leurs incidences sur l’objectif qui est le produit fini et sur les moyens de production permettant la réalisation de ce produit.

flexibilité de produits : offre la possibilité d’une reconfiguration du système pour la prise en compte d’un nouveau produit ou famille de produits permettant ainsi un gain de productivité ;

flexibilité de mélange : c’est la possibilité de produire simultanément un ensemble de produits ayant des caractéristiques de base communes ; cette flexibilité peut être mesurée par le nombre de produits différents qui peuvent être fabriqués simultanément ;

flexibilité de quantité : il s’agit de la capacité du système à faire face aux fluctuations de la quantité des produits à fabriquer en modifiant les rythmes, ainsi que les temps de passage et d'engagement des outils ;

flexibilité de routage : offre au système les moyens d’un aiguillage plus souple, de façon à servir les différents segments de procédés libres ou sous - engagés ;

flexibilité d'ordre des opérations : permet de changer l’ordre des opérations en cours de production (ce qui suppose l’existence d’une gamme principale et des gammes secondaires) ou de choisir la destination suivante après chaque opération ;

flexibilité d'expansion : autorise une extension et une modification de l’architecture du système et elle exige une modélisation ;

flexibilité des ressources : c’est la capacité des ressources à effectuer plusieurs tâches élémentaires et de permettre la reprogrammation.

En considérant les définitions données ci-dessus on peut déduire que la flexibilité est un facteur déterminant dans l’élaboration de la conception d’un système de production apte à fabriquer plusieurs variantes de produits. Malheureusement, une forte accentuation sur cette flexibilité engendre des investissements très élevés des ressources technologiques relevant de ce système, à cause de leur surdimensionnement à l’installation, et entraîne une baisse de productivité. Au cours de l’automatisation d’un système flexible de production il faut donc faire un compromis entre flexibilité et productivité.


Page 10

5.2. Réactivité

La réactivité d’un système de production est définie comme l’aptitude à répondre (réagir) dans un temps requis aux changements de son environnement interne ou externe. C’est à dire qu’il doit avoir une conduite qui lui permette de réagir et de s’adapter, en fonction des objectifs de production, aux fluctuations des besoins et aux aléas du système par rapport au régime (fonctionnement) permanent (stable) [Dauzère-P, 2005]. Cette réactivité impose une vue dynamique des événements, pour cela trois fonctions s’avèrent nécessaires : Une fonction d’observation, Une fonction de surveillance et Une fonction de correction.

une fonction d’observation qui collecte les variables nécessaires au suivi, afin de connaître l'état courant du système (disponibilité et état des produits, disponibilité et état des moyens de production) ;

une fonction de surveillance qui détecte (suite au résultat d'une observation) et interprète les écarts et les changements entre le plan prévisionnel et le plan courant par anticipation ;

une fonction de correction qui tente à tout instant de corriger les écarts entre ces plans, ce qui implique un ordonnancement dynamique.

5.3. Pro-activité

La pro-activité d’un système de production se caractérise par ses capacités d’anticipation (prévoir et/ou provoquer) des changements d’état, d’apprentissage et d’enrichissement des connaissances, d’adaptation de ses règles de fonctionnement et par sa capacité de réorganisation reposant sur une architecture décentralisée et une délégation de responsabilité. Les fonctions d’observation, de surveillance et de correction sont nécessaires pour assurer la pro activité. Les processus de décision distribuée offrent de réelles capacités en termes de réactivité et de pro activité.

5.4. Robustesse

La robustesse d’un système de production se définit par son aptitude à produire conformément aux résultats attendus. Cela suppose la garantie de l’obtention des performances souhaitées en présence d’incertitudes dans le système [Billaut, 2005].


Page 11

5.5. La performance des Systèmes de Production

5.5.1 Définition de la performance globale

La performance peut être un résultat (Apprendre le coran…), le meilleur résultat (celle du sportif), le résultat idéal (celle du matériel), ou encore une action (domaines linguistique et du spectacle). La performance globale d’un système est l’obtention conjointe de la pertinence, de l’efficience, et de l’efficacité, appréciée en termes de coûts et de valeur, sur l’intégralité du cycle de vie du système [Tahon, 2003]. La performance est une notion relative aux objectifs que l’on se fixe, aux résultats que l’on obtient, et aux actions mises en œuvre pour produire ces résultats, grâce à des moyens donnés. Ainsi la performance peut être « décomposée » en trois sous notions que sont la pertinence, l’efficience et l’efficacité.

La pertinence

Elle se détermine lors de la conception du système de production, car elle représente l’articulation entre objectifs et moyens, c’est-à-dire se donner exactement les moyens d’atteindre un certain niveau de satisfaction.

L’efficience

C’est la réponse à la question : « Est ce que les résultats sont suffisants compte tenu des moyens mis en œuvre ? ». L’indicateur d’efficience par excellence est le rendement d’un système et si elle n’est pas satisfaisante, ce sont des décisions relatives au pilotage ou au management qui seront à prendre.

L’efficacité

L’efficacité est l’articulation entre résultats et objectifs, elle peut être bien souvent jugée grâce à des indicateurs de qualité. La performance est relative au niveau de décision auquel elle correspond.

6. Décomposition du système de production

Les systèmes de production peuvent être des systèmes très complexes et difficiles à gérer au vu de toutes leurs composantes fonctionnelles (fabrication, achat, distribution, maintenance...). Ils sont donc beaucoup étudiés, et ce depuis longtemps. Plusieurs approches ont été envisagées dans le but de mieux comprendre leur fonctionnement et de mieux les appréhender.

D’une manière classique, tout système de production est décomposé selon une approche systématique en deux sous systèmes [Doumeinghts et al, 1983] : le système physique de production dans lequel circulent les flux des matières et le système de gestion dans lequel sont regroupés les flux d’informations et de décisions.


Page 12

FIG. 1.2— Vision systématique d’un système de production

La figure 1.2 schématise les interactions existantes entre le système de pilotage et le système de production.

− Le système de production est un ensemble de ressources (humaines et matérielles) permettant de convertir des matières premières en produits finis.

− Le système de pilotage fixe les ordres de gestion; des données récupérées par le sous système informationnel sont traitées par le sous système décisionnel afin de définir les décisions qui garantissent le bon fonctionnement du système physique compte tenu des multiples contraintes internes ou externes à l’entreprise. Ces décisions sont classées selon l’horizon sur lequel elles s’appliquent.

− Le système de décision contrôle le système physique de production. Il en coordonne et organise les activités en prenant des décisions basées sur les données transmises par le système d’information.

− Le système d’information, son rôle est de collecter, stocker, traiter et transmettre des informations. Il intervient à l’interface entre les systèmes de décision et de production et à l’intérieur même du système de décision, pour la gestion des informations utilisées lors de prises de décision, et du système physique de production, pour la création et le stockage d’informations de suivi par exemple. L’association des parties des systèmes de décision et d’information concernant uniquement la production constitue le système de gestion de production.


Page 13

7. Typologie décisionnelle en gestion de production

Le système de gestion de production doit maintenir un certain niveau de productivité tout en restant compatible avec les contraintes commerciales, techniques, financières et sociales. Mais, en raison des contraintes imposées par le marché et de la diversité des fonctions à assurer, celui-ci est souvent confronté à des prises de décisions possédant une forte combinatoire et surtout, incluant plusieurs problématiques différentes. C’est pourquoi les décisions de gestion sont souvent structurées en niveaux.

L’organisation des décisions prises par le système de gestion d’une unité de production s’inspire du modèle classique pyramidal, décomposant les décisions selon troix niveaux : stratégique, tactique et opérationnel [Anthony, 1965], [Bitran et Tirupati, 1993] (voir Figure 1.3).

FIG. 1.3 — Classification hiérarchique de décisions [Anthony, 1965], [Bitran et Tirupati, 1993]

− le niveau stratégique élabore la stratégie au plus haut niveau en formulant une politique à long terme de l’entreprise (vision à plus de deux ans, en général) au niveau des moyens financiers, matériels et humains qui sont déterminés par une


Page 14

série de décisions, compte tenu d’objectifs techniques et économiques. Des exemples de ce type de décisions sont par exemple : la détermination de la taille et l’emplacement de nouvelles usines, l’acquisition d’équipements neufs, le choix de nouvelles gammes de produits, etc.

− le niveau tactique assure l’organisation de la production en cohérence avec les décisions prises au niveau stratégique de façon à obtenir une utilisation efficace des ressources du système. Ce problème est complexe et nécessite généralement une décomposition. Par exemple, les décisions tactiques prises à moyen terme peuvent nécessiter une agragation de la fabrication des produits en familles ou un fractionnement de la production en sous-ensembles ou lots.

− le niveau opérationnel prend des décisions à court terme et à très court terme celles-ci, sont prises et / ou mises en œuvre par des agents de maîtrise ou d’exécution. Les données sont ici beaucoup plus détaillées. Les décisions prises à ce niveau concernent la mise en œuvre des moyens de l’atelier afin de produire, dans les délais, les quantités fixées au niveau supérieur, ce qui nécessite une désagrégation complète du plan si celui-ci a été construit par famille de produits. Les types de problème que l’on rencontre sont : l’ordonnancement de la production, la gestion du stockage, etc.

8. Ordonnancement de la production

La résolution d’un problème d’ordonnancement commence par la modélisation du système de fabrication et de son fonctionnement. Il faut donc définir un ensemble de paramètres représentant le système étudié, les liens existant entre ces paramètres et les critères qui permettront d’évaluer les solutions obtenues. Il est clair qu’il existe diverses manières de modéliser chaque problème d’ordonnancement et on est amené à choisir un mode de description. Parmi ces modes, on peut citer les équations mathématiques, les graphes potentiels-taches, les réseaux de Pétri, etc.

8.1. Le problème d’ordonnancement

L’ordonnancement est une fonction essentielle en gestion de production, C’est un problème difficile en raison du nombre de calculs à effectuer pour obtenir un ordonnancement qui optimise le critère retenu. En plus, il existe de nombreux problèmes d’ordonnancements ou diverses méthodes exactes ou approches de résolution sont proposées pour résoudre une partie d’entre eux [Esquirol, 1999].

L’ordonnancement ne se limite pas à une simple question de séquence de tâches, le problème d’ordonnancement doit prendre en compte également des contraintes temporelles et de disponibilité de ressources. Dans la littérature un bon nombre de définitions du « problème d’ordonnancement » ont été proposées.


Page 15

Définition 1

Ordonnancer ou (planifier) le fonctionnement d’un système industriel de production consiste à gérer l’allocation (ou l’accès à des ressources au cours du temps, tout en satisfaisant au mieux un ensemble de critères). [Rodammer et White, 1988]

Définition 2

Ordonnancer, c’est programmer l’exécution d’une réalisation en attribuant des ressources aux tâches et en fixant leurs dates d’exécution. [Carlier et Chrétienne, 1988]

Définition 3

« Une tâche est un travail élémentaire nécessitant un certains nombre d’unités de temps et de ressources. Ordonnancer un ensemble de tâches, c’est programmer leur exécution en leur allouant les ressources requises et en fixant leur date de début ». [Gotha, 1993]

Définition 4

« Le problème d’ordonnancement consiste à organiser dans le temps la réalisation de tâches, compte tenu de contraintes temporelles (délais, contraintes d’enchaînement,…) et de contraintes portant sur l’utilisation et la disponibilité des ressources requises ». [Esquirol et Lopez, 1999]

L’ordonnancement est considéré comme un processus de prise de décision qui joue un rôle important dans la plupart des systèmes de production et de fabrication. Parmi les définitions du problème d’ordonnancement, on retrouve l’aspect commun de l’affectation des tâches dans le temps et dans l’espace au moindre coût et en un temps réduit.

Donc il ya problème d’ordonnancement : 1. Quand un ensemble de travaux est à réaliser, 2. Que cette réalisation est décomposable en tâches(ou opérations), 3. Que le problème consiste à définir la localisation temporelle des tâches et, ou la

manière de leur affecter les moyens nécessaires. Les problèmes d’ordonnancement apparaissent dans tous les domaines de l’économie.

L’informatique : où les tâches sont les jobs et les ressources sont la mémoire et le processeur,

La construction : dans le cadre de suivi de projet, L’industrie : pour les problèmes d’atelier et la gestion de production, L’administration : comme l’emploi du temps.


Page 16

8.2. Objectifs de l’ordonnancement

D’une manière générale, on distingue plusieurs classes d’objectifs concernant un ordonnancement [Esquirol et Lopez, 1999] : − les objectifs liés au temps : on trouve par exemple la minimisation du temps total

d’exécution, du temps moyen d’achèvement, des durées totales de réglage ou des retards par rapport aux dates de livraison,

− les objectifs liés aux ressources : maximiser la charge d’une ressource ou minimiser le nombre de ressources nécessaires pour réaliser un ensemble de tâches sont des objectifs de ce type,

− les objectifs liés au coût : ces objectifs sont généralement de minimiser les coûts de lancement, de production, de stockage, de transport, etc,

Un exemple de structure d’objectifs est présenté Figure 1.4.

FIG. 1.4 — Structure d’objectifs [Grabot, 1998]

8.3. Concepts de base

Les concepts généraux de l’ordonnancement de production concernent les commandes, les attributs du job, les ressources et les tâches, etc. [Enginest, 2005].

a) Commande : commande de clients pour un produit donné, b) Job : (le travail), il correspond à la mise en production des commandes de l’usine, par

exemple le processus entier de fabrication dans une entreprise, c) Attributs du job : où chaque job comporte des attributs, d) Tâches : une tâche correspond à un processus de fabrication de produit et elle est

caractérisée par des informations nécessaires dont une tâche peut être une date de début, une date de fin souhaitée, une durée,…Comme on peut avoir des contraintes


Page 17

liées aux tâches. Par exemple l’exécution d’une tâche est conditionnée par la fin d’exécution d’une autre tâche. Un job est représenté par une ou plusieurs tâches et ce travail (job) consiste à réaliser ces tâches dont l’ordre d’exécution constitue la gamme de fabrication du travail et ce qui permet de distinguer les grandes familles d’ateliers :

o problèmes à une machine : chaque job n’est constitué que d’une tâche à réaliser,

o problèmes à des machines parallèles : chaque job n’est constitué que d’une tâche qui peut être réalisée par une ou plusieurs machines,

o problèmes d’'open shop' : la gamme de production n’est pas fixée et différente pour chaque job,

o problèmes de ' job shop': la gamme de fabrication est linéaire (l’opération ne peut être commencée qu’après la fin de la précédente) et elle est différente pour chaque job,

o problèmes de ' flow shop' : la gamme de fabrication est linéaire et identique pour chaque job.

e) Ressources : correspond à ce qu’on utilise pour la production (machines, main d’œuvre, etc) et chaque tâche est réalisée par une ressource. On peut avoir un sous-ensemble de ressources de même caractéristique qu’on appelle ressource type, on utilise une ressource de ce sous-ensemble pour traiter une tâche,

f) Critères : correspondent aux objectifs à optimiser avec la minimisation ou la maximisation d’une fonction, ces critères peuvent être liés aux temps : temps total d’exécution, temps moyen d’achèvement…etc, ou liés aux ressources : la charge des ressources, la quantité totale des ressources, etc.

g) Contraintes : correspondent aux restrictions sur les valeurs que peuvent prendre les variables de décision, on a :

- Les contraintes temporelles, - Les contraintes de temps alloué ; les dates limites des tâches ou la durée totale

d’un projet, - Les contraintes de cohérence technologique ou de gamme, - Les contraintes de ressources, - Les contraintes d’utilisation des ressources, - Les contraintes de disponibilité des ressources, - La priorité des jobs, - L’ordre d’exécution des tâches d’un job, - La succession et/ou précédence des jobs…

8.4. Notion de Pilotage

A l’heure actuelle, il n’existe pas de définition unique ni stabilisée du terme pilotage. Une définition a été proposée dans les travaux de Trentesaux en 2000, dans laquelle il définit le pilotage comme suit :


Page 18

Le pilotage consiste à décider dynamiquement des consignes pertinentes à donner à un système soumis à perturbation pour atteindre un objectif donné décrit en termes de maîtrise de performances [Trentesaux, 2002]. Le concept de pilotage concerne la définition et l’organisation des interrelations entre deux sous-systèmes : un sous-système physique (appelé système opérant) et sous-système de décision (appelé système de pilotage), conduisant à la mise en œuvre d’une boucle de rétroaction. Les informations en entrée du système de pilotage sont les objectifs (résultats souhaités du système opérant), les autres données et contraintes externes (issues de l’environnement) ainsi que les observations effectuées sur le système opérant (états internes et mesure des effets). Les informations en sortie sont les signaux de commande, les résultats du système opérant ainsi que le sous-ensemble des indicateurs de performance requis par l’environnement. D’une manière générale, piloter un système de production fait appel à deux fonctions distinctes :

• Une fonction de gestion à priori (ou planification) dont le rôle est d'assurer la programmation d'un ensemble d’actions ou de décisions.

• Une fonction de gestion en temps réel (ou conduite) dont le rôle est de prendre les décisions qui relèvent de l’immédiat, c’est-à-dire qui sont motivées par les événements liés à l’état courant du système de production.

La fonction pilotage temps réel peut être décomposée en deux sous fonctions : conduite et commande.

FIG. 1.5 — Les Fonctions de Pilotage

Evénements

Conduite

Système physique

Commande

Suivi

Suivi temps réel

Capteurs Actions

Tâches exécutables

Décisions planifiées


Page 19

8.5. Pilotage et Ordonnancement

Parunak [Parunak, 1991] définit l’ordonnancement prévisionnel comme étant le : « sous ensemble du produit cartésien Quoi*Où*Quand pour un sous ensemble de taches à réaliser ». On peut différencier les types de pilotage selon qu’un ordonnancement prévisionnel des taches est réalisé ou non :

1. Pilotage sans ordonnancement prévisionnel : Les allocations se font en temps réel et de manière dynamique au fur et à mesure de l’évolution du système de production.

2. Pilotage à ordonnancement prévisionnel partiel : Seule une partie des taches à réaliser sont planifiées à priori. Les autres sont allouées dynamiquement.

3. Pilotage à ordonnancement prévisionnel total : Toutes les taches à réaliser sont allouées en amont du système de pilotage.

8.6. Méthodes d’ordonnancement

Parmi les méthodes utilisées en ordonnancement, on peut distinguer les méthodes anciennes comme la méthode PERT, la méthode des potentiels, la simulation ainsi que les méthodes liées à l’intelligence artificielle ou l’emploi d’heuristiques. Cependant, les méthodes PERT et des potentiels ne sont applicables que pour l’ordonnancement d’un ouvrage unitaire ou de production unitaire le passage à la petite série leur est fatal. Elles doivent passer le relais à des méthodes exactes issues des techniques de l’optimisation combinatoire (programmation dynamique, procédure par séparation et évaluation etc.) à des méthodes approchées (heuristiques) ou à des algorithmes génétiques. Ces méthodes peuvent être classées en diverses familles ; nous donnons brièvement la description de quelques familles [Taghezout, 2008].

8.6.1. Simulation

L’idée de base de la simulation est de simuler le comportement d'un atelier en faisant avancer le temps et en chargeant les machines libres par un choix sur les opérations disponibles. L’approche de la simulation intègre donc la notion de règles de priorité lors du chargement des postes de travail. Un grand nombre de ces règles ont été citées dans la littérature. Elles ne sont pas toutes efficaces et il n’existe pas vraiment de règle donnant de bons résultats pour tous les types de problèmes et pour un critère donné.

En effet, L’approche de simulation fait partie des méthodes dites à construction progressive d’un ordonnancement. Ce type de méthode permet de déterminer rapidement un ordonnancement respectant les contraintes techniques. Il se caractérise par une grande puissance de modélisation. La qualité de l’ordonnancement dépend des règles de construction de celui-ci, exprimées sous la forme de priorités données aux différents travaux dans les files d’attente.


Page 20

Règles de priorité : Un très grand nombre de règles ou combinaisons de règles ont été définies et testées. On distingue plusieurs critères de classification :

- Règle locale ou globale : une règle est locale si elle prend en compte que les informations locales à la file d’attente.

- Statique ou dynamique : une règle est dite statique si la valeur de la priorité reste invariante pendant le séjour du travail dans la file d’attente. Une règle dynamique peut conserver l’ordre relatif entre deux travaux (SLACK) mais la valeur de la priorité doit être mise à jour dès qu’un nouveau travail arrive dans la file d’attente.

- Informations prises en compte par la règle : on distingue les règles qui prennent en compte les temps opératoires, les dates de livraison, combinent les deux.

- Complexité : combinaison pondérée de règles, utilisation de paramètres à régler.

8.6.2. Résolution de problèmes par agents

Nous pouvons considérer que le problème d’ordonnancement est un problème bien posé puisque le traitement fait apparaître des caractères de répartition et de distribution plus ou moins collectives des actions au niveau des machines (ressources). Pour cette raison, nous pouvons le traiter par une approche par agents. La notion d’organisation d’agents fait référence à la façon dont les agents réalisent en commun leurs actions pour contribuer à l’amélioration d’un objectif global. Les agents ont donc des tâches précisées à priori par une gamme de tâches et ils règlent par eux-mêmes la coordination de ces tâches. [Taghezout, 2008]

8.6.3. Les Contraintes

Sur ces problèmes, il existe des contraintes qui peuvent être obligatoires ou sujettes à des relaxations:

- Des contraintes de précédence entre les opérations qui sont en général absolues et fortes,

- Des contraintes physiques qui reproduisent la capacité des diverses ressources de l'atelier,

- Des contraintes de disponibilité des ressources, qui concernent à la fois les ressources consommables (utilisables une seule fois) et les ressources récupérables, indiquant les ressources pouvant être utilisées durant une période de temps donné (comme les machines et la main-d’œuvre).

Parmi les contraintes relaxables (ou de préférences) figurent des contraintes de respect des livraisons, d'encombrement minimal, de lissage de charge, etc.

8.6.4. Qualité de la solution

Ainsi, on parle d’ordonnancements admissibles ou réalisables pour un ordonnancement vérifiant ces contraintes absolues, c’est-à-dire la réalité de l'atelier et de la vie courante.


Page 21

Cependant, si un ordonnancement est admissible, il faut encore pouvoir juger de sa qualité et s’il respecte les préférences que l’on s’est assignées. On ne peut parler de bon ordonnancement que si on l’évalue par rapport à un critère donné. Donc, il faut donner des objectifs à atteindre, au mieux, car il est toujours difficile d'optimiser une fonction comprenant plusieurs critères. On peut toujours citer parmi les objectifs les plus importants le respect des dates de livraison, la qualité des produits, et la limitation des en-cours de fabrication. On peut aussi envisager de respecter un niveau de stock, maximiser la productivité, répartir au mieux la charge sur les différentes machines, éviter les goulots d'étranglement (sources de gêne pour l'atelier et des problèmes en cas de panne). Il existe d'autres objectifs moins rigides comme la répartition au mieux du travail, les changements compliqués d'outils [Vacher, 2000]. Le cout d’une planification est affecté de manière plus ou moins forte par tous ces objectifs et l'on ne peut les inclure tous dans notre fonction de cout sous peine de rendre difficile, voire impossible, l’obtention d'une solution. Il faut aussi s’efforcer de respecter au mieux les décisions passées, et éviter de trop remettre en cause les ordonnancements. Le difficile compromis entre les différentes préférences impose donc une échelle des objectifs à satisfaire en distinguant entre ceux qui ont la priorité et ceux que l'on ne peut satisfaire qu’à moitié. Pour notre problème, nous prendrons pour objectif la minimisation des retards quelque soit leur nature.

9. Conclusion

Les systèmes de production sont, par nature, complexes. Il est par ailleurs nécessaire de tenir compte des demandes réelles ou prévues à long et à moyen terme, pour pouvoir utiliser au mieux les ressources disponibles. De plus, les événements aléatoires internes et externes qui interviennent constamment nécessitent de recalculer l’ordonnancement. L’ordonnancement consiste à placer les différentes opérations sur les différentes ressources en respectant les contraintes des ressources et les contraintes de précédence. Le système de pilotage des flux de production proposé permet la maîtrise et la gestion des moyens de production pour la fabrication de produits donnés. Le chapitre suivant introduit la notion de Systèmes Interactifs d’Aide à la Décision (SIAD).

Chapitre 2 L’aide à la décision et les technologies Web

Page 22

1. Introduction

Avec le développement de l’Internet, les Systèmes Interactifs d’Aide à la Décision à base de Web (SIAD à base de Web) sont devenus une nouvelle tendance dans la recherche des SIAD. Dans [Power, 2002], Power définit les Systèmes Interactifs d’Aide à la Décision à base de Web (Web-based DSS) comme un système informatisé d’aide à la décision qui apporte des informations ou des outils d’aide à la décision à un gestionnaire ou à un analyste en utilisant le navigateur Web comme le navigateur Netscape ou Internet Explorer.

L’Internet s’étend tous les jours aussi bien du point de vue du nombre de serveurs connectés que du point de vue de la quantité d’informations disponible sur ces serveurs et du nombre de clients qui se connectent. Les principaux services responsables de cet engouement sont le World Wide Web et l’e-mail. Le 3W, le WWW, le World Wide Web ou en un mot le Web qui désigne en anglais la toile d’araignée, représente donc la toile d’araignée couvrant le monde entier. Comme on le sait, ses concepteurs ont eu l’intelligence d’englober les principaux outils déjà existant à l’époque où il fut inventé (ex: Gopher, les News, ftp, telnet et d’autres). Surfer sur le Web c’est visiter d’autres pays à l’autre bout du monde, ou une galerie de peinture dans votre ville, avoir les dernières nouvelles ou accéder à des traités sur la préhistoire, réviser votre Anglais ou apprendre le Breton, réserver une place de ciné ou gérer votre compte en banque… et la liste est longue.

Ce chapitre présente les Systèmes d’Aide à la Décision (SAD), les Systèmes Interactifs d’Aide à la Décisions (SIAD), et les Systèmes Interactifs d’Aide à la Décisions à base de Web (Web-based DSS : Web-based Decision Support System), les concepts et les définitions de base qui leurs sont directement associés et les technologies Web.

2. Décision et aide à la décision

2.1. Décision

Pour la plupart des écoles rationalistres-analytiques, la décision est définit comme un choix entre plusieurs alternatives. Pour d’autres, la décision concerne aussi le processus de sélection de buts et d’alternatives. Les approches cognitives, finalement, traitent la décision comme le résultat d’un processus global de résolution de problèmes.

Le terme décision a plusieurs définitions. Il est assimilé à un acte, une action ou un processus de résolution de problèmes :

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 [Lévine, 1989].


Page 23

Roy et Bouyssou [Roy et Bouyssou, 1993] estiment que la décision est souvent présentée comme le fait d’un individu isolé (décideur) qui exerce librement un choix entre plusieurs possibilités d’actions à un moment donné dans le temps.

Selon Mintzberg [Mintzberg, 1979], une décision quelle soit individuelle ou résultante d’un travail de groupe, peut être définie comme l’engagement dans une action, c’est-à-dire, une intention explicite d’agir.

Par ailleurs, les théoriciens de la décision identifient cinq types de problèmes décisionnels distincts :

1. Description : problèmes associés à la caractérisation réelle de l’état courant de l’organisation ;

2. Investigation : problèmes associés aux relations entre deux ou plusieurs éléments de données ou phénomènes ;

3. Explication : problèmes associés à l’établissement d’une relation cause à effet ; 4. Prédiction : problèmes associés à projection future basée sur des données

historiques ; 5. Prescription : problèmes associés à la projection normative basée sur des données

historiques.

Selon Simon [Simon, 1977], l’examen de la nature des décisions prises dans l’organisation permet de répartir les décisions dans l’organisation sur toute la longueur d’une échelle qui va du moins normalisé au plus normalisé.

1. Une décision est bien normalisée quand un processus connu et explicitable existe permettant de traiter les informations entrantes dans le système de traitement de l’information. Les décisions bien normalisées reviennent souvent, et c’est probablement pour cette raison que l’organisation a fait l’effort de les formaliser.

2. Une décision mal ou non normalisée est prise par une procédure non programmée ou peu programmée, ce qui ne veut pas dire qu’elle n’est pas programmable. Assez naturellement, une décision mal normalisée est une décision que l’on ne prend pas souvent et qui présente un caractère exceptionnel par sa nouveauté et son enjeu.

Une décision non normalisée est un problème que se pose le décideur tel que, si on veut formaliser la résolution, un gros effort va être nécessaire. Ce problème est assez souvent nouveau. Il faudra d’abord construire un espace de résolution, c’est-à-dire la ou les bonnes représentations du problème, il faudra donc structurer et modéliser le problème ; d’où une analogie soulignée par Simon [Simon, 1977], entre décision mal normalisée et décision mal structurée, et un recouvrement entre les décisions biens structurées et celles qui sont normalisées. Ainsi, selon le niveau de structuration des décisions, celles-ci peuvent être classées en trois types [Trentesaux, 1996] :


Page 24

1. Décision structurée : le problème est clairement posé en termes techniques, les données sont fiables et numériques. Les modèles sont clairement définis, ce qui permet une résolution fiable et algorithmique du processus décisionnel. Une décision est bien structurée quand un processus connu et explicitable existe permettant de traiter les informations dans le système [Lévine, 1989]. Elle correspond à un programme immuable et fixe. Exemple : facturation, paye, gestion de production par programmation linéaire, etc.

2. Décision peu ou mal structurée : le problème peut ne pas être clairement posé et nécessite un gros effort pour être formalisé, les données sont souvent qualitatives, peu fiables, très peu stables, difficilement accessibles, etc. la décision est difficilement exprimable sous forme algorithmique. Exemple : choix de placement, choix d’un réseau de distribution, augmentation de capital, etc.

3. Décision non structurée : le problème n’est pas clairement posé, le principe de la rationalité limité [Simon, 1977] s’applique à toutes les étapes du processus décisionnel. La décision élaborée est difficilement justifiable de manière rationnelle. Exemple : choix d’une publicité, choix d’un modèle de gestion et réalisation du logiciel associé, choix de nouveaux produits, réaction de l’opérateur face à un aléa qu’il n’a jamais envisagé.

2. 2. Processus de décision

Pour Holtzman [Holtzman, 1989], prendre une décision signifie concevoir et s’engager à une stratégie d’allocation irrévocable de ressources précieuses. Le processus de prise de décision n’inclut pas, pour autant, l’allocation de ces ressources qui est appelée une action. Parmi les différents travaux sur les processus de décision, Simon [Simon, 1977] a proposé un schéma de la prise de décision suffisamment général pour pouvoir être reconnu comme un véritable modèle canonique de la décision (Figure. 2.1)


Page 25

FIG. 2.1— Modèle du processus de décision de Simon [Simon, 1977]

Ce modèle distingue quatre phases dans le processus de décision, non obligatoirement distincts.

La recherche d’information (Intelligence) : il s’agit d’identifier les objectifs ou buts du décideur et de définir le problème à résoudre. Pour cela, il est nécessaire de rechercher les informations pertinentes en fonction des préoccupations du décideur.

La conception (Design) : cette phase comprend la génération, le développement et l’analyse des différentes suites possibles d’actions. Pour cela, il va être nécessaire de choisir un ou plusieurs modèles de décision en fonction de la complexité du problème à traiter.

Le choix (Choice) : pendant cette phase, le décideur choisit entre les différentes suites d’actions (solutions) qu’il a été capable de construire et d’identifier pendant la phase précédente.

L’évaluation (Review) : cette phase conduit à la recommandation d’une solution appropriée au modèle. Cette phase peut amener à la réactivation de l’une des trois phases précédentes ou, au contraire, à la validation de la solution.

2. 3. Aide à la décision

Selon Roy et Bouyssou [Roy et Bouyssou, 1993], l’aide à la décision est définie comme étant l’activité de celui (homme d’étude) qui, prenant appui sur des modèles clairement explicités mais non nécessairement complètement formalisés, cherche à obtenir des éléments de réponses aux questions que pose un intervenant (décideur) dans un processus de décision, éléments concourant à éclairer la décision et normalement à prescrire, à 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 duquel cet intervenant se trouve placé, d’autre part. par ailleurs, ils soulignent que l’aide à la décision contribue à construire et à faire partager des convictions.


Page 26

3. Les Systèmes Interactifs d’Aide à la Décision (SIAD)

Le concept d’aide à la décision interactive est basé sur l’équilibre entre le jugement humain et le traitement des informations par l’ordinateur. Keen et Scott-Morton [Keen et Scott-Morton, 1978] présentent les Systèmes Interactifs d’Aide à la Décision (SIAD) comme des systèmes se consacrant aux tâches semi-structurées. Contrairement aux problèmes structurés, l’un des aspects les plus importants dans l’aide interactive à la décision est que l’homme prend l’avantage sur la machine. Résoudre le problème nécessite de faire appel à l’intuition et aux savoir-faire du décideur qui devient l’élément prépondérant du couple homme-machine.

3.1. Définitions

Le concept de Systèmes Interactifs d’Aide à la Décision (SIAD) a tout d’abord été introduit par l’école anglo-saxonne et est la traduction du concept de Decision Support Systems (DSS).

De nombreuses définitions ont été proposées dans la littérature [Holtzman, 1989] [Marakas, 2003] [Simon, 1977] [Zaraté, 1991] [Turban, 1993], qualifiant un SIAD de système d’information interactif spécifiquement développé pour aider à la résolution d’un problème de décision.

Une des définitions les plus citées des Systèmes d’aide à la Décision est celle de Keen et Scott-Morton [Keen et Scott-Morton, 1978] : « 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 d’aide informatique aux décideurs qui traitent des problèmes semi-structurés ». Dans ce sens, les SIAD impliquent l’utilisation d’ordinateurs pour :

− Assister les décideurs dans leur processus de décision dans 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é.

Sprague et Carlson [Sprague et Carlson, 1982] ont donné une définition très proche de celle proposée par Keen et Scott-Morton [Keen et Scott-Morton, 1978] : « Les SIAD peuvent être caractérisés comme des systèmes informatisés, interactifs, qui aident les décideurs en utilisant des données et des modèles pour résoudre des problèmes mal structurés ». leur définition repose sur les mots « données » et « modèles » qui fondent l’architecture des SIAD proposée par les mêmes auteurs.

D’une manière plus précise, Turban [Turban, 1995] définit un système d’aide à la décision comme un système d’information automatisé interactif, flexible, adaptable et


Page 27

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 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 de la prise de décision et inclure une base de connaissances.

3.2. Structure d’un Système Interactif d’Aide à la Décision (SIAD)

De la même manière que les définitions varient en fonction des auteurs, il n’existe pas d’architecture standard pour un SIAD. Chaque auteur reprend sous le terme de SIAD un ensemble plus ou moins étendu de composants. En effet, plusieurs architectures pour la conception de SIAD ont été proposées. Sprague et Carlson [Sprague et Carlson, 1982] identifient trois composants fondamentaux d’un SIAD (Figure. 2.2 ) : l’interface homme-machine, un Système de Gestion de Bases de Données (SGBD) et un Système de Gestion de Bases de Modèles (SGBM).

FIG. 2.2— Structure d’un SIAD selon Sprague [Sprague et Carlson, 1982]

L’interface homme-machine est un composant essentiel du SIAD. Elle permet à l’utilisateur de dialoguer avec les différents composants du système.

Le système de Gestion de Base de Données (SGBD) assure la fonction de mémoire ; il stocke non seulement les données, de façon permanente ou temporaire, mais il gère également l’enregistrement de données volatiles ainsi que l’effacement de ces données selon le souhait de l’utilisateur.


Page 28

Le Système de Gestion de Base de Modèles (SGBM) contient l’ensemble des modèles et des procédures de calcul utilisé dans les différents traitements standards des données mis à disposition de l’utilisateur.

Cependant, cette structure n’est pas suffisante pour caractériser un SIAD et le différencier des systèmes d’information classiques. En se basant sur les diverses architectures existantes, Marakas [Marakas, 2003] propose une architecture générale faite de 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. (Figure. 2.3)

FIG. 2.3— Structure d’un SIAD basé sur la connaissance selon Marakas [Marakas, 2003]

Un Système de Gestion de Base de Données (SGBD) ainsi que la base de données associée qui stocke, organise, trie et remonte les données pertinentes pour un contexte particulier de décision ;

Un système de gestion de base de Modèles (SGBM) ainsi que la base de modèles associée qui 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 de Gestion de Base de Connaissances (SGBC) qui remplit les tâches relatives à la reconnaissance de problèmes et à la génération de solutions finales ou intermédiaires aussi bien que des fonctions relatives à la gestion du processus de résolution de problèmes.

Interface utilisateur qui est un élément clé des fonctionnalités du système global. Par l’intermédiaire des interfaces gérées par ce module, le décideur accède aux données et


Page 29

aux fonctions de calcul, et le système utilise le même système vecteur pour lui communiquer le résultat des manipulations qu’il a effectuées.

Un utilisateur qui fait partie intégrante du processus de résolution de problème.

4. Informatique décisionnelle

Les systèmes décisionnels sont dédiés au management de l’entreprise pour l’aider au pilotage de l’activité, et sont indirectement opérationnels car n’offrant que rarement le moyen d’appliquer les décisions. Ils constituent une synthèse d’informations opérationnelles, internes ou externes, choisies pour leur pertinence et leur transversalité fonctionnelle, et sont basés sur des structures particulières de stockages volumineux (Data Warehouse, bases OLAP). Le principal intérêt d’un système décisionnel est d’offrir au décideur une vision transversale de l’entreprise intégrant toutes ses dimensions.

L’intégration de ces outils décisionnels dans un SIAD a pour objectif de permettre l’établissement de consolidations et de rapprochements non prédéfinis entre des données, essentiellement à des fins de prise de décision. Ce sont donc des outils d’interrogation de données et de restitution des résultats.

Deux fonctions principales sont destinées aux outils décisionnels [Goglin, 2001] :

1. Collecter et stocker : Data Warehouse, Datamart, OLAP, Dataweb 2. Extraire et presenter: Datamining.

4.1. Le Data Warehouse

Le DataWarehouse est actuellement, non seulement une réalité au sein des grandes entreprises, mais aussi un marché pour un nombre croissant d’acteurs : intégrateurs, éditeurs de SGBD ou d’outils spécialisés.

Un DataWarehouse est un entrepôt de données. Il s’agit d’un stockage intermédiaire des données issues des applications dans lesquelles les utilisateurs puissent avec des outils d’analyse. Le DataWarehouse permet au décideur de travailler dans un environnement informationnel, référencé, homogène et historié. Cette technique l’affranchit des problèmes liés à l’hétérogénéité des systèmes informatiques et à l’hétérogénéité des différentes définitions de données issues de l’historique de l’organisation.

Un DataWarehouse est une collection de données thématiques, intégrées, non volatiles et historiées organisées pour la prise de décision.


Page 30

4.2. Datamart

Un Datamart est un magasin de données. Il s’agit d’une solution départementale d’entrepôt de données (Datawarehouse) supportant une partie de données et fonctions de l’entreprise. C’est un sous-ensemble d’un Datawarehouse qui ne contient que les données d’un métier de l’entreprise alors qu’un Datawarehouse contient toute les données décisionnelles de l’entreprise pour tous les métiers. L’avantage de la mise en œuvre d’un tel outil est plus aisé vu sa portée et son étendue réduites dans l’organisation. La difficulté reste le coût de développement d’une ontologie ad hoc pour chaque domaine défini.

4.3. OLAP (On Line Analytical Processing)

Traitement analytique en ligne, c’est la technologie qui permet de produire des synthèses descriptives en ligne (ou vues) des données contenues dans les grosses bases et les Datawarehouses. Cette technologie permet à l’utilisateur, par la production de tableaux multidimensionnels intermédiaires, de construire par sélection, les séries chronologiques ou les tableaux croisés dont il a besoin. OLAP repose sur une structure de données spécialement adaptée aux extractions et aux croisement : hypercube (ou cube). Un hypercube est une construction intellectuelle qui rassemble les données en plusieurs axes appelés « dimensions ». après avoir été extrait depuis Datawarehouse, un hypercube permet de croiser et d’extraire des données de manière interactive suivant des critères qui n’avaient pas été imaginés. Le contenu de ces hypercubes doit être défini à priori, à partir de l’analyse des besoins, de sorte qu’ils satisfassent aux mieux les besoins des utilisateurs.

4.4. DataWeb

Actuellement, on assiste au développement d’un nouveau concept qui permet de fusionner le DataWarehouse et le Web : il s’agit du DataWeb. Le DataWeb désigne le support d’applications décisionnelles sur le web. De manière plus générale, c’est l’idée sous-jacente d’un accès à une base de données universelle, quelle que soit la plate-forme d’hébergement, de localisation (interne / externe, internet) ou le format des données (numérique, alphanumérique, HTML, images,…). Il n’est pas récent d’affirmer qu’il est essentiel d’avoir accès aux données internes à l’entreprise, mais aussi aux données externes qui peuvent provenir par exemple de l’internet. Un des avantages du DataWeb est de faciliter l’obtention des informations externes de l’entreprise.

4.5. Datamining

Le terme de Datamining signifie littéralement forage de données. Comme dans tout forage, son but est de pouvoir extraire un élément : la connaissance. Ses concepts s’appuient sur le constat qu’il existe au sein de chaque entreprise des informations cachées dans le gisement de données. Ils permettent, grâce à un certain nombre de techniques spécifiques de faire apparaître des connaissances.


Page 31

5. Classification des Systèmes Interactifs d’Aide à la Décision (SIAD)

La taxonomie des systèmes d’aide à la décision sont perçus selon différents niveaux :

5.1. Classification au niveau utilisateur

Hattenschwiller [Hattenschwiller, 1998] distingue les SIAD coopératifs, actifs et passifs :

Un SIAD passif est un système qui aide le processus décisionnel mais qui ne peut pas apporter des solutions ou des suggestions de décisions explicites.

Un SIAD actif peut apporter de telles solutions ou suggestions de décisions.

Un SIAD coopératif permet au décideur (ou son conseiller) de modifier, de compléter ou de données les suggestions de décisions fournies par le système avant de les renvoyer au système pour validation. Le système améliore aussi, complète et affine les suggestions du décideur et les kui renvoie pour validation. Le processus entier recommence alors à nouveau jusqu’à ce qu’une solution consolidée soit générée.

5.2. Classification au niveau conceptuel

Power [Power, 2002] propose un cadre étendu se focalisant sur une dimension importante avec cinq types génériques de systèmes d’aide à la décision :

Un SIAD guidé par les données (Data-Driven DSS) ou bien 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 guidé par les modèles (Model-Driven DSS) ou bien un SIAD orienté modèles 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.

Un SIAD guidé par les documents (Document-Driven DSS) ou bien 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 guidé par les communications (Communications-Driven DSS) ou bien un SIAD orienté communications supporte plus qu’une personne travaillant sur une tâche partagée.


Page 32

Dans cette dernière catégorie, on retrouve les systèmes d’aide à la décision de groupe (appelés GDSS) 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.

5.3. Classification au niveau système

Power [Power, 1997] distingue entre des SIAD d’entreprise et ceux de bureau :

Un SIAD d’entreprise est relié à de large 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.

Lévine et Pomerol [Lévine, 1989] distinguent quatre types de systèmes décisionnels :

EIS (Executive Information System) : ce sont des outils de navigation et de visualisation des données de type tableaux de bord, permettant aux différents niveaux de management d’accéder aux informations essentielles de leur organisation et de les présenter de façon élaborée. Ces outils sont dotés d’une interface graphique très conviviale et très esthétique.

ESS (Executive Support System) : l’ESS va au-delà de l’EIS en incluant des outils de communication, d’analyse et d’intelligence. Afin de mieux distinguer les deux systèmes, nous disons que l’EIS est un outil permettant au décideur de se focaliser sur des données critiques pour obtenir une appréciation de l’organisation tandis que l’ESS doit permettre l’analyse de ces données grâce aux modèles d’analyse.

DSS (Decision Support System) : ce sont des systèmes interactifs et flexibles, spécifiquement développés pour aider les décideurs à exploiter les données et les modèles, pour rechercher des solutions aux problèmes non structurés et analyser les effets d’éventuels changement de l’environnement sur l’organisation.

PSS (Planning Support System) : ils permettent une analyse de faisabilité des procédures ou des décisions retenues (c’est-à-dire fournir aux décideurs une assistance intelligente).

Si nous revenons au modèle de Simon, la phase Intelligence correspond à l’EIS et l’ESS : le premier permet au décideur de se focaliser sur des données critiques (par exemple : la chute des actions en bourse durant une certaine période) et le second de faire une analyse pour une appréciation future de l’organisation. Les autres étapes du modèle peuvent être assurées selon Turban [Turban, 1998] par le DSS qui peut faire de la planification


Page 33

stratégique et offre la possibilité d’analyser les effets d’éventuels changements sur l’organisation (en effectuant des simulations).

6. Les systèmes Interactifs d’aide à la décision à base de Web (Web-based DSS)

Quand une structure d’un SIAD est construite à la base d’une technologie Web ou un accès à l’internet, il semble plus approprié d’appeler le système SIAD un SIAD à base de Web. À base de Web devrait se traduire par le fait que l’application entière est mise en œuvre en utilisant des technologies Web, y compris un serveur Web, HTML, CGI, PHP et peut-être un produit de base de données comme MySQL ou Oracle.

Les technologies web peuvent être utilisées pour mettre en œuvre toute catégorie de SIAD y compris les SIAD guidés par les communications, SIAD guidés par les données, SIAD guidés par les documents, SIAD guidés par la connaissance et les SIAD guidés par le modèle. À un moment donné, la plupart des systèmes étiquetés “SIAD à base de Web” ont été reliés à un entrepôt de données, mais ce n’est certainement plus le cas. Une simulation d’aide à la décision guidée par le modèle développée en Java peut être développée via le Web et peut utiliser ainsi un grand entrepôt de texte HTML/XML qui fait partie de SIAD guidé par les documents. Avec un SIAD à base de Web, aucun composant de l’application du système d’aide à la décision ne doit figurer sur l’ordinateur de client. Un navigateur Web et une connexion à Internet offrent les fonctionnalités d’aide à la décision à l’utilisateur. Kuljis et Paul [Kuljis et Paul, 2001] et le Miller et d’autres. [54] passent en revue sur le Web des études de simulation et de développements.

6.1. Définitions d’un SIAD à base de Web (Web-based DSS)

Les technologies Web sont utilisées pour améliorer la capacité de système d’aide à la décision par des modèles de décision, le traitement d’analyse en ligne (OLAP) et les outils d’extraction de données qui permettent la publication normalisée et le partage de ressources de décision sur internet. Dans un système d’aide à la décision à base de Web, tous les processus décisionnels impliquant des opérations sont exécutés sur un serveur réseau d’ordre n afin de bénéficier la distribution de la prise de décision et l’indépendance de la plate forme, des périodes d’apprentissage plus courtes pour des utilisateurs déjà familiers avec les outils web et la navigation web, de la diffusion des logiciels à bas prix, la mise à jour des logiciels et la réutilisabilité de modules de décision et d’information sur internet grâce à une panoplie de protocoles normalisés. [Huaiqing et al, 2002]

Définition 1

Selon [Friedman, 2005], l’importance d’utiliser les SIAD à base de Web résulte de l’utilisation croissante de l’information disponible qui devrait être identifiée, contrôlée et


Page 34

accédée à distance en utilisant les outils à base de Web pour soutenir la réutilisabilité des modules de décision intégrés. De tels systèmes aident les entreprises globales à gérer et améliorer les processus de décision, le contrôle des processus, le service client, et rendre la nouvelle conception plus flexible.

En utilisant les SIAD à base de Web, les décideurs peuvent partager des modules de prise de décision ouverts sur internet en utilisant des protocoles normalisés tels que le HTTP, en un format normalisé comme XML ou DAML.

Définition 2

D’après [Shaw et al, 2002], les systèmes à base de Web sont considérés comme des “plates formes de choix” pour fournir l’aide à la décision tout en tenant compte de nombreuses considérations techniques, économiques et sociales. La migration vers les SIAD à base de Web, dénote un changement des générateurs des SIAD (ce qui permet aux utilisateurs de développer des applications spécifiques caractérisées par un déploiement limité, une rigidité à intégrer des orientations au travers des applications qui soulignent la réutilisation des applications et des composants. En déployant les capacités de Web, les bases de connaissances multiples et les techniques de traitement de la connaissance peuvent être utilisées. La conception des systèmes interactifs d’aide à la décision a été affectée par la disponibilité d’une large gamme d’outils du web, des techniques et des technologies. L’utilisation des outils de Web a permis de remodeler la description des relations entre les composants de l’information et les modules de décision de telle façon que la conception physique et la logique du SIAD, se trouvent affectées. En conséquence, l’architecture fondamentale du SIAD à base de Web est passée des architectures centralisées, aux systèmes client-serveur, au web et aux systèmes répartis basés sur la technologie de réseau qui permettent l’intégration de grandes quantités de données et des outils d’aide à la décision provenant des sources hétérogènes pour la disposition (fourniture) d’informations à valeur ajoutée en utilisant la découverte de connaissance et les outils d’extraction de données.

Définition 3

Les systèmes d’aide à la décision à base de web sont utilisés par des organisations comme outils aides à la décision pour les employés aussi bien que les clients. Il s’agit d’utiliser les siad à base de Web comme assistants pour aider les clients à configurer le produit et le service selon leurs besoins. Ce sont des SIAD grand public.

Ces systèmes permettent aux différents clients de concevoir leurs propres produits par le choix d’un menu d’attributs, des composants, des prix et des options de livraison. Par exemple, sur les sites web de la plupart des producteurs des ordinateurs de bureau (www.dell.com, www.compaq.com, and www.ibm.com), les individus peuvent


Page 35

commencer par une configuration de base définie par un modèle et une vitesse de processeur, et continuer ensuite à spécifier la configuration complète avec leur choix de taille de disque dur, mémoire et accessoires comme les CD-ROMs, moniteurs et imprimantes. Des cas semblables peuvent être trouvés dans : (1) l’industrie d’habillement ( www.landsend .com , www.blair.com ,and www.wedding channel.com ), qui permet à un utilisateur un modèle virtuel pour concevoir son costume, (2) dans l’industrie de finances ( www.calvertgroup.com), qui permet à l’utilisateur d’essayer la retraite différente sauvant (économisant) des plans, et (3) dans l’industrie de jouets (www.vermontteddybear. com ), où les enfants peuvent faire sur mesure les ours en peluche, ils désirent de la couleur, la taille et le type du manteau.

6.2. Les travaux de recherche récents dans le SIAD à base de Web (Web-based DSS)

Cette section présente un état de l’art sur les SIAD à base de Web (Web-based DSS), organisée autour de deux principaux points : (6.2.1) architectures et technologies et (6.2.2) applications et réalisations.Un certain nombre d’articles ont passé en revue des matières plus spécifiques liées au SIAD à base de Web.Par exemple, Kuljis et Paul [Kuljis et Paul, 2001] ont passé en revue la simulation à base de Web et le Kersten et le Noronba [Kersten et le Noronba, 1999] ont passé en revue l’aide à la négociation à base de Web.

6.2.1. Architectures et technologies

Un certain nombre d’articles discutent les issues architecturales, les cadres, la rentabilité, et d’autres matières de technologie qui sont généralement applicables au SIAD à base de Web.

Bharati et Chaudhury [Bharati et Chaudhury, 2004 ] ont entrepris une étude empirique pour étudier la satisfaction de clients avec des systèmes interactifs d’aide à la décision à base de Web. Dans leur modèle conceptuel, ils ont proposé trois variables indépendantes (qualité de système, qualité de l’information, et présentation de l’information) qui ont influencé la satisfaction des utilisateurs (variable dépendante). Ils ont montré que la qualité de système et la qualité de l’information sont fortement corrélées avec la satisfaction des utilisateurs, mais la présentation de l’information n’a pas d’impact significatif sur la satisfaction des utilisateurs.

Iyer et al. [Iyer et al, 2005] se sont intéressés à la gestion du modèle pour l’aide à la décision dans un environnement de calcul où les données et les modèles d’entreprise sont distribués. Ils ont défini des couches de connaissances pour la gestion du modèle et ont proposé une architecture préliminaire pour un environnement virtuel d’affaires (VBE).

Guntzer et al. [Guntzer et al, 2007] ont proposé des modèles de service structurés qui emploient une variante de modèles structurés. Cette approche proposée peut aider les


Page 36

utilisateurs à trouver des ressources d’information disponibles comme un service en ligne dans un Intranet.

Zhang et Goddard [Zhang et Goddard, 2007] ont appliqué des architectures de logiciel à la conception des SIAD à base de Web. Une architecture multi-couches de logiciel a été proposée pour aider les développeurs à concevoir et mettre en application un SIAD dans un environnement distribué ; une telle architecture peut fournir une vue formelle et hiérarchique du SIAD qui aide la conception d’un SIAD à base de Web. En outre, les auteurs ont présenté un cadre à base de composant, 3CoFramework, pour aider l’exécution du SIAD.

Mitra et Valente [Mitra et Valente, 2007] ont fournit un aperçu sur l’optimisation à base de Web pour les SIAD guidés par les modèles. Leur étude a porté sur deux paradigmes (ASP et e-Services), et ont développé un fournisseur de service d’optimisation (OSP) " et le "WEBPOT " et ont trouvé de nouveaux avantages permis par l’implémentation du e-Service. Certains de ces avantages incluent la découverte de service, la gestion de service, et la gestion de qualité.

Pour récapituler, ces études discutent les métadonnées, la gestion du modèle, et la rentabilité pour le SIAD à base de Web. En outre, Mitra et Valente ont démontré que le SIAD à base de Web peut efficacement incorporer des modèles et des outils d’optimisation. Ces efforts d’aborder les questions fondamentales dans le calcul à base de Web sont les pierres angulaires essentielles pour l’usage pratique de l’aide à la décision à base de Web. La recherche précédente indique que (a) les utilisateurs de Web ont besoin de détaillées des informations sur le SIAD pour organiser et comprendre le contenu disponible, (b) les systèmes devrait être conçu pour inclure les constructions et les objets façonnés qui aident la livraison d’information de haute qualité, et (c) les nouvelles approches pour la gestion du modèle sont nécessaires pour faciliter le stockage, la recherche, la récupération, l’assortiment, et la composition d’une bibliothèque des modèles de décision. Les avances de recherches dans ces secteurs seront critiques au développement des orientations et des possibilités pour établir un SIAD à base de Web efficace.

6.2.2. Applications et réalisations

Beaucoup de chercheurs et fournisseurs se sont intéressés à des études de cas basées sur les SIAD à base de Web et le développement des applications prototypes. Kohli et al. [Kohli et al, 2001] ont rapporté une étude de cas d’un SIAD à base de Web pour la gestion d’hôpital appelé système de Physician Profiling (PPS). Le PPS est un système de gestion de rapport de client (CRM) pour la gestion de rapport de médecin. Les auteurs ont démontré le développement du PPS et ont présenté une analyse coûts-avantages du projet.


Page 37

Ngai et Wat [Ngai et Wat, 2005] ont développé et mis en application un SIAD à base de Web qui a employé un modèle basé sur la théorie des ensembles brouillée pour procéder à l’analyse de risque pour le développement du e-commerce. Les chefs de projet aidés par le prototype identifient, analysent, et donnent la priorité au risque impliqué dans un développement d’e-commerce. Dans leur prototype, le web browser sert de composant d’interface utilisateur et l’ensemble des modèles et des bases de données ont été hébergés par le serveur. Dong et al. [Dong et al, 2004] ont développé un cadre de SIAD à base de Web pour le choix de brochure. Ils ont employé le traitement analytique en ligne (OLAP) et une machine virtuelle parallèle (PVM) pour améliorer l’exécution globale de leur prototype du système de choix de brochure à base de Web (WPSS). Puisque le web browser est le composant d’interface utilisateur et le serveur contient tous les modèles et des bases de données, le prototype permet aux ordinateurs multiples de manipuler un problème à grande échelle d’aide à la décision efficacement.

[Sundarraj, 2004] a identifié les questions clés dans les contrats d’entretien de gestion et a développé un prototype qui peut soutenir le procédé de la planification d’un directeur. L’avantage le plus important du prototype est étalonnage de la gestion des contrats d’entretien parce que le système à base de Web permet à beaucoup de directeurs d’accéder et employer à un système simple.

[Ray, 2007] a rapporté une étude de cas qui démontre l’exécution des technologies d’aide à la décision à base de Web. Il a discuté une application spécifique développée pour le département du Delaware du transport (De lDOT). Le système a utilisé un réseau à base d’outils d’optimisation et des systèmes interactifs d’aide à la décision spatiaux pour améliorer la gestion des mouvements de véhicules à poids excessifs.

Delen et al. [Delen et al, 2007] ont développé un SIAD à base de Web, appelé le gourou de Movie Forecast, pour aider des décideurs dans l’industrie du cinéma. Pour prévoir des reçus de caisse, le système proposé adopte un méta-modèle de fusion de l’information qui emploie le rendement d’un réseau neurologique, des arbres de décision, d’une régression logistique ordinale, et d’une analyse discriminante. Leur évaluation exploratoire du système a indiqué que les utilisateurs ont été satisfaits de sa rentabilité en termes de plénitude de qualité de l’information, de qualité de système, et d’utilisation (Cf, [Davis, 1989] [DeLone et McLean, 1992]).


Page 38

7. Technologies Web

7.1. Définitions

7.1.1. Internet

INTERNET (INTERnational NETwork) est un réseau télématique international d’origine américaine. Constituant à ce jour le plus grand réseau du monde, Internet est accessible aux professionnels comme aux particuliers.

Aujourd’hui, Internet permet à tout individu d’accéder à une multitude de données se présentant sous divers formats : textes, bases de données, images, sons (MP3), vidéos, etc. Il offre de nombreux services aux professionnels, comme aux particuliers : réserver un hôtel en Asie, installer un encart publicitaire aux États-Unis, consulter les catalogues de constructeurs automobiles, passer des commandes, acheter ou vendre aux enchères un bien, visiter des musées, obtenir des informations officielles, etc.

Les informations présentées sur le réseau Internet sont, le plus souvent, publiées dans des pages au format HTML (HyperText Markup Language). Ce format permet l’introduction dans le texte de liens à d’autres pages ou d’autres sites, appelés liens hypertextes. Ces liens permettent de naviguer dans le réseau Internet. Un autre format tend à se développer sur Internet : le format XML (eXtended Markup Language). Outre les possibilités offertes par le format HTML, le langage XML permet de mieux structurer l’information et de séparer clairement la forme et le contenu.

7.1.1.1. Les protocoles d’Internet

Internet sert de support à plusieurs protocoles et services : FTP (File Transfer Protocol) pour le transfert de fichiers (téléchargement), SMTP (Simple Mail Transfer Protocol) pour la communication électronique avec d’autres personnes (e-mail), NNTP (Network News Transfer Protocol) pour l’envoi et la réception de courriers publics, HTTP (HyperText Transfer Protocol) pour le protocole de transmission hypertexte, Web pour la publication d’informations, etc.

Pour faire fonctionner ce vaste réseau, Internet met en œuvre des protocoles de communication. Les deux protocoles de base sont TCP (Transmission Control Protocol) et IP (Internet Protocol). Ils sont référencés sous le vocable TCP/IP. TCP récupère les informations à transmettre, IP les transforme en paquets et les délivre à la couche chargée du transport (composant électronique).

7.1.2. World Wide Web

World Wide Web (WWW) est l’interface la plus communément utilisée sur le réseau télématique Internet. Le World Wide Web, que l’on pourrait traduire en français par « toile d’araignée mondiale », a permis d’ouvrir le réseau Internet au grand public en facilitant la consultation des sites. Il offre aux utilisateurs la possibilité de consulter en ligne une vaste


Page 39

étendue d’informations, présentées sous forme d’archives de magazines, de pages de livres de bibliothèques publiques et universitaires, de documentation à usage professionnel, etc.

Le World Wide Web (WWW ou W 3), appelé plus couramment le Web, fut développé en 1991 par l’informaticien britannique Timothy Berners-Lee, chercheur du Laboratoire européen de physique des particules (CERN) à Genève. Au départ, cette interface avait pour but de favoriser le partage d’informations entre des équipes de chercheurs dispersées dans le monde entier. Mais rapidement, le Web fit office de plate-forme internationale pour le développement de logiciels apparentés, tandis que le nombre d’ordinateurs et d’utilisateurs connectés s’accrut considérablement. Aujourd’hui, le rôle principal du Web est d’être la fenêtre d’Internet. Son développement est géré par le consortium WWW situé au Massachusetts Institute of Technology (MIT).

7.2. Termes rattachés au Web

La terminologie propre au Web contient plusieurs dizaines de termes. Parmi eux, on peut citer :

7.2.1. Ressource du Web

Une ressource du World Wide Web est une entité informatique (texte, image, boîte aux lettres électronique, etc.) accessible indépendamment d’autres ressources. Une ressource en accès public est librement accessible depuis Internet. Une ressource locale est présente sur l’ordinateur utilisé, par opposition à une ressource distante (ou en ligne) qui est accessible à travers un réseau.

7.2.2. HTTP

HTTP (HyperText Transfer Protocol) est le protocole de communication communément utilisé pour transférer les ressources du Web. HTTPS est la variante sécurisée de ce protocole.

7.2.3. HTML

HTML (HyperText Markup Language) est un langage informatique de marquage hypertexte qui permet de décrire le contenu d’un document (titres, paragraphes, disposition des images, etc.), constituant le langage de base du Web (World Wide Web).

7.2.4. Document HTML

Un document HTML est un document écrit avec le langage HTML. Les documents HTML sont les ressources les plus consultées du Web.

7.2.5. Serveur Web

Un serveur Web est un hôte sur lequel fonctionne un serveur HTTP (ou serveur Web).


Page 40

7.2.6. Navigateur Web

Un navigateur Web est un logiciel client HTTP conçu pour accéder aux ressources du Web. Sa fonction de base est de permettre la consultation des documents HTML disponibles sur les serveurs HTTP, exemple Internet Explorer, Netscape,…

7.2.7. Page Web

Une page Web est un document destiné à être consulté avec un navigateur Web. Une page Web est toujours constituée d’une ressource centrale (généralement un document HTML).

7.2.8. Editeur HTML

Un éditeur HTML (ou éditeur Web) est un logiciel conçu pour faciliter l’écriture de documents HTML et de pages Web en général.

7.2.9. Site Web

Un site Web est un ensemble de pages Web et d’éventuelles autres ressources, liées dans une structure cohérente, publiées par un propriétaire (une entreprise, une administration, une association, un particulier, etc.) et hébergées sur un ou plusieurs serveurs Web.

7.2.10. Adresse Web

Une adresse Web est une URL de page Web, généralement écrite sous une forme simplifiée limitée à un nom d’hôte. Une adresse de site Web est en fait l’adresse d’une page du site prévue pour accueillir les visiteurs.

7.2.11. Hébergeur Web

Un hébergeur Web est une entreprise de services informatiques hébergeant (mettant en ligne) sur ses serveurs Web les ressources constituant les sites Web de ses clients.

7.2.12. Agence Web

Une agence Web est une entreprise de services informatiques réalisant des sites Web pour ses clients.

7.2.13. Annuaire Web

Un annuaire Web est un site Web répertoriant des sites Web.

7.2.14. Portail Web

Un portail Web est un site Web tentant de regrouper la plus large palette d’informations et de services possibles dans un site Web. Certains portails sont thématiques.


Page 41

7.2.15. Service Web

Un service Web est une technologie client-serveur basée sur les protocoles du Web.

7.3. Les bases du Web

Le Web fait appel à un certain nombre de concepts de base. Nous verrons les trois plus importants dans cette première partie.

7.3.1. Architecture Client-Serveur

Le WWW s’appuie sur la notion d’architecture Client-Serveur. Un serveur est une machine en général assez puissante qui fournit un ou plusieurs services (accès à des sources de données, applications…). Pour fournir ces services, elle fait tourner en permanence des programmes que l’on appelle aussi des serveurs en l’occurrence ce sont des serveurs Web ou serveurs HTTP. De l’autre coté les utilisateurs font tourner sur leur machine (machine cliente) un programme client qui, comme son nom l’indique va être demandeur de services, en l’occurrence ce client est un navigateur Web qui va demander des pages Web à un serveur Web. Le dialogue entre le client et le serveur se compose donc de requêtes émises par le client et de réponses données par le serveur.

FIG. 2.4— Technologie Client-Serveur

Le client est couramment appelé un navigateur (ou encore browser, fureteur ou butineur). Les navigateurs les plus connus étant Netscape, Internet Explorer, Lynx, Mosaic, Opera, Kfm. Les plus courant acceptent des extensions (Plug-In) permettant d’étendre leurs capacités (lire des vidéo, recevoir du son ou des films en flot continu, …). Ils connaissent aussi fréquemment des langages évolués (JAVA, Javascript, VRLM…) et permettent d’élargir le champ des possibilités de l’utilisation des pages Web. Les navigateurs sont des logiciels soigneusement étudiés pour faciliter et assister la navigation sur le Web. Ils proposent en standard des fonctionnalités d’historique pour revenir sur ses pas, une gestion


Page 42

des signets pour pouvoir garder ses pages préférées bien organisées et facilement accessibles, et plusieurs autres fonctions utilitaires et outils d’assistance.

Un serveur est une machine qui est capable de servir d’autres machines en fonction de leur requête, ces dernières sont appelées clients. Pour cela elle doit toujours être connectée au réseau et exécuter le démon (daemon) correspondant au service rendu. On appelle démon un programme qui tourne en tâche de fond sur une machine et le cas échéant répond à des requêtes qui lui sont adressées ou déclenche des actions en réponse à des événements ou un planning. Sur le Web les documents s’échangent selon le protocole HTTP (HyperText Transfer Protocol) et le démon qui se charge de répondre aux requêtes des autres machines se nomme HTTPD (HyperText Transfer Protocol Daemon). De la même façon un serveur offrant des fichiers via FTP est une machine sur laquelle tourne un serveur FTP encore appelé démon FTPD (File Transfer Protocol Daemon), de même pour l’e-mail, etc...

FIG. 2.5— Architecture Client-Serveur

FIG. 2.6— Architecture Client-Serveur du Web

Il y a deux cas : soit l’utilisateur cherche à visualiser une page disponible sur sa machine auquel cas le navigateur obtient le fichier par simple lecture directe sur un disque de la machine sur laquelle il s’exécute, soit l’utilisateur souhaite accéder à une page disponible sur une machine distante auquel cas le navigateur doit se connecter au serveur publiant cette page à travers le réseau. On se rappelle qu’Internet est l’infrastructure internet (interconnected networks = réseaux interconnectés) d’un réseau informatique mondial. Ce

Serveur Client

Requête

Réponse

TCP/IP

Navig.

Serveur Web

Navig.

Requête

Réponse

Pages Web


Page 43

réseau mondial se compose de réseaux d’ordinateurs locaux interconnectés et dont les échanges suivent les protocoles TCP, UDP et IP (Transmission Control Protocol and Internet Protocol) chaque ordinateur connecté étant adressé par un numéro IP ou un nom symbolique / nom de domaine. L’architecture client-serveur du Web repose sur ces bases en ce sens que le programme client (navigateur) se connecte au programme serveur (serveur Web) grâce aux protocoles TCP/IP et ainsi met en place une connexion bidirectionnelle fiable qu’il va utiliser pour obtenir les informations souhaitées (document, image et autres fichiers).

7.3.2. URL

Pour accéder à une page web il faut d’abord pouvoir décrire où elle se trouve. Pour repérer un document, un fichier, une source de données … il faut développé la notation URL (Universal/Uniform Resource Locator). Un URL peut désigner un serveur ftp, un fichier sur votre disque, une image, une adresse courrier, et bien sûr une page Web publiée par un serveur http, c’est-à-dire un serveur de Web. En particulier, dans ce dernier cas l’URL contient le nom du protocole d’accès au fichier (HTTP, SHTTP), le nom du serveur (adresse IP ou nom symbolique), le chemin d’accès au fichier et bien sûr le nom du fichier :

<Protocole> ://<nom serveur>/<chemin> Exemple:

http://www-op.inria.fr/acacia/personnel/Fabien.Gandon/index.html

7.3.3. Hypertexte et Topologie du Web

Le World Wide Web est un vaste ensemble de sources d’informations accessibles à travers le réseau Internet. Il est maintenant utilisé par tout le monde pour mettre en ligne (i.e. rendre accessible sur le Web via Internet) des documents et des services de tous horizons. L’information est présentée essentiellement sous forme de texte et d’images, mais le son, la vidéo… bref le multimédia étant en pleine explosion on commence à employer de plus en plus souvent le terme hypermédia au lieu d’hypertexte. On qualifie d’Hypertexte (terme et notion inventés par Ted Nelson en 1960) un document essentiellement textuel, dynamique, capable de changer et de réagir en fonction de certains événements comme par exemple un clic à la souris. Un tel document offre une très grande convivialité et la tendance étant à élargir cette technique à d’autres médias (image, video, animations…) on parle maintenant d’hypermédia. Le langage permettant de décrire les pages Web est le HTML (Hyper Text Markup Langage). Ce langage à balise permet de doter certains mots, ou images d’une propriété d’hyperlien ou plus simplement de lien qui est constitué d’une adresse URL que vous atteindrez en cliquant dessus.


Page 44

FIG. 2.7— Topologie du Web

7.4. La technologie du Web

Parmis les technologies Web, on peut citer :

7.4.1. HTTP

Le protocole de base du World Wide Web est HTTP (HyperText Transfer Protocol) qui peut être utilisé pour n’importe quelle application client-serveur impliquant de l’hypertexte. Ce protocole est capable d’assurer le transfert de texte, hypertexte, fichiers audio, images ou tout autre type d’information pouvant se mettre sous la forme d’un fichier.

Le scénario de dialogue classique entre un navigateur et un serveur Web est le suivant. Le navigateur Web client établit une connexion TCP avec le serveur Web qui contient la page qui l’intéresse. Une fois la connexion établie, le client émet une requête HTTP contenant une commande, une URL, et parfois d’autres informations. Lorsque le serveur Web reçoit la requête il essaie d’exécuter la commande qu’elle contient. Il retourne ensuite comme réponse le résultat obtenu qui peut être des données, un message d’erreur, et d’autres informations. Une fois que le client a reçu sa réponse la connexion est fermée et détruite. Voici par exemple une requête émise par un navigateur dont l’utilisateur est "Fabien Gandon" et demandant à ce que le document html "cv.html" lui soit envoyé s’il a été modifié depuis le 31 juillet 1999 à 12:30:00.


Page 45

7.4.2. HTML

Le langage HTML (HyperText Markup Language) est utilisé sur le système de partage de l’information mondial WWW (World Wide Web) depuis 1990. Ce langage se compose d’un ensemble d’annotations, appelées étiquettes ou balises, qui permettent de créer et formater un document hypertexte. Un fichier HTML est un fichier texte ce qui a l’avantage de le rendre facilement lisible sur n’importe quelle plate-forme/ordinateur. Les balises du HTML sont insérées dans le texte du document et guident son affichage. Le navigateur interprète les commandes HTML contenues dans le document et en déduit le format d’affichage du document.

HTML est le langage standard d’édition de pages hypertexte pour le Web. Il existe plusieurs versions les plus communes et les plus supportées sont les versions 2.0 et 3.2. La toute dernière étant la version 4. Une page Web peut être crée directement avec un simple éditeur de texte en tapant des commandes HTML ou en utilisant un éditeur de page Web qui très souvent vous permettra de créer votre document de façon très conviviale et générera pour vous le code HTML correspondant sans que vous ayez à connaître ce langage.

Comme dans tous les langages il y a un minimum d’informations à donner dans le fichier HTML. Le fichier HTML minimum ressemble à ceci : <HTML> <HEAD> <TITLE> Document bonjour </TITLE> </HEAD> <BODY> Bonjour. </BODY> </HTML>

Les balises <HTML> et </HTML> stipulent que ce fichier texte est formaté selon le langage HTML et délimitent le contenu à interpréter.

En-tête du document

Corps du document

Titre du document


Page 46

Les balises <HEAD> et </HEAD> viennent du mot HEADER (Entête) et délimitent l’en-tête du document contenant son titre et des informations sur son contenu.

Les balises <BODY> et </BODY> délimitent le corps du document contenant le texte, son formatage les objets et les liens qu’il inclut.

7.4.3. Feuilles de style CSS

Avec HTML vous définissez la structure fondamentale de vos pages Web, les éléments, les structures, les liens, les éléments référencés tels les graphiques, le multimédia etc... Mais HTML n’est en fait pas conçu pour donner de façon exacte comment un élément doit apparaître. Ainsi vous pouvez définir des titres en HTML en précisant qu’il s’agit d’un titre n°1. Mais vous ne pouvez pas décider en HTML dans quelle police et dans quelle taille ce titre doit être représenté. Le navigateur WWW prend cela en charge lors de l’affichage. Il utilise pour ce faire un mélange de réglages de base que peut entreprendre l’utilisateur et de représentations programmées de façon fixe d’éléments distincts HTML.

C’est ici que les Cascading Style Sheets (CSS) (feuilles de style en cascade) entrent en scène. Il s’agit d’un langage de programmation directement complémentaire qui fut développé spécialement pour le HTML. Il s’imbrique sans heurt dans le HTML et permet le formatage ad libitum d’éléments séparés HTML. À l’aide de feuilles de style CSS vous pouvez par exemple déterminer que tous les titres N° 1 aient une taille de 24 points et apparaissent dans la police Helvetica en couleur rouge avec un espacement de 16 points pour le texte qui suit et un encadrement supérieur d’une double ligne verte mais vous pouvez aussi bien établir pour un texte au choix que seul ce texte doit avoir une taille de 3 centimètres et une couleur de fond jaune. En outre, le langage de programmation CSS contient également des commandes pour placer des éléments au pixel près sur l’écran et pour d’autres systèmes de reproduction comme l’impression ou l’audio.

7.4.4. XML

Le langage XML (Extensible Markup Language) est un moyen de structurer l’information indépendant des plates-formes. Comme XML sépare le contenu d’un document de sa structure, il peut servir à échanger des données. Par exemple, XML peut servir à transférer des données entre les bases de données et des programmes Java. Comme contenu et structure sont séparés, des feuilles de style peuvent être appliquées pour afficher le même contenu dans différent formats comme PDF (Portable Document Format), HTML pour l’affichage dans un navigateur Web, etc.

7.4.5. JavaScript/DOM

JavaScript n’est pas directement une partie qui constitue HTML, mais un langage de programmation distinct. Ce langage a pourtant été créé spécialement pour mettre à la disposition des auteurs un outil grâce auquel les pages WWW se laissent optimiser.


Page 47

Les programmes en JavaScript sont notés directement dans le fichier HTML ou dans des fichiers séparés. ils sont interprétés en temps réel par le navigateur Web. Les navigateurs Web modernes possèdent à cet effet le logiciel d’interprétation correspondant.

DOM est l’acronyme de Document Object Model. C’est une spécification du W3C pour proposer une API qui permet de modéliser, de parcourir et de manipuler un document XML.

Le principal rôle de DOM est de fournir une représentation mémoire d’un document XML sous la forme d’un arbre d’objets et d’en permettre la manipulation (parcours, recherche et mise à jour).

A partir de cette représentation (le modèle), DOM propose de parcourir le document mais aussi de pouvoir le modifier. Ce dernier aspect est l’un des aspect les plus intéressant de DOM.

DOM est défini pour être independant du langage dans lequel il sera implémenté.

7.4.6. CGI et Perl

L’interface CGI (Common Gateway Interface - Interface générale de passerelle) est une possibilité de tenir à disposition des programmes ou des scripts pouvant être appelés à partir de fichiers HTML et qui peuvent créer eux même du code HTML pour l’envoyer à un navigateur Web. À la différence de JavaScript de tels scripts ou programmes ne sont pas exécutés après la transmission d’une page Web sur le navigateur de l’utilisateur mais avant que le navigateur ne reçoive des données transmises par le serveur. C’est pour cette raison que les scripts CGI ou les programmes CGI ne sont exécutables que lorsqu’une liaison HTTP est établie entre le navigateur Web et le serveur Web. CGI est domicilié du côté du serveur.

La plupart des programmes CGI d’aujourd’hui ne sont pourtant pas des programmes compilés mais ni plus ni moins que des scripts qui sont exécutés par l’interpréteur lorsqu’ils sont appelés. Le plus connu et plus populaire de ces interpréteurs est l’interpréteur Perl.

Perl est un langage de programmation qui représente un mélange entre les langages de programmation traditionnels comme C et les langages scripts comme les Shell scripts Unix. Perl est extrêmement puissant et l’interpréteur Perl est parfaitement au point. C’est pourquoi Perl a conquis les programmeurs dans d’innombrables domaines. Entre autres justement, le domaine de la programmation CGI. Pour cette raison, on ne peut entre-temps évoquer la programmation CGI, nommer Perl et les considèrer comme faisant partie d’un tout. Il est seulement important de savoir que l’association de CGI et de Perl n’est pas innée ou indispensable. CGI est en fin de compte une norme pour une interface de


Page 48

programmation que le logiciel serveur Web doit soutenir et que Perl est un langage script utilisable partout et qui de toutes façons est particulièrement bien adapté en raison de ses caractéristiques à la programmation CGI.

7.4.7. PHP

PHP est l’acronyme récursif pour Hypertext Preprocessor. C’est un langage interprété (un langage de script) exécuté du coté serveur (comme les scripts CGI, ASP, ...) et non du côté client. La syntaxe du langage PHP provient de celles du langage C, du Perl et de Java.

Ce langage a été conçu par Rasmus Lerdorf et est aujourd’hui exploité par la société ZEND. Il est aujourd’hui très à la mode dans le développement des applications web.

7.4.8. ASP

ASP signifie Active Server Pages (pages actives du serveur) et représente comme PHP une alternative à CGI/Perl. Chez ASP également il s’agit de créer des pages Web dynamiques du côté du serveur par exemple pour donner les résultats d’une recherche dans une base de données sous forme d’une liste HTML au navigateur appelant. De façon similaire à du code PHP, vous pouvez incorporer du code Script ASP directement en HTML - Des scripts séparés comme pour Perl et CGI, devant être sauvegardés dans des répertoires spéciaux, ne sont donc pas nécessaires. À la différence de PHP, ASP est davantage couplé au monde de Microsoft et de Windows. Il y a bien aussi ASP pour Linux et autres systèmes basés sur Unix et outre le serveur Web Microsoft, le serveur Apache et beaucoup d’autres sont soutenus. Pourtant l’intégration de ASP est optimisée pour des serveurs Web de Microsoft et c’est pour cela qu’il est utilisé surtout sous Windows NT.

ASP n’est à la différence de PHP qu’un "environnement", et non pas un langage script distinct. Comme langages scripts ce sont avant tout les langages propres à Microsoft JScript et VBScript (Script Visual Basic) qui sont prévus. Mais même l’utilisation de Perl pour ASP est possible - et l’utilisation universelle de Perl est mise ici encore en évidence qui à l’inverse de ASP par exemple n’est pas lié à un environnement particulier. VBScript est de toutes façon le langage script standard pour ASP.

Le principe ASP est le même que celui de PHP. En raison de certaines conventions, le serveur Web reconnaît qu’un fichier HTML est un fichier ASP. Le serveur avec environnement ASP intégré, exécute alors le code Script contenu dans le fichier et envoie à la fin le code HTML complet qui en résulte au navigateur appelant.

7.4.9. ActiveX

ActiveX est une technologie introduite par Microsoft pour du code programme exécutable sur les pages Web et a l’ambition d’être une alternative ou une concurrence


Page 49

à Java. ActiveX est un terme regroupant plusieurs composantes logicielles. Toutes ces composantes sont basées sur ce qu’on appelle le Component Object Model (COM). ActiveX n’est pourtant pas un standard Internet au sens habituel du terme, mais la tentative de mettre à profit les propriétés spécifiques au système d’exploitation MS-Windows pour les pages Web.

Une composante essentielle d’ActiveX est ce qu’on appelle les contrôles ActiveX. De tels contrôles sont des programmes ou des modules de programme qui peuvent être incorporés dans des fichiers HTML en tant qu’objet, un peu comme les applets Java. Le code programme est exécuté dans la mémoire de travail de l’ordinateur client (donc celui de l’utilisateur qui appelle une page Web). En principe, un fichier de présentation ActiveX est alors également installé sur l’ordinateur de l’utilisateur. Avec les contrôles ActiveX toutes sortes d’applications peuvent être réalisées.

Il n’y a pas de règle établie pour déterminer dans quel langage de programmation le code ActiveX doit être écrit. Le compilateur doit pourtant soutenir le Component Object Model (COM). Pour créer des contrôles ActiveX, vous n’avez donc pas besoin d’un logiciel bien déterminé, mais d’un compilateur compatible à COM. Ce peut être Visual Basic, Microsoft C++ etc.

ActiveX n’est pour l’instant exécuté directement que par l’Explorer Internet Microsoft. Pour Netscape il y a un plugiciel ActiveX à télécharger. Chez les utilisateurs de Netscape qui ont installé le plugiciel, les contrôles ActiveX sont alors également exécutables.

7.4.10. Flash

Flash offre la possibilité de mettre sur les pages Web des effets multimédia, mais aussi des applications telles que des jeux, des simulations ou des Aides à la navigation pour les pages Web.

7.4.11. AJAX

AJAX (Asynchronous JavaScript and XML), une technologie web prometteuse pour les besoins applicatifs des entreprises. Ajax est une nouvelle architecture client-serveur qui s’appuie entièrement sur des standards web pour construire des applications aussi conviviales que celles qui s’exécutent directement sur un PC.

7.4.12. Servlet

Les servlets sont des programmes Java qui s’intègrent à un serveur web pour fournir le traitement côté serveur des requêtes issues d’un navigateur client. Ils ont besoin d’un serveur web supportant la technologie JavaServer, par exemple le serveur Tomcat livré avec JBuilder.


Page 50

7.4.13. JSP (Pages JavaServer)

Les pages JavaServer (JSP) sont une extension de la technologie des servlets. C’est essentiellement un moyen simplifié d’écrire des servlets, avec une attention plus forte accordée à la présentation de votre application

La technologie JSP (JavaServer Pages) permet aux développeurs et concepteurs Web de développer rapidement et de maintenir facilement des pages Web, dynamiques et riches en information, qui tirent profit des systèmes d’entreprise existants. Faisant partie de la famille Java, la technologie JSP permet de développer rapidement des applications Web indépendantes des plates-formes.

8. Conclusion

Les Systèmes d’Aide à la Décision sont très souvent des systèmes d’information distribués multi-utilisateurs. Il est donc nécessaire qu’ils reposent sur des systèmes informatiques distribués : des utilisateurs répartis sur plusieurs sites coopèrent au travers de l’outil informatique. C’est pourquoi dans le cadre de nos travaux, nous nous sommes intéressés aux Systèmes Multi-Agents (SMA). Nous allons présenter plus en détail les Systèmes Multi-Agents (SMA) dans le chapitre qui suit.

Chapitre 3 Les Systèmes Multi-Agents (SMA)

Page 51

1. Introduction

Les Systèmes Multi-Agents (SMA) sont des systèmes informatiques distribués. Comme la plupart des systèmes distribués, ils sont composés d’entités informatiques qui interagissent entre elles. A la différence des systèmes distribués classiques, les entités qui les constituent sont intelligentes. En effet le domaine des systèmes multi-agents est issu du domaine de l’Intelligence Artificielle Distribuée (IAD).

Ce chapitre présente les Systèmes Multi-Agents (SMA), les différentes sections proposées permettent d’introduire les notions d’agents, des interactions entre les agents et des protocoles de communication entre les agents.

2. La notion d’agents

2.1. Intelligence Artificielle Distribuée

L’Intelligence Artificielle Distribuée (IAD) semble à travers les Systèmes Multi-Agents (SMA), être un outil intéressant pour modéliser la prise de décision [Chebeane et Echalier, 1997].

Contrairement à l’approche centralisée de l’IA, l’intelligence artificielle distribuée vise la distribution de l’expertise sur un ensemble de composants qui communiquent pour atteindre un objectif global. Cette approche nécessite la division du problème en sous-problèmes.

Une extension des systèmes d’IAD a été proposée : les composants doivent être capables de raisonner sur les connaissances et les capacités des autres dans le but d’une coopération effective. Pour ce faire, ils doivent être dotés de capacités de perception et d’action sur leur environnement et doivent posséder une certaine autonomie de comportement.

Nous retiendrons donc que l’IAD cherche à reproduire les formes d’intelligence et exploiter les mécanismes de traitement de l’information qui reposent spécifiquement sur leur distribution en des formes plus simples, organisées et co-agissantes où les agents opèrent collectivement pour accomplir une tâche.

FIG. 3.1— Évolution vers l’IAD


Page 52

2.2. Définitions d’agents

Définition 1

Pour un certains nombre d’auteurs [Maes, 1994], [Weiss, 1999], un agent est défini comme étant une entité logicielle d’un système informatique qui possède les caractéristiques suivantes :

• Autonomie : les agents contrôlent leurs actions et leurs états internes. Le système dans son ensemble est capable de réagir sans l’intervention d’un humain ou d’un autre agent ;

• Réactivité : ils perçoivent leur environnement et réagissent aux changements qui s’y produisent dans le temps requis ;

• Proactivité : ils exhibent un comportement proactif et opportuniste pour ne pas agir uniquement par réaction à leur environnement mais prendre des initiatives selon leurs buts individuels ;

• Sociabilité : ils sont capables d’interagir les uns avec les autres quand la situation l’exige afin d’accomplir leurs tâches ou d’aider les autres agents à accomplir leurs buts.

Définition 2

Cette définition d’agent est toutefois remise en question par autres auteurs. Pour Wooldridge et Ciancarini [Wooldridge et Ciancarini, 2000] “un agent caractérise un système informatique matériel ou (plus souvent logiciel) qui comporte les caractéristiques suivantes” :

• Autonomie : l’agent agit sans l’intervention d’humain ou d’autre intervenants, et a un certain contrôle sur ces actions et ses états internes.

• Habilité sociale : l’agent interagit avec d’autre agents (pouvant être des humains) à l’aide d’un langage de communication d’agents.

• Réactivité : l’agent perçoit son environnement.

• Pro activité : l’agent n’agit pas simplement aux stimulus de son environnement, il est aussi capable de démontrer des comportement dirigés par des buts en prenant des initiatives.


Page 53

Définition 3

Les agents sont des entités physiques (capteurs, processeurs,...) ou abstraites (tâches à réaliser, déplacements,...), qui sont capables d’agir sur leur environnement et sur elles-mêmes, c’est-à-dire de modifier leur propre comportement. Elles disposent, pour ce faire, d’une représentation partielle de cet environnement et de moyens de perception et de communication. [Erceau, 1993]

Définition 4

En dépit de l’absence d’une définition consensuelle de ce qu’est un agent, on retient la définition suivante proposée par Ferber [Ferber, 1995] « Un agent peut être définit comme une entité (physique ou abstraite) capable d'agir sur elle même et sur son environnement, disposant d'une représentation partielle de cet environnement, pouvant communiquer avec d'autres agents et dont le comportement est la conséquence de ses observations, de sa connaissance et des interactions avec les autres agents ».

FIG. 3.2— Exemple d’agent

2.3. Structure générale d’un agent

Plusieurs architectures ont été procurées pour modéliser les agents, nous proposons celle adoptée par Ferber [Ferber, 1995], représentée dans la figure suivante :

Agent

Action Perception

Environnement


Page 54

FIG. 3.3— Structure générale d’un agent 2.3.1. Perception

Les connaissances d’un agent ont plusieurs origines :

− Le savoir initial de l’agent,

− la perception de soi (perception proprioceptive) et du monde (perception extéroceptive),

− la communication avec les autres agents.

Généralement, les informations issues de la perception et du savoir initial de l’agent sont considérées comme des connaissances certaines puisqu’elles n’ont subi aucune mise à jour, alors que les connaissances provenant des autres agents sont considérées incertaines puisqu’elles évoluent sans que l’agent en soit forcément informé. On peut pour cela associer à chaque connaissance son origine afin d'en évaluer la crédibilité et d'en permettre la vérification.

2.3.2. Action

L’agent se fixe des buts suite à une perception ou à une interaction avec le monde extérieur, il doit élaborer un plan d'action. Pour cela, il doit décider quel serait le but à retenir et à satisfaire en premier, ensuite planifier en fonction de ce but et passer à l’exécution

2.4. Typologie des agents

2.4.1. Agent réactif

L’approche des agents réactifs est fondée sur l’idée qu’il n’est pas nécessaire que chaque agent d’un système multi-agents soit individuellement intelligent pour parvenir à un comportement global intelligent. Cette approche propose la coopération d’agents de faible granularité mais beaucoup plus nombreux. L’agent réactif ne dispose que d’un protocole et d’un langage de communication réduits. Ses capacités répondent uniquement à la loi


Page 55

stimulus/actions : l’occurrence de chaque événement déclenche l’exécution d’une action prédéfinie.

2.4.2. Agent cognitif

Un système d’agents cognitifs est constitué d’un petit nombre d’agents de forte granularité ; chaque agent est apparenté à un système expert plus ou moins évolué. Les actions de ces agents seront ainsi réfléchies en ce sens qu’elles sont basées sur les connaissances de l’agent sur lui-même, sur les autres et sur son environnement et les objectifs qui le guident.

2.4.3. Architecture hybride

Dans ce cas, un agent est composé de plusieurs couches arrangées selon une hiérarchie, la plupart des architectures considèrent 3 couches.

Au plus bas niveau, on trouve une couche purement réactive, qui prend ses décisions en se basant sur des données brutes en provenance des senseurs. La couche intermédiaire fait abstraction des données brutes et travaille plutôt avec une version qui se situe au niveau des connaissances de l’environnement. Finalement, la couche supérieure se charge des aspects sociaux de l’environnement (raisonnement tenant compte des autres agents).

2.4.4. Agents autonomes

L’approche des agents autonomes ne suppose par l’existence de plusieurs agents dans le cadre d’un système multi-agents. L’agent est considéré comme un collaborateur intelligent capable d’apprendre des habitudes de l’utilisateur pour le décharger de certaines tâches répétitives.

On peut citer l’exemple de L’agent WBI d’IBM (Web Browser Intelligence) dont le but est d’assister l’utilisateur dans sa recherche d’information sur le Web en se servant de l’historique des navigations [Boussetta et al, 1998].

2.4.5. Agents sociaux

Cette approche considère que le concept d’agent ne prend tout son intérêt que dans un système multi-agents. L’agent a un comportement individuel et collectif. Le caractère individuel d’un agent se manifeste à travers des objectifs qui lui sont propres et qu’il essaye dans la mesure du possible d’atteindre avec les ressources et les compétences dont il dispose.

Le caractère collectif se manifeste sous forme d’interactions entre les agents. Ces interactions peuvent être de différents types : coordination, coopération, négociation [Boussetta et al, 1998].


Page 56

2.4.6. Agents mobiles

Lors de l'utilisation d'agents mobiles toutes les caractéristiques des agents fixes sont conservées. L'utilisation des agents mobiles présente en outre, plusieurs avantages :

• répartition de la charge de calcul : un agent mobile peut en effet se déplacer sur un ordinateur plus puissant pour effectuer un calcul complexe. De même il peut quitter une machine qui est saturé pour aller sur une autre,

• réduction du trafic réseau : un agent qui a besoin de traiter une grande quantité de données situé sur un autre ordinateur (base de données par exemple) peut se déplacer sur l'ordinateur possédant les données et revenir avec le résultat. Cela permet d'éviter de faire transiter les données sur le réseau.

Les agents mobiles présentent des intérêts évidents, mais sont cependant plus complexes à gérer. Il faut, par exemple, faire suivre les messages lorsque l'agent se déplace. Pour qu'un agent puisse se déplacer il faut bien entendu que des sites d'accueil existent.

L'utilisation de plusieurs langages de programmation peut poser des problèmes pour la mobilité des agents [Fradet et Rouvrais, 2002].

Ces agents peuvent :

• Migrer d'une machine à une autre dans le système,

• Interagir avec différentes machines,

• Exécuter des tâches pour les utilisateurs

2.4.7. Agents adaptatifs

Un agent adaptatif est capable d’apprendre en fonction de son expérience passée et de son évolution. Les architectures d’agents produisant des unités fonctionnelles dédiées à des tâches précises, les techniques d’apprentissage classique de l’intelligence artificielle s’appliquent particulièrement bien à l’apprentissage d’un agent (qu’il s’agisse de faire évoluer ses capacités d’action, de décision ou d’analyse).

2.4.8. Agents flexibles

Les agents flexibles sont des agents capables de modifier leur structure fonctionnelle (code) en cours d’utilisation. Par exemple, les agents flexibles peuvent être capables de charger dynamiquement un script de contrôle envoyé par l’utilisateur.


Page 57

L’exécution de tels scripts nécessite une interface de chargement (typiquement, un service réseau) ainsi qu’un mécanisme d’exécution des scripts reçus : interface avec les données, opérateurs d’exécution, etc. Ainsi, que le fléau de l’informatique : les Virus.

2.4.9. Agents du Web

La dénomination « Agents du Web » désignent les agents qui circulent sur le réseau Internet pour extraire de l’information. Certains systèmes ont pour objectif de fournir au consommateur une valeur ajoutée en lui fournissant des informations supplémentaires afin qu’il fasse un choix approprié selon les critères qu’il est fixé [Guttman and Maes, 1998]. Il peut s’agir d’informations comparatives entre produits ou encore d’études qualitatives.

Prenons un exemple concret : vous souhaitez achetez une nouvelle voiture mais vous n’avez pas encore décidé du modèle exact. Jusqu’à maintenant, vous deviez visiter un certain nombre de concessionnaires, étudier des documentations techniques, acheter des magazines spécialisés qui effectuent eux-mêmes des tests et des études comparatives. Tous ce travail est fastidieux et coûteux en temps. Le but des applications dans le domainedu commerce électronique va être d’extraire toute cette information qui est disponible à divers endroits du Web et de n’en retenir que celle qui vous intéresse. Il va s’agir d’un travail d’extraction, de filtrage et d’analyse de l’information disponible. La multiplicité des sources d’informations disponibles sur le Web et la complexité des traitements à effectuer rend particulièrement appropriée l’utilisation du paradigme agent pour le développement des applications de commerce électronique.

3. Les Systèmes Multi-Agents

3.1. Définition des Systèmes Multi-Agents (SMA)

L’approche multi-agents confère aux systèmes un avantage fondamental qui réside dans sa manière de s’adapter. D'ailleurs, elle présente encore l’avantage d’être une technique de développement qui facilite l’implémentation envisagée de notre travail.

Selon Ferber [Ferber, 1995] on appelle système multi agent un système composé des éléments suivants:

Un environnement E, c’est-à-dire un espace disposant généralement d’une métrique ;

Un ensemble d’objets O. Ces objets sont situés, c’est-à-dire que, pour tout objet, il est possible, à un moment donné, d’associer une position dans E. Ces objets sont passifs, c’est-à-dire qu’ils peuvent être perçus, créés, détruits et modifiés par les agents ;


Page 58

Un ensemble A d’agents, qui sont des objets particuliers représentant les entités actives du système ;

Un ensemble de relations R qui unissent des objets (et donc des agents) entre eux ;

Un ensemble d’opérations Op permettant aux agents de A de percevoir, produire, consommer, transformer et manipuler des objets de O ;

Des opérateurs chargés de représenter l’application de ces opérations et la réaction du monde à cette tentative de modification, que l’on appellera les lois de l’univers.

FIG. 3.4— Exemple de Système Multi-Agents (SMA)

L’intérêt d’une approche SMA est de distribuer la connaissance dans un ensemble d’agents. Cette distribution diminue la complexité de chaque agent et permet de mixer divers modèles de raisonnement (logique pure, base de connaissances) au sein d’un même SMA.

La compétition entre ces différents modèles de raisonnement peut engendrer une meilleure solution.

FIG. 3.5 — Représentation imagée d’un agent en interaction avec son environnement et

les autres agents [Ferber, 1995]


Page 59

3.2. Décomposition du SMA

Nous adopterons la vision du SMA introduite par Yves Demazeau et communément admise aujourd’hui [Denis et Lesage, 1995]. Nous pouvons identifier un axe Agent, un axe Environnement, des Interactions et une structure Organisationnelle explicite ou non.

SMA = Agent + Environnement + Interaction + Organisation

Agent : est une sorte d’organisme vivant dont le comportement se résume à communiquer, à agir et à éventuellement se reproduire, dans le but de satisfaire des besoins et des objectifs. Ces besoins sont déterminés à partir de l’état interne de l’agent et de l’environnement.

Environnement : un environnement est un espace représentant le monde dans lequel les agents évoluent. On fait généralement une distinction entre les agents qui sont les entités actives, et les objets passifs qui se situent dans l’environnement. Lorsque ce dernier dispose d’une métrique (cas général), la capacité de perception d’un agent est sa capacité à reconnaître les objets situés (position, relations entre objets) et la capacité d’action d’un agent est celle de transformer l’état du système en modifiant les positions et relations qui existent entre les objets. Par exemple dans un univers de robots, l’environnement est l’espace géométrique euclidien dans lequel se déplacent les robots (agents) et où sont situés des objets physiques que les robots peuvent manipuler ou doivent éviter.

Interaction : Ferber définit une interaction comme étant la mise en relation dynamique de deux ou plusieurs agents par le biais d’un ensemble d’actions réciproques. Une interaction peut se caractériser par une simple trace qu’un agent laisse dans l’environnement (déplacement d’un objet par exemple) et la perception de cette trace par un autre agent. Elle peut également se caractériser par un message que s’échangent deux agents ou encore par un acte de langage entre ces deux derniers.

Organisation : est une structure décrivant comment les membres d’une organisation sont en relation et interagissent afin d’atteindre un but commun. Cette structure peut être statique, donc conçue a priori par le programmeur du système ou dynamique.

3.3. Interactions entre les agents

Pour un agent, l’interaction constitue à la fois la source de sa puissance et l’origine de ses problèmes [Ferber, 1995]. Une des principales propriétés de l’agent dans un système multi-agents est celle d’interagir avec les autres. Ces interactions sont généralement définies comme étant toute forme d’action exécutée au sein de la société qui a pour effet de modifier le comportement d’un autre agent. Elles donnent à l’agent la possibilité de participer à la satisfaction d’un but global. Cette participation lui permet alors d’évoluer vers un des objectifs qui le composent. L’interaction peut être décomposée en trois phases non nécessairement séquentielles [Chaib-draa, 1996] :

i. la réception d’informations ou la perception d’un changement,


Page 60

ii. le raisonnement sur les autres agents,

iii. une émission de messages(s) ou plusieurs actions (plan d’actions) modifiant l’environnement. Cette phase est le résultat d’un raisonnement de l’agent sur son propre savoir-faire et celui des autres agents.

3.3.1. L’interaction par la communication

La communication, dans les Systèmes multi-agents est souvent l’un des moyens utilisés pour échanger des informations entre agents (ex. plans, résultats partiels, buts, etc.). L’interaction constitue un niveau supérieur à la notion de communication et d’action. Le problème est alors de savoir combiner ces éléments (communications et actions) afin de coordonner et de contrôler les échanges entre plusieurs agents pour avoir un comportement collectif cohérent du système [Mazouz, 2001].

Ainsi, les questions abordées par un modèle de communication peuvent être résumées par l’interrogation suivante : qui communique quoi, à qui, quand, pourquoi et comment ?

Les agents communiquent entre eux à l’aide de protocoles de communication. Leur communication peut être de deux types : par partage d’information ou par envoie de message.

• En mode partage d’information, toute l’information sur le système est centralisée dans une structure de données globale. Les agents viennent lire et écrire dans cette base de données pour faire évoluer le système qui contient initialement les données du problème. Ce type de communication, appelé « tableau noir » ou « blackboard ». D’apparence assez simple, ce mode communication centralisé implique que les agents effectuent un grand nombre de requêtes sur un seul et unique site central.

De plus, le fonctionnement global du système n’est pas purement multi-agents puisque le comportement d’un des agents est dépendant du contenu d’une base de connaissances commune.

FIG. 3.6 — Mode de communication par tableau noir


Page 61

Les Systèmes Multi-Agents fondés sur la communication par envoi de messages se caractérisent par le fait que chaque agent possède une représentation propre et locale de l’environnement qui l’entoure. Chaque agent va alors interroger les autres agents sur cet environnement ou leur envoyer des informations sur sa propre perception des choses. La communication se fait soit en mode point à point, soit en diffusion. Cette communication permet de réaliser un véritable système multi-agents puisque chaque agent possède sa propre base de connaissance. Par contre, il est plus difficile d’assurer une convergence globale du système. De plus, dans un environnement distribué, la communication entre un grand nombre d’agents peut très vite amener à une saturation du réseau compte tenu de la grande quantité de messages échangés.

FIG. 3.7 — Mode de communication par envoie de messages : (a) Diffusion, (b) Point à

Point

3.3.2. L’interaction par la coopération d’agent

Les agents travaillent à la satisfaction d’un but commun, ou individuel, dont l’objectif est d’améliorer le mode de travail des agents en thème de :

Validité et rationalité des informations échangées et des comportements,

efficacité des stratégies de résolution employées,

cohérence entre planification locale et globale, et

rééquilibrage dynamique de la charge de travail.

Des agents totalement coopératifs peuvent changer leurs buts pour répondre aux besoins des autres agents afin d’assurer une meilleure coordination entre eux. Cela peut résulter en de coûts de communication élevés.

Les interactions des agents d’un SMA sont motivées par l’interdépendance des agents selon ces trois dimensions:

Agent

Agent

Agent

Agent Agent

Agent

Agent

Agent Agent

Agent


Page 62

• Leurs buts peuvent être compatibles ou non,

• les agents peuvent désirer des ressources que les autres possèdent,

• un agent X peut disposer d’une capacité nécessaire à un agent Y pour l’accomplissement d’un des plans d’action de Y.

3.3.3. L’interaction par la négociation entre ressources

La négociation est avant tout un mécanisme de résolution de conflit. Cette résolution peut alors s’effectuer dans un contexte favorable ou défavorable. Dans un contexte favorable, toutes les parties sont prêtes à faire les concessions nécessaires pour arriver à un accord. Dans un contexte défavorable, l’objectif principal pour au moins l’un des participants, est d’obtenir un accord qui le favorise même aux dépends des autres. De ce fait, la négociation peut être décrite comme une coopération dont l’objectif commun est l’obtention d’un accord.

3.4. Protocoles d’interaction

Un système multi-agents est un ensemble organisé d’agents interactifs. L’interaction est ainsi un concept clé des systèmes multi-agents. Pour définir les interactions entre agents, différents protocoles d’interactions ont été définis (voir par exemple les travaux faits par FIPA).

Les protocoles d’interaction sont des descriptions de patterns standards d’interactions entre deux ou plusieurs agents. La majorité des travaux existants, notamment les travaux de FIPA, décrit en effet les séquences de messages échangés et leurs contenu (émetteur, receveur, performative…).

Les représentations proposées des protocoles d’interaction fournissent plusieurs facilités pour concevoir des systèmes multi-agents [Ocello, 2003]. Ce pendant, les actions locales et les processus de décision d’un agent ne sont pas toujours explicitement représentés.

Cette section définit les protocoles d’interaction et les comportements nécessaires à leur exécution.

3.4.1. Protocoles de Coordination

La coordination se traduit par un comportement individuel visant à servir ses propres intérêts tout en essayant de satisfaire le but global du système. Un des exemples de protocole pour la coordination est celui du réseau contractuel (contract-net). L’intérêt d’un tel protocole est qu’il réalise la coordination de tâches parmi les agents en assurant l’allocation la plus optimale possible.


Page 63

De nombreux exemples de coordination existent dans la vie quotidienne: deux déménageurs déplaçant un meuble lourd, deux jongleurs échangeant des balles avec lesquelles ils jonglent, des personnes qui parlent à tour de rôle en se passant un micro, etc. Malone [Malone, 1988] note que deux des composantes fondamentales de la coordination entre agents sont l’allocation de ressources rares et la communication de résultats intermédiaires. Dans ce contexte, les agents doivent être capables de communiquer entre eux de façon à pouvoir échanger les résultats intermédiaires. Pour l’allocation des ressources partagées, les agents doivent être capables de faire des transferts de ressources. Ceci peut d’ailleurs imposer certains comportements à des agents particuliers.

3.4.2. Protocoles de Coopération

Les protocoles de coopération consistent à décomposer un problème en tâches puis les distribuer [Mazouz, 2001]. Cette approche a l’avantage de réduire la complexité d’un problème. Mais il risque d’avoir des interactions entre les tâches et par conséquent des conflits entre les agents.

Il existe plusieurs mécanismes pour distribuer les tâches. On cite les mécanismes d’élection où les tâches sont attribuées à des agents suite à un accord ou un vote, les réseaux contractuels où des tâches sont attribuées aux agents suite à des cycles d’appels d’offres ou de propositions.

La planification multi-agents attribue aux agents planificateurs la responsabilité de la distribution des tâches et la structure organisationnelle où les agents ont des responsabilités pour des tâches particulières.

3.4.3. Protocoles de Négociation

Les protocoles de négociation sont utilisés dans le cas où les agents ont des buts différents. Les dispositifs principaux de la négociation sont : le langage utilisé, le protocole suivi dans le principe de négociation et la procédure de décision que chaque agent utilise pour déterminer ses positions, ses concessions et ses critères pour l’accord.

La négociation joue un rôle fondamental dans les activités de coopération en permettant aux personnes de résoudre des conflits qui pourraient mettre en péril des comportements coopératifs. Durfee et al [Durfee et al, 1989] définissent la négociation comme le processus d’améliorer les accords (en réduisant les inconsistances et l’incertitude) sur des points de vue communs ou des plans d’action grâce à l’échange structuré d’informations pertinentes. En général les chercheurs en IA distribuée utilisent la négociation comme un mécanisme pour coordonner un groupe d’agents. Différentes approches ont été développées en s’appuyant sur la riche diversité des négociations humaines dans divers contextes.


Page 64

3.5. Domaines d’application des SMA

Les SMA permettent de modéliser une grande quantité de systèmes relevant de domaines d’application très variés. Pour illustrer ce fait, nous allons d’abord évoquer quelques applications relevant du domaine industriel, puis de domaines divers.

3.5.1. Applications industrielles

La conception et l’ingénierie simultanée : il s’agit de produire de meilleurs produits en un temps court. A cet effet, toutes les étapes du cycle de vie du produit (définition du cahier des charges, conception, élaboration des méthodes, mises en fabrication…) sont considérées aussi tôt que possible.

Le système d’information et le CIM(Computer Integrated Manufacturing) : il est de plus en plus prouvé que la productivité des entreprises est plus limitée par l’information que par le travail ou le capital. Un exemple de gêne à la circulation de l’information provient des logiciels des différentes parties de l’entreprise qui ne peuvent pas "discuter" entre eux. Dans l’approche SMA, chacune de ces parties peut être vue comme un agent.

La distribution du système de production (multi-sites) : chaque site de production est autonome, mais doit tenir compte des décisions des autres sites.

La gestion de la production : le problème consiste à faire cohabiter des objectifs qui ont des termes plus ou moins longs.

L’ordonnancement et le pilotage des systèmes de production : comment ré-ordonnancer dynamiquement un atelier qui subit des événements perturbateurs. Ce ré-ordonnancement est une résolution coopérative et distribuée de problèmes entre les différentes entités de l’entreprise. La résolution part de la plus petite entité (le poste de travail), et tente de résoudre le problème en mettant en jeu progressivement de plus en plus d’entités (machines identiques, puis atelier, etc…).

les chaînes logistiques : ce sont des réseaux de fournisseurs, d’usines, d’entrepôts, de centres de distribution et de détaillants à travers lesquels des matières premières sont acquises, transformées et livrées au consommateur. L’objectif est d’optimiser les performances de ces chaînes logistiques. Pour cela, les niveaux de décision stratégique, tactique et opérationnel sont mis en jeu pour que chaque maillon opère de manière intégrée à l’ensemble de la chaîne.

3.5.2. Autres applications

Parmi les autres domaines dans lesquels les SMA se révèlent utiles, citons :


Page 65

Les transports : une approche multi-agent a été appliquée pour résoudre les problèmes de planification et de négociation dans les systèmes de transport de marchandises par camions. Les conducteurs de camion et leur compagnie respective y sont vus comme des agents intelligents, autonomes et rationnels. L’objectif de l’étude est d'atteindre un compromis qui minimise le coût global des transports en appliquant successivement différentes méthodes de coopération. A cet effet, les conducteurs négocient à travers leur compagnie leurs propositions en effectuant des ventes et des achats de commandes.

La biologie : une étude vise à étudier l’émergence d’un comportement global intelligent à partir du comportement basique de chaque agent. Cette étude a montré comment un groupe de termites au comportement très simple peut rassembler en une seule pile des copeaux de bois. En outre, elle a aussi étudié la propagation d’une épidémie dans une population composée d’agents sains et d’agents malades.

La médecine : un système multi-agent a été mis en œuvre pour la surveillance des patients.

3.6. Plates-formes de développement de SMA

Des plate-formes génériques sont apparues pour le développement de systèmes reposant sur l’utilisation du paradigme agent. Après avoir examiné plusieurs de ces plate-formes, très peu apparaissent comme pouvant servir réellement à la conception de tout type d’application. En effet, la plupart s’adapte souvent à la conception d’un type d’applications ou d’une classe d’applications mais rarement plus. Il apparaît, de plus, que la définition d’un agent est beaucoup trop vague pour qu’un modèle générique et universel puisse exister.

Parmi les plate-formes les plus connues on peut citer : SWARM [Burkhart, 1994] [Daniels, 1999] [Daniels, 2000], Voyager (http://www.objectspace.com/products/voya-ger/), DIMA [Guessoum, 1996], MADKIT [Madkit, 2001], Zeus [Azvine et al., 2000], JADE [Bellifemine et al, 1999][ Bellifemine et al, 2000], etc.

4. Conclusion

Issus de l’intelligence artificielle distribuée, les agents et systèmes multi-agents sont de plus en plus présents dans les systèmes en interaction avec les utilisateurs. Nous avons souligné dans ce chapitre l’importance croissante apportée aux nouvelles approches à base d’agents et de systèmes multi-agents. La conception de tels systèmes exploitant ces nouvelles approches doit se baser sur les méthodes de conception et d’évaluation adaptées (considérant les notions d’autonomie et d’adaptation).


Page 66

Les notions les plus importantes pour commencer notre étude semblent être présentées globalement, nous entamons par la suite le domaine d’application c’est à dire la gestion de production dans un cadre industriel et de ce fait toutes les décisions devant être prises concernent ce contexte et tentent d’apporter des solutions temps réel à la problématique ainsi définie.

Chapitre 4 Conception

Page 67

1. Introduction Les Systèmes Multi-Agents sont l’une des dernières générations de systèmes informatiques intelligents. Émergeant de la recherche en intelligence artificielle distribuée dans les années quatre-vingt, les Systèmes Multi-Agents constituent aujourd’hui une grande part de la recherche et du développement de l’intelligence artificielle et de la programmation distribuée.

Partageant un espace commun, usuellement appelé environnement, les agents sont amenés à coopérer pour s’aider mutuellement dans l’accomplissement de leurs objectifs, partager leurs ressources, résoudre les conflits éventuels ou les éviter, etc. Ceci amène les agents à se coordonner afin de pouvoir évoluer en complète synergie dans cet environnement. En conséquence, des interactions prennent place afin que ces agents déterminent l’organisation la plus appropriée (qui fait quoi) et communiquent les résultats de leur coopération (quand et à qui).

Dans ce chapitre, nous allons présenter l’architecture générale de notre contribution qui va combiner entre la technologie Web et les agents pour aider les utilisateurs à trouver une solution à un problème donné, on va entamer directement par la suite la coordination entre les agents pour avoir une bonne interaction entre les agents.

2. Contribution

Étant donnés les diverses sources de données et les différents outils d’aide à la décision, la conception, la spécification et la mise en œuvre d'un SIAD à base de technologie Web souvent dans un environnement distribué est toujours un domaine de recherche en plein essor. Premièrement, un "Web-DSS" consiste souvent en un ensemble de fonctions de données et des outils connexes, qui viennent de domaines pluridisciplinaires. A L’origine, ces données et ces outils ne sont pas conçus pour fonctionner ensemble. Deuxièmement, avec l'aide du Web et des technologies de réseau, les données et les outils d'aide à la décision provenant des domaines pluridisciplinaires peuvent être localisés sur des ordinateurs répartis sur un réseau. Dans un tel environnement distribué, un ‘Web-DSS’ a besoin d’une architecture distribuée destinée à gérer et à intégrer les données et les outils d'une manière transparente et unifiée.

L’étude présentée ici s’insère dans le prolongement des travaux réalisés dans [Taghezout, 2008]. Elle consiste à proposer un SIAD à base d’agents et à intégrer une technologie Web, son principe est d'aider les décideurs dans la prise de décision par l’accès à l’information sur le Web. Plusieurs agents sont prévus pour faciliter la recherche des ressources de substitution ainsi que l’accès à ces ressources. [Bessedik et Taghezout, 2009] Comme deuxième contribution, on va intégrer le protocole de coordination dans un Web-DSS à base d’agents en ajoutant un agent coordinateur. [Bessedik et Taghezout, 2010].


Page 68

3. Architecture générale

FIG. 4.1— Architecture générale

L’architecture générale de notre logiciel contient trois grandes parties :

1. Atelier : qui contient les ressources (machines) et l’Agent Production (APr) qui contrôle les ressources en panne.

2. Système Multi-Agent (SMA) qui englobe quatre agents : Un Agent Coordinateur (AC), un Agent Analyseur (AA) qui va analyser et filtrer la liste des ressources en panne envoyée par l’Agent Production (APr), un Agent Ressource (AR) qui fait la recherche des ressources en panne sur le Web, et l’Agent Proposition (AP) qui propose des solutions aux pannes à travers le Web.

3. SIAD à base de Web ("Web-based DSS").

4. Fonctionnement du modèle

Pour la résolution d’une panne, l’Agent Production (APr) va récupérer toutes les informations concernent les ressources en panne dans l’atelier et il va les envoyer aux agents qui se trouvent dans le serveur.

Au niveau du serveur, l’Agent Analyseur (AA) va recevoir une liste qu’il va analyser et filtrer, ensuite il va l’envoyer à l’Agent Coordinateur (AC). Ce dernier va appliquer ce dernier un algorithme de coordination pour le choix de la première ressource à traiter, ensuite il va envoyer la première ressource sélectionnée à l’Agent Ressource (AR) qui va chercher la référence de cette ressource sur le Web et il va lui répondre soit par « référence trouvée » ou bien par « référence non trouvée ». Dans le prmier cas, l’Agent Coordinateur (AC) va demander l’Agent Proposition (AP) de chercher une solution à cette panne, suite à cette demande, deux (02) solutions sont fournies : « solution trouvée » (l’Agent Production APr devra réparer la ressource), soit par « solution non trouvée » (proposer à l’utilisateur de commander une nouvelle ressource qui a les mêmes références).

Agent Ressource

Agent Proposition

Agent Analyseur

SMA

SIAD à base de Web

Agent Production Ressource

sAtelier

Ressources en panne

Agent Coordinateur


Page 69

La figure 4.2 représente le scénario échangé entre les agents du modèle proposé sous forme d’un diagramme de séquence.

On peut aussi représenter les communications entre les agents par le schéma suivant : (Figure 4.3).

FIG. 4.2— Scénario échangé entre les agents (diagramme de séquence)

APr AA Agent Coordinateur AR AP

Liste des ressources en panne

Analyser et filtrer la panne

Ressource tombe en

panneChercher la référence de la ressource tombée en

panne

Rechercher

X

Référence trouvée

Référence non trouvée

Référence trouvéeChercher la solution de la panne

Rechercher

Solution non trouvée

Solution trouvée

Solution trouvéeSolution de la panne

Solution de la panne

Panne réparée Solution non trouvée

Commander la ressourceAccepter la commande

Ressource commandéeNouvelle ressource

Nouvelle ressource Remplacer la

ressource tombée en panne

Référence non trouvée

X

Remplacer la ressource tombée

en panne

Commander la ressource

Ressource commandéeAccepter la commande

Nouvelle ressource Nouvelle ressource


Page 70

FIG. 4.3— Communication entre les agents 1 : l’Agent Production va récupérer les informations complètes des ressources tombées en panne dans l’atelier, et il va les envoyer à l’Agent analyseur pour les analyser et les filtrer. 2 : l’Agent analyseur va envoyer la première référence de la ressource tombée en panne (après analyse et filtrage) à l’Agent ressource et lui demande de chercher cette référence sur le Web, et après réponse il va envoyer la deuxième et ainsi de suite. 3 : l’Agent ressource va chercher sur le web. Si la référence existe dans le web : 4’ : l’Agent ressource va récupérer cette référence et il va l’envoyer à l’Agent analyseur. 5 : l’Agent analyseur va envoyer la référence de cette ressource et la diagnostic de cette panne à l’Agent proposition et il lui demande de chercher la solution de cette panne sur le web. 6 : l’Agent proposition va chercher sur le web. Si la solution existe sur le web : 7’ : l’Agent proposition va récupérer la solution qu’il transmet à l’Agent analyseur. Si la solution n’existe pas sur le web : 7’’ : l’Agent va récupérer le lien qui permet de commander une ressource et il va l’envoyer à l’Agent analyseur. Si la référence n’existe pas dans la web : 4’’ : l’Agent va récupérer le lien qui permet de commander une ressource et il va l’envoyer à l’Agent analyseur.


Page 71

8 : l’Agent analyseur va envoyer la solution proposée à l’Agent Production. 9 : l’Agent Production va réparer la panne.

5. Les structures des agents

5.1. Structure de l’Agent Analyseur (AA) L’Agent Analyseur (AA) inclut plusieurs types de modules fonctionnels comme : le module d’analyse, le module de générateur de proposition, une Base De Données (BDD), une Base de Connaissances (BC), un filtre et une interface. L’ensemble de ces composants est montré dans la figure 4.4.

− Le module d’analyse est le noyau de cette architecture, son rôle est d’utilisé comme entrée les données qui sont stockées dans la BDD, les connaissances qui sont stockées dans la BC et les règles qui sont stockées dans la BR pour analyser et filtrer les pannes et produit comme sortie un générateur de propositions des pannes analysées et filtrées.

− Le module d’interface contrôle les échanges de l’information entre l’Agent Analyseur et les autres agents.

FIG. 4.4— Structure d’Agent Analyseur (AA)

Les fonctions du module d’analyse sont : − Utiliser les données entrées qui sont stockées dans la BDD ; − utiliser les connaissances qui sont stockées dans la BC ; − utiliser les règles qui sont stockées dans la BR ;

Base de Connaissances

(BC)

Base de Données (BDD)

Base des règles (BR)

Module d’Analyse

Module de générateur de propositions

Module d’Interface

Filtre


Page 72

− analyser et filtrer les informations de panne ; − au cours de la résolution du problème, l’Agent Analyseur exigera de l’Agent

Ressource (AR) qu’il cherche la référence de la ressource tombée en panne sur le Web.

5.2. Structure de l’Agent Proposition (AP)

Après avoir trouvé la réfèrence de la ressource tombée en panne sur le web, l’Agent Coordinateur (AC) demande à l’Agent Proposition (AP) de lancer une recherche avancée sur le web concernant la panne de cette ressource. L’Agent Proposition (AP) inclut plusieurs types de modules fonctionnels comme : le module de recherche, le module de générateur de solutions, une Base de Données (BDD), une Base de Connaissances (BC), une Base de règles (BR), une base de web et une interface.(figure 4.5). − Le module de recherche est le noyau de cette architecture ; son rôle est de lancer une

recherche avancée sur le web concernant la panne de cette ressource, il produira comme sortie plusieurs solutions.

− Le module d’interface contrôle les échanges de l’information entre l’Agent Proposition et les autres agents

FIG. 4.5— Structure d’Agent Proposition (AP) Les fonctions du module de recherche sont les suivantes :

− Démarrage d’une recherche avancée sur le web ; − génération de plusieurs solutions ; − le module d’interface gère les échanges d’informations entre l’Agent Proposition

(AP) et les autres agents.

5.3. Structure de l’Agent Ressource (AR)

L’Agent Ressource (AR), est l’agent qui fait la recherche de la référence des ressources en panne sur le web. Sa structure est la même que celle de l’Agent Proposition (AP), elle

Base de Données (BDD)

Base de Connaissances

(BC)

Base de Données du web

Base des Règles (BR)

Module de Recherche

Module de Générateur de Solutions

Module d’Interface


Page 73

comporte cinq modules fonctionnels : interface, module de générateur de propositions, base de données, base de connaissances et de contrôle.

5.4. Structure de l’Agent Production (APr)

Dans un travail précédent [Taghezout, 2008], un système de production composé de plusieurs stations intégrées de production appelées agents a été défini. Chaque Agent Production (APr) est spécialisé dans les opérations de production et il est de type cognitif. Il possède un niveau de connaissances suffisant pour permettre une prise de décision, son rôle est alors de :

o gérer localement en temps réel les processus d’allocation des tâches, les files d’attente, etc ;

o gérer la disponibilité des éléments nécessaires à la réalisation des tâches opératoires ;

o le système est alors constitué d’un ensemble d’agents coopératifs sous le contrôle d’un superviseur.

5.5. Structure de l’Agent Coordinateur (AC)

Clairement, tous les modules représentant la structure interne de l’agent sont montrés à la figure 4.6. Cela est valable particulièrement pour le résolveur local de problème et les modules de coordination qui échangent non seulement l'information en temps réel mais, en outre, doivent coordonner leurs règles de décision et critères d'exécution. Si nous considérons le rapport entre le module de coordination, le résolveur de problème, et la base de connaissance, nous constatons qu'ils doivent s'assurer de la disponibilité des données. La communication entre les agents est décrite par le module de coordination et le composant d'interface.

FIG. 4.6— Structure d’Agent Coordinateur (AC)

Module de Coordination

Solution du problème

Connaissance

Interface


Page 74

6. La Coordination

La coordination est un processus d’agencement et de répartition des actions d’un système distribué en vue d’atteindre un objectif déterminé ou d’obtenir une meilleure rentabilité des composants du système.

Selon Malone et Crowston, la coordination peut également être définie comme étant la gestion des interdépendances entre les activités [Malone et Crowston, 1994]. Ces interdépendances peuvent concerner des ressources partagées, des contraintes de simultanéité, des relations entre producteur_consommateur, des tâches_sous-tâches,etc.

Dans ce contexte, le rôle d’un agent est de construire des solutions, seul ou en coopération avec d’autres agents, qui tiennent compte des interdépendances et des contraintes spécifiques au problème traité et qui soient en plus en mesure d’assurer une cohésion avec l’ensemble des agents qui partagent son environnement.

7. Syntaxe des requêtes échangée entre agents

Le modèle de requêtes que nous présentons est utilisé dans notre approche pour formaliser les besoins de l’utilisateur, mais aussi le contenu des messages échangés entre agents. Parce qu’il est employé dans les interactions humain-agent et interagents, il comprend plusieurs types de requêtes, dont des questions, des commandes, des assertions, etc.

Une requête est une paire :

Où est un performatif et est le contenu (ou l’objet) de la requête.

Le performatif de la requête peut ainsi prendre les valeurs suivantes :

− What-is : pour les requêtes qui représentent les questions à propos des données de l’agent.

− Assert-is : pour les assertions à propos des valeurs des données de l’agent (en réponse aux requêtes What-is).

− Order : pour commander l’exécution d’une action étant donné un ensemble de paramètres, i.e. moyennant l’envoi d’un évènement.

− Ack : pour les confirmations d’exécution d’actions (en réponse aux requêtes Order).

− Assert-cannot : pour exprimer qu’un agent est incapable d’exécuter une action. − Assert-can : pour exprimer qu’un agent peut exécuter une commande, moyennant

certains paramètres.


Page 75

− Unknown : pour exprimer qu’une entité demandée n’a pas été reconnue de l’agent. − Missing : pour communiquer les valeurs d’attributs que l’agent n’a pas pu

interpréter. Cela se produit, lorsqu’une requête reçue présente des dépendances avec d’autres requêtes.

Ainsi, {What-is, Assert-is, Order, Ack, Assert-cannot, Assert-can, Unknown, Missing}est l’ensemble de performatifs que nous utilisons dans la formalisation des requêtes de l’utilisateur ainsi que dans la représentation des réponses des agents.

8. Langage de communication entre agents

Un langage de communication est conçu pour l’échange, entre logiciels (agents), d’informations, de connaissances ou encore de services [Koning et Pesty, 2001]. Dans notre architecture, les agents sont munis d’un ACL leur permettant de communiquer à propos des besoins de l’utilisateur et de construire des contenus de messages exprimant des informations à propos de leurs capacités [Charif et Sabouret, 2004].

8.1. Envoi de messages

Un agent envoi un message dans deux cas de figure :

1. S’il a reçu un message nécessitant d’être traité, il construit alors un message pour répondre à celui qu’il a reçu et l’envoi à l’émetteur de ce dernier ;

2. S’il exécute une action dont les effets consistent en l’envoi d’un ou plusieurs messages, alors il construit ces messages et les envoi au(x) destinataire(s) spécifié(s).

8.2. Contenu des messages

En contraste avec les messages KQML et FIPA-ACL, où est exprimée une seule valeur d’illocution appliquée à un seul contenu propositionnel, nos agents peuvent au contraire traiter un ensemble de requêtes, chacune comportant un performatif et un contenu.

En effet, les langages KQML et FIPA-ACL ont été conçu pour des besoins applicatifs, le plus souvent liés à l’échange d’informations et de connaissances. Ces modèles ne sont cependant pas adaptés à des interactions de types conversationnel, en particulier lorsqu’il s’agit de communautés impliquant agents artificiels et humains.

C’est dans cette optique que nous avons conçu notre ACL. Il est un moyen pour les agents non seulement de communiquer et d’exprimer une large gamme d’informations, mais aussi de pouvoir directement traiter les besoins de l’utilisateur avec lequel ils interagissent. En effet, ces besoins peuvent être complexes et doivent parfois être formalisés en un ensemble de requêtes qui se complètent et dont certaines dépendent des résultats des autres. Ces besoins peuvent ainsi être manipulés par les agents, moyennant leur ACL. Leur traitement s’effectuera ensuite, en fonction de la capacité des agents à répondre à tout ou partie de ces


Page 76

besoins, soit au niveau de leur module de raisonnement, i.e. le RPM, soit au niveau du protocole de coordination.

8.3. Syntaxe des messages

Pour construire les messages échangés entre les agents, ceux-ci utilisent un langage de communication appelé FIPA-ACL [Fipa, 2002]. Un message FIPA-ACL comprend un niveau de communication et un niveau contenu :

1. Le niveau communication permet d’identifier les agents émetteur et récepteur, et précise l’identifiant du message ainsi que l’identifiant de celui auquel il est construit en réponse (i.e. le message d’origine). De plus, ce niveau affecte un identifiant de la conversation à laquelle appartient ce message, i.e. c’est un identifiant commun à l’ensemble des messages générés pour la satisfaction d’un même ensemble de besoins de l’utilisateur, et les identifiants des requêtes auxquelles le message répond.

2. Le niveau contenu englobe le contenu du message. Celui-ci est constitué d’un ensemble de requêtes dont la syntaxe et la sémantique ont précédemment été définies.

Chaque message a ainsi la syntaxe suivante :

− sender est l’identifiant de l’agent émetteur ; − receiver est l’identifiant de l’agent récepteur ; − conv-id est l’identifiant de la conversation dans laquelle le message m est impliqué.

Une conversation réfère l’ensemble des messages générés pour satisfaire un même ensemble de besoins de l’utilisateur ;

− reply-with est l’identifiant du message m; − in-reply-to est l’identifiant du message auquel m est construit en réponse ; − req-id est un tableau regroupant les identifiants des requêtes auxquelles m répond ; − content est le contenu du message.


Page 77

8.4. Exemple de primitives

8.4.1. Requêtes Order

8.4.2. Requêtes What-is

8.5. Algorithme de Coordination

• Le principe de notre algorithme est comme suit :

FIG. 4.7— Primitive “Order”

A : Agent B : Agent

Order

Alt

Ack

Assert-Cannot

Assert-Can

[Success]

[Failure]

[alt]

FIG. 4.8 — Primitive “What-is”

A : Agent B : Agent

What-is

Alt

Assert-is

Unknown

Unknown

[Success]

[Failure]

[alt]


Page 78

lire la liste des ressources en panne ; pour choisir la première à traiter, il vérifie d’abord le temps de panne des

ressources ; Si les temps des pannes des ressources sont différents, alors il va choisir la première

ressource qui est tombée en panne et il applique le diagramme présenté dans la figure 4.2.

s’il existe des temps de panne égaux, il va tester leurs diagnostic. Si le diagnostic existe dans sa base de connaissances, donc il va choisir cette

ressource, Si le diagnostic n’existe pas dans sa base de connaissances, donc on passe à une autre, Si aucun diagnostic n’existe dans sa base de connaissances, donc il va choisir au hasard et applique le diagramme présenté dans la figure 4.2.

FIG. 4.9 — Algorithme de Coordination

Begin Var j, i, n : integer ; Var OK: boolean; Var Tmax, CA (Coordinator Agent), H : string; R: resource; T [Ri], D [Ri] = Array [R1…R2] of String; Repeat Read (n); Read (T [R1]); For i := 1 to n do Begin Read T [Ri]; if T [Ri] > Tmax then R1 Ri End CA R1; Apply the sequence diagram of figure 4.2; N n-1; For i := 1 to n do Begin Read T [Ri]; if T [Ri] = T [Rj] then Begin if D [Ri] ∈{H}then OK Vrai

CA Ri; Apply the sequence diagram of figure 4.2; n n-1; else

if D [Rj] ∈{H}then OK Vrai CA Rj; j j+1; Apply the sequence diagram of figure 4.2; n n-1; else if D [Rj] and D [Rj] ∉{H}then OK False CA choose a resource randomly; Apply the sequence diagram of figure 4.2; n n-1;

End End to n := 1; End


Page 79

9. Conclusion

Nous avons proposé dans ce chapitre une architecture générale de notre application, ainsi que la structure des agents. Nous avons présenté le modèle de requêtes permettant à la fois de formaliser les requêtes de l’utilisateur, mais également le contenu des messages échangés par les agents. Nous avons vu que ce modèle permettait de formaliser à la fois des requêtes en services, des requêtes ou assertions à propos des capacités des agents mais aussi des requêtes présentant des dépendances avec d’autres, couvrant ainsi plusieurs domaines d’applications tels que le web.

Dans ce chapitre, nous avons également présenté l’ACL utilisé par les agents pour qu’ils puissent à la fois communiquer mais aussi gérer directement les besoins de l’utilisateur avec lequel ils interagissent.

Dans le chapitre suivant, nous allons proposer des scénarios d’éxecution des modules implémentés avec la plate forme JADE.

Chapitre 5 Implémentation

Page 80

1. Introduction

Dans ce dernier chapitre, nous allons décrire l’environnement d’implémentation et la structuration logicielle, enfin quelques imprimes écrans d’illustration de notre application.

L’application développée englobe trois parties : la technologie J2EE pour le Web, la plate forme JADE pour un environnement SMA, une application développée sous Jbuilder qui présente l’Atelier.

2. La technologie J2EE

J2EE est l’acronyme de Java 2 Entreprise Edition. Cette édition est dédiée à la réalisation d’applications pour entreprise.

FIG. 5.1— Architecture générale du J2EE

Le client, dans une application J2EE, peut être une page HTML ou une applet s’exécutant dans un navigateur, une application Java sur une machine de bureau ou même un client Java sur un périphérique portable, comme un assistant numérique personnel (ANP) ou un téléphone cellulaire.

Le niveau intermédiaire peut contenir des pages JavaServer™ ou des servlets exécutés sur un serveur Web. Ces éléments constituent généralement la logique de présentation côté serveur. Un conteneur EJB fournit un environnement d’exécution pour les Enterprise JavaBeans™, qui contient la logique métier de l’application. Un serveur Web et un


Page 81

conteneur EJB (Enterprise JavaBeans) fournissent tous deux des services aux composants qui s’exécutent sur eux. Puisque ces services sont toujours disponibles, les programmeurs n’ont pas à les inclure dans les composants qu’ils écrivent.

Le niveau de système d’informations d’entreprise (EIS, Enterprise Information System) est un référentiel pour les données de l’entreprise. Il est composé généralement de données d’un système de base de données relationnelle.

FIG. 5.2— Principe de fonctionnement du J2EE

2.1. les fonctions couvertespar J2EE

L’édition Entreprise de JBuilder comprend de nombreuses fonctions pour aider votre équipe à développer des applications J2EE. Voici les technologies dont dispose JBuilder pour vous aider à développer le niveau client :

2.1.1. Technologies du niveau client

• Applets : Les applets sont un type spécial d’application Java qui sont téléchargées et exécutées par un navigateur Web sur une machine client. Pour commencer le développement d’une applet dans JBuilder, utilisez l’expert Applet. Pour plus d’informations sur l’utilisation des applets, voir “Utilisation des applets” dans le Guide du développeur d’applications web.

• Applications d’interface utilisateur Java : JBuilder comporte plusieurs fonctions qui peuvent vous aider à développer une application s’exécutant sur une machine client. Commencez une application Java en utilisant l’expert Application. Poursuivez la conception de votre interface utilisateur à l’aide du concepteur d’interface utilisateur de JBuilder. Créez votre interface utilisateur en ajoutant des composants d’interface utilisateur à partir de la palette de composants de JBuilder. Pour plus d’informations


Page 82

sur le concepteur d’interface utilisateur de JBuilder, voir “Conception visuelle dans JBuilder” dans Conception d’applications avec JBuilder.

2.1.2. Technologies du niveau intermédiaire

Voici les technologies J2EE du niveau intermédiaire qui utilisent un serveur Web :

• Servlets : Une servlet est une application Java côté serveur pouvant traiter les requêtes issues des clients. Les servlets répondent aux requêtes en générant des sorties dynamiques renvoyées au client. Vous pouvez commencer à développer des servlets à l’aide de l’expert Servlet de JBuilder Pour plus d’informations sur les servlets et leur développement.

• Pages JavaServer (JSP) : Les pages JavaServer (extension de la technologie servlet) offrent une façon simplifiée de développer des servlets. Comme les servlets, elles génèrent des sorties dynamiques qui sont renvoyées au navigateur Web du client. Commencez le développement de pages JavaServer avec l’expert Page JavaServer de JBuilder.

FIG. 5.3— fonctionnement d’une JSP Voici les technologies J2EE du niveau intermédiaire qui utilisent un conteneur EJB :

• Enterprise JavaBeans (EJB) Les Enterprise JavaBeans sont des composants côté serveur qui contiennent la logique métier de l’application. JBuilder vous assiste dans la construction des composants EJB 1.x et EJB 2.0.

2.1.3. Autres technologies J2EE

Sans être confinées dans un niveau d’architecture particulier, ces technologies contribuent au bon déroulement des opérations :

• JDBC (Java Database Connectivity) : JDBC est la norme utilisée pour accéder à votre base de données sur le niveau des systèmes d’information d’entreprise


Page 83

(Enterprise Information Systems, EIS). JDBC définit une API Java que vous utilisez pour écrire des instructions SQL envoyées à votre base de données.

JBuilder inclut DataExpress, une bibliothèque de composants pour l’accès aux données de votre base de données. Elle connecte votre application à votre base de données à l’aide de pilotes JDBC.

JBuilder inclut également JDataStore, une bibliothèque de composants et une base de données imbriquée entièrement Java. Vous accédez à JDataStore par l’intermédiaire de JDBC.

Les beans entité, qui accèdent aux lignes de votre base de données, vous connectent également à vos données via JDBC.

• JMS (Java Message Service) : JMS est un service de messagerie d’entreprise qui achemine les messages entre les composants et s’exécute dans une application distribuée.

• JNDI (Java Naming and Directory Interface): Tous les serveurs J2EE utilisent JNDI, un service de nommage Java utilisé pour localiser les objets distribués.

• XML (Extensible Markup Language) : Bien que XML ne soit pas réellement une technologie J2EE, ce langage est largement utilisé par les technologies J2EE. Par exemple, les descripteurs de déploiement des composants Web et des enterprise beans sont écrits en XML. Ces descripteurs décrivent le comportement des composants lorsqu’ils sont déployés. JBuilder comprend plusieurs fonctionnalités XML qui vous aident à accomplir les tâches de programmation communes que vous pouvez rencontrer dans vos projets J2EE.

3. L’environnement de développement

3.1. Choix de langage de programmation

Java est un langage de programmation récent (les premières versions datent de 1995) développé par Sun MicroSystems. Il est fortement inspiré des langages C et C++.

On a choisi d’utiliser la langage Java par l’assistance de Jbuilder qui va nous permettre d’informatiser nos idées : construire notre application (acquérir dynamiquement les données, afficher graphiquement le résultat).


Page 84

3.2. JBuilder : environnement de développement intégrant Java

JBuilder est un environnement intégré Java qui, associé à un serveur d’applications de sociétés comme Borland, BEA, IBM, SUN et Sybase simplifie et accélère considérablement le développement d’applications J2EE.

4. La plate forme JADE

Le meilleur moyen pour implémenter un système multi-agent (SMA) est d'utiliser une plate-forme multi-agent. Une plate-forme multi-agent est un ensemble d'outils nécessaires à la construction et à la mise en service d'agents au sein d'un environnement spécifique. Ces outils peuvent servir également à l'analyse et au test du SMA ainsi créé. Ces outils peuvent être sous la forme d'environnement de programmation (API) et d'applications permettant d'aider le développeur. Nous allons étudier dans cette partie la plate-forme JADE (Java Agent DEvelopment framework).

4.1. Brève description de JADE

JADE (Java Agent DEvelopement framework) est une plate-forme multi-agent créé par le laboratoire TILAB et décrite par Bellifemine et al. Dans [Bellifemine et al, 1999] [Bellifemine et al, 2000]. JADE permet le développement de systèmes multi-agents et d'applications conformes aux normes FIPA [Fipa, 2002]. Elle est implémentée en JAVA et fourni des classes qui implémentent « JESS » pour la définition du comportement des agents. JADE possède trois modules principaux (nécessaire aux normes FIPA).

• DF « Director Facilitor » fournit un service de « pages jaunes» à la plate-forme ; • ACC «Agent Communication Channel » gère la communication entre les agents ; • AMS « Agent Management System » supervise l'enregistrement des agents, leur

authentification, leur accès et l'utilisation du système.

Ces trois modules sont activés à chaque démarrage de la plate-forme.

4.2. La norme FIPA

La FIPA (Foundation for Intelligent Physical Agents) est une organisation à but non lucratif fondée en 1996 dont l'objectif est de produire des standards pour l'interopération d'agents logiciels hétérogènes. Par la combinaison d'actes de langages, de logique des prédicats et d'ontologies publiques, la FIPA cherche à offrir des moyens standardisés permettant d'interpréter les communications entre agents de manière à respecter leur sens initial, ce qui est bien plus ambitieux que XML, qui ne standardise que la structure syntaxique des documents. Afin d'atteindre ce but, le FIPA émet des standards couvrant :


Page 85

• Les applications (applications nomades, agent de voyage personnel, applications de diffusion audiovisuelles, gestion de réseaux, assistant personnel…) ;

• Les architectures abstraites, définissant d'une manière générale les architectures d'agents ;

• Les langages d'interaction (ACL), les langages de contenu (comme SL, CCL, KIF ou RDF) et les protocoles d'interaction ;

• La gestion des agents (nommage, cycle de vie, description, mobilité, configuration);

• Le transport des messages : représentation (textuelle, binaire ou XML) des messages ACL, transport (par IIOP, WAP ou HTTP) de ces messages.

Ces standards évoluent, et sont régulièrement mis à jour, ainsi que de nouveaux standards qui sont nouvellement proposés. Les standards qu'édicte la FIPA ne constituent pas vraiment une plate-forme de construction multi-agents. Ce n'est pas non plus l'objectif que s'est fixé la FIPA. Tout au plus, la FIPA normalise une plate-forme d'exécution standardisée dans un but d'interopérabilité. Ces normes s'appliquent donc pour la plupart en phase de déploiement. Elles n'abordent pas les phases d'analyse ni de conception. Elles peuvent cependant guider certains choix d'implémentation.

4.3. Architecture logicielle de la plate-forme JADE

JADE reprend donc l'architecture de l'Agent Management Reference Model proposé par FIPA. Les différents modules présentés dans la figure suivante sont présentés sous forme de services. Les services de base proposés sont le Directory Facilitator (DF) et l'Agent Management System (AMS). Il est possible de lui demander de tenir en plus le service de Message Transport Service (MTS) pour communiquer entre plusieurs plates-formes. Mais ce service sera chargé à la demande pour ne conserver par défaut que les fonctionnalités utiles à tout type d'utilisation. L'agent est l'acteur fondamental de la plate-forme, un Agent Identifier (AID) identifie un agent de manière unique. Le DF est un composant qui fait office d'annuaire. C'est un service de « pages jaunes » qui permet de mettre en relation les agents avec leurs compétences. Un agent peut enregistrer ses compétences dans le DF ou interroger le DF pour connaître les compétences proposées par les autres agents. L'AMS est un autre composant important car il contrôle l'accès et l'utilisation de la plate-forme et maintient un répertoire contenant les adresses de transport des agents de la plate forme. Ce service est plus un service de type « pages blanches » qui effectue la correspondance entre l'agent et l'AID. Chaque agent doit s'enregistrer à un AMS pour avoir un AID. Il n'y a qu'un AMS par plate-forme. Le MTS est une méthode par défaut de communication entre agents de différentes plates-formes. Cela permet l'interconnexion entre systèmes hétérogènes ou tout au moins


Page 86

de système ne communicant pas de la même façon. L'Agent Platform (AP) constitue l'infrastructure physique sur laquelle se déploient les agents. Il contient le DF, l'AMS et le MTS. Lorsqu'on parle de AP, on inclut souvent le matériel électronique, l'OS, le software et les composants cités ci-dessus avec les agents. Enfin, l'Agent Identifier (AID) est un identifiant précis d'un agent. On lui donne plusieurs paramètres tels que l'adresse de transport, l'adresse de service de résolution de nom, … Un exemple est : name@HAP (Home Agent Platform)

FIG. 5.4 — Architecture logiciel de La plate-forme JADE

Dans la plate-forme JADE, deux méthodes sont fournies par la classe Agent afin d'obtenir l'identifiant de l'agent DF par défaut et celui de l'agent AMS : getDefaultDF() et respectivement getAMS(). Ces deux agents permettent de maintenir une liste des services et des adresses de tous les autres agents de la plate-forme. Le service DF propose quatre méthodes afin de pouvoir :

• Enregistrer un agent dans les pages jaunes (register). • Supprimer un agent des pages jaunes (deregister). • Modifier le nom d'un service fourni par un agent (modify). • Rechercher un service (search).

Le service AMS s'utilise généralement de manière transparente (chaque agent créé est automatiquement enregistré auprès de l'AMS et se voit attribué une adresse unique). Ces deux services fournissent donc les annuaires qui permettent à n'importe quel agent de trouver un service ou un autre agent de la plate-forme.

4.4. Langage de communication de la plate-forme JADE

Le langage de Communication de la plate-forme JADE est FIPA-ACL (Agent Communication language). La classe ACLMessage représente les messages qui peuvent


Page 87

être échangés par les agents. La communication de messages se fait en mode asynchrone. Lorsqu'un agent souhaite envoyer un message, il doit créer un nouvel objet ACLMessage, compléter ces champs avec des valeurs appropriées et enfin appeler la méthode send(). Lorsqu'un agent souhaite recevoir un message, il doit employer la méthode receive() ou la méthode blockingReceive(). Un message ACL dispose obligatoirement des champs suivants :

Performative : type de l'acte de communicationSender : expéditeur du message

Receiver : destinataire du message reply-to : participant de la communicationcontent : contenu du message language : description du contenu encoding : description du contenu ontology : description du contenu protocol : contrôle de la communication

conversation-id : contrôle de la communication reply-with : contrôle de la communication in-reply-to : contrôle de la communicationreply-by : contrôle de la communication

Tous les attributs de la classe ACLMessage peuvent être obtenus et modifiés par les méthodes set/get(). Le contenu des messages peut être aussi bien du texte que des objets car la sérialisation Java est supportée.

5. Exemple d’application

Dans notre application, on a une architecture client (Atelier + Agent Production (APr)) / Serveur (Web + 4 agents). Dans le coté client, l’utilisateur va créer un nouveau projet qui va contenir un ensemble de ressources. À un certain moment une ou plusieurs ressources tombent en panne. Pour la résolution de cette panne, on a proposé un outil d’aide à la décision à base de Web qui va aider l’utilisateur à choisir la tâche à effectuer par exemple : réparer la ressource, commander une nouvelle ressource,.. À ce moment là, l’Agent Production (APr) va récupérer la liste des ressources en panne et l’envoyer au serveur. La réception de cette liste va être par l’Agent Analyseur (AA).

5.1. Création d’un nouveau projet

Du coté client, l’utilisateur va créer un nouveau projet nommé « prod » (Figure 5.5) et l’enregistrer (Figure 5.6).


Page 88

FIG. 5.5 — Création d’un nouveau projet

FIG. 5.6 — L’enregistrement d’un nouveau projet

5.2. Affectation des ressources au projet

Le projet « prod » contient huit (8) ressources qui sont de différents types (Imprimantes, Ordinateurs_Portables). Chaque ressource est identifiée par : Nom de ressource, Type de ressource, Temps_Début, Temps_Fin, Fournisseur (Figure 5.7) (Figure 5.9), après la sélection du Type de ressource (Imprimante ou Ordinateurs_Portable), on clique sur le bouton pour sélectionner d’autres attributs : Marque, Catégorie,

Référence. (Figure 5.8) (Figure 5.10).

Soit la Ressource 1 de type Imprimante (Figure 5.7).


Page 89

FIG. 5.7 — Affectation des ressources au projet (Imprimante) En cliquant sur le bouton la fenêtre suivante apparaîtra :

FIG. 5.8 — Détails sur les ressources de type « imprimante »


Page 90

Soit la Ressource 2 de type Ordinateur_Portable (Figure 5.9).

FIG. 5.9 — Affectation des ressources au projet (Ordinateurs_Portables)

En cliquant sur le bouton la fenêtre suivante apparaît:

FIG. 5.10 — Détails sur les ressources de type « Ordinateur Portable »


Page 91

5.3. Traitement de l’évènement panne

5.3.1. Exécution des ressources

La Figure 5.11 montre l’exécution des ressources.

FIG. 5.11 — Exécution des ressources

5.3.2. Provocation de panne de quelques ressources

La Figure 5.12 montre que la ressource 2 et la ressource 8 sont toujours en cours d’exécution par contre les ressources 1, 3, 4, 5, 6, 7 sont en panne.


Page 92

FIG. 5.12 — Provocation de panne

Pour obtenir les détails sur la panne, on clique sur : on aura la fenêtre suivante :

FIG. 5.13 — Détails sur la panne


Page 93

Si la ressource est de type « imprimante », en cliquant sur le bouton on aura la fenêtre suivante :

FIG. 5.14 — Diagnostic de panne des imprimantes Si la ressource est de type « Ordinateur Portable », en cliquant sur le bouton on aura la fenêtre suivante :

FIG. 5.15 — Diagnostic de panne des Ordinateurs _Portables


Page 94

5.4. Résolution de panne

En cliquant sur le bouton « envoyer », l’Agent Production (APr) va récupérer la liste des ressources en panne. (Figure 5.16).

FIG. 5.16 — Linterface de l’Agent Production (APr)

En cliquant sur le bouton , on va activer l’Agent Analyseur (AA) qui va analyser et filtrer cette table. (Voir la figure 5.17).

FIG. 5.17 — L’interface de l’Agent Analyseur (AA)


Page 95

En cliquant sur le bouton , on va activer l’Agent Coordinateur (AC) dont l’interface est montrée dans la figure 5.18.

FIG. 5.18 — L’interface de l’Agent Coordinateur (AC) On commence par la recherche de la première ressource, donc on clique sur le bouton « Recherche ressources sur Web » qui va activer l’Agent Ressource. (Figure 5.19).

FIG. 5.19 — L’interface de l’Agent Ressource (AR)

Recherche


Page 96

En cliquant sur le bouton « Recherche », l’Agent Ressource (AR) va chercher sur le web la référence de la ressource en panne en parcourant plusieurs pages web. (Figure 5.20).

FIG. 5.20 — Exemple des pages web Comme résultat de la recherche, on aura la fenêtre suivante (Figure 5.21).

FIG. 5.21 — Résultat de recherche (succés)


Page 97

Dans le cas contraire, on aura la fenêtre suivante. (Figure 5.22).

FIG. 5.22 — Résultat de recherche (échec)

En cliquant sur le bouton « Recherche solution sur le Web », on va activer l’Agent Proposition (AP) (Figure 5.23). Ce dernier va lancer une recherche de la solution, comme cela est montré à la figure 5.24. La solution sera envoyée au client.

FIG. 5.23 — Linterface de l’Agent Proposition (AP)

Recherche


Page 98

FIG. 5.24 — Dépannage des imprimantes La communication entre les agents est présentée par la figure suivante : (Figure 5.25)

FIG. 5.25 — Interaction entre les agents (plate forme JADE)


Page 99

6. Conclusion

Dans ce chapitre, nous avons défini l’architecture de développement ainsi que

l’environnement d’interaction. Plusieurs écrans d’affichage sont proposés par la suite,

pour donner un aperçu sur la prise de décision en utilisant la technologie Web et les

différents agents composant notre système à savoir l’Agent de Production (APr), l’Agent

Analyseur (AA), l’Agent Coordinateur (AC), l’Agent Ressource (AR) et l’Agent Proposition

(AP).

Conclusion Générale & Perspectives

Page 100

Les Systèmes d’Aide à la Décision (SIAD) reposent de plus en plus souvent sur des systèmes informatiques qui sont chargés de fournir aux décideurs le maximum d’éléments dans les meilleurs délais et qui l’aideront dans sa prise de décision.

Avec l’apparition des SIAD à base de web (Web-based DSS), la prise de décision par l’utilisateur est devenue plus efficace et rapide, c’est ce qu’on a conclu d’après les résultats obtenus.

Pour rendre notre application automatique et intelligente, on a intégré des agents dans notre SIAD à base de Web pour faciliter la recherche sur le Web et la proposition des solutions aux problèmes d’utilisateurs.

En effet, Les agents sont conçus pour être des solveurs autonomes de problèmes (problems resolvers), et de ce fait ils peuvent communiquer entre eux et avec les utilisateurs. Tout en étant suffisamment dotés de capacités cognitives pour effectuer un raisonnement sur un problème précis, ils sont capables de prendre certains types de décisions et exécuter les actions associées. Les agents sont beaucoup plus efficaces pour automatiser une tâche de résolution d’un problème qu’un système d’aide à la décision ou bien un système tout court.

L’incorporation d'agents dans un système en général, lui offre l'opportunité de participer directement à l'implémentation de décisions par l'exécution d'actions directes sur le domaine. La capacité de planification des agents peut aussi aider dans différentes prises de décision. Nous allons montrer dans la table1 qu’à chaque étape du processus classique de Simon correspondent une ou plusieurs sous-tâches.

Tout en étant une partie constituante de la résolution de problème dans le domaine, un agent peut choisir des sources d'information particulières à utiliser. La collecte de Données peut être une fonction dans un agent (détectant), ou une activité dévouée d'un agent spécialisé d'information si la tâche est complexe. Le but est de maintenir un modèle exact du domaine pour le but de la classe de tâches devant être exécutées. Une fois créées, les alternatives peuvent être arbitrées parmi par l'agent lui-même, ou à défaut par la communication avec un autre agent ou avec l'utilisateur qui fait le choix de la sélection finale.

Cette approche par l’aide à la décision est appliquée grâce à un système multi-agents qui adopte des protocoles de coordination et de négociation entre agents comme moyens d’interaction. Les agents responsables de la production ont une architecture robuste reposant essentiellement sur un mécanisme de raisonnements, autonomes et adaptatifs, ils présentent une capacité de prise de décision et un certain nombre de comportements leur permettant de gérer des situations de conflits sur l’utilisation de ressources critiques.

La coordination étant assurée par un agent appelé agent coordinateur.

Conclusion Générale & Perspectives

Page 101

Ce qui concerne les perspectives pour notre travail :!!!

− Utiliser la même architecture mais en utilisant des agents mobiles.

− Utiliser des services Web, au lieu l’utilisation des agents où bien les combiner.

p

co

T

CF

a

aS

ch

«

F

[Abrudan, proiectare s

[Adamou, conduite deobjet », Thè

[Afnor, 19Technical R

[Akrout, 2Colloque InFès, Maroc,

[Anthony, analysis ». H

[Azvine et and Soft CoSpring-Verl

[Bellifemincompliant ahas been al1999.

[Bellifemin« Jade Prog

[Bénassy, 1

[Bessedik eFramework

1996] : Absi managem

1997] : Ades systèmes fèse de docto

88] : AfnorReport X50-

2001] : Aknternational, 24-26 Oct

1965] : AnHarvard Un

al., 2000] :omputing : Plag. 2000.

ne et al, 199agent framelso publish

ne et al, 20grammer’s

1987] : Bén

et Taghezouk for a Web

brudan I. –ment », Ed. D

damou M. –flexibles d'

orat, Univer

r, « Concep- 310, Agen

krout, M. 2l Conceptioobre, 2001.

nthony, R. «niversity Pre

Azvine, B.Prospects, T

99]: Bellifeework », CSed in Proce

000] : BelliGuide », Ja

nassy, J. « La

ut, 2009] : b-based Dec

– « SistemeDacia, Cluj-

– « Contrib'assemblagersité de Fran

pts fondamence française

2001. « Mion et Produ

« Planing aess. 1965.

., Azarmi, NTools and A

emine F., PoSELT interneedings of

ifemine F., ade version.

a gestion de

Bessedik. Icision Supp

Réf

e flexibile d-Napoca, 19

bution à la e à l'aide denche-Comté

entaux de le de normal

ise en plauction Intég

and control

N., and NauApplications

oggi A., Rimnal technicaPAAM’99,

Giovani C2000.

e la product

I., and Taghport System

férences bi

de fabricati996.

modélisatioes réseaux dé, 1997.

la gestion dlisation, 198

ce d’une grées, CPI 2

systems : A

uck, D. « Ins », volume

massa G., « al report. Pa, London, p

C., Tiziana

tion ». 1987

hezout. N., :m Applied to

ibliographi

Page

ie - concep

on en vue de Petri ori

de producti88.

G.P.A.O ». 2001, articl

A framewor

telligent Syse 1804 of L

JADE – A art of this rpp.97-108,

T., Rimass

7.

« A Multi-o Manufact

iques

e 102

pte de

de la ientés

ion ».

2ème le 77,

rk for

stems NCS.

FIPA report April

sa G.,

agent turing

Références bibliographiques

Page 103

System », Conférence Internationale sur l'informatique et ses applications, CIIA'09, Saida, pp. 60-70, 03-04 Mai 2009.

[Bessedik et Taghezout, 2010] : Bessedik. I., and Taghezout. N.,: « Decentralized multi-agent Coordination in a Web-based DSS: Application to Resource Allocation Problems », Internatonal Congress On Models, Optimization and Security Of Systems, ICMOSS’2010, Tiaret, pp. 401-404, May 29-31, 2010.

[Bharati et Chaudhury, 2004 ] : Bharati. P., and Chaudhury, A.,: « An empirical investigation of decision-making satisfaction in Web- based decision support systems », Decision Support Systems 37 (2), pp. 187-197, 2004.

[Billaut, 2005] : Billaut. J-C., et Moukrim. A., : « Introduction à la flexibilité et à la robustesse en ordonnancement dans Flexibilité et robustesse en ordonnancement » (Billaut). Sciences publications Lavoisier Hermes. Paris, 2005 .

[Bitran et Tirupati, 1993] : Bitran, G. et Tirupati, D. « Hierarchical production planning, logistics of production and inventory ». Handbooks in operations research and management science. 1993.

[Boussetta et al, 1998] : Boussetta S., El Fallah-Seghrouchni A., Haddad S., Moraitis P., Taghelit M. « Coordination d’agents rationnels par planification distribuée » Revue d’Intelligence Artificielle, Vol 12, n°1, 1998.

[Burkhart, 1994] : Burkhart, R. « The SWARM multi-agent simulation system ». In Object Oriented Programming Systems, Languages and Applications (OOPSLA), 1994.

[Carlier et Chrétienne, 1988] : Carlier, J. et Chrétienne, P. « Problèmes d’ordonnancement ». Masson. 1988.

[Chaib-draa, 1996] : Chaib-draa, B et Moulin, B, «An overview of Distributed Artificial Intelligence », in Foundations of Distributed Artificial Intelligence, 1, G.M.P. O’Hare et N.R. Jennings eds., J.Wiley and ssons, pp. 3.55, 1996.

[Charif et Sabouret, 2004]: Charif, N., Sabouret. N. : « A Model of Interactions about Actions for Active and Semantic Web Services ». In Proc. Semantic Web Service workshop at 3rd International Semantic Web Conference (ISWC’04), pages 31–46, 2004.

[Chebeane et Echalier, 1997] : Chebeane H., Echalier F. « Reactive object-oriented modeling of real time control », in proceedings of the Conference on Emerging Technologies and Factory Automation ETFA, Los Angeles, USA, pp, 387-390, 1997.


Page 104

[Courtois et al., 2006] : Courtois, A., Pillet, M. et Martin-Bonnefous, C. « Gestion de la production ». 2006.

[Courtois, 1995] : Courtois. A., Pillet, M., et Martin. C., : « Gestion de Production ». Editions d'organisation, 2ème édition, 1995.

[Crouhy et Greif, 1991] : Crouhy, M. et Greif, M. « Gérer simplement la gestion de production : du plan directeur au suivi des ateliers ». Edition du Moniteur. 1991.

[Dagoumau, 2000] : Dagoumau. N., : « Contribution à la gestion des modes des systèmes automatisés de production ». Thèse de doctorat, Université des sciences et technologies de Lille, 2000.

[Daniels, 1999] : Daniels, M. « Integrating simulation technologies with swarm ». In Agent Simulation: Application, Models, and Tools, University of Chicago. 1999.

[Daniels, 2000]: Daniels, M. « An open framework for agent-based modeling ». In Applications of Multi-Agent Systems in Defence Analysis, Los Alamos National Labs.2000.

[Dauzère-P, 2005] : Dauzère-Pérès, S., Castagliola, P., et Lahlou. C. : « Niveau de service en ordonnancement dans Flexibilité et robustesse en ordonnancement » (Billaut). Sciences publications Lavoisier Hermes. Paris, 2005.

[Davis, 1989] : Davis, F.D.: « Perceived usefulness, perceived ease of use, and user acceptance of information technology », MIS Quarterly 13 (3) 319-340, 1989.

[Delen et al, 2007] : Delen, D., Sharda, R. and Kumar, P.: « Movie forecast guru: a Webbased DSS for hollywood managers », Decision Support Systems 43, doi:10.1016/ j.dss.2005.07.005, pp. 1151-1170, 2007.

[DeLone et McLean, 1992] : DeLone, W.H., et McLean, E.R.,: « Information systems success : the quest for the dependent variable », Information Systems Research 3(1), 60-95, 1992.

[Denis et Lesage, 1995] : Denis B., Lesage J.J. « Un panorama de la recherche en conception de la conduite des systèmes de production », La productivité dans un monde sans frontières, Congrès International de Génie Industriel de Montreal, Quebec, p.1537-1549, 1995.

[Dong et al, 2004] : Dong, J., Du, H.S., Wang. S., Chen, K. and Deng, X.,: « A framework of Web-based decision support systems for portfolio selection with OLAP and PVM », Decision Support Systems 3, pp. 367– 376, 2004.


Page 105

[Doumeinghts et al, 1983] : Doumeinghts et al, « la gestion de production assistée par ordinateur », Hermes publishing. 1983.

[Durfee et al, 1989] : Durfee E.H, Lesser V.R et Corkill D.D, « Coorperative distributed problem solving, in the handbook of artificial intelligence », vol IV, A Barr, P.R Cohen et E.A Feigenbaum (Ed), p.83-148, Addison-Wesley, 1989.

[Enginest, 2005] : Enginest, « ordonnancement de production » Enginest Software, Réf : ESD000013, Ver : 1.0, mars 2005, www.enginest.com.

[Erceau, 1993] : Erceau J., « Intelligence Artificielle Distribuée et Systèmes Multi-Agents de la théorie aux applications ». 23 ème Ecole Internationale d’Informatique de l’AFCET, Neuchâtel, 1993.

[Esquirol et Lopez, 1999] : Esquirol, P. et Lopez, P. « L’ordonnancement ». Economica. 1999.

[Esquirol, 1999] : Esquirol, P., et Lopez,. P. : « L’ordonnancement ». Ed. ECONOMICA, Collection GESTION. Série : Production et techniques quantitatives appliquées à la gestion, 1999.

[Ferber, 1995] : Ferber J., « Les systèmes multi-agents. Vers une intelligence collective », InterEditions, Paris, 1995.

[Fipa, 2002]: The FIPA ACL Message Structure Specifications. http://www.f ipa.org/ specs/fipa0 0061/,2002.

[Fradet et Rouvrais, 2002] : Fradet. P, Rouvrais. S ; « Agents mobiles pour services distribués » Projet LANDE Logiciel : analyse et développement. Rapport d’activité INRIA 2002.

[Friedman, 2005] : Friedman, T. L.: « The World Is Flat: A Brief History of the Twenty-First Century », Farrar, Straus and Giroux, 2005.

[Goglin, 2001] : Goglin J.F. : « Construction du datawarehouse », Hernès. 2001.

[Gotha, 1993] : Gotha. « Les problèmes d’ordonnancement ». RAIRO-Recherche opérationnelle / operation research. 1993.

[Grabot, 1998] : Grabot, B.: « Objective satisfaction assessment using neural nets for balancing multiple objectives », International Journal of Production Research, vol.36, n°9, pp. 2377-2395, 1998.


Page 106

[Guessoum, 1996] : Guessoum, Z. « Un Environnement Opérationnel de Conception et de Réalisation de Systèmes Multi-Agents ». PhD thesis, Laforia, Paris 6. 1996.

[Guntzer et al, 2007] : Guntzer, U., Muller, R., Muller, S. and Schimkat, R.D.: «Retrieval for decision support resources by structured models », Decision Support Systems 43, doi:10.1016/j.dss.2005.07.004, pp. 1117-1132, 2007.

[Guttman and Maes, 1998] : Guttman, R. Maes, P. « Agents-Mediated integrative negociation for retail electronic commerce ». In Pablo Noriega, C. S., editor, the 1st International Workshop on Agent Mediated Electronic Trading (AMET’98), LNCS, Pages 70-90, Minneapolis, MN, USA, Springer-Verlag, 1998.

[Holtzman, 1989] : Holtzman S. : « Intelligent decision systems », Addison Wesley, 1989.

[Huaiqing et al, 2002] : Huaiqing, W., Stephen, L., and Lejian, L.: « Modeling constraint-based negotiating agents », Decision Support Systems 33(2), pp. 201-217, 2002.

[Iyer et al, 2005] : Iyer, B., Shankaranarayanan, G., and Lenard, M.L.: « Model management decision environment: a Web service prototype for spreadsheet models », Decision Support Systems 40 (2), pp. 283– 304, August 2005.

[Keen et Scott-Morton, 1978] : Keen, P., and M. Scott-Morton: « Decision Support Systems: an organizational perspective », Addison-Wesley Publishing, 1978.

[Kersten et le Noronba, 1999] : Kersten, G.E. and Noronba, S.J.: « WWW-based negotiation support design, implementation, and use », Decision Support Systems 25 (2), pp. 135- 154, March 1999.

[Kohli et al, 2001] : Kohli, R., Piontek, F., Ellington, T., VanOsdol, T., Shepard, M., and Brazel, G.: « Managing customer relationships through E-business decision support applications: a case of hospital–physician collaboration », Decision Support Systems 32, pp. 171-187, 2001.

[Koning et Pesty, 2001]: Koning, J.L, and Pesty. S.: Modèles de communication, In J-P. Briot et Y. Demazeau, editor, « Principes et architecture des systèmes multi-agents ». Hermès, Lavoisier,2001.

[Kuljis et Paul, 2001] : Kuljis, J., and Paul, R.J. : « An appraisal of Web-based simulation: whether we wander? », Simulation Practice and Theory 9, pp. 37-54, 2001.


Page 107

[Lévine, 1989] : Lévine P. et J.Pomerol : « Systèmes Interactifs d’Aide à la Décision et systèmes experts », Editions Hermès, 1989.

[Lopez, 2001] : Lopez, P., et Roubellat, F. : « Ordonnancement de la production ». Ed. Hermes Science, 2001.

[Madkit, 2001] : MADKIT. http://www.madkit.org.

[Maes, 1994] : Maes P. « Agents that Reduce Work and Information Overload » Communications of the ACM, Vol. 37, pp.31-40. 1994.

[Malone et Crowston, 1994]: Malone, T.W., Crowston, K.: « The interdisciplinary study of coordination ». ACM Compus. Surv., 26 (1): 87-119, 1994.

[Malone, 1988] : Malone T.W., « What is coordination theory », in national science foundation coordination theory workshop, MIT, 1988.

[Marakas, 2003] : Marakas, G. : « Decision Support Systems in the Twenty-First Century », Upper Saddle River, N.J., Prentice Hall. 2003.

[Mazouz, 2001] : Mazouz, H. : « Ingénierie des protocoles d’interaction des systèmes distribués aux systèmes multi-agents ». Thèse de Doctorat, Université Paris IX-Dauphine, 2001.

[Mintzberg, 1979] : Mintzberg, H. : « The structuring of Organization », Prentice Hall, 1979.

[Mitra et Valente, 2007] : Mitra, G., and Valente, P.: « The evolution of Web- based optimization from ASP to e-services », Decision Support Systems 43, 1096--1116, doi:10.1016/j.dss.2005.07.003, 2007.

[Ngai et Wat, 2005] : Ngai, E.W.T., and Wat, F.K.T.: « Fuzzy decision support system for risk analysis in e-commerce development », Decision Support Systems 40 (2), pp. 235-255, August 2005.

[Ocello, 2003] : Occello, M. : « Méthodologie et architectures pour la conception de systèmes multi-agents ». Thèse HDR. Université Pierre Mendès France de Grenoble, 2003.

[Parunak, 1991] : Cité dans [Trentesaux, 2000].

[Power, 1997] : Power, D.J. : « What is DSS ? », The On-line Executive Journal for Data Intensive Decision Support 1 (3). 1997.


Page 108

[Power, 2002] : Power, D.J.: « Decision Support Systems: Concepts and Resources for Managers », Quorum Books, Wesport Conn, 2002.

[Ray, 2007] : Ray, J.J.: « A Web-based spatial Decision Support System optimizes routes for oversize/overweight vehicles in Delaware », Decision Support Systems 43, (this issue), doi:10.1016/j.dss.2005.07.007, pp. 1171-1185, 2007.

[Rodammer et White, 1988] : Rodammer, F. et White, K. « A recent survey of production scheduling ». IEEE transaction on systems, man and cybernetics. 1988.

[Roy et Bouyssou, 1993]: Roy. B. et D. Bouyssou : « Aide multicritère d’aide à la décision ». Economica, Paris, 1993.

[Shaw et al, 2002] : Shaw, N.G., Mian, A., and Yadav, S.B.: « A comprehensive agent-based architecture for intelligent information retrieval in a distributed heterogeneous environment ». Decision Support Systems 32 (4), pp. 34-42, 2002.

[Simon, 1977] : Simon, H. : « The New science of management decision », Prentice hall, Englewood-Cliffs. 1977.

[Sprague et Carlson, 1982] : Sprague R. and E. Carlson. : « Building Effective Decision Support Systems », Prentice-Hall, Inc, Englewood Cliffs. 1982.

[Sundarraj, 2004] : Sundarraj, R.P.: « AWeb-based AHP approach to standardize the process of managing service-contracts », Decision Support Systems 3, pp. 343-365, 2004.

[Taghezout, 2008] : Taghezout, N., Zaraté, P.: « Negotiation Process for Multi-Agent DSS for Manufacturing System », in : Collaborative Decision Making: Perspectives and Challenges, P. Zaraté et al. ,ed., IOS Press, Vol. 176, Frontiers in Artificial Intelligence and Applications, pp. 49--60, 2008

[Tahon, 2003] : Tahon., C. : « Evaluation des performances des systèmes de production ». Editions Lavoisier, 2003.

[Trentesaux, 1996] : Trentesaux, D, « conception d’un système de pilotage distribué, supervisé et multicritère pour les systèmes automatisés de production. », Thèse de doctorat, Institut National Polytechnique de Grenoble, France, 1996.

[Trentesaux, 2002] : Trentesaux., D. : « Pilotage hétérarchique des systèmes de production ». Thèse d’habilitation. Université de Valenciennes et du Hainaut-Cambrésis (UVHC), 2002.


Page 109

[Turban, 1993] : Turban E. : « Decision Support and Expert Systems », New York, Macmillan. 1993.

[Turban, 1995] : Turban E. : « Decision Support and Expert Systems », New York, Macmillan. 1995.

[Turban, 1998] : Turban, E. and Aronson, J. : « Decision Support and Intelligent systems », Prentice-Hall International, Upper Saddle River, New Jersey. 1998.

[Vacher, 2000] : Vacher, J. : « Un système adaptatif par agents avec utilisation des algorithmes génétiques multi-objectifs : Application à l’ordonnancement d’atelier de type job-shop N *M ». Thèse de Doctorat. Université du HAVRE, 2000.

[Vincent, 2003] : GIARD Vincent, « Gestion de la production et des flux »,3`eme Edition, Economica, Paris, 2003.

[Weiss, 1999] : Weiss G. « Multi-agent Systems », MIT Press. 1999.

[Wooldridge et Ciancarini, 2000] : Wooldridge M., Ciancarini P. « Agent-Oriented Software Engineering : The state of the art » Lecture Notes in AI, Vol. 1957: Springler-Verlag, 2000.

[Zaraté, 1991] : Zaraté P. : « Conception et mise en œuvre de systèmes Interactifs d’Aide à la Décision : Application à l’élaboration des plannings de repos du personnel navigant », thèse de doctorat de l’université Paris Dauphine, France. 1991.

[Zhang et Goddard, 2007] : Zhang, S., Goddard, S.: « A software architecture and framework for Web-based distributed decision systems », Decision Support Systems 43, doi:10.1016/ j.dss.2005.06.001, pp. 1133-1150, 2007.

Références Webliographiques

http://www.telecomitalialab.com/

http://www.fipa.org/specs/fipa00001/





Abstract / Résumé Abstract The Combination between Web services and software agents provides a promising computing

paradigm for efficient service selection and integration of inter-organizational business

processes. This thesis proposes an agent-based Web DSS; the main contribution of our study

is to provide an efficient tool that helps users find information resources available as an online

service within Intranet. The decision-making is not only guided by the information provided

by DSS but rather than the Web technology, the process is entirely based on communication

between ISP Agents and Web agent. While negotiating compromises for conflict solving to

share common resources, decision centres use Web service to conduct various complementary

tasks.

Résumé La combinaison entre les services Web et les agents software fournit un outil efficace pour

l’aide à la décision. Notre thèse propose un Web DSS à base d’agents ;la contribution

principale de notre étude doit fournir un outil efficace qui aide les utilisateurs à trouver des

ressources d’information disponibles comme service en ligne dans l'Intranet. La prise de

décision est non seulement guidée par l'information fournie par DSS mais plutôt aussi par la

technologie de Web, le processus est entièrement basée sur la communication entre l'agent

ISP et les agents de Web. Tandis que la négociation compromet pour le conflit résolvant

pour partager les ressources communes, les centres de décision emploient le service Web pour

conduire de diverses tâches complémentaires.

SIAD (Systèmes Interactifs d’Aide à la Décision) ; SIAD à base de Web (Web-DSS) ;

Systèmes-Multi-Agents (SMA) ; Décision ; Systèmes d’aide à la décision (SAD) ;

technologies web ; gestion de production dynamique ; agents ; communication, coordination.

Mots clés

Documents

REALISATION D’UN WEB-DSS A BASE D’AGENTS …theses.univ-oran1.dz/document/TH3236.pdfMr ABDI Mustapha Kamel Maître de Conférence à l’Université d’Oran (Président) Mr BOUAMRANE