Signature de l'encadrant

Mr. Zarrouk Hichem

 Remerciements

VANT d'entreprendre l'exposé de ce rapport, nous présentons tous nos remer-

A ciements à tous ceux qui ont bien voulu apporter l'assistance nécessaire au bon
déroulement de ce stage.
Notre gratitude et profonde reconnaissance s'adressent tout particulièrement à notre
encadrant Monsieur ZARROUK Hichem qui nous a guidé tout au long de la réalisation
de ce projet. Son professionnalisme, ses conseils judicieux et ses remarques pertinentes
nous ont facilités le travail. Nous le remercions sincèrement pour son amabilité et son
assistance continue tout au long de la réalisation de ce projet.
 Résumé

Le présent travail entre dans le cadre du stage d'immersion à l'entreprise. En eet,

il s'agit de réaliser et intégrer deux open sources, OCS Inventory and GLPI, dans la
plateforme SURA an de permettre de garder un oeil sur la conguration des ma-
chines du réseau et sur les logiciels qui y sont installés d'une part, et la possibilité de
télédeployer des paquets d'autre part.
Mots clefs : Inventaire, parc informatique, open source, OCS Inventory, GLPI,
réseau.
 Abstract

The present work is carried out as a training period in a company. In fact, it

deals with realizing and integrating tow open sources, OCS Inventory and GLPI, into
the framework of SURA, which would allow the management and the track of the
computer conguration and software that are installed on the network, in one hand,
and the possibility to include package deployment in the other hand.
Index terms : Inventory, helpdesk , open source, OCS Inventory, GLPI, network.
 Table des matières

Remerciements ii

Résumé iii

Abstract iv

Liste des gures ix

Introduction générale 1

I Etude préalable 3
1 Présentation du cadre de travail et du sujet 4
1.1 Présentation de l'organisme d'accueil . . . . . . . . . . . . . . . . . . . 4
1.1.1 Présentation générale de VE TUNISIE . . . . . . . . . . . . . . 4
1.1.2 Domaines d'activité et services oerts . . . . . . . . . . . . . . . 5
1.2 Enoncé de la problématique . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Conduite du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Equipe du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.3 Planning de réalisation . . . . . . . . . . . . . . . . . . . . . . . 8

2 Etat de l'art 10
2.1 Les technologies du Web . . . . . . . . . . . . . . . . . . . . . . . . . . 10
TABLE DES MATIÈRES vi

2.1.1 Description des architectures distribuées . . . . . . . . . . . . . 10

2.1.2 Modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Notion d'inventaire automatisé . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Dénition d'un inventaire . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Nécessité d'un inventaire . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Notion du parc informatique et du Helpdesk . . . . . . . . . . . . . . . 15
2.3.1 Vue d'ensemble . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 L'inventaire informatique . . . . . . . . . . . . . . . . . . . . . . 16
2.3.3 L'administration de parc . . . . . . . . . . . . . . . . . . . . . . 16
2.3.4 Le Helpdesk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Protocole SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.1 A propos d'SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.2 Généralité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3 Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.4 Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . 21

3 Etude de l'existant 24
3.1 Mandriva Pulse 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Vue d'ensemble . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Points forts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3 Points faibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 OCS Inventory NG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1 Vue d'ensemble . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.2 Architecture d'OCS Inventory NG . . . . . . . . . . . . . . . . . 26
3.3.3 Points faibles d'OCS . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 GLPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.1 Vue d'ensemble . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.2 Fonctionnalité du GLPI . . . . . . . . . . . . . . . . . . . . . . 29
TABLE DES MATIÈRES vii

3.4.3 Point faibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

II Spécication et conception 32
4 Spécication des besoins 33
4.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Les besoins non-fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Spécication semi formelle . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.1 Présentation des acteurs . . . . . . . . . . . . . . . . . . . . . . 35
4.3.2 Les diagrammes des cas d'utilisation . . . . . . . . . . . . . . . 35

5 Conception 39
5.1 Conception architecturale . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.1 Architecture de l'application . . . . . . . . . . . . . . . . . . . . 39
5.1.2 Architecture du site . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.1 Conception de la base de données . . . . . . . . . . . . . . . . . 43
5.2.2 Les diagrammes de séquence . . . . . . . . . . . . . . . . . . . . 45
5.2.3 Conception des couches . . . . . . . . . . . . . . . . . . . . . . . 51

III Réalisation 54
6 Réalisation 55
6.1 Environnement et outils de travail . . . . . . . . . . . . . . . . . . . . . 55
6.1.1 Environement matériel . . . . . . . . . . . . . . . . . . . . . . . 55
6.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . 56
6.2 Principales interfaces graphiques . . . . . . . . . . . . . . . . . . . . . . 56
6.2.1 Page d'Authentication . . . . . . . . . . . . . . . . . . . . . . 56
6.2.2 Page d'Accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
TABLE DES MATIÈRES viii

6.2.3 Page Détail d'une machine . . . . . . . . . . . . . . . . . . . . . 58

6.2.4 Page de Recherche . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2.5 Page de Création d'un paquet . . . . . . . . . . . . . . . . . . . 60
6.2.6 Page d'Aectation de paquets . . . . . . . . . . . . . . . . . . . 61
6.2.7 Page de statut de paquets . . . . . . . . . . . . . . . . . . . . . 61
6.3 Problèmes rencontrés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Conclusion générale et Perspectives 63

A Annexe 1 65

Bibliographie 66

Netographie 67
 Liste des gures

1.1 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Architecture 2-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Architecture 3-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Topologie d'un parc informatique . . . . . . . . . . . . . . . . . . . . . 15
2.6 Les composantes d'un programme de gestion de helpdesk . . . . . . . . 17
2.7 Organisation idéal d'un helpdesk . . . . . . . . . . . . . . . . . . . . . 18
2.8 Le protocole SSL/TLS dans son environnement . . . . . . . . . . . . . 20
2.9 Phase de négociation SSL . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Architecture d'OCS Inventory . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Principe de fonctionnement de GLPI . . . . . . . . . . . . . . . . . . . 29
3.3 Synchronisation OCS NG/GLPI . . . . . . . . . . . . . . . . . . . . . . 30

4.1 Diagramme de cas d'utilisation de l'administrateur OCSI NG . . . . . . 36

4.2 Diagramme de cas d'utilisation de l'administrateur GLPI . . . . . . . . 37
4.3 Diagramme de cas d'utilisation de l'agent . . . . . . . . . . . . . . . . . 37

5.1 Architecture générale de l'application . . . . . . . . . . . . . . . . . . . 41

5.2 Architecture générale de la base de données répartie . . . . . . . . . . . 42
5.3 Architecture du site : vue administrateur . . . . . . . . . . . . . . . . . 43
5.4 Modèle entité/association . . . . . . . . . . . . . . . . . . . . . . . . . 44
LISTE DES FIGURES x

5.5 Diagramme de séquence d'authentication de l'administrateur . . . . . 46

5.6 Diagramme de séquence d'achage de l'inventaire . . . . . . . . . . . . 47
5.7 Diagramme de séquence de consultation d'un inventaire d'une machine 47
5.8 Diagramme de séquence de création d'un paquet de déploiement . . . . 48
5.9 Diagramme de séquence d'aectation d'un paquet . . . . . . . . . . . . 49
5.10 Diagramme de séquence de téléchargement d'un paquet . . . . . . . . . 50
5.11 Architecture de la couche présentation . . . . . . . . . . . . . . . . . . 51
5.12 Diagramme de classe de l'application . . . . . . . . . . . . . . . . . . . 53

6.1 Page de connexion de l'utilisateur . . . . . . . . . . . . . . . . . . . . . 57

6.2 Page d'Acceuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3 Page détail d'une machine . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.4 Page de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.5 Page de création d'un paquet . . . . . . . . . . . . . . . . . . . . . . . 60
6.6 Page d'aectation de paquets . . . . . . . . . . . . . . . . . . . . . . . 61
6.7 Page de statut de paquets . . . . . . . . . . . . . . . . . . . . . . . . . 61

A.1 Schéma de fonctionnement d'OCS Inventory NG . . . . . . . . . . . . . 65

 Introduction générale

A croissance économique énorme et la dispersion des entreprises gigantesques et

L multinationales qui caractérisent notre époque accompagnées par le développe-
ment technologique, l'augmentation de taille des réseaux et l'informatisation du sto-
ckage et de la gestion des données rendent primordiaux le contrôle et la surveillance de
la création et de l'utilisation de ces données via des systèmes informatiques distants,
hétérogènes et sécurisés.

En eet, ce développement augmente aussi les taux d'erreur et de pannes résultant

de la pression appliquée sur les serveurs et l'élargissement du diamètre des intervenants
sur les données ce qui rend souvent indispensable une intervention de stabilisation ou
de maintenance nécessitant souvent le ralentissement voire l'arrêt des serveurs mettant
ainsi l'intégralité du travail de l'entreprise et de sa réputation.

Ceci impose l'entreprise à chercher des techniciens capables d'administrer leurs pla-
teformes et assurer le suivi technique de leur parc informatique en temps réel an
d'assurer la meilleure performance possible ses outils.

Mais cette tâche reste encore insusante puisque les données peuvent être sujet aux
intrusions et attaques sur les réseaux aussi bien qu'à l'accès non autorisé ou la violation
de privilèges. Ainsi, la tâche d'administrateur nécessite le contrôle et la surveillance des
machines connectés ensemble ainsi que la sécurisation des données contre les attaques
externes.

Ce suivi et ce contrôle doivent donc compromis entre la simplicité de la tâche, l'ef-

cacité et la abilité pour permettre le diagnostic des performances des serveurs, le
contrôle des utilisateurs et la manipulation précise du parc.

Notre projet se situe dans ce cadre, consistant à concevoir et réaliser une solution
web permettant le suivi d'un inventaire du matériel et logiciel disponible dans un parc
INTRODUCTION GÉNÉRALE 2

informatique en se basant sur des open sources disponibles : OCS Inventory NG pour
la gestion de l'inventaire et GLPI pour la gestion du helpdesk.

Ce présent rapport présente les diérentes étapes suivies pour la réalisation de ce

projet. Il s'articule autour de six chapitres

Nous consacrons le premier chapitre à présenter le cadre du travail et du sujet.

Un deuxième chapitre donne des notions théoriques des technologies nécessaires à la
réalisation du projet. Par la suite, le troisième chapitre décrit quelques solutions exis-
tantes. Nous passerons dans le quatrième chapitre à la spécication des besoins et nous
les analysons à travers des méthodes formelles. Le cinquième chapitre sera dédié à la
conception de l'application. Enn, le chapitre six couronne le travail réalisé en expo-
sant l'environnement matériel et logiciel utilisé et les interfaces graphiques conçues en
se basant sur quelques captures d'écran. Nous nirons par une conclusion générale et
les principales perspectives.
Première partie

Etude préalable
CHAPITRE

1 Présentation du cadre de
travail et du sujet

Introduction
ANS le cadre du stage d'immersion à l'entreprise, nous avons été accueillis au sein
D de l'entreprise VE TUNISIE (située au pôle des technologies de communications
Elgazela), Tunis. Ce stage s'attaque à plusieurs fronts qui s'article autour de deux
open sources à savoir OCS Inventory NG pour la réalisation d'un inventaire sur la
conguration matérielle des machines d'un réseau d'une part et GLPI pour la gestion
d'un parc informatique d'autre part, avec pour l'objectif leur intégration.

1.1 Présentation de l'organisme d'accueil

1.1.1 Présentation générale de VE TUNISIE
VE TUNISIE est une société anonyme spécialisée dans la conception, la fabrication
et la commercialisation de produits de réseaux informatiques.

Forte d'une expérience dans les nouvelles technologies, les produits et services pro-
posés par VE TUNISIE ciblent les marchés de la maîtrise des communications infor-
matiques, de la sécurité, des technologies mobiles, de la continuité de service/hautes
disponibilités et des applications/services " On Demande ".

VE TUNISIE se distingue des autres acteurs du marché par ses produits aux archi-
tectures modulaires, particulièrement au niveau des technologies utilisées.
CHAPITRE 1. PRÉSENTATION DU CADRE DE TRAVAIL ET DU SUJET 5

Experte en réseaux et télécommunications, VE TUNISIE est avant tout une équipe

professionnelle, sérieuse, dynamique et à l'écoute du client. Elle se compose d'ingé-
nieurs en réseaux informatiques, d'ingénieurs en qualité, de développeurs/intégrateurs,
d'installateurs réseaux, et d'une force commerciale et marketing.

Les ressources humaines de VE TUNISIE possèdent une expérience signicative dans

la conception et la réalisation des systèmes de communication électroniques et des
architectures réseaux (conguration de tous types d'équipements réseau, certication
CISCO CCNA1 à 4). Une attention particulière est portée à la stabilité des réalisations,
à l'ergonomie des interfaces ainsi qu'à la simplicité de leur utilisation.

1.1.2 Domaines d'activité et services oerts

1.1.2.1 Prestations réseaux
VE TUNISIE assure à travers son équipe de techniciens et d'ingénieurs l'audit du
réseau de votre structure, la migration technologique de votre architecture réseau, la
conguration d'équipements réseaux, etc. ...

En eet, VE TUNISIE se charge essentiellement à :

 L'élaboration de tableaux de bord et d'outils de reporting.
 L'intégration des modules de formation.
 L'analyse de vulnérabilité face à l'intelligence économique.
 Un support juridique.
 L'élaboration de code déontologique de sécurité au niveau de la gestion des res-
sources humaines (équilibre entre la sécurité et la liberté d'accès à l'information
CNIL).
 Une politique d'information permanente sur la sécurité.

1.1.2.2 Service maintenance

Les équipes d'ingénieurs de VE TUNISIE assurent l'assistance et la maintenance
des équipements proposés au client et intervient rapidement lors d'incidents réseau (à
distance et/ou sur site).

Le support de VE TUNISIE bénécie d'un système d'information partagé entre les

diérents intervenants. Une base de données répertorie chaque incident et intervention.
CHAPITRE 1. PRÉSENTATION DU CADRE DE TRAVAIL ET DU SUJET 6

Des outils d'analyse temps réel permettent un diagnostique pointu.

Tous ces moyens combinés permettent des interventions rapides et ecaces auprès des
clients.

1.1.2.3 Service formation

Diérents types de formations sont proposés aux utilisateurs, distribu-
teurs/revendeurs et éditeurs :
 Formation utilisateur : donne une idée sur l'utilisation des diérents produits
de la gamme V2b Technology.
 Formation utilisateur avancé : elle inclut la formation utilisateur ordinaire
en lui ajoutant des notions de bases sur les réseaux et des législations relatives
aux réseaux informatiques.
 Formation administrateur : se familiariser sur les outils de supervisions du
réseau et des options avancées des diérents produits de la gamme V2b Techno-
logy.
 Formation intégrateur : architectures réseaux, maintenance du système
SURA.
 Formation éditeur : développement de modules intégrés dans le système SURA.

1.1.2.4 Service développement

VE TUNISIE propose des développements spéciques pour ses clients, distributeurs
et éditeurs :
 Personnalisation graphique de l'interface des produits de la gamme V2b Techno-
logy : utilisation de vos logos, de vos couleurs sur l'interface
 Personnalisation fonctionnelle de la SURA : intégration de vos applications ou de
vos besoins.
 Développements d'applications orientées métier.
 Développement d'application orientées réseaux.
 Développements de sites web avec mise en place de votre charte graphique.

1.2 Enoncé de la problématique

Dans le cadre de son activité, VE TUNISIE est amenée à des appels d'ore ou à
eectuer des présentations de ses prestations réseaux auprès de client potentiels. Un
CHAPITRE 1. PRÉSENTATION DU CADRE DE TRAVAIL ET DU SUJET 7

élément constitutif de ces démarches vers le client est la personnalisation fonctionnelle

de la SURA par l'intégration de plusieurs modules et fonctionnalités permettant la
gestion d'un parc informatique sur la plateforme adaptées aux besoins.

Au court de ces dernières années, le monde du logiciel libre connaît un succès croissant
qui compte. Parmi les outils et les solutions les plus prisés, on trouve, d'une part, Open
Computer and Software Inventory Next Generation (OCS Inventory NG) pour réaliser
un inventaire sur la conguration matérielle des machines du réseau et sur les logiciels
qui y sont installés. Et d'autre part, Gestion Libre d'un Parc Informatique (GLPI)
pour la gestion de parc informatique.

OCS Inventory NG en plus de proposer toutes les fonctions classiques d'un inven-
taire suscite un engouement sans précédent qui s'explique par sa richesse en termes de
fonctionnalités et le faible coût matériel nécessaire.
GLPI quand à lui, est une implémentation Full Web pour gérer l'ensemble des pro-
blématiques de gestion du parc informatique qui s'attelle à fournir une plateforme
complète et able.

Le couplage de ces diérentes technologies présente des avantages indéniables et c'est

ce que ce stage propose de mettre en lumière.
A terme, il s'agit d'intégrer au premier lieu un module de télé-déploiement d'OCS
Inventory NG sur la plateforme SURA. Ensuite, un module d'inventaire hardware et
software devra être étudié et intégré. Enn, le module helpdesk du GLPI sera optimiser
et automatiser pour se connecter directement avec les deux modules déjà mentionnés.

1.3 Conduite du projet

1.3.1 Equipe du projet
Le sujet a été proposé par Ridha BEN ROMDHANE, chef du département déve-
loppement au sein de VE TUNISIE.
L'encadrement du stage et la consultation sur les aspects techniques de l'application a
été assuré par Hichem ZARROUK, ingénieur développeur.
Le présent document expose notre contribution au projet.
CHAPITRE 1. PRÉSENTATION DU CADRE DE TRAVAIL ET DU SUJET 8

1.3.2 Méthodologie
La démarche adopté pour traiter le sujet repose sur les étapes élémentaires de la
conduite du projet. Dans un premier temps, les analyses préalables, par l'exploration
du sujet et les analyses internes et externes, ont permis de rédiger ainsi un cahier
des charges prévisionnel. La validation de celui-ci a permis de dénir les modalités
techniques et fonctionnelles de la base et de rédiger ainsi le cahier des charges détaillé.
C'est en s'appuyant sur les conclusions de ce dernier que la phase de mise en oeuvre a
pu être amorcée. Au moment de la rédaction du présent rapport, les choix techniques
ont été aectés, notamment concernant la structure et les modalités de traitement, et
certains scripts d'installation rédigés.

1.3.3 Planning de réalisation

Un diagramme de Gantt a été établi en début de projet pour permettre d'encadrer
la progression. Les diérentes échéances en ont globalement été respectées. Un délai
supplémentaire a toutefois été accordé à la réalisation d'une série de vérication et
validation des modules.

Figure 1.1  Chronogramme

CHAPITRE 1. PRÉSENTATION DU CADRE DE TRAVAIL ET DU SUJET 9

Conclusion
Après avoir présenté le cadre de ce stage d'été, le sujet à traiter et la méthodologie
qui sera utilisée, il est utile d'étudier les notions principales pour comprendre le projet
comme il faut.
CHAPITRE

2 Etat de l'art

Introduction
VANT de procéder à toute opération de réalisation, il importait dans un premier
A temps d'approfondir la connaissance du sujet et de dénir les diérentes consti-
tuantes de la problématique. A cette n, l'étude a débuté par une phase préliminaire
d'exploration du sujet, découlant sur une analyse interne des technologies Web exis-
tantes. Par la suite, la notion d'inventaire automatisé et du parc informatique s'avère
nécessaire à dénir. Et enn, nous donnons un aperçu sur les diérentes fonctionnalités
oertes par le protocole SSL.

2.1 Les technologies du Web

Il s'est avéré être intéressant d'avoir une idée claire sur les technologies du web ;
nous proposons alors de décrire les architectures existantes, les modèles instances et
les technologies professionnelles.

2.1.1 Description des architectures distribuées

Ce sont des applications dont les fonctions sont réparties entre plusieurs systèmes.
Elles sont appelées aussi architectures multi-tiers. Dans une architecture distribuée
type, les fonctions sont réparties entre un système client (station de travail,terminal,...)
et un système serveur (serveur PC, Unix, ...). Chaque système contient une partie de
l'application, les parties manquantes sont exécutées sur les autres systèmes participants
à l'application et les informations sont échangées par le réseau.

Ces fonctions sont réparties suivants trois types de catégories :

CHAPITRE 2. ETAT DE L'ART 11

 Fonctions de présentation qui gèrent l'interface utilisateur.

 Fonctions applicatives orientées métier pour la validation des données et la mo-
délisation des processus métiers (prises de commandes ...).
 Fonctions de stockage orientées base de données.
Les deux architectures types les plus répondues à savoir sont l'architecture 2-tiers
et l'architecture 3-tiers.

2.1.1.1 Architecture 2-tiers

L'architecture 2-tier, aussi appelée architecture à deux niveaux, caractérise les sys-
tèmes clients/serveurs dans lesquels le client demande une ressource et le serveur la
lui fournit directement. Cela signie que le serveur ne fait pas appel à une autre ap-
plication an de fournir le service. Etant polyvalent, le serveur est capable de fournir
directement l'ensemble des ressources demandées par le client. Le schéma suivant sert
d'exemple explicatif :

Figure 2.1  Architecture 2-tiers

2.1.1.2 Architecture 3-tiers

Dans l'architecture à 3-tiers, aussi appelée architecture à trois niveaux, il existe un
niveau intermédiaire, c'est-à-dire que l'on a généralement une architecture partagée
entre :
 Le client demandeur de ressources
 Le serveur d'application (appelé aussi middleware) : le serveur chargé de fournir
la ressource mais faisant appel à un autre serveur.
 Le serveur secondaire (généralement un serveur de base de données), fournissant
un service au premier serveur.
CHAPITRE 2. ETAT DE L'ART 12

Dans l'architecture 3-tiers, contrairement à l'architecture 2-tiers, les applications au

niveau serveur sont délocalisées, c'est-à-dire que chaque serveur est spécialisé dans une
tâche (serveur Web et serveur de base de données par exemple). Le schéma suivant sert
d'exemple explicatif :

Figure 2.2  Architecture 3-tiers

Ainsi, l'architecture à trois niveaux permet :

 De simplier le développement
 Une plus grande séparation entre les couches
 De meilleures performances (les tâches sont partagées)
 Une intégration avec l'existant : mettre à la disposition des développeurs des
moyens standards d'accès aux données des systèmes déjà existants.
 Une mise en place des mécanismes standardisés pour gérer la sécurité sur tous les
systèmes d'une application distribuée (la sécurité peut être dénie pour chaque
service

2.1.2 Modèle MVC

Le modèle MVC cherche à séparer les couches présentation, traitement et accès aux
données. Une application web respectant ce modèle pourrait être architecturée de la
façon suivante :

Figure 2.3  Modèle MVC

CHAPITRE 2. ETAT DE L'ART 13

Une telle architecture est appelée 3-tiers ou à 3 niveaux :

1. l'interface utilisateur est le V (la vue)
2. la logique applicative est le C (le contrôleur)
3. les sources de données sont le M (Modèle)
L'interface utilisateur est souvent un navigateur web mais cela peut être également une
application autonome qui via le réseau envoie des requêtes HTTP au service web et
met en forme les résultats que celui-ci lui renvoie. La logique applicative est constituée
des scripts traitant les demandes de l'utilisateur. La source de données est souvent une
base de données mais cela peut être aussi de simples chiers. Le développeur a intérêt
à maintenir une grande indépendance entre ces trois entités an que si l'une d'elles
change, les deux autres n'aient pas à changer ou changent peu.

Figure 2.4  Architecture MVC

CHAPITRE 2. ETAT DE L'ART 14

2.2 Notion d'inventaire automatisé

2.2.1 Dénition d'un inventaire

Un inventaire est une opération permettant à l'administrateur de collecter le maxi-
mum d'information sur le parc informatique dans le temps le plus court possible. On
distingue trois types d'inventaires :
 Inventaire initial : c'est le plus long. Il s'agit de recenser tous les matériels et
logiciels gérés et nécessite la plupart du temps de passer " physiquement " sur
chaque PC.
 Inventaire de contrôle : il s'agit de valider que les données gérées sont à jour.
L'inventaire de contrôle permet de valider que le matériels et logiciels n'ont pas
été achetés ou mis en place sans en informer le service informatique.
 Inventaire permanent : il nécessite l'utilisation d'un logiciel d'inventaire auto-
matisé qui scanne régulièrement (tous les mois ou toutes les semaines) les postes
connectés au réseau. Ce type d'inventaire permet d'eectuer un suivi des instal-
lations de logiciels et de se protéger contre les vols de composants matériels.
An de réaliser un bon inventaire, il doit passer par la dénition des objets qu'on veut
inventorier. A ce titre, une liste exhaustive de ces matériels est établie pour servir à
la construction d'une base de données, en particulier une famille de postes, de péri-
phériques et de logiciels. Quelques contraintes sont à prendre en compte : plus il y a
d'élément à inventorier, plus l'inventaire sera long et comportera de risques d'erreur.
En plus, tous les éléments ne doivent pas être inventoriés. Par exemple : si les claviers
ne sont pas gérés de manière unitaire, il est parfaitement inutile de relever leur numéro
de série. De même si les adresses IP sont attribuées par un serveur DHCP.

2.2.2 Nécessité d'un inventaire

La topologie et la conguration des éléments de réseau situés à la périphérie des
backbones évoluent trop rapidement pour être connues de façon précise par l'adminis-
trateur réseaux. Ceci est d'autant plus vrai avec le développement de l'informatique
mobile et l'apparition de zones Wi. Néanmoins, l'administrateur se doit de maîtriser
la conguration et la topologie du réseau pour des raisons de sûreté de fonctionnement,
de sécurité et de disponibilité (mauvaise conguration, connections non permises, sur-
charge du réseau du à un sous dimensionnement).
CHAPITRE 2. ETAT DE L'ART 15

Avec l'avènement des portables à un euro, des connexions wireless, le fait que les
diérents départements d'une entreprise ne cessent d'augmenter en taille, il en découle
que l'administrateur a bien du mal à faire remonter les informations sur les machines
vers lui pour gérer son parc constitué d'une centaine de machine.

Figure 2.5  Topologie d'un parc informatique

Des solutions existent mais souvent très coûteuses. (Hp open view, Tivoly, Lansur-
veyor, Landesk, etc...) Dans le monde du logiciel libre des développements de gestion de
parc se développent actuellement des solutions prometteuses qui manipulent les infor-
mations soit par la saisie directe à la main (phpmyzero, phpmycampus, GLPI), soit ils
nécessitent l'installation d'un client sur le poste pour l'analyser (OCS Inventory NG).

2.3 Notion du parc informatique et du Helpdesk

2.3.1 Vue d'ensemble
L'évolution des technologies Intranet/Internet a contribué à une modication im-
portante de l'utilisation de l'outil informatique par les entreprises. Ces évolutions né-
cessitent, au sein des services informatiques, une gestion rigoureuse des parcs de micro-
ordinateurs et des logiciels.

Donc les entreprises sont à la recherche des techniciens capables, non seulement
d'assurer le suivi technique des parcs de micro-ordinateurs et de contrôler son infra-
structure, mais aussi d'amener les décideurs à faire le bon choix informatique, an
CHAPITRE 2. ETAT DE L'ART 16

d'assurer à l'entreprise la meilleur performance possible de ses outils, des services e-
caces auprès des utilisateurs et une meilleur ecacité des équipes.
Ce résultat nous amène à relever trois fonctions de base qu'un système de gestion d'un
parc informatique doit répondre :
 L'inventaire informatique
 L'administration de parc
 Le helpdesk

2.3.2 L'inventaire informatique

Avec l'inventaire technique, il ne s'agit pas seulement de détailler les congura-
tions matérielles et logicielles des PC. Les périphériques, ainsi que les serveurs et les
équipements réseaux sont également concernés. Il s'agit alors de décrire la chaîne de
liaison jusqu'à spécier les ports des commutateurs sur lesquels sont reliés les systèmes.
D'autre part, un outil de reporting permet de sortir des statistiques sur l'état du parc,
par exemple pour déterminer combien de PC intègrent le processeur et la mémoire
aptes à supporter le déploiement d'une nouvelle application.

2.3.3 L'administration de parc

La gestion administrative consiste d'abord à tenir à jour une base spéciant les
références des PC, leur attribution et leur localisation physique. Mais de plus en plus,
elle prend en compte tous les coûts et les procédures intrinsèques à une gestion de
parc : suivi budgétaire, amortissement, assurances ou encore gestion des achats, li-
cences, commandes, stocks et factures.

D'autre part, ces outils s'ouvrent à l'ensemble des actifs de l'entreprise - éléments
péri-informatiques tels que PABX ou télécopieurs mais aussi biens de production, voire
mobilier ou immobilier. Même si les éditeurs admettent que peu de leurs clients se sont
engagés dans cette voie, les cahiers des charges montrent que beaucoup l'envisagent.

2.3.4 Le Helpdesk
2.3.4.1 Dénition
Un helpdesk est constitué d'un certain nombre de spécialistes apportant un support
à des utilisateurs de technologie. Plus traditionnellement, le domaine sur lequel porte
CHAPITRE 2. ETAT DE L'ART 17

ce soutien est l'informatique (au sens large : hardware, software ou conseils).

En général, les personnes travaillant au helpdesk (que nous appellerons " analystes
helpdesk") répondent aux utilisateurs par téléphone et classent leur requête en fonction
de critères tels que l'urgence, les délais de commande, le type de problème, la position
de l'utilisateur dans l'entreprise, le nombre d'utilisateurs bloqués, etc. Les informations
nécessaires concernant un appel sont enregistrées (qui, quand et pourquoi) et ce ticket
est suivi, à l'aide d'un logiciel spécialisé dans la gestion du ux d'information, jusqu'à
sa résolution.

Figure 2.6  Les composantes d'un programme de gestion de helpdesk

De nombreux programmes orent une solution base de données qui permet de réutili-
ser des appels et leur suivi pour résoudre des problèmes déjà rencontrés. Le plus impor-
tant, dans ce cadre, est de trouver une solution qui convienne à l'entreprise considérée,
il n'existe en eet pas de solution unique. Il faut savoir que si il peut être aisé de conce-
voir un système qui enregistre les appels, il est moins trivial de prévoir un programme
qui permette de capturer et mettre à jour les solutions qui ont permis de résoudre les
problèmes des utilisateurs.

2.3.4.2 Fonctions du Helpdesk

Les helpdesks fournissent, sur demande, des conseils, de l'information ou des actions
pour permettre aux utilisateurs d'eectuer une tâche informatique. Plus généralement,
CHAPITRE 2. ETAT DE L'ART 18

la tâche des analystes helpdesk est de répondre par téléphone aux questions des utilisa-
teurs, de réguler l'assistance technique et d'organiser la résolution du problème. Pour
Bruton (1998c), consultant spécialisé en helpdesk, le but de l'existence d'un helpdesk
est de " restaurer la productivité de l'utilisateur".

Ces centres de support à l'utilisateur nal (end-user) deviennent de nos jours une par-
tie intégrante des services fournis par une entreprise pour la satisfaction du client. Un
helpdesk est généralement actif pendant les heures de bureau, et parfois au-delà (mais
avec une équipe réduite). Certaines entreprises utilisent activement le web (inter- ou
intranet) qui permet une automatisation (au moins partielle) de certains traitements.

Figure 2.7  Organisation idéal d'un helpdesk

La gure ci-dessus présente l'organisation interne d'un helpdesk ainsi que ses rapports
avec d'autres services de l'entreprise. Lorsque l'utilisateur prend en contact avec le
helpdesk, toutes les informations concernant le cas sont prises en compte par l'ana-
lyste helpdesk qui crée le ticket. Les informations pertinentes extraites du problème de
l'utilisateur font ensuite l'objet d'une analyse qui débouche sur une décision.
CHAPITRE 2. ETAT DE L'ART 19

Le cas échéant, les informations sont transmises au responsable du helpdesk qui

participe à la décision. Les décisions prises sont également enregistrées et pourront,
par la suite, être mises en relation avec les informations que possédait le helpdesk au
départ. Une action est ensuite entreprise, et des informations sont transmises formant
une boucle de rétroaction, à la fois à l'utilisateur, mais aussi aux services concernés par
le type de problème en question.

Face aux problèmes liés à l'entretien d'un parc informatique devenant de plus en
plus complexe et diversié, il faut de multiples groupes de personnes, possédant de
multiples connaissances, pour les prendre en charge. Un des grands débats dans ce
domaine est de savoir s'il faut engager des spécialistes ou des généralistes. La plupart
des responsables de helpdesk semble préférer de bonnes capacités de communication,
de l'expérience dans le service aux clients et une capacité pour faire face au stress en
plus de compétences purement techniques. Des instituts tels que Help Desk Institute et
Software Support Professionals Association ont mis en place une formation qui apporte
des notions de base pour le support aux clients en général et plus spéciquement pour
le personnel d'un helpdesk.

2.4 Protocole SSL

2.4.1 A propos d'SSL
C'est le besoin d'éliminer les interceptions sur les réseaux par des personnes non
autorisés et par la même occasion d'empêcher la récupération de données personnels
des utilisateurs qui a conduit à l'élaboration d'un standard permettant des transmis-
sions sécurisées des données via les navigateurs Web. Netscape Communications est
la compagnie qui a conçu le protocole SSL (Secure Socket Layer), qui fut le premier
protocole de sécurisation des communications via les navigateurs Web.

La première version du protocole a été publiée dans le milieu de l'année 1994 et est
intégrée au navigateur Mosaic, puis n 1994 la seconde version fut intégrée dans le
navigateur Netscape Navigator. La troisième version fut publiée n 1995 permettant
de corriger les faiblesses de son prédécesseur.
C'est en mai 1996 que l'IETF accepta de faire de SSL un standard universel. Et c'est
en 1999 que SSL fut renommé par l'IETF : TLS (Transport Layer Security), TLS v1.0
n'est qu'une extension de SSL v3.0.
CHAPITRE 2. ETAT DE L'ART 20

A l'heure actuelle la plupart des navigateurs Web supportent le protocole et c'est ainsi
que le protocole SSL est utilisé dans les transactions sur Internet allant de l'achat de
livres jusqu'au transfert de fonds.

2.4.2 Généralité
SSL est donc un protocole à négociation développé à l'origine par Netscape. Son
but est de sécuriser les transactions Internet, par authentication du serveur et éven-
tuellement du client, et par chirement de la session.
Il est une couche optionnelle se situant entre les couches d'application et de transport.
Le but de SSL est d'être un protocole de sécurité facile à déployer assurant une sécurité
totale des échanges de plusieurs applications. Pour TCP, SSL n'est qu'une application
qui utilise ses services.

Figure 2.8  Le protocole SSL/TLS dans son environnement

SSL ne dépend pas des applications utilisées lors des transactions et s'applique sous
les protocoles HTTP, FTP, Telnet, LDAP, etc.
La sécurisation des connexions à l'aide du protocole SSL doit assurer que la connexion
assure la condentialité et l'intégrité des données transmises, la possibilité de vérica-
tion de l'identité des correspondants et abilité de la connexion.
CHAPITRE 2. ETAT DE L'ART 21

Clients et serveurs commencent par s'authentier mutuellement (pas toujours de ma-

nière symétrique), puis négocient une clé symétrique de session qui servira à assurer la
condentialité des transactions. L'intégrité de ces dernières est assurée par l'application
de HMAC.

2.4.3 Fonctionnalités
Les principales fonctions assurées par SSL sont :
 Authentication : dans SSL v3.0 et TLS, l'authentication du serveur est obli-
gatoire. Elle a lieu à l'ouverture de la session. Elle emploie pour cela des certicats
conformes à la recommandation X 509 v3. Cela permet au client de s'assurer de
l'identité du serveur avant tout échange de données. Dans la version actuelle de
SSL et de TLS l'authentication du client reste facultative.
 Condentialité : Elle est assurée par des algorithmes de chirement symé-
triques. Bien que le même algorithme soit utilisé par les deux parties chacune
possède sa propre clé secrète qu'elle partage avec l'autre. Les algorithmes utilisés
sont : DES, 3DES, RC2, RC4.
 Intégrité :Elle est assurée par l'application d'un algorithme de hachage (SHA
ou MD5) aux données transmises. L'algorithme génère, à partir des données et
d'une clé secrète, une signature pour les données appelée code d'authentication
de message. Ainsi tout changement appliqué aux données provoquera un mes-
sage d'erreur côté récepteur puisque la signature contenue dans le message sera
diérente de celle calculée par le récepteur.

2.4.4 Principe de fonctionnement

Le protocole SSL/TLS est composé de 4 sous protocoles qui sont :
 Handshake Protocol : Ce protocole permet l'authentication obligatoire du
serveur, du client (optionnelle), et la négociation de la suite du chirement qui
sera utilisé lors de la session.
 CCS (ChangeCipherSpec) Protocol : Ce protocole comprend un seul et
unique message (1 octet) qui porte le même nom que le protocole, il permet
d'indiquer au protocole Record la mise en place des algorithmes de chirement
qui viennent d'être négociés.
 Alert Protocol : Ce protocole génère des messages d'alerte suite aux erreurs
que peuvent s'envoyer le client et le serveur. Les messages sont composés de 20
CHAPITRE 2. ETAT DE L'ART 22

octets, le premier étant soit fatal soit warning. Si le niveau de criticité du message
est fatal, la connexion SSL est abandonnée.
 Record Protocol :Ce protocole intervient après l'émission du message Chan-
geCipherSpec. Il permet de garantir la condentialité à l'aide de chirement des
données et l'intégrité à l'aide de génération d'un condensât.
Le protocole SSL comporte une phase de négociation où client et serveur peuvent
dénir le niveau de sécurité voulu et s'authentier. Après cette phase, ils peuvent
communiquer (échange de données applicatives : HTTP, FTP, etc.)

Rappelons que les trois fonctionnalités principales de SSL sont l'authentication

du serveur, l'authentication du client et le chirement des données. Le protocole se
compose de deux couches principales : le protocole Record qui traite l'encodage des
données à envoyer et le protocole Handshake qui gère la négociation.

Suite à cette phase de négociation,comme la décrit la Figure ci-dessous , le client et

le serveur peuvent s'échanger des données de façon sécurisée. Celles-ci seront chirées
par l'algorithme symétrique choisit au cours de la négociation.
CHAPITRE 2. ETAT DE L'ART 23

Figure 2.9  Phase de négociation SSL

Conclusion
L'état de l'art nous a permis de présenter le contexte de notre application et de
nous familiariser avec les concepts de l'inventaire automatisé et de la gestion d'un parc
informatique en donnant des notions théoriques sur le protocole SSL et ses fonction-
nalités. Pour cela, le chapitre suivant sera consacré pour l'étude de l'existant et les
solutions adoptés.
CHAPITRE

3 Etude de l'existant

Introduction
NE étape essentielle de tout projet informatique consiste à eectuer une étude
U préalable. Cette étude consiste à examiner le système auquel nous voulons ap-
porter des solutions an de déceler les défaillances et les insusances auxquelles nous
devons remédier. En eet, dans la majorité voir dans la totalité des cas, la mise en
place d'un projet est due à un problème ou un manque dans l'entreprise. Il faut donc
bien étudier l'existant an d'aboutir à une solution ecace des besoins de l'entreprise.

3.1 Mandriva Pulse 2.0

Ceci est à priori un logiciel de gestion de parc informatique. Nous n'avons malheu-
reusement pas pu le tester car il est introuvable. Ce logiciel est sensé être " leader "
dans le domaine, cependant aucun téléchargement n'est disponible sur le site de Man-
driva. Il semblerait qu'il faille contacter directement Mandriva pour pouvoir essayer ce
produit.

3.2 SNMP
3.2.1 Vue d'ensemble
SNMP est un protocole dont le but est de permettre une gestion " simple " d'un
réseau informatique (Simple Network Management Protocol). Il est déployé en utili-
sant un modèle clients/serveur (agents/superviseur) secondé par une base de données
appelée MIB (Management Information Base).
Les agents sont installés sur des " noeuds " du réseau (switch, routeurs, ordinateurs,...)
CHAPITRE 3. ETUDE DE L'EXISTANT 25

et peuvent être interrogés par le superviseur pour récupérer certaines informations

matérielles et logicielles.

Les informations récupérées par le serveur sont ensuite stockées dans la MIB. Les
échanges clients/serveur se font via le protocole UDP généralement par le port 161.
SNMP est utilisable avec des logiciels tels que MRTG ou CACTI lui fournissant une
interface graphique et permettant l'édition de graphes reétant l'état du réseau.

3.2.2 Points forts

Plus que de l'inventaire, on aborde ici la notion de gestion de réseau à distance. Il
est en eet possible de dénir des " comportements " que les noeuds devraient adopter
lorsqu'une variable surveillée dépasse un certain seuil, malheureusement cela ne fait
pas partie de nos objectifs.

MRTG et CACTI permettent l'édition de graphes représentant l'état du réseau à un

moment donnée. CACTI édite même ces graphes de manière dynamique (contrairement
à MRTG qui ne le fait que tout les cinq minutes), il permet donc une surveillance plus
précise du réseau ou de l'utilisation d'un processeur ou d'un disque dur. Encore une
fois, cela ne nous est d'aucune utilité dans le cadre de notre projet.
Cependant, SNMP permet malgré tout de faire l'inventaire des logiciels présent sur un
ordinateur.

3.2.3 Points faibles

L'inventaire des logiciels d'un ordinateur se fait malheureusement sans interface
graphique et de manière très archaïque.
Les logiciels inventoriés sont exclusivement les logiciels présents dans le registre de
Windows. De plus les informations relatives aux programmes sont groupées par type
d'information et non par programme, le seul moyen de faire correspondre une infor-
mation (la date d'installation par exemple) à son programme est son numéro dans la
liste...

Quand bien même nous aurions eu le temps de remédier à ces lacunes d'interface
et de fonctionnalités, l'utilisation du protocole en elle même parait risquée car peu
sécurisée (mot de passe transmis sans cryptage ...).
CHAPITRE 3. ETUDE DE L'EXISTANT 26

3.3 OCS Inventory NG

3.3.1 Vue d'ensemble
OCS Inventory NG est un logiciel open-source spéciquement conçu pour aider l'ad-
ministrateur système ou réseau à garder un oeil sur la conguration des machines du
réseau et sur les logiciels qui y sont installés.
Ce logiciel permet de récupérer quasiment toutes les informations dont nous pourrions
avoir besoin, tant sur le matériels que sur les logiciels. Parmi les informations récoltées
par OCS Inventory NG, on cite le bios, processeur, slot mémoire, système d'exploita-
tion, logiciels etc...

Il possède une interface conviviale et claire en PHP, qu'il nous est possible de modi-
er pour l'adapter à nos besoins pour détecter tout périphérique actif sur le réseau ,
comme les commutateurs, routeurs, imprimantes et autres matériels inattendus. Pour
chacun, il stocke les adresses MAC et IP et vous autorise à les classier.
Si le serveur d'administration fonctionne sous Linux, et que nmap et smblookup sont
disponibles, il est possible aussi de scanner une IP ou un sous-réseau pour des infor-
mations détaillées sur les hôtes non inventoriés.

3.3.2 Architecture d'OCS Inventory NG

Parmi les points forts du choix d'OCS Inventory NG, on trouve sa capacité de ré-
cupérer toute la conguration matérielle (processeur, mémoire, réseau, écran...), ainsi
que la liste de la plupart des logiciels installés via le gestionnaire de programmes du
système d'exploitation (registre sous Windows, RPM ou DEB sous Linux). Il est éga-
lement possible d'obtenir certaines valeurs des clés du registre sous Windows.

An de réaliser cette tâche, une simplicité de déploiement des agents est oerte. En
eet, il peut s'eectuer à distance pour l'agent Windows. Alors quant à l'agent Linux,
il doit se déployer à la main mais il est toutefois fourni avec un script d'installation.
Par la suite, la mise à jour des agents déjà installés peut se faire automatiquement.
La communication entre agents et serveur de gestion se fait simplement par le protocole
HTTP/HTTPS à l'aide de données XML compressés (ce qui optimise l'utilisation de
la bande passante). Les informations sont stockées dans une base MySQL.
CHAPITRE 3. ETUDE DE L'EXISTANT 27

Figure 3.1  Architecture d'OCS Inventory

D'autre part, l'architecture OCS Inventory NG inclut aussi des fonctionnalités

de mise à jour automatisées des informations d'un ordinateur. En eet, l'agent peut
envoyer ses informations au serveur de gestion de façon régulière, avec un système de
délai aléatoire qui évite la surcharge du serveur. Le serveur peut également demander
une mise à jour à n'importe quel moment.

OCS Inventory NG présente une interface web conviviale (ocsreports) qui faci-
lite la consultation de la base de données. Cette interface permet, entre autres, de
rechercher facilement un ordinateur suivant un grand nombre de critères, de consulter
les informations d'un ordinateur par catégorie, de classer les postes à l'aide de " tag
" : une fonctionnalité permettant d'assigner une valeur spécique à une poste.
Au niveau du code d'OCS, la conception intègre un système de modules, permettant
d'ajouter facilement des traitements au code principal à diérents moments de
l'inventaire, ce qui facilite le travail à eectuer.
CHAPITRE 3. ETUDE DE L'EXISTANT 28

3.3.3 Points faibles d'OCS

OCS Inventory NG possède cependant certains points faibles.
En premier lieu, OCS n'est pas capable de détecter tous les logiciels installés sur un
poste. Certains logiciels sans installation, comme Eclipse n'apparaissent pas dans l'in-
ventaire. La gestion des utilisateurs et de l'authentication dans l'interface sont très ba-
siques, et certaines informations sensibles ne sont pas cachées aux non-administrateurs.

La gestion des machines en dual boot est loin d'être parfaite. OCS est capable de
détecter les doublons selon une série de critères, mais rien n'est prévu pour empêcher
la fusion des doublons dans le cas d'un OS diérent (à moins d'empêcher la fusion des
doublons purement et simplement).

3.3.4 Conclusion
OCS Inventory NG est une solution complète d'inventaire qui représente une base
solide et modiable pour ce projet. Les possibilités d'amélioration et d'intégration
à l'environnement existant sont nombreuses tout en restant faisables dans le temps
imparti. Il s'agit donc à nos yeux du meilleur candidat et nous avons décidé de baser
notre travail dessus.

3.4 GLPI
3.4.1 Vue d'ensemble
GLPI (Gestion Libre de Parc Informatique) est une application Web libre, distribuée
sous licence GPL destinée à la gestion de parc informatique.
GLPI est composé d'un ensemble de services web écrits en PHP qui permettent de
recenser et de gérer l'intégralité des composants matérielles ou logicielles d'un parc
informatique et ainsi, d'optimiser le travail des techniciens grâce à une maintenance
plus cohérente.

Les fonctionnalités principales de l'application s'articulent autour de deux axes :

 L'inventaire précis de toutes les ressources techniques, matérielles et logicielles,
existantes dont les caractéristiques sont stockées dans une base de données.
CHAPITRE 3. ETUDE DE L'EXISTANT 29

 La gestion et l'historisation, des diverses opérations de maintenance et de procé-

dures liées, réalisées sur ces ressources techniques.

Figure 3.2  Principe de fonctionnement de GLPI

Enn, cette application a pour but d'être dynamique et directement reliée aux utili-
sateurs. Une interface autorise donc ces derniers à éventuellement prévenir le service de
maintenance et à répertorier un problème rencontré avec l'une des ressources techniques
à laquelle ils ont accès.

3.4.2 Fonctionnalité du GLPI

GLPI propose énormément de fonctionnalités intéressantes qui facilitent son utili-
sation et qui dépassent les exigences du sujet. Il permet la gestion Multiutilisateurs
en fournissant un système d'authentication et de permissions multiple (local, LDAP,
Active Directory, Pop/Imap).
On pourra noter la possibilité de grouper les machines par critères géographiques, la
gestion et l'export de plannings, génération de rapports sur le matériel, le réseau ou
les interventions.
CHAPITRE 3. ETUDE DE L'EXISTANT 30

Comme son nom l'indique, GLPI est bien plus qu'un simple logiciel d'inventaire. Il
permet aussi la gestion d'un parc informatique avec un module Helpdesk qui centralise
les demandes d'intervention, un module qui gère les contacts des entreprises extérieurs
pour les interventions, etc.
Enn, un aspect intéressant à signaler, est le fait de pouvoir, en tant qu'utilisateur,
demander une intervention ou de réserver du matériel.

3.4.3 Point faibles

Pour inventorier les ordinateurs, GLPI a besoin d'OCS Inventory NG déployé sur
le réseau, il faudrait donc faire le travail d'adaptation deux fois, une fois pour OCS et
ensuite pour GLPI. D'où la nécessité d'une synchronisation entre les deux applications
an de simplier la tâche comme la montre la gure ci-dessous.

Figure 3.3  Synchronisation OCS NG/GLPI

3.4.4 Conclusion
Etant donné le temps dont nous disposons pour ce projet, il ne nous est pas possible
de travailler sur deux logiciels, d'où nous avons juste préparé la partie théorique de
GLPI an de l'intégrer ultérieurement.
CHAPITRE 3. ETUDE DE L'EXISTANT 31

Conclusion
Ce chapitre nous a permis d'amener une étude préalable de notre projet tout en
exploitant les produits existant sur le marché, évaluant leurs performances et propo-
sants les solutions les plus adaptées an de remédier aux insusances qu'ils présentent.
Les objectifs étant éclaircis, nous spécierons dans le chapitre suivant clairement les
fonctionnalités de notre système.
 Deuxième partie

Spécication et conception
CHAPITRE

4 Spécication des besoins

Introduction
OUR garantir une bonne spécication du logiciel, des rencontres entre le client et
P le réalisateur est inévitable. Ceci permettra aux analystes de bien comprendre les
besoins an de réaliser une bonne conception de l'application. Dans ce chapitre, nous
commencerons par une étude préliminaire qui consiste à repérer les besoins fonction-
nels et non fonctionnels. Par la suite, nous passerons à une modélisation détaillée en
diagramme de cas d'utilisation pour aboutir à une formalisation claire de ce qui a été
établi au cours de cette étude.

4.1 Les besoins fonctionnels

L'application consiste à développer des interfaces qui permettent de gérer un inven-
taire d'un parc informatique en se basant sur le noyau d'OCS Inventory NG en liaison
avec GLPI.
Module Inventaire
 Le système doit fournir un inventaire complet de toutes les machines connectées
au réseau de l'entreprise.
 Le système doit être capable de lister les informations de l'inventaire en détails
pour chaque machine.
 Le système doit être muni d'un moteur de recherche facile à utiliser et donnant à
l'utilisateur la possibilité de raner sa recherche en imposant ses propres critères
(par IP, nom, MAC, ).
Module télé-déploiement
 Le système doit prévoir une conguration par défaut lors de l'installation du
module de télé-déploiement.
CHAPITRE 4. SPÉCIFICATION DES BESOINS 34

 L'application doit assurer une première interface pour la création de paquet, une
deuxième pour l'aectation et la dernière pour visualiser l'état du déploiement
(succès, erreur d'exécution,)
 L'application doit concevoir une interface pour le suivi de l'état de déploiement.
 Les fonctions de création et activation devrons être fusionnées et automatisées.
 L'application doit être capable de sauvegarder tous les traitements à l'aide d'une
base de données.
Module Helpdesk
 L'application doit assurer une liaison OCS/GLPI automatique.
 L'application doit intégrer le module helpdesk de GLPI avec toutes ses fonction-
nalités dans la solution SURA.

4.2 Les besoins non-fonctionnels

Quelques aspects classiques des sites web seront aussi à prendre en compte :
 L'interface doit être cohérente du point du vue de l'agronomie : l'interface de l'ap-
plication doit être simple et utilisable an 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.
 Besoin de portabilité et modularité : l'application devra être multiplateforme et
modulaire an de garantir la souplesse et l'évolutivité de la solution.
 Rapidité et intégrabilité dans d'autres applications : l'application devra être ra-
pide et assure que les modules seront intégrable et utilisable dans d'autre appli-
cations.
 Sécurité : l'application doit assurer la sécurité de transfert de paquets entre le
serveur et le client lors d'une opération par une liaison SSL.

4.3 Spécication semi formelle

Pour réussir une bonne spécication des besoins, ces derniers doivent être modélisés,
ce qui facilite la compréhension des problèmes et la communication entre les diérents
acteurs impliqués dans un projet. La modélisation améliore la lisibilité des schémas de
conception et facilite la maintenance du système.
CHAPITRE 4. SPÉCIFICATION DES BESOINS 35

4.3.1 Présentation des acteurs

Les acteurs se recrutent parmi les utilisateurs du système et aussi parmi les res-
ponsables de sa conguration et sa maintenance. Dans notre cas, il ya deux acteurs
principaux :
 Administrateur : l'administrateur est un super utilisateur ayant le droit d'eec-
tuer toutes sortes d'opérations tel que la conguration du système, la supervision
des machines, la mise à jour du système, le contrôle des connexions
 Agent :l'agent peut se connecter et accéder aux paquets aectés an de les
télécharger, les stocker ou les exécuter

4.3.2 Les diagrammes des cas d'utilisation

Un cas d'utilisation est une abstraction d'une partie du comportement du système
par une instance d'un acteur an de structurer les besoins des utilisateurs et les objectifs
d'un système.

4.3.2.1 Diagramme de cas d'utilisation de l'administrateur d'OCSI NG

Une fois l'administrateur est connecté, deux opérations de base sont accessibles : le
télé-déploiement des paquets et la gestion de l'inventaire.
En eet, l'application ore à l'administrateur d'OCSI NG la possibilité de créer les
paquets et les aecter. Et par la suite, elle permet de visualiser leur statut de déploie-
ment, an de s'assurer si tout marche bien.
En un deuxième lieu, des analyses régulières de la conguration matérielle et logicielles
sont faites toutes les 24 heures permettant de mettre à jour l'état d'inventaire sur
le serveur de base de données. La liste des machines inventoriées est accessible par
l'administrateur soit pour la consulter, soit pour la mettre à jour.

Les détails de ce cas d'utilisation sont donnés par la gure suivante.

CHAPITRE 4. SPÉCIFICATION DES BESOINS 36

Figure 4.1  Diagramme de cas d'utilisation de l'administrateur OCSI NG

4.3.2.2 Diagramme de cas d'utilisation de l'administrateur GLPI

Pour assurer la gestion du parc informatique, l'administrateur GLPI possède les
privilèges d'eectuer plusieurs congurations an d'améliorer les performances du sys-
tème ou pour le rendre ergonomique transparent et plus sécurisé. A titre d'exemple,
il possède la permission de contrôler le suivi des tickets, d'ajouter un nouveau, de
consulter leur historiques, de planier les interventions comme le montre le diagramme
ci-dessous :
CHAPITRE 4. SPÉCIFICATION DES BESOINS 37

Figure 4.2  Diagramme de cas d'utilisation de l'administrateur GLPI

4.3.2.3 Diagramme de cas d'utilisation de l'agent

L'agent ou le propriétaire d'une machine sur le réseau a la permission de se connecter
et d'accéder aux données et aux services oertes par le système. En eet, quand l'agent
contacte le serveur de communication, celui-ci lui indique qu'il y a un ou plusieurs
paquets à déployer, avec le niveau de priorité de chaque paquet et où il peut télécharger
le chier d'information du paquet. L'agent commence alors à télécharger les fragments
puis exécute l'action voulu et renvoie le code résultat au serveur de communication.

Figure 4.3  Diagramme de cas d'utilisation de l'agent

CHAPITRE 4. SPÉCIFICATION DES BESOINS 38

Conclusion
Ce chapitre nous a permis de couvrir tous les cas d'utilisations concernant les dif-
férents utilisateurs de notre présent système et de dénir les besoins non fonctionnels
à prendre en considérations an de satisfaire les utilisateurs. La spécication des be-
soins étant établie, nous essayerons dans le chapitre suivant de concevoir clairement
l'architecture de notre système.
CHAPITRE

5 Conception

Introduction
E nombreuses applications fonctionnent selon un environnement client/serveur,
D c'est le cadre que notre application se situe. Il s'agit donc dans ce qui suit d'en
xer l'architecture tout en se référant aux architectures et aux modèles précédemment
cités. Ainsi, ce chapitre sera dédié pour la conception architecturale de notre application
et pour la conception détaillée.

5.1 Conception architecturale

5.1.1 Architecture de l'application
Notre système proposé repose sur une architecture n-tiers (cf. Figure 5.1). C'est un
modèle logique d'architecture applicative qui vise à séparer nettement n couches logi-
cielles au sein d'un même système (généralement 3 ou 4 couches). Elle sert à modéliser
et présenter cette application comme un empilement de " n " couches (appelées aussi
étages, ou niveaux) dont le rôle est clairement déni comme suit :
 La représentation des données : contient les interfaces utilisateurs (navigateur
web).
 La couche de contrôle : c'est dans cette couche qu'on retrouve l'ensemble des
traitements représentant les règles métiers de l'application.
 Le traitement métier des données : correspondent à la mise en uvre de l'ensemble
des règles de gestion applicative.
 L'accès aux données persistances : correspondant aux données qui sont destinées
à être gardées sur une longue durée, voir de manière persévérante.
CHAPITRE 5. CONCEPTION 40

Dans cette approche, les couches communiquent entre elles à travers d'un " modèle
d'échange " et chacune d'entre elles propose un ensemble de services rendus. Les ser-
vices d'une couche sont mis à la disposition de la couche supérieure. On s'interdit par
conséquent qu'une couche invoque les services d'une couche plus basse que la couche im-
médiatement inférieure ou plus haute que la couche immédiatement supérieure (chaque
niveau ne communique qu'avec ses voisins immédiats). Le rôle de chacune des couches
et leur interface de communication étant bien déni, les fonctionnalités de chacune
d'entre elles peuvent évoluer sans induire de changements dans les autres.

Ce modèle n-tiers a pour objectif de répondre aux préoccupations suivantes :

La exibilité : Les applications sont sujettes à des changements structurels fréquents
à cause de la mutation rapide des technologies c'est pourquoi l'ajout de nouveaux
modules est primordiale pour la pérennité de l'application.
La scalabilité : est la capacité que l'architecture ore pour évoluer en cas de montée
en charge si nécessaire. En eet, chaque module peut être déployé indépendamment
des autres sur une machine, ou un cluster de machines. Ce qui permet d'ajouter
des ressources si nous avons besoin.
La modularité : est une approche structurante qui sépare un logiciel en petites unités
qui rassemblées composeront l'ensemble d'un logiciel. Cette approche permet non
seulement une certaine réutilisation de certaines unités de traitements mais aussi
une très grande souplesse dans la modication puisque le changement d'un module
n'implique pas le changement de tous les autres.
CHAPITRE 5. CONCEPTION 41

Figure 5.1  Architecture générale de l'application

CHAPITRE 5. CONCEPTION 42

Concernant la base de données, nous optons pour un système de base de données

suivant :

Figure 5.2  Architecture générale de la base de données répartie

Ce système fonctionne suivant ces règles :

1. Toutes les tables sur les bases de données locales possèdent le même schéma de
données que celle correspondantes sur le serveur.
2. Des triggers sont installés au niveau des bases de données locales. Chaque modi-
cation sur la base locale (insertion, suppression, ou mise à jour) s'eectue auto-
matiquement sur la base Serveur.
3. La base Serveur contient les données de toutes les bases locales.
La connexion entre les bases de données via le réseau soit locale, soit sur Internet,
permettra l'échange des données.

5.1.2 Architecture du site

L'application présente une vue simple à utiliser pour les administrateurs (cf. Figure
5.3) an de gérer librement leurs diérentes tâches.
CHAPITRE 5. CONCEPTION 43

Figure 5.3  Architecture du site : vue administrateur

5.2 Conception détaillée

Ayant dégagé les diérents acteurs et énuméré les objets nécessaires lors du pré-
cédent chapitre et après avoir décrit la conception générale de l'application, on doit
désormais détailler la conception de l'application en décortiquant les diérentes classes
d'une telle application et en dénissant en détails notre base de données.
Pour cela, la notion UML a été adoptée an de réussir la modélisation des diérents
modules ainsi que leurs interactions et les diérentes vues statiques et dynamiques du
système.

5.2.1 Conception de la base de données

5.2.1.1 Modèle entité/association
La base de données du système est d'une utilité majeur. An de détailler son archi-
tecture, nous avons conçu un modèle entité/association décrit par la gure ci-dessous :
CHAPITRE 5. CONCEPTION 44

Figure 5.4  Modèle entité/association

CHAPITRE 5. CONCEPTION 45

5.2.1.2 Modèle relationnel de la base

Il existe plusieurs types de base de données (hiérarchiques, relationnelles, orientées
objet) la plus connue et commune au point de vue implémentation est celle relation-
nelle qui sera adoptée pour la conception et l'implémentation de la base de notre
système.
La base de données relationnelle du système est basée sur celle d'OCS Inventory NG
que nous donnons une description des champs des tables principales suivantes :

 Devices( #HARDWARE_ID, NAME, IVALUE, TVALUE, COMMENTS,

#hardwareDEVICEID ).
 Accountinfo(HARDWARE_ID, TAG).
 Tags( #TAG , LOGIN).
 Deploy(NAME, CONTENT).
 Download_enable( #ID,FILEID, INFO_LOC, PACK_LOC, CERT_PATH,
CERT_FILE, SERVER_ID, #hardwareDEVICEID
).
 Download_aect-rules(ID, RULE, PRIORITY, CFIELD, OP, COMPTO,
SERV_VALUE, RULE_NAME).
 Engine_persistent(ID , #NAME
, IVALUE, TVALUE)

5.2.2 Les diagrammes de séquence

Le diagramme de séquence permet de représenter des collaborations entre objets
selon un point de vue temporel, on y met l'accent sur la technologie des envoies de mes-
sages. On présentera dans ce qui suit les diagrammes de séquences les plus importants
qui illustrent les cas d'utilisation déjà décrits.
CHAPITRE 5. CONCEPTION 46

5.2.2.1 Diagrammes de séquence de l'administrateur

Scénario de l'authentication de l'administrateur

Figure 5.5  Diagramme de séquence d'authentication de l'administrateur

Une tâche très importante est celle de l'ouverture d'une session pour l'administrateur.
Le diagramme précédent décrit la séquence à suivre. En eet, l'administrateur doit
saisir son login et son mot de passe qui seront vériés par le système en se connectant
à la base de données et en validant l'authentication.

Scénario de la consultation de l'inventaire des machines

Une fois l'administrateur est connecté, deux opérations sont possibles pour gérer l'in-
ventaire : soit il choisit de visualiser toutes les machines, soit de les consulter chacune
à part. Les deux gures ci-dessous décrivent les deux scénarios cités.
CHAPITRE 5. CONCEPTION 47

Figure 5.6  Diagramme de séquence d'achage de l'inventaire

Figure 5.7  Diagramme de séquence de consultation d'un inventaire d'une machine

CHAPITRE 5. CONCEPTION 48

Scénario de création d'un paquet de déploiement

Le diagramme de séquence ci-dessous décrit le processus de création d'un paquet
de déploiement par l'administrateur. En eet, après le choix d'un chier à déployer,
l'administrateur passe sa demande au système et saisie les informations nécessaires
pour la création du paquet tel que le nom, le chier, l'action du chier, la priorité
Par la suite, un script d'activation automatique se lance et un message le signale du
succès de l'opération.

Figure 5.8  Diagramme de séquence de création d'un paquet de déploiement

Scénario d'aectation d'un paquet de déploiement]

Une fois activé, le paquet est prêt à être aecté. L'administrateur sélectionne
une machine soit par recherche, soit de la liste des machines inventoriées. Ensuite, il
lui associe un paquet voulu. La gure suivante explique en mieux les diérents échanges.
CHAPITRE 5. CONCEPTION 49

Figure 5.9  Diagramme de séquence d'aectation d'un paquet

5.2.2.2 Diagramme de séquence de l'agent

Suite à l'aectation des paquets, une notication sera envoyée par le système vers
les agents. Donc, an de les télécharger et les exploiter, l'agent nécessite un certicat
SSL pour assurer le transfert des paquets entre le serveur et sa machine.
CHAPITRE 5. CONCEPTION 50

Figure 5.10  Diagramme de séquence de téléchargement d'un paquet

CHAPITRE 5. CONCEPTION 51

5.2.3 Conception des couches

Notre système, étant réparti en plusieurs couches indépendantes, nous proposons
dans cette partie de les énumérer, de détailler la présentation de chaque couche et de
spécier son apport à notre application.

5.2.3.1 Couche présentation

An d'augmenter l'interactivité de l'utilisateur avec notre système, nous avons re-
cours à un ensemble de vues claires et conviviales permettant l'échange dynamique
des données. La conception de cette couche consiste alors à mettre en place un dos-
sier OCSVE contenant l'ensemble des outils tels que CSS, image, JavaScript, Views
et langages nécessaires pour la présentation des vues pour les administrateurs et les
agents.

Figure 5.11  Architecture de la couche présentation

CHAPITRE 5. CONCEPTION 52

5.2.3.2 Couche de contrôle

Cette couche est implémentée selon le modèle MVC. Le contrôleur est le coeur de
notre application web. Tous les traitements de l'administrateur ou de l'agent transitent
par lui. Il est dénit par des codes JavaScript qui prennent les informations dont il a
besoin à partir des formulaires.

5.2.3.3 Couche métier

Pour faciliter la maintenance du système et augmenter la réutilisation de ces compo-
santes, nous avons décidé de séparer les traitements métier suivant les tables de la base
de données du système, c'est-à-dire que nous allons regrouper pour chaque table toute
la logique qui peut s'y appliquer dans une seule classe de la couche métier. Chaque
classe métier fournit toutes les méthodes gérant le traitement métier appliqué sur la
table correspondante.

5.2.3.4 Couche de persistance

C'est la couche la plus basse de notre système. Implémentée par MySQL, la mani-
pulation de la base de données relationnelle s'avère plus pratique suite à la facilité de
manipuler les données sous forme d'objets. En eet, cela permet de défaire de toute la
couche SQL lors de la manipulation de la base de l'application. De plus, cela permet
de dénir la limite entre la persistance et la couche métier, ce qui révèle très utile dans
le cas d'une application trois-tiers.

Notre couche de persistance se compose alors de deux classes particulières, de quatre

chiers de congurations et de trois packages.
Les deux classes sont FichierConf et Req. La classe FichierConf est une fabrique de
sessions qui permet d'instancier des sessions. Alors que la classe Req, comme son nom
l'indique permet l'ouverture et la fermeture des sessions avec la base de données.
Le diagramme de la gure suivante décrit les diérentes classes relatives aux acteurs
du système à savoir l'authentication, les opérations de gestion de l'inventaire, de télé-
déploiement, du helpdesk et de la gestion de la base de données.
CHAPITRE 5. CONCEPTION 53

Figure 5.12  Diagramme de classe de l'application

Conclusion
A travers ce chapitre, nous avons présenté notre conception de l'application. Nous
avons fourni, dans un premier lieu, une conception globale à travers un schéma générale
décrivant l'organisation de notre système. Ensuite, nous avons présenté la conception
détaillée de l'application à travers les diagrammes de classe et des scénarios. A présent,
nous sommes capables d'entamer la partie réalisation.
Troisième partie

Réalisation
CHAPITRE

6 Réalisation

Introduction
PRÈS avoir décortiqué la partie conception, il sagit désormais de présenter la
A partie réalisation de notre application. Pour cela, nous procéderons, dans ce cha-
pitre à la spécication de l'environnement logiciel de développement et l'argumentation
du choix des langages de programmation. Nous terminerons ce chapitre par présenter
et décrire quelques interfaces de notre application.

6.1 Environnement et outils de travail

6.1.1 Environement matériel
L'environnement matériel utilisé pour le développement de notre application se
compose de trois ordinateurs dont deux ont les caractéristiques suivantes :
 Processeur Pentium 4 de 3 GHz de vitesse
 Un disque dur de capacité 80 Go
 Une RAM de 512 Mo
 Système d'exploitation Linux Debian
Et un a les caractéristiques suivantes :
 Processeur Intel Core 2 Duo de 2.20 GHz
 Un disque dur de capacité 360 Go
 Une RAM de 2 Go
 Système d'exploitation Windows XP Service Pack 3
CHAPITRE 6. RÉALISATION 56

6.1.2 Environnement logiciel

Système d'exploitation : Linux Debian

Outils de développement : Eclipse 3.4 avec le plugin PHP5. En eet, Eclipse est
un outil développement libre conçu pour Java en générale, mais avec le plugin
PHP5, Eclipse ore des solutions de développement PHP multiplateforme et un
environnement de développement très convivial et très adapté à la plateforme
Linux. Cet outil ore des technologies pour créer et déployer rapidement des ap-
plications PHP, Web et base de données avec un éditeur de code source extensible,
un compilateur et surtout des concepteurs visuels très simple à utiliser. En plus, il
ore les technologies d'audit de code et d'audit d'erreur qui nous permet d'éviter
les erreurs de syntaxes.

Outil de conception : Visual Paradigm for UML 7.0 est un outil de conception qui
permet de procéder à une analyse et une modélisation objet basées sur le standard
UML (diagramme de cas d'utilisation, de séquence, de classes, etc.).

Serveur de base de données : MySQL 5 est le serveur de gestion de base de don-

nées relationnels utilisé par OCS Inventory NG pour stocker les données.

Langage de programmation : OCS Inventory NG utilise le PHP 5 comme un lan-

gage de programmation. En eet, ce langage a subit une évolution à noter vu que
le côté orienté objet commence réellement être susamment performant avec PHP
5 et devrait être parachevé avec PHP 6.

6.2 Principales interfaces graphiques

Nous avons réalisé pour une meilleure convivialité et interactivité de l'application
une interface graphique présentant les diérentes fonctionnalités de notre prototype.
Dans ce que suit, nous présenterons notre application à travers quelques captures
d'écran.

6.2.1 Page d'Authentication

Cette interface présente un formulaire de connexion permettant l'utilisateur de
s'identier pour qu'il soit autorisé à la consultation du site.
CHAPITRE 6. RÉALISATION 57

Figure 6.1  Page de connexion de l'utilisateur

6.2.2 Page d'Accueil

La page d'accueil de notre application, donne la liste de toutes les machines inven-
toriées sur le réseau soit local, soit sur Internet. Chaque machine est décrite par sa
dernière connexion, son adresse IP, le système d'exploitation installé ...
En outre, cette page groupe les liens vers tous les cas d'utilisation vu dans les chapitres
précédents tel que la recherche et la consultation de l'inventaire ...

Figure 6.2  Page d'Acceuil

CHAPITRE 6. RÉALISATION 58

6.2.3 Page Détail d'une machine

Cette page donne la conguration complète et en détail de la machine inventoriée
en cours. Un menu d'illustration aide l'utilisateur à ltrer le niveau de détail voulu.

Figure 6.3  Page détail d'une machine

CHAPITRE 6. RÉALISATION 59

6.2.4 Page de Recherche

An de faciliter la tâche de l'utilisateur, cette page retourne le résultat de la re-
cherche des machines dans la base de données suivant des critères choisis. En eet, une
liste de machines sera crée, aché et manipuler par l'utilisateur.

Figure 6.4  Page de recherche

CHAPITRE 6. RÉALISATION 60

6.2.5 Page de Création d'un paquet

Cette interface permet à l'administrateur de remplir un formulaire avec les infor-
mations nécessaires pour la création d'un paquet tel que le chier voulu, le protocole
utilisé, l'action à faire, an de le télé-déployer ultérieurement.

Figure 6.5  Page de création d'un paquet

CHAPITRE 6. RÉALISATION 61

6.2.6 Page d'Aectation de paquets

Notre système fournit cette page an d'aecter des paquets sur les ordinateurs
clients. Cette liste donne des informations sur l'état des paquets : nom, nombre de
fragments, chemin, priorité... Pour chaque machine inventoriée, on associe un bouton
aecter, à chaque fois on choisit, un script automatique sera lancer an de notier les
agents de la possibilité de télécharger un nouveau paquet.

Figure 6.6  Page d'aectation de paquets

6.2.7 Page de statut de paquets

L'interface ci-dessous est conçue pour le suivi de l'état de déploiement.

Figure 6.7  Page de statut de paquets

CHAPITRE 6. RÉALISATION 62

6.3 Problèmes rencontrés

Le long du présent travail nous nous sommes trouvés face à plusieurs corvées im-
prédictibles que nous avons essayé de surmonter :
 Une diculté certaine consistait à comprendre et à reprendre un code déjà exis-
tant. La manque de connaissance des langages PERL et C++ a apporté son lot
de complications lors du développement des modules.
 Le code existant n'étant pas parfait, certaines incohérences ont dû être corrigées
pour permettre le fonctionnement des modules développés.
 Enn, le déploiement aussi a apporté son lot de problèmes : le module php5-
curl est nécessaire au fonctionnement de notre système ; la redirection lors de la
connexion ne fonctionne pas sur le serveur de test, le script d'installation n'était
pas capable de mettre à jour la table operotors correctement, le déploiement a
échoué car des agents étaient déjà installés

Conclusion
Au cours de ce chapitre, nous avons décrit les plates-formes matérielles et logicielles
sur lesquelles nous avons construit notre application. Nous avons, ensuite, présenté
les interfaces les plus signicatives de notre application. Enn nous avons clôturé ce
chapitre par la des problèmes rencontrés le long de l'élaboration de ce projet.
 Conclusion générale et
Perspectives
OTRE projet s'agit de concevoir et d'intégrer deux open sources OCS Inventory
N NG et GLPI dans la plateforme SURA qui permettent la gestion des machines
inventoriées et le télé-déploiement de paquets d'une part, et la gestion d'un parc infor-
matique d'autre part.

En premier lieu, nous avons commencé par une présentation générale du problème
à aborder en allant de l'énumération des avantages et des inconvénients des solutions
présentes au marché, à l'étape de l'analyse et de spécication pour nir par la xation
des besoins de l'application en montrant les diérents cas d'utilisation. En troisième
lieu, nous avons entamé la conception de l'application en donnant un aperçu sur les
principales classes et méthodes utilisée. Enn, nous avons laissé la dernière partie à la
réalisation dans laquelle nous avons sélectionné les technologies les plus adaptées à notre
choix techniques, pour nir par une illustration des diérentes interfaces graphiques de
notre application qui pourra servir comme un guide d'utilisation du site.

Dans le cadre de ce projet, nous avons eu l'opportunité d'apprivoiser de nouvelles

notions telles que le modèle MVC et l'architecture N-tiers. Nous avons eu aussi l'op-
portunité de nous familiariser avec des technologies récentes telles que PHP 5.
Autre attrait de ce projet était aussi de pouvoir travailler avec des open sources tels que
GLPI et OCS Inventory NG et des logiciels libres tels que l'IDE Eclipse et le SGBDR
MySQL et d'apprécier la qualité des services oerts par ce type de logiciels.

Nous avons atteint l'objectif du projet en développant les principales fonctionnalités

désirés dans le cahier de charge dans le temps programmé bien qu'une grande partie
du temps du projet a été consacrée à l'apprentissage de nouvelles technologies.

En perspective, cette application pourrait être améliorée par l'intégration de nou-

veaux modules tels que le portage des modules vers la nouvelle version d'OCS Inven-
tory NG (pas encore sortie), avec une conversion du module client vers le nouveau
CONCLUSION GÉNÉRALE ET PERSPECTIVES 64

"unied_unix_agent" et la conversion des modules d'OCS hard codés dans la partie

conguration de l'interface vers notre nouveau système de module générique.
ANNEXE

A Annexe 1

Voici un poster décrivant le fonctionnement complet de toutes les fonctionnalités

du produit OCS Inventory NG !
 Déploiement des agents Windows par scripts ou GPO
 Inventaire des machines
 Découverte du réseau par les agents
 Télédéploiement de paquets
 Produit tier de gestion de parc interrogeant la base de données OCS Inventory
NG via SOAP

Figure A.1  Schéma de fonctionnement d'OCS Inventory NG

 Bibliographie

[1] T. Converse, PHP5 and MySQL ,Bible,2004.

[2] A. Barr, Software Trends at the Help Desk , (pp. 1037), Standford,1992.
http ://www.stanford.edu/group/scip/avsgt/helpdesk/helpdesk.html (consulté le
10 juillet 2009).
[3] N. Bruton, Helpdesk management reporting ,1997b. http ://www.bruton.win-
uk.net/pages/articles.htm(consulté le 12 juillet 2009).
[4] J. Doléans, Le projet GLPI LOGCRI,2007. http ://creativecom-
mons.org/(consulté le 20 juillet 2009).
[5] J. Doléans, Le projet GLPI LOGCRI,2007. http ://creativecom-
mons.org/(consulté le 20 juillet 2009).
http ://www.ocsinventory-ng.org/
 Netographie

[N1] www.ocsinventory-ng.org, consulté le 26 Juin 2009

[N2] www.developpez.com, consulté le 28 Juin 2009

[N3] www.php.com, consulté le 28 Juin 2009

[N4] demo.glpi-project.org, consulté le 30 juin 2009

[N5] svn2.assembla.com/svn/ProjetS6-OCS, consulté le 15 Juillet 2009