Final
Final
Final
Remerciements ii
Résumé iii
Abstract iv
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
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
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
A Annexe 1 65
Bibliographie 66
Netographie 67
Liste des gures
1.1 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
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.
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.
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.
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
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.
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.
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.
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.
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).
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
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
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.
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.
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
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.
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.
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
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.
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.)
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.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
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.
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
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.
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
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
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.
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.
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.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
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.
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.
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.
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.
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.
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.
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.
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.).
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.
A Annexe 1