Rapport Supervision PDF

Conception et Réalisation d’un Système de
Supervision Informatique à base

d’Agents Mobiles
BOUSSALEM Assam
ZERARA Younes
2007/2008
Ministère de l’enseignement supérieur et de la recherche
scientifique
Institut National de formation en Informatique (I.N.I)
Oued-Smar, Alger
Mémoire de fin d’études

Pour l’obtention du diplôme d’Ingénieur
d’Etat en Informatique
Option : Systèmes Informatiques
Thème
Conception et Réalisation d’un Système de Supervision
Informatique à base d’Agents Mobiles
Réalise par Encadré par

- Mr. BOUSSALEM Assam - Mr. HAFRI Younes
- Mr. ZERARA Younes - Mr. MENACER Djamel-Eddine
PROMOTION : 2007/2008
INSTITUT NATIONAL D’INFORMATIQUE
Conception et Réalisation d’un Système de Supervision

Informatique à base d’Agents Mobiles
BOUSSALEM Assam
ZERARA Younes
INEODEV Limited / INI
MEMOIRE PRÉSENTÉ EN VUE DE L'OBTENTION

DU DIPLÔME D’INGENIEUR D’ETAT EN INFORMATIQUE
(SYSTEMES INFORMATIQUES)
SEPTEMBRE 2008
© BOUSSALEM Assam, ZERARA Younes, 2008.

Remerciement
AU NOM DE DIEU TOUT PUISSANT, CLEMENT ET MISERICORDIEUX
Nous remercions ALLAH le tout puissant de nous avoir donné la force et le courage
pour réaliser ce travail.
Nos vifs remerciements, accompagnés de toute notre gratitude, vont tout d’abord à notre
promoteur Mr. Djamel-Eddine MENACER, et à notre Co-promoteur Mr. Younes HAFRI,
pour nous avoir proposé ce sujet, pour les conseils utiles qu’ils n’ont cessé de
nous prodiguer, les orientations et l’intérêt qu’ils nous ont montré
durant la progression de ce travail.
Nous tenons à remercier les membres du jury pour l’honneur qu’ils nous ont fait en
acceptant de juger ce travail.
Notre reconnaissance va particulièrement à Melle. CHEURFI Halima, Melle. BOULEFAAT

Habiba, Melle. MEDJADBA Sanaa, Mr. DEMIL Rezki et Melle. AIT ADDA Samia,
pour leurs aides et conseils.
Ce travail n’aurait sans doute pu voir le jour sans le soutien de nos parents, nos proches et
de nos amis, que nous les remercions affectueusement.
Que tous ceux, de près ou de loin, ont contribué, par leurs conseils, leurs encouragements
ou leur amitié, à l’aboutissement de ce travail, trouvent ici l’expression
de notre profonde reconnaissance.
IV
Dédicaces
Younes
A mon père mon professeur de toujours, et ma très chère mère
Pour leurs soutien et encouragements.
A mes proches et toute ma famille.
A mes amis et tous les gens qui m’aiment.
A tous ceux qui sont proches de mon cœur et dont je n’ai pas cité le nom.
Au bonheur des plus chers.
Je dédie ce modeste travail.
Assam
Je dédie cet humble travail,
À mes très chers parents, pour leurs amour et sacrifices,
À mes adorables sœurs ; Imene, Asma et Aya pour leur patience,
À mes proches amis et toute ma grande famille, pour leurs soutient et encouragements,
À toutes les personnes qui connaissent Assam de prés ou de loin, et surtout,
À Okba, Noureddine, Nabil, Khaled, Imane, Adel et Souad,
Seulement pour leur existence.
V
Résumé
Les systèmes multi-agents font de nos jours l’actualité dans le
domaine de l’intelligence artificielle ainsi que dans le développement
des applications distribuées autonomes. Ils touchent divers domaines
qui visent une automatisation des tâches de l’homme, entre autres,
les systèmes de supervision qui sont indispensables dans les systèmes
informatiques de l’entreprise.
Le présent travail consiste à l’étude d’une architecture basé sur

les agents mobiles orientée ‘’Monitoring Informatique’’. Dans ce
cadre, nous allons présenter les notions de base de la supervision
informatique et ses logiciels les plus utilisés actuellement, puis nous
étudierons le nouveau paradigme multi-agent, ainsi que le concept
d’agent mobile; et nous proposerons une architecture alternative que
nous évaluons et critiquons par la suite.
Mots clés : Agent, système multi-agents, agent mobile, système de

supervision/monitoring.
VI
Sommaire
Liste des figures ...................................................................................................................... XI

Introduction générale ............................................................................................................... 1
1. Contexte de travail ..............................................................................................................1
2. Problématique ................................................................................................................... 2
3. Objectifs ............................................................................................................................. 3
4. Organisation du mémoire ................................................................................................. 3
PARTIE 1: Etat de l'art

Chapitre 1 : La Supervision Informatique ................................................................................ 5
1 Introduction ............................................................................................................................ 5
2 Définition de la supervision informatique ........................................................................... 5
3 Fonctionnalités et niveaux d’information ............................................................................ 6
3.1 Informations sur les systèmes ..................................................................................... 7
3.2 Informations sur les réseaux ....................................................................................... 7
3.3 Informations sur les applications et services ............................................................. 7
4 Rôle de la supervision ............................................................................................................ 7
5 Aspects de la supervision ......................................................................................................8
6 Protocole SNMP .....................................................................................................................8
6.1 Définition du protocole SNMP ........................................................................................ 9
6.2 Principe de fonctionnement du protocole SNMP ......................................................... 9
6.3 SNMP en pratique.......................................................................................................... 10
7 Conclusion .............................................................................................................................. 11
Chapitre 2 : Les Systèmes de Monitoring Existants ..............................................................12

1 Introduction ...........................................................................................................................12
2 Le marché de la supervision .................................................................................................12
2.1 Les offres éditeurs .......................................................................................................... 12
2.1.1 HP OpenView ............................................................................................................13
VII
2.1.2 IBM Tivoli Monitoring .............................................................................................. 14
2.2 Les offres du monde libre ..............................................................................................15
NAGIOS : ............................................................................................................................... 16
1 Fonctionnalités de Nagios ............................................................................................ 16
2 Architecture de Nagios .................................................................................................. 17
3 Principes de bases de Nagios ...................................................................................... 18
4 Mise en réseau de la supervision avec Nagios ............................................................ 19
3 Limite des systèmes actuels ................................................................................................ 20
4 Conclusion............................................................................................................................. 22
Chapitre 3 : Le concept Agent ................................................................................................ 23

1 Introduction .......................................................................................................................... 23
2 Intelligence Artificielle Distribuée : .................................................................................... 24
2.1 Objectif de l’intelligence artificielle ............................................................................... 24
2.2 Orientation vers l’intelligence artificielle distribuée .................................................... 25
3 Notion d’Agent ..................................................................................................................... 26
3.1 Définition d’un Agent ..................................................................................................... 26
3.2 Principales caractéristiques d’un Agent ....................................................................... 27
3.3 L’Agent versus l’Objet ................................................................................................... 29
3.4 Principaux types des Agents ......................................................................................... 29
3.4.1 Les agents réactifs .................................................................................................. 29
3.4.2 Les agents cognitifs ................................................................................................ 30
3.4.3 Les agents hybrides .................................................................................................31
3.5 Architecture d’un Agent ................................................................................................ 32
3.6 Utilisation des agents .................................................................................................... 33
4 Les Systèmes Multi-Agents ................................................................................................. 33
4.1 Qu’est-ce qu’un Système Multi-Agents ? ...................................................................... 34
4.1.1 Définition .................................................................................................................. 34
4.1.2 Caractéristiques des SMA ....................................................................................... 35
4.1.3 Types des SMA ........................................................................................................ 36
4.2 Méthodologie de conception des SMA ........................................................................ 36
4.3 Apport des SMA ............................................................................................................. 38
4.4 Intérêts des SMA ........................................................................................................... 38
4.5 Domaines d’application des SMA ................................................................................. 39
VIII
5 Les agents mobiles ...............................................................................................................40
5.1 Qu’est ce qu’un agent mobile ? ..................................................................................... 41
5.1.1 Définition .................................................................................................................. 41
5.1.2 Attributs d’un agent mobile.................................................................................... 41
5.1.3 Caractéristiques d’un agent mobile ....................................................................... 42
5.1.4 Types d’agents mobiles .......................................................................................... 43
5.1.5 Avantages des agents mobiles ............................................................................... 44
5.2 Paradigme d’agent mobile ............................................................................................ 45
5.2.1 Schéma d’organisation Client/Serveur ................................................................... 45
5.2.2 Autres schémas d’organisation avec mobilité ......................................................46
5.2.3 Fonctionnement des agents mobiles .................................................................... 48
6 Conclusion.............................................................................................................................49
PARIE 2: Conception et Implémentation

Chapitre 4 : Conception ...........................................................................................................51
1 Introduction ...........................................................................................................................51
2 Fonctions principales ............................................................................................................51
3 Vision proposée: Vers une supervision à base d’agents mobiles ..................................... 52
3.1 Utilisation d’un seul agent mobile pour la supervision ................................................ 52
3.2 Utilisation d’un agent pour la détection et un autre pour la réparation .................... 53
3.3 Détection avec NAGIOS et réparation par agent mobile ............................................ 54
Voie choisie : Le deuxième scénario ................................................................................... 55
4 Conception............................................................................................................................ 56
4.1 Phase 1 : Analyse ............................................................................................................. 56
4.2 Phase 2 : Conception ..................................................................................................... 58
4.2.1 Schéma général du système ................................................................................... 58
4.2.2 Principe de fonctionnement :................................................................................. 59
4.3.3 Entités et modules du système : ............................................................................ 61
4.3.4 Description des agents du système....................................................................... 62
4.3.5 Schéma d’interaction Inter-Agents........................................................................64
5 Conclusion .............................................................................................................................66
IX
Chapitre 5 : Implémentation .................................................................................................. 67
1 Introduction .......................................................................................................................... 67
2 Environnement de développement .................................................................................... 67
2.1 Plateforme JADE pour le développement des SMA.....................................................68
2.2 Environnement Eclipse pour programmer en JAVA ....................................................69
2.3 Le package ‘’SNMP4J’’ pour les tests des services .....................................................69
3 Intégration de JADE et SNMP4J dans Eclipse ....................................................................69
4 Présentation de l’interface de MAMS (Multi Agent Monitoring System) .......................71
5 Mise en pratique ................................................................................................................... 72
6 Services supervisés .............................................................................................................. 73
7 Nœuds supervisés ................................................................................................................ 74
8 Conclusion............................................................................................................................. 75
Conclusion générale................................................................................................................ 76
Bibliographie et Web-graphie ..........................................................................................….77
Annexe : La plate-forme JADE................................................................................................ 81
X
Liste des figures
Liste des figures
Figure 1: Fonctionnalités de la supervision................................................................................. 6

Figure 2: Eléments de base du protocole SNMP.......................................................................10
Figure 3 : Fonctionalités de Nagios. ........................................................................................... 17
Figure 4 : Architecture de NAGIOS. ...........................................................................................18
Figure 5 : Fonctionnement d’un Plugin de NAGIOS. .................................................................19
Figure 6 : Schéma général de fonctionnement d'un système de monitoring actuel. ........... 20
Figure 7 : Schéma d’un système de monitoring à base d’agents mobiles. ............................. 21
Figure 8: Fonctionnement d’un agent réactif. ......................................................................... 30
Figure 9: Modules d’un agent cognitif. ..................................................................................... 31
Figure 10: Tableau comparatif entre les agents cognitifs et réactifs....................................... 31
Figure 11: Structure d’un agent hybride en trois couches. ...................................................... 32
Figure 12: Architecture générale d’un agent. ........................................................................... 32
Figure 13: Représentation symbolique d’un SMA. ................................................................... 34
Figure 14: Les phases de développement de SMA. ................................................................. 36
Figure 15: Domaines d’application de la technologie SMA. .................................................... 40
Figure 16: Le schéma client/serveur.......................................................................................... 45
Figure 17: Le fonctionnement du schéma client/serveur. ....................................................... 46
Figure 18: Le schéma Evaluation distante. ............................................................................... 47
Figure 19: Le schéma Code à la demande................................................................................. 47
Figure 20: Le schéma Agent mobile. ........................................................................................ 48
Figure 21: Paradigme d’agents mobiles. ................................................................................... 49
Figure 22: Utilisation d’un seul agent mobile pour la supervision. ......................................... 53
Figure 23 : Utilisation d’un agent pour la détection et un autre pour la réparation.............. 54
Figure 24: Détection avec NAGIOS et réparation par agent mobile. ...................................... 55
Figure 25: Schéma général du système. ................................................................................... 58
Figure 26: Principe de fonctionnement. ................................................................................... 59
Figure 27 : Entités et composantes du système........................................................................61
Figure 28 : Agent de gestion. .................................................................................................... 62
Figure 29 : Agent d’analyse. ...................................................................................................... 63
Figure 30 : Agent de réaction. ................................................................................................... 64
Figure 31: Schéma d’interaction inter-agents. ......................................................................... 64
Figure 32: Diagramme d’interaction inter-agents .................................................................... 65
Figure 33: Environnement de développement. ....................................................................... 67
Figure 34: Intégration de JADE et SNMP4J avec Eclipse......................................................... 70
Figure 35: Le moniteur JADE RMA. ............................................................................................ 71
Figure 36: L’interface utilisateur MAMS. .................................................................................. 72
Figure 37 : Le client de supervision. .......................................................................................... 73
Figure 38: Les services supervisés. ........................................................................................... 74
Figure 39: Les nœuds supervisés. ............................................................................................. 75
XI
Introduction générale
1. Contexte de travail
Dans le domaine des entreprises modernes, l’adoption d’un système informatique
facilite énormément les processus d’administration (personnelle et matérielle) et de
productivité. Un tel outil aide à bien satisfaire les exigences croissantes non seulement des
administrateurs, mais aussi des utilisateurs, c’est pourquoi les développeurs conçoivent ce
système d’une telle façon que tous les besoins soient satisfaits à travers une bonne gestion
de toutes les branches de l’entreprise.
En effet, toutes les entreprises, de nos jours, sont équipées d’un réseau local au
minimum, et pour les plus importantes d’entre elles de réseaux longue distance (Wide Area
Network), leurs parcs informatiques englobent des centaines, voire des milliers de
terminaux engendrés par des serveurs de bases de données et des serveurs de
traitements.
L’apparition de ces nouveaux environnements informatisés rend la surveillance des

éléments clefs de réseau et de système une opération indispensable, afin de minimiser la
perte d’exploitation et garantir que les utilisateurs ne s’aperçoivent pas des anomalies de
fonctionnement. Ces anomalies provoquent des conséquences variables en degré pour le
fonctionnement au niveau de système d’entreprise. En effet, l’arrêt d’un service de
messagerie n’est pas aussi couteux que la perte de la base de données de son entreprise
due à un disque défectueux [REU, 04].
Vu que le système informatique est au cœur des activités d’entreprise, sa maitrise

devient primordiale, puisque, il doit fonctionner pleinement et en permanence pour
garantir la fiabilité et l’efficacité exigées, d’une part. D’autre part, les problèmes liés au
système informatique tels que les défaillances, les pannes, les coupures et les différents
problèmes techniques doivent être réduits, du fait qu’une indisponibilité du système ou du
réseau peut causer des pertes considérables.
Afin de minimiser le nombre de ces pertes, une sorte de surveillance et de contrôle

s’avère obligatoire ; la notion de la « supervision informatique » fût apparue et devenue une
tâche vitale pour tout système informatique. Cette nouvelle branche d’administration
système/réseau doit assurer trois fonctionnalités :
- garantir la disponibilité de leurs système et réseau ;

- tenter de prévenir en cas de problème ;
- garantir une durée d’intervention et de résolution minimale.
1
En résumé, le but majeur attendu d'un système de supervision (Monitoring system : en
Anglais) est d’assurer le plus possible le bon fonctionnement du système informatique, en
surveillant les services et les entités logicielles (software) ainsi qu’en contrôlant le matériel
(hardware).
2. Problématique
Actuellement, dans un environnement d’entreprise basé sur l’informatique, il est plus
important que jamais d’identifier et de résoudre les interruptions de service et les goulets
d’étranglement qui menacent les applications vitales, et ce avant tout impact sur la
productivité du système et la satisfaction de l’utilisateur.
De ce fait, ces entreprises ont suivi plusieurs démarches pour surveiller et assurer la
bonne gestion de leurs systèmes. Ces dernières peuvent nécessiter beaucoup de personnel
et d’argent s'il s'agit de gérer des systèmes éloignés à l’aide de systèmes d’exploitation
différents.
De plus, il y a souvent peu d’informations disponibles pour aider les administrateurs à

comprendre les problèmes actuels et à prévoir les défaillances du système. Donc, il peut
leur être difficile d’atteindre les niveaux de service requis par l’entreprise.
Plus important encore, avec tous les nouveaux équipements et les nouvelles
technologies apparues et qui évoluent chaque jour, les réseaux se complexifient et la tâche
de la surveillance devient de plus en plus difficile. Cette complexité permet l’accès à un
nouveau marché pour les constructeurs qui désormais se lancent dans le développement
et la vente de logiciels de supervision.
Mais bien que leur efficacité ait été prouvée, presque toutes les solutions de supervision
actuelles se limitent à effectuer des vérifications locales ou distantes sur les machines et
services du réseau, et d’en communiquer les résultats ou signaler des pannes éventuelles le
cas échéant. Dans ce dernier cas, le logiciel de supervision alerte l’administrateur qui doit
intervenir manuellement pour le bon fonctionnement du système. Cela rend les choses
plutôt pénibles et exige toujours la présence humaine et l’intervention manuelle, parfois
même tardive, ce qui devient à la limite coûteux et influe sur l’efficacité et la fiabilité du
système informatique de l’entreprise. En effet, un client de la S.A.R.L. INEODEV Limited
veut remédier à ce manque, puisqu’il dispose d’un moniteur de supervision Open-Source
(NAGIOS : leader dans le monde libre). Ce client veut améliorer la qualité de ses services
offerts en perfectionnant son monitoring system avec l’automatisation de certaines tâches.
D’un autre point de vue, les applications d’aujourd’hui deviennent de plus en plus
distribuées dans de multiples objets et fonctionnalités qui sont amenés à coopérer. La
décentralisation est donc la règle et une organisation coopérative entre modules logiciels
2
est un besoin. En contrepartie, la taille, la complexité et l’évolutivité croissantes de ces
nouvelles applications informatiques font qu’une vision centralisée, rigide et passive
(contrôlée explicitement par le programmeur) atteint ses limites.
On est ainsi naturellement conduit à chercher à donner plus d’autonomie et d’initiative

aux différents modules logiciels. Le concept de système multi-agent propose un cadre de
réponse à ces deux enjeux : autonomie et organisation [DEM, 01].
3. Objectifs
Devant ce constat et dans le cadre de ce mémoire, nous avons fixé l’objectif de
concevoir et de réaliser un système de monitoring informatique, qui pour le mettre en
œuvre, nous nous dirigeons naturellement vers une solution distribuée.
Plus précisément, nous suivrons l'approche d'agents mobiles qui est une nouvelle
architecture dédiée à la réalisation des systèmes distribués. Cette dernière modélise les
applications à travers un ensemble d'agents mobiles.
Notre travail consiste, alors, à implémenter une architecture à base d’agents adaptée à
la supervision informatique en assurant la détection des pannes dans un système
informatique donné. Puis, nous allons tenter de résoudre, s’il y a possibilité, les problèmes
qui apparaissent dans un environnement de réseau informatique pour offrir un meilleur
service. Pour réaliser ce travail, nous comptons atteindre les objectifs suivants :
1. Etudier les systèmes de supervision et leurs principes.

2. Comprendre le paradigme agent et tout ce qu’il en découle.
3. Montrer les avantages et l’apport des agents mobiles dans ce type de logiciels.
4. Proposer une architecture à base d’agents mobiles pour la supervision.
5. Tester et estimer cette architecture.
4. Organisation du mémoire
Notre travail consiste à comprendre le fonctionnement de deux architectures
différentes, à savoir : les systèmes de supervision informatique et le paradigme d’agent.
Pour cela, nous avons organisé le manuscrit de la façon suivante :
I. La première partie est structurée en trois chapitres qui constituent notre état de
l’art :
1. La supervision informatique : présente une étude de la supervision informatique,
son rôle, ses principes et ses approches.
2. Les systèmes de monitoring existants : ce chapitre est consacré à la présentation
de quelques infrastructures de supervision qui feront l’objet de critiques.
3
3. Le concept agent: aborde la notion de la technologie agent, des systèmes multi-
agents et des agents mobiles.
II. La deuxième partie est constituée de deux chapitres :

4. Conception: c’est une présentation d’un modèle d’application et description des
différents sous systèmes de l’architecture qu’on va proposer.
5. Implémentation : c’est une mise en pratique de la conception et l’implantation
des théories dans un environnement réel.
Finalement, nous terminons par une conclusion générale qui récapitule les principales
observations concernant l’évolution du travail et nous indiquons également comment les
travaux réalisés tout au long de ce mémoire pourraient être améliorés, en donnant des
perspectives.
A la fin de ce document, nous présenterons une annexe qui introduit des concepts
techniques utilisés pour la conception de notre système multi-agent, à savoir la plateforme
Jade.
4
Chapitre 1 La Supervision Informatique
Chapitre 1 : La Supervision Informatique
1 Introduction
La gestion d'un parc de serveurs est un travail de chaque instant. Un bon
administrateur système doit savoir à tout moment l'état des différentes machines et des
différents services.
Cependant, l'administrateur ne peut pas se permettre de passer son temps devant un
tableau avec des voyants verts en attendant qu'un voyant passe au rouge pour agir, son
temps est occupé à d'autres tâches, donc il ne peut pas surveiller les statuts des machines
en permanence. L'examen quotidien des logs systèmes est un bon début, mais, si un
problème survient, on s'en rend compte seulement le lendemain, ce qui peut être trop
tard.
Pour simplifier leur travail, les administrateurs utilisent généralement ce qu’on appelle
un ‘’moniteur de supervision informatique’’, un tel moniteur permet d'avoir une vue globale
du fonctionnement de réseau ainsi que du niveau de performances des systèmes, et
d’alerter par différents moyens l’apparition d’une anomalie.
Dans ce chapitre, nous allons présenter les notions de base concernant la supervision
informatique.
2 Définition de la supervision informatique

En informatique, la supervision est une technique de suivi, qui permet de surveiller,
analyser, rapporter et d’alerter les fonctionnements normaux et anormaux des systèmes
informatiques.
5
D’un point de vue théorique, Eric D’HEM explique : « le Monitoring1 s’agit de répéter de
manière régulière un processus de test ou de surveillance d’une personne ou d’un bien. Le but
étant d’obtenir très rapidement et simplement une vision précise des événements ou
anomalies sur la période analysée » [Lien 3].
Entre outre, La supervision informatique consiste à indiquer et/ou commander l’état
d’un serveur, d’un équipement réseau ou d’un service software pour anticiper les
plantages ou diagnostiquer rapidement une panne [Lien 6].
3 Fonctionnalités et niveaux d’information

Généralement, les moniteurs de supervision regroupent les fonctionnalités illustrées
dans la figure suivante [Lien 5]:
Figure 1: Fonctionnalités de la supervision.
Supervision réseau2 : elle porte sur la surveillance de manière continue de la

disponibilité des services en ligne, du fonctionnement du réseau, des débits et
bande passante, de la sécurité, etc.
Supervision système : c’est la vérification de la santé d'un serveur coté
ressources matérielles (la mémoire, le CPU, le disque dur, etc.).
Exécution de commandes : qui sont des actions ou programmes lancés
automatiquement.
Envoi d'alertes : c’est une émission de message d’alerte sous forme sonore,
visuelle ou encore par e-mail.
1
Monitoring : mot en Anglais qui désigne la surveillance ou la supervision.
2
http://fr.wikipedia.org/wiki/Supervision
6
Cartographie : présente la vue d'ensemble de l'architecture informatique
surveillé.
Rapports d'activité (reporting): comme les tableaux de bord et les
histogrammes.
Il est à noter qu’à partir de ces fonctionnalités qui sont réalisées par des modules
spécifiques constituant le système de monitoring, trois niveaux d’informations se
dégagent [Lien 3]:
3.1 Informations sur les systèmes

Cette supervision fournira des informations sur le fonctionnement du système
comme l'utilisation du CPU, l’occupation de la mémoire physique, l’espace libre des
disques dures, l’état de la table de partitionnement du disque, la chaleur dégagée, etc.
3.2 Informations sur les réseaux

Ce type de surveillance va permettre de diagnostiquer la disponibilité d’un
équipement physique connecté à un réseau. Les technologies employées pour ce type
de supervision sont assez simples et le niveau des informations retournées est assez
limité. Les matériels visés sont : les commutateurs, les routeurs et les serveurs
(disponibilité, interrogation des sondes, alertes), ainsi que les onduleurs (disponibilité,
charge, état) et les imprimantes (disponibilité, état de l’imprimante et des
consommables).
3.3 Informations sur les applications et services

On va disposer non seulement d'une visibilité sur l’équipement physique mais
également sur les applications qui y sont exécutées et les informations qu’elles
retournent. Ses principaux axes sont : la disponibilité, le nombre d’utilisateurs, la
cohérence des réponses aux interrogations et les performances.
Pour les deux derniers cas, les tests devront être effectués par des équipements qui ne
sont pas sur la machine, car le serveur est destiné à des utilisateurs externes (par exemple
serveur Web connecté à Internet). Le monitoring informatique fournira dans ce contexte,
une vision utilisateur depuis les endroits où il est effectué.
Par exemple, le monitoring réseau permet la vérification de la connectivité d’un
serveur Web, qui rend les sites Web accessible par les internautes. Ou encore le monitoring
applicatif qui permet la vérification de l’opérationnalité d’un serveur (Apache ou IIS par
exemple) et celle du contenu des pages Web.
4 Rôle de la supervision
Deux phases sont importantes pour que les administrateurs soient capables atteindre
l’objectif voulu par la supervision, à savoir, surveiller le système et garantir sa disponibilité
même en cas d’anomalie [DOS, 06]:
7
- Tenter de prévenir en cas de problème (défaillances matérielles ou interruption des
services) et garantir une remontée d'information rapide ;
- Automatiser les tâches de récupération des applications et des services en assurant

des mécanismes de redondance en une durée d'intervention minimale (par
exemple : le redémarrage des services interrompus, l’arrêt de la machine en cas du
surcharge du CPU, la sauvegarde des données en cas du risque de perte d’un disque
dure en miroir, etc.).
5 Aspects de la supervision
La supervision peut porter sur plusieurs aspects de l’informatique. Pour simplifier on
peut les classer dans trois catégories principales qui sont les suivantes [Lien 3]:
1. La Fiabilité : Il s’agit de l’utilisation la plus courante du monitoring informatique.

Une surveillance permanente de la disponibilité de l’équipement est effectuée, et ce
pour détecter la moindre anomalie et de la signaler à l’administrateur.
2. La Performance : Le monitoring de performance a pour but de retourner des

informations sur le rendement d’un équipement ou d’un service comme par
exemple le temps de résolution DNS, le temps de connexion, le temps de
récupération du premier octet et dans le cas d’une page Web le temps de
récupération de la page et de l’ensemble des éléments de celle-ci (image, scripts…).
Grâce à cette analyse, on va pouvoir diagnostiquer une montée en charge difficile
ou même un surdimensionnement de votre bande passante.
3. Le Contenu : Dans ce dernier cas, on analyse les informations retournées par les
éléments surveillés pour détecter, par exemple, la suppression d’un fichier sur un
serveur FTP, la modification d’une page Web ou encore la disparition d’un mot clef.
Toutes ces approches sont complémentaires et peuvent bien entendu se retrouver

regroupée dans une seule analyse. L’analyse Fiabilité étant implicitement présentée dans le
cas d’une analyse Performance et Contenu.
6 Protocole SNMP
Le principe de base de la supervision est d’avertir d’un problème le responsable d’une
ressource avant même que les utilisateurs ne s’en aperçoivent, ce responsable pourra ainsi
intervenir dans les plus brefs délais sur l’ordinateur ou le service en question. Ceci permet
d’être proactif pour un service informatique qui gère de nombreux serveurs sur lesquels
résident beaucoup de services.
8
Il existe plusieurs méthodes pour superviser un système informatique :
Analyser les fichiers ‘’log’’ ou ‘’journaux’’ : qui sont des fichiers regroupant l'ensemble
des événements survenus sur un service, une application, un serveur ou tout autre
système informatique.
Récupérer des résultats de commandes et de scripts locaux ou distants ;
Utiliser le protocole SNMP (Simple Network Management Protocol) : qui va être
expliqué ainsi dessous.
6.1 Définition du protocole SNMP

SNMP est l’abréviation du ‘’protocole simple de gestion de réseau’’. Comme son nom
voudrait le faire croire, Il s'agit d'un protocole simple qui permet aux administrateurs
réseau de gérer les équipements du réseau et de diagnostiquer les problèmes de réseau
[Lien 10].
6.2 Principe de fonctionnement du protocole SNMP

Avec le protocole SNMP, le système de gestion de réseau est basé sur trois éléments
principaux : un superviseur, des agents et les nœuds gérés.
Le superviseur est la console qui permet à l'administrateur réseau d'exécuter des
requêtes de management. Les agents sont des entités qui se trouvent au niveau de chaque
interface qui connecte l’équipement managé au réseau et qui permette de récupérer des
informations sur différents équipements tels que les switchs, les hubs, les routeurs et les
serveurs contenant des objets gérables via SNMP. Ces derniers peuvent être des
informations matérielles, des paramètres de configuration, des statistiques sur les
performances ou encore tout autre objets directement liés au comportement en cours de
l’équipement concerné.
Ces objets sont classés dans une sorte de base de données nommée MIB
("Management Information Base") qui est un ensemble d'informations structuré
hiérarchiquement sur une entité réseau. Les informations sont regroupées en arbre
[Lien 9].
SNMP permet le dialogue entre le superviseur et les agents afin de recueillir les objets
souhaités dans la MIB [Lien 10].
L'architecture de gestion de réseau proposée par le protocole SNMP est donc basée
sur trois principaux éléments :
1. Les équipements managés : ce sont des éléments du réseau (ponts, hubs,
routeurs ou serveurs), contenant des "objets de gestion" pouvant être des
informations sur le matériel, des éléments de configuration ou des informations
statistiques ;
9
2. Les agents : c'est-à-dire une application de gestion de réseau résidant dans un
périphérique et chargé de transmettre les données locales de gestion du
périphérique au format SNMP ;
3. Les systèmes de management de réseau (network management systems notés
NMS), c'est-à-dire une console à travers laquelle les administrateurs peuvent
réaliser des tâches d'administration.
Voici ci-dessous un schéma qui présente les éléments de base du protocole SNMP:
Figure 2: Eléments de base du protocole SNMP.
6.3 SNMP en pratique

Concrètement, dans le cadre d'un réseau, SNMP est utilisé: pour administrer les
équipements et pour surveiller le comportement des équipements [Lien 11].
Une requête SNMP est un datagramme UDP3 habituellement à destination du port

161. Les schémas de sécurité dépendent des versions de SNMP (v1, v2 ou v3). Dans les
versions 1 et 2, une requête SNMP contient un nom appelé communauté, utilisé comme un
3
UDP : en français protocole de datagramme utilisateur, c’est l’un des principaux protocoles de
télécommunication utilisés par Internet
10
mot de passe. Il y a un nom de communauté différent pour obtenir les droits en lecture et
pour obtenir les droits en écriture.
Dans bien des cas, les colossales lacunes de sécurité que comportent les versions 1 et
2 de SNMP limitent l'utilisation de SNMP à la lecture des informations car la communauté
circule sans chiffrement avec ces deux protocoles. Un grand nombre de logiciels libres et
propriétaires utilisent SNMP pour interroger régulièrement les équipements et produire
des graphes rendant compte de l'évolution des réseaux ou des systèmes informatiques
(MRTG, Cacti, Nagios, Zabbix...) [Lien 11].
7 Conclusion
La supervision informatique est indispensable pour une entreprise qui se respecte et
dont la défaillance d’un quelconque de ses services informatiques et l’indispensabilité de
son système d’information influent sur le rendement global de sa productivité.
Les systèmes de supervision feront l'objet de notre étude, Le chapitre suivant donnera
une vue détaillée des différentes infrastructures de monitoring existantes.
Pour pouvoir être efficace, la surveillance doit donc impérativement être effectuée
depuis différents points de contrôle sur une architecture distribuée, avec des techniques
permettant d'analyser et gérer en permanence les flux.
11
Chapitre 2 Les systèmes de monitoring existants
Chapitre 2 : Les Systèmes de Monitoring

Existants
1 Introduction
Le marché de la supervision informatique déborde des logiciels de monitoring ; il en
existe une diversité, d’autres sont payants et d’autres font parti du monde libre ou on peut
même trouver des Open Source, Nous allons dans ce qui suit citer quelque uns et nous
détaillerons les plus connus et répandus dans le milieu des entreprises.
2 Le marché de la supervision
Le marché de la supervision peut être découpé en deux grandes sous-parties :
Les offres éditeurs : qui permettent de fournir des moniteurs de supervision
payants.
Les offres du monde libre : qui permettent d’avoir des moniteurs gratuits
(Open-source).
2.1 Les offres éditeurs

Les gros éditeurs logiciels ont rapidement compris que la supervision était une
ressource clé pour les entreprises qui, de plus en plus, utilisent leur système d'information
et ont donc besoin d'une disponibilité toujours plus grande de leur infrastructure
informatique. Par conséquent, la supervision est un domaine dans lequel les sociétés
n'hésitent pas à investir depuis quelques années. Ayant rapidement compris cela, les gros
éditeurs logiciels sont donc très vite entrés dans la course aux logiciels de supervision.
Aujourd'hui, la majorité des gros éditeurs logiciels propose des outils complets de
supervision. On retrouve, parmi les plus connus :
• HP : la gamme Openview (NNM, OVO, ...); IBM : Tivoli ; BMC : Patrol ; Computer
Associates : Unicenter TNG .
12
Ces outils, véritables frameworks de la supervision, possèdent tous leurs avantages et
inconvénients face à la concurrence. Et bien entendu, tous ont également le même défaut,
à savoir: leurs prix couteux !
Cette constatation faite, il est alors logique de voir de plus en plus de sociétés
aujourd'hui regarder du côté du logiciel libre, où les projets commencent depuis quelques
années à devenir de plus en plus professionnels et suivis.
Dans ce qui va suivre, nous présenterons deux leaders des logiciels payants de
supervision : HP OpenView et IBM Tivoli.
2.1.1 HP OpenView
HP OPEN VIEW est un outil de supervision reconnu sur le marché. Son principal
avantage est la centralisation des informations sur un seul poste. Il a pour rôle de gérer et
de surveiller entre autre les infrastructures et services réseaux. Ce logiciel est donc destiné
aux moyennes et grandes entreprises qui souhaitent avoir une vue global de leur réseau et
de son état [Lien 12].
1. Principe de fonctionnement
HPOV est un produit qui propose, aux personnes chargées de l’exploitation des
systèmes d’information, un outil favorisant :
une vue globale du système d'information ;
un contrôle homogène des différents composants du système informatique ;
une vision des incidents et leur impact.
La plate-forme HP OpenView est composée principalement de :
OVOW (OpenView Opération for Windows) : composé d’une base SQL SERVER;
Le logiciel est assorti d’un serveur HTTP Apache pour l’accès aux interfaces Web des
outils.
2. La console OVOW
La console OVOW permet à l'opérateur d'avoir une vision globale de son réseau
informatique. L’opérateur peut visualiser d’un seul coup d’œil la disponibilité globale d’un
service, la gravité d’une erreur, la raison principale de cette erreur ...
Les nœuds
Pour OVOW, chaque client est un « nœud ». Un nœud correspond donc à un élément
surveillé (un nœud peut être un serveur, un photocopieur …).
Les agents OVOW

OVOW a besoin d’un agent pour pouvoir surveiller un élément. Un agent OVOW est un
programme que l’on déploie à partir du serveur HPOV sur un nœud. On doit spécifier à cet
agent un domaine cible (Que doit-on surveiller ?).
13
L'agent OVOW est composé d'une mini base de données très sécurisée nommée base
Coda. L’agent stocke ses les informations liées aux métriques de performances du matériel
surveillé dans la base Coda ensuite le serveur se connecte à cette base toutes les 4 minutes
(variable paramétrable), et récupère les informations et les stockent dans sa base SQL
SERVER.
2.1.2 IBM Tivoli Monitoring

Les solutions IBM Tivoli Monitoring sont conçues pour une meilleure gestion des
applications en ligne essentielles à l’entreprise en :
• surveillant de manière proactive les ressources système vitales ;
• en détectant efficacement les goulets d’étranglement et les problèmes potentiels ;
• en répondant automatiquement aux événements.
En s’appuyant sur les meilleures pratiques pour identifier et résoudre les problèmes
d’infrastructure, il a été conçu pour aider les opérateurs à surveiller et gérer les matériels
et logiciels essentiels, comprenant les systèmes d’exploitation, les bases de données et les
applications sur des environnements répartis [Lien 13].
Ce moniteur de supervision se classe parmi les leaders du domaine, puisque il offre de
nombreux avantages. En effet, il :
Surveille de manière proactive les composants vitaux de votre infrastructure à la
demande, en vous aidant à isoler et prévenir rapidement les problèmes de
performance ;
Visualise les mesures de performances historiques et en temps réel sous forme de
tableaux et graphiques, avec en plus des conseils spécialisés et des actions
automatiques au sein d’IBM Tivoli Enterprise Portal ;
Consolide la surveillance et la gestion de systèmes répartis et de systèmes hôte à
l’aide d’une seule console de travail personnalisable ;
Fournit des outils de surveillance puissants et personnalisables à davantage
d’opérateurs nécessitant beaucoup moins de compétences et formation en
programmation pour déployer le produit ;
Aide à réduire les coûts opérationnels informatiques globaux en simplifiant
l’installation et la configuration, et en déployant des règles allégées avec des
fonctionnalités de surveillance automatique ;
Effectue automatiquement le suivi de l’état des principaux composants de votre
environnement informatique complexe et reçoit des alertes uniquement en cas
d’incident ;
14
Aide à optimiser l’offre de services informatiques en intégrant des produits de
gestion et des processus informatiques pour stimuler les performances et respecter
les accords de niveau de service ;
Aide à optimiser le temps de réalisation en simplifiant l’installation et la surveillance,
avec également des fonctionnalités de gestion s’appuyant sur des technologies
pointer-cliquer [Lien 13].
2.2 Les offres du monde libre

Depuis une dizaine d'années déjà, plusieurs projets de supervision ont vu le jour au sein
de la communauté du logiciel libre. Il suffit pour cela d'aller faire une simple recherche sur
le Net pour se rendre compte de la multitude de projets émergeants autour de la
supervision système et réseau.
Nous présenterons ainsi, les systèmes de monitoring plus populaires [Lien 4]:
NAGIOS ou Net saint4 (qui sera détaillé par la suite) est le principal logiciel Open
Source de supervision de réseaux et de systèmes; c’est le plus rependu et le plus suivi
par la communauté de développeurs. Par conséquent, il est adapté aux systèmes
d’information de taille moyenne ou importante ;
MRTG est un outil de supervision du trafic de liens réseaux. Il peut s'intégrer
étroitement à des solutions comme Nagios.
MRTG (Multi Router Traffic Grapher) génère des pages HTML de représentation en
temps réel du trafic réseau. Le logiciel prend toute sa dimension comme produit fini,
mais également comme brique spécialisée d'une solution intégrée plus large. Il
s'intègre notamment parfaitement dans la solution de supervision de Nagios. Son
architecture logicielle permet l'intégration sur des plates-formes et composants
hétérogènes.
CACTI est un logiciel de supervision réseau basé sur RRDTool. Il peut-être considéré
comme un successeur à MRTG et également comme une interface à RRDTool.
Cacti permet de représenter graphiquement divers statuts de périphériques réseau
utilisant SNMP ou encore grâce à des scripts (Bash, PHP, Perl, VBs...) pour avoir par
exemple l'espace disque restant ou bien la mémoire utilisée, la charge processeur ou le
ping d'un élément actif. Les données sont récoltées auprès des différents agents
SNMP (ou auprès des scripts locaux) grâce à un script php. Pour de meilleures
performances un exécutable, nommé cactid, peut également effectuer les
interrogations.
4
Net Saint : c’est l’ancienne appellation du NAGIOS
15
ZENOOS représente une alternative à des plates-formes de supervisions comme Tivoli
ou OpenView, notamment pour les entreprises de taille moyenne.
Il assure des fonctions de découverte, d'inventaire, de supervision de la
disponibilité, de gestion de la performance, de gestion des évènements et des alertes
qui peuvent être envoyées par email. Le produit fédère et s'interface avec de
nombreux utilitaires de supervision et d'administration open source. Zenoss est
disponible en version GPL ou commerciale (avec support).
Le moniteur Nagios qu’utilise actuellement le client d’INEODEV Limited et que nous
allons le décrire, ainsi dessous, est considéré comme la solution la plus aboutie dans son
genre et la plus utilisée dans le monde du logiciel libre de supervision.
NAGIOS :
Nagios, le successeur de Netsaint, est un logiciel de monitoring et de supervision libre
sous licence GPL.
Il offre une solution de surveillance efficace dans un système informatique complexe. Il
permet de surveiller le bon fonctionnement des services d’une ou plusieurs machines dans
un réseau hétérogène. Il est écrit en C et fonctionne grâce à un ensemble de plugins (qui
eux peuvent être écrits dans n’importe quel langage).
Prévu à l'origine pour fonctionner sous Linux, Nagios devrait fonctionner également
sous les autres systèmes Unix.
Plusieurs améliorations ont été apportées à Nagios pour qu'il devienne un partenaire
simple à utiliser et remarquablement fiable et efficace.
1 Fonctionnalités de Nagios
Nagios offre à l'utilisateur plusieurs fonctionnalités, à savoir [Lien 14] :
Surveillance des services réseaux (SMTP, POP3, HTTP, NNTP, PING, etc.) ;
Surveillance des ressources des hôtes (charge processeur, utilisation des disques,
etc.) ;
Permettre aux utilisateurs de développer facilement leurs propres vérifications de
services grâce à son système de plugins ;
Paralléliser la vérification des services ;
Possibilité de définir la hiérarchie du réseau en utilisant des hôtes "parents", ce qui
permet la détection et la distinction entre les hôtes qui sont à l'arrêt et ceux qui sont
injoignables ;
Notifications des contacts quand un hôte ou un service a un problème et quand celui-
ci est résolu ;
16
Possibilité de définir des gestionnaires d'évènements qui s'exécutent pour des
évènements sur des hôtes ou des services, pour une résolution proactive des
problèmes ;
Rotation automatique des fichiers log ;
Support pour l'implémentation de la surveillance redondante des hôtes ;
Interface web optionnelle, pour voir l'état actuel du réseau, notification et historique
des problèmes, fichiers log, etc. ;
Une interface permettant l’intégration simple de plugins ;
De prévenir par email ou par toute autre méthode personnalisée en cas de problème ;
Déclencher des procédures personnalisées pour résoudre les problèmes ;
La consultation des différents événements et données collectés via une interface
web ;
Archivage automatique des données collectées ;
Dans la figure suivante, les fonctionnalités de Nagios se résument [OUD, 05]:
Figure 3 : Fonctionalités de Nagios.
Cependant, pour pallier aux éventuelles lacunes du Nagios, des plugins peuvent être
ajoutés qui sont personnalisés selon les besoins d’utilisation, pour accomplir ou améliorer
d’autres services et tâches.
2 Architecture de Nagios
Nagios est un programme modulaire de telle sorte que son évolution puisse être facile,
il se compose principalement de trois parties [Lien 6]:
17
1. L’ordonnanceur : c’est le moteur de l’application qui s’occupe de
l’ordonnancement des tâches de supervision.
2. L’interface Web : qui permet d’avoir une vue d’ensemble du système
d’information et des possibles anomalies, Nagios s’appuie sur simple serveur
Web tel apache basé sur des CGI.
3. Les sondes : Les sondes de Nagios (Plugins ou Greffons) sont de petits scripts
ou programmes qui sont à la base des vérifications. Ces minis programmes que
l’on peut compléter selon nos besoins pour superviser chaque tache
Nagios peut aussi gérer ses données dans des bases de données (MySQL ou
PostgreSQL) ou bien dans des fichiers textes.
La figure 4 montre cette architecture [Lien 6]:
Figure 4 : Architecture de NAGIOS.
3 Principes de bases de Nagios

Les Common Gate Interface (CGI) : C’est une technologie standard implémenté
à tous serveurs Web. Elle permet l’échange de données entre un programme et le
contenu d’une page Web visualisée par un internaute distant. Un tel programme peut
être écrit à l’aide de n’importe quel langage de programmation : les plus utilisée sont
le langage C, Perl ou encore Python.
Les Plugins : A la différence de beaucoup d’autres outils de supervision. Nagios ne

dispose pas de mécanisme interne pour vérifier l’état d’un service, d’un hôte…etc.
Il utilise des programmes externes appelés Plugins, Les Plugins sont des
programmes exécutables ou scripts (Perl, Shell, Etc.) qui peuvent être lancés depuis
une ligne de commande pour tester un hôte ou un service. Nagios utilise le résultat
18
de cette action pour déterminer le statut des hôtes ou services sur le réseau. Pour
Nagios peut importe peut importe ce que fait un Plugin, seul le résultat compte.
Les Plugins permettent aux utilisateurs de développer facilement leurs propres
vérifications de services. Ces plugins fonctionnent soit en local sur la machine
supervisée, soit exécutent des tests à distance (Tels sur des protocoles réseaux tels
Http, Smtp ou exécution distante via Ssh ou autres).
Ce concept est illustré dans la figure suivante [Lien 15]:
Figure 5 : Fonctionnement d’un Plugin de NAGIOS.
4 Mise en réseau de la supervision avec Nagios

Les plugins locaux au serveur de supervision sont exécutés directement par Nagios. La
vérification d’un service à distance (par l’exécution d’un Plugin situé sur une autre machine
ou par SNMP) se fait elle aussi par le biais de l’exécution d’un Plugin local au serveur Nagios
qui n’est en faite qu’un ordonnanceur de tâches dédiés à la supervision.
Nagios n’a pas pour vocation d’intégrer des fonctionnalités de vérification de bon
fonctionnement quelconques autres que ses fonctions internes [Lien 14].
Pour l’exécution de plugins à distance, plusieurs possibilités existent:
Par le biais d’autres serveurs de supervision Nagios distants : dans le cas de la
supervision distribuée qui concentrent la vérification sur un site distant, et ne
remontent que les problèmes.
Les agents de transport ou d’exécution des tests, tels [Lien 14]:
1. NRPE (Nagios Remote Plugin Executor) qui permet l’exécution à la demande
de Plugins à distance, à choisir parmi un certain nombre de services disponibles.
C’est ce qu’on appelle la supervision active.
19
2. NSCA (Nagios Service Chek Acceptor) qui permet de son coté la remontée
d’information de façon passive vu du point de vue de Nagios, c’est ce qu’on
appelle la supervision passive.
L’ordonnancement des vérifications est assuré de façon locale à chaque
machine et surtout permet d’inverser le sens des connexions entre serveur
supervisé et serveur superviseur qui peut avoir un intérêt dans un réseau
sécurisé.
3. NSClient++ : qui est un greffon (plugin) lourd pour la supervision des serveurs
Windows NT/2K/XP.
4. Check_Snmp : pour la supervision basée sur SNMP à travers le réseau.
3 Limite des systèmes actuels

Toutes les solutions de supervision actuelles se focalisent à :
Effectuer des vérifications locales ou distantes sur les machines et/ou services du
réseau.
Récupérer les résultats de ces vérifications pour ensuite informer les
administrateurs sur l’état des services de leurs systèmes informatiques.
En cas d’une anomalie, le logiciel de supervision ne peut rien et l’intervention
humaine est indispensable pour le bon fonctionnement du système.
Et bien que Nagios soit un logiciel de monitoring plutôt réussit, et offrant diverses
fonctionnalités, il ne fait pas exception à la coutume quand il s’agit d’anomalies et
problèmes dans les systèmes surveillés. Il se contente de récupérer les résultats retournés
par les Plugins définis et de les afficher sur écran afin de délivrer une information simple et
fiable à l’utilisateur, ce dernier intervient manuellement pour résoudre ces pannes.
La figure suivante représente le fonctionnement général d’un outil de monitoring :
Figure 6 : Schéma général de fonctionnement d'un système de monitoring actuel.
20
Cependant, parfois il arrive qu’un problème apparaisse sur un site distant, quand il
s’agit d’un système complexe (réseau MAN ou WAN par exemple), donc il faudrait s’y
déplacer pour le solutionner. Cela rend les choses plutôt pénibles et exigent toujours la
présence humaine et l’intervention manuelle, ce qui devient à la limite coûteux et influe sur
l’efficacité et la fiabilité du système.
Pour remédier à ce type de problèmes, nous nous proposons d’utiliser un logiciel qui
réunit à la fois le monitoring et l’intervention automatique et cela en intégrant la
technologie d’agent mobile5 dans un système de monitoring. En effet, une telle plate-
forme à agents mobiles peut apporter une aide substantielle à un administrateur, puisque
certaines tâches routinières (par exemple la défragmentation périodique d’un disque),
peuvent être directement effectuées par des agents mobiles.
Le schéma précédent peut alors se basculer vers le schéma suivant (Figure 7):
Figure 7 : Schéma d’un système de monitoring à base d’agents mobiles.
5
La technologie d’agent (particulièrement : l’agent mobile) sera être décrite dans le chapitre suivant.
21
La solution donc va effectuer le rôle d’un logiciel simple de monitoring en cas de bon
fonctionnement, mais en cas de panne, elle sera capable d’en assurer le diagnostic et la
résolution automatique.
4 Conclusion
Tous ces logiciels que nous avons décris ci-dessus sont considérés comme un
aboutissement et une réussite dans leur branche, cependant, on voit qu’ils ont tous leurs
propres inconvénients qui doivent être résolus.
Un bon moniteur de supervision doit englober tous les avantages de ces derniers et
aussi, se remédier à leurs lacunes et inconvénients afin de converger vers la perfection et
atteindre un niveau de supervision et de fiabilité optimum.
Pour cela, la mise en place d’un tel moniteur exige le bon choix de plate-forme de
développement qui conduit à la réalisation d’une architecture distribuée fiable et robuste.
22
Chapitre 3 Le concept Agent
Chapitre 3 : Le concept Agent
1 Introduction
Durant la première génération des programmes informatiques, l'ordinateur était
chargé de réaliser des tâches prises en charge habituellement par un homme. Ce
remplacement progressif de l'homme par la machine s'est accompagné d’une
identification de la machine à l'humain ; un programme représentant l'expert sera capable
de résoudre le problème par lui-même.
Cette façon de concevoir les programmes comme des sortes de penseurs repliés sur
eux-mêmes a trouvé sa limite lorsqu'on a cherché à développer des applications plus
complexes, et habituellement, réalisées souvent par un groupe de personnes parfois
délocalisées. La machine devait alors être identifiée non uniquement à un humain mais à
une société organisée d'humains.
Les concepteurs des systèmes industriels complexes ont constaté que le savoir-faire,
les compétences et les connaissances diverses sont détenues par des individus différents
qui, au sein d'un groupe, communiquent, échangent leurs connaissances et collaborent à la
réalisation d'une tâche commune.
En effet, les méthodologies de réalisation d'applications informatiques se sont alors
concentrées sur les aspects organisationnels des logiciels et sur la représentation des
communications entre leurs différents composants.
Ainsi, on trouve parmi ces méthodologies qui convergent vers l’utilisation des entités
intelligentes coopérantes afin d’atteindre un objectif, la technologie des systèmes multi-
agents qui est une branche relativement récente de l’intelligence artificielle distribuée et
qui a enrichi cette dernière en suggérant l'usage de métaphores sociologiques et/ou
biologiques pour la conception de systèmes artificiels intelligents.
23
Cette terminologie rassemble les travaux qui portent sur l'étude et la conception
d'organisations d'agents (processus) autonomes, capables d'agir sur leur environnement
physique, et de communiquer ou d’interagir pour accomplir collectivement des tâches
spécifiques.
De ce fait, bien que la technologie des agents reste plutôt pénible à mettre en œuvre,
vu qu’elle est encore dans une phase de recherche et de développement quant aux
standards, plate formes, langages et protocoles, mais, elle retient de plus en plus
l’attention de la communauté informatique.
Dans ce chapitre, nous verrons les concepts fondamentaux de l’approche agent, nous
commencerons par introduire l’intelligence artificielle distribuée et l’évolution de cette
discipline jusqu’au systèmes multi-agents, nous mettrons ensuite l’accent sur l’évolution de
l’aspect individuel des agent vers l’aspect collectif, nous citerons également quelques
caractéristiques des systèmes multi-agents et nous finirons par introduire la notion des
agents mobiles qui est à son tour une nouvelle technologie qui émerge dans cette
discipline.
2 Intelligence Artificielle Distribuée :

John McCarthy a introduit l’Intelligence Artificielle (IA) en 1955. Il l’a définit comme
suit : « L’Intelligence Artificielle a pour but de faire exécuter par l’ordinateur des tâches
pour lesquelles l’homme, dans un contexte donné, est aujourd’hui meilleur que la
machine », [SAB, 01].
2.1 Objectif de l’intelligence artificielle

Pour recouvrir des domaines vastes et complexes, l’application de l’intelligence
artificielle (IA) a été évoluée. Elle sert à définir des systèmes capables de représenter des
connaissances, de raisonner ou planifier des actions afin de résoudre des problèmes
pouvant être très complexes tels que l’aide à la discision, la reconnaissance et la
compréhension des formes, la conduite des processus industriels, etc.
Principalement, l’IA vise à obtenir des résultats comparables et proches (voire même
meilleurs) de ce que feraient des êtres humains dans des cas similaires, et ceci bien
entendu, sans avoir à recourir forcement aux mêmes moyens.
Mais, l’approche classique de l’intelligence artificielle a montré ses limites, puisque elle
s’appuie sur la centralisation d’expertises dans plusieurs domaines techniques et
disciplines pédagogiques au sein d’un seul système, et modélise le comportement
intelligent d’un seul agent (système).
24
2.2 Orientation vers l’intelligence artificielle distribuée
Pour résoudre des problèmes de l’intelligence artificielle centralisée, il est devenu
nécessaire de s’orienter vers une approche cartésienne (modulaire) et de distribuer
l’intelligence sur plusieurs entités (agents) décomposant ainsi un système complexe en
plusieurs sous systèmes de complexité inférieure. Ces derniers sont capables d’interagir
entre eux afin d’aboutir au but prédéfini du système original [ROU, 04].
De cette approche décentralisée utilisée dans le domaine de l’intelligence artificielle
est née l’Intelligence Artificielle Distribuée (IAD) qui est définie comme étant la branche de
l’intelligence artificielle classique qui s’intéresse à des comportements intelligents qui sont
le produit de l’activité coopérative de plusieurs agents. En d’autres termes l’IAD est le
passage du comportement individuel au comportement collectif pour combler les limites
de l’IA classique à résoudre des problèmes complexes à travers la conception des systèmes
intelligents par un ensemble d’entités (sous systèmes ou encore modules) plus simple où
chacune s’occupe d’une partie du problème tout en ayant au final une complexité globale
moindre [LAB, 93].
À la différence de l’intelligence artificielle classique qui modélise le comportement
intelligent d’un seul agent, l’intelligence artificielle distribuée se focalise sur le
comportement intelligent qui est produit par la coopération et la coordination entre
plusieurs agents. Et par conséquent, ces agents sont des membres d’un groupe travaillant
dans un but commun autour d’une activité complexe comme le contrôle de processus
industriels, la gestion de réseaux informatiques ou la coordination de rebots industriels.
L’IAD recouvre trois axes fondamentaux de recherche [LAB, 93]:
La résolution distribuée des problèmes (RDP) : Elle s'intéresse à la méthode de
division d’un problème donné sur un ensemble d'entités distribuées et
coopérantes et à la manière de partager la connaissance de ce problème et d'en
obtenir la solution.
L'Intelligence artificielle parallèle (IAP) : c’est l’étude de développement de
langages et d'algorithmes parallèles pour l’IAD. Elle vise l'amélioration des
performances des systèmes d'intelligence artificielle sans, toutefois, s'intéresser à
la nature du raisonnement ou au comportement intelligent d'un groupe d'agents.
Toutefois, il est vrai que le développement de langages concurrents et
d'architectures parallèles peut avoir un impact important sur les systèmes d’IAD.
Les systèmes multi-agents (SMA) : c’est la coopération entre un ensemble
d'agents (ou processus) dotés d'un comportement intelligent et la coordination
de leurs buts et leurs plans d'actions pour la résolution d'un problème souvent
complexe. C'est le thème auquel nous nous intéressons le plus dans ce document.
Dans ce qui va suivre, nous allons se pencher sur l’étude de ce dernier axe qui se base
principalement sur la notion d’agent.
25
3 Notion d’Agent
La technologie des agents offre une nouvelle méthode pour analyser, concevoir et
implémenter des applications sophistiquées car ils font partie du domaine IAD en
bénéficiant aussi d'autres disciplines comme les sciences cognitives, sociologie, et
psychologie sociale.
Le terme agent est associé à des concepts très différents. Un agent est simplement
une entité qui agit ou opère, donc on pourra trouver le terme agent à n’importe quelle
application informatique ayant des buts à atteindre. Il est aussi utilisé, depuis plusieurs
années, dans [SEK, 07]:
• le domaine de l’informatique distribuée pour distinguer entre les entités dédiées à
la résolution de tâches spécifiques telles que, agents utilisateurs, agents de
transfert de messages et agents de systèmes d’annuaire.
• le domaine de la gestion des réseaux, où l’on parle d’agents SNMP par exemple.
Pour clarifier ce concept dont ses origines sont diverses, plusieurs définitions ont été
proposées par différents auteurs.
3.1 Définition d’un Agent

Jusqu’à présent, on ne peut pas trouver une définition universelle d’un agent, mais
plutôt une multitude de définitions, elles se ressemblent toutes, quoique elles se différent
suivant le type d’application pour laquelle est conçu l’agent.
a. A titre d’exemple, nous citons l’une des premières définitions de J. FERBER :

« Un agent est une entité autonome, réelle ou abstraite, qui est capable d’agir sur elle-même
et sur son environnement, qui, dans un univers multi-agents, peut communiquer avec d’autres
agents, et dont le comportement est la conséquence de ses observations, de ses
connaissances et des interactions avec les autres agents. » [FER, 97].
En d’autres termes, J. FERBER le redéfinit comme suit : « Un agent est une entité
physique ou virtuelle :
1. qui est capable d’agir dans un environnement,

2. qui peut communiquer directement avec d’autres agents,
3. qui est mue par un ensemble de tendances (sous la forme d’objectifs individuels ou
d’une fonction de satisfaction, voire de survie, qu’elle cherche à optimiser),
4. qui possède des ressources propres,
5. qui est capable de percevoir (mais de manière limitée) son environnement,
6. qui ne dispose que d’une représentation partielle de cet environnement (et
éventuellement aucune),
7. qui possède des compétences et offre des services,
26
8. qui peut éventuellement se reproduire,
9. dont le comportement tend à satisfaire ses objectifs, en tenant compte des ressources
et des compétences dont elle dispose, et en fonction de sa perception, de ses
représentations et des communications qu’elle reçoit. »
b. Selon M. WOOlDRIDGE, une définition plus récente et brève:
« Un agent est un système informatique capable d’agir de manière autonome et flexible dans
un environnement changeant» [WOO, 02].
Pour bien cerner cette notion, nous synthétisons qu’un agent informatique, ou plus
exactement une application agent, devra réaliser une certaine tâche au compte d’une
personne ou une application. Plus précisément une application agent sera orientée tâche,
c’est à dire qu’elle déploiera une activité (suite de fonctionnalités offertes par son
environnement), et sera caractérisée par un certain degré d’autonomie, d’interactivité et
de réactivité (ces propriétés seront développées plus loin).
Notons qu’on trouve cette notion d’agent dans divers domaines de l’informatique
[MEN, 04]:
Les systèmes multi-agents : provenant des domaines de la robotique et de
l’intelligence artificielle qui proposent de structurer une application en
différentes fonctions représentées chacune par un agent. Les différents
agents coopèrent pour la résolution des problèmes de l’application.
Les agents d’interface : provenant des domaines de l’interface homme
machine et de l’intelligence artificielle qui essayent de simplifier la vie de
l’utilisateur en automatisant des tâches réalisées couramment par
l’observation des comportements répétitifs ou en surveillant des ressources
comme le courrier électronique.
Les agents mobiles : provenant du domaine des réseaux dont l’objectif est la
réalisation de tâches réparties sur un ensemble de machines interconnectées
pour le compte d’un utilisateur ou d’une application.
3.2 Principales caractéristiques d’un Agent

Il est important de déterminer les différentes caractéristiques que doit posséder un
agent et qui font la différence avec les programmes conventionnels. En effet,
dépendamment des situations et des circonstances, un agent peut être fortement
caractérisé par un sous-ensemble des propriétés indiquées ci-dessous et être difficilement
associable aux autres spécifications.
Voici les principales caractéristiques [OLI, 98], [ROU, 04]:
1- Autonomie : un agent a un certain degré d'autonomie, c'est-à-dire qu’il possède
certains états (non accessibles aux autres agents et composants du système) et qu’il
peut prendre certaines décisions par rapport à ses états (sans intervention externe
27
humaine ou depuis un autre agent), il contrôle tout simplement ses actions ainsi que
son état interne ;
2- Sociabilité : est la capacité d’un agent de se trouver engagé dans des transactions
sociales comme la négociation ou la coopération pour résoudre un problème avec les
autres agents. Il sera alors capable d'interagir et de coopérer (par des langages de
communication) dans un environnement peuplé d’agents, afin de résoudre des
problèmes ou effectuer des tâches ;
3- Réactivité : est une propriété primordiale pour l’agent, c’est la capacité qu’a un agent
de modifier son comportement lorsque les conditions environnementales changent, il
pourra ainsi percevoir via des senseurs et agir via des effecteurs dans les temps requis
sur son environnement ;
4- Pro-activité : les agents n’agissent pas seulement en réponse à leur environnement,

mais ils sont également capables d’avoir un comportement guidé par un but, en ayant
la possibilité de prendre l’initiative ;
5- Activité : un agent est toujours actif. Il s'exécute donc nécessairement dans un thread
ou un processus indépendant ;
6- Apprentissage : l’agent est capable d’apprendre et d’évoluer en fonction de cet

apprentissage, en le rendant capable de changer de comportement (en fonction des
expériences passées). En fait, l’apprentissage est une caractéristique qui fournit aux
systèmes la capacité d’acquérir la compréhension de certains comportements au cours
du temps, sans nécessiter que ces comportements soient programmés manuellement;
7- Migration : l’agent peut se déplacer d’un système à un autre pour accéder à des
ressources distantes ou pour rencontrer d’autres agents (notion d’agent mobile).
8- Communication : c’est la possibilité d’échanges de messages entre agents. Un agent
peut invoquer une méthode d’un autre agent comme il peut lui envoyer des messages
s’il est autorisé à le faire. La communication inter-agents peut suivre trois schémas
différents [BAR, 03] :
Now-type messaging : c’est le type de messagerie le plus utilisé. C’est un type
synchrone. Il bloque l’exécution de l’émetteur du message jusqu’à ce que le
receveur aura complètement téléchargé le message et aura envoyé sa réponse.
Future-type messaging : c’est un type de messagerie asynchrone qui ne bloque pas
l’exécution. L’expéditeur retient une variable qui peut être utilisée pour obtenir le
résultat.
One-way-type messaging : c’est un type asynchrone qui ne bloque pas l’exécution
courante. L’expéditeur ne va pas retenir une variable pour ce message et le
récepteur ne va jamais répondre. Ce type est utile quand deux agents engagent une
conversation où l’agent expéditeur n’a pas besoin de la réponse de l’agent
récepteur.
28
3.3 L’Agent versus l’Objet
Les agents sont à la programmation orientée agent (POA) ce que sont les objets à la
programmation orientée objet (POO). En se basant sur les caractéristiques de l’agent, il est
remarquable qu’en développant des applications par l’approche orientée agent, le
problème est décomposé en modules (agents) ayant des interactions, une autonomie, et
un objectif spécifique à atteindre. Les concepts clés d’abstraction liés à un système orienté
agent sont : agent, interaction, organisation [SEK, 07].
La terminologie objet n’est pas adaptée aux systèmes agents même s’il existe une
similarité superficielle entre objet et agent, ceci s’explique à travers les points suivants
[COU, 07] :
les agents sont permanents actifs alors que les objets sont généralement passifs;
les agents sont autonomes et responsables de leurs actions alors que les objets ne
le sont pas toujours;
les comportements des agents dans les systèmes ne sont pas tous prévus ;
l’approche orientée-objet ne fournit pas un ensemble adéquat de concepts et de
mécanismes pour modéliser les systèmes complexes dans lesquels les rapports
évoluent dynamiquement;
« un agent est un objet actif ayant une autonomie et un objectif », c’est la définition
de certains chercheurs dans le domaine du paradigme agent.
3.4 Principaux types des Agents

La typologie des agents repose sur la granularité, c'est-à-dire la complexité des
fonctionnalités que possède l’agent, et par conséquent, Il existe deux écoles distinctes
[CHA, 01]:
• l’école réactive qui perçoit les agents comme des entités très simples réagissant
directement aux modifications de l’environnement ;
• l’école cognitive qui définit les agents comme des entités intelligentes.
Les types d’agents induits sont donc les agents réactifs et les agents cognitifs (ou
délibératifs). D'autres types d'agents, qualifiés d'hybrides, utilisant donc ces deux types de
comportement, sont ensuite apparus:
3.4.1 Les agents réactifs

Les agents réactifs n'ont pas de représentation de leur environnement, de leur monde
si ce n'est que très partiellement. Ils ont un comportement de type « stimulus/réponse ».
Les actions consistent à réagir à des informations leur parvenant.
29
La figure 8 présente le fonctionnement d’un agent réactif [Lien 1] :
Figure 8: Fonctionnement d’un agent réactif.
Les défenseurs de cette approche partent du principe suivant : dans un système multi-
agent, il n’est pas nécessaire que les agents soient intelligents individuellement pour que le
système ait un comportement global intelligent car la coopération de ces agents de faible
granularité (à faible capacité d’action) mais beaucoup plus nombreux permet l'émergence
d'une intelligence. Les sociétés d'insectes comme les fourmis, les termites sont les
exemples les plus anciens d'agents réactifs. Les agents réactifs sont de plus bas niveau, et
ne disposent que d’un protocole et d’un langage de communication réduit.
L’absence de formalisme est l’inconvénient majeur de ce type d’agent, ce qui explique
la difficulté de la compréhension et la prédiction du comportement des agents, [WOO, 95].
3.4.2 Les agents cognitifs

Les sociétés d’agents cognitifs sont composées d’un petit nombre d’agents de forte
granularité (à grande capacité d’action) dont chacun est assimilable, suivant le niveau de
ses capacités, à un système expert plus ou moins sophistiqué. Ces agents sont des agents
communicants [DIE, 90].
L’agent cognitif est constitué d’une base de connaissances qui contient toutes les
connaissances concernant son fonctionnement et son environnement. Cette base peut
être mise à jour par de nouvelles connaissances acquises, par échange d’informations avec
les autres agents ou par le biais de la perception sur son environnement. Contrairement
aux agents réactifs, les agents cognitifs possèdent :
une représentation globale et explicite de leur environnement, des autres agents
avec lesquels ils communiquent et d’eux-mêmes ;
des capacités de raisonnement sur leurs bases de connaissances, leurs intentions et
leurs buts pour prendre des décisions suivant une planification.
30
La figure 9 montre les modules constituant un agent cognitif [Lien 2] :
Figure 9: Modules d’un agent cognitif.
La figure 10, nous montre un tableau comparatif entre les deux approches [ROU, 04]:
Systèmes d'agents cognitifs Systèmes d'agents réactifs
Représentation explicite de Pas de représentation explicite

l'environnement
Peut tenir compte de son passé Pas de mémoire de son historique
Agents complexes Fonctionnement Stimulus/réponse
Petit nombre d'agents Grand nombre d'agents
Figure 10: Tableau comparatif entre les agents cognitifs et réactifs.
3.4.3 Les agents hybrides

Une architecture hybride d'un agent est une architecture composée d'un ensemble de
modules organisés dans une hiérarchie, chaque module étant soit une composante
cognitive avec représentation symbolique des connaissances et capacités de
raisonnement, soit une composante réactive. De cette manière, le comportement proactif
de l'agent, dirigé par les buts, est combiné avec un comportement réactif aux
changements de l'environnement, afin d’obtenir simultanément les avantages des
architectures cognitives et réactives, tout en éliminant leurs limitations [SEC, 03].
La plupart des architectures hybrides considèrent que trois couches suffisent
amplement. Ainsi, au plus bas niveau de l’architecture, on retrouve habituellement 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
31
travaille plutôt avec une vision qui se situe au niveau des connaissances de
l’environnement. Finalement, la couche supérieure se charge des aspects sociaux de
l’environnement, c’est à dire du raisonnement tenant compte des autres agents [CHA, 01].
Ci-dessous, la structure d’un agent hybride est illustrée à travers la figure 10 :
Couche cognitive
Couches Intermédiaires
Couche réactive
Figure 11: Structure d’un agent hybride en trois couches.
3.5 Architecture d’un Agent

La structure interne d’un agent logiciel n’est pas simple. Généralement, les agents ont
une architecture qui leur permet d’être réactifs ou cognitif.
La figure 11 montre cette architecture générale [ROU, 04] :
Figure 12: Architecture générale d’un agent.
En effet, si l’agent perçoit des situations qu’il connait très bien, alors il s’agit d’un agent
réactif. Par contre, lorsque l’agent rencontre ou perçoit une situation familière et qu’il lui
suffit un simple raisonnement pour la résoudre, on parle d’un agent cognitif.
Dans certains cas, il peut toutefois s’avérer qu’un agent ne peut pas résoudre un
problème (situation non familière), l’agent aura donc besoin d’engager un processus de
coopération pour demander l’aide aux d’autres agents.
32
3.6 Utilisation des agents
Il y a évidemment plusieurs domaines d'utilisation pour les applications agents dû au
fait que les architectures basées sur les agents fournissent une manière bien particulière
afin d'aborder des problèmes rapidement. C'est pour cette raison que les agents soient
largement utilisés, actuellement et prochainement, dans les domaines suivants [MEN, 04]:
a. Les agents dans un réseau informatique : Un agent informatique est un programme

qui s’exécute sur une machine, l’environnement d’exécution doit cependant fournir
aux agents un moyen de communiquer entre eux. Les agents peuvent se déplacer
d’une machine à l’autre, principalement en empruntant un réseau.
b. Les assistants : Ce sont des agents qui travaillent pour et avec les utilisateurs. Les
plus célèbres d’entre eux sont les assistants de Microsoft Office. En effet, l’assistant
surveille tout ce que l’utilisateur fait et lui propose des astuces pour aller plus vite
(raccourcis clavier, manipulations à la souris …).
c. Les jeux : Des agents permettent de faire fonctionner les avatars, c'est-à-dire, les
joueurs gérés par l’ordinateur. En effet, lorsque l’ordinateur qui joue, il y de fortes
chances pour que se soit un agent qui joue.
d. La robotique : Dans ce cas, on est plus dans le domaine de l’informatique. Le petit
robot qui transporte des charges, la tendeuse ou la balayeuse automatique, ce sont
des agents.
e. L’attente d’information : Parfois, le problème n’est pas de savoir où se trouve
l’information mais quand est- ce qu’elle va s’y trouver. Dans ce cas, les agents
peuvent aussi se révéler utiles. Prenons l’exemple de cours boursiers : ce sont
disponibles sur Internet (Bourse de New York, Yahoo-Finance…). On sait donc où
est l’information, il faut maintenant savoir quand l’information va devenir
intéressante. Ainsi, on peut envoyer un agent sur le serveur de la bourse en lui
programmant d’attendre jusqu’à ce qu’une action atteigne un certain cours puis de
revenir faire un rapport.
Quand l’agent est sur le serveur de la bourse, il peut revenir à tout moment. Il existe
deux cas :
On reste connecté et l’agent revient faire un rapport dès que le cours est atteint.
On ne reste pas connecté et l’agent attend que l’on se reconnecte pour faire son
rapport.
4 Les Systèmes Multi-Agents

L’agent en tant qu’entité individuelle peut s’avérer limité dans pas mal de cas, surtout
en vue de ce que l’on connaît aujourd’hui comme applications distribuées et pour
lesquelles un ensemble d’agents mettant en commun leurs compétences et connaissances
parait plus que nécessaire.
33
Ce type d’agents forme ce qu’on appelle des Systèmes Multi-Agents. Ces derniers se
basent sur le principe suivant : au lieu d’avoir un seul agent en charge de l’intégrité d’un
problème, on considère plusieurs agents qui ont chacun en charge qu’une partie de ce
problème. La solution au problème initial est alors obtenue au travers de l’ensemble des
comportements individuels et des interactions, c'est-à-dire par une résolution collective.
Par conséquent, les systèmes multi-agents constituent l’un des champs de recherche
les plus actifs dans le domaine de l’informatique et ses champs d’application ne cessent de
s’élargir et de s’approfondir [RIC, 01].
4.1 Qu’est-ce qu’un Système Multi-Agents ?

Pour se familiariser avec le concept de système multi-agents, nous avons jugé utile de
voir sa définition, ses principales caractéristiques et ses types.
4.1.1 Définition
Un Système Multi-Agents (avec son acronyme SMA, et MAS pour « Multi-Agent
System» en anglais) est un ensemble d’agents situés dans un certain environnement et
interagissant selon une certaine organisation6, il est défini comme étant un système
distribué composé d’un ensemble d’agents.
Une simple représentation symbolique est montrée dans la figure 12 [SEK, 07] :
Figure 13: Représentation symbolique d’un SMA.
6
http://fr.wikipedia.org/wiki/Syst%C3%A8me_multi-agents
34
Voici ci-dessous quelques définitions standards d’un SMA :
a. Selon J. Ferber les SMA sont définis de la façon suivante [FER, 97]:
« On appelle système multi-agents (ou SMA), 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;
un ensemble A d’agents, qui sont des objets particuliers (A ⊆ O), lesquels représentent
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 appelle les lois de l’univers. »
b. J. Ferber a les redéfinit comme suit [FER, 97]: « Les systèmes multi-agents ont des
applications dans le domaine de l’intelligence artificielle où ils permettent de réduire la
complexité de la résolution d’un problème en divisant le savoir nécessaire en sous-
ensembles, en associant un agent intelligent indépendant à chacun de ces agents, on
parle ainsi d’intelligence artificielle distribuée ».
c. Un Système Multi-Agent est défini comme étant : un système distribué composé d’un
ensemble d’agents. Contrairement aux systèmes d’IA, qui simulent dans une certaine
mesure les capacités du raisonnement humain, les SMA sont conçus et implantés
idéalement comme un ensemble d’agents interagissant, le plus souvent, selon des
modes de coopération, de concurrence ou de coexistence [CHA, 94].
En synthétisant à partir de ces définitions, un SMA peut être assimilé à une population
d’agents autonomes en interaction, où la coopération et la coordination deviennent plus
importantes que l’intelligence individuelle.
Nous pouvons tirer, alors, que le but d’un SMA est de faire fonctionner un ensemble
d’agents pour résoudre des problèmes, accomplir des tâches fonctionnelles et simuler des
systèmes existants.
4.1.2 Caractéristiques des SMA

Un SMA est caractérisé par [MBA, 03]:
35
Chaque agent possède des informations ou des capacités de résolution des
problèmes limitées : on dit qu’il a un point de vue partiel ;
Il n’existe aucun contrôle global du système ;
Les données sont décentralisées (les agents agissent et travaillent indépendamment

les uns des autres) ;
Les traitements sont en mode asynchrone.
un agent est capable de coordonner ses activités avec les autres agents pour accéder
à des ressources et à des services partagés dont il a besoin (pour réaliser ses buts).
4.1.3 Types des SMA

On peut différencier les SMA selon le nombre d’agents, la nature et la complexité de
ces agents. Ainsi, un SMA peut être soit [DRO, 05] :
• Ouvert : les agents y entrent et en sortent librement (par exemple: l’utilisation
d’un SMA pour développer une application de commerce électronique).
• Fermé : où l'ensemble d'agents reste le même.
• Homogène : dont tous les agents sont construits sur le même modèle.
• Hétérogène : dont les agents de modèles sont différents, c'est-à-dire de
granularités différentes.
4.2 Méthodologie de conception des SMA

L’intérêt d’une méthodologie de conception est de passer d’un cahier des charges à
une implémentation, et de pouvoir gérer le cycle de vie globale d’une application. Tout ceci
couvre des besoins comme la spécification initiale (besoin, analyse), l’architecture
(conception), l’implémentation, mais encore l’expression des modèles utilisés dans un but
de maintenance ou de réalisation.
D’après [BRA, 87], les phases de développement de SMA sont : les besoins, l’analyse, la
conception, l’implémentation et le test (Figure 14).
Besoins Analyse Conception Implémentation Test
Figure 14: Les phases de développement de SMA.
36
Les méthodologies orientées agents sont devenues une priorité pour le
développement de systèmes complexes. Il s’agit avant tout de tirer parti des modèles,
méthodes et outils déjà proposés pour faciliter la construction de systèmes multi-agents.
La plupart des méthodologies pour les systèmes multi-agents sont des extensions des
méthodologies orientées-objets et restent ainsi incomplètes. De plus, peu d’efforts ont été
faits pour la normalisation des méthodologies orientées agents et les plates formes
d’exécution.
Dans ce qui va suivre, nous allons détailler l’une des méthodologies les plus utilisées :
La méthodologie Voyelles
La méthodologie Voyelles (AEIO) se décompose en 4 parties [DEM, 95] :
Agents : qui concernent les modèles (ou les architectures) utilisés pour la partie active
de l’agent, depuis un simple automate à un complexe système à base de
connaissances.
Environnements : qui sont les milieux dans lesquels sont plongés les agents. Ils sont
généralement spatiaux dans la plupart des applications multi-agents.
Interactions : qui concernent les infrastructures, les langages et les protocoles
d’interactions entre agents, depuis de simples interactions physiques à des
interactions langagières par actes de langage.
Organisation : qui structure les agents en groupes, hiérarchies ou en relations.
La méthodologie AEIO englobe à travers trois phases [PIC, 04]:

a. Phase d'analyse : dans un premier temps, cette méthodologie consiste à identifier
et décomposer le problème en quatre composantes fondamentales: Agents,
Environnement, Interactions et Organisation, pour dégager l'architecture générale
du système.
b. Phase de conception : les quatre composantes A, E, I et O étant identifiées, elles
constituent ainsi les spécifications globales du système multi-agents. Il s'agit, au
cours de cette phase, de choisir les modèles opérationnels des composantes pour
aboutir à la spécification du fonctionnement global du système exprimé sous forme
de diagrammes de comportement. Les modèles d'agent ou architectures d'agents
vont de modèles simples comme les automates à états finis (agents réactifs) aux
modèles plus complexes comme les systèmes à base de connaissances (agents
cognitifs). Les modèles d'environnement dépendent du domaine d'application, ils
sont généralement spatialisés et dotés d'une métrique. Les structures et langages
d'interaction vont des modèles issus de la physique, comme les modèles à base de
forces, à des interactions de haut niveau basées sur la théorie des actes de langage.
Enfin, les modèles d'organisations vont des modèles biologiques jusqu'aux modèles
inspirés par les lois sociales.
37
c. Phase de programmation : (ou d’implémentation) consiste en l’instanciation des
modèles, en utilisant des plates-formes et des langages choisis. Le résultat, le
système implémenté, peut alors être exécuté, évalué (test et validation) et repensé
en cas d’inadéquation avec les besoins exprimés par le type de problème et le
domaine d’application.
4.3 Apport des SMA

Si les architectures et les applications actuelles basées sur les SMA manifestent des
défauts, ils n'en sont qu'à leur début, et on peut affirmer, en plus, que la prochaine
génération des systèmes informatiques sera construite autour de la technique des "agents
logiciels".
Leur comportement dynamique et leur capacité de voyager sur les réseaux en faisant
l’outil de base pour le développement des applications "télécommunications" qui
constitueront l’essentiel de l’activité informatique de demain. Il va être possible de
maîtriser les réseaux, de coordonner de manière efficace des architectures décentralisées
et d’amorcer de vraies bases de données réparties. C’est une vraie révolution
technologique qui va bouleverser les méthodes traditionnelles de gestion des activités de
la communication et du commerce.
Au futur, on s’attend à voir un développement des infrastructures industrielles qui
demandera sûrement des progrès informatiques pour répondre aux besoins de
l’entreprise. Bref, l’intérêt de cette branche de l’intelligence artificielle distribuée soit
montré, et qui offre une méthode de conception des systèmes que la plupart des logiciels
d’ingénierie courants considèrent comme complexes.
Cependant, la transition à partir de laboratoires de recherche vers des applications
industrielles déployées est effectivement un challenge que vont relever les prochains
développeurs de logiciels dans le domaine des systèmes multi-agents.
4.4 Intérêts des SMA

Les principaux intérêts se résument ainsi:
Ils s’adaptent bien à la réalité dans la mesure où de nombreux problèmes sont de

nature distribuée ;
l’utilisation de nombreux agents résolvant le même problème de façon différente,
produit généralement des solutions de meilleure qualité en termes de complétude et
de précision ;
ils permettent d’intégrer des connaissances diverses et complexes;
38
les connaissances insuffisantes peuvent être complétées suivant la résolution ;
ils permettent de résoudre des problèmes de taille et de complexité telle qu’il n’est pas
réaliste d’essayer de les résoudre avec un seul agent ;
la modularité : la complexité d’un système d’IA croit avec la taille de sa base de
connaissances. Partitionner ce système en N agents réduit sa complexité par un
facteur parfois plus grand que N, et la configuration résultante se trouve plus facile à
développer, à tester et à maintenir ;
4.5 Domaines d’application des SMA

Les systèmes multi-agents ont déjà montré des promesses particulières dans une
variété de systèmes technico-sociaux comme: la gestion du trafic aérien, la gestion des
ressources, les applications boursières, la télémédecine, l’environnement de robotique
cognitive ou les systèmes de commande et de contrôle en temps réel, etc.
Aussi, la technologie agent a trouvé sa place dans les systèmes dynamiques, où l’action
autonome, la flexibilité et l’intelligence sont requises quand les quantités de données à
traiter dépassent l’envergure de traitement sur une seule machine. Cette approche
constitue un bon moyen de résolution et d’appréhension des problèmes [WOO, 95]. Cela,
explique l’utilisation actuelle des systèmes multi-agents dans divers domaines, dont nous
avons cité quelques uns brièvement :
- le web sémantique et la gestion documentaire sur le web ;
- les réseaux tels que Peer to Peer (P2P) ;
- les systèmes distribués concurrents et les bases de données reparties ;
- le commerce électronique sur le net et la gestion des processus d’affaires ;
- les systèmes d’information coopératifs ;
- les télécommunications ;
- les interfaces humain machine (HCI pour humain machine interface)…etc.
La suivante figure (Figure 15) illustre les domaines d’application de la technologie

SMA ainsi que les diverses disciplines qu’elle fait intervenir [Lien 8].
39
Figure 15:: Domaines d’application de la technologie SMA.
5 Les agents mobiles

Les applications
ions de traitement
traiteme de l’information ont souvent exigé (et continuent à
exiger) d'être de plus en plus distribuées sur de nombreux sites distants. Les systèmes
distribués qui les supportent sont souvent basés sur le fameux modèle Client/Serveur.
Client/Serveur
Mais, le
e volume d'informations
d'informations manipulées par les différentes applications n'a pas
cessé de croître ; et ce, à un rythme très accéléré dépassant largement le rythme des
améliorations apportées aux réseaux. Pour cela, il était nécessaire de moderniser le
modèle Client/Serveur afin de supporter
supporter plus efficacement les interactions entre les clients
et les serveurs et ce en améliorant les méthodes de communication existantes [GAR, 00].
Parmi les modèles modernisés, on trouve l’approche d’agent mobile. En effet, avec les
travaux de J. WHITE chez General Magic [WHI, 95], le
e monde des agents a été enrichi d’un
nouveau type : les agents mobiles.
mobiles
Cela était en 1995, quand le
le développement des agents mobiles a coïncidé avec le
succès du langage Java qui permet d’offrir un environnement technique très favorable.
40
Sur le plan commercial, ce nouveau concept n’a pas encore suscité de grandes
applications. Mais, la communauté informatique pense que les agents mobiles vont jouer
un rôle important dans l’informatique de demain, notamment Internet.
5.1 Qu’est ce qu’un agent mobile ?

Nous entamerons ce paradigme d’agent mobile par sa définition.
5.1.1 Définition
Nous avons jugé utile de citer quelques définitions pour mieux comprendre son
fonctionnement :
Un agent mobile est un programme avec un but précis, capable de suspendre son
exécution sur une plate-forme pour se déplacer vers une autre plate-forme où il
reprend son exécution [LAR, 03].
Un agent mobile est un agent logiciel qui peut se déplacer d’un site physique à un autre
en cours d’exécution pour se rapprocher de données ou de ressources. Non seulement,
il se déplace avec son code et ses données propres, mais aussi avec son état
d’exécution [MED, 07].
Un agent mobile peut se déplacer à travers un réseau hétérogène sous son propre
contrôle, migrant d’un site à un autre, c'est-à-dire que l’agent décide lui-même de
manière autonome de ses mouvements. Durant sa migration, l’agent mobile interagit
avec d’autres agents ou d’autres ressources (bases de données…), et généralement, il
revient sur son site initial une fois sa tâche est accomplie [GAR, 00].
5.1.2 Attributs d’un agent mobile

Un agent mobile est une entité qui possède cinq composants : son état, son
implémentation (code), son interface, son identifiant et son autorité [MED, 07]:
a. L’état : quand un agent se déplace, il transporte avec lui son état, ceci lui permet de
reprendre son exécution quand il arrive à destination au point même où il l’avait
quittée. L’état d’un agent peut être considéré comme une photo instantanée de
son exécution. Dans la plupart des langages de programmation, on peut
partitionner cet état en :
1. Un état d’exécution : instruction en cours (compteur) + pile ; c’est les
valeurs des variables qui peuvent aider à déterminer la suite de l’exécution
après migration.
2. Un état d’objet : contient les valeurs des variables d’instance dans un objet.
b. L’implémentation (code) : comme n’importe quel autre programme, l’agent mobile
a besoin d’un code pour pouvoir s’exécuter. Quand il se déplace à travers le réseau,
l’agent peut soit emporter son code soit aller à destination, voir quel code est
disponible sur la machine distante et récupérer le code manquant à partir du
réseau. L’implémentation d’agent doit être à la fois exécutable et sans risque pour
l’hôte de destination.
41
c. L’interface : un agent fournit une interface qui permet aux autres agents et aux
autres systèmes d’interagir avec lui. Cette interface peut être un ensemble de
méthodes qui permet aux autres agents et applications d’accéder aux méthodes de
l’agent par un système de messagerie.
d. L’autorité : une autorité est une entité dont l’identité peut être authentifiée par
n’importe quel système auquel elle essaye d’accéder. Une autorité peut être soit
une personne privée, soit une organisation. L’identité est constituée d’un nom et
d’autres attributs. Pour les agents, il existe principalement deux types d’autorités :
Le fabriquant (manufacturer) qui est le fournisseur du code d’implémentation de
l’agent,
Le propriétaire (owner) qui a la responsabilité du comportement de l’agent.
e. L’identifiant : Chaque agent possède un identifiant unique durant son cycle de vie,
qui lui permet d’être identifié et localisé et qui soit géré par un service de nommage.
Le nom de l’agent est une combinaison de son autorité, de l’identifiant d’une
instance particulière de l’agent et de l’identifiant de type du système d’agent dans
lequel il évolue. Ce nom est immuable avec les déplacements de l’agent.
L’identifiant permet également au système de destination de savoir s’il est capable
d’interpréter l’agent entrant.
5.1.3 Caractéristiques d’un agent mobile

Les principales caractéristiques sont [MEN, 04]:
1. La mobilité : est la première caractéristique d’un agent mobile, ça concerne les
mécanismes utilisés pour transporter l’agent entre les différents sites, c'est-à-dire que
le déplacement de l’agent soit contrôlé par la fonction de migration.
Deux types de migration existent ; la migration faible et la migration forte :
Migration faible : transfert du code et de données ;
Migration forte : transfert du code, de données et de l’état d’exécution.
2. La communication : un modèle de communication est nécessaire dans un système
d’agents mobiles : ils peuvent communiquer sur le même site (communication locale),
ou sur des sites différents (communication à distance).
3. La gestion des ressources : lorsqu’un agent mobile se déplace sur un site, il y utilise des
ressources, tant matérielles (cycles CPU, segments mémoire, accès disque, accès
réseau) que logicielles (bases de données, fichiers, programmes, interface utilisateur).
Il est donc impératif que ces ressources soient contrôlées par leurs prioritaires, qu’ils
doivent éviter que l’agent mobile monopolise certaines de ces ressources.
L’agent a aussi besoin de contrôler ses propres ressources afin d’optimiser leurs
performances et satisfaire aux exigences des hôtes.
4. La tolérance aux pannes : comme un agent mobile s’exécute sur un site distant, il
pourra tomber en panne (déconnexion, défaillance…). Il faut donc définir des
42
mécanismes de récupération pour relancer l’agent à nouveau, une certaine
redondance (copies par exemple) est nécessaire.
5. La sécurité : il faut considérer avec précaution l’aspect de la sécurité des sites visités
par l’agent mobile d’une part et la sécurité des agents mobiles durant leurs exécutions
d’autre part.
En effet, le site d’accueil d’un agent doit se protéger contre la sur-utilisation des
ressources et les actions malveillantes (intentionnelles ou non) des agents accueillis.
Par exemple, des limitations sur la consommation des ressources (temps CPU, taille
mémoire) peuvent également être fixées.
En revanche, l’agent doit avoir l’assurance que ni son code ni ses données ne seront
modifiés par le système hôte. Ce problème est plus complexe que le précédent,
puisque tout ce qui est accessible par l’agent l’est aussi au système d’exploitation dans
lequel il s’exécute.
5.1.4 Types d’agents mobiles

Plusieurs types d’agent mobiles peuvent exister. Ces derniers sont à regrouper en
fonction des tâches génériques qu’ils sont en mesure d’exécuter [ROU, 04].
Agent statique :
Un agent statique est un agent mobile qui ne fait en général qu’une seule migration,
cette migration s’effectue depuis la station de départ vers un nœud bien définit au
lancement. A l’arrivée sur le nœud, l’agent mobile ne migre plus mais exécute une tache
prédéfinie.
Agent visiteur :
C’est un agent mobiles qui visite successivement les différents nœuds de la plateforme
afin d’y appliquer la même fonction d’administration du réseau, par exemple, récupérer les
versions des systèmes d’exploitation installés sur les nœuds du réseau.
Agent collecteur de données :
Un agent collectant les données est un agent mobile qui nécessite un point de rendez-
vous avec un ou plusieurs agents mobiles pour les décharger des données que ces derniers
ont collectées. Cette agent de collecte peut toutefois récupérer des données qui ont étés
laissées à sa disposition sur les différents systèmes par d’autres agents mobiles, après la
collecte cet agent transporte les données jusqu'à un système définit à l’avance.
Agent transporteur :
C’est un agent qui transporte des agents mobiles d’un réseau à un autre, ou qui
transporte les agents mobiles dans un sous réseau du même système. Il permet d’éviter la
multiplication des procédures d’authentification des agents mobiles lors du passage d’un
réseau à un autre (Par exemple si les contraintes imposées aux agents mobiles sont
différentes).
Agent de suivi d’incident :
C’est un agent qui est programmé pour réagir aux données qu’il analyse.
43
5.1.5 Avantages des agents mobiles
Le paradigme des agents mobiles est prometteur, mais les agents mobiles ne
parviennent pas à s’imposer comme technologie viable. Certains se demandent même s’ils
sont utiles. Pourtant les agents mobiles apportent des bénéfices et il est utile de les utiliser
dans certains cas. Plus précisément, il existe sept bonnes raisons d’utiliser les agents
mobiles :
1. Réduction du trafic réseau:

Les systèmes distribués basés sur le paradigme Client–Server génèrent de
multiples interactions entre le client et le serveur, le paradigme des agents mobiles
permet d’empaqueter un dialogue et de l’envoyer sur le site distant ou les
interactions (multiples) se feront en local. Plus le volume d’informations stockées
sur les sites est important, plus l’approche agent mobile est forte : déplacer les
traitements vers les données plutôt que déplacer les données vers les traitements.
2. Suppression de la latence du réseau :

Pour les applications critiques qui nécessitent du temps réel, il est impératif de
supprimer la latence du réseau (temps mort du au temps nécessaire pour se
connecter). Les interactions locales offertes par les agents mobiles résolvent ce
problème.
3. Encapsulation des protocoles :

Lorsque les hôtes d’un réseau utilisent des protocoles différents les uns des
autres, un agent mobile peut encapsuler le protocole nécessaire pour s’exécuter
sur un site donné.
4. Exécution asynchrone et autonome :

Les agents mobiles s’exécutent de manière autonome et comportent une
caractéristique essentielle ; L’asynchronisme. Cela permettra d’envoyer un agent
mobile sur le réseau puis de se déconnecter. Une fois terminée sa tache, l’agent
notifie au site initiateur qui se reconnecte pour récupérer les résultats. Une fois le
client reconnecté, il pourra récupérer ses agents mobiles qui auront terminé leurs
taches.
5. Adaptation dynamique :
Les agents mobiles, étant des agents, sont naturellement adaptatifs, c’est à dire
qu’ils perçoivent leur environnement d’exécution et réagissent aux changements.
En particulier dans un système multi-agents, les agents mobiles maintiennent une
configuration optimale pour résoudre un problème de manière coopérative.
6. Hétérogénéité naturelle :
Généralement, un agent mobile est Independent du matériel et des couches de
transport du réseau. Il dépend seulement de son environnement d’exécution. Les
agents mobiles conviennent bien aux réseaux hétérogènes.
44
7. Robustesse et tolérances aux pannes :
Grâce à leur capacité d’adaptation aux situations (surtout défavorables). Les
agents mobiles permettent de construire des applications distribuées robustes et
tolérantes aux pannes. En particulier, lorsque un hôte va être arrêté, tous les
agents s’exécutant sur cette machine seront notifiés et peuvent migrer sur un
autre site ou ils pourront continuer leur exécution.
5.2 Paradigme d’agent mobile

Pourquoi utiliser des agents mobiles ? Pour répondre à cette question qui a du mal à
trouver une réponse définitive, nous allons présenter des schémas d’organisation
distribuée afin de montrer la différence entre ses schémas et ce paradigme.
5.2.1 Schéma d’organisation Client/Serveur

Le client-serveur constitue le schéma d’organisation distribué le plus populaire et le
plus répandu jusqu’à présent, c’est le modèle de base pour le développent des applications
réparties. Dans ce schéma, on distingue deux entités : le fournisseur du service (ou
serveur) et le consommateur du service (ou client) [MEN, 04];
Le serveur : celui qui répond aux besoins du client ; il héberge un certain nombre de
services qui fournissent des accès à des ressources comme l’utilisation du CPU
(ressource physique), ou l’interrogation d’une base de données (ressource
logicielle). Nous disons que le serveur dispose du savoir-faire (know-how), puisque il
stocke localement le code qui implémente ces services.
Le serveur exécute le service demandé par le client, il a donc la capacité de
traitement.
Le client : celui qui exprime des besoins ; si un client est intéressé par des ressources
hébergées sur un serveur, il utilisera simplement les services fournis à cet effet. Le
client doit disposer d’une certaine intelligence pour décider quel service il doit
choisir.
La figure 16 est une simple présentation de ce schéma :
Serveur
Clients
Figure 16: Le schéma client/serveur.

45
Nous pouvons dire que le client-serveur est une technique de dialogue entre deux
processus, un processus client et un processus serveur. En effet, seul le client, demandeur
du service, est à la base du dialogue, ça veut dire que c’est lui qui l’initie. De son coté, le
serveur ne fait que répondre aux requêtes des clients. Une requête est un message qui
décrit l’opération à exécuter (le service) ainsi que ses données paramètres [ROU, 02].
Ce schéma est dit synchrone : le client émet une requête et se bloque jusqu’à l’arrivée
de la réponse. Afin de satisfaire un client en accomplissant un service pour son compte,
trois éléments doivent se trouver dans le même site à un instant donné. Ils sont
nécessaires pour l’exécution d’un service [ROU, 02]:
1. Le code du service (savoir-faire) ;
2. L’unité d’exécution ou « processeur » qui est une machine qui encapsule
l’état d’exécution, par exemple : pile d’exécution, compteur ordinal… ;
3. Un ensemble de ressources qui représentent les données passives ou les
unités physiques, par exemple : base de données, fichiers, mémoire,
processeur, etc.
Ce fonctionnement est simplifié à travers la figure suivante :
Figure 17: Le fonctionnement du schéma client/serveur.
5.2.2 Autres schémas d’organisation avec mobilité

En marge du schéma client/serveur, il existe d’autres schémas qui utilisent la mobilité
du code exécutable pour répartir les tâches d’exécution. Voici les principaux
schémas [ROU, 02] :
5.1.2.1 Evaluation distante

Dans une interaction par évaluation distante (Remote Evaluation ou REV), un
composant client envoie un code à un autre site. Le composant récepteur exécute le code,
qui peut contenir des données, et renvoie les résultats au composant émetteur.
46
L’unité d’exécution et les ressources sont fixes, seul le savoir-faire (le code) est mobile.
L’interaction par évaluation distante est illustrée dans la figure suivante :
Figure 18: Le schéma Evaluation distante.
Des exemples d’évaluation distance sont :

- La commande rsh du système Unix, qui permet à un utilisateur d’exécuter une
suite d’instructions (ou script) sur un site Unix distant.
- Les interactions avec les imprimantes ‘’PostScript’’ utilisent le schéma REV.
- Les requêtes SQL (Structured Query Language) émises vers un serveur de base
de données.
- Les servlets Java présentes sur un serveur HTTP.
5.1.2.2 Code à la demande

Dans le schéma de code à la demande (Code On Demand ou COD), le composant
client interagit avec le composant serveur afin de récupérer le code nécessaire à la
réalisation d’un service.
La requête sur le site serveur ne contient pas de données paramètres, le composant
serveur fournit le code du service qui sera exécuté sur le site client.
En permettant à des composants de récupérer du code, ce schéma permet d’étendre
dynamiquement le comportement d’une application.
Ainsi, la figure 19 montre le schéma Code à la demande :
Figure 19: Le schéma Code à la demande.
L’appliquette ou applet Java qui est l’exemple le plus populaire : un programme est
chargé à partir d’une page Web pour être exécutée sur le site client, généralement, au sein
du navigateur Web.
47
5.1.2.3 Agents mobiles
Comme nous avons déjà montré, les agents mobiles sont des processus (code et unité
d’exécution) qui peuvent se déplacer, dans un réseau, d’eux-mêmes d’un site à un autre
pour interagir localement avec des ressources d’autres sites.
Dans ce schéma, le savoir-faire appartient au client. Nous pouvons dire que le schéma
d’évaluation distante est un cas particulier du schéma à agents mobiles.
Ce schéma s’explique ainsi, dans la figure 20 :
Figure 20: Le schéma Agent mobile.
L’approche d’agents mobiles est plus générale : en plus du code, l’unité d’exécution
associée est mobile. De plus, les agents mobiles peuvent transporter des données
paramètres. Après l’exécution, l’agent peut, éventuellement, retourner au site initial.
5.2.3 Fonctionnement des agents mobiles

Les agents mobiles supportent les opérations déconnectes grâce au mode
d’interaction asynchrone. Ils sont indépendants des sites clients qui peuvent se
déconnecter et se reconnecter afin de récupérer ultérieurement l’agent et ses résultats.
Le paradigme d’agents mobiles propose d’utiliser la migration du code afin de
supprimer la contrainte de connexion constante. On demande aux deux parties d’être
connectées seulement pendant la phase de migration. Ainsi un agent mobile peut se
déplacer dans un réseau de machines offrant des services pour réaliser une tache
complexe.
Un client donne une mission à un agent qui pour la réaliser se déplace dans le réseau de
machines accédant localement aux services offerts par ces machines, on peut distinguer trois
phases :
L’activation de l’agent mobile avec la description de sa mission.
L’exécution de la mission par l’agent qui se déplace pour accéder aux services.
La récupération éventuelle des résultats de l’agent mobile.
48
La figure suivante (Figure 21) présente le paradigme d’agent mobile :
Figure 21: Paradigme d’agents mobiles.
Les agents mobiles se déplacent d’une machine à l’autre. Pour migrer, un agent
transfère son code et ses données sur le nouveau site puis continue son exécution sur ce
site là. A l’issue de la migration, le processus de la machine initiale est détruit par une
commande du nouveau processus.
L’intérêt de ces agents concerne les recherches dans beaucoup de données sur des
sites éloignés. Ces agents peuvent servir à nous assister dans nos taches d’administrations
quotidiennes, ils filtrent par exemples des e-mails, partent à la recherche de virus,
détectent les intrusions dans les réseaux…Etc. En Bref, ils effectuent les opérations
d’administration de base sans solliciter d’interventions humaines. Ils peuvent
communiquer entre eux, analyser l’information qu’ils recueillent et avertir le cas échéant
l’administrateur du réseau. Par ailleurs ils permettent d’éviter d’avoir une station
d’administration centralisée et statique, car au contraire, ils peuvent être interrogés et
lancés à distance de n’importe où. Toutes ces facettes des agents mobiles permettent aux
administrateurs du système de rentrer pleinement dans l’aire de la mobilité.
6 Conclusion
49
Dans ce chapitre, nous avons présenté une vue détaillée sur une approche qui est
actuellement un champ de recherche très actif, l’approche « Agents ». Cette discipline de
l'intelligence artificielle qui s’intéresse, tout d’abord, aux notions d’agents et de Systèmes
Multi-Agents.
Nous avons détaillé par la suite les différentes questions relevées par la problématique
de ces systèmes, nous avons également bien détaillé la mobilité qui est considérée comme
le futur des systèmes multi-agents.
A travers cette étude, il nous est apparu que la robustesse de ce type de systèmes
repose sur la modularité de ses composants, la richesse des interactions et l'efficacité de
communication entre agents. Cette approche est donc très adaptée à la conception de
systèmes où plusieurs éléments indépendants doivent coopérer et accéder à des sources
hétérogènes et distribuées soit sur un réseau local (Intranet) soit sur Internet qui est
devenue une partie intégrante de la vie quotidienne des agents.
L’IAD et les SMA sont des thèmes de recherche en cours d’exploitation, ils font
intervenir plusieurs domaines de recherche tels que les systèmes répartis, la biologie, l’IA
et la psychologie cognitive.
Les principales conclusions que nous pouvons tirer de cette modeste recherche sont
les suivantes:
- L’IAD s’adapte mieux à la réalité des systèmes complexes que l’IA classique. Elle
enrichit le processus de résolution de problèmes en le partageant entre
plusieurs agents.
- L’interaction de plusieurs expertises incomplètes ou peu fiables à travers les
SMA peut mener à une expertise plus sure et plus robuste.
- La puissance du nouveau paradigme d’agent mobile le rend une méthodologie
prometteuse pour le développement des nouvelles applications distribuées.
50
Chapitre 4 La Conception
Chapitre 4 : Conception
1 Introduction
Dans ce chapitre, nous présenterons la conception de notre système basé sur un
modèle à d’agents mobiles. Nous avons pu voir dans le chapitre précédent que les
approches de détection se diversifies, et la détection porte sur plusieurs aspects, et donc,
pour pouvoir choisir une approche et trouver un compromis, nous allons proposer
plusieurs scenarios envisageables que nous allons critiquer pour bien se décider.
Nous insisterons aussi sur la solution libre NAGIOS qu’on pourrait utiliser pour la
détection et le protocole SNMP qui est l’approche la plus courante dans le domaine de
supervision.
Nous allons essayer de concevoir un prototype d’un système multi-agents ouvert, dans
le sens ou il sera extensible, par l’ajout éventuel d’autres agents, et modules de détection,
de récolte d’informations ou de réaction.
Ce chapitre sera organisé comme suit ; nous allons donner en premier une
présentation générale du système, nous donnerons par la suite une description des
différentes tâches et méthodes à implémenter dans les agents avec argumentation de nos
choix, en suite nous détaillerons l’architecture interne de chaque agent, et enfin, pour
terminer une présentation du fonctionnement du système sera donnée.
2 Fonctions principales
Comme nous l’avons déjà présenté, l’objectif principal de notre application est de créer
un système de monitoring informatique, notre travail s’agira, alors, d’une implémentation
d’une architecture à base d’agents mobiles adaptée à la supervision informatique en
assurant la détection des pannes dans un système informatique donné, puis, nous allons
tenter de résoudre si possible les problèmes qui apparaissent dans un environnement de
51
réseau informatique pour offrir un meilleur service. En d’autres termes, nous concevons
notre solution comme un outil basé sur une approche de supervision pilotée par une
nouvelle technologie ; la technologie agent mobile.
Cet outil aura pour fonctions principales de :
1. Effectuer une série de tests système dans des sites donnés.
2. Visualiser ces résultats à travers une interface utilisateur.
3. Tenter si possible de réparer certaines anomalies ou signaler d’éventuels
problèmes persistants à l’utilisateur.
3 Vision proposée: Vers une supervision à base d’agents mobiles

Avant d’entamer la conception de notre plate forme de supervision, nous allons
d’abord discuter les diverses situations possibles pour répondre à la problématique.
Comme nous l’avons vu dans le chapitre 2, il existe plusieurs méthodes de détection,
ce qui induit qu’en faisant varier la méthode de détection et le nombre d’agents en
interaction, nous obtiendrons plusieurs cas de figure ou scénario. Dans ce qui suit, nous
allons les présenter tout en donnant leurs principaux avantages et inconvénients.
3.1 Utilisation d’un seul agent mobile pour la supervision

Dans ce cas, on utilise un agent mobile qui va migrer vers chaque machine supervisée,
pour y effectuer des tests sur les services considérés, la résolution des problèmes relevés
est basée sur une base de règles (base de connaissance de l’agent) pouvant être étendue
et personnalisée par l’utilisateur.
L’agent envoie des rapports périodiques au site de supervision pour informer
l’administrateur du déroulement des opérations.
Avantages:
• Economise la consommation de la bande passante.
• Nœud central peu sollicité.
Inconvénients :
• Difficulté d’implémentation vu le manque de modularité.
La figure suivante (Figure 22) illustre les différentes étapes de ce cas de figure.
52
Figure 22: Utilisation d’un seul agent mobile pour la supervision.
a) Le nœud de supervision lance des agents mobiles vers toutes les machines supervisées ;
ces agents disposent de base des connaissances dynamique et extensible.
b) L’agent mobile s’exécute dans la machine cible, cette exécution consiste à faire des
tests locaux c.à.d. des commandes système, s’il y a des problèmes l’agent réagit et tente
de régler les anomalies. Le cas échéant, il signale le problème au niveau du nœud central.
c) Quelque soit le résultat des tests, diagnostiques ou réparations, l’agent remonte un

message au serveur contenant un rapport détaillé.
d) Après analyse du rapport des résultats envoyé, si l’utilisateur n’est pas satisfait, il peut
mettre à jour la base des connaissances des agents à travers une intervention manuelle ou
par la modification d’un moteur d’inférence.
3.2 Utilisation d’un agent pour la détection et un autre pour la

réparation
Dans ce cas, deux agents sont employés, le premier sera dédié aux tests des différents
aspects supervisés, et l’autre intervient seulement dans le cas d’anomalies ou il doit réagir
suivant sa base de règles qui seront toutefois personnalisée par l’utilisateur en fonction de
ses besoins et exigences.
Avantages :
• Simplicité d’implémentation et modularité des programmes.
• Taille des agents moins importante.
53
Figure 23 : Utilisation d’un agent pour la détection et un autre pour la réparation.
Le serveur lance des agents d’analyse vers toutes les machines clientes.
a) Exécution des agents : Commandes de test systèmes, diagnostique des erreurs et
des pannes éventuelles.
b) L’envoie d’un rapport au serveur sera après la récolte des résultats des tests au
niveau des nœuds distants.
c) Si après analyse de rapport, il n’y a aucun problème, le système continu son travail
en recevant les rapports des agents mobiles qui testent les hôtes et les services à des
intervalles de temps bien définis, sinon le système renvoie un autre agent dédié pour
résoudre les problèmes survenus.
d) Exécution de l’agent réparateur, et envoie du rapport final contenant les résultats

obtenus.
e) Ajout des règles supplémentaires par l’utilisateur en cas de non satisfaction et mise
à jour de la base des connaissances des agents de réparation.
3.3 Détection avec NAGIOS et réparation par agent mobile

Cette solution se base sur les résultats des tests effectués par Nagions puisqu’ il se
restreint à la détection ; on complétera alors le manque de ce dernier en ajoutant les
parties : diagnostique et résolution des pannes implémentés dans un agent mobile qui se
mobilise à l’apparition d’anomalies.
54
Avantages:
• Coté de détection assuré et fiable.
• Archivage des résultats des tests.
Inconvénients :
• Difficulté d’implémentation ; besoin de comprendre le code source de NAGIOS
fait avec le langage de programmation C et le langage de Script Perl.
Figure 24: Détection avec NAGIOS et réparation par agent mobile.
a) L’application envoie un agent qui a pour tâche la consultation des tables de la base
de données de Nagios afin de pouvoir récupérer les informations concernant les
états des machines et des services.
b) Retour de l’agent envoyé avec un rapport sur l’état actuel de chaque service.
c) Migration d’un agent dédié qui exécute des commandes système afin de résoudre
la panne ou récupérer la fonction d’un service après détermination d’erreur.
d) Retour de l’agent ou envoi de son rapport d’exécution au serveur d’application.
Voie choisie : Le deuxième scénario

Dans le but d’atteindre notre objectif, nous avons opté pour le deuxième scenario ou
deux types d’agents sont utilisés ; des agents pour les tests et des agents de réaction, ce
55
choix est dû en grande partie à la modularité offerte par cette solution par rapport aux
autres solutions.
4 Conception
Lors de la rencontre d’un problème complexe, le mieux à faire est d’opter pour
l’approche de conception cartésienne et moduler le système le plus possible afin de
dégager les différents sous systèmes et leurs fonctions respectives.
Commençons tous d’abord par présenter la méthodologie de conception de notre
Système.
Conception du SMA selon la méthodologie « Voyelle »

La méthodologie Voyelles comporte trois étapes essentielles :
La phase d’Analyse ou d’Identification des composantes.
La phase de conception ou de Choix des modèles fonctionnels.
La phase de programmation ou d’implémentation.
Nous ne suivrons, dans cette partie de conception, que les deux premières phases.
La dernière étant relative à l’implémentation des agents (phase de réalisation).
Phase1 : Analyse
Consiste à identifier à priori les quatre composantes : A, I, E, O et U (respectivement,
Agent, Interaction, Environnement, Organisation et Utilisateur).
Phase2 : Conception
Cette phase consiste à choisir les modèles fonctionnels des composantes
préalablement définies.
4.1 Phase 1 : Analyse

L’analyse se base sur :
Agents :
Nous allons classer les agents et partager les tâches entre ces derniers, par
conséquent, nous allons avoir trois classes d’agents. La première classe, contient les
agents dont le rôle est la récolte des données, la deuxième classe d’agents effectue
l’analyse des données issues de la première classe afin de détecter les anomalies, et la
troisième classe contient les agents qui agissent en fonction des données.
• Agent de gestion : Utilisé pour la coordination et le pilotage de la supervision.
• Agents d’analyse : Utilisés pour la collecte d’informations utiles sur le réseau.
• Agent de réaction : Utilisé pour agir directement sur l’environnement.
56
Environnement :
L’environnement contient les objets et l’ensemble des agents modélisés. Les agents
sont capables d’agir sur cet environnement à partir des entrées qu’ils reçoivent de ce
même environnement. Il est constitué par ce qui est fixe durant son activation.
L’environnement de notre SMA comporte l’ensemble de machines à superviser.
Interactions :
Les interactions sont primordiales dans ce système puisque à l’origine tout est basé sur
la coopération des agents identifiés précédemment.
Chaque opération est modélisée sous forme de suites de messages pour lesquels nous
présentons toutes les interactions possibles entre les différentes entités. Il existe deux
types d’interactions :
• Interactions entre l’administrateur et l’agent de gestion : Elles correspondent soit

à l’action de l’acteur sur les paramètres du système (interaction utilisateur-agent),
soit à la présentation d’informations et de résultats dans une interface graphique
(interaction agent-utilisateur).
• Interactions entre les Agents. Elles correspondent à l’envoi et à la réception

des messages, tels que les requêtes de migration, les messages des résultats de
collecte de données ou les rapports d’exécution des agents.
Organisation :
Une structure organisationnelle est définie par :
- un ensemble de classes d’agents caractérisées par les rôles affectés aux agents.
- un ensemble des relations abstraites existant entre ces rôles.
Ces deux points seront détaillés un peu plus loin dans ce chapitre.
Utilisateur :
Le seul utilisateur réel du système et l’administrateur du réseau et qui s’occupe de la
supervision. Cependant sa présence n’est pas obligatoire puisque la résolution des
défaillances éventuelles est pilotée et gérée entièrement par le moniteur de supervision
qui est essentiellement prévu pour un fonctionnement autonome.
57
4.2 Phase 2 : Conception
4.2.1 Schéma général du système
Le schéma général de notre application peut être résumé comme suit ;
• un agent administrateur s’occupe de la coordination entre les différentes entités du

système ;
• des agents de test migrent vers tous les sites qui doivent être supervisés, et
envoient régulièrement des rapports des résultats obtenus après analyse de leurs
nœuds respectifs aux agents de réaction ;
• les agents de réaction intégrant des méthodes SNMP agissent suivant ces données,
pour soit tenter de régler les anomalies éventuelles, ou avertir l’utilisateur le cas
échéant.
Le schéma suivant résume d’une manière concise le principe de déroulement des

diverses taches de supervision (Figure 25).
Figure 25: Schéma général du système.
Agent de gestion : C’est le cerveau du system, il est stationnaire et a pour principal

rôle la coordination et la synchronisation entre les agents du système, il est
instancié avant les deux autres types d’agent et sa durée de vie est équivalente à
celle du système
58
Agents d’analyse : Ce sont des agents collecteurs de données via SNMP, ils se
déplacent sur le réseau et rassemblent les données relatives aux nœuds du
système, ces données sont redirigées vers l’agent de gestion qui les analyse et
décide de l’action à entreprendre.
Agents de réaction : Ces agents quand à eux sont instanciés par l’agent de gestion
en but de réagir à un événement donné, ils intègrent des méthodes SNMP pour
gérer directement des services systèmes. Les agents de rection sont des agents
statiques ; c’est à dire qui s’exécutent une seule fois, ils s’autodétruisent dès que
leur tache ait été accomplie.
4.2.2 Principe de fonctionnement :

Le principe du déroulement de la supervision est illustré par le schéma suivant
(Figure 25):
Figure 26: Principe de fonctionnement.
59
La stratégie de supervision est basée sur une suite logique d’événements :
1. Au début un agent de gestion est créé dans le site de supervision pour gérer la
totalité de du processus.
2. Ensuite, on instancie pour chaque site distant un agent d’analyse qui va y résider
pour alléger le trafic dans le réseau.
3. L’agent d’analyse récolte les informations localement et envoie des rapports

périodiques à l’agent de gestion.
4. L’agent de gestion analyse ces rapports et dans le cas d’une anomalie, il instancie un
agent de réaction dédié qu’il envoie directement au site en question pour résoudre
le problème. L’administrateur, quand à lui, est alerté de chaque étape durant
l’opération.
5. L’agent de réactions s’exécute localement et tente de rétablir le fonctionnement

normal de chaque service présentant des problèmes.
L’agent de réaction envoie ensuite un rapport d’exécution à l’agent de gestion lui

indiquant si l’opération s’est bien déroulée ou si le problème persiste, il s’autodétruit juste
après vu que sa tache est à présent terminée.
N.B : Le fonctionnement normal de la supervision repose sur la disponibilité de la
connexion, ainsi, pour vérifier à chaque instant que les sites supervisés sont toujours
connectés au centre de supervision, des modules spécifiques s’occupent d’envoyer des
requêtes PING périodiquement aux différents nœuds du réseau.
S’ils ne reçoivent pas de requêtes PING après un délai déterminé, l’administrateur est
alerté d’une défaillance de communication qui pourrait être due à différentes causes (câble
réseau débranché, default d’adresse IP, Pare-feu bloquant la communication, …etc.).
60
4.3.3 Entités et modules du système :
Le schéma suivant résume les principales entités et composantes de notre système de
supervision :
Figure 27 : Entités et composantes du système.
L’administrateur interagit directement avec une interface utilisateur qui traduit les
résultats des données de test sous une forme simple et intuitive, et à travers laquelle on a
une vision globale du fonctionnement des différents services des réseaux supervisés.
Les agents du système quand à eux collaborent pour accomplir la tache de supervision,
les agents de test et de réaction sont ceux interagissent avec les nœuds du réseau, l’agent
de gestion est chargé de la synchronisation et la coordination de l’opération globale.
Les modules de test de connectivité sont utilisés dans le but de vérifier à chaque
moment la disponibilité des nœuds du système et avertir l’utilisateur dans le cas d’un
problème de connexion.
61
4.3.4 Description des agents du système
La partie suivante est consacrée à la description des agents présentés précédemment
et à l’organisation et échange de données entre agents.
Agent de gestion
C’est le cerveau du système, il pilote l’application et gère l’intégralité de l’opération

de supervision, il reçoit en entrée des données et des paramètres pouvant provenir des
autres agents tels que les rapports d’analyses ou les rapports d’exécution des agents de
réaction, et des informations sur l’environnement et la méthodes de supervision tels que
la connexion ou la déconnexion d’un nœud, les problèmes de communication, le
changement de paramètres et des préréglages par l’administrateur.
Différents modules sont implémentés dans le corps de cet agent :
• Des modules d’émission et de réception de messages entre agents, elle est

globalement la même sur tous les agents.
• Des modules et routines de gestion et de traitement des donnés d’analyses et de

gestion de l’application.
• Des modules de test de disponibilité de connexion avec les nœuds supervisés du

réseau.
Le schéma suivant illustre mieux l’architecture interne de cet agent (Figure 28):
Figure 28 : Agent de gestion.
62
Agent d’analyse
Il est moins complexe que l’agent de gestion, il comprend une unité de

communication, et des modules pour accomplir la tache de collecte d’information sur l’état
les services du nœud ou il se trouve. Principalement c’est des routines SNMP.
Il reçoit en entrée des données de commandes telles que les requêtes de migration
vers des nouveaux nœuds, ou les changements éventuels de paramètres de supervision.
Le schéma suivant illustre mieux l’architecture interne de cet agent (Figure 29):
Figure 29 : Agent d’analyse.
Agent de réaction
L’agent de réaction comprend principalement des modules SNMP pour manipuler des
services systèmes, il peut également faire appel direct à des fonctions système, les
modules de communication sont juste utilisés pour envoyer les rapports d’exécution de ce
dernier à l’agent de gestion et le passage des paramètres nécessaires (Adresse du nœud
présentant un problème et liste des services défaillants).
63
Voici ci-dessous son architecture illustrée dans la figure 30 :
Figure 30 : Agent de réaction.
4.3.5 Schéma d’interaction Inter-Agents

La communication et échange de données dans les SMA se fait soit par mémoire
partagée ou par messages, mais du moment ou le système comprend des agents mobiles,
la première méthode devient difficile à gérer et augmente le trafic sur le réseau, pour cela
nous avons opté pour la communication par messages afin de nous simplifier les travail,
chaque agent comme décrit précédemment contient des modules de gestion de
communication inter-agents, les messages sont au format texte, formatés d’une manière à
simplifier leur découpage pour extraire et interpréter leurs contenu. Un protocole de
communication spécifique est utilisé pour assurer l’échange de messages inter agents.
Le schéma suivant résume la communication entre les agents du système (Figure 31):
Figure 31: Schéma d’interaction inter-agents.
64
Les différents messages échangés sont :
• Des requêtes envoyées par l’agent de gestion aux agents d’analyse (1) et de
réaction (2).
• Des rapports envoyés par les agents d’analyse et de réaction à l’agent de gestion
(3) et (4).
Le schéma UML suivant illustre la chronologie des interactions inter-agent :
Figure 32: Diagramme d’interaction inter-agents
65
5 Conclusion
Nous avons présenté dans ce chapitre la conception de notre système de supervision
basé sur un système multi agent utilisant l’approche SNMP implantée dans des agents
mobiles. Nous résumons les caractéristiques de notre prototype dans les points suivants :
- Architecture : Système multi-agent.
- Détection : Approche SNMP.
- Déploiement : Réseau.
- Comportement après rencontre d’anomalie : Actif (Tentative de résolution).
- Fréquence d’utilisation : Continue.
Nous allons présenter dans le chapitre qui suit l’implémentation et la réalisation de

l’architecture proposée.
66
Chapitre 5 L’implémentation
Chapitre 5 : Implémentation
1 Introduction
Ce chapitre sera consacré à la l’implémentation et mise en pratique de notre système
de supervision. Nous commencerons par décrire les outils de développement utilisés, après
quoi nous présenterons l’interface utilisateur de notre système.
2 Environnement de développement
Dans la figure suivante, nous illustrons nos choix en termes d’environnement de
développement (Figure 32):
Figure 33: Environnement de développement.
Le choix des outils de développement joue un rôle très important et décisif dans le
développent des applications. Plusieurs critères devront être définis et respectés. Parmi
ces critères on site :
67
- Le temps de développement : nous devrons utiliser les outils qui minimisent le
temps de développement, et facilitent l’implémentation et la maintenance de
l’application.
- La stabilité : les outils utilisés devront être les plus stables possibles pour faciliter le
débogage lors du développement.
- La portabilité : les outils devront nous permettre de réaliser des applications
compatibles avec un grand nombre de plateformes matérielles et logicielles.
- Simplicité : facilité d’utilisation et disponibilité de la documentation.
- Les licences : notre préférence va aux outils libres de droits qui n’imposent pas de
restriction sur le développement et la diffusion de l’application.
Nous allons présenter dans ce qui suit les outils utilisés et les raisons du choix de
chaque outil.
2.1 Plateforme JADE pour le développement des SMA

Pour développer des agents, il est pratique de choisir une plate-forme. A l’heure
actuelle, plusieurs outils ont été développés pour la réalisation d’agents. Si ces plateformes
abondent en quantité, elles ne répondent pas toutes aux critères que nous nous sommes
fixés. Cette partie présente notre démarche dans le choix d’une plate forme de
développement d’agents.
La plate forme devra répondre aux contraintes suivantes :

- La plate forme doit répondre à plusieurs fonctionnalités et offrir une large gamme
de bibliothèques.
- Il faut tenir compte de la nature de l’interface de développement vu le temps court
réserver au développement des agents.
- La plateforme doit être répandue. Elle doit avoir été utilisée dans plusieurs projets
de développement de systèmes multi-agents pour avoir un maximum d’exemple et
de tutoriaux.
- Le langage de programmation sous jacent et la nature des messages échangés sont
aussi un point important. Un langage connu et répandu favorisera une meilleure
compréhension des codes sources.
Nous avons choisis JADE (Java Agent DEveloppement framework) pour les raisons
suivantes:
- Facilité d’installation.
- Documentation détaillée.
- Utilise un langage puissant et stable (JAVA).
- Intégration avec d’autres outils de développement (Intégration dans Eclipse via les
plugins EJIP et EJADE).
68
- Licence libre (LGPL : (pour GNU Lesser General Public License) ; c’est une licence
utilisée par certains logiciels libres.).
JADE est une plate-forme multi-agents développée intégralement en JAVA, par F.

ellifemine & A. Poggy, G.Rimassa, P. Turci pour la société de télécommunications CSELT
(Italie) en 1999. Elle a pour but de faciliter le développement des applications agent
conformément à la norme FIPA (Fondation for Intelligent Physical Agents) pour les
systèmes multi-agents interopérable. JADE essaye d’optimiser les performances d’un
système d’agents distribué. (Une description détaillée de JADE est donnée dans l’annexe).
2.2 Environnement Eclipse pour programmer en JAVA

JAVA fut le langage de notre choix vu que nous avons choisi préalablement la
plateforme JADE, et aussi grâce à sa portabilité et à son aspect Orienté Objet qui facilite la
migration d’une conception d’objet vers une implémentation de classe.
Pour Eclipse, c’est un environnement de développement intégré (le terme Eclipse
désigne également le projet correspondant, lancé par IBM) extensible, universel et
polyvalent, permettant potentiellement de créer des projets de développement mettant
en œuvre n'importe quel langage de programmation. Eclipse est principalement écrit en
Java, et ce langage, grâce à des bibliothèques spécifiques, est également utilisé pour écrire
des extensions.
La spécificité d'Eclipse vient du fait de son architecture totalement développée autour
de la notion de plug-in: toutes les fonctionnalités de cet atelier logiciel sont développées en
tant que plug-in. Plusieurs logiciels commerciaux sont basés sur ce logiciel libre.
2.3 Le package ‘’SNMP4J’’ pour les tests des services

SNMP4J est un package pour java permettant d’intégrer les fonctions et des routines
SNMP dans des programmes java, pour notre cas d’utilisation, ce sera l’outil élémentaire
pour implémenter les corps des agents d’analyse et de réaction pour manipuler des
services systèmes en plus des commandes de l’API de Windows (Application Programming
Interface : ensembles de commandes et fonctions de gestion du système d’exploitation). Il
intègre aussi les agents SNMP qui vont être lances dans les machines supervisées afin d’en
récolter et de récupérer les données nécessaires.
3 Intégration de JADE et SNMP4J dans Eclipse

L’intégration de JADE est SNMP est simple a faire sur Eclipse, il suffit de définir pour un
projet les différentes bibliothèques utilisées.
69
La figure suivante (Figure 34) montre l’explorateur de package après intégration des
JARs.
Figure 34: Intégration de JADE et SNMP4J avec Eclipse.
Le JADE RMA est une console de la plateforme JADE, c’est un genre d’explorateur ou
on peut voir les conteneurs les agents actifs du système, le Main-Container est le
conteneur principal lancé dans la machine du serveur de supervision, les autres tels au
Container- 1 dans l’exemple suivant est le conteneur lancé à partir d’une autre machine et
relié au conteneur principal.
70
La figure suivante présente l’interface utilisateur du JADE RMA (Figure 35).
Figure 35: Le moniteur JADE RMA.
4 Présentation de l’interface de MAMS (Multi Agent Monitoring

System)
L’environnement de l’application est intuitif et très simple d’usage, il permet d’avoir
une vue globale sur le fonctionnement des services considérés sur les nœuds supervisés.
Aussi mous avons pensé à un champ LOG (Journal) pour lister a chaque étape l’état du
système. Pour chaque machine supervisée on utilise une sorte de tableau de bord qu’on
affiche pour donner en tout instant l’état actuel de la machine et des services supervisés
sur celle-ci. La figure suivante représente l‘interface utilisateur après démarrage de MAMS
(Figure 36).
71
Figure 36: L’interface utilisateur MAMS.
5 Mise en pratique
La supervision ne peut démarrer qu’après le lancement de la plate forme JADE dans
tout les nœuds du réseau, après quoi les différents agents pourront êtres exécutes et
migrés vers les différentes machines, JADE utilise un mécanisme souple pour le lancement
de la plate forme sur des machines distantes, c’est la notion de conteneurs qui existent en
deux types ; conteneurs principaux qui doivent être lancés dans des machines offrant
généralement des services comme dans notre serveur de supervision, et conteneurs
simples qui doivent être reliés au conteneurs principaux pour étendre la plateforme. Cette
notion est bien détaillée dans l’annexe.
La figure suivante montre l’application exécutée sur les machines qui vont être
supervisées, sont rôle est principalement de lancer la plate forme JADE et Le démarrage du
client SNMP sur la machine en question, pour le champ ou l’adresse doit être entrée, il
s’agit de l’adresse IP du serveur de supervision ou se trouve le conteneur principal avec
lequel sera relié le conteneur lancé par l’application cliente (Figure 37).
72
Figure 37 : Le client de supervision.
6 Services supervisés
La supervision de notre application porte sur l’aspect fiabilité et disponibilité des
services systèmes. Le but de notre étude étant la recherche, nous avons donc cherché à
prouver la justesse de notre théorie et nous n’avons supervisé qu’un nombre restreint de
services système. On a choisi les services les plus connus de la communauté des
utilisateurs, à savoir ;
1. Le HyperText Transfer Protocol, plus connu sous l'abréviation HTTP.
2. Le service DHCP pour : Dynamic Host Configuration Protocol.
3. Le service d’accès au web à travers le réseau : WebClient.
4. Et le service connu Terminal Network ou TelNet.
Des voyants sont utilisés pour signaler l’état des services dans les tableaux de bord, à
savoir :
• Voyant vert : Service en marche
• Voyant rouge : Service interrompu
• Voyant bleu : Service ignoré
• Voyant orange : Etat du service inconnu
73
Figure 38: Les services supervisés.
7 Nœuds supervisés
Les nœuds supervisés sont enregistrés dans une liste dynamique, on peut avoir leurs
adresses IP ou les supprimer afin d’ignorer complètement leur comportement dans le
serveur de supervision. Dans leurs tableaux de bord respectifs, un voyant représenté par
un PC montre à tout instant si le nœud est toujours joignable (Voyant en couleurs) ou s’il
est déconnecté du serveur de supervision (Voyant en noir et blanc).
74
La figure 39 montre la boite de dialogue des nœuds supervisés.
Figure 39: Les nœuds supervisés.
8 Conclusion
Dans ce chapitre, nous avons présenté les différents aspects liés à l’implémentation de
notre système. Cette partie nous a permis de toucher un peu au coté pratique et nous a
émergé dans les nouvelles technologies telles que les SMA et la supervision informatique,
ce qui nous a permis de comprendre le fonctionnement de ces technologies.
75
Conclusion et Perspectives
Conclusion générale
Nous avons tenté dans ce modeste travail de relier deux domaines très vastes de
l’informatique actuelle. D’un coté la supervision informatique et d’un autre l’intelligence
artificielle avec les systèmes multi-agents.
L'approche d'agents mobiles constitue un paradigme de programmation puissant et

efficace pour les applications sur réseau.
La réalisation de ce projet nous a permis de mettre en pratique nos connaissances

théoriques. Nous nous sommes entre autres familiarisés avec les outils suivants :
-L’environnement Eclipse pour développement d’applications Java.
-La plateforme multi agents « Jade » pour l'implémentation des SMA.
-L’approche SNMP pour la supervision sur réseaux.
Et bien sur, il y a toujours place pour l’amélioration de notre architecture, comme
perspectives nous pouvons penser à :
- Rajouter d’autres services pour enrichir et compléter les modules de supervision afin
d’être plus fiables et plus complets.
- L’archivage les données récoltées par les agents d’analyse pour des statistiques et
des traitements futures.
- Etendre les modules de détection et de réactions afin de superviser des machines des
réseaux hétérogènes.
- Elaborer d’autres versions pour autres systèmes d’exploitation comme Linux et
Solaris.
- L’utilisation d’agent mobile comme plugin pour NAGIOS serait aussi très intéressante.
« Il n’est pas tant important de tout savoir que de connaître la valeur exacte de chaque chose,
d’apprécier ce que nous apprenons, et de faire avec ce que nous savons. »
Hannah More
76
Bibliographie
Bibliographie et Web-graphie :
[BAR, 03] F.A. M. BARIKA, « Vers un IDS Intelligent à base d’Agents Mobiles »,
Université de Tunis, 2003
[BRA, 87] M. E. BRATMAN, « Intention, Plans, and Practical Reason ». Harvard

University Press: Cambridge, MA - 1987.
[BUF, 03] O. BUFFET, « Une double approche modulaire de l’apprentissage par

renforcement pour des agents intelligents adaptifs », Université Henri
Poincaré – Nancy France, 2003.
[CHA, 94] B. CHAIB-DRAA, « Distributed Artificial Intelligence: An overview »,

Encyclopaedia of Computer Science and Technology, volume 31,
pages 215-243, 1994.
[CHA, 01] B. CHAIB-DRAA, I. JARRAS et B. MOULIN, « Systèmes multi-agents :

Principes généraux et applications », Article paru dans : J. P. BRIOT et
Y. DEMAZEAU « Agent et systèmes multi-agents » chez Hermès , 2001.
[CHE, 02] V. CHEVRIER, « Contributions au domaine des systèmes multi-agents »,

Mémoire d’habilitation à diriger des recherches. Université Herni
Poincaré, Nancy, 2002.
[COU, 07] R. COURDIER, « Cours Intelligence Collective et Système Multi-Agents ».

Université de la Réunion, 2007
[DEM, 95] Y. DEMAZEAU, « From Interactions to Collective Behaviour in Agent-

Based Systems », Proceeding of the First European Conference on
Cognitive Science, Saint-Malo, p. 117-132, 1995.
[DEM, 01] Y. DEMAZEAU et J.P. BRIOT, « Introduction aux agents: Principes et

architecture des systèmes multi agent », collection IC2, Hermès, 2001.
[DIE, 90] R. DIENG, « Relation Linking Cooperating Agents ». The 2nd European
Workshop MAAMA’90, page 185-202, Saint-Quentin in Yvelines-France
, Aout 1990.
[DOS, 06] T. DOSTES, « Mise en œuvre d’un portail de supervision des systèmes et
réseaux », Formation Nagios, Mars 2006.
[DRO, 05] A. DROGOUL, MIRIAD, « Systèmes multi-agents », OASIS/LIP6,

Université Paris 6.
[DUR, 89] E. H. DURFEE, V. LESSER, « Negotiating task decomposition and

allocation using partiel global planning », Pitman publishing: London
77
Bibliographie
and Morgan Kaufmann: San Mateo, CA - 1989
[FER, 97] J. FERBER, « Les Systèmes Multi-Agents : Vers une Intelligence

Collective », Inter-éditions - 1997.
[GAR, 00] T. GHARBI, « Structuration d’applications réparties dans un

environnement mobile », USTHB, 2000.
[GUE, 96] Z. GUESSOUM, « Un environnement opérationnel de conception et de

réalisation de systèmes multi – agents ». Thèse de l’université de
paris6 Laforia, 1996.
[HOA, 02] T. HOANG et M. KOLP, « Développement de patrons de conception à

ancrage social pour architectures multi-agents ». Belgique, 2002.
[KLU, 99] M. KLUSCH, « Intelligent Information agents: Agent-based information

discovery and management on the internet », Springer preface, 1998.
[LAB, 93] S.LABIDI, W.LEDJOUAD, « De l’intelligence artificielle distribuée aux

systèmes multi-agents », Institut national de recherche en
informatique et automatique INRIA France, Août 1993.
[LAR, 03] B. LARAB et A. ZERHOUNI, « Agents mobiles anonymes », USTHB

Alger, 2003.
[LUD, 99] L. BLIN, « Gestion des télécommunications, de la télématique et de la

télévision », Septembre 1999.
[MAE, 95] P. Maes, « Artificial Intelligence meets Entertainment: Lifelike

Autonomous Agents », Communications of the ACM 38 (11), pp. 108-
114, novembre. 1995.
[MAL, 94] T. MALONE et K. CROWSTON, « The interdisciplinary study of

coordination », ACM Computers Surveys, 1994
[MBA, 03] A. MBALA HIKOLO, « Analyse, conception, spécification et

développement d’un système multi-agents pour le soutien des activités
en formation à distance », octobre 2003.
[MED, 07] S. MEDJADBA et H. BOULEFAAT, « Conception et réalisation d’un

comparateur des prix à base des agents mobiles », USTHB Alger, 2007
[MEL, 04] T. MELLITI, « Interopérabilité des services Web complexes. Application

aux systèmes multi-agents », décembre 2004.
[MEN, 04] D.E. MENACER, « Un modèle d’architecture à base d’agents mobiles

pour les applications réparties », Institut national de formation en
informatique Alger, 2004.
78
Bibliographie
[NWA, 96] H. S. Nwana. « Software Agents Knowledge Engineering: An

Overview ». 1996.
[OLI, 98] R. F. Teixeira De OLIVEIRA, « Gestion des Réseaux avec Connaissance

des Besoins: Utilisation des Agents Logiciels », Thèse de l’ENST de Paris,
1998.
[OUD, 05] Clément OUDOT, « Linagora : Utilisation du module Rapport de
Nagios », 2005.
[PER, 97] P. Stéphane, « Agents mobiles pour l’accès nomade à l’information

répartie dans les réseaux de grande envergure », Université Joseph
Fourier - Grenoble, 1997.
[PIC, 04] G. PICARD, « Méthodologie de développement de systèmes Multi

agents adaptatifs et conception de logiciels à fonctionnalité
émergente », Université Paul Sabatier de Toulouse III, 2004.
[REU, 04] E. REUTER, « Agents Mobiles : Itinéraires pour l’administration système

et réseau », Université de Nice Sophia Antipolis, Mai 2004.
[RIC, 01] P.M. RICORDEL, « Programmation Orientée Multi-Agents », Institut

national polytechnique de Grenoble, octobre 2001.
[ROU, 04] L. ROUANE, « L’apport des systèmes multi-agents à la recherche

d‘information dans les bases de données réparties », Institut national
de formation en informatique d’Alger, 2004
[SAB, 01] A. SABAS, « Systèmes multi-agents : une analyse comparative des

méthodologies de développement », Université du Québec à Trois-
Rivières, Octobre 2001.
[SEC, 03] Y. SECQ, « RIO : Rôles, Interactions et Organisations une méthodologie

pour les systèmes multi-agents ouverts », Université des Sciences et
Technologies de Lille France, 2003.
[SEK, 07] L. SEKHRI et N. KADRI, « Une approche multi-agent pour la détection

d’intrusions », Institut national de formation en informatique d’Alger,
2007.
[WHI, 95] J.E. WHITE, « Telescript technology : an introduction to the language »,

General Magic Inc., 1995
[WOO, 95] M. Wooldridge, « N. R. Jennings, Agents: Theory and Practice », 10(2):

115-152, 1995.
[WOO, 02] M. WOOLDRIDGE, « An introduction to Multiagent Systems », John

Wiley and Sons Publishers – Angleterre, 2002.
79
Web-graphie
[Lien 1] « Modèle Agent-Cellule, un Agent réactif »,
<http://www.limsi.fr/~jps/enseignement/examsma/2005/3.simulation_1/carriere.ht
ml>
[Lien 2] P.E. MICHON, D. DUGUAY et G. EDWARD, « Modules d’un agent cognitif »,

<http://www.cybergeo.eu/index10461.html>
[Lien 3] E. D’HEM, « La sécurité par le monitoring 2003 »,

<http://www.netvigie.com/Societe/Presse/Articles/la_securite_par_le_monitoring.
html>
[Lien 4] «Annuaire des logiciels libres»,

<http://www.01net.com/contenu/4817/annuaire-logiciels-libres>
[Lien 5] D. REVUZ, « Nagios et la Supervision »

http://www-igm.univ-mlv.fr/~dr/XPOSE2004/nchaveron/Supervision.html#modules
[Lien 6] N. CHAVERON, « La supervision de Nagios »,

<http://nagios.square-box.com>, Décembre 2004
[Lien 7] L. DESIMONE, P. JERMINI, « Le monitoring avec Nagios »,

<http://ditwww.epfl.ch/SIC/SA/SPIP/Publications/spip.php?article1450>, Mars 2008
[Lien 8] A. M. FLOREA, « Agents intelligents », < http://turing.cs.pub.ro/auf2/>, 2002.
[Lien 9] « Management Information Base »,

<http://fr.wikipedia.org/wiki/Management_Information_Base>
[Lien 10] C. CALECA, « Tutoriel SNMP »,
<http://christian.caleca.free.fr/snmp/> , Septembre 2003
[Lien 11] S. CALON, S. FONTAINE, « Cours SNMP »,

<http://www.frameip.com/snmp/> , Septembre 2007
[Lien 12] Hewlett Packard, « OpenView User Guide 2004 »,

< http://www.hp.com>, 2004
[Lien 13] IBM Tivoli Monitoring, « Guide de l’utilisation Version 5.1.2 »,

< http://www.IBM.com>
[Lien 14] E. GALSTAD, « Nagios Version 3.x Documentation », <http://www.nagios.org>, 2007
[Lien 15] G. BERNARD, « Etude Nagios », < http://www.todoo.biz/>, 2003
80
Annexe : La plate-forme JADE

1 - Présentation de la plate forme JADE
Le meilleur moyen pour construire un Système Multi-Agent (SMA) est d'utiliser

une plate-forme multi-agent. Celle-ci est un ensemble d'outils nécessaire à 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éé, ils peuvent être sous la forme
d'environnement de programmation (API7) ou d'applications permettant d'aider le
développeur à la programmation d’un SMA ainsi que son débogage.
Nous allons décrire dans cette partie la plate-forme JADE et ses principales
caractéristiques.
1.1 - Introduction
JADE (Java Agent DEvelopment Framework) est une marque déposée, enregistrée par
CSELT (Centro Studi E Laboratori Telecomunicazioni)8, résulte principalement d'une
activité de recherche.
JADE est une plate-forme multi-agents crée par Bellifemine, Poggy et Rimassa en 1999,
elle permet le développement et l’exécution de systèmes multi-agents conformes aux
normes FIPA9 1997. La plate-forme est implémentée en Java et fourni deux composantes
de base : Une plate-forme agents compatible FIPA et un paquet logiciel pour le
développement des agents Java inclut
- Un environnement d’exécution (Runtime environnement) où les agents JADE

vivent ;
7
Application Programming Interface.
8
Groupe de recherche de Gruppo Telecom, Italie.
9
Foundation for Intelligent Physical Agents (organisation à but non lucratif produisant des normes pour l’interopérabilité
des agents hétérogènes de logiciels), son site principale : www.fipa.org
81
- Une bibliothèque de classes que les programmeurs peuvent utiliser (directement ou
en les spécialisant) pour développer leurs agents ;
- Une suite d’outils graphiques qui permet d’administrer et de surveiller l’activité
courante des agents.
1.2 - Conteneurs et Plateformes
Chaque instance de l'environnement d'exécution de JADE est appelée « conteneur »

(container) car elle peut contenir plusieurs agents. L'ensemble des conteneurs actifs est
appelé « plateforme ». Dans chaque plateforme, un conteneur spécial appelé conteneur
principal (main container) doit toujours être en activité, les autres conteneurs
s'enregistrent auprès de celui-ci à leur démarrage.
La figure 1 illustre, à travers un exemple, les notions définies ci-dessus. Cet exemple
montre deux plateformes JADE composées respectivement d’un et de trois conteneurs.
Les agents JADE sont identifiés par un nom unique. Grâce à la connaissance de leurs noms
respectifs, les agents peuvent communiquer de façon transparente, sans avoir à prendre
en considération la localisation de chacun : même conteneur (exemple des agents A2 et
A3), conteneurs différents au sein de la même plateforme (exemple des agents A1 et A2)
ou plateformes différentes (exemple des agents A4 et A5).
Figure 1. Conteneurs et plateformes.
82
Une plateforme d'agents peut être répartie sur plusieurs serveurs. Une seule
application Java, et donc une seule machine virtuelle de Java (JVM), est exécutée sur
chaque serveur.
Chaque JVM est un conteneur d'agents qui fournit un environnement d’exécution

complet pour l'exécution d'agents et permet à plusieurs agents de s'exécuter en parallèle
sur le même serveur. Chaque conteneur d'agents est un environnement multi- threads
composé d'un thread d'exécution pour chaque agent.
La distribution de ces conteneurs à travers un réseau d'ordinateurs est permise à

condition que la communication RMI10 entre leurs hôtes soit conservée. Chaque conteneur
d'agents est un objet serveur RMI qui gère localement un ensemble d'agents. Il règle le
cycle de vie des agents (création, suspension, attente et destruction). Il assure en plus, le
traitement de tous les aspects de la communication : répartition des messages ACL reçus,
routage des messages selon l’agent destinataire (receiver) et dépôt des messages dans les
files de messages privées des agents. Pour les messages vers l'extérieur, le conteneur
d'agents maintient assez d'information pour chercher l'emplacement de l'agent récepteur
et pour choisir une méthode de transport convenable pour expédier le message ACL.
La plate-forme offre une interface graphique utilisateur (GUI) pour la gestion

à distance qui permet de contrôler et surveiller le statut des agents, par exemple arrêter
et remettre en marche un agent. L'interface graphique permet aussi de créer
et de commencer l'exécution d'un agent sur un hôte éloigné, à condition qu'un conteneur
d'agents s'exécute déjà sur cet hôte. L'interface elle-même a été implémentée comme un
agent, appelé RMA (Remote Monitoring Agent). Toute la communication entre les agents
et l'interface (GUI) et toute la communication entre cette interface et l'AMS est faite par
ACL via une extension ad hoc de l'ontologie des agents de gestion FIPA.
JADE supporte la gestion des comportements coopératifs. Le runtime inclut quelques

fonctions complexes prêtes à l'emploi pour les tâches les plus communes dans la
programmation agent, comme des protocoles d'interaction de FIPA. JADE offre entre
10
Remote Method Invocation (Méthode d’invocation à distance).
83
autres un certain JessBehaviour qui permet la pleine intégration dans JESS, où JADE fournit
le GUI de l'agent et garantit la conformité de FIPA, alors que JESS est le moteur qui
exécute tout le raisonnement nécessaire. On a donc la possibilité de créer des agents
intelligents en délégant le raisonnement à d'autres outils.
1.3 - La Bibliothèque JADE
JADE est composé des principaux packages suivants :

- Jade.core implante le noyau du système. Il possède la classe « Agent » qui doit être
étendue par les applications des programmeurs. Une classe behaviour
(comportement) est contenue dans jade.core.behaviours, qui est une sous classe
de jade.core. Les comportements implémentent les tâches ou intentions des
agents.
- Le package jade.lang contient un sous-package pour chaque langage de
communication utilisé par JADE en particulier jade.lang.acl.
- Jade.content contient un ensemble de classes qui permettent de définir
des ontologies.
- Jade.domain contient toutes les classes Java qui représentent les entités Agent
Managment définies par FIPA en particulier AMS et DF.
- Jade.gui contient un ensemble générique de classes utiles pour la création de GUIs
pour l’affichage, l’édition des messages ACL, et de la description des agents.
- Jade.mtp contient une interface Java que chaque MTP (Message Transport
Protocol) doit implémenter.
- Jade.proto contient des classes qui modélisent les protocoles standards
d’interaction. Les classes permettent aussi aux programmeurs d’ajouter d’autres
protocoles.
- JADE est accompagnée de certains outils qui facilitent l’administration de la plate
forme et le développement d’applications. Chacun de ces outils est contenu dans
un sous package de jade.tools.
84
1.4 - Les Agents de base
Pour supporter la tâche difficile du débogage des applications Multi-Agent, des outils
ont été développés. Chaque outil est empaqueté comme un agent, obéissant aux mêmes
règles, aux mêmes possibilités de communication et aux mêmes cycles de vie d’un agent
générique.
1. Remote Managment Agent « RMA » : le RMA permet de contrôler le cycle de vie de

la plate-forme et tous les agents la composant. L'architecture répartie de JADE
permet le contrôle à distance d'une autre plate-forme. Un RMA est un objet Java,
instance de la classe jade.tools.rma.rma et peut être lancé à partir de la ligne de
commande Java jade.Boot -gui. Plusieurs RMA peuvent être lancés sur la même
plate-forme du moment qu'ils ont des noms distincts.
Figure 2. Interface graphique d’un RMA.
2. Agent Management System « AMS » (système de gestion d’agents) : est un agent

qui exerce la supervision et le contrôle de sur l’accès et l’usage de la plateforme
(voir figure 2). Il fournit les services de pages blanches en maintenant un répertoire
85
des identifiants d’agents (AID) et de leurs états respectifs. Chaque agent doit
s’inscrire auprès de l’AMS pour obtenir un AID valide.
3. Agent Communication Canal « ACC » (canal de communication) : c’est le composant
logiciel qui contrôle tous les échanges de messages dans la plateforme, incluant
également les messages de/vers des plateformes distantes. L’agent ACC doit aussi
être compatible avec le protocole IIOP11 pour assurer l’interopérabilité entre les
différentes plateformes.
4. Directory Facilitor « DF » (facilitateur d’annuaire) : c’est l’agent fournissant un
service de pages jaunes à la plateforme. Grace à ce service, un agent peut connaître
les agents capables de lui fournir les services qu’il requiert pour atteindre son but.
L’interface du DF peut être lancée à partir du menu du RMA, cette action est en fait
implémentée par l’envoi d’un message ACL au DF lui demandant de charger son
interface graphique. L’interface peut être juste vue sur l’hôte où la plateforme est
exécutée. En utilisant cette interface, l’utilisateur peut interagir avec le DF : voir la
description des agents enregistrés, ajouter ou supprimer des agents, modifier la
description sur les agents enregistrés ou chercher la description d’un agent.
Figure 3. Interface du DF.
11
Le protocole IIOP, compatible avec la norme FIPA 1997, pour connecter les différentes plateformes
multi-agents.
86
5. Dummy Agent « DA » : l'outil DummyAgent permet aux utilisateurs d'interagir avec
les agents JADE d'une façon particulière. L'interface permet la composition et
l'envoi de messages ACL et maintient une liste de messages ACL envoyés et
reçus. Cette liste peut être examinée par l'utilisateur et chaque message peut être
vu en détail ou même édité. Plus encore, le message peut être sauvegardé sur
le disque et renvoyé plus tard. Plusieurs instances du DummyAgent peuvent être
lancées de la barre de menu du RMA.
Figure 4. Interface graphique d’un Dummy Agent.
6. Sniffer Agent « SA » : Quand un utilisateur décide d'épier un agent ou un groupe

d'agents, il utilise un agent Sniffer. Chaque message partant ou allant vers ce
groupe est capté et affiché sur l'interface du sniffer. L'utilisateur peut voir et
enregistrer tous les messages, pour éventuellement les analyser plus tard. L'agent
peut être lancé du menu du RMA ou de la ligne de commande suivante Java
jade.Boot sniffer : jade.tools.sniffer.sniffer
87
Figure 5. Interface du Sniffer Agent.
7. Introspector Agent : Cet agent permet de gérer et de contrôler le cycle de vie

d'un agent s'exécutant et de la file de ses messages envoyés et reçus.
Figure 6. Interface de l’introspector.
88
2 - Cycles de vie d’un agent JADE
Un agent JADE peut, à un instant donné, être dans l’un des états établis par la spécification
FIPA relative au cycle de vie de la plateforme d’agents. Ces états sont :
Figure 7. Cycle de vie d’un agent.
AP_INITIATED : l’agent est créé, mais ne s'est pas encore enregistré à l'AMS, il n'a ni
nom ni adresse et ne peut pas communiquer avec d'autres agents.
AP_ACTIVE : l’agent est inscrit à l'AMS, a un nom et une adresse réguliers et peut
accéder à tous les dispositifs de JADE.
AP_SUSPENDED : l’agent est actuellement arrêté. Son thread est suspendu et aucun
de ces comportements (Behaviour) n'est exécuté.
AP_WAITING : l'agent est bloqué, il attend quelque chose. Son thread est en
sommeil et se réveillera dès qu’une condition sera vérifiée (exemple : l’arrivée d’un
message).
AP_DELETED : l'agent est mort. Le thread correspondant a terminé son exécution et
l'agent n’est plus inscrit à l'AMS.
AP_TRANSIT : un agent mobile est dans cet état lorsqu’il migre vers un nouvel
emplacement. Le système continue à stocker ses messages qu’il lui transmettra
à son nouvel emplacement.
AP_COPY : cet état est exécuté par JADE pour cloner un agent.
89
AP_GONE : cet état est exécuté par JADE quand un agent mobile migre à un nouvel
endroit et a un état stable.
La classe « Agent » fournit des méthodes publiques pour exécuter des transitions entre
les divers états ; ces méthodes sont conforment aux spécifications de la FIPA pour
la gestion des agents. À titre d’exemples :
La méthode doWait() (correspond à la fonction sleep() pour les threads de java) fait
passer l’agent de l’état AP_ACTIVE à l’état AP_WAITING.
La méthode doSuspend() fait passer l’agent de l’état AP_ACTIVE ou AP_WAITING à
l’état AP_SUSPENDED.
Notons qu’il n’est permis à un agent d’exécuter ses comportements ou tâches
(Behaviours) que lorsqu’il est dans l’état AP_ACTIVE.
3 - Les Comportements d’agents (Behaviours)
Un Behaviour (comportement) représente une tâche qu’un agent doit effectuer.

Chaque Behaviour possède deux méthodes : la méthode action() qui définit les opérations
à exécuter par l’agent, et la méthode done() qui renvoie un booléen spécifiant si le
Behaviour a terminé et doit être supprimé de la file des Behaviours à exécuter par l’agent.
Nous distinguons principalement trois types de Behaviours :
1. Behaviours mono-coup « OneShot behaviours » qui se terminent immédiatement et

dont la méthode action() est exécutée seulement une fois. La méthode done()
retourne «Vrai».
2. Behaviours cycliques « Cyclic behaviours » qui ne sont jamais terminés et dont la
méthode action() exécute les mêmes opérations chaque fois qu’elle est appelée. La
méthode done() retourne «Faux».
3. Behaviours génériques « Generic behaviours » qui exécutent différentes opérations
dépendamment d’un état ; Ils se terminent quand une certaine condition est
vérifiée.
90
La figure ci-dessous illustre le scénario d’exécution du thread d’un agent.
Figure 8. Exécution d’un thread d’agent.
4 - Communication entre agents
Un des dispositifs les plus importants que les agents JADE fournissent est la capacité
de communiquer. Le paradigme de communication adopté est le mode asynchrone.
Chaque agent a une sorte de boîte aux lettres (la file d'attente de messages de l’agent).
91
A chaque fois qu’un message arrive, il est ajouté à la queue de la file et l’agent commence
par traiter le premier message arrivé.
Figure 9. Le paradigme JADE de traitement asynchrone de message.
Les messages échangés par les agents JADE obéissent au format spécifié par le
langage ACL lequel a été défini par la norme FIPA pour l'interopérabilité des agents.
4. 1 - Envoi de messages
L'envoi d’un message consiste à créer un objet ACL-Message et appeler la méthode

send() de classe « Agent ».
Exemple : Le code suivant correspond à l’envoi d’un message à l’agent « Bibito »

dans le but de l’informer qu’ « il fait beau aujourd’hui».
ACLMessage msg = new ACLMessage (ACLMessage.INFORM);
msg.addReceiver (new AID ("Bibito", AID.ISLOCALNAME));
msg.setLanguage ("Français");
msg.setOntology ("Prévision-météo");
92
4.2 - Réception de messages
La lecture des messages de la file d'attente de message est accomplie par la méthode
receive() de la classe d'agent. Cette méthode renvoie le premier message dans la file
d'attente (en le retirant de la file) ou NULL si la file d'attente est vide.
L’exemple suivant défini la méthode action() d’un Behaviour ; dans cette méthode on
impose à l’agent de bloquer ce Behaviour par la méthode block() si aucun message n’est
reçu pour ne pas occuper le CPU, sinon on traite le message.
Public void action() {
ACLMessage msg = myAgent.receive();
if (msg != null) {
// Message reçu : Traitement du message;
else {
93

Rapport Supervision PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rapport Supervision PDF

Uploaded by

Copyright:

Available Formats

Conception et Réalisation d’un Système de

Supervision Informatique à base

Mémoire de fin d’études

Réalise par Encadré par

Conception et Réalisation d’un Système de Supervision

MEMOIRE PRÉSENTÉ EN VUE DE L'OBTENTION

© BOUSSALEM Assam, ZERARA Younes, 2008.

AU NOM DE DIEU TOUT PUISSANT, CLEMENT ET MISERICORDIEUX

Notre reconnaissance va particulièrement à Melle. CHEURFI Halima, Melle. BOULEFAAT

Pour leurs soutien et encouragements.

A mes proches et toute ma famille.

A mes amis et tous les gens qui m’aiment.

Au bonheur des plus chers.

Je dédie ce modeste travail.

À mes très chers parents, pour leurs amour et sacrifices,

À mes adorables sœurs ; Imene, Asma et Aya pour leur patience,

À toutes les personnes qui connaissent Assam de prés ou de loin, et surtout,

À Okba, Noureddine, Nabil, Khaled, Imane, Adel et Souad,

Seulement pour leur existence.

Le présent travail consiste à l’étude d’une architecture basé sur

Mots clés : Agent, système multi-agents, agent mobile, système de

Liste des figures ...................................................................................................................... XI

PARTIE 1: Etat de l'art

Chapitre 2 : Les Systèmes de Monitoring Existants ..............................................................12

Chapitre 3 : Le concept Agent ................................................................................................ 23

PARIE 2: Conception et Implémentation

Bibliographie et Web-graphie ..........................................................................................….77

Annexe : La plate-forme JADE................................................................................................ 81

Liste des figures

Figure 1: Fonctionnalités de la supervision................................................................................. 6

L’apparition de ces nouveaux environnements informatisés rend la surveillance des

Vu que le système informatique est au cœur des activités d’entreprise, sa maitrise

Afin de minimiser le nombre de ces pertes, une sorte de surveillance et de contrôle

- garantir la disponibilité de leurs système et réseau ;

De plus, il y a souvent peu d’informations disponibles pour aider les administrateurs à

On est ainsi naturellement conduit à chercher à donner plus d’autonomie et d’initiative

1. Etudier les systèmes de supervision et leurs principes.

Pour cela, nous avons organisé le manuscrit de la façon suivante :

II. La deuxième partie est constituée de deux chapitres :

Chapitre 1 : La Supervision Informatique

2 Définition de la supervision informatique

3 Fonctionnalités et niveaux d’information

Figure 1: Fonctionnalités de la supervision.

Supervision réseau2 : elle porte sur la surveillance de manière continue de la

3.1 Informations sur les systèmes

3.2 Informations sur les réseaux

3.3 Informations sur les applications et services

- Automatiser les tâches de récupération des applications et des services en assurant

1. La Fiabilité : Il s’agit de l’utilisation la plus courante du monitoring informatique.

2. La Performance : Le monitoring de performance a pour but de retourner des

Toutes ces approches sont complémentaires et peuvent bien entendu se retrouver

6.1 Définition du protocole SNMP

6.2 Principe de fonctionnement du protocole SNMP

Figure 2: Eléments de base du protocole SNMP.

6.3 SNMP en pratique

Une requête SNMP est un datagramme UDP3 habituellement à destination du port

Chapitre 2 : Les Systèmes de Monitoring

2.1 Les offres éditeurs

Les agents OVOW

2.1.2 IBM Tivoli Monitoring

2.2 Les offres du monde libre

Figure 3 : Fonctionalités de Nagios.

Figure 4 : Architecture de NAGIOS.