Rapport PFE: Gestion de Parc Informatique

i Réalisé par Éric OBONO

En vue de l’obtention du diplôme

National d’ingénieur

PROJET DE FIN D’ETUDES

MISE EN PLACE D’UN OUTIL DE

GESTION DE PARC INFORMATIQUE

ET DE HELPDESK

Encadrant académique:

M. Arafet BOUSSAID

Réalisé par:

M. Eric Maxime OBONO OBONO

ii Réalisé par Éric OBONO

Signatures

Signature de l’encadrant pédagogique

Signature du département des langues

iii Réalisé par Éric OBONO

AVANT-PROPOS

L’obtention du diplôme national d’ingénieur au sein de l’Ecole Supérieure Privée

d’Ingénierie et de Technologie ESPRIT en Tunisie est couronnée par la réalisation d’un projet de

fin d’études aux termes duquel l’étudiant est appelé à faire une présentation du travail effectué

tout au long dudit projet.

C’est dans ce cadre que j’ai effectué un stage de fin d’études au sein de l’unité de

Recherche – Développement – Innovation d’Espritec. Le développement de cette division est

guidé par la maitrise des technologies avancées offrant des services ayant des retombées

industrielles et socio-économiques.

Le projet qui m’a été attribué a pour titre la mise en place d’un outil de gestion de parc

informatique et de helpdesk et vise à la gestion des ressources d’un parc informatique d’une

entreprise.

iv Réalisé par Éric OBONO

DEDICACES

A mon Papa Bonaventure OBONO et à mes chères et tendres maman Nicole et maman

Solange pour tous leurs sacrifices toujours consentis pour le bien-être de leurs chers enfants.

A mes grands frères ELOUNDOU Stéphane et ETABA Yves pour leurs efforts sans limites

et la confiance qu’ils m’accordent.

A mes frères et sœurs pour tout le soutient qu’ils n’ont jamais cessé de m’apporter.

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 séjour sur le territoire Tunisien.

v Réalisé par Éric OBONO

REMERCIEMENTS

Je rends grâce à l’ETERNEL tout Puissant pour la Merveille que je suis ; Merci PAPA pour

ton immense Amour et pour la connaissance que tu m’as permis d’acquérir au fils des ans.

Je tiens à exprimer toute ma grande reconnaissance à l’endroit de mon encadreur M. Arafet

BOUSSAID, enseignant à l’Ecole Supérieure Privée d’Ingénierie et de Technologies

(ESPRIT) qui n’a 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 qualités humaines qui

nous ont permis de travailler avec confiance dans un climat détendu.

Je porte un remerciement particulier à mon ami Anthony Rey qui m’a soutenu tout au long

de la partie développement de l’application GOATS.

Tous mes remerciements à tout le corps enseignant d’ESPRIT, à M. Lamjed BETTAIEB

et à M. Tahar BEN LAKHDAR pour leurs multiples efforts et sacrifices déployés pour nous

garantir une bonne formation.

Enfin, je témoigne ici à tous les membres du jury, toute ma reconnaissance et le respect que

j’ai pour eux pour avoir accepté d’évaluer mon travail.

vi Réalisé par Éric OBONO

Figure 1 : Clarilog -------------------------------------------------------------------------------------- 6

Figure 2: H-inventory ---------------------------------------------------------------------------------- 6

Figure 3: Spiceworks ------------------------------------------------------------------------------------ 7

Figure 4: Méthodologie 2TUP ------------------------------------------------------------------------ 12

Figure 5: Diagramme de Contexte Statique ------------------------------------------------------ 16

Figure 6: Diagramme de Cas d’utilisation GLOBAL ------------------------------------------- 19

Figure 7: Diagramme de Cas d’utilisation « Gérer les tickets » pour un administrateur

--------------------------------------------------------------------------------------------------------------- 20

Figure 8: Diagramme de Cas d’utilisation « Gérer les tickets » pour un agent ------------ 21

Figure 9: Diagramme de Cas d’utilisation « Gérer les tickets » pour un Technicien ---- 21

Figure 10: Schéma architecture 2-tiers ------------------------------------------------------------- 29

Figure 11: Schéma architecture 3-tiers ------------------------------------------------------------- 30

Figure 12: Architecture du système ----------------------------------------------------------------- 35

Figure 13: Diagramme d’activité Cycle de vie d’un ticket ------------------------------------- 37

Figure 14: Chronogramme d’avancement du projet -------------------------------------------- 42

Figure 15: Présentation des tâches ------------------------------------------------------------------ 42

Figure 16: Interface d’authentification ------------------------------------------------------------- 43

Figure 17: Interface parc ordinateur --------------------------------------------------------------- 44

Figure 18: Interface parc logiciel -------------------------------------------------------------------- 44

Figure 19: Interface découverte du réseau --------------------------------------------------------- 45

Figure 20: Interface parc imprimante -------------------------------------------------------------- 46

Figure 21: Interface parc périphérique ------------------------------------------------------------ 46

Figure 22: Interface Réseau IP ----------------------------------------------------------------------- 47

Figure 23: Interface de création d’un ticket ------------------------------------------------------- 48

Figure 24: Interface de création d’un problème -------------------------------------------------- 48

Figure 25: Interface association d’un problème à un ticket ------------------------------------ 49

Figure 26: Interface de Changement de l’état d’un ticket -------------------------------------- 49

Figure 27: Interface de planification des interventions ----------------------------------------- 50

Figure 28: Interface d’association d’un ticket à un budget ------------------------------------ 50

Figure 29: Interface d’affichage des statistiques des tickets ----------------------------------- 51

LISTE DES FIGURES

*

vii Réalisé par Éric OBONO

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

Figure 31: Interface de notification mail ----------------------------------------------------------- 52

Figure 32: Interface intégration AD sur GLPI --------------------------------------------------- 52

Figure 33: Interface de configuration du plugin Webservices --------------------------------- 53

Figure 34: Interface Application GOATS --------------------------------------------------------- 54

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

Tableau 2: Tableau comparatif des différentes technologies de Travail -------------------- 11

Tableau 3: Description du cas d’utilisation « S’authentifier » -------------------------------- 23

Tableau 4: Description du cas d’utilisation « Afficher les statistiques des tickets» ------- 24

Tableau 5: Description du cas d’utilisation « Planifier les interventions » ----------------- 25

Tableau 6: Description du cas d’utilisation « Gérer les informations financières » ------ 27

LISTE DES TABLEAUX

*

viii Réalisé par Éric OBONO

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

GLOSSAIRE

*

ix Réalisé par Éric OBONO

Sommaire

INTRODUCTION GENERALE ................................................................................................ 1

Chapitre 1 : ETAT DE L’ART ................................................................................................. 3

Introduction ............................................................................................................................ 4

I- Présentation de l’organisme d’accueil ............................................................................. 4

II- Présentation du projet .................................................................................................. 5

1. Problématique .............................................................................................................. 5

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

b. Le manque de traçabilité et de suivi......................................................................... 5

c. Equipements non recensés ....................................................................................... 5

d. L’insécurité .............................................................................................................. 5

2. Etude de l’existant ....................................................................................................... 6

a. Clarilog .................................................................................................................... 6

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

c. Spiceworks ............................................................................................................... 7

3. Critique de l’existant ................................................................................................... 7

4. Solution Proposée ........................................................................................................ 7

III- Méthodologie de travail ............................................................................................... 8

1. Comparaison ................................................................................................................ 9

2. Choix de la méthodologie de travail .......................................................................... 11

Conclusion ............................................................................................................................ 13

Chapitre 2 : ANALYSE ET SPECIFICATION DES BESOINS ............................................. 14

Introduction .......................................................................................................................... 15

I- Contexte Statique .......................................................................................................... 15

II- Branche Fonctionnelle ............................................................................................... 16

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

x Réalisé par Éric OBONO

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

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

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

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

4. Diagramme de cas d’utilisation ................................................................................. 18

a. Cas d’utilisation GLPI ........................................................................................... 18

b. Cas d’utilisation « gérer tickets » pour un administrateur ..................................... 20

c. Cas d’utilisation « gérer tickets » pour un utilisateur ............................................ 21

d. Cas d’utilisation « gérer tickets » pour un technicien ............................................ 21

5. Description des cas d’utilisation ................................................................................ 22

a. Description du cas d’utilisation : « S’authentifier » .............................................. 22

b. Description du cas d’utilisation : « Afficher les statistiques des tickets » ............. 23

c. Description du cas d’utilisation « Planifier interventions » ................................... 24

d. Description du cas d’utilisation « Gérer les informations financières » ................ 26

III- Branche Technique .................................................................................................... 27

1. Architecture ............................................................................................................... 28

a. L’architecture décentralisée ................................................................................... 28

b. L’architecture client-serveur .................................................................................. 28

2. Langages de développement ...................................................................................... 32

a. PHP ........................................................................................................................ 32

b. PERL ...................................................................................................................... 32

3. Serveurs ..................................................................................................................... 32

a. Serveur de base de données ................................................................................... 32

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

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

Conclusion ............................................................................................................................ 33

CHAPITRE 3 : CONCEPTION ............................................................................................... 34

xi Réalisé par Éric OBONO

Introduction .......................................................................................................................... 35

I- Architecture du système ................................................................................................ 35

II- Etude Dynamique ...................................................................................................... 36

Conclusion ............................................................................................................................ 38

CHAPITRE 4 : REALISATION .............................................................................................. 39

Introduction .......................................................................................................................... 40

I- Environnement de travail .............................................................................................. 40

1. Environnement matériel ............................................................................................ 40

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

II- Difficultés Rencontrées ............................................................................................. 41

1. Installation ................................................................................................................. 41

2. Analyse ...................................................................................................................... 41

3. Inventaire ................................................................................................................... 41

4. Connectivité ............................................................................................................... 41

III- Chronogramme d’avancement du projet ................................................................... 42

IV- Présentation des interfaces ......................................................................................... 43

1. Interface d’authentification ........................................................................................ 43

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

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

4. Interfaces de découverte du réseau ............................................................................ 45

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

b. Interface parc périphérique .................................................................................... 46

c. Interface réseau IP .................................................................................................. 47

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

a. Création d’un ticket ................................................................................................ 48

b. Création d’un problème ......................................................................................... 48

c. Association d’un problème à un ticket ................................................................... 49

xii Réalisé par Éric OBONO

d. Changement de l’état d’un ticket ........................................................................... 49

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

f. Association d’un ticket à un budget ....................................................................... 50

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

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

7. Interface Intégration AD ............................................................................................ 52

V- Présentation de la partie mobile ................................................................................. 53

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

2. Interface de l’application mobile GOATS [10] ....................................................... 54

Conclusion ............................................................................................................................ 55

CONCLUSION GENERALE .................................................................................................. 56

WEBOGRAPHIE ..................................................................................................................... 58

1

Réalisé par Éric OBONO

Avec le développement de l’utilisation d’internet, de plus en plus d’entreprises ouvrent

leur parc informatique à leurs partenaires ou à leurs fournisseurs. Le parc informatique est un

ensemble de ressources matérielles et logicielles dont dispose une entreprise dans le

traitement automatisé de l’information.

Pour assurer la survie et la pérennité de ses ressources, il est important d’avoir une

gestion efficiente du parc informatique de l’entreprise. La gestion du parc informatique

consiste donc d’une part à lister et à localiser les équipements de l’entreprise, d’autre part à

effectuer des tâches de maintenance, d’assistance aux utilisateurs. Ces opérations peuvent être

effectuées par une personne qualifiée, mais bien souvent ce travail dépasse ses compétences.

Pour pallier à cela, il est nécessaire qu’un ou plusieurs outils soient mis en place au

sein de l’entreprise afin d’avoir un suivi régulier du parc informatique et parfois anticiper sur

les défaillances de ses ressources.

Le présent rapport abordera donc les différentes phases, de la gestion de l’inventaire

des composantes matérielles et logicielles d’un parc informatique à la gestion de l’assistance

aux utilisateurs et sera divisé en quatre chapitres principaux.

Le premier chapitre sera dédié à la présentation de l’état de l’art. Nous allons tout

d’abord présenter l’organisme d’accueil et le projet. Ensuite nous passerons à l’étude et à la

INTRODUCTION GENERALE

2


critique de l’existant pour enfin proposer une solution adéquate. La méthodologie

utilisée y sera également définie pour nous permettre de réaliser convenablement notre travail.

Le second chapitre sera consacré sur l’analyse des besoins fonctionnels et non

fonctionnels. Nous modéliserons les besoins des utilisateurs via les diagrammes de cas

d’utilisation.

Le troisième chapitre sera intitulé conception et fera dans un premier temps une étude

préliminaire en présentant l’architecture de la solution proposée précédemment. Dans un

second temps, en se référant à la méthodologie de travail choisie, elle illustrera la plupart des

diagrammes de conception.

Le quatrième chapitre quant à lui sera réservé à la réalisation. Celui-ci, passera en

revue l’environnement de travail, le planning de réalisation et finalement les résultats obtenus.

Pour finir, une conclusion générale de tout le rapport sera nécessaire où nous

proposerons les éventuelles améliorations susceptibles d’être ajoutées ultérieurement.

3


Chapitre 1 :

ETAT DE L’ART

4


Introduction

Nous allons introduire dans ce premier chapitre le cadre du projet, à savoir l’entreprise

d’accueil. Par la suite, nous passerons à la présentation du sujet, et pour finir, nous parlerons

de la méthodologie du développement à suivre durant notre projet.

I- Présentation de l’organisme d’accueil

Le projet a été réalisé au sein d’ESPRITEC, l’unité de Recherche-Développement-

Innovation (RDI) de l’Ecole Supérieure Privé d’Ingénierie et de Technologies

(ESPRIT) situé au pôle technologique EL Ghazela. Cette unité s’oriente vers la

« recherche appliquée » et privilégie deux axes :

L’axe « Technologique » : pour la maitrise des technologies avancées. Il

nécessite la mise en place d’une plate-forme pour le développement des

services et l’expérimentation de nouvelles applications et de nouveaux

services ;

L’axe « Application et service » : pour développer des prototypes, des

nouveaux services et applications avancés pouvant avoir des retombées

industrielles ou socioéconomique. [1]

L’organisme ESPRITEC est constitué de quatre grandes équipes :

L’équipe Cloud travaille sur la mise en place du Cloud ;

L’équipe ESPRIT On-line spécialisée dans la mise en place et le

développement des solutions internes d’ESPRIT ;

L’équipe M2M (Machine to Machine) s’intéresse à la technologie ambiante et

RFID ;

M-vision s’intéresse à la vision et le traitement d’image.

Les projets entrepris mobilisent des équipes composées de plusieurs chercheurs, enseignants-

chercheurs, ingénieurs et étudiants en projet de fin d’études (PFE) et projet d’intégration (PI)

sous la conduite d’un chef de projet. Des étudiants en Masters ou Doctorats sont aussi intégrés

dans les équipes de projets dans le cadre de conventions, de partenariat avec les laboratoires et

unités de recherche des établissements publics.

5


II- Présentation du projet

1. Problématique

L’idée générale du projet consiste à concevoir un outil applicatif qui pourra de façon

concrète permettre à un utilisateur de circonscrire un incident ou une demande de service à

travers les tickets. L’administrateur utilisera le même système pour gérer la partie

administrative et financière (budget, contrats avec les fournisseurs…) d’une part et d’autre

part effectué la supervision (configuration, retour d’évènements) en se basant sur l’inventaire

des matériaux du dit parc.

Avant de plonger dans l’étude proprement dite de la solution, il est indispensable de

prendre du recul et de faire un résumé des problèmes concrets existants que rencontrent au

jour le jour nos différents acteurs.

C’est donc dans cette optique qu’une petite enquête a été menée auprès de ces personnes

et la plupart des problèmes recensés sont les suivants :

a. La non maitrise du hardware et du software

En tête de liste, ce problème est le plus récurrent chez la plupart des administrateurs

réseaux et systèmes. En effet, le nombre croissant d’équipements et l’hétérogénéité du parc ne

permettent pas à ceux-ci de maitriser tous les systèmes, logiciels et matériaux installés.

b. Le manque de traçabilité et de suivi

De nos jours, le contrôle et le suivi des opérations techniques et financières dans les

entreprises se font mais pas de manière automatisées et sécurisées.

c. Equipements non recensés

Dans le réseau d’une entreprise, lorsqu’un équipement tombe en panne, nous avons du

mal à le remplacer par un équipement adéquat (même système, même modèle, même

périphérique…) qui remplirait exactement les mêmes fonctions. Ceci est dû au fait que le

stock des ressources de l’entreprise n’est pas inventorier.

d. L’insécurité

Les usagers utilisent les équipements de l’entreprise comme bien personnel. De ce fait, ils

connectent diverses périphériques de stockage pouvant contenir des virus, installent des

logiciels plus ou moins malveillant, désactivent le pare-feu, etc.

6


L’application proposée devra donc être à mesure d’apporter une solution

concrète à la prise en charge des différents problèmes ci-dessus.

2. Etude de l’existant

Parmi les produits existants sur le marché, nous retrouvons :

a. Clarilog

b. H-inventory

Figure 1 : Clarilog

Sous licence GNU GPL, H-inventory propose les

fonctionnalités suivantes :

Inventorier les machines d’un parc informatique ;

Gérer les incidents (HelpDesk) ;

Faire un audit réseau (scan nmap) ;

Déployer automatiquement des applications

Windows et Linux ;

Effectuer du monitoring sur les services (alertes,

mail…) [3]

Figure 2: H-inventory

Cette application a été créée par l’entreprise

Clarilog France et permet entre autre :

L’audit du parc informatique en utilisant le

module clarilog Fast Inventory qui permet de

récolter les données sans déploiement

d’agent ;

Une cartographie complète des équipements

du parc ;

Clarilog SNMP Discovery récupère les

informations présentes dans le réseau via le

protocole SNMP et fait appel à un référentiel

d’information alimenté par les équipes [2]

clarilog ;

Clarilog offre les services de supervision et de

messageries instantanées avec les utilisateurs.

7


c. Spiceworks

3. Critique de l’existant

Une analyse des solutions existantes montre que la plupart de ces applications offrent

des fonctionnalités de base de gestion d’un parc informatique à savoir l’inventaire, l’accès au

Helpdesk et le scan du réseau.

Au regard de ces informations, nous pouvons relever qu’elles répondent au besoin

principal des utilisateurs. Néanmoins, nous pouvons aussi noter les inconvénients suivants :

Clarilog n’est pas une application open source ;

H-inventory n’offre pas une gestion administrative et financière ne permettant pas

une traçabilité et un suivi des tâches administrative et financière effectuées ;

Spiceworks ne permet pas à un utilisateur d’intégrer ses propres modules pour une

bonne performance de son parc.

4. Solution Proposée

Après une étude comparative sur les différentes solutions existantes, il est donc

primordial au regard des inconvénients recensés de proposer une solution qui pourra répondre

à nos besoins.

Nous avons choisi de travailler avec l’outil de Gestion Libre de Parc Informatique

abrégé GLPI. Cet outil est capable de fournir une liste des ressources de notre part via un

inventaire et/ou un scan du réseau permettant ainsi à l’utilisateur de maitriser les équipements

Cette solution offre aux usagers les possibilités

suivantes :

Effectuer l’inventaire des machines sans

déploiement d’agent ;

Gérer les incidents (HelpDesk) ;

Scanner le réseau ;

Effectuer la gestion des configurations. [4]

Figure 3: Spiceworks

8


de son parc. Il effectue le contrôle et le suivi des opérations techniques et

financières et optime la gestion du parc avec l’ajout de modules. [5]

Le tableau ci-dessous résume les fonctionnalités de chacune des solutions présentées

plus haut.

Accès au

Helpdesk

Machine

inventoriée

Gestion

administrative

et financière

Scan

du

réseau

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- Méthodologie de travail

Pour assurer un bon rendement de développement en termes de qualité et de productivité

le choix de la méthodologie en informatique est primordial. Vue la complexité des systèmes

de nos jours, le génie logiciel doit tenter de remédier à cette complexité en offrant une

démarche à suivre avec des étapes bien précises .C’est le principe des méthodologies de

travail.

Une méthode d’analyse ou de conception est un procédé qui a pour objectif de permettre de

formaliser les étapes préliminaires du développement d’un système afin de rendre ce travail

plus fidèle au besoin du client. Pour ce faire nous partons d’un énoncé informel (le besoin tel

qu’il est exprimé par le client complété par la recherche d’information auprès des experts du

domaine fonctionnel, comme par exemple les futurs utilisateurs de ce logiciel), ainsi que

l’analyse de l’existant éventuel (c’est à dire la manière dont les processus à traiter par le

système se déroulent actuellement chez d autre client).

La phase d’analyse permet de lister les résultats attendus, en termes de fonctionnalités, de

robustesse, de maintenance de sécurité, d’extensibilités, etc. La phase d’analyse permet de

décrire de manière ambiguë, le plus souvent en utilisant un langage de modélisation, le

fonctionnement futur du système, afin d’en faciliter la réalisation. Aujourd’hui le standard

9


industriel de modélisation objet est UML (Unified Modeling Langage). UML se

définit comme un langage de modélisation graphique et textuelle. Notre choix s’est orienté

vers le processus unifié (PU ou UP en anglais pour Unified Process) comme méthode de

développement.

1. Comparaison

Le tableau ci-dessous contient un comparatif entre les principales méthodologies de

développement que nous avons choisi vu la diversité de ces méthodes.

Méthodologies Description Points forts Points faibles

Cascade

- Les phases

sont

déroulées

d’une

manière

séquentielle.

- Distingue

clairement les

phases du

projet.

- Non itératif ;

- Pas de

modèles pour

les

documents.

RUP (Rational

Unified Process)

- Promu par

Rational ;

- Le RUP est à

la fois une

méthodologie

et un outil

prêt à

l’emploi ;

- Cible des

projets de

plus de 10

personnes.

- Itératif ;

- Spécifie le

dialogue entre

les différents

intervenants

du projet ;

- Propose des

modèles de

documents

pour des

projets types.

- Assez flou

dans sa mise

en œuvre ;

- Ne couvre

pas les phases

en amont et

en aval au

développeme

nt.

- S’articule

autour de

l’architecture;

- Itératif ;

- Laisse une

- Plutôt

superficiel sur

les phases

10


2TUP(Two Truck

Unified Process)

- Propose un

cycle de

développeme

nt en Y;

- Cible des

projets de

toutes tailles.

large place à

la technologie

et à la gestion

des risques ;

- Définit les

profils des

intervenants,

les plannings,

les

prototypes.

situées en

amont et en

aval du

développeme

nt ;

- Ne propose

pas de

documents

types.

XP (eXtreme

Programming)

- Ensemble des

bonnes

pratiques de

développeme

nt ;

- Cible : Moins

de 10

personnes.

- Itératif ;

- Donne une

importance

aux aspects

techniques ;

- Innovant :

programmatio

n en duo.

- Assez flou

dans sa mise

en œuvre ;

- Ne couvre

pas les phases

en amont et

en aval au

développeme

nt.

Scrum

- Se base sur

des itérations

dites sprints

de

développeme

nt.

- Donne toute

confiance aux

développeurs

et les laisser

faire leur

travail ;

- Chaque

itération a un

objectif bien

précis et

fournit une

- La mise en

œuvre du

développeme

nt n’est pas

précisée ;

- Le

développeme

nt rapide et

répétitif se

traduit par

une forte

11


fonctionnalité

testée.

pression sur

l’ensemble

des membres

de l’équipe de

développeme

nt.

Tableau 2: Tableau comparatif des différentes technologies de Travail

L’étude comparative réalisé sur les trois principaux processus de développement Rup,

Xp, 2TUP résumé dans le tableau nous permet de tirer les conclusions suivantes :

Le processus RUP néglige les contraintes techniques qui sont indispensables

dans notre projet, nous avons par conséquent choisie de l’écarter ;

Le processus XP néglige la phase de capture de besoins fonctionnels et

techniques et la phase de conception et donne une grande importance à la phase

de développement, il est par conséquent écarté ;

Le processus 2TUP permet en particulier de séparer les contraintes

fonctionnelles des contraintes techniques érigées sous forme de deux branches

permettant de les exploiter parallèlement ;

CASCADE est un processus séquentiel et non itératif ;

Scrum quant à lui subdivise les différentes phases du projet en sprint qui en

théorie ne dépasse pas 30 jours.

2. Choix de la méthodologie de travail

Suite à l’étude et à la comparaison des principaux processus de développement et afin de

contrôler les risques et de mener à bon terme notre projet vu sa complexité, nous avons opté

pour le processus 2TUP pour plusieurs raisons :

D’une part, 2TUP donne une grande importance à la technologie ce qui est

important pour notre projet ;

D’autre part, 2TUP est un processus en Y qui contient une branche technique,

une branche fonctionnelle et une branche réalisation. Les deux branches

12


technique et fonctionnelle peuvent être exploitées en parallèle. De ce

fait, si la technologie évolue ou lors de déroulement du projet, s’il y’a

modification d’un besoin technique, la branche technique peut être traitée puis

réintégrée dans le projet facilement. De même si une nouvelle fonctionnalité se

présente, seule la branche fonctionnelle va être traitée sans toucher à l’autre

branche.

Figure 4: Méthodologie 2TUP

Ce processus commence par une étude préliminaire qui permet d’identifier les acteurs

du système à mettre en œuvre qui est considéré comme une boite noire tout en présentant les

différents messages entre les utilisateurs et le système et d’élaborer le cahier de charges.

D’après la figure ci-dessus, nous remarquerons que 2TUP est composée essentiellement de

trois étapes :

La branche gauche (fonctionnelle)

Capitalise la connaissance du métier de l’entreprise. Elle constitue généralement un

investissement pour le moyen et long terme. Les fonctions du système d’information sont en

effet indépendantes des technologies utilisées. Cette branche comporte les étapes suivantes :

13


La capture des besoins fonctionnels, qui produit un modèle des besoins

focalisé sur le métier des utilisateurs. Cette étape élimine le risque d’avoir un

système inadapté aux besoins des utilisateurs ;

L’analyse qui consiste à étudier les besoins fonctionnels de manière à obtenir une

idée de ce que va réaliser le système en terme métier.

La banche droite (architecture technique)

Capitalise un savoir-faire technique. Elle constitue un investissement pour le court et

moyen terme. Les techniques développées pour le système peuvent l’être en effet

indépendamment des fonctions à réaliser. Cette branche comporte les étapes suivantes :

La capture des besoins techniques ;

La conception générique.

La branche du milieu (réalisation)

A l’issue des évolutions du modèle fonctionnel et de l’architecture technique, la

réalisation du système consiste à fusionner les résultats des deux branches. Cette fusion

conduit à l’obtention d’un processus en forme Y. Cette branche comporte les étapes

suivantes :

La conception préliminaire ;

La conception détaillée ;

Le codage ;

L’intégration.

Conclusion

Dans ce chapitre, il a été question de présenter l’organisme d’accueil ESPRITEC. Nous

avons également procédé à 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 dernières. Une analyse de

la méthodologie de développement à mettre en œuvre est venue finalement mettre un terme à

cette première partie.

Le chapitre suivant est consacré à l’analyse et la spécification des besoins du projet qui

présente la première étape du processus de développement 2TUP.

14


Chapitre 2 :

ANALYSE ET SPECIFICATION DES

BESOINS

15


Introduction

Après l’étude et l’analyse de l’état de l’art, il est temps à présent de se focaliser sur une

analyse des besoins de notre application de gestion de parc informatique. Il sera question de

présenter dans un premier temps les principaux acteurs et leurs rôles. Ensuite dans la branche

fonctionnelle, nous allons définir les besoins fonctionnels et non fonctionnels, puis présenter

le diagramme de cas d’utilisation du système et décrire les différents cas d’utilisation.

Finalement nous clôturons ce chapitre sur la deuxième branche de la méthodologie à savoir la

branche technique, d’où seront listés également les principaux besoins.

I- Contexte Statique

C’est l’étape initiale qui consiste à faire un recensement sur les différents acteurs qui vont

interagir de près ou de loin avec le système. Mais avant d’aller plus loin, il est important de

définir au préalable certains termes importants pour la suite.

Acteur : Constitue une entité physique capable d’interagir avec le système. Notons

juste que cette entité peut être humaine ou matérielle.

Système : C’est l’entité à concevoir, dans notre cas il s’agit de l’application en

elle-même.

Identification des acteurs

Les acteurs se recrutent parmi les utilisateurs du système et aussi parmi les responsables

de la configuration et de la maintenance. Dans notre cas, il y’a trois acteurs principaux :

Administrateur : C’est un super utilisateur ayant le droit d’effectuer toutes sortes

d’opérations telles que la configuration du système, le contrôle des connexions, le

contrôle du suivi des tickets, l’affectation des fournisseurs, budgets, contrats et bien

d’autre.

Technicien : effectue la prise en charge des tickets, reçoit les notifications de la part

de l’administrateur.

Utilisateur : Crée des tickets, reçoit des notifications.

16


La figure ci-dessous illustre parfaitement ces différents acteurs ainsi que leur

interaction avec le système qui se représente sous forme de trait reliant les acteurs concernés

au système.

Figure 5: Diagramme de Contexte Statique

Nous apercevons donc clairement le système de Gestion Libre de Parc Informatique

représenté, ainsi que les différents acteurs. Néanmoins cette représentation est encore

incomplète car le système ainsi représenté constitue une sorte de « boite noire » dont nous ne

connaissons en rien le fonctionnement. Il est donc nécessaire de passer par une représentation

un peu plus détaillée et c’est ce qui fera l’objet de la partie suivante.

II- Branche Fonctionnelle

1. Besoins Fonctionnels

Avant de parler du fonctionnement proprement dit du système, il est nécessaire de

définir dans un premier temps les fonctionnalités qui seront implémentées au sein dudit

système. Ainsi donc, cette étape décrira ce que nous attendons de notre application. Puis, tout

System

Système de Gestion Libre de Parc Informatique

Technicien

Administrateur Utilisateur

17


ceci sera modélisé sous forme de diagramme à l’aide du langage de modélisation

UML, en ce que nous appellerons par la suite cas d’utilisation.

De ce fait, s’il faut redéfinir concrètement les fonctionnalités de notre système, nous pouvons

tout simplement dire que notre application doit être capable de :

a. Module inventaire et Gestion

Afficher l’inventaire des ressources ;

Afficher la map du réseau ;

Gérer les informations financières;

Gérer le module de configuration.

b. Module Helpdesk

Gérer les tickets

Planifier les interventions

Afficher les statistiques des tickets

Afficher les notifications

2. Besoins non fonctionnels

Nous entendons par là les besoins qui caractérisent le système. Autrement dit, il s’agit

de définir un ensemble de critères essentiels pour le bon fonctionnement de notre application.

Il est à noter cependant qu’ils peuvent être exprimés en matière de performance, de type de

matériel ou le type de conception.

Dans le cadre de notre travail, nous pouvons citer par exemple :

Ergonomie : L’interface de l’application doit être simple et utilisable afin que

l’utilisateur puisse l’exploiter sans se référer à des connaissances particulières, en

d’autres termes, notre application doit être lisible et facile à manipuler par n’importe

quel utilisateur ;

Besoins de sécurité : L’application devra assurer la sécurité des utilisateurs. D’où la

nécessité de procéder à l’authentification des agents et administrateurs tout en assurant

la confidentialité de leurs données ;

L’extensibilité : C’est-à-dire qu’il doit y avoir une possibilité d’ajouter de nouvelles

fonctionnalités ou de modifier celles existantes ;

18


Rapidité et intégrabilité dans d’autres applications : L’application devra

être rapide et assure que les modules seront intégrables et utilisables dans d’autres

applications ;

Besoins de haute disponibilité : Au final il est important que notre application puisse

fonctionner sur une plateforme hautement disponible et pouvant gérer un nombre

élevé de requêtes.

3. Besoins Optionnels

Il est question ici d’enrichir le système de fonctionnalités qui pourraient répondre aux

besoins des utilisateurs afin de le rendre encore plus agréable à utiliser. Sans toutefois

tendre vers le superflu, nous pourrions par exemple dresser en fonction des acteurs la liste

suivante :

Intégration de l’annuaire AD dans le but d’importer les utilisateurs de l’entreprise

dans le serveur GLPI ;

Intégration d’un serveur de messagerie pour gérer la partie notification avec un

domaine en locale propre à une entreprise et séparé le domaine professionnel du

domaine privée.

Nous venons d’exposer l’ensemble des besoins auxquels doit répondre le système global à

développer, et avons mis le point sue un ensemble des fonctionnalités jugées faisables dans le

cadre de notre projet. Il est désormais possible de migrer vers une autre partie tout aussi

importante qui traitera de façon plus détaillée des fonctionnalités évoquées ci-dessus relatives

à chaque entité.

4. Diagramme de cas d’utilisation

Nous parvenons à une étape clé du processus. C’est elle qui grâce à l’étude réalisée dans

la partie précédente mettra en valeur le rôle de chaque acteur du système ainsi que les

fonctionnalités présentées plus haut.

a. Cas d’utilisation GLPI

Pour assurer la gestion du parc informatique, l’administrateur possède les privilèges

d’effectuer plusieurs configurations afin d’améliorer les performances du système, le rendre

ergonomique transparent et sécuritaire. A titre d’exemple, il possède la permission de gérer

19


les modules de gestion des finances, d’assistance aux utilisateurs (helpdesk),

d’inventaires comme le montre le diagramme ci-dessous :

Figure 6: Diagramme de Cas d’utilisation GLOBAL

La figure ci-dessus représente le diagramme de cas d’utilisation général de notre

système de gestion de parc informatique. Nous y retrouvons comme convenu les acteurs

principaux et leurs rôles. Nous remarquons également les relations d’inclusions qui lient les

différents cas d’utilisations, et qui indiquent simplement que le cas d’utilisation vers lequel ils

tendent devrait être exécuté au préalable.

System

Administrateur

Utilisateur

Gérer les informationns financières

Afficher l'inventaire des ressources

Gérer module configuration

Gérer tickets

Planifier intervations

Afficher les statistiques des tickets

S'authentifier

<<include>>

<<include>>

<<include>>

Technicien

<<include>>

<<include>>

Afficher la map du réseau

<<include>>

20


b. Cas d’utilisation « gérer tickets » pour un administrateur

Figure 7: Diagramme de Cas d’utilisation « Gérer les tickets » pour un administrateur

La figure suivante nous présente de façon plus détaillée le cas d’utilisation « Gérer tickets ».

Nous pouvons donc entrevoir plusieurs fonctions qui servent à construire le cycle de vie d’un

ticket.

System

Gérer tickets

Administrateur

Ajouter des tickets

Envoyer les suivis des tickets

Modifier l'etat des tickets

Associer des intervenants à des tickets

Associer des couts à des tickets

Supprimer des tickets

<<extend>>

<<extend>>

<<extend>>

<<extend>>

<<extend>>

<<extend>>

21


c. Cas d’utilisation « gérer tickets » pour un utilisateur

Sur la figure ci-dessous, nous découvrons la même fonctionnalité mais qui correspond

à l’agent. Lui également aura la possibilité de créer, de modifier et de supprimer des tickets.

Figure 8: Diagramme de Cas d’utilisation « Gérer les tickets » pour un agent

d. Cas d’utilisation « gérer tickets » pour un technicien

Il s’agit ici donner l’état de validation des tickets et d’ajouter des suivis. Les différents

états de validation sont : En attente de validation, Acceptée, Refusée.

Figure 9: Diagramme de Cas d’utilisation « Gérer les tickets » pour un Technicien

System

Utilisateur

Gérer tickets

Créer des tickets

Visualiser les suivis des tickets

Supprimer des tickets

Modifier des tickets

<<extend>>

<<extend>>

<<extend>>

<<extend>>

System

TechnicienAjouter les suivis des tickets

valider les tickets

Associer des solutions à des tickets

Gérer tickets

<<extend>>

<<extend>>

<<extend>>

22


5. Description des cas d’utilisation

Dans cette partie il sera question de donner plus de détails sur les différents cas

d’utilisation présentés ci-dessus. Tous les cas cités ne seront pas présentés uniquement ceux

qui suivent: « S’authentifier », « Planifier interventions », « Afficher statistiques » et « Gérer

finances ».

a. Description du cas d’utilisation : « S’authentifier »

Etapes Description

Résumé Acteurs : Administrateur/Utilisateur/Technicien

Titre : Authentifier Administrateur ou Utilisateur ou Technicien

Description : Le système identifie à ce niveau

l’administrateur/utilisateur /technicien qui veut utiliser le service.

Pré

conditions

L’administrateur/utilisateur/technicien s’est connecté au système

Le système est opérationnel

Scénario

Nominal

L’administrateur/utilisateur/technicien entre ses paramètres de

connexion identifiant et mot de passe

Le système vérifie les informations saisies

Le système affiche la page de profil de

l’administrateur/utilisateur/technicien

Scénario

Alternatif

Les données saisies sont erronées

Post-

conditions

L’administrateur/utilisateur/technicien est sur sa page de profil

Le système attend désormais qu’il exécute une action

Séquencement

alt

administrateur<<Actor>> Système

1 : saisie des paramètres de connexion()

2 : vérification des paramètres()

3 : affiche page de profil()

4 : message d'erreur()

23


Tableau 3: Description du cas d’utilisation « S’authentifier »

Comme dans tout système d’informations utilisé par plusieurs acteurs, il est important pour

assurer la sécurité des données de chaque acteur que chacun passe par une phase

d’authentification. C’est également le cas de notre système où administrateur, utilisateur et

technicien se sont authentifiés avant de pouvoir réaliser une quelconque opération.

b. Description du cas d’utilisation : « Afficher les statistiques des tickets »

Etapes Description

Résumé Acteurs : Administrateur

Titre : Afficher les statistiques des tickets

Description : affiche à l’administrateur le nombre de

tickets ouverts, résolus, en retard et clos.

Pré conditions L’administrateur s’est authentifié

Les tickets ont été crées

L’administrateur accède au menu d’assistance ou helpdesk

Scénario Nominal

L’administrateur clique sur l’onglet « Statistiques »

L’administrateur sélectionne les statistiques à visualiser

Le système renvoi sur sa page des graphes indiquant le

cycle de vie des tickets et la durée moyenne de traitement

des tickets

Scénario Alternatif Le système n’a pas pu afficher les statistiques car aucun

ticket n’a été crée

Post-conditions Les statistiques des tickets sont affichées

Le système attend désormais qu’il exécute une nouvelle

action

24


Séquencement

Tableau 4: Description du cas d’utilisation « Afficher les statistiques des tickets»

Dans le tableau ci-dessus, nous décrivons également les détails du cas d’utilisation « afficher

les statistiques »qui s’accompagne du scénario d’exécution nominal et d’un scénario

alternatif. Nous y retrouvons aussi le séquencement qui indique l’ordre d’exécution des

actions des différents acteurs.

c. Description du cas d’utilisation « Planifier interventions »

Etapes Description


Titre : Planifier interventions

Description : affiche à l’administrateur du système les dates

et les heures libres afin d’affecter des tickets aux techniciens

disponibles.

Pré

conditions

L’administrateur s’est authentifié

Le système a au préalable un ticket en cours de planification

Le système a au préalable un technicien disponible

L’administrateur accède au menu d’assistance ou helpdesk

Gérer les ticketsref


1 : demande l'affichage des statistiques()

2 : affiche les statistiques()

25


Scénario Nominal

L’administrateur clique sur l’onglet « Tickets »

L’administrateur sélectionne le ticket à planifier

L’administrateur affecte la date, l’heure et un technicien à ce

ticket

Le système renvoi sur la page Planning un tableau qui

indique la date, l’heure et le technicien affectés

Scénario Alternatif Le système n’a pas de ticket en cours de planification

Le système ne contient pas de technicien disponible

Post-conditions Le planning des interventions est affiché

Le système attend désormais qu’il exécute une nouvelle

action

Séquencement

Tableau 5: Description du cas d’utilisation « Planifier les interventions »

Le tableau ci-dessus décrit à son tour les détails du cas d’utilisation « Planifier les

intervenants » qui s’accompagne du scénario d’exécution nominal et d’un scénario alternatif.

Nous y retrouvons aussi le séquencement qui indique l’ordre des actions des acteurs.

S'authentifierref


1 : sélectionne 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()

26


d. Description du cas d’utilisation « Gérer les informations

financières »

Etapes Description


Titre : Gérer finances

Description : Associe les fournisseurs, les budgets, les contrats.

Pré

conditions

L’administrateur s’est authentifié

L’administrateur accède au menu de gestion

Scénario

Nominal

L’administrateur clique sur l’onglet « Budget »

L’administrateur crée un budget

L’administrateur clique sur l’onglet « fournisseurs »

L’administrateur crée un fournisseur

L’administrateur clique sur l’onglet « Contrat »

L’administrateur crée un contrat

L’administrateur associe des budgets et des contrats à des fournisseurs

Scénario

Alternatif

Le système n’a pas créé de fournisseur

Le système n’a pas créé de contrat

Le système n’a pas créé de budget

Post-

conditions

La liaison entre les fournisseurs, les contrats et les budgets a été créée

Le système attend désormais qu’il exécute une nouvelle action

27


Séquencement

Tableau 6: Description du cas d’utilisation « Gérer les informations financières »

Après avoir identifié les rôles des acteurs aussi bien que les fonctionnalités du système,

nous pouvons passer à présent à la branche technique qui va se charger de présenter les

besoins techniques indispensable au développement de notre projet.

III- Branche Technique

Les besoins fonctionnels de notre système ayant été définis, 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. C’est ainsi que nous définirons dans cette partie en premier lieu

S'authentifierref

Administrateur<<Actor>> Système

1 : selectionne le menu de gestion()

2 : affiche les éléments du menu()

3 : crée un fournisseur()

4 : enregistre le fournisseur créé()

5 : crée un budget()

6 : enregistre le budget créé()

7 : associe un budget à un fournisseur()

8 : crée un contrat()

9 : enregistre le contrat créé()

10 : associe un contrat à un fournisseur()

28


l’architecture, puis les langages de développement et nous terminerons par les

serveurs utilisés.

1. Architecture

Nous devons savoir qu’il existe plusieurs types d’architectures. Parmi ces

architectures, nous pouvons citer :

a. L’architecture décentralisée

Les données et l’application ne sont pas localisées sur un seul serveur. Une telle

architecture permet de résister à des attaques puisse que le logiciel client ne se connecte pas à

un unique serveur mais à plusieurs. Le système est ainsi plus robuste mais la recherche

d’informations est plus difficile.

b. L’architecture client-serveur

L’application est subdivisée entre deux entités client et serveur qui coopèrent

ensemble via des requêtes. Le dialogue entre les deux entités peut se résumer par :

Le client demande un service au serveur

Le serveur réalise ce service et renvoie le résultat au client

Nous distinguons trois types d’architectures client-serveur :

Architecture 2-tiers

Une architecture 2-tiers est composée de deux éléments, un client et un serveur et où le

tiers fait référence non pas à une entité physique mais logique. Une analyse détaillée des

éléments de cette architecture et de leurs fonctions attachées met en évidence certains points

essentiels sur lesquels nous attirons l’attention :

La fonction de présentation est à la charge du client exclusivement.

Le calcul (processing) est reparti entre le client et le serveur.

Le logiciel client est généralement spécifique au serveur.

Les données sont stockées ou accessibles via un le serveur. Dans le cadre d’une

topologie d’accès à une base de données, le serveur traitera les requêtes en

provenance du client qui se feront en général en langage SQL.

C’est parce que le client assume des tâches de présentation et de processing, et donc de fait

communique avec le serveur sans intervention d’un autre processus que le client est dit

29


« lourd » par opposition à l’architecture 3-tiers où le client est constitué d’un

simple navigateur internet et communique avec un serveur via un frontal.

En définitive et dans la perspective d’une architecture 2-tiers avec un serveur de base de

données (SGBD) nous obtenons le schéma suivant :

Figure 10: Schéma architecture 2-tiers

Avantages :

Développement rapide toute chose étant égale par ailleurs à la complexité du

projet.

Outils de développement robustes

Inconvénients :

Problèmes de contrôle des évolutions de versions et de redistribution des

applications.

En termes de sécurité l’architecture 2-tiers peut être complexe dans la mesure

où il sera nécessaire à l’utilisateur d’avoir autant d’accès protégés par un mot de passe

que d’accès serveurs.

Client Réseau Serveur de BD

Base de données

30


Architecture 3-tiers

L’architecture 3-tiers est composée de trois éléments, ou plus précisément de trois

couches. En effet, dans la philosophie qui a guidé l’élaboration de cette architecture, il est

adéquat de parler de couche fonctionnelle attachée à un élément/entité logique. Il faut

distinguer trois couches/éléments :

La couche présentation : associée au client qui de fait est dit « léger » dans

la mesure où il n’assume aucune fonction de traitement à la différence du

modèle 2-tiers.

La couche fonctionnelle : liée au serveur, qui dans de nombreux cas est un

serveur Web muni d’extensions applicatives. C’est ce dernier qui va exécuter

tous les calculs ou faire des requêtes vers d’autres serveurs additionnels

(exemple vers des SGBD).

La couche de données : liée au serveur de base de données (SGBD).

Enfin le schéma suivant illustre une architecture souvent rencontrée avec un serveur Web.

Figure 11: Schéma architecture 3-tiers

Client

léger

Navigateu

r

Réseau

Serveur

WEB

Server

Extension

Program

Réseau

Database

Serveur

Base de données

31


Avantages :

Requêtes plus flexibles au niveau du client.

La séparation qui existe entre le client et le serveur et le SGBD permet une

spécialisation des développeurs sur chaque tiers l’architecture.

Plus de flexibilité dans l’allocation des ressources

Inconvénients :

Une expertise de développement à acquérir qui semble plus longue que dans le

cadre d’une architecture 2-tiers.

Coût de développement plus élevé.

Architecture n-tiers

L’architecture n-tiers a été pensée pour pallier aux limitations des architectures trois tiers

et concevoir des applications puissantes et simples à maintenir. En fait, l’architecture n-

tiers qualifie la distribution d’application entre de multiples services et non la

multiplication des niveaux de services.

Avantages :

Ajout de composants

Meilleures performances

Fiabilité accrue

Sécurité

Flexibilité

Maintenance

Inconvénients :

Gestion de la complexité du système global

Gestion de la communication entre composants

Gestion de l’hétérogénéité des outils et systèmes [6]

32


Choix de l’architecture utilisée

Suite à l’étude qui vient d’être faite, notre choix s’est porté sur l’architecture client-

serveur et plus précisément sur l’architecture n-tiers pour les raisons suivantes :

Elle correspond le mieux à la structure attendue dans le sens où notre système

constituera en quelque sorte le serveur et les autres acteurs seront les clients.

Deuxièmement, vu que nous avons besoin d’un client léger qui n’aura qu’à se

connecter au serveur, il nous a donc paru évident d’opter pour une architecture

plus évoluée que l’architecture 2-tiers.

Finalement, bien que l’architecture 3-tiers soit adéquate, elle possède

néanmoins des limites qui sont corrigées dans la structure n-tiers qui rappelons-

le est plus flexible, plus souple et plus puissante.

2. Langages de développement

a. PHP

Le PHP est un langage de programmation qui s’intègre dans vos pages HTML. Il est

permet entre autre de rendre automatiques des tâches répétitives, notamment grâce à la

communication avec une base de données. [7]

b. PERL

PERL est un langage de programmation utilisé pour le développement de scripts

d’administration système sous UNIX. [8]

3. Serveurs

Comme le stipule l’architecture n-tiers, nous aurons besoin au minimum d’un serveur web

et d’un serveur de base de données.

a. Serveur de base de données

Comme serveur de base de données, nous avons choisi d’utiliser MYSQL tout

&simplement parce qu’il offre les avantages suivants :

Rapidité

33


Facilité d’utilisation

Gratuit

Connexion et sécurité

Portabilité

b. Serveur web

Nous avons choisi d’utiliser le serveur Apache pour les raisons suivantes :

Il peut fonctionner sur une variété de systèmes d’exploitation.

Son architecture modulaire se prête à la personnalisation lorsqu’il est nécessaire de

construire une configuration de serveur aux besoins d’un client.

Extensible : Il est en constante évolution.

C’est gratuit, fiable et facile à configurer.

c. Serveur de messagerie

Le serveur de messagerie nous a permis de gérer la partie notification par mail.

Conclusion

En conclusion, nous avons spécifié les différents besoins auxquels doit répondre notre

système. Ce chapitre nous a été utile pour montrer notre but, nos besoins et éclaircir notre

démarche. Il nous a offert une vision plus ou moins détaillée sur le but même du projet, et une

meilleure distinction entre les éléments constitutifs du système.

Enfin, il nous reste à élaborer une bonne conception afin d’assurer le bon

fonctionnement du système. C’est ainsi que nous pourrons entamer le prochain chapitre sur la

conception à pas sûrs.

34


CHAPITRE 3 :

CONCEPTION

35


Introduction

L’étape de conception définit généralement les structures et les modèles à suivre lors de la

phase d’implémentation de l’application. C’est la phase où nous préparons l’architecture du

projet, et où nous définissons la structure de l’application. Par souci de clarté, nous débuterons

par une phase préliminaire où sera présentée l’architecture du système à mettre en place.

Ensuite, nous poursuivrons par une étude dynamique qui illustrera le processus de

fonctionnement du dit système.

I- Architecture du système

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

C’est donc à ce niveau que seront définis l’architecture du système.

Figure 12: Architecture du système

Les agents FusionInventory sont installés sur les machines du parc informatique.

36


Le plugin FusionInventory intégré dans le serveur GLPI permet de donner des

informations sur des ressources physiques se trouvant dans le réseau du parc.

La communication entre l’agent et le serveur se fait via le protocole http ou https. En cas

d’absence d’un agent, les équipements dans le réseau communiquent directement avec le

serveur via le protocole SNMP. Les données de l’inventaire sont stockées dans la base de

données de GLPI.

Le serveur GLPI effectue une synchronisation avec le plugin FusionInventory dans le but

d’avoir des remontées automatisées des informations venant du parc.

Ce serveur effectue également une synchronisation avec Active Directory afin que chaque

acteur à travers son compte Active Directory puisse accéder à l’interface graphique de GLPI

et s’authentifier en tant qu’utilisateur, technicien ou administrateur.

La synchronisation des serveurs GLPI et de messagerie permet d’avoir un suivi de la gestion

des tickets sur sa boite mail.

L’administrateur exécute les opérations de suivi des tickets soit à travers son ordinateur ou

son smartphone.

Le plugin Webservice intégré dans le serveur GLPI a pour rôle de faire communiquer celui-ci

avec des applications externes à partir du protocole XML-RPC.

II- Etude Dynamique

L’étude dynamique permet de représenter le comportement dynamique du système. En

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

Diagramme d’activité

Nous allons ici évoquer le diagramme comportemental d'UML, permettant de

représenter le déclenchement d'événements en fonction des états du système et de modéliser

des comportements parallèles (multi-threads ou multi-processus).

Ce diagramme est une représentation proche de l'organigramme. Le but ici est de décrire en

détail le processus général de la gestion des tickets de sorte qu’elle soit facile à comprendre et

simple à utiliser.

37


Figure 13: Diagramme d’activité Cycle de vie d’un ticket

38


Conclusion

En conclusion, ce chapitre nous a permis de mettre en avant les phases nécessaires à la

réalisation de notre application à savoir : L’architecture, les composants du système et les

diagrammes de conception.

A cette étape, il devient possible de passer au chapitre suivant où nous allons parler de

l’environnement de travail utilisé pour l’implémentation de la solution adoptée et décrire la

démarche de la réalisation.

39


CHAPITRE 4 :

REALISATION

40


Introduction

Nous avons tout au long des chapitres précédents introduit le projet, énuméré les

étapes nécessaires à sa mise en œuvre, analysé l’ensemble des besoins à satisfaire et conçu

l’architecture du système. A présent, nous entamerons la phase de réalisation qui est l’étape

où nous traduisons la conception et les règles par un langage de programmation afin d’aboutir

à une automatisation des besoins tels qu’ils ont été défini dans la spécification.

Ainsi donc, ce chapitre sera divisé en quatre parties majeures. Premièrement, nous allons

commencer par une description de l’environnement de travail à savoir l’environnement

logiciel et l’environnement matériel. Ensuite nous énumèrerons les difficultés rencontrées

pendant la réalisation de ce projet, puis suivra la présentation des résultats obtenus, et enfin

nous terminerons par la présentation du chronogramme du projet.

I- Environnement de travail

1. Environnement matériel

Nous avons utilisé pour les besoins de ce projet un ordinateur portable SAMSUNG

RV509 caractérisé par :

Un système d’exploitation Windows 7 (32 bits) ;

Un processeur Intel® Pentium ® CPU;

Une mémoire RAM de 3,00 Go ;

Un disque dur de 300 Go.

2. Environnement logiciel

VMware ;

Centos 6.5 ;

Windows server 2003 ;

StarUml ;

Smartdraw : C’est un logiciel de dessin. Nous allons utiliser pour réaliser

l’architecture de notre application ainsi que le diagramme d’activité ;

Eclipse Juno ;

Serveur de messagerie.

41


II- Difficultés Rencontrées

En termes de difficultés, nous avons fait face à des problèmes qui peuvent se regrouper en

plusieurs catégories : l’installation, l’analyse, l’inventaire, la connectivité.

1. Installation

L’installation du serveur GLPI n’a pas été aisée. Il nous a fallu gérer les problèmes de

dépendances. C’est ainsi que nous avions d’abord installés des archives de paquets (RPM)

compatibles avec notre système d’exploitation d’une part et d’autre part compatible avec la

version de GLPI choisie avant de commencer l’installation proprement dite de GLPI.

2. Analyse

Une étude Théorique et pratique a été faite sur les outils OCSInventory NG et

FusionInventory afin de sélectionner la technologie utilisée concernant la partie inventaire.

3. Inventaire

Pour effectuer la remontée des informations des machines agents, il a fallu faire et

refaire plusieurs tests. A travers ces tests, nous avons retenu :

La remontée est effective si et seulement si la version de l’agent fusion

installé est inférieure ou égale à celle du serveur fusion ;

L’inventaire au niveau des machines virtuelles est fonctionnel lorsque l’on

édite une nouvelle règle sur le serveur GLPI permettant de récupérer les

informations de l’agent via son tag.

4. Connectivité

D’une part la connectivité entre GLPI et les autres serveurs, d’autre part la

connectivité entre l’émulateur, l’environnement de développement et GLPI.

Pour résoudre ces problèmes nous avons utilisé PFsense, ce qui a permis de connecter GLPI

aux différents serveurs suivant une architecture de LAN-WAN-DMZ, ensuite nous avons

installé l’émulateur Android sur une machine virtuelle afin de lui affecter une carte réseau lui

permettant de se connecter avec l’environnement de développement ainsi que GLPI.

Toutes ces phases ne constituent en fait qu’une partie de toutes les phases de réalisations

énoncées dans ce rapport. Une vue complète de l’ensemble de ces tâches et du temps qui a été

alloué fait l’objet de la partie suivante.

42


III- Chronogramme d’avancement du projet

La figure ci-dessous présente le chronogramme d’avancement du projet.

Figure 14: Chronogramme d’avancement du projet

Chaque branche de cette figure représente la durée d’une tâche. Les tâches réalisées tout au

long de ce projet sont répertoriées sur la figure suivante.

Figure 15: Présentation des tâches

43


De cette figure, nous pouvons tirer plusieurs informations mais les plus pertinentes sont les

suivantes :

Durée du projet : Le projet a débuté au mois de février 2014 et s’est achevé en

Juillet 2014 Ce qui nous fait environ cinq mois qui sont découpés suivant le

chronogramme ci-dessus.

Il comprend cinq (07) phases principales qui sont : l’élaboration du sujet, l’analyse

des besoins fonctionnels et techniques, l’installation de GLPI, la maitrise des

menus GLPI (la partie Helpdesk y compris), le développement (GOATS), la

validation des fonctionnalités et finalement la rédaction du rapport.

IV- Présentation des interfaces

1. Interface d’authentification

Figure 16: Interface d’authentification

La figure ci-dessus représente l’interface d’authentification de notre application. Seul les

utilisateurs internes (administrateur, technicien, utilisateur normal) et les utilisateurs externes

c’est-à-dire ceux ayant un compte dans Active Directory peuvent y accéder.

44


2. Interface parc ordinateur

Figure 17: Interface parc ordinateur

Après avoir installé les agents FusionInventory sur les machines, une remontée des

informations (ordinateur, logiciel,…) est faite au niveau de notre serveur GLPI. Nous

pouvons aussi effectuer un inventaire manuel. C’est 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 l’éditeur, la version, le nombre

d’installation et le nombre de licence de chaque logiciel inventorié. Dans notre cas, le nom

des systèmes d’exploitation ne sont pas visibles car tous sont traqués.

45


4. Interfaces de découverte du réseau

Avant d’exécuter une découverte du réseau, d’autres préalables sont indispensables,

dont :

La définition des plages IP sur lesquelles l’agent FusionInventory va opérer ;

L’ajout d’une tâche et l’association de celle-ci à un agent et une plage IP.

Figure 19: Interface découverte du réseau

A partir de cette découverte du réseau, nous avons récupérer les informations sur les

imprimantes, les moniteurs, les switchs ainsi que les réseaux directement connectés à notre

pc. [9]

46


a. Interface parc imprimante

Figure 20: Interface parc imprimante

b. Interface parc périphérique

Figure 21: Interface parc périphérique

47


c. Interface réseau IP

Figure 22: Interface Réseau IP

5. Interfaces pour la gestion des tickets

Scénario

Un utilisateur a un problème avec son ordinateur, son clavier USB ne marche pas. Il

envoie une demande de tickets : le ticket passe à l’état nouveau.

L’administrateur reçoit la demande : le ticket passe de l’état nouveau à l’état attente

d’affectation. Ensuite, l’administrateur attribue le ticket à un technicien et planifie celui-ci en

fonction de son emploi de temps. Le ticket passe de l’état en attente à l’état en cours planifié.

Le jour J le technicien va installer un nouveau clavier USB sur ce pc. Il établit le cout du

matériel acheté, le cout de sa main d’œuvre et les affecte à ce ticket. Le problème étant résolu,

le technicien fait passer le ticket de l’état en cours à l’état résolu et envoi un suivi à

l’administrateur.

L’administrateur vérifie alors les comptes et clos le ticket.

48


a. Création d’un ticket

Figure 23: Interface de création d’un ticket

b. Création d’un problème

Figure 24: Interface de création d’un problème

49


c. Association d’un problème à un ticket

Figure 25: Interface association d’un problème à un ticket

d. Changement de l’état d’un ticket

Figure 26: Interface de Changement de l’état d’un ticket

e. Planification pour une intervention

50


Figure 27: Interface de planification des interventions

f. Association d’un ticket à un budget

Figure 28: Interface d’association d’un ticket à un budget

51


g. Affichage des statistiques des tickets

Figure 29: Interface d’affichage des statistiques des tickets

6. Interface pour les notifications par mail

Figure 30: Interface de test des notifications mails

52


Figure 31: Interface de notification mail

7. Interface Intégration AD

Figure 32: Interface intégration AD sur GLPI

53


V- Présentation de la partie mobile

GLPI offre un suivi mobile de la gestion des tickets, mais à partir des versions supérieures

ou égales à la version 0.80.X, cette fonctionnalité n’est pas intégrée car elle est encore en

cours de développement. C’est pourquoi nous avons trouvé utile de développer une partie

mobile. Cette partie consistera à :

Afficher la liste des nouveaux tickets ;

Afficher leurs informations de bases (date de création, affectation des acteurs…) ;

Clôturer 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 d’adresses IPv4 correspond à l’adresse ip de notre émulateur.

54


2. Interface de l’application mobile GOATS [10]

Figure 34: Interface Application GOATS

55


Lors du démarrage, une interface d’authentification s’ouvre dans laquelle nous devons

entrer l’adresse ip du serveur GLPI ainsi que le nom du compte administrateur et son mot de

passe. Après l’authentification, une liste de nouveaux tickets s’affiche sur l’écran. En cliquant

sur le nom de l’un 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 l’objectif principal était de présenter le

produit final obtenu. A cet effet, nous avons tour à tour présentés les outils matériels et

logiciels utilisés d’une part, puis nous avons décrit les difficultés rencontrées, qui ont été suivi

du chronogramme d’avancement et de la présentation des interfaces de notre système.

56


Ce document a été rédigé au terme du projet de fin d’études réalisé au sein

d’ESPRITEC.

Il s’agissait en effet de développer une application de « Outil de gestion de parc

informatique et de Helpdesk », qui devrait booster la gestion des ressources des entreprises.

La première phase de ce rapport était consacrée à la présentation de l’état de l’art, et nous

avons présenté l’organisme d’accueil, ainsi que le projet proprement dit. Ces deux parties ont

été suivies d’une analyse sur les applications existantes et leurs limites, ce qui nous a permis

de poser la première pierre de l’édifice en proposant notre propre solution.

La deuxième phase quant à elle consistait à dégager les besoins fonctionnels, non

fonctionnels de l’application, et par la même occasion les besoins techniques suivant la

méthodologie de développement 2TUP. Cela nous permettait par la suite de réaliser les

diagrammes de cas d’utilisation qui nous serviraient dans la phase de conception.

La phase de conception nous a permis d’entrer plus en profondeur dans l’analyse et de

parler de l’architecture de l’application. Par la suite il a fallu décrire le système à l’état

statique et dynamique. Ce que nous avons fait par l’entremise des diagrammes de classes et

d’activités.

CONCLUSION GENERALE

57


Enfin dans la phase de réalisation nous avons présenté les outils et technologies

utilisés pour réaliser ce travail. Puis nous nous sommes attardés sur les difficultés rencontrées,

le chronogramme d’avancement du projet et les interfaces de notre système.

Au final donc, il est important de souligner que ce projet a atteint les objectifs fixés au

départ, et au-delà du sentiment de satisfaction qui s’en suit, il nous a permis de bénéficier de

nouvelles connaissances venues compléter celles que nous avons acquises tout au long de

notre formation.

Cependant, nous pouvons toujours y apporter quelques améliorations 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 intégrer 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.

58


WEBOGRAPHIE

[1] : Site officiel d’ESPRIT http://www.esprit.ens.tn/test/v3/index.php?lang=fr , dernière visite

le 03/06/2014 (Page 4)

[2] : Site officiel de clarilog http://www.clarilog.com/FR/solutions/demonstrations-

fonctionnelles.html , dernière visite le 05/06/2014 (Page 6)

[3] : Site LINUXFR.ORG http://linuxfr.org/news/h-inventory-un-nouvel-asset-manager-

opensource--2 , dernière visite le 05/06/2014 (Page 6)

[4] : Site officiel de Spiceworks http://www.spiceworks.com/ , dernière visite le 05/06/2014

(Page 7)

[5] : Installation de GLPI http://smnet.fr/ocsglpi/ocs-glpi-intro.html , dernière visite le

21/04/2014 (Page 8)

[6] : Architecture client-serveur http://mrproof.blogspot.com/2011/03/larchitecture-client-

serveur.html , dernière visite le 09/06/2014 (Page 31)

[7] : Gestion des dépendances http://dl.fedoraproject.org/pub/epel/6/i386/ , dernière visite

15/04/2014 (Page 32)

[8] : Installation de l’agent Fusion sur Linux

http://wiki.kogite.fr/index.php/Installation_de_l'agent_fusioninventory , dernière visite le

23/04/2014 (Page 32)

[9] : Découverte du réseau http://www.prestaopen.com/gestion-de-parc-glpi/decouverte-

snmp.html , dernière visite 07/06/2014 (Page 45)

[10] : Installation de l’émulateur Android sur une machine virtuelle

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

le 01/07/2014 (Page 54)

http://www.esprit.ens.tn/test/v3/index.php?lang=fr

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

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

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

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

http://www.spiceworks.com/

http://smnet.fr/ocsglpi/ocs-glpi-intro.html

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

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

http://dl.fedoraproject.org/pub/epel/6/i386/

http://wiki.kogite.fr/index.php/Installation_de_l'agent_fusioninventory

http://www.prestaopen.com/gestion-de-parc-glpi/decouverte-snmp.html

http://www.prestaopen.com/gestion-de-parc-glpi/decouverte-snmp.html

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

59


RESUME

Aujourd’hui bien gérer son parc informatique

pour une entreprise est devenu indispensable.

Bien gérer son parc informatique c’est aussi bien

gérer le capital informatique de la société et ainsi

réduire les coûts, satisfaire les utilisateurs,

optimiser les ressources internes, imposer une

certaine démarche qualité.

GLPI est la solution Open Source de référence

dans la gestion de parc informatique et de

Helpdesk. Elle se présente comme une

application Full Web qui gère l’ensemble de vos

problématiques de gestion de parc informatique :

de la gestion de l’inventaire des composantes

matérielles ou logicielles d’un parc informatique

à la gestion de l’assistance 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

IT asset management: managing the inventory of

hardware and software components of a computer

park management assistance to users.

Engineering

Rapport PFE: Gestion de Parc Informatique