Académique Documents
Professionnel Documents
Culture Documents
National d’ingénieur
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.
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 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.
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 porte un remerciement particulier à mon ami Anthony Rey qui m’a soutenu tout au long
de la partie développement de l’application GOATS.
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.
Introduction ............................................................................................................................ 4
1. Problématique .............................................................................................................. 5
d. L’insécurité .............................................................................................................. 5
a. Clarilog .................................................................................................................... 6
b. H-inventory .............................................................................................................. 6
c. Spiceworks ............................................................................................................... 7
1. Comparaison ................................................................................................................ 9
Conclusion ............................................................................................................................ 13
Introduction .......................................................................................................................... 15
1. Architecture ............................................................................................................... 28
a. PHP ........................................................................................................................ 32
b. PERL ...................................................................................................................... 32
3. Serveurs ..................................................................................................................... 32
Conclusion ............................................................................................................................ 33
Conclusion ............................................................................................................................ 38
Introduction .......................................................................................................................... 40
2. Environnement logiciel.............................................................................................. 40
1. Installation ................................................................................................................. 41
2. Analyse ...................................................................................................................... 41
3. Inventaire ................................................................................................................... 41
4. Connectivité ............................................................................................................... 41
1. Interface d’authentification........................................................................................ 43
Conclusion ............................................................................................................................ 55
WEBOGRAPHIE ..................................................................................................................... 58
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 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
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.
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.
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.
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.
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 :
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.
2. Etude de l’existant
Parmi les produits existants sur le marché, nous retrouvons :
a. Clarilog
mail…) [3]
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.
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
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).
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.
10
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 :
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
11
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 :
12
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.
13
14
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.
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 :
15
System
Technicien
Administrateur Utilisateur
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
16
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 :
b. Module Helpdesk
Gérer les tickets
Planifier les interventions
Afficher les statistiques des tickets
Afficher les notifications
17
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 :
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é.
System
Technicien
Gérer les informationns financières <<include>>
<<include>>
<<include>>
Gérer tickets
<<include>>
Utilisateur
19
System
Ajouter des tickets
<<extend>>
<<extend>>
Associer des couts à des tickets
<<extend>>
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.
20
System
<<extend>>
Gérer tickets
Supprimer des tickets
Utilisateur <<extend>>
<<extend>>
System
<<extend>>
Gérer tickets
Ajouter les suivis des tickets
Technicien <<extend>>
<<extend>>
21
<<Actor>> Système
administrateur
alt
Séquencement 3 : affiche page de profil()
4 : message d'erreur()
22
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.
23
Séquencement
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.
24
<<Actor>> Système
administrateur
ref S'authentifier
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.
25
26
ref S'authentifier
3 : crée un fournisseur()
5 : crée un budget()
8 : crée un contrat()
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.
27
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 :
Architecture 2-tiers
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
28
Base de données
Avantages :
Inconvénients :
29
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.
Base de données
Database
Serveur
Navigateu
r
Figure 11: Schéma architecture 3-tiers
30
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 :
31
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 :
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.
Rapidité
32
b. Serveur web
Nous avons choisi d’utiliser le serveur Apache pour les raisons suivantes :
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.
33
34
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.
Les agents FusionInventory sont installés sur les machines du parc informatique.
35
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.
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.
Diagramme d’activité
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.
36
37
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.
38
39
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 :
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.
40
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 :
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.
41
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.
42
1. Interface d’authentification
43
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.
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.
44
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]
45
46
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.
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.
47
48
49
50
51
7. Interface Intégration AD
52
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.
53
54
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.
55
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.
56
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.
57
58