SlideShare une entreprise Scribd logo
1  sur  71
Télécharger pour lire hors ligne
iRé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
iiRéalisé par Éric OBONO
Signatures
Signature de l’encadrant pédagogique
Signature du département des langues
iiiRé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.
ivRé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.
vRé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.
viRé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
*
viiRé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
*
viiiRé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
*
ixRé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
xRé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
xiRé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
xiiRé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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
Chapitre 1:
ETAT DE L’ART
4
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
 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
Réalisé par Éric OBONO
Chapitre 2:
ANALYSE ET
SPECIFICATION DES
BESOINS
15
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
 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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Technicien
Ajouter les suivis des tickets
valider les tickets
Associer des solutions à des tickets
Gérer tickets
<<extend>>
<<extend>>
<<extend>>
22
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Résumé  Acteurs : Administrateur
 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
administrateur
<<Actor>> Système
1 : demande l'affichage des statistiques()
2 : affiche les statistiques()
25
Réalisé par Éric OBONO
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
administrateur
<<Actor>> Système
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
Réalisé par Éric OBONO
d. Description du cas d’utilisation « Gérer les informations
financières »
Etapes Description
Résumé  Acteurs : Administrateur
 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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
« 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
Réalisé par Éric OBONO
 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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
 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
Réalisé par Éric OBONO
 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
Réalisé par Éric OBONO
CHAPITRE 3 :
CONCEPTION
35
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
Figure 13: Diagramme d’activité Cycle de vie d’un ticket
38
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
CHAPITRE 4:
REALISATION
40
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
a. Interface parc imprimante
Figure 20: Interface parc imprimante
b. Interface parc périphérique
Figure 21: Interface parc périphérique
47
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
Figure 31: Interface de notification mail
7. Interface Intégration AD
Figure 32: Interface intégration AD sur GLPI
53
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
2. Interface de l’application mobile GOATS [10]
Figure 34: Interface Application GOATS
55
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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
Réalisé par Éric OBONO
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)
59
Réalisé par Éric OBONO
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

Contenu connexe

Tendances

Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Ahmed Makni
 
Rapport de stage d'été
Rapport de stage d'étéRapport de stage d'été
Rapport de stage d'étéJinenAbdelhak
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Sofien Benrhouma
 
Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique ayoub daoudi
 
Rapport de stage développement informatique
Rapport de stage développement informatique Rapport de stage développement informatique
Rapport de stage développement informatique MehdiOuqas
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITLina Meddeb
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Riadh K.
 
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
Projet de fin étude  ( LFIG : Conception et Développement d'une application W...Projet de fin étude  ( LFIG : Conception et Développement d'une application W...
Projet de fin étude ( LFIG : Conception et Développement d'une application W...Ramzi Noumairi
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRouâa Ben Hammouda
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSFaissoilMkavavo
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaNazih Heni
 
Rapport de projet de fin d'année
Rapport de projet de fin d'année Rapport de projet de fin d'année
Rapport de projet de fin d'année kaies Labiedh
 
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCGhodbane Heni
 
Rapport projet c : Logiciel de gestion des ressources humaines
Rapport projet c : Logiciel de gestion des ressources humainesRapport projet c : Logiciel de gestion des ressources humaines
Rapport projet c : Logiciel de gestion des ressources humainesHosni Mansour
 
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...Madjid Meddah
 
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)Yasmine Tounsi
 
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Anas Riahi
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachAyoub Mkharbach
 
Mémoire de fin d'études. Modules: SI Helpdesk , Gestion Park informatique , B...
Mémoire de fin d'études. Modules: SI Helpdesk , Gestion Park informatique , B...Mémoire de fin d'études. Modules: SI Helpdesk , Gestion Park informatique , B...
Mémoire de fin d'études. Modules: SI Helpdesk , Gestion Park informatique , B...Abderrahmane Belhimer
 

Tendances (20)

Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...
 
Rapport de stage d'été
Rapport de stage d'étéRapport de stage d'été
Rapport de stage d'été
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 
Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique
 
Rapport de stage développement informatique
Rapport de stage développement informatique Rapport de stage développement informatique
Rapport de stage développement informatique
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
 
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
Projet de fin étude  ( LFIG : Conception et Développement d'une application W...Projet de fin étude  ( LFIG : Conception et Développement d'une application W...
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédia
 
Rapport de projet de fin d'année
Rapport de projet de fin d'année Rapport de projet de fin d'année
Rapport de projet de fin d'année
 
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
 
Rapport projet c : Logiciel de gestion des ressources humaines
Rapport projet c : Logiciel de gestion des ressources humainesRapport projet c : Logiciel de gestion des ressources humaines
Rapport projet c : Logiciel de gestion des ressources humaines
 
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
 
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
 
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
 
Mémoire de fin d'études. Modules: SI Helpdesk , Gestion Park informatique , B...
Mémoire de fin d'études. Modules: SI Helpdesk , Gestion Park informatique , B...Mémoire de fin d'études. Modules: SI Helpdesk , Gestion Park informatique , B...
Mémoire de fin d'études. Modules: SI Helpdesk , Gestion Park informatique , B...
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
 

Similaire à Rapport PFE: Gestion de Parc Informatique

BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdf
BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdfBAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdf
BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdfBayeOusseynouFall
 
Stage de Perfectonnement Génie Electrique (1) mm 24
Stage de Perfectonnement Génie Electrique (1) mm 24Stage de Perfectonnement Génie Electrique (1) mm 24
Stage de Perfectonnement Génie Electrique (1) mm 24DhaouiMastour
 
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...Alexis Legrand
 
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)zakia saadaoui
 
Rapport version finale kouakou aboua pokou alexis
Rapport version finale kouakou aboua pokou alexis Rapport version finale kouakou aboua pokou alexis
Rapport version finale kouakou aboua pokou alexis abouaalexis
 
Support de présentation EECS
Support de présentation EECSSupport de présentation EECS
Support de présentation EECSGroupe EEIE
 
MEMOIR FIN D'ETUDE STATION DE POMPAGE.docx
MEMOIR FIN D'ETUDE  STATION DE POMPAGE.docxMEMOIR FIN D'ETUDE  STATION DE POMPAGE.docx
MEMOIR FIN D'ETUDE STATION DE POMPAGE.docxSimoFbmc
 
Etude et mise en place d’un Cloud privé Avec Openstack
Etude et mise en place d’un Cloud privé Avec OpenstackEtude et mise en place d’un Cloud privé Avec Openstack
Etude et mise en place d’un Cloud privé Avec OpenstackBayeOusseynouFall
 
portail_captif.pdf
portail_captif.pdfportail_captif.pdf
portail_captif.pdfnabila201151
 
Projet stage : Mise en place d'un système générique de sauvegarde et de rest...
Projet stage : Mise en place d'un système générique  de sauvegarde et de rest...Projet stage : Mise en place d'un système générique  de sauvegarde et de rest...
Projet stage : Mise en place d'un système générique de sauvegarde et de rest...Gedeon AGOTSI
 
Memoire finale
Memoire finaleMemoire finale
Memoire finalegoogang
 
Rapport PFE 2011 Zimbra
Rapport PFE 2011 ZimbraRapport PFE 2011 Zimbra
Rapport PFE 2011 ZimbraAyoub Kochbati
 
Le dessous des cartes agiles de la transformation numérique de France Télé...
Le dessous des cartes agiles de la transformation numérique de France Télé...Le dessous des cartes agiles de la transformation numérique de France Télé...
Le dessous des cartes agiles de la transformation numérique de France Télé...Alain Buzzacaro
 
Étude et Mise en Place de Monitoring
Étude et Mise en Place de Monitoring Étude et Mise en Place de Monitoring
Étude et Mise en Place de Monitoring ImnaTech
 

Similaire à Rapport PFE: Gestion de Parc Informatique (20)

Rapport de stage bts
Rapport de stage btsRapport de stage bts
Rapport de stage bts
 
BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdf
BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdfBAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdf
BAYE_O_FALL-SAIDOU_MBODJI-LabUT.pdf
 
Stage de Perfectonnement Génie Electrique (1) mm 24
Stage de Perfectonnement Génie Electrique (1) mm 24Stage de Perfectonnement Génie Electrique (1) mm 24
Stage de Perfectonnement Génie Electrique (1) mm 24
 
Research master's thesis
Research master's thesisResearch master's thesis
Research master's thesis
 
Memoire complet.pdf
Memoire complet.pdfMemoire complet.pdf
Memoire complet.pdf
 
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
 
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
 
Rapport de stage Ingelec
Rapport de stage IngelecRapport de stage Ingelec
Rapport de stage Ingelec
 
Rapport version finale kouakou aboua pokou alexis
Rapport version finale kouakou aboua pokou alexis Rapport version finale kouakou aboua pokou alexis
Rapport version finale kouakou aboua pokou alexis
 
Support de présentation EECS
Support de présentation EECSSupport de présentation EECS
Support de présentation EECS
 
MEMOIR FIN D'ETUDE STATION DE POMPAGE.docx
MEMOIR FIN D'ETUDE  STATION DE POMPAGE.docxMEMOIR FIN D'ETUDE  STATION DE POMPAGE.docx
MEMOIR FIN D'ETUDE STATION DE POMPAGE.docx
 
Etude et mise en place d’un Cloud privé Avec Openstack
Etude et mise en place d’un Cloud privé Avec OpenstackEtude et mise en place d’un Cloud privé Avec Openstack
Etude et mise en place d’un Cloud privé Avec Openstack
 
portail_captif.pdf
portail_captif.pdfportail_captif.pdf
portail_captif.pdf
 
ERP Universitaire
ERP UniversitaireERP Universitaire
ERP Universitaire
 
Projet stage : Mise en place d'un système générique de sauvegarde et de rest...
Projet stage : Mise en place d'un système générique  de sauvegarde et de rest...Projet stage : Mise en place d'un système générique  de sauvegarde et de rest...
Projet stage : Mise en place d'un système générique de sauvegarde et de rest...
 
Memoire finale
Memoire finaleMemoire finale
Memoire finale
 
Rapport PFE 2011 Zimbra
Rapport PFE 2011 ZimbraRapport PFE 2011 Zimbra
Rapport PFE 2011 Zimbra
 
Rapport finiale
Rapport finialeRapport finiale
Rapport finiale
 
Le dessous des cartes agiles de la transformation numérique de France Télé...
Le dessous des cartes agiles de la transformation numérique de France Télé...Le dessous des cartes agiles de la transformation numérique de France Télé...
Le dessous des cartes agiles de la transformation numérique de France Télé...
 
Étude et Mise en Place de Monitoring
Étude et Mise en Place de Monitoring Étude et Mise en Place de Monitoring
Étude et Mise en Place de Monitoring
 

Dernier

Chapitre 2 : fondations et analyses de données géotechniques
Chapitre 2 : fondations et analyses de données géotechniquesChapitre 2 : fondations et analyses de données géotechniques
Chapitre 2 : fondations et analyses de données géotechniquesangevaleryn
 
BOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcinBOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcinidelewebmestre
 
BOW 2024 - Dedans/Dehors quand voir ne suffit pas
BOW 2024 - Dedans/Dehors quand voir ne suffit pasBOW 2024 - Dedans/Dehors quand voir ne suffit pas
BOW 2024 - Dedans/Dehors quand voir ne suffit pasidelewebmestre
 
Support de cours La technologie WDM.pptx
Support de cours La technologie WDM.pptxSupport de cours La technologie WDM.pptx
Support de cours La technologie WDM.pptxdocteurgyneco1
 
BOW 2024 - 3 1 - Les infrastructures équestres et le changement climatique
BOW 2024 - 3 1 - Les infrastructures équestres et le changement climatiqueBOW 2024 - 3 1 - Les infrastructures équestres et le changement climatique
BOW 2024 - 3 1 - Les infrastructures équestres et le changement climatiqueidelewebmestre
 
Compersseur d'air a vis atlas copco avec huile
Compersseur d'air a vis atlas copco avec huileCompersseur d'air a vis atlas copco avec huile
Compersseur d'air a vis atlas copco avec huileMBouderbala
 
présentation sur la logistique (4).
présentation     sur la  logistique (4).présentation     sur la  logistique (4).
présentation sur la logistique (4).FatimaEzzahra753100
 
La logistique a L'ère de l'industrie 4.0
La logistique a L'ère de l'industrie 4.0La logistique a L'ère de l'industrie 4.0
La logistique a L'ère de l'industrie 4.0ourssoula
 
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminantsBow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminantsidelewebmestre
 
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcinsBOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcinsidelewebmestre
 
Agrivoltaïsme et filière ovine en Dordogne
Agrivoltaïsme et filière ovine en DordogneAgrivoltaïsme et filière ovine en Dordogne
Agrivoltaïsme et filière ovine en Dordogneidelewebmestre
 
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitièresBOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitièresidelewebmestre
 
BOW 2024 - 3-6 - Adaptation climat chaud Porcs
BOW 2024 - 3-6 - Adaptation climat chaud PorcsBOW 2024 - 3-6 - Adaptation climat chaud Porcs
BOW 2024 - 3-6 - Adaptation climat chaud Porcsidelewebmestre
 
Accompagnement de l'agrivoltaïsme dans le département de la Nièvre
Accompagnement de l'agrivoltaïsme dans le département de la NièvreAccompagnement de l'agrivoltaïsme dans le département de la Nièvre
Accompagnement de l'agrivoltaïsme dans le département de la Nièvreidelewebmestre
 
Cours-de-Ponts Cours de Ponts Principes généraux - Conception Méthodes de con...
Cours-de-Ponts Cours de Ponts Principes généraux - Conception Méthodes de con...Cours-de-Ponts Cours de Ponts Principes généraux - Conception Méthodes de con...
Cours-de-Ponts Cours de Ponts Principes généraux - Conception Méthodes de con...maach1
 
BOW 2024 - 3-3 - Adaptation des bâtiments pour ruminants au changement clima...
BOW 2024 - 3-3 -  Adaptation des bâtiments pour ruminants au changement clima...BOW 2024 - 3-3 -  Adaptation des bâtiments pour ruminants au changement clima...
BOW 2024 - 3-3 - Adaptation des bâtiments pour ruminants au changement clima...idelewebmestre
 
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...idelewebmestre
 
BOW 2024 - Logement des veaux laitiers en plein air
BOW 2024 - Logement des veaux laitiers en plein airBOW 2024 - Logement des veaux laitiers en plein air
BOW 2024 - Logement des veaux laitiers en plein airidelewebmestre
 
Actions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdf
Actions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdfActions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdf
Actions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdfalainfahed961
 

Dernier (20)

Chapitre 2 : fondations et analyses de données géotechniques
Chapitre 2 : fondations et analyses de données géotechniquesChapitre 2 : fondations et analyses de données géotechniques
Chapitre 2 : fondations et analyses de données géotechniques
 
BOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcinBOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcin
 
BOW 2024 - Dedans/Dehors quand voir ne suffit pas
BOW 2024 - Dedans/Dehors quand voir ne suffit pasBOW 2024 - Dedans/Dehors quand voir ne suffit pas
BOW 2024 - Dedans/Dehors quand voir ne suffit pas
 
Support de cours La technologie WDM.pptx
Support de cours La technologie WDM.pptxSupport de cours La technologie WDM.pptx
Support de cours La technologie WDM.pptx
 
BOW 2024 - 3 1 - Les infrastructures équestres et le changement climatique
BOW 2024 - 3 1 - Les infrastructures équestres et le changement climatiqueBOW 2024 - 3 1 - Les infrastructures équestres et le changement climatique
BOW 2024 - 3 1 - Les infrastructures équestres et le changement climatique
 
Compersseur d'air a vis atlas copco avec huile
Compersseur d'air a vis atlas copco avec huileCompersseur d'air a vis atlas copco avec huile
Compersseur d'air a vis atlas copco avec huile
 
présentation sur la logistique (4).
présentation     sur la  logistique (4).présentation     sur la  logistique (4).
présentation sur la logistique (4).
 
La logistique a L'ère de l'industrie 4.0
La logistique a L'ère de l'industrie 4.0La logistique a L'ère de l'industrie 4.0
La logistique a L'ère de l'industrie 4.0
 
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminantsBow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
 
Note agro-climatique n°2 - 17 Avril 2024
Note agro-climatique n°2 - 17 Avril 2024Note agro-climatique n°2 - 17 Avril 2024
Note agro-climatique n°2 - 17 Avril 2024
 
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcinsBOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
 
Agrivoltaïsme et filière ovine en Dordogne
Agrivoltaïsme et filière ovine en DordogneAgrivoltaïsme et filière ovine en Dordogne
Agrivoltaïsme et filière ovine en Dordogne
 
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitièresBOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
 
BOW 2024 - 3-6 - Adaptation climat chaud Porcs
BOW 2024 - 3-6 - Adaptation climat chaud PorcsBOW 2024 - 3-6 - Adaptation climat chaud Porcs
BOW 2024 - 3-6 - Adaptation climat chaud Porcs
 
Accompagnement de l'agrivoltaïsme dans le département de la Nièvre
Accompagnement de l'agrivoltaïsme dans le département de la NièvreAccompagnement de l'agrivoltaïsme dans le département de la Nièvre
Accompagnement de l'agrivoltaïsme dans le département de la Nièvre
 
Cours-de-Ponts Cours de Ponts Principes généraux - Conception Méthodes de con...
Cours-de-Ponts Cours de Ponts Principes généraux - Conception Méthodes de con...Cours-de-Ponts Cours de Ponts Principes généraux - Conception Méthodes de con...
Cours-de-Ponts Cours de Ponts Principes généraux - Conception Méthodes de con...
 
BOW 2024 - 3-3 - Adaptation des bâtiments pour ruminants au changement clima...
BOW 2024 - 3-3 -  Adaptation des bâtiments pour ruminants au changement clima...BOW 2024 - 3-3 -  Adaptation des bâtiments pour ruminants au changement clima...
BOW 2024 - 3-3 - Adaptation des bâtiments pour ruminants au changement clima...
 
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
 
BOW 2024 - Logement des veaux laitiers en plein air
BOW 2024 - Logement des veaux laitiers en plein airBOW 2024 - Logement des veaux laitiers en plein air
BOW 2024 - Logement des veaux laitiers en plein air
 
Actions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdf
Actions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdfActions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdf
Actions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdf
 

Rapport PFE: Gestion de Parc Informatique

  • 1. iRé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
  • 2. iiRéalisé par Éric OBONO Signatures Signature de l’encadrant pédagogique Signature du département des langues
  • 3. iiiRé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.
  • 4. ivRé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.
  • 5. vRé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.
  • 6. viRé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 *
  • 7. viiRé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 *
  • 8. viiiRé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 *
  • 9. ixRé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
  • 10. xRé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
  • 11. xiRé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
  • 12. xiiRé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
  • 13. 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
  • 14. 2 Réalisé par Éric OBONO 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.
  • 15. 3 Réalisé par Éric OBONO Chapitre 1: ETAT DE L’ART
  • 16. 4 Réalisé par Éric OBONO 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.
  • 17. 5 Réalisé par Éric OBONO 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.
  • 18. 6 Réalisé par Éric OBONO 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.
  • 19. 7 Réalisé par Éric OBONO 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
  • 20. 8 Réalisé par Éric OBONO 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
  • 21. 9 Réalisé par Éric OBONO 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
  • 22. 10 Réalisé par Éric OBONO 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
  • 23. 11 Réalisé par Éric OBONO 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
  • 24. 12 Réalisé par Éric OBONO 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 :
  • 25. 13 Réalisé par Éric OBONO  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.
  • 26. 14 Réalisé par Éric OBONO Chapitre 2: ANALYSE ET SPECIFICATION DES BESOINS
  • 27. 15 Réalisé par Éric OBONO 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.
  • 28. 16 Réalisé par Éric OBONO 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
  • 29. 17 Réalisé par Éric OBONO 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 ;
  • 30. 18 Réalisé par Éric OBONO  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
  • 31. 19 Réalisé par Éric OBONO 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>>
  • 32. 20 Réalisé par Éric OBONO 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>>
  • 33. 21 Réalisé par Éric OBONO 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 Technicien Ajouter les suivis des tickets valider les tickets Associer des solutions à des tickets Gérer tickets <<extend>> <<extend>> <<extend>>
  • 34. 22 Réalisé par Éric OBONO 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()
  • 35. 23 Réalisé par Éric OBONO 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
  • 36. 24 Réalisé par Éric OBONO 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 Résumé  Acteurs : Administrateur  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 administrateur <<Actor>> Système 1 : demande l'affichage des statistiques() 2 : affiche les statistiques()
  • 37. 25 Réalisé par Éric OBONO 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 administrateur <<Actor>> Système 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()
  • 38. 26 Réalisé par Éric OBONO d. Description du cas d’utilisation « Gérer les informations financières » Etapes Description Résumé  Acteurs : Administrateur  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
  • 39. 27 Réalisé par Éric OBONO 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()
  • 40. 28 Réalisé par Éric OBONO 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
  • 41. 29 Réalisé par Éric OBONO « 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
  • 42. 30 Réalisé par Éric OBONO  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
  • 43. 31 Réalisé par Éric OBONO 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]
  • 44. 32 Réalisé par Éric OBONO  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é
  • 45. 33 Réalisé par Éric OBONO  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.
  • 46. 34 Réalisé par Éric OBONO CHAPITRE 3 : CONCEPTION
  • 47. 35 Réalisé par Éric OBONO 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.
  • 48. 36 Réalisé par Éric OBONO 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.
  • 49. 37 Réalisé par Éric OBONO Figure 13: Diagramme d’activité Cycle de vie d’un ticket
  • 50. 38 Réalisé par Éric OBONO 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.
  • 51. 39 Réalisé par Éric OBONO CHAPITRE 4: REALISATION
  • 52. 40 Réalisé par Éric OBONO 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.
  • 53. 41 Réalisé par Éric OBONO 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.
  • 54. 42 Réalisé par Éric OBONO 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
  • 55. 43 Réalisé par Éric OBONO 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.
  • 56. 44 Réalisé par Éric OBONO 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.
  • 57. 45 Réalisé par Éric OBONO 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]
  • 58. 46 Réalisé par Éric OBONO a. Interface parc imprimante Figure 20: Interface parc imprimante b. Interface parc périphérique Figure 21: Interface parc périphérique
  • 59. 47 Réalisé par Éric OBONO 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.
  • 60. 48 Réalisé par Éric OBONO 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
  • 61. 49 Réalisé par Éric OBONO 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
  • 62. 50 Réalisé par Éric OBONO Figure 27: Interface de planification des interventions f. Association d’un ticket à un budget Figure 28: Interface d’association d’un ticket à un budget
  • 63. 51 Réalisé par Éric OBONO 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
  • 64. 52 Réalisé par Éric OBONO Figure 31: Interface de notification mail 7. Interface Intégration AD Figure 32: Interface intégration AD sur GLPI
  • 65. 53 Réalisé par Éric OBONO 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.
  • 66. 54 Réalisé par Éric OBONO 2. Interface de l’application mobile GOATS [10] Figure 34: Interface Application GOATS
  • 67. 55 Réalisé par Éric OBONO 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.
  • 68. 56 Réalisé par Éric OBONO 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
  • 69. 57 Réalisé par Éric OBONO 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.
  • 70. 58 Réalisé par Éric OBONO 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)
  • 71. 59 Réalisé par Éric OBONO 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