2008 / 2009

Rapport de stage

Système dynamique
de représentation d’un
parc informatique

BERNARDIN BENOIT
Maitre de stage : GAVARRET Benoit – Tuteur : GREFFIER Françoise

Licence professionnelle CDOAM

Conception et Développement Orientés Objets d’Applications Multi-tiers

Université de Franche-Comté - LIFC

BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

REMERCIEMENTS

Je tiens particulièrement à remercier :

- M. Georges ALBERT, Président de la société SCAM-TP, pour m’avoir accueilli en tant que stagiaire au
sein de sa société.

- M. Benoit GAVARRET, Responsable du Service Informatique et Responsable du stage, pour son aide,
ses conseils, et pour m’avoir au mieux intégré dans le service informatique.

- M. Marc AVRIL, administrateur du réseau et développeur, pour sa disponibilité, son soutien et son
aide tout au long de la réalisation de mon projet ainsi que pour l’apprentissage du travail d’analyste-
programmeur.

2
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

INTRODUCTION

L'outil informatique est devenu un des éléments primordial du système d'information dans
les entreprises. Toute défaillance, panne ou coupure peut avoir des répercussions importantes sur le
fonctionnement de la société, et engendrer des conséquences, financières ou autres, irréversibles.
Pour palier à ce type de défaillances, il est nécessaire qu’un ou plusieurs outils soient mis en place au
sein de l’entreprise afin d’avertir les responsables, au plus tôt, des problèmes rencontrés sur le
réseau ; parfois même de les anticiper. La supervision de systèmes et de réseaux est devenue
indispensable. Elle permet aux administrateurs d'avoir une vue en temps réel et de gérer ce système
d’anticipation des alertes.

La société SCAM-TP est une entreprise de travaux publics implantée sur plusieurs sites dans
la région Sud/Sud-ouest de la France. Chacune de ses agences compte des ressources matérielles
informatiques. Il est donc important pour les administrateurs du service concerné d’avoir un suivi des
alertes produites sur le parc ou, le cas échéant, d’avoir une vue globale du réseau afin de cibler les
éventuels problèmes.
Ce rapport représente une synthèse du projet de mise en place d’un système dynamique de
représentation du parc informatique et des alertes de connectivité de cette société.

Une première partie présente les conditions dans lesquelles s’est déroulée la réalisation du
projet : présentation de la société dans sa globalité ainsi que du service informatique de l’entreprise.

Dans un deuxième temps, sera présentée, l‘étude préalable au projet. En effet, les objectifs
seront déterminés et une analyse sera réalisée sur les applications existantes. Ensuite, plusieurs
inconvénients seront retirés des étapes précédentes, pour enfin exposer les exigences de l’entreprise
face à la future application.

Une troisième partie présentera les différentes possibilités de développement par rapport
aux objectifs visés et aux exigences données. De cette partie, un choix de développement, qui sera
validé en accord avec l’entreprise, sera justifié.

Par la suite, le développement même de la future application sera présenté, de l’étape de

conception à l’étape de réalisation en passant par quelques phases de tests.

Ensuite, la phase d’implémentation sera brièvement décrite avec les phases de

fonctionnement en double ainsi que de la formation aux utilisateurs.

Enfin, pour conclure, la réalisation face aux objectifs visés sera étudiée et une description
sera faite concernant les éventuelles possibilités d’évolutions de l’application réalisée.

3
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Sommaire
REMERCIEMENTS ................................................................
................................................................................................
...................................................................
................................... 2

INTRODUCTION ................................................................
................................................................................................
.......................................................................
....................................... 3

I. PRESENTATION ................................................................
................................................................................................
....................................................................
.................................... 5
1 – La société ................................................................
................................................................................................
.................................................................................
.................................................5
.................5

2 – Le service informatique................................................................
...........................................................................................
...........................................................7
...........................7

II. ANALYSE PROJET ................................................................

ANALYSE PREALABLE AU PROJET .......................................................................
....................................... 8
1 – Objectif du projet ................................................................
................................................................................................
.....................................................................
.....................................8
.....8

2 – Les applications de supervision existantes ...........................................................

...........................................................9
...........................9

3 – Limites des outils actuels................................................................

......................................................................................
......................................................11

4 – Besoins exprimés pour la future application .......................................................

.......................................................11

DIFFERENTES POSSIBILITES..........................................................
III. ETUDE DES DIFFERENTES .......................................................... 12

REALISATION ................................................................
IV. CONCEPTION ET REALISATION .........................................................................
......................................... 13
1 – Conception / Dossier d’analyse ................................................................
...........................................................................
...........................................13

2 – Réalisation / Dossier de développement.............................................................

.............................................................19

Programme implanté sur chaque agence : Agent distant ...................... 19

Centralisation des images de chaque agence : Superviseur ................ 23
Affichage de la vue représentative du réseau construit : L’interface .... 24

D’IMPLEMENTATION ..............................................
V. DESCRIPTION DE LA PHASE D’IMPLEMENTATION .............................................. 29
1 – Fonctionnement en double ................................................................
...................................................................................
...................................................29

2 – Formation des utilisateurs ................................................................

....................................................................................
....................................................29

VI. CONCLUSION ................................................................

................................................................................................
...................................................................
................................... 29

GLOSSAIRE ................................................................
................................................................................................
...........................................................................
........................................... 31

GRAPHIE ................................................................
BIBLIOGRAPHIE / NETOGR
NETOGRAPHIE ...........................................................................
........................................... 33

4
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

I. PRESENTATION
1 – LA SOCIETE
SCAM Travaux Publics (SCAM-
(SCAM-TP)

Adresses
Siège Social Agences rattachées administrativement au siège*
TOULOUSE CLERMONT
CLERMONT-FERRAND MONTPELLIER BORDEAUX
14 Rue de Chambussière 18--20 Rue Roger Touton
16 RN 88 ZAC De Champ Lamet ZAE Cresse St-Martin Cedex 260
31380 GARIDECH 64430 Pont Du Château 34660 Cournonsec 33083 Bordeaux Cedex

Tél. : 05 34 26 50 00 Tél. : 04 73 84 54 17 Tél. : 04 67 85 01 12 Tél. : 05 56 56 55 05

Site Internet : www.scam-tp.fr

*Comptabilité, Qualité, Facturation,
acturation, Juridique et Matériel.

Structure Juridique

Société : SAS (Société par Action Simplifiée) SCAM Travaux Publics

Président : Monsieur ALBERT Georges
Capital : 400 000 €
Immatriculations :
- Numéro identification SIRET : 383 988 219 000028
- Code APE : 4221 Z

Secteurs d’Activités Effectifs

Assainissement
350
Affermage 305
300
Réhabilitation de
collecteurs 250
Travaux sans tranchée
200
VRD

AEP Irrigation 150

Génie civil 100

Station d'épuration 50
7%
8%
0
38%
24%

4%
8% 5% 6%

5
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

La SCAM est une société de travaux publics ayant une spécialité « canalisation »
(eau potable et assainissement). Elle gère l’ensemble des étapes d’un chantier de l’étude à
la réalisation, ainsi que la maintenance des installations.

De nombreux clients sollicitent la SCAM notamment dans le secteur public comme les
hôpitaux, les syndicats des eaux, les communautés de communes ou encore les mairies. De
plus, à cette liste s’ajoutent les entreprises privées puisque la société a participé à plusieurs
chantiers pour Total, Esso, ASF (Autoroutes du Sud de la France) et notamment au chantier
de l’AéroConstellation (Airbus A380) à Toulouse. Actuellement, le cancéropôle de Toulouse
est l’un des chantiers que réalise la SCAM.

Structure Informatique

L'entreprise possède un parc informatique d'environ 150 machines réparties sur sept
sites (dont trois sites sur chantier). L’administration du parc est gérée depuis le siège social
et la société sous-traite parfois la maintenance dans les six autres agences, lorsque des
problèmes importants surgissent.

Le schéma ci-dessous représente globalement l’architecture du réseau informatique.

Un schéma plus précis est disponible en annexe (Figure 1 : Schéma du réseau informatique
SCAM-TP).

INTERNET

Agence Toulouse Agence Montpellier Agence Clermont-Ferrand Agence Bordeaux

40 machines réseau 8 machines réseau 7 machines réseau 4 machines réseau
100 postes clients 35 postes clients 5 postes clients 2 postes clients

Fibre optique

Agence Verfeil Agence Sauvian Agence Marguerittes

6 machines réseau 3 machines réseau 7 machines réseau
2 postes clients 4 postes clients 2 postes clients

INTERNET

6
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

L’utilisation d’un VPN (Virtual Private Network) ou Réseau Privée Virtuel, a été mis en
place au sein de l’entreprise afin de connecter, de façon sécurisée, des ordinateurs distants,
au travers d’une liaison non fiable (Internet).

Inventaire matériel

- 150 machines (fixes et portables : 60/40) dont une dizaine fonctionnant sous Linux
- Périphériques divers (imprimantes, traceurs, copieurs… etc.)
- LTO 3 (Linear Tape Open) : technologie de stockage open-source sur bande
magnétique
- Switch N3 (fonctionnalités avancées, rapprochées de celles d’un routeur)

Inventaire logiciel

- Microsoft XP (Pack 2 et 3) installé sur tous les postes du parc

- Pack Office Standard 2007 installé sur l’ensemble des machines
- Une application de comptabilité et de gestion des paies
- Une application pour l’affermage (contrats dans lesquels l’exploitation de biens est
confiée à la société SCAM-TP)
- Plusieurs licences Autocad (logiciel de Dessin Assisté par Ordinateur)
- Autocad Light (version simplifiée d’Autocad qui permet quelques retouches)
- Covadis, qui est un logiciel de topographie
- Microstation (logiciel d'ingénierie collaborative, de Conception Assistée par Ordinateur)
- Logiciel de suivi des chantiers Pharos

2 – LE SERVICE INFORMATIQUE

Implanté au sein du siège social, ce service compte trois salariés dont le RSI
(Responsable des Systèmes d’Information) : M.GAVARRET Benoit.

GAVARRET Benoit* AVRIL Marc THOMAS Vincent

(Responsable Informatique)
Administration des Systèmes
Gestion Réponse aux besoins
Stratégie de développement
Gestion financière
*Maitre de stage
(Ingénieur) (Technicien Informatique)
Maintenance et Maintenance et
Administration des Systèmes Administration des
Réponse aux besoins Systèmes
Stratégie de développement Réponse aux besoins

Le projet s’est réalisé, dans sa totalité, au sein de ce service sous la responsabilité de

M.GAVARRET Benoit.

7
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

II. ANALYSE PREALABLE AU PROJET

Cette étude, décomposée en quatre sous-étapes, consiste à déterminer l’objectif

principal du projet puis analyser les applications existantes afin d’en retirer les différents
inconvénients. Par la suite sera exposé, le cahier des charges qui présente les exigences de
l’entreprise face à la future application.

1 – OBJECTIF DU PROJET

L'objectif du projet est de créer une application qui permet de :

REPRESENTER DYNAMIQUEMENT L’ETAT

L’ETAT
D’UN RESEAU INFORMATIQUE

C'est-à-dire un outil qui permet de visualiser entièrement les ressources critiques de

manière graphique et de mettre en évidence leur état. Ce projet va être réalisé en vue de
créer un outil complet de supervision du parc informatique. De multiples extensions seront
donc envisagées.

Pour la réalisation de cette application, certains logiciels et matériels ont été mis à
disposition.

Logiciels Matériels

CATEGORIE LIBELLE - Ecran 22 pouces avec une résolution

1440x900 utilisé pour le
XP Professionel SP3(Windows)
Windows Server 2003 et 2008 développement de l’application.
Système d'Exploitation
Suse 9.0.0 (Linux) - Ecran 32 pouces sur lequel la future
Framework de Eclipse Platform 3.4.2 application sera utilisée.
développement (Ganymede)
Scanner de ports réseau Nmap 4.76 - Une machine sera mise à
disposition : elle servira de plate-
Logiciel de prise de contrôle
VNCviewer forme de développement et de tests
de bureau à distance
sous Windows XP.
Editeurs de Texte Notepad++ (Windows)
Internet Explorer 7
Navigateur Web
Firefox 3.0.10
Logiciel de Diagrammes
Microsoft Visio
et Synoptiques
Logiciel de Retouche d'Images PhotoFiltre

8
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

2 – LES APPLICATIONS EXISTANTES

La société dispose de plusieurs applications pour gérer l’ensemble de son parc

informatique, comme par exemple GLPI (Gestionnaire Libre de Parc Informatique).
Néanmoins, deux outils, développés au sein même de l’entreprise, vont être en partie repris
pour la réalisation du projet.

Outil de supervision
supervision des alertes machines

Cet outil, développé par

l’entreprise, permet aux
administrateurs de gérer les
équipements du parc
informatique et de diagnostiquer
les problèmes de réseau.
En effet, cette gestion est
basée sur trois grands
principes :

Les équipements managés appelés aussi nœuds (ou nodes) qui sont tous les
éléments présents sur le parc (ex : serveurs, routeurs… etc.)

Les agents c'est-à-dire une application de gestion permettant d’envoyer les données
locales du périphérique sur lequel ils sont installés, au format SNMP
SNMP. Les données peuvent
être des informations sur le matériel, des éléments de configuration ou des informations
statistiques (ex : capacité du disque dur d’une machine saturée).

Une console de supervision qui va permettre de manager les équipements et qui va

afficher les différentes remontées d’alarme. Les informations retournées par les agents sont
stockées dans une base de données spéciale, appelée : MIB (Management Information
Base) ou base d'information pour la gestion du réseau.

SNMP permet le dialogue entre le superviseur et les agents afin de recueillir les
objets souhaités dans la MIB.
MIB L’application développée récupère ces informations présentes
dans la MIB pour ensuite les comparer avec des seuils, fixés par les administrateurs. Si une
donnée (exemple : capacité du disque dur) ne respecte pas le seuil correspondant (exemple :
80% de sa capacité totale) ; alors une alerte est générée et affichée. Ainsi de nombreuses
alertes sont affichées, de manière plus ou moins synthétique, via une interface Web. Cette
application permet de savoir, en parallèle, le nombre de machines connectés au réseau, et
ce, dans chaque agence.

9
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Outil de centralisation de logs machines

Cette application orientée Web a, elle aussi, été développé par l’entreprise. Elle
permet de remonter toutes les alertes du parc informatique. Elle s’appuie sur l’utilisation des
logs machines, d’un serveur Syslog pour la centralisation de ces derniers et d’une base de
données pour la sauvegarde.
Son principe de fonctionnement est assez simple : un agent, implanté sur chaque
machine, récupère les logs générés par le système de celle-ci, puis les envoie à un serveur
Syslog.
Syslog Ce dernier, jouant le rôle de superviseur, centralise tous les logs et les insère dans
une base de données. L’interface Web affiche toutes les informations présentes dans la
base. A noter que les logs sont triés selon leur importance. Seuls, ceux qui sont caractérisés
comme importants, sont affichés sur l’interface.

Sous Linux, il est possible de spécifier que l’on

désire envoyer les alertes de logs sur une autre
LINUX WINDOWS machine.
Sous Windows, cette possibilité n’existant pas et
Partie les journaux d’évènements ne correspondant pas au
CLIENT format Syslog Unix, un outil doit permettre l’envoi des
alertes systèmes à un système Unix afin de pouvoir
Snare centraliser les logs sur une machine distante. SNARE
est un logiciel capable de récupérer sous forme de
trame Syslog,
Syslog les évènements sous environnement
Windows.
SERVEUR SYSLOG
Afin de peupler la base MySQL avec les logs
Fichier FIFO arrivant sur le serveur, ceux-ci sont envoyés dans un
Démon fichier qui représente la source de journalisation de
SYSLOG Syslog-NG. Ici le fichier « FIFO » représente ce
Partie
SERVEUR tampon.
Syslog-NG inscrit toutes les informations
envoyées par Snare dans le fichier « FIFO ». Ensuite
BdD
le démon envoie des requêtes afin d’insérer ces
MySQL
données dans la base.

En résumé, la supervision du parc informatique de l’entreprise est gérée, pour

l’instant, par deux outils. Le premier a pour rôle principal d’afficher les alertes, dites
« personnalisées », générées sur le parc. Le second, quant à lui, se charge de sauvegarder
et d’afficher tous les logs importants.

Néanmoins, vu le flux incessant des alertes et des logs générés sur les deux
interfaces, il est difficile pour les administrateurs de rendre compte de l’état du réseau, et ce
à n’importe quel moment. Ces applications, bien que très utiles, présentent donc des limites.

10
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

3 – LIMITES DES OUTILS ACTUELS

Cette étape consiste à faire ressortir les difficultés d’utilisation que peuvent présenter
les logiciels, actuellement en fonction dans l’entreprise. De ce constat, des besoins pourront
être conclus afin de déterminer l’objectif de la future application.

Aucune représentation dynamique du réseau informatique : Les outils utilisés

actuellement ne permettent pas d’avoir une visualisation de l’ensemble du parc. Plusieurs
schémas représentatifs, réalisés notamment avec Microsoft Visio, permettent de se rendre
compte du réseau de la société. Néanmoins, à chaque évolution du parc, le schéma doit
être mis à jour.

Aucune visualisation rapide de l’état du réseau : Les administrateurs souhaiteraient

connaitre quelles sont les machines non connectées à n’importe quelle moment, et ce, de
manière efficace.

Maintenant que les outils existants ont été étudié et que leurs limites d’utilisation ont
été présenté, il est important de définir les besoins du service informatique quant à la future
application.

4 – BESOINS EXPRIMES POUR L’APPLICATION FUTURE

Le cahier des charges représente la synthèse des besoins exprimés par le RSI
(Responsable des Systèmes d’Information) et permet de définir les fonctionnalités
demandées à l’application ainsi que les ressources disponibles, les contraintes et le temps
prévu pour ce projet.

Spécifications fonctionnelles

L’outil doit permettre de :

- Représenter graphiquement et dynamiquement l’ensemble des ressources critiques

du parc informatique de la société

- ressources critiques)
Visualiser toutes les machines (ressources critiques recensées par agence (image
descriptive, nom)

- Générer l’état des machines selon leur résultat au « ping » (commande permettant de
vérifier la connexion d’une machine sur un réseau)

- Mettre en évidence l’état des machines (code de couleurs ou autres)

11
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Spécifications non fonctionnelles

La réalisation du projet s’effectuera avec certaines contraintes et ressources nécessaires.

En effet, l’ensemble du projet, depuis l’examen de l’objectif jusqu’à la validation définitive

de l’application, doit être effectué dans un délai de 13 semaines.

Le cycle représentatif d’analyse et de développement étant le suivant :

- 3 semaines d’analyse et de conception
- 10 semaines de développement dont :
o 1 à 2 semaines de tests
o 1 à 2 semaines de validation (des grandes phases)
Le cycle précis est disponible en annexe (Annexe 2 : Diagramme GANTT du projet)

La programmation devra être structurée et commentée afin de faciliter les évolutions

futures.

Maintenant que les besoins ont été déterminé et que l’objectif a été ciblé, il convient
d’étudier, avant toute conception, les différentes possibilités de développement.

III. ETUDE DES DIFFERENTES POSSIBILITES

Il existe actuellement sur le marché de nombreux logiciels permettant de subvenir aux

besoins précédemment énoncés, et ce avec plus ou moins de fonctionnalités. Une étude de
ces outils a été réalisé afin de choisir, en accord avec la société, la solution la mieux
adaptée.

Ainsi, le tableau suivant est un comparatif des diverses solutions proposées.

Critères / Logiciels MOM OpenView Nagios Cisco Works

Nagios
Fabricant Microsoft HP Dell
Enterprise
Coût 800 € 17 000 € Licence GPL* 13 000 €
Windows Windows
Environnement dédié Windows Windows
(possibilité sous Linux) et Linux
Possibilités Oui mais pas Oui mais pas
Non Oui
d'extensions personnellement personnellement
Simplicité
Facile Moyenne Facile Moyenne
d'installation
*Licence GPL (General Public License) ou Licence publique générale : Logiciel libre

12
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

L’entreprise, s’appuyant sur des critères de coût mais aussi de possibilité

d’évolutions, l’outil « Nagios » était le plus approprié pour répondre aux besoins et
exigences.

Néanmoins, la société souhaite continuer son programme de supervision en

développant une application en interne afin de personnaliser, au mieux, cette dernière avec
son réseau informatique. C’est par ce choix et les besoins exprimés que, le projet de
développement d’un système dynamique de représentation d’un parc informatique, se
justifie.

A noter que l’étude des différents logiciels, existants sur le marché, a permis de
donner un aperçu des fonctionnalités de ces outils. Certaines options pourront être reprises
dans la future application.

IV. CONCEPTION ET REALISATION

Le choix du développement étant pris, il est à présent important d’analyser la solution
à développer dans son ensemble c'est-à-dire d’examiner les choix organisationnels,
d’architecture logicielle et d’environnements à prendre et à établir.

1 – CONCEPTION / DOSSIER D’ANALYSE

Cette étape est une étude avant tout développement. Elle permet de définir le
contexte, plus technique, du projet. En effet, il est important de réfléchir sur le choix des
langages de programmation à utiliser et de conceptualiser la solution, avant même de
commencer à programmer.

L’application permettra la visualisation des ressources critiques de chaque agence, et

permettra donc d’avoir une représentation globale du réseau sur une interface graphique.
Cette dernière, dite « représentative », rendra l’image du réseau avec ses ressources
critiques et la mise en évidence de leur état. Cette vue permettra de voir rapidement quelle
machine n’est pas connectée au réseau.

Choix de
de l’architecture
l’architecture logicielle et de l’environnement
l’environnement de développement

Après réflexion sur les fonctionnalités de la future application et compte tenu des
nombreuses évolutions qu’elle offrira, la programmation s’est orientée vers le langage Java.
En effet, ce choix est justifié par plusieurs raisons :

- Langage orienté « objet » : Possède un mécanisme permettant de

décrire les caractéristiques d’un objet de manière unique, et de pouvoir
lui faire subir des opérations. Ainsi, il sera possible de conceptualiser
le réseau de l’entreprise en associant un objet à une machine (ou type
de machine) du parc informatique.

13
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

- Langage portable : Indépendant vis-à-vis de la plateforme (de l’hôte sur lequel il est
exécuté). Dans le cadre du projet, l’application doit répondre à un besoin de portabilité
c’est-à-dire que l’application pourra s’exécuter aussi bien sur une machine sous
environnement Windows, que sur un hôte sous environnement Linux.

- Langage réutilisable : Permet une meilleure réutilisation du code grâce à une bonne
structure des applications. Compte tenu des fortes possibilités d’évolution qui subsisteront
après le développement de ce projet, il est important de s’inscrire dans une démarche de
bonne programmation afin de faciliter la réutilisation aux futurs développeurs.

- Langage avec modèle client/serveur : Permet grâce à diverses APIs

API (interfaces) d’orienter
sa programmation sur un modèle client/serveur. Ainsi, la future application pourra se
baser sur cette fonctionnalité pour permettre la communication d’informations entre les
agences de l’entreprise.

A présent que le langage de programmation a été choisi, il convient de sélectionner

un environnement de développement. En effet, afin de faciliter la programmation aux
développeurs, il existe des programmes regroupant un ensemble d’outils pour le
développement d’applications.
Ainsi, le choix s’est porté sur la plateforme Eclipse
d’IBM. Bien qu’elle puisse mettre en œuvre quasiment tous
les langages de programmation, elle est davantage utilisée
pour créer des projets en Java. C’est un environnement
modulaire qui permet d’ajouter des plug-ins, suivant
l’orientation de la programmation.

Un aperçu de la plateforme Eclipse est disponible en annexe : « Annexe 3 : Aperçu

de la plateforme Eclipse ».

Maintenant que les choix de développement ont été effectué, l’architecture et le

principe de fonctionnement de la future application doivent être exposés.

Architecture et principe de fonctionnement

Il est important de conceptualiser le réseau informatique de

l’entreprise. Une analyse UML (Unified Modeling Language), ou
langage de modélisation unifiée, doit donc être réalisée. Cette étude
consiste à modéliser informatiquement un ensemble d’éléments (ici,
le réseau) en un ensemble d’identités informatiques. Le but étant de créer une représentation
des éléments sur lesquels le projet s’appuie, sans se préoccuper de l’implémentation c’est-à-
dire sans se soucier du langage de programmation utilisé. Néanmoins, ce dernier s’appuiera
sur cette analyse pour constituer la base de l’application : le réseau informatique.

14
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Le diagramme ci-dessous établit, en partie, le résultat de cette étape de conception.

En effet, l’application finale s’étendra sur de nombreuses phases de réalisation. Ce projet
s’inscrit donc comme la base du projet global de supervision. Ainsi, l’étude préalable au
développement doit prévoir, au maximum, toutes ces étapes.

Un « nœud » est une machine du parc

informatique : serveur, routeur,
machine cliente (des employés)…etc.

Un « hote » est un nœud

spécifique, tout comme
« interconnexion ». La première
est dédiée aux machines dites
« de terminaison » alors que la
seconde est définie pour les
nœuds où plusieurs autres
machines viennent se
connectées dessus.

Certaines classes ne sont pas remplies, puisque le

projet en est qu’à ses débuts. Ainsi, la
programmation, basée sur ce diagramme,
permettra toute évolution en ajoutant des
attributs (caractéristiques) et des méthodes
(opérations) aux différents objets (classes).

Avant tout développement, l’analyse UML ne suffit pas. En effet, celle-ci représente
informatiquement les différentes entités du réseau de la société mais elle ne permet, en
aucun cas, d’étudier le fonctionnement de la future application.

C’est pourquoi une étude a été réalisé afin de réfléchir aux différentes possibilités
proposées notamment sur la récupération des informations telles que l’adresse
adresse MAC,
MAC le nom
de la machine ou encore savoir si cette dernière est connectée au réseau ou non. En effet,
plusieurs idées de conception sont apparues : récupérer toutes les données depuis le siège
social, depuis les principales agences ou encore décomposer l’application en différents
programmes implantés sur chaque agence.

15
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Après étude, la dernière solution a été retenu : l’outil à développer sera orienté
client/serveur c’est-à-dire qu’il sera décomposé en plusieurs programmes implantés chacun,
à distance.

Agent distant
Agence de Toulouse
Agence de
Bordeaux
INTERFACE
SUPERVISEUR 1 Agence de
1 Clermont-Ferrand
2
1
Agence de
Montpellier
1
1
Site de Verfeil
1
1
Agence de Site de Sauvian
Toulouse
Site de Marguerittes

Principe de fonctionnement :

1 : Sur chaque agence, un agent est implanté jouant le rôle de serveur. Celui-ci récupère
« l’image » de l’agence et la met à disposition. Le superviseur quant à lui, joue le rôle du
client dans cette première étape : Il va chercher chaque image et les centralise dans un
tableau.

2 : L’interface va rechercher le tableau et n’a plus qu’à afficher toutes les informations
récupérées. Elle joue le rôle du client tandis que le superviseur joue le rôle du serveur en
mettant à disposition le tableau « d’images ».

Le superviseur a donc deux rôles : il est à la fois client puis serveur. Il est implanté au
sein du siège social, sur l’agence de Toulouse. Néanmoins, l’application permettra de
l’exporter à tout moment. Ainsi, ce dernier pourra être sur une machine distincte de celle de
l’interface, dans la même agence ou non.

Afin d’implémenter ce type de schéma, l’application reposera sur une

API Java appelée RMI (Remote Method Invocation). Celle-ci permet de
manipuler des objets distants (sur une autre machine du réseau) de manière
transparente c’est-à-dire comme s’ils étaient sur la même machine. La page
suivante détaille le fonctionnement de l’architecture RMI au travers d’un modèle
client/serveur. C’est sur ce principe que vont reposer les appels distants, vu précédemment,
entre les agences et le superviseur ainsi qu’entre ce dernier et l’interface.

16
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

ARCHITECTURE RMI : RMIREGISTRY

(Serveur de noms)

JVM CLIENT JVM SERVEUR

Stub
2
Naming
1
rebind()

Mise à 3 Serveur
Client
disposition

Stub

Skeleton

Etape n°0 : A la création de l’objet, un stub et un skeleton sont créés, coté serveur.
Etape n°1 : L’objet serveur s’enregistre auprès du Naming de sa JVM : méthode rebind().
Etape n°2 : Le Naming enregistre le stub de l’objet auprès du serveur de noms (rmiregistry).
Etape n°3 : Le serveur de noms est prêt à donner des références à l’objet distant.

RMIREGISTRY
(Serveur de noms)

JVM CLIENT JVM SERVEUR

Stub
5
Naming Naming
4
lookup()

Client 6 Serveur
installation

7 7

Stub Skeleton

Etape n°4 : L’objet client fait appel au Naming pour localiser l’objet serveur : « lookup() ».
Etape n°5 : Le Naming récupère le stub vers l’objet serveur.
Etape n°6 : Le Naming installe l’objet Stub et retourne sa référence au client.
Etape n°7 : Le client effectue l’appel à l’objet serveur par appel à l’objet Stub.

17
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

A la fin de cette procédure, une passerelle est créée entre le stub, coté client, et le
skeleton, coté serveur. Dès que le client effectue un appel à l’objet distant, il met en œuvre le
stub qui émet directement la requête au skeleton. Les connexions et les transferts de
données dans RMI sont effectués par Java avec le protocole RMI- RMI-IIOP (Internet Inter-Orb
Protocol), et bien souvent sur le port 1099 (modifiable).

La transmission se fait grâce à un système de couches, basé sur le modèle OSI

(Open Systems Interconnection) afin de garantir une interopérabilité entre les programmes et
les versions de Java. Le schéma ci-dessous est un descriptif de ce système :

CLIENT RESEAU SERVEUR MODELE OSI

Application

STUB SKELETON Présentation

RRL RRL Session

COUCHE TRANSPORT Transport

Réseau

Liaison données

Le stub et le skeleton assurent donc la conversion des Physique

communications avec l'objet distant entre le client et le serveur.

La couche de référence (RRL pour Remote Reference Layer) est chargée de la

localisation pour fournir un moyen aux différents objets (objet client, objet serveur,
Naming…etc.) d'obtenir une référence à l'objet distant. Cette couche est le serveur de nom
(appelée aussi « rmiregistry »).

La couche de transport, quant à elle, permet d'écouter les appels entrants ainsi que
d'établir les connexions et le transport des données sur le réseau par l'intermédiaire du
protocole TCP.

L’application globale de supervision reposera donc sur ce modèle client/serveur. A

présent, la conception de cette application étant terminée, le projet s’oriente donc sur le
développement de la base même du futur outil ainsi que des mises en œuvre l’entourant. A
savoir, la réalisation d’une interface graphique dynamique des ressources critiques de la
société SCAM-TP.

18
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

2 – REALISATION / DOSSIER DE DEVELOPPEMENT

Comme évoqué précédemment, l’application sera décomposée en trois programmes.

C’est pourquoi le développement de l’application s’est décomposé en plusieurs étapes
distinctes. En effet, dans un premier temps, le fonctionnement du programme, implanté sur
chaque agence (agent distant), sera exposé. Puis, dans une seconde étape le rôle du
superviseur sera abordé. Enfin, l’interface graphique avec sa représentation dynamique sera
présentée.

Une visualisation de l’interface de l’application est disponible en annexe 4 : « Aperçu

de l’application ». Cette vue a été réalisé en cours de développement.

Programme implanté sur chaque agence : Agent distant

Cet agent permettra de récupérer « l’image » du site sur lequel il est implanté. Une
fois, l’image construite, il pourra alors la mettre à disposition grâce au système basé sur RMI
(comme vu précédemment). Cet agent est donc la base
de ce projet.

L’illustration ci-contre présente la structure d’un agent :

- Le package « Configuration » contient tout ce qui va

servir indirectement à l’agent pour construire l’image
locale.

- Le package « LeLanceur » avec sa classe

« MainDeploiement » est ce qui va démarrer l’agent.
De plus, la gestion des mises à jour sera gérée ici.

- Le package « Modeles » quant à lui, contient le

modèle du réseau par rapport au diagramme UML
présenté en étude préalable. Il servira aussi à la
construction du réseau.

La procédure de fonctionnement de l’agent distant, allant de la construction de l’image du

réseau local jusqu’à la mise à disposition de celle-ci, est la suivante :

AGENT DISTANT : « MainDeploiement »

Mise à Boucle de mise à jour

Construction de l’image
Disposition
Package Modeles MISE A JOUR
«ChargementFichierCONF » « RMIDeploiement » « ReseauLocalImpl »
« ReseauLocal »
« ReseauLocalImpl »
ATTENTE

19
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Afin de mieux comprendre la démarche, il est important de détailler précisément

l’étape de construction de l’image du réseau. Cette image est un objet de type
« ReseauLocalImpl ». Cette classe implémente notamment l’interface « ReseauLocal » afin
de pouvoir utiliser RMI pour la mise à disposition. L’illustration ci-dessous décrit cette classe.
dateMAJ est un attribut
tabNoeuds est le tableau
ReseauLocalImpl pour enregistrer la date
de tous les nœuds
(date/heure) de la
(machines) du réseau. dateMAJ : String
dernière mise à jour.
tabNoeuds : Vector
tabLiens est un tableau
tabSwitchs : Vector tabSwitchs est un tableau
d’objets de type « Lien »
tabLiens : Vector d’objets de type
(package Modeles).
« Switch ». Ces objets ne
Chaque instance définit + ReseauLocalImpl() sont pas présents dans le
les points de départ et - initTabNoeuds() : Vector « tabNoeuds » car ils
d’arrivée d’une - majTabCorrespondance() : void subiront, tout comme leur
connexion sur le réseau. - creerLesLiens() : Vector tableau, des opérations
+ listecategories() : Vector spécifiques.
+ « Getters and setters »

« Getters and setters » n’est en aucun cas une méthode. C’est une information ajoutée à ce
schéma pour regrouper toutes les méthodes d’accès et de modification aux attributs ci-dessus.

La construction du réseau se fait donc par les trois tableaux principaux :

« tabNoeuds », « tabSwitchs » et « tabLiens ». Pour l’instant, l’application doit permettre la
visualisation des ressources critiques. C’est pourquoi la construction du tableau de nœuds se
fait par un fichier de configuration (voir ci-dessous) que les administrateurs rempliront au fur
et à mesure de l’agrandissement du réseau.

Ainsi, la construction du réseau suit la procédure

suivante : Ouverture du fichier de configuration

Fin Contrôle de la fin du fichier

Récupération de la ligne suivante…

OU
Récupération Ligne de
des infos commentaire

Création d’un nœud du type correspondant

à celui récupéré dans le fichier
Description ci-après (page suivante)

Ajout du nœud créé dans le tableau

Fermeture du fichier de configuration

20
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

A chaque ligne, non commentée, un nœud est donc crée par rapport aux informations
récupérées : le type du nœud (switch, routeur, serveur, copieur…etc.), l’adresse
adresse IP,
IP l’adresse
adresse
MAC la fonction du nœud (reseau ou autres pour les serveurs) et une description facultative.
MAC,

NOEUD Néanmoins, en suivant le schéma UML qui a été réalisé au

préalable, d’autres informations, à remplir, caractérisent un nœud.
adresseMAC : String
adresseIP : inetAddress
type : String Informations récupérées dans le fichier de
fonction : String configuration, au moment de la création.
descrpiton : String

nomHote : String « nomHote » et « ping » sont deux données

ping : Boolean récupérées via une source externe : NMAP.

icone : imageIcon « icone » est l’image qui permettra la représentation

graphique du nœud. Elle est créée à partir du type du nœud.

Les deux propriétés « nomHote » et « ping » sont récupérées à partir du résultat d’un
scan réseau, réalisé avec le logiciel NMAP. En effet, ce dernier est un scanner de ports
réseau permettant de récupérer une multitude d’informations sur une ou plusieurs machines
d’un réseau, suivant les commandes spécifiées à son exécution. Il permet aussi d’exporter
son résultat dans un fichier texte ou XML,
XML comme ci-après :
Etat de la machine
« up » : connectée
« down » : ne répond pas

Le nom de la machine peut être récupéré

grâce à la résolution DNS effectuée par Nmap.

Dans le cadre du projet, NMAP sera exécuté régulièrement en tâche de fond sur la
machine hébergeant l’agent distant. Au moment de la création d’un objet, l’agent parcourra le
fichier XML généré par Nmap pour rechercher la machine concernée grâce à l’adress
adresse
adresse IP et
adresse MAC.
l’adresse MAC Une fois trouvée, il ne reste plus qu’à lire son statut et son nom, pour les
spécifier dans ses caractéristiques.

21
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Nmap est donc à la base de la dynamique de l’application. En effet, après la mise à

disposition de l’image construite sur le réseau, l’agent effectue une mise à jour régulière de la
caractéristique « ping » de chaque machine présente dans le tableau de nœuds. Ainsi, les
administrateurs, grâce à l’interface, sauront qu’une machine n’a pas répondu à la dernière
mise à jour.

A la fin de la construction de l’image locale, un tableau des nœuds est donc obtenu,
correspondant aux machines renseignées dans le fichier de configuration. Néanmoins, celui-
ci possède aussi les switchs existants sur le parc informatique. Pour implémenter le tableau
de switchs, une extraction est donc suffisante.

Une fois le tableau de switchs créé, la table de correspondance de chaque switch est
initialisée et épurée. Il existe deux cas de figures. Soit l’agent actuel est implanté :
- sur une agence dite « manageable ». Dans ce cas, plusieurs switchs manageables
peuvent être présents. Il est donc possible de récupérer des informations via SNMP.
SNMP
- sur une agence non manageable c'est-à-dire qu’un seul switch non manageable est
présent dans l’agence. Le switch n’a donc pas d’adresse
adresse IP connue.

Le traitement est alors différent selon le switch auquel l’agent a à faire.

Parcours du tableau de switchs

Switch manageable Switch NON manageable

Table de correspondance Table de correspondance

Nœud connecté Port réel Nœud connecté Port fictif

INITIALISATION
tabNoeuds.get(0) 0
DE LA TABLE
tabNoeuds.get(1) 1
tabNoeuds.get(2) 2
…/… …/…

Récupération de la table de Une table fictive est

correspondance dans la MIB de générée pour dire
l’agent SNMP implanté sur le switch. que tous les nœuds
EPURATION DE
sont connectés sur
LA TABLE
ce switch.
Epuration de la table de
correspondance récupérée

Switch courant initialisé

La table récupérée possède des correspondances à éliminer.

Exemple : Sur le port 0, le switch se voit lui-même.

22
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Après tout ces différents traitements, l’image du réseau est donc construite. En résumé,
la création des nœuds se fait essentiellement par le fichier de configuration, rempli
manuellement par les administrateurs. De là, les deux principaux tableaux (de nœuds et du,
ou des, switchs) sont initialisés. La construction du réseau, c'est-à-dire les connexions entre
les diverses machines, est représentée par le tableau de liens. Celui-ci est construit grâce à
la table de correspondance du ou des switchs.
La mise à disposition de l’image est donc l’étape suivante avec la mise à jour régulière de
la caractéristique « ping » de chaque machine.

Un agent est implanté sur chaque agence, ce qui comptabilise 9 images qu’il faut
récupérer, pour ensuite transmettre le tout à l’interface. Ceci est le rôle du superviseur.

Centralisation des images de chaque agence : Superviseur

Le superviseur est un programme qui regroupe l’image de chaque agence dans un

tableau. C’est ce tableau qui, une fois initialisé entièrement, sera transmis à l’interface pour
l’affichage du réseau.

Son principe de fonctionnement est quasiment identique à l’agent distant :

SUPERVISEUR

Boucle de mise à jour

Construction du tableau
Mise à disposition
d’images avec la MISE A JOUR
du tableau
récupération de chaque Détails
image d’agence.

Détails ATTENTE

Pour chaque Suppression de

Insertion de la
agence… l’ancienne image
Récupération nouvelle image
correspondante à
OK récupérée
l’agence courante,
dans le tableau
Initialisation des
paramètres :
- IP Serveur Récupération Ancienne image gardée
- Port échouée

23
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Le tableau, une fois construit, est mis à disposition sur le réseau grâce au système
RMI. Le traitement rentre ensuite dans une boucle infinie. Une mise à jour est faite en
reconstruisant le tableau sur le même principe que le schéma ci-avant. Puis, un thread (ou
processus) d’attente est levé, pour ensuite reprendre la boucle… Et ainsi de suite.

Le superviseur est d’abord « client » en récupérant l’image de chaque agence pour

ensuite, jouer le rôle de « serveur » en mettant à disposition le tableau d’images d’agence.

A ce niveau, le réseau est construit en fond d’application. Il ne reste qu’à récupérer et

afficher les informations présentes dans le tableau du superviseur. C’est le rôle de l’interface
de mettre en forme les différentes remontées.

Affichage de la vue représentative du réseau construit : L’interface

L’interface est le programme qui affiche les informations présentes dans le tableau du
superviseur, et donc ce qu’ont récupéré les agents distants.
Pour l’application, elle utilise deux APIs
API Java : Swing et
Java2D.
Java2D La première permet de créer une interface de base
avec fenêtre(s), menu(s) et de nombreux autres
composants. La seconde, quant à elle, permet de dessiner
des formes, du simple trait au polygone de toute forme.

Le nombre d’informations remontées pouvant évoluer à n’importe quel moment,

l’interface doit pouvoir s’adapter à ce changement. Elle doit donc permettre l’évolution du
réseau, pour chaque agence. Néanmoins, bien que l’application doive répondre à une
certaine dynamique, il n’est pas envisageable de créer une interface entièrement réactive
selon le nombre d’équipements présents sur le parc de la société. Cela impliquerait :
- un redimensionnement de l’espace occupé par une agence sur la fenêtre
- un redimensionnement des images représentatives
- un système de gestion des traits représentant les connexions entre les équipements.

C’est pourquoi certaines limites ont été posé pour l’affichage. En effet, trois types
d’agences seront distingués :
- les petites agences avec moins de 10 équipements
- les agences dites « de taille moyenne » possédant jusqu’à 15/20 équipements
- et le siège social avec les principales ressources critiques.
Sachant que des agences peuvent très bien aussi être créées.

Le principe de fonctionnement global de l’interface s’appuie sur celui de l’agent

distant et du superviseur, outre la mise à disposition. En effet, l’interface récupère le tableau
d’images, puis son traitement rentre dans une boucle de mise à jour qui reconstruit
entièrement la fenêtre afin de tout redimensionner, si besoin.

24
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

La construction de l’interface graphique débute par la création d’une fenêtre avec les
dimensions maximales de l’écran. A cette fenêtre est ajouté, un système de couche de
superposition appelé « JLayeredPane » qui permet de positionner des composants dans un
espace à trois dimensions. La création de l’interface graphique va donc suivre ce système de
couche qui va permettre de mettre en arrière-plan toutes les grilles et de mettre en avant les
traits et les images représentatives.
Grille principale décomposant les agences
1 Sous-grille pour le siège
2 social : répartit l’espace
3
4 de l’agence pour
Grille secondaire pour
5 chaque switch
la décomposition d’une
agence (ou d’un espace
de switch) en petites
cellules

Couche pour les images représentatives. Au-

dessus des liens, sinon ceux-ci
traverseraient certaines images.
Couche de dessin : trace les traits représentant toutes
les connexions entre les différents équipements.

Les composants sont disposés par niveaux. Ceux d'un niveau donné sont affichés par
dessus ceux d'un niveau inférieur. A savoir qu’il faut différencier les composants et les
conteneurs. Les premiers, comme les boutons par exemple, sont intégrés dans les seconds
(exemple : JPanel, JFrame…etc.). Ainsi, chaque couche sera conteneur de composants.

Afin de mieux comprendre cette architecture d’interfaçage, il est important de

décomposer sa construction par couche.

COUCHE 1 : Grille principale

Cette grille est associée au conteneur, qu’est la couche 1, grâce à un gestionnaire

d’interfaces afin de disposer les composants. En effet, lorsqu’on intègre un composant
graphique dans un conteneur, il n'est pas nécessaire de préciser son emplacement car il est
déterminé de façon automatique : la mise en forme est dynamique. On peut influencer cette
mise en page en utilisant un gestionnaire de mise en page (Layout Manager) qui définit la
position de chaque composant inséré.

Il existe plusieurs gestionnaires d’interfaces en Java, avec pour chacun une utilisation
particulière. Dans le cas de la couche 1, c’est le gestionnaire TableLayout qui a été utilisé.
Celui-ci, non inclus d’origine dans la librairie java Swing,
Swing permet de disposer des composants
graphiques au sein d’un Container (conteneur) à la manière d’un tableur, tel qu’Excel.

25
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Son principe de fonctionnement est assez simple : on indique pour chaque

composant, les lignes et colonnes de début et de fin et le layout divise le Container en
cellules, par rapport au « schéma » qu’on lui a indiqué.

Ainsi, cette première couche a été divisé

3 5 7 9
de manière à afficher les 7 agences de la 2
société avec une possibilité d’en rajouter 3 4 6 8 10
nouvelles. De plus, une cellule restante servira
de résumé d’affichage en mettant en évidence
par exemple, le nombre de machines qui 1
répondent sur le nombre de machines total par
agences.
D’autres cellules ont été créé en parallèle afin de mettre en évidence « Internet » et le
VPN de l’entreprise.

COUCHE 2 : Sous-
Sous-grille (principale)

Cette couche sert essentiellement pour la disposition du siège social. Effectivement,

la cellule 1 (voir illustration ci-avant) sera partagée dynamiquement entre les switchs, suivant
le nombre d’équipements connectés sur chacun. Ainsi, un switch avec trois machines
connectées dessus aura peu de place en comparaison d’un switch qui aura une quinzaine de
connexions. Machine du parc

Switch Switch Switch

Ces grilles ne seront pas visibles pour l’utilisateur. Ce sont juste des grilles mises en
place afin de gérer, en fond, l’affichage de tous les composants.

COUCHE 3 : Grille secondaire

Chaque agence est donc représentée dans une

cellule, plus ou moins grande. Afin de faciliter
l’affichage des images, une grille secondaire est mise
en place pour décomposer la grille principale en petites 50/60
cellules. Deux cas de figure sont alors possibles.
pixels

26
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

- Siège social : Ici, ce n’est pas la cellule de la grille principale mais les sous-grilles
(des switchs) qui sont décomposées en cellule de taille 60x60 pixels.
- Autres agences : La cellule de la grille principale correspondant à l’agence est
décomposée en cellules de taille 50x50 pixels.

C’est dans ces cellules que seront ajoutées par la suite (couche 5), les images
représentatives.

A ce stade, nous avons donc plusieurs couches superposées, mais toujours

transparentes pour l’utilisateur.

COUCHE 4 (Couche de dessin)

dessin) et COUCHE 5 (Couche des images)

Une fois les différentes grilles placées, l’étape suivante consiste à dessiner les traits
puis à ajouter les images à la grille secondaire (voir ci-avant). C’est durant ces deux étapes
que l’affichage du réseau va progressivement prendre forme.

Chaque nœud (switch courant compris) va instancier un objet de type

« NoeudGraphique ». Cette classe hérite de « panel » : conteneur de composants. Chaque
nœud sera donc représenté par un panel formé comme ceci :

NoeudGraphique : panel

Image représentative du type de la machine

Image du (serveur, switch, routeur, firewall…etc.)
nœud

Nom de l’hote Nom de la machine. Si le nom n’a pas été

récupéré lors de la création, l’adresse IP ou MAC
est prise.
Cellule de 50x50 ou 60x60 pixels

ZoneDessin
A cela s’ajoutent, les zones de dessin c'est-à-dire les
traits dessinés d’un point à un autre et représentant une - pointRef : Point
connexion. Pour cela, le switch sera le point de référence d’une - listePoints : Vector
de ces zones. A ce point, une liste d’autres points (les autres
machines connectées sur ce switch) sera associée. Par la + zoneDessin()
suite, pour dessiner du point de référence aux autres points, il - initialize()
suffira de parcourir la liste et de tracer un trait à chaque fois - paintComponent()
entre le point de référence et le point indexé dans la liste. + getListePoints()
+ setListePoints(vector v)

27
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Ces deux phases sont réalisées en commun dans le même traitement. En effet, pour
afficher les traits puis les images représentatives, le traitement d’affichage se base sur la
table de correspondance des switchs. Le déroulement de la procédure est la suivante :

Le switch sera disposé au Initialisation d’un objet « zoneDessin » avec comme point
milieu du panel de l’agence. de référence, le centre du panel du switch courant

Suivant le type du nœud, ce Parcours de la table de correspondance du switch

dernier sera placé
différemment dans la grille
secondaire afin de respecter Nœud « réseau » Nœud « de base »
une certaine cohérence dans (Routeur, firewall et (Serveur et copieur)
l’affichage. borne wifi)

Création d’un objet « NœudGraphique »

Gestion d’affichage
permettant de placer le Gestion d’affichage appliquée au type de nœud
nœud dans la grille
secondaire, suivant son type.

Un traitement particulier est Autres Firewall Routeur

effectué si le nœud actuel
est un firewall ou un routeur. Ajout du point du centre du panel dans la liste de points
En effet, en plus de relier cet associée au point de référence
objet au switch, une
connexion doit être Changement du point de
représentée en traçant un référence (switch)
trait de cet objet au point le Firewall : pointRef=internet
Routeur : pointRef=VPN
concernant (indiquée dans le
schéma ci-contre)
Traçage du trait supplémentaire

Affichage de l’objet « zoneDessin »

Chaque agence dite « de petite taille » est associée à un et un seul switch. La

procédure d’affichage s’appuie donc essentiellement sur le switch et sa table de
correspondance. A la fin, l’agence est affichée avec au centre le switch et tous les
équipements connectés dessus. Quant au routeur, il est connecté au VPN de l’entreprise
(disposé au centre de la fenêtre) et le firewall est connecté aux bordures Internet. Plusieurs
traitements sont réalisés en parallèle pour des points spécifiques.

28
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

V. DESCRIPTION DE LA PHASE D’IMPLEMENTATION

La phase d’implémentation est la dernière étape avant la finalisation du projet.

1 – FONCTIONNEMENT EN DOUBLE

L’application réalisée n’est qu’un outil supplémentaire dans la démarche de

supervision du parc informatique. Les outils existants sont toujours utilisés en parallèle. Un
fonctionnement en double n’a donc pas été requis. L’organisation n’a suscité aucun
aménagement.

2 – FORMATION DES UTILISATEURS

Cette étape très importante en général, n’a pas été nécessaire dans la mise en œuvre
globale de l’application réalisée puisque l’outil s’adresse aux administrateurs du parc
informatique de la société. C’est d’ailleurs eux qui seront à l’origine des nombreuses
évolutions futures de l’application.

VI.
VI. CONCLUSION

Difficultés rencontrées

Outre les difficultés basiques que l’on surmonte grâce à des recherches sur Internet
ou autres, certaines étapes ont été très complexes, parfois même embarrassantes, prenant
quelques semaines avant de les résoudre. Ainsi peuvent être cités, l’algorithme de
construction du réseau par les switchs ou l’affichage dynamique des machines et des liens
entre elles.

A l’issue de ces trois mois d’analyse et de développement, un sentiment

d’insatisfaction se dégage. En effet, vu le travail effectué comparé à l’ampleur du projet,
beaucoup de choses peuvent être encore réalisées. Néanmoins, le travail effectué s’appuie
sur une analyse longuement menée et bien étudiée afin de permettre toute évolution possible
de l’application. De plus, et dans la même logique, le développement qui a suivi a été
rigoureux et respecte les exigences d’une bonne programmation afin de faciliter la
compréhension et la reprise aux développeurs. Ce projet est donc une base solide pour les
évolutions à venir.

Limites et évolutions possibles de l’application produite

Cet outil de représentation dynamique est une évolution à l’ensemble des fonctions
d’administrations en service. Néanmoins, elle présente quelques limites et certaines
évolutions pourraient être réalisées.

29
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

- Historique de l’état du réseau : Il serait logique de pouvoir visualiser l’image

instantanée, à un moment donné, du réseau. Ainsi, les administrateurs auraient la
possibilité de revoir l’état du réseau de la semaine précédente, par exemple.

- Amélioration de la construction dynamique : La représentation du réseau se fait grâce

aux diverses données récupérées dans la MIB des switchs. La construction du parc
est donc réalisée par ceux-ci. Dans le cas d’une défaillance d’un tel équipement,
l’agence concernée par ce dernier, serait impossible à construire. Il serait donc
normal de sécuriser cette construction en comparant diverses informations entre
elles.

- Extension sur la gestion des équipements : Pour l’instant, seul les switchs Hewlett
Packard sont manageables. Si l’entreprise acquiert un nouvel équipement de ce type,
mais d’une marque différente, l’application ne s’adapte pas puisque les MIBs
MIB sont
différentes selon le constructeur. Un manager pourrait donc être réalisé afin de
construire une MIB générale, qui regrouperait les données communes à toutes les
MIBs.
MIB

- Extension applicative : L’application, dans son état actuel, permet de visualiser l’état
des ressources critiques de chaque agence. Cette extension s’appliquerait sur toute
la partie dite « cliente » du parc informatique. Ainsi, le système de représentation
prendrait en compte non seulement toute la partie dite « réseau » avec notamment
les ressources critiques du parc, mais aussi la partie cliente avec les postes de tous
les employés.

- Apprentissage applicatif des alertes générées : Dans cette optique, une gestion des
alertes serait implantée, en parallèle à l’outil de supervision des alertes machines.
Ainsi, dès qu’une alerte de haute importance sera générée sur l’outil de supervision,
l’application se « souviendrait » si elle doit en tenir compte ou non, suivant certains
critères définis par les administrateurs et pourrait l’afficher.

- Ajout d’une vue fonctionnelle : Cette fonctionnalité permettrait une représentation du

réseau en arborescence. Lors du clic de la souris sur une machine (dans
l’arborescence) les caractéristiques matérielles et logicielles de la machine
sélectionnée apparaitraient. Le développement de cette vue a été commencé :
l’arborescence est réalisée et en reprenant le système de récupération des
informations présentes dans les MIBs
MIB des agents SNMP,
SNMP il ne reste qu’à gérer les
évènements.

30
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

GLOSSAIRE
Toutes les expressions expliquées ici, sont mises en évidence dans le rapport (en bleu).

VPN (Virtual Private Network) ou Réseau Privée Virtuel : Extension ou interconnexion des
réseaux locaux d’une entreprise. Un VPN permet de connecter, de façon sécurisée, des
ordinateurs distants, au travers d’une liaison non fiable (Internet).

RESSOURCES CRITIQUES
CRITIQUES : Toutes les machines dites « à haute disponibilité » c’est-à-dire
les serveurs, les switchs, les routeurs, les bornes WIFI et les firewalls.

SNMP (Simple Network Management Protocol, ou protocole simple de gestion de réseau) :

Protocole de communication qui permet aux administrateurs réseau de gérer tous les
équipements présents sur le parc mais aussi de superviser et de diagnostiquer des
problèmes réseaux, matériels à distance.

MIB (Management Information Base) ou base d'information pour la gestion du réseau :

Ensemble d'informations structuré sur une entité réseau comme un serveur, un routeur ou
encore un switch manageable. La structure de la MIB est hiérarchique : les informations sont
regroupées en arbre. Chaque information a un « object identifier », une suite de chiffres
séparés par des points, qui l'identifie de façon unique.

SYSLOG : Protocole définissant un service de journaux d'événements d'un système

informatique. C'est aussi le nom du format qui permet ces échanges. On parle de serveur
Syslog lorsqu’une machine centralise tous les logs (évènements) émis par des clients
Syslog.

COMMANDE « PING » : Permet de tester la connectivité à un ordinateur. Quand on fait

une commande PING, la machine, sur laquelle la commande est exécutée, envoie un paquet
de données à un PC. Dans un second temps, elle attend un retour de ces paquets.

ADRESSE MAC : Identifiant physique stocké dans une carte réseau ou une interface
réseau similaire et utilisé pour attribuer mondialement une adresse unique au niveau de la
couche de liaison (couche 2 du modèle OSI).
OSI

PROTOCOLE RMI-
RMI-IIOP : Protocole particulier utilisé principalement pour RMI. A la base,
créé pour faciliter le développement d’applications CORBA (langage de programmation), il a
été repris avec RMI sous Java.

MODELE OSI (Open Systems Interconnection), ou Interconnexion de systèmes ouverts :

Modèle de communications entre ordinateurs proposé par l'ISO (Organisation internationale
de normalisation). Il décrit les fonctionnalités nécessaires à la communication et
l'organisation de ces fonctions.

ADRESSE IP (Internet Protocol), ou Protocole Internet : Numéro qui identifie chaque

ordinateur connecté à Internet, ou plus généralement et précisément, l'interface avec le
réseau de tout matériel informatique (routeur, imprimante…etc.) connecté à un réseau
informatique utilisant le protocole Internet.

31
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

XML (Extensible Markup Language), ou Langage extensible de balisage : Langage

informatique de balisage générique. Il sert essentiellement à stocker/transférer des données
de type texte Unicode structurées en champs arborescents.

SWING : Bibliothèque graphique pour le langage Java. Celle-ci offre la possibilité de créer
des interfaces graphiques identiques quelque soit le système d'exploitation sous-jacent, au
prix de performances moindres qu'en utilisant son prédécesseur AWT (Abstract Window
Toolkit). Elle utilise le principe Modèle-Vue-Contrôleur (MVC) et dispose de plusieurs choix
d'apparence (de vue) pour chacun des composants standards.

JAVA2D : Bibliothèque graphique de bas niveau pour Java. Cette bibliothèque est le fruit
d’une collaboration entre Sun Microsystems et Adobe Systems pour pallier les manques et
déficiences de l'AWT. Java2D permet de tracer toutes sortes de figures géométriques en 2
dimensions. En effet, chaque opération Java2D peut se résumer en un remplissage d'une
forme avec une peinture suivi de sa composition sur l’écran.

32
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

BIBLIOGRAPHIE / NETOGRAPHIE
Moteurs de recherche et références de langages
- http://www.google.fr/
- http://fr.wikipedia.org/wiki/Accueil
- http://translate.google.com/

Références à Java
- http://java.sun.com/j2se/1.4.2/docs/api/

Tutoriels en ligne
Général
- http://www.jmdoudoux.fr/java/dejae/ : « Développons en Java avec Eclipse »
- http://www.jmdoudoux.fr/java/dej/ : « Développons en Java »
- http://java.developpez.com/cours/
- http://www.javafr.com/tutoriaux/
- http://www.siteduzero.com/tutoriel-3-10601-programmation-en-java.html

RMI (Remote Method Invocation)

- http://raphaello.univ-fcomte.fr/javareseau/rmi/rmi.htm
- http://drisshazzaf.typepad.com/oracle/files/Java_RMI.pdf
- http://pagesperso-systeme.lip6.fr/Gael.Thomas/srcs/2008/cours/srcs-4-rmi.pdf
- http://sardes.inrialpes.fr/~boyer/cours/RMI/NOTES/MesNotesForumRMI.htm

SNMP (Simple Network Management Protocol)

- http://www.scribd.com/doc/2511356/Ladministration-de-linternet-SNMP
- http://www.loriotpro.com/Products/On-line_Documentation_V5/LoriotProDoc_FR/C3-
Introduction_to_Network_Supervision/C3-B2_SNMP_Concepts_FR.htm

AWT/SWING et JAVA2D
- http://raphaello.univ-fcomte.fr/IG/Java2D/Java2D.htm
- http://prevert.upmf-grenoble.fr/Prog/Java/swing/tableDesMatieres.html
- http://www.d.umn.edu/~gshute/java/swing/graphics.html

Forums

- http://www.developpez.net/forums/f6/java/
- http://forum.hardware.fr/hfr/Programmation/Java/
- http://www.infos-du-net.com/forum/

33
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Annexe 1 : Schéma du réseau informatique SCAM-TP

34
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Annexe 2 : Diagramme GANTT du projet

35
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Annexe 3 : Aperçu de la plateforme Eclipse (aperçu 1)

36
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Annexe 3 : Aperçu de la plateforme Eclipse (aperçu 2)

37
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

Annexe 4 : Aperçu de l’application (en construction)

38
BERNARDIN Benoît
Système dynamique de représentation d’un parc informatique

RESUME
Les premières expériences professionnelles sont des étapes majeures dans
une carrière puisqu'elles permettent de confronter ses idées à la réalité de la
profession. Cette expérience s'est concrétisée, pour ma part, par un stage de douze
semaines dans un service informatique d’une société de travaux publics. Ce stage à
été l'occasion d'une immersion totale dans les conditions réelles du monde du travail.
Ainsi, durant quelques mois, j’ai pu développer un projet à grandes ambitions qui
changent complètement des projets scolaires effectués auparavant. J’ai donc pu
prendre connaissance des exigences appliquées au métier d’analyste programmeur.

Mots-clés : Java, J2SE, Eclipse Platform, API, JDOM, SNMP4J, SWING, JAVA2D

ABSTRACT
First experiences are major steps in a career you can face up to job reality.
This experience has resulted, for my part, for a period of twelve weeks in a
computing service of a company of civil engineering. This internship was the
opportunity for a full immersion in a medium business company. Thus, for a few
months, I was able to develop a major project totally different from those I did as a
student. So I have become aware of the requirements applied to the analyst
programmer job.

Keywords : Java, J2SE, Eclipse Platform, API, JDOM, SNMP4J, SWING, JAVA2D

39