PROJET DE FIN DETUDES

En vue de lobtention du diplme

National dingnieur

MISE EN PLACE DUN OUTIL DE

GESTION DE PARC INFORMATIQUE
ET DE HELPDESK

Ralis par:
M. Eric Maxime OBONO OBONO

Ralis par ric OBONO

Encadrant acadmique:
M. Arafet BOUSSAID

Signatures

Signature de lencadrant pdagogique

Signature du dpartement des langues

Ralis par ric OBONO

ii

AVANT-PROPOS

Lobtention du diplme national dingnieur au sein de lEcole Suprieure Prive

dIngnierie et de Technologie ESPRIT en Tunisie est couronne par la ralisation dun projet de
fin dtudes aux termes duquel ltudiant est appel faire une prsentation du travail effectu
tout au long dudit projet.
Cest dans ce cadre que jai effectu un stage de fin dtudes au sein de lunit de
Recherche Dveloppement Innovation dEspritec. Le dveloppement de cette division est
guid par la maitrise des technologies avances offrant des services ayant des retombes
industrielles et socio-conomiques.
Le projet qui ma t attribu a pour titre la mise en place dun outil de gestion de parc
informatique et de helpdesk et vise la gestion des ressources dun parc informatique dune
entreprise.

Ralis par ric OBONO

iii

DEDICACES

A mon Papa Bonaventure OBONO et mes chres et tendres maman Nicole et maman
Solange pour tous leurs sacrifices toujours consentis pour le bien-tre de leurs chers enfants.
A mes grands frres ELOUNDOU Stphane et ETABA Yves pour leurs efforts sans limites
et la confiance quils maccordent.
A mes frres et surs pour tout le soutient quils nont jamais cess de mapporter.
A toute la grande famille OBONO.
A toute ma famille de Tunisie, mes cher (e)s camarades, amis et amies qui ont chang le
visage de mon sjour sur le territoire Tunisien.

Ralis par ric OBONO

iv

REMERCIEMENTS

Je rends grce lETERNEL tout Puissant pour la Merveille que je suis ; Merci PAPA pour
ton immense Amour et pour la connaissance que tu mas permis dacqurir au fils des ans.
Je tiens exprimer toute ma grande reconnaissance lendroit de mon encadreur M. Arafet
BOUSSAID, enseignant lEcole Suprieure Prive dIngnierie et de Technologies
(ESPRIT) qui na cess de suivre chacun de mes pas tout au long de ce projet, pour ses
encouragements, ses conseils sa rigueur dans le travail et surtout ses qualits humaines qui
nous ont permis de travailler avec confiance dans un climat dtendu.
Je porte un remerciement particulier mon ami Anthony Rey qui ma soutenu tout au long
de la partie dveloppement de lapplication GOATS.
Tous mes remerciements tout le corps enseignant dESPRIT, M. Lamjed BETTAIEB
et M. Tahar BEN LAKHDAR pour leurs multiples efforts et sacrifices dploys pour nous
garantir une bonne formation.
Enfin, je tmoigne ici tous les membres du jury, toute ma reconnaissance et le respect que
jai pour eux pour avoir accept dvaluer mon travail.

Ralis par ric OBONO

LISTE DES FIGURES

*
Figure 1 : Clarilog
-------------------------------------------------------------------------------------- 6
Figure 2: H-inventory ---------------------------------------------------------------------------------- 6
Figure 3: Spiceworks ------------------------------------------------------------------------------------ 7
Figure 4: Mthodologie 2TUP ------------------------------------------------------------------------ 12
Figure 5: Diagramme de Contexte Statique ------------------------------------------------------ 16
Figure 6: Diagramme de Cas dutilisation GLOBAL ------------------------------------------- 19
Figure 7: Diagramme de Cas dutilisation Grer les tickets pour un administrateur
--------------------------------------------------------------------------------------------------------------- 20
Figure 8: Diagramme de Cas dutilisation Grer les tickets pour un agent------------ 21
Figure 9: Diagramme de Cas dutilisation Grer les tickets pour un Technicien ---- 21
Figure 10: Schma architecture 2-tiers ------------------------------------------------------------- 29
Figure 11: Schma architecture 3-tiers ------------------------------------------------------------- 30
Figure 12: Architecture du systme ----------------------------------------------------------------- 35
Figure 13: Diagramme dactivit Cycle de vie dun ticket ------------------------------------- 37
Figure 14: Chronogramme davancement du projet -------------------------------------------- 42
Figure 15: Prsentation des tches ------------------------------------------------------------------ 42
Figure 16: Interface dauthentification ------------------------------------------------------------- 43
Figure 17: Interface parc ordinateur --------------------------------------------------------------- 44
Figure 18: Interface parc logiciel -------------------------------------------------------------------- 44
Figure 19: Interface dcouverte du rseau--------------------------------------------------------- 45
Figure 20: Interface parc imprimante -------------------------------------------------------------- 46
Figure 21: Interface parc priphrique ------------------------------------------------------------ 46
Figure 22: Interface Rseau IP ----------------------------------------------------------------------- 47
Figure 23: Interface de cration dun ticket ------------------------------------------------------- 48
Figure 24: Interface de cration dun problme -------------------------------------------------- 48
Figure 25: Interface association dun problme un ticket------------------------------------ 49
Figure 26: Interface de Changement de ltat dun ticket -------------------------------------- 49
Figure 27: Interface de planification des interventions ----------------------------------------- 50
Figure 28: Interface dassociation dun ticket un budget ------------------------------------ 50
Figure 29: Interface daffichage des statistiques des tickets ----------------------------------- 51
Ralis par ric OBONO

vi

Figure 30: Interface de test des notifications mails ---------------------------------------------- 51

Figure 31: Interface de notification mail ----------------------------------------------------------- 52
Figure 32: Interface intgration AD sur GLPI --------------------------------------------------- 52
Figure 33: Interface de configuration du plugin Webservices --------------------------------- 53
Figure 34: Interface Application GOATS --------------------------------------------------------- 54

LISTE DES TABLEAUX

*

Tableau 1: Tableau comparatif ----------------------------------------------------------------------- 8

Tableau 2: Tableau comparatif des diffrentes technologies de Travail -------------------- 11
Tableau 3: Description du cas dutilisation Sauthentifier -------------------------------- 23
Tableau 4: Description du cas dutilisation Afficher les statistiques des tickets ------- 24
Tableau 5: Description du cas dutilisation Planifier les interventions ----------------- 25
Tableau 6: Description du cas dutilisation Grer les informations financires ------ 27

Ralis par ric OBONO

vii

GLOSSAIRE
*

AD: Active Directory

ADB: Android Debug Bridge
GLPI : Gestion Libre de Parc Informatique
GOATS: Glpi Open Android Tickets Service
IP: Internet Protocol
OCSIventoryNG: Open Computers and Software Inventory Next Generation
RPM: Red Hat Package Manager
SNMP: Simple Network Management Protocol
UML: Unified Modeling Language
XML-RPC: eXtensible Markup Language Remote Procedure Call
2TUP: Two Truck Unified Process

Ralis par ric OBONO

viii

Sommaire
INTRODUCTION GENERALE ................................................................................................ 1
Chapitre 1 : ETAT DE LART ................................................................................................. 3
Introduction ............................................................................................................................ 4
Prsentation de lorganisme daccueil ............................................................................. 4

III-

Prsentation du projet .................................................................................................. 5

1.

Problmatique .............................................................................................................. 5
a.

La non maitrise du hardware et du software ............................................................ 5

b.

Le manque de traabilit et de suivi......................................................................... 5

c.

Equipements non recenss ....................................................................................... 5

d.

Linscurit .............................................................................................................. 5
Etude de lexistant ....................................................................................................... 6

2.
a.

Clarilog .................................................................................................................... 6

b.

H-inventory .............................................................................................................. 6

c.

Spiceworks ............................................................................................................... 7

3.

Critique de lexistant ................................................................................................... 7

4.

Solution Propose ........................................................................................................ 7

III-

Mthodologie de travail ............................................................................................... 8

1.

Comparaison ................................................................................................................ 9

2.

Choix de la mthodologie de travail .......................................................................... 11

Conclusion ............................................................................................................................ 13
Chapitre 2 : ANALYSE ET SPECIFICATION DES BESOINS ............................................. 14
Introduction .......................................................................................................................... 15
I-

Contexte Statique .......................................................................................................... 15

II1.

Branche Fonctionnelle ............................................................................................... 16

Besoins Fonctionnels ................................................................................................. 16

Ralis par ric OBONO

ix

a.

Module inventaire et Gestion ................................................................................. 17

b.

Module Helpdesk ................................................................................................... 17

2.

Besoins non fonctionnels ........................................................................................... 17

3.

Besoins Optionnels .................................................................................................... 18

4.

Diagramme de cas dutilisation ................................................................................. 18

a.

Cas dutilisation GLPI ........................................................................................... 18

b.

Cas dutilisation grer tickets pour un administrateur ..................................... 20

c.

Cas dutilisation grer tickets pour un utilisateur ............................................ 21

d.

Cas dutilisation grer tickets pour un technicien ............................................ 21

Description des cas dutilisation ................................................................................ 22

5.
a.

Description du cas dutilisation : Sauthentifier .............................................. 22

b.

Description du cas dutilisation : Afficher les statistiques des tickets ............. 23

c.

Description du cas dutilisation Planifier interventions ................................... 24

d.

Description du cas dutilisation Grer les informations financires ................ 26

III-

Branche Technique .................................................................................................... 27

1.

Architecture ............................................................................................................... 28
a.

Larchitecture dcentralise ................................................................................... 28

b.

Larchitecture client-serveur .................................................................................. 28

2.

Langages de dveloppement ...................................................................................... 32

a.

PHP ........................................................................................................................ 32

b.

PERL ...................................................................................................................... 32

3.

Serveurs ..................................................................................................................... 32
a.

Serveur de base de donnes ................................................................................... 32

b.

Serveur web ........................................................................................................... 33

c.

Serveur de messagerie ............................................................................................ 33

Conclusion ............................................................................................................................ 33
CHAPITRE 3 : CONCEPTION ............................................................................................... 34
Ralis par ric OBONO

Introduction .......................................................................................................................... 35
I-

Architecture du systme ................................................................................................ 35

II-

Etude Dynamique ...................................................................................................... 36

Conclusion ............................................................................................................................ 38
CHAPITRE 4 : REALISATION .............................................................................................. 39
Introduction .......................................................................................................................... 40
I-

Environnement de travail .............................................................................................. 40

1.

Environnement matriel ............................................................................................ 40

2.

Environnement logiciel.............................................................................................. 40

II-

Difficults Rencontres ............................................................................................. 41

1.

Installation ................................................................................................................. 41

2.

Analyse ...................................................................................................................... 41

3.

Inventaire ................................................................................................................... 41

4.

Connectivit ............................................................................................................... 41

III-

Chronogramme davancement du projet ................................................................... 42

IV-

Prsentation des interfaces......................................................................................... 43

1.

Interface dauthentification........................................................................................ 43

2.

Interface parc ordinateur ............................................................................................ 44

3.

Interface parc logiciel ................................................................................................ 44

4.

Interfaces de dcouverte du rseau ............................................................................ 45

a.

Interface parc imprimante ...................................................................................... 46

b.

Interface parc priphrique .................................................................................... 46

c.

Interface rseau IP .................................................................................................. 47

5.

Interfaces pour la gestion des tickets ......................................................................... 47

a.

Cration dun ticket ................................................................................................ 48

b.

Cration dun problme ......................................................................................... 48

c.

Association dun problme un ticket ................................................................... 49

Ralis par ric OBONO

xi

d.

Changement de ltat dun ticket ........................................................................... 49

e.

Planification pour une intervention ........................................................................ 49

f.

Association dun ticket un budget ....................................................................... 50

g.

Affichage des statistiques des tickets ..................................................................... 51

6.

Interface pour les notifications par mail .................................................................... 51

7.

Interface Intgration AD ............................................................................................ 52

V-

Prsentation de la partie mobile................................................................................. 53

1.

Interface de configuration du Plugin Webservices .................................................... 53

2.

Interface de lapplication mobile GOATS [10] ....................................................... 54

Conclusion ............................................................................................................................ 55
CONCLUSION GENERALE .................................................................................................. 56
WEBOGRAPHIE ..................................................................................................................... 58

Ralis par ric OBONO

xii

INTRODUCTION
GENERALE
Avec le dveloppement de lutilisation dinternet, de plus en plus dentreprises ouvrent
leur parc informatique leurs partenaires ou leurs fournisseurs. Le parc informatique est un
ensemble de ressources matrielles et logicielles dont dispose une entreprise dans le
traitement automatis de linformation.
Pour assurer la survie et la prennit de ses ressources, il est important davoir une
gestion efficiente du parc informatique de lentreprise. La gestion du parc informatique
consiste donc dune part lister et localiser les quipements de lentreprise, dautre part
effectuer des tches de maintenance, dassistance aux utilisateurs. Ces oprations peuvent tre
effectues par une personne qualifie, mais bien souvent ce travail dpasse ses comptences.
Pour pallier cela, il est ncessaire quun ou plusieurs outils soient mis en place au
sein de lentreprise afin davoir un suivi rgulier du parc informatique et parfois anticiper sur
les dfaillances de ses ressources.
Le prsent rapport abordera donc les diffrentes phases, de la gestion de linventaire
des composantes matrielles et logicielles dun parc informatique la gestion de lassistance
aux utilisateurs et sera divis en quatre chapitres principaux.
Le premier chapitre sera ddi la prsentation de ltat de lart. Nous allons tout
dabord prsenter lorganisme daccueil et le projet. Ensuite nous passerons ltude et la

Ralis par ric OBONO

critique de lexistant pour enfin proposer une solution adquate. La mthodologie

utilise y sera galement dfinie pour nous permettre de raliser convenablement notre travail.
Le second chapitre sera consacr sur lanalyse des besoins fonctionnels et non
fonctionnels. Nous modliserons les besoins des utilisateurs via les diagrammes de cas
dutilisation.
Le troisime chapitre sera intitul conception et fera dans un premier temps une tude
prliminaire en prsentant larchitecture de la solution propose prcdemment. Dans un
second temps, en se rfrant la mthodologie de travail choisie, elle illustrera la plupart des
diagrammes de conception.
Le quatrime chapitre quant lui sera rserv la ralisation. Celui-ci, passera en
revue lenvironnement de travail, le planning de ralisation et finalement les rsultats obtenus.
Pour finir, une conclusion gnrale de tout le rapport sera ncessaire o nous
proposerons les ventuelles amliorations susceptibles dtre ajoutes ultrieurement.

Ralis par ric OBONO

Chapitre 1 :
ETAT DE LART

Ralis par ric OBONO

Introduction
Nous allons introduire dans ce premier chapitre le cadre du projet, savoir lentreprise
daccueil. Par la suite, nous passerons la prsentation du sujet, et pour finir, nous parlerons
de la mthodologie du dveloppement suivre durant notre projet.

I-

Prsentation de lorganisme daccueil

Le projet a t ralis au sein dESPRITEC, lunit de Recherche-Dveloppement-

Innovation (RDI) de lEcole Suprieure Priv dIngnierie et de Technologies

(ESPRIT) situ au ple technologique EL Ghazela. Cette unit soriente vers la
recherche applique et privilgie deux axes :
Laxe Technologique : pour la maitrise des technologies avances. Il
ncessite la mise en place dune plate-forme pour le dveloppement des
services et lexprimentation de nouvelles applications et de nouveaux
services ;
Laxe Application et service : pour dvelopper des prototypes, des
nouveaux services et applications avancs pouvant avoir des retombes
industrielles ou socioconomique. [1]
Lorganisme ESPRITEC est constitu de quatre grandes quipes :
Lquipe Cloud travaille sur la mise en place du Cloud ;
Lquipe ESPRIT On-line spcialise dans la mise en place et le
dveloppement des solutions internes dESPRIT ;
Lquipe M2M (Machine to Machine) sintresse la technologie ambiante et
RFID ;
M-vision sintresse la vision et le traitement dimage.
Les projets entrepris mobilisent des quipes composes de plusieurs chercheurs, enseignantschercheurs, ingnieurs et tudiants en projet de fin dtudes (PFE) et projet dintgration (PI)
sous la conduite dun chef de projet. Des tudiants en Masters ou Doctorats sont aussi intgrs
dans les quipes de projets dans le cadre de conventions, de partenariat avec les laboratoires et
units de recherche des tablissements publics.

Ralis par ric OBONO

II-

Prsentation du projet
1. Problmatique
Lide gnrale du projet consiste concevoir un outil applicatif qui pourra de faon

concrte permettre un utilisateur de circonscrire un incident ou une demande de service

travers les tickets. Ladministrateur utilisera le mme systme pour grer la partie
administrative et financire (budget, contrats avec les fournisseurs) dune part et dautre
part effectu la supervision (configuration, retour dvnements) en se basant sur linventaire
des matriaux du dit parc.
Avant de plonger dans ltude proprement dite de la solution, il est indispensable de
prendre du recul et de faire un rsum des problmes concrets existants que rencontrent au
jour le jour nos diffrents acteurs.
Cest donc dans cette optique quune petite enqute a t mene auprs de ces personnes
et la plupart des problmes recenss sont les suivants :
a. La non maitrise du hardware et du software
En tte de liste, ce problme est le plus rcurrent chez la plupart des administrateurs
rseaux et systmes. En effet, le nombre croissant dquipements et lhtrognit du parc ne
permettent pas ceux-ci de maitriser tous les systmes, logiciels et matriaux installs.
b. Le manque de traabilit et de suivi
De nos jours, le contrle et le suivi des oprations techniques et financires dans les
entreprises se font mais pas de manire automatises et scurises.
c. Equipements non recenss
Dans le rseau dune entreprise, lorsquun quipement tombe en panne, nous avons du
mal le remplacer par un quipement adquat (mme systme, mme modle, mme
priphrique) qui remplirait exactement les mmes fonctions. Ceci est d au fait que le
stock des ressources de lentreprise nest pas inventorier.
d. Linscurit
Les usagers utilisent les quipements de lentreprise comme bien personnel. De ce fait, ils
connectent diverses priphriques de stockage pouvant contenir des virus, installent des
logiciels plus ou moins malveillant, dsactivent le pare-feu, etc.

Ralis par ric OBONO

Lapplication propose devra donc tre mesure dapporter une solution

concrte la prise en charge des diffrents problmes ci-dessus.

2. Etude de lexistant
Parmi les produits existants sur le march, nous retrouvons :
a. Clarilog
Cette application a t cre par lentreprise
Clarilog France et permet entre autre :
Laudit du parc informatique en utilisant le
module clarilog Fast Inventory qui permet de
rcolter

les

donnes

sans

dploiement

dagent ;
Une cartographie complte des quipements
du parc ;
Clarilog SNMP Discovery rcupre les
informations prsentes dans le rseau via le

Figure 1 : Clarilog

protocole SNMP et fait appel un rfrentiel

dinformation aliment par les quipes [2]
clarilog ;
Clarilog offre les services de supervision et de
b. H-inventory
messageries instantanes avec les utilisateurs.
Sous licence GNU GPL, H-inventory propose les
fonctionnalits suivantes :
Inventorier les machines dun parc informatique ;
Grer les incidents (HelpDesk) ;
Faire un audit rseau (scan nmap) ;
Dployer

automatiquement

des

applications

Windows et Linux ;
Effectuer du monitoring sur les services (alertes,

Figure 2: H-inventory

mail) [3]

Ralis par ric OBONO

c. Spiceworks
Cette solution offre aux usagers les possibilits
suivantes :
Effectuer

linventaire

des

machines

sans

dploiement dagent ;
Grer les incidents (HelpDesk) ;
Scanner le rseau ;
Effectuer la gestion des configurations. [4]

Figure 3: Spiceworks

3. Critique de lexistant
Une analyse des solutions existantes montre que la plupart de ces applications offrent
des fonctionnalits de base de gestion dun parc informatique savoir linventaire, laccs au
Helpdesk et le scan du rseau.
Au regard de ces informations, nous pouvons relever quelles rpondent au besoin
principal des utilisateurs. Nanmoins, nous pouvons aussi noter les inconvnients suivants :
Clarilog nest pas une application open source ;
H-inventory noffre pas une gestion administrative et financire ne permettant pas
une traabilit et un suivi des tches administrative et financire effectues ;
Spiceworks ne permet pas un utilisateur dintgrer ses propres modules pour une
bonne performance de son parc.

4. Solution Propose
Aprs une tude comparative sur les diffrentes solutions existantes, il est donc
primordial au regard des inconvnients recenss de proposer une solution qui pourra rpondre
nos besoins.
Nous avons choisi de travailler avec loutil de Gestion Libre de Parc Informatique
abrg GLPI. Cet outil est capable de fournir une liste des ressources de notre part via un
inventaire et/ou un scan du rseau permettant ainsi lutilisateur de maitriser les quipements

Ralis par ric OBONO

de son parc. Il effectue le contrle et le suivi des oprations techniques et

financires et optime la gestion du parc avec lajout de modules. [5]
Le tableau ci-dessous rsume les fonctionnalits de chacune des solutions prsentes
plus haut.
Accs au

Machine

Gestion

Scan

Helpdesk

inventorie

administrative

du

et financire

rseau

Cartographie

Prix

Clarilog

Oui

Windows

Oui

Oui

Oui

Payant

H-inventory

Oui

Windows/Unix

Non

Oui

Non

Gratuit

Spiceworks

Oui

Windows

Oui

Oui

Oui

Gratuit

GLPI

Oui

Windows/Unix

Oui

Oui

Oui

Gratuit

Tableau 1: Tableau comparatif

III-

Mthodologie de travail

Pour assurer un bon rendement de dveloppement en termes de qualit et de productivit

le choix de la mthodologie en informatique est primordial. Vue la complexit des systmes
de nos jours, le gnie logiciel doit tenter de remdier cette complexit en offrant une
dmarche suivre avec des tapes bien prcises .Cest le principe des mthodologies de
travail.
Une mthode danalyse ou de conception est un procd qui a pour objectif de permettre de
formaliser les tapes prliminaires du dveloppement dun systme afin de rendre ce travail
plus fidle au besoin du client. Pour ce faire nous partons dun nonc informel (le besoin tel
quil est exprim par le client complt par la recherche dinformation auprs des experts du
domaine fonctionnel, comme par exemple les futurs utilisateurs de ce logiciel), ainsi que
lanalyse de lexistant ventuel (cest dire la manire dont les processus traiter par le
systme se droulent actuellement chez d autre client).
La phase danalyse permet de lister les rsultats attendus, en termes de fonctionnalits, de
robustesse, de maintenance de scurit, dextensibilits, etc. La phase danalyse permet de
dcrire de manire ambigu, le plus souvent en utilisant un langage de modlisation, le
fonctionnement futur du systme, afin den faciliter la ralisation. Aujourdhui le standard
8

Ralis par ric OBONO

industriel de modlisation objet est UML (Unified Modeling Langage). UML se

dfinit comme un langage de modlisation graphique et textuelle. Notre choix sest orient
vers le processus unifi (PU ou UP en anglais pour Unified Process) comme mthode de
dveloppement.

1. Comparaison
Le tableau ci-dessous contient un comparatif entre les principales mthodologies de
dveloppement que nous avons choisi vu la diversit de ces mthodes.
Mthodologies

Description
-

Cascade

Les

Points forts

phases

Points faibles

Distingue

sont

clairement les

droules

phases

dune

projet.

du

Non itratif ;

Pas

modles pour

manire

les

squentielle.

documents.

Promu

par

Itratif ;

Rational ;

RUP (Rational
Unified Process)

flou

la

les diffrents

une

en uvre ;

le

dialogue entre
-

Ne

couvre

mthodologie

intervenants

pas les phases

et

du projet ;

en amont et

un

outil

prt

lemploi ;

Spcifie

Le RUP est
fois

Assez

dans sa mise
-

de

en
-

Propose

des

modles

de

Cible

des

projets

de

pour

plus

10

projets types.

de

aval

au

dveloppeme
nt.

documents
des

personnes.

Sarticule
autour

Itratif ;

de

larchitecture;

Plutt
superficiel sur

Laisse

une

les

phases

Ralis par ric OBONO

2TUP(Two Truck

situes

un

la technologie

amont et en

cycle

de

et la gestion

aval

des risques ;

dveloppeme

du

nt ;

nt en Y;
-

en

Propose

dveloppeme

Unified Process)

large place

Cible

des

projets

de

toutes tailles.

Dfinit

les

profils

des

Ne

propose

intervenants,

pas

de

les plannings,

documents

les

types.

prototypes.
-

Ensemble des

Itratif ;

bonnes
de

Donne

en uvre ;

une

dveloppeme

importance

nt ;

aux

Programming)

aspects

techniques ;
-

10

Innovant :

en

programmatio

dveloppeme

n en duo.

nt.

Donne

toute

aval

au

La mise en

des itrations

confiance aux

uvre

dites

dveloppeurs

dveloppeme

de

et les laisser

nt nest pas

dveloppeme

faire

prcise ;

nt.

travail ;

sprints

leur

Scrum

couvre

en amont et

personnes.

Se base sur

Ne

pas les phases

Cible : Moins
de

flou

dans sa mise

pratiques

XP (eXtreme

Assez

du

Le

Chaque

dveloppeme

itration a un

nt rapide et

objectif bien

rptitif

se

prcis

traduit

par

fournit

et
une

une

forte

10

Ralis par ric OBONO

fonctionnalit

pression

teste.

lensemble

sur

des membres
de lquipe de
dveloppeme
nt.

Tableau 2: Tableau comparatif des diffrentes technologies de Travail

Ltude comparative ralis sur les trois principaux processus de dveloppement Rup,
Xp, 2TUP rsum dans le tableau nous permet de tirer les conclusions suivantes :
Le processus RUP nglige les contraintes techniques qui sont indispensables
dans notre projet, nous avons par consquent choisie de lcarter ;
Le processus XP nglige la phase de capture de besoins fonctionnels et
techniques et la phase de conception et donne une grande importance la phase
de dveloppement, il est par consquent cart ;
Le processus 2TUP permet en particulier de sparer les contraintes
fonctionnelles des contraintes techniques riges sous forme de deux branches
permettant de les exploiter paralllement ;
CASCADE est un processus squentiel et non itratif ;
Scrum quant lui subdivise les diffrentes phases du projet en sprint qui en
thorie ne dpasse pas 30 jours.

2. Choix de la mthodologie de travail

Suite ltude et la comparaison des principaux processus de dveloppement et afin de
contrler les risques et de mener bon terme notre projet vu sa complexit, nous avons opt
pour le processus 2TUP pour plusieurs raisons :
Dune part, 2TUP donne une grande importance la technologie ce qui est
important pour notre projet ;
Dautre part, 2TUP est un processus en Y qui contient une branche technique,
une branche fonctionnelle et une branche ralisation. Les deux branches
11

Ralis par ric OBONO

technique et fonctionnelle peuvent tre exploites en parallle. De ce

fait, si la technologie volue ou lors de droulement du projet, sil ya
modification dun besoin technique, la branche technique peut tre traite puis
rintgre dans le projet facilement. De mme si une nouvelle fonctionnalit se
prsente, seule la branche fonctionnelle va tre traite sans toucher lautre
branche.

Figure 4: Mthodologie 2TUP

Ce processus commence par une tude prliminaire qui permet didentifier les acteurs
du systme mettre en uvre qui est considr comme une boite noire tout en prsentant les
diffrents messages entre les utilisateurs et le systme et dlaborer le cahier de charges.
Daprs la figure ci-dessus, nous remarquerons que 2TUP est compose essentiellement de
trois tapes :
La branche gauche (fonctionnelle)
Capitalise la connaissance du mtier de lentreprise. Elle constitue gnralement un
investissement pour le moyen et long terme. Les fonctions du systme dinformation sont en
effet indpendantes des technologies utilises. Cette branche comporte les tapes suivantes :

12

Ralis par ric OBONO

 La capture des besoins fonctionnels, qui produit un modle des besoins

focalis sur le mtier des utilisateurs. Cette tape limine le risque davoir un
systme inadapt aux besoins des utilisateurs ;
Lanalyse qui consiste tudier les besoins fonctionnels de manire obtenir une
ide de ce que va raliser le systme en terme mtier.
La banche droite (architecture technique)
Capitalise un savoir-faire technique. Elle constitue un investissement pour le court et
moyen terme. Les techniques dveloppes pour le systme peuvent ltre en effet
indpendamment des fonctions raliser. Cette branche comporte les tapes suivantes :
La capture des besoins techniques ;
La conception gnrique.
La branche du milieu (ralisation)
A lissue des volutions du modle fonctionnel et de larchitecture technique, la
ralisation du systme consiste fusionner les rsultats des deux branches. Cette fusion
conduit lobtention dun processus en forme Y. Cette branche comporte les tapes
suivantes :
La conception prliminaire ;
La conception dtaille ;
Le codage ;
Lintgration.

Conclusion
Dans ce chapitre, il a t question de prsenter lorganisme daccueil ESPRITEC. Nous
avons galement procd une tude des solutions existantes qui nous a conduite par la suite
proposer une solution dont le but est de combler les limites de ces dernires. Une analyse de
la mthodologie de dveloppement mettre en uvre est venue finalement mettre un terme
cette premire partie.
Le chapitre suivant est consacr lanalyse et la spcification des besoins du projet qui
prsente la premire tape du processus de dveloppement 2TUP.
13

Ralis par ric OBONO

Chapitre 2 :
ANALYSE ET
SPECIFICATION DES
BESOINS

14

Ralis par ric OBONO

Introduction
Aprs ltude et lanalyse de ltat de lart, il est temps prsent de se focaliser sur une
analyse des besoins de notre application de gestion de parc informatique. Il sera question de
prsenter dans un premier temps les principaux acteurs et leurs rles. Ensuite dans la branche
fonctionnelle, nous allons dfinir les besoins fonctionnels et non fonctionnels, puis prsenter
le diagramme de cas dutilisation du systme et dcrire les diffrents cas dutilisation.
Finalement nous clturons ce chapitre sur la deuxime branche de la mthodologie savoir la
branche technique, do seront lists galement les principaux besoins.

I-

Contexte Statique

Cest ltape initiale qui consiste faire un recensement sur les diffrents acteurs qui vont
interagir de prs ou de loin avec le systme. Mais avant daller plus loin, il est important de
dfinir au pralable certains termes importants pour la suite.
Acteur : Constitue une entit physique capable dinteragir avec le systme. Notons
juste que cette entit peut tre humaine ou matrielle.
Systme : Cest lentit concevoir, dans notre cas il sagit de lapplication en
elle-mme.

Identification des acteurs

Les acteurs se recrutent parmi les utilisateurs du systme et aussi parmi les responsables
de la configuration et de la maintenance. Dans notre cas, il ya trois acteurs principaux :
Administrateur : Cest un super utilisateur ayant le droit deffectuer toutes sortes
doprations telles que la configuration du systme, le contrle des connexions, le
contrle du suivi des tickets, laffectation des fournisseurs, budgets, contrats et bien
dautre.
Technicien : effectue la prise en charge des tickets, reoit les notifications de la part
de ladministrateur.
Utilisateur : Cre des tickets, reoit des notifications.

15

Ralis par ric OBONO

La figure ci-dessous illustre parfaitement ces diffrents acteurs ainsi que leur
interaction avec le systme qui se reprsente sous forme de trait reliant les acteurs concerns
au systme.

System

Technicien

Systme de Gestion Libre de Parc Informatique

Administrateur

Utilisateur

Figure 5: Diagramme de Contexte Statique

Nous apercevons donc clairement le systme de Gestion Libre de Parc Informatique

reprsent, ainsi que les diffrents acteurs. Nanmoins cette reprsentation est encore
incomplte car le systme ainsi reprsent constitue une sorte de boite noire dont nous ne
connaissons en rien le fonctionnement. Il est donc ncessaire de passer par une reprsentation
un peu plus dtaille et cest ce qui fera lobjet de la partie suivante.

II-

Branche Fonctionnelle
1. Besoins Fonctionnels
Avant de parler du fonctionnement proprement dit du systme, il est ncessaire de

dfinir dans un premier temps les fonctionnalits qui seront implmentes au sein dudit
systme. Ainsi donc, cette tape dcrira ce que nous attendons de notre application. Puis, tout

16

Ralis par ric OBONO

ceci sera modlis sous forme de diagramme laide du langage de modlisation

UML, en ce que nous appellerons par la suite cas dutilisation.
De ce fait, sil faut redfinir concrtement les fonctionnalits de notre systme, nous pouvons
tout simplement dire que notre application doit tre capable de :
a. Module inventaire et Gestion
Afficher linventaire des ressources ;
Afficher la map du rseau ;
Grer les informations financires;
Grer le module de configuration.
b. Module Helpdesk
Grer les tickets
Planifier les interventions
Afficher les statistiques des tickets
Afficher les notifications

2. Besoins non fonctionnels

Nous entendons par l les besoins qui caractrisent le systme. Autrement dit, il sagit
de dfinir un ensemble de critres essentiels pour le bon fonctionnement de notre application.
Il est noter cependant quils peuvent tre exprims en matire de performance, de type de
matriel ou le type de conception.
Dans le cadre de notre travail, nous pouvons citer par exemple :
Ergonomie : Linterface de lapplication doit tre simple et utilisable afin que
lutilisateur puisse lexploiter sans se rfrer des connaissances particulires, en
dautres termes, notre application doit tre lisible et facile manipuler par nimporte
quel utilisateur ;
Besoins de scurit : Lapplication devra assurer la scurit des utilisateurs. Do la
ncessit de procder lauthentification des agents et administrateurs tout en assurant
la confidentialit de leurs donnes ;
Lextensibilit : Cest--dire quil doit y avoir une possibilit dajouter de nouvelles
fonctionnalits ou de modifier celles existantes ;

17

Ralis par ric OBONO

 Rapidit et intgrabilit dans dautres applications : Lapplication devra

tre rapide et assure que les modules seront intgrables et utilisables dans dautres
applications ;
Besoins de haute disponibilit : Au final il est important que notre application puisse
fonctionner sur une plateforme hautement disponible et pouvant grer un nombre
lev de requtes.

3. Besoins Optionnels
Il est question ici denrichir le systme de fonctionnalits qui pourraient rpondre aux
besoins des utilisateurs afin de le rendre encore plus agrable utiliser. Sans toutefois
tendre vers le superflu, nous pourrions par exemple dresser en fonction des acteurs la liste
suivante :
Intgration de lannuaire AD dans le but dimporter les utilisateurs de lentreprise
dans le serveur GLPI ;
Intgration dun serveur de messagerie pour grer la partie notification avec un
domaine en locale propre une entreprise et spar le domaine professionnel du
domaine prive.
Nous venons dexposer lensemble des besoins auxquels doit rpondre le systme global
dvelopper, et avons mis le point sue un ensemble des fonctionnalits juges faisables dans le
cadre de notre projet. Il est dsormais possible de migrer vers une autre partie tout aussi
importante qui traitera de faon plus dtaille des fonctionnalits voques ci-dessus relatives
chaque entit.

4. Diagramme de cas dutilisation

Nous parvenons une tape cl du processus. Cest elle qui grce ltude ralise dans
la partie prcdente mettra en valeur le rle de chaque acteur du systme ainsi que les
fonctionnalits prsentes plus haut.
a. Cas dutilisation GLPI
Pour assurer la gestion du parc informatique, ladministrateur possde les privilges
deffectuer plusieurs configurations afin damliorer les performances du systme, le rendre
ergonomique transparent et scuritaire. A titre dexemple, il possde la permission de grer
18

Ralis par ric OBONO

les modules de gestion des finances, dassistance aux utilisateurs (helpdesk),

dinventaires comme le montre le diagramme ci-dessous :

System
Afficher l'inventaire des ressources

Afficher la map du rseau

Technicien

<<include>>

Grer les informationns financires

<<include>>

Grer tickets

Planifier intervations

Administrateur

<<include>>
<<include>>

<<include>>

S'authentifier

Afficher les statistiques des tickets

<<include>>

Utilisateur
Grer module configuration

Figure 6: Diagramme de Cas dutilisation GLOBAL

La figure ci-dessus reprsente le diagramme de cas dutilisation gnral de notre

systme de gestion de parc informatique. Nous y retrouvons comme convenu les acteurs
principaux et leurs rles. Nous remarquons galement les relations dinclusions qui lient les
diffrents cas dutilisations, et qui indiquent simplement que le cas dutilisation vers lequel ils
tendent devrait tre excut au pralable.

19

Ralis par ric OBONO

b. Cas dutilisation grer tickets pour un administrateur

System
Ajouter des tickets

Modifier l'etat des tickets

<<extend>>

Envoyer les suivis des tickets

<<extend>>

Grer tickets
Administrateur

<<extend>>

Supprimer des tickets

<<extend>>
<<extend>>
<<extend>>

Associer des couts des tickets

Associer des intervenants des tickets

Figure 7: Diagramme de Cas dutilisation Grer les tickets pour un administrateur

La figure suivante nous prsente de faon plus dtaille le cas dutilisation Grer tickets .
Nous pouvons donc entrevoir plusieurs fonctions qui servent construire le cycle de vie dun
ticket.

20

Ralis par ric OBONO

c. Cas dutilisation grer tickets pour un utilisateur

Sur la figure ci-dessous, nous dcouvrons la mme fonctionnalit mais qui correspond
lagent. Lui galement aura la possibilit de crer, de modifier et de supprimer des tickets.
System
Crer des tickets

Modifier des tickets

<<extend>>

<<extend>>

Grer tickets

Supprimer des tickets

Utilisateur

<<extend>>

<<extend>>

Visualiser les suivis des tickets

Figure 8: Diagramme de Cas dutilisation Grer les tickets pour un agent

d. Cas dutilisation grer tickets pour un technicien

Il sagit ici donner ltat de validation des tickets et dajouter des suivis. Les diffrents
tats de validation sont : En attente de validation, Accepte, Refuse.
System

valider les tickets

<<extend>>

Grer tickets
Technicien

Ajouter les suivis des tickets

<<extend>>

<<extend>>

Associer des solutions des tickets

Figure 9: Diagramme de Cas dutilisation Grer les tickets pour un Technicien

21

Ralis par ric OBONO

5. Description des cas dutilisation

Dans cette partie il sera question de donner plus de dtails sur les diffrents cas
dutilisation prsents ci-dessus. Tous les cas cits ne seront pas prsents uniquement ceux
qui suivent: Sauthentifier , Planifier interventions , Afficher statistiques et Grer
finances .
a. Description du cas dutilisation : Sauthentifier
Etapes

Description
Acteurs : Administrateur/Utilisateur/Technicien

Rsum

Titre : Authentifier Administrateur ou Utilisateur ou Technicien

Description :

Le

systme

identifie

ce

niveau

ladministrateur/utilisateur /technicien qui veut utiliser le service.

Ladministrateur/utilisateur/technicien sest connect au systme

Pr

Le systme est oprationnel

conditions

Ladministrateur/utilisateur/technicien entre ses paramtres de

Scnario

connexion identifiant et mot de passe

Nominal

Le systme vrifie les informations saisies

Le

systme

affiche

la

page

de

profil

de

ladministrateur/utilisateur/technicien
Les donnes saisies sont errones

Scnario
Alternatif

Ladministrateur/utilisateur/technicien est sur sa page de profil

Post-

Le systme attend dsormais quil excute une action

conditions

<<Actor>>
administrateur

Systme

1 : saisie des paramtres de connexion()

2 : vrification des paramtres()

Squencement

alt
3 : affiche page de profil()

4 : message d'erreur()

22

Ralis par ric OBONO

Tableau 3: Description du cas dutilisation Sauthentifier

Comme dans tout systme dinformations utilis par plusieurs acteurs, il est important pour
assurer la scurit des donnes de chaque acteur que chacun passe par une phase
dauthentification. Cest galement le cas de notre systme o administrateur, utilisateur et
technicien se sont authentifis avant de pouvoir raliser une quelconque opration.

b. Description du cas dutilisation : Afficher les statistiques des tickets

Etapes
Rsum

Description
Acteurs : Administrateur
Titre : Afficher les statistiques des tickets
Description : affiche ladministrateur le nombre de
tickets ouverts, rsolus, en retard et clos.

Pr conditions

Ladministrateur sest authentifi

Les tickets ont t cres
Ladministrateur accde au menu dassistance ou helpdesk

Ladministrateur clique sur longlet Statistiques

Scnario Nominal

Ladministrateur slectionne les statistiques visualiser

Le systme renvoi sur sa page des graphes indiquant le
cycle de vie des tickets et la dure moyenne de traitement
des tickets

Scnario Alternatif

Le systme na pas pu afficher les statistiques car aucun

ticket na t cre
Post-conditions

Les statistiques des tickets sont affiches

Le systme attend dsormais quil excute une nouvelle

action

23

Ralis par ric OBONO

Systme

<<Actor>>
administrateur

ref Grer les tickets

Squencement

1 : demande l'affichage des statistiques()

2 : affiche les statistiques()

Tableau 4: Description du cas dutilisation Afficher les statistiques des tickets

Dans le tableau ci-dessus, nous dcrivons galement les dtails du cas dutilisation afficher
les statistiques qui saccompagne du scnario dexcution nominal et dun scnario
alternatif. Nous y retrouvons aussi le squencement qui indique lordre dexcution des
actions des diffrents acteurs.

c. Description du cas dutilisation Planifier interventions

Etapes
Rsum

Description
Acteurs : Administrateur
Titre : Planifier interventions
Description : affiche ladministrateur du systme les dates
et les heures libres afin daffecter des tickets aux techniciens
disponibles.

Pr
conditions

Ladministrateur sest authentifi

Le systme a au pralable un ticket en cours de planification
Le systme a au pralable un technicien disponible
Ladministrateur accde au menu dassistance ou helpdesk
24

Ralis par ric OBONO

 Ladministrateur clique sur longlet Tickets

Scnario Nominal

Ladministrateur slectionne le ticket planifier

Ladministrateur affecte la date, lheure et un technicien ce
ticket
Le systme renvoi sur la page Planning un tableau qui
indique la date, lheure et le technicien affects

Scnario Alternatif

Le systme na pas de ticket en cours de planification

Le systme ne contient pas de technicien disponible

Post-conditions

Le planning des interventions est affich

Le systme attend dsormais quil excute une nouvelle

action
<<Actor>>
administrateur

Systme

ref S'authentifier

Squencement

1 : slectionne le ticket planifier()

2 : affiche l'interface du ticket()

3 : affecte la date, l'heure et le technicien()

4 : enregistre les affectations()

5 : affiche le planning des interventions()

Tableau 5: Description du cas dutilisation Planifier les interventions

Le tableau ci-dessus dcrit son tour les dtails du cas dutilisation Planifier les
intervenants qui saccompagne du scnario dexcution nominal et dun scnario alternatif.
Nous y retrouvons aussi le squencement qui indique lordre des actions des acteurs.

25

Ralis par ric OBONO

d. Description du cas dutilisation Grer les informations

financires
Etapes
Rsum

Description
Acteurs : Administrateur
Titre : Grer finances
Description : Associe les fournisseurs, les budgets, les contrats.

Pr
conditions

Ladministrateur sest authentifi

Ladministrateur accde au menu de gestion

Ladministrateur clique sur longlet Budget

Scnario

Ladministrateur cre un budget

Nominal

Ladministrateur clique sur longlet fournisseurs

Ladministrateur cre un fournisseur
Ladministrateur clique sur longlet Contrat
Ladministrateur cre un contrat
Ladministrateur associe des budgets et des contrats des fournisseurs

Scnario

Le systme na pas cr de fournisseur

Alternatif

Le systme na pas cr de contrat

Le systme na pas cr de budget

Postconditions

La liaison entre les fournisseurs, les contrats et les budgets a t cre

Le systme attend dsormais quil excute une nouvelle action

26

Ralis par ric OBONO

<<Actor>>
Administrateur

Systme

ref S'authentifier

1 : selectionne le menu de gestion()

2 : affiche les lments du menu()

3 : cre un fournisseur()
4 : enregistre le fournisseur cr()
5 : cre un budget()

Squencement

6 : enregistre le budget cr()

7 : associe un budget un fournisseur()

8 : cre un contrat()
9 : enregistre le contrat cr()
10 : associe un contrat un fournisseur()

Tableau 6: Description du cas dutilisation Grer les informations financires

Aprs avoir identifi les rles des acteurs aussi bien que les fonctionnalits du systme,
nous pouvons passer prsent la branche technique qui va se charger de prsenter les
besoins techniques indispensable au dveloppement de notre projet.

III-

Branche Technique

Les besoins fonctionnels de notre systme ayant t dfinis, il est temps de se poser la
question de savoir quels outils allons-nous utiliser et surtout sur quelle architecture logicielle
notre choix va se porter. Cest ainsi que nous dfinirons dans cette partie en premier lieu
27

Ralis par ric OBONO

larchitecture, puis les langages de dveloppement et nous terminerons par les

serveurs utiliss.

1. Architecture
Nous devons savoir quil existe plusieurs types darchitectures. Parmi ces
architectures, nous pouvons citer :
a. Larchitecture dcentralise
Les donnes et lapplication ne sont pas localises sur un seul serveur. Une telle
architecture permet de rsister des attaques puisse que le logiciel client ne se connecte pas
un unique serveur mais plusieurs. Le systme est ainsi plus robuste mais la recherche
dinformations est plus difficile.
b. Larchitecture client-serveur
Lapplication est subdivise entre deux entits client et serveur qui cooprent
ensemble via des requtes. Le dialogue entre les deux entits peut se rsumer par :
Le client demande un service au serveur
Le serveur ralise ce service et renvoie le rsultat au client
Nous distinguons trois types darchitectures client-serveur :
Architecture 2-tiers
Une architecture 2-tiers est compose de deux lments, un client et un serveur et o le
tiers fait rfrence non pas une entit physique mais logique. Une analyse dtaille des
lments de cette architecture et de leurs fonctions attaches met en vidence certains points
essentiels sur lesquels nous attirons lattention :
La fonction de prsentation est la charge du client exclusivement.
Le calcul (processing) est reparti entre le client et le serveur.
Le logiciel client est gnralement spcifique au serveur.
Les donnes sont stockes ou accessibles via un le serveur. Dans le cadre dune
topologie daccs une base de donnes, le serveur traitera les requtes en
provenance du client qui se feront en gnral en langage SQL.
Cest parce que le client assume des tches de prsentation et de processing, et donc de fait
communique avec le serveur sans intervention dun autre processus que le client est dit
28

Ralis par ric OBONO

 lourd par opposition larchitecture 3-tiers o le client est constitu dun

simple navigateur internet et communique avec un serveur via un frontal.
En dfinitive et dans la perspective dune architecture 2-tiers avec un serveur de base de
donnes (SGBD) nous obtenons le schma suivant :

Base de donnes

Client

Rseau

Serveur de BD

Figure 10: Schma architecture 2-tiers

Avantages :
Dveloppement rapide toute chose tant gale par ailleurs la complexit du
projet.
Outils de dveloppement robustes
Inconvnients :
Problmes de contrle des volutions de versions et de redistribution des
applications.
En termes de scurit larchitecture 2-tiers peut tre complexe dans la mesure
o il sera ncessaire lutilisateur davoir autant daccs protgs par un mot de passe
que daccs serveurs.

29

Ralis par ric OBONO

 Architecture 3-tiers
Larchitecture 3-tiers est compose de trois lments, ou plus prcisment de trois
couches. En effet, dans la philosophie qui a guid llaboration de cette architecture, il est
adquat de parler de couche fonctionnelle attache un lment/entit logique. Il faut
distinguer trois couches/lments :
La couche prsentation : associe au client qui de fait est dit lger dans
la mesure o il nassume aucune fonction de traitement la diffrence du
modle 2-tiers.
La couche fonctionnelle : lie au serveur, qui dans de nombreux cas est un
serveur Web muni dextensions applicatives. Cest ce dernier qui va excuter
tous les calculs ou faire des requtes vers dautres serveurs additionnels
(exemple vers des SGBD).
La couche de donnes : lie au serveur de base de donnes (SGBD).
Enfin le schma suivant illustre une architecture souvent rencontre avec un serveur Web.

Base de donnes

Database
Server

Rseau

Serveur

Extension
Program
Serveur
Client

Rseau

WEB

lger
Navigateu
r
Figure 11: Schma architecture 3-tiers

30

Ralis par ric OBONO

Avantages :
Requtes plus flexibles au niveau du client.
La sparation qui existe entre le client et le serveur et le SGBD permet une
spcialisation des dveloppeurs sur chaque tiers larchitecture.
Plus de flexibilit dans lallocation des ressources
Inconvnients :
Une expertise de dveloppement acqurir qui semble plus longue que dans le
cadre dune architecture 2-tiers.
Cot de dveloppement plus lev.
Architecture n-tiers
Larchitecture n-tiers a t pense pour pallier aux limitations des architectures trois tiers
et concevoir des applications puissantes et simples maintenir. En fait, larchitecture ntiers qualifie la distribution dapplication entre de multiples services et non la
multiplication des niveaux de services.
Avantages :
Ajout de composants
Meilleures performances
Fiabilit accrue
Scurit
Flexibilit
Maintenance
Inconvnients :
Gestion de la complexit du systme global
Gestion de la communication entre composants
Gestion de lhtrognit des outils et systmes [6]

31

Ralis par ric OBONO

 Choix de larchitecture utilise

Suite ltude qui vient dtre faite, notre choix sest port sur larchitecture clientserveur et plus prcisment sur larchitecture n-tiers pour les raisons suivantes :
Elle correspond le mieux la structure attendue dans le sens o notre systme
constituera en quelque sorte le serveur et les autres acteurs seront les clients.
Deuximement, vu que nous avons besoin dun client lger qui naura qu se
connecter au serveur, il nous a donc paru vident dopter pour une architecture
plus volue que larchitecture 2-tiers.
Finalement, bien que larchitecture 3-tiers soit adquate, elle possde
nanmoins des limites qui sont corriges dans la structure n-tiers qui rappelonsle est plus flexible, plus souple et plus puissante.

2. Langages de dveloppement
a. PHP
Le PHP est un langage de programmation qui sintgre dans vos pages HTML. Il est
permet entre autre de rendre automatiques des tches rptitives, notamment grce la
communication avec une base de donnes. [7]
b. PERL
PERL est un langage de programmation utilis pour le dveloppement de scripts
dadministration systme sous UNIX. [8]

3. Serveurs
Comme le stipule larchitecture n-tiers, nous aurons besoin au minimum dun serveur web
et dun serveur de base de donnes.
a. Serveur de base de donnes
Comme serveur de base de donnes, nous avons choisi dutiliser MYSQL tout
&simplement parce quil offre les avantages suivants :
Rapidit

32

Ralis par ric OBONO

 Facilit dutilisation
Gratuit
Connexion et scurit
Portabilit
b. Serveur web
Nous avons choisi dutiliser le serveur Apache pour les raisons suivantes :
Il peut fonctionner sur une varit de systmes dexploitation.
Son architecture modulaire se prte la personnalisation lorsquil est ncessaire de
construire une configuration de serveur aux besoins dun client.
Extensible : Il est en constante volution.
Cest gratuit, fiable et facile configurer.
c. Serveur de messagerie
Le serveur de messagerie nous a permis de grer la partie notification par mail.

Conclusion
En conclusion, nous avons spcifi les diffrents besoins auxquels doit rpondre notre
systme. Ce chapitre nous a t utile pour montrer notre but, nos besoins et claircir notre
dmarche. Il nous a offert une vision plus ou moins dtaille sur le but mme du projet, et une
meilleure distinction entre les lments constitutifs du systme.
Enfin, il nous reste laborer une bonne conception afin dassurer le bon
fonctionnement du systme. Cest ainsi que nous pourrons entamer le prochain chapitre sur la
conception pas srs.

33

Ralis par ric OBONO

CHAPITRE 3 :
CONCEPTION

34

Ralis par ric OBONO

Introduction
Ltape de conception dfinit gnralement les structures et les modles suivre lors de la
phase dimplmentation de lapplication. Cest la phase o nous prparons larchitecture du
projet, et o nous dfinissons la structure de lapplication. Par souci de clart, nous dbuterons
par une phase prliminaire o sera prsente larchitecture du systme mettre en place.
Ensuite, nous poursuivrons par une tude dynamique qui illustrera le processus de
fonctionnement du dit systme.

I-

Architecture du systme

Cette tape constitue la fusion entre la branche fonctionnelle et la branche technique.

Cest donc ce niveau que seront dfinis larchitecture du systme.

Figure 12: Architecture du systme

Les agents FusionInventory sont installs sur les machines du parc informatique.
35

Ralis par ric OBONO

Le plugin FusionInventory intgr dans le serveur GLPI permet de donner des

informations sur des ressources physiques se trouvant dans le rseau du parc.
La communication entre lagent et le serveur se fait via le protocole http ou https. En cas
dabsence dun agent, les quipements dans le rseau communiquent directement avec le
serveur via le protocole SNMP. Les donnes de linventaire sont stockes dans la base de
donnes de GLPI.
Le serveur GLPI effectue une synchronisation avec le plugin FusionInventory dans le but
davoir des remontes automatises des informations venant du parc.
Ce serveur effectue galement une synchronisation avec Active Directory afin que chaque
acteur travers son compte Active Directory puisse accder linterface graphique de GLPI
et sauthentifier en tant quutilisateur, technicien ou administrateur.
La synchronisation des serveurs GLPI et de messagerie permet davoir un suivi de la gestion
des tickets sur sa boite mail.
Ladministrateur excute les oprations de suivi des tickets soit travers son ordinateur ou
son smartphone.
Le plugin Webservice intgr dans le serveur GLPI a pour rle de faire communiquer celui-ci
avec des applications externes partir du protocole XML-RPC.

II-

Etude Dynamique
Ltude dynamique permet de reprsenter le comportement dynamique du systme. En

effet cette vision sert mettre en vidence les relations inter-objets.

Diagramme dactivit
Nous allons ici voquer le diagramme comportemental d'UML, permettant de
reprsenter le dclenchement d'vnements en fonction des tats du systme et de modliser
des comportements parallles (multi-threads ou multi-processus).
Ce diagramme est une reprsentation proche de l'organigramme. Le but ici est de dcrire en
dtail le processus gnral de la gestion des tickets de sorte quelle soit facile comprendre et
simple utiliser.

36

Ralis par ric OBONO

Figure 13: Diagramme dactivit Cycle de vie dun ticket

37

Ralis par ric OBONO

Conclusion
En conclusion, ce chapitre nous a permis de mettre en avant les phases ncessaires la
ralisation de notre application savoir : Larchitecture, les composants du systme et les
diagrammes de conception.
A cette tape, il devient possible de passer au chapitre suivant o nous allons parler de
lenvironnement de travail utilis pour limplmentation de la solution adopte et dcrire la
dmarche de la ralisation.

38

Ralis par ric OBONO

CHAPITRE 4 :
REALISATION

39

Ralis par ric OBONO

Introduction
Nous avons tout au long des chapitres prcdents introduit le projet, numr les
tapes ncessaires sa mise en uvre, analys lensemble des besoins satisfaire et conu
larchitecture du systme. A prsent, nous entamerons la phase de ralisation qui est ltape
o nous traduisons la conception et les rgles par un langage de programmation afin daboutir
une automatisation des besoins tels quils ont t dfini dans la spcification.
Ainsi donc, ce chapitre sera divis en quatre parties majeures. Premirement, nous allons
commencer par une description de lenvironnement de travail savoir lenvironnement
logiciel et lenvironnement matriel. Ensuite nous numrerons les difficults rencontres
pendant la ralisation de ce projet, puis suivra la prsentation des rsultats obtenus, et enfin
nous terminerons par la prsentation du chronogramme du projet.

I-

Environnement de travail
1. Environnement matriel
Nous avons utilis pour les besoins de ce projet un ordinateur portable SAMSUNG

RV509 caractris par :

Un systme dexploitation Windows 7 (32 bits) ;
Un processeur Intel Pentium CPU;
Une mmoire RAM de 3,00 Go ;
Un disque dur de 300 Go.

2. Environnement logiciel
VMware ;
Centos 6.5 ;
Windows server 2003 ;
StarUml ;
Smartdraw : Cest un logiciel de dessin. Nous allons utiliser pour raliser
larchitecture de notre application ainsi que le diagramme dactivit ;
Eclipse Juno ;
Serveur de messagerie.

40

Ralis par ric OBONO

II-

Difficults Rencontres

En termes de difficults, nous avons fait face des problmes qui peuvent se regrouper en
plusieurs catgories : linstallation, lanalyse, linventaire, la connectivit.

1. Installation
Linstallation du serveur GLPI na pas t aise. Il nous a fallu grer les problmes de
dpendances. Cest ainsi que nous avions dabord installs des archives de paquets (RPM)
compatibles avec notre systme dexploitation dune part et dautre part compatible avec la
version de GLPI choisie avant de commencer linstallation proprement dite de GLPI.

2. Analyse
Une tude Thorique et pratique a t faite sur les outils OCSInventory NG et
FusionInventory afin de slectionner la technologie utilise concernant la partie inventaire.

3. Inventaire
Pour effectuer la remonte des informations des machines agents, il a fallu faire et
refaire plusieurs tests. A travers ces tests, nous avons retenu :
La remonte est effective si et seulement si la version de lagent fusion
install est infrieure ou gale celle du serveur fusion ;
Linventaire au niveau des machines virtuelles est fonctionnel lorsque lon
dite une nouvelle rgle sur le serveur GLPI permettant de rcuprer les
informations de lagent via son tag.

4. Connectivit
Dune part la connectivit entre GLPI et les autres serveurs, dautre part la
connectivit entre lmulateur, lenvironnement de dveloppement et GLPI.
Pour rsoudre ces problmes nous avons utilis PFsense, ce qui a permis de connecter GLPI
aux diffrents serveurs suivant une architecture de LAN-WAN-DMZ, ensuite nous avons
install lmulateur Android sur une machine virtuelle afin de lui affecter une carte rseau lui
permettant de se connecter avec lenvironnement de dveloppement ainsi que GLPI.
Toutes ces phases ne constituent en fait quune partie de toutes les phases de ralisations
nonces dans ce rapport. Une vue complte de lensemble de ces tches et du temps qui a t
allou fait lobjet de la partie suivante.

41

Ralis par ric OBONO

III-

Chronogramme davancement du projet

La figure ci-dessous prsente le chronogramme davancement du projet.

Figure 14: Chronogramme davancement du projet

Chaque branche de cette figure reprsente la dure dune tche. Les tches ralises tout au
long de ce projet sont rpertories sur la figure suivante.

Figure 15: Prsentation des tches

42

Ralis par ric OBONO

De cette figure, nous pouvons tirer plusieurs informations mais les plus pertinentes sont les
suivantes :
Dure du projet : Le projet a dbut au mois de fvrier 2014 et sest achev en
Juillet 2014 Ce qui nous fait environ cinq mois qui sont dcoups suivant le
chronogramme ci-dessus.
Il comprend cinq (07) phases principales qui sont : llaboration du sujet, lanalyse
des besoins fonctionnels et techniques, linstallation de GLPI, la maitrise des
menus GLPI (la partie Helpdesk y compris), le dveloppement (GOATS), la
validation des fonctionnalits et finalement la rdaction du rapport.

IV-

Prsentation des interfaces

1. Interface dauthentification

Figure 16: Interface dauthentification

La figure ci-dessus reprsente linterface dauthentification de notre application. Seul les

utilisateurs internes (administrateur, technicien, utilisateur normal) et les utilisateurs externes
cest--dire ceux ayant un compte dans Active Directory peuvent y accder.

43

Ralis par ric OBONO

2. Interface parc ordinateur

Figure 17: Interface parc ordinateur

Aprs avoir install les agents FusionInventory sur les machines, une remonte des
informations (ordinateur, logiciel,) est faite au niveau de notre serveur GLPI.

Nous

pouvons aussi effectuer un inventaire manuel. Cest le cas des machines DELL ordinateur et
HP ordinateur.

3. Interface parc logiciel

Figure 18: Interface parc logiciel

La figure ci-dessus nous donne les informations sur lditeur, la version, le nombre
dinstallation et le nombre de licence de chaque logiciel inventori. Dans notre cas, le nom
des systmes dexploitation ne sont pas visibles car tous sont traqus.

44

Ralis par ric OBONO

4. Interfaces de dcouverte du rseau

Avant dexcuter une dcouverte du rseau, dautres pralables sont indispensables,
dont :
La dfinition des plages IP sur lesquelles lagent FusionInventory va oprer ;
Lajout dune tche et lassociation de celle-ci un agent et une plage IP.

Figure 19: Interface dcouverte du rseau

A partir de cette dcouverte du rseau, nous avons rcuprer les informations sur les
imprimantes, les moniteurs, les switchs ainsi que les rseaux directement connects notre
pc. [9]

45

Ralis par ric OBONO

a. Interface parc imprimante

Figure 20: Interface parc imprimante

b. Interface parc priphrique

Figure 21: Interface parc priphrique

46

Ralis par ric OBONO

c. Interface rseau IP

Figure 22: Interface Rseau IP

5. Interfaces pour la gestion des tickets

Scnario
Un utilisateur a un problme avec son ordinateur, son clavier USB ne marche pas. Il
envoie une demande de tickets : le ticket passe ltat nouveau.
Ladministrateur reoit la demande : le ticket passe de ltat nouveau ltat attente
daffectation. Ensuite, ladministrateur attribue le ticket un technicien et planifie celui-ci en
fonction de son emploi de temps. Le ticket passe de ltat en attente ltat en cours planifi.
Le jour J le technicien va installer un nouveau clavier USB sur ce pc. Il tablit le cout du
matriel achet, le cout de sa main duvre et les affecte ce ticket. Le problme tant rsolu,
le technicien fait passer le ticket de ltat en cours ltat rsolu et envoi un suivi
ladministrateur.
Ladministrateur vrifie alors les comptes et clos le ticket.

47

Ralis par ric OBONO

a. Cration dun ticket

Figure 23: Interface de cration dun ticket

b. Cration dun problme

Figure 24: Interface de cration dun problme

48

Ralis par ric OBONO

c. Association dun problme un ticket

Figure 25: Interface association dun problme un ticket

d. Changement de ltat dun ticket

Figure 26: Interface de Changement de ltat dun ticket

e. Planification pour une intervention

49

Ralis par ric OBONO

Figure 27: Interface de planification des interventions

f. Association dun ticket un budget

Figure 28: Interface dassociation dun ticket un budget

50

Ralis par ric OBONO

g. Affichage des statistiques des tickets

Figure 29: Interface daffichage des statistiques des tickets

6. Interface pour les notifications par mail

Figure 30: Interface de test des notifications mails

51

Ralis par ric OBONO

Figure 31: Interface de notification mail

7. Interface Intgration AD

Figure 32: Interface intgration AD sur GLPI

52

Ralis par ric OBONO

V-

Prsentation de la partie mobile

GLPI offre un suivi mobile de la gestion des tickets, mais partir des versions suprieures
ou gales la version 0.80.X, cette fonctionnalit nest pas intgre car elle est encore en
cours de dveloppement. Cest pourquoi nous avons trouv utile de dvelopper une partie
mobile. Cette partie consistera :
Afficher la liste des nouveaux tickets ;
Afficher leurs informations de bases (date de cration, affectation des acteurs) ;
Clturer les tickets

1. Interface de configuration du Plugin Webservices

Figure 33: Interface de configuration du plugin Webservices

Sur la figure ci-dessus, nous avons activ les services, la compression et le mode
Debug. La plage dadresses IPv4 correspond ladresse ip de notre mulateur.

53

Ralis par ric OBONO

2. Interface de lapplication mobile GOATS [10]

Figure 34: Interface Application GOATS

54

Ralis par ric OBONO

Lors du dmarrage, une interface dauthentification souvre dans laquelle nous devons
entrer ladresse ip du serveur GLPI ainsi que le nom du compte administrateur et son mot de
passe. Aprs lauthentification, une liste de nouveaux tickets saffiche sur lcran. En cliquant
sur le nom de lun de ses tickets, nous avons sur une autre interface tous les informations
concernant ce ticket ainsi que la possibilit de le fermer.

Conclusion
Nous sommes parvenus au terme de ce chapitre dont lobjectif principal tait de prsenter le
produit final obtenu. A cet effet, nous avons tour tour prsents les outils matriels et
logiciels utiliss dune part, puis nous avons dcrit les difficults rencontres, qui ont t suivi
du chronogramme davancement et de la prsentation des interfaces de notre systme.

55

Ralis par ric OBONO

CONCLUSION
GENERALE
Ce document a t rdig au terme du projet de fin dtudes ralis au sein
dESPRITEC.
Il sagissait en effet de dvelopper une application de Outil de gestion de parc
informatique et de Helpdesk , qui devrait booster la gestion des ressources des entreprises.
La premire phase de ce rapport tait consacre la prsentation de ltat de lart, et nous
avons prsent lorganisme daccueil, ainsi que le projet proprement dit. Ces deux parties ont
t suivies dune analyse sur les applications existantes et leurs limites, ce qui nous a permis
de poser la premire pierre de ldifice en proposant notre propre solution.
La deuxime phase quant elle consistait dgager les besoins fonctionnels, non
fonctionnels de lapplication, et par la mme occasion les besoins techniques suivant la
mthodologie de dveloppement 2TUP. Cela nous permettait par la suite de raliser les
diagrammes de cas dutilisation qui nous serviraient dans la phase de conception.
La phase de conception nous a permis dentrer plus en profondeur dans lanalyse et de
parler de larchitecture de lapplication. Par la suite il a fallu dcrire le systme ltat
statique et dynamique. Ce que nous avons fait par lentremise des diagrammes de classes et
dactivits.

56

Ralis par ric OBONO

Enfin dans la phase de ralisation nous avons prsent les outils et technologies
utiliss pour raliser ce travail. Puis nous nous sommes attards sur les difficults rencontres,
le chronogramme davancement du projet et les interfaces de notre systme.
Au final donc, il est important de souligner que ce projet a atteint les objectifs fixs au
dpart, et au-del du sentiment de satisfaction qui sen suit, il nous a permis de bnficier de
nouvelles connaissances venues complter celles que nous avons acquises tout au long de
notre formation.
Cependant, nous pouvons toujours y apporter quelques amliorations qui feront de cette
application un outil incontournable tant dans le domaine de gestion de parc informatique que
dans le domaine de supervision. En effet nous pourrons intgrer un module monitoring qui
nous permettra ainsi de superviser les machines inventori dans notre parc. Ce module
monitoring interagira avec des applications de supervision telles que Shinken ou Centreon.

57

Ralis par ric OBONO

WEBOGRAPHIE
[1] : Site officiel dESPRIT http://www.esprit.ens.tn/test/v3/index.php?lang=fr , dernire visite
le 03/06/2014 (Page 4)
[2] :

Site

officiel

de

clarilog

http://www.clarilog.com/FR/solutions/demonstrations-

fonctionnelles.html , dernire visite le 05/06/2014 (Page 6)

[3] :

Site

LINUXFR.ORG

http://linuxfr.org/news/h-inventory-un-nouvel-asset-manager-

opensource--2 , dernire visite le 05/06/2014 (Page 6)

[4] : Site officiel de Spiceworks http://www.spiceworks.com/ , dernire visite le 05/06/2014
(Page 7)
[5] : Installation de GLPI http://smnet.fr/ocsglpi/ocs-glpi-intro.html , dernire visite le
21/04/2014 (Page 8)
[6] : Architecture

client-serveur

http://mrproof.blogspot.com/2011/03/larchitecture-client-

serveur.html , dernire visite le 09/06/2014 (Page 31)

[7] : Gestion des dpendances
15/04/2014

(Page 32)
Installation

[8] :

http://dl.fedoraproject.org/pub/epel/6/i386/ , dernire visite

de

lagent

Fusion

sur

Linux

http://wiki.kogite.fr/index.php/Installation_de_l'agent_fusioninventory , dernire visite le

23/04/2014

(Page 32)

[9] : Dcouverte du rseau http://www.prestaopen.com/gestion-de-parc-glpi/decouvertesnmp.html , dernire visite 07/06/2014 (Page 45)

[10] :

Installation

de

lmulateur

Android

sur

une

machine

virtuelle

http://www.phonandroid.com/tutoriel-installer-android-4-3-sur-votre-pc.html , dernire visite

le 01/07/2014

(Page 54)

58

Ralis par ric OBONO

RESUME
Aujourdhui bien grer son parc informatique
pour une entreprise est devenu indispensable.
Bien grer son parc informatique cest aussi bien
grer le capital informatique de la socit et ainsi
rduire les cots, satisfaire les utilisateurs,
optimiser les ressources internes, imposer une
certaine dmarche qualit.
GLPI est la solution Open Source de rfrence
dans la gestion de parc informatique et de
Helpdesk.

Elle

se

prsente

comme

une

application Full Web qui gre lensemble de vos

problmatiques de gestion de parc informatique :
de la gestion de linventaire des composantes
matrielles ou logicielles dun parc informatique
la gestion de lassistance aux utilisateurs.

Abstract
Today manager its IT infrastructure for a business has
become indispensable. Manage its IT park is also
manage the IT capital of the company and reduce
costs, user satisfaction, optimize internal resources,
impose some quality control.
GLPI is the open source reference solution in the IT
asset management and Helpdesk. It presents itself as
a Full Web application that manages all of your issues
59
IT asset management: managing the inventory of

Ralis par ric OBONO

hardware and software components of a computer