Signature de l'encadrant

Mr. Zarrouk Hichem

Remerciements
VANT d'entreprendre l'exposé de ce rapport, nous présentons tous nos remerciements à tous ceux qui ont bien voulu apporter l'assistance nécessaire au bon déroulement de ce stage.

A

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 machines 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
réseau.

: Inventaire, parc informatique, open source, OCS Inventory, GLPI,

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 Résumé Abstract Liste des gures Introduction générale

ii iii iv ix 1

I Etude préalable
1 Présentation du cadre de travail et du sujet
1.1 Présentation de l'organisme d'accueil . . . . . . . . . . . . . . . . . . . 1.1.1 1.1.2 1.2 1.3 Présentation générale de VE TUNISIE . . . . . . . . . . . . . . Domaines d'activité et services oerts . . . . . . . . . . . . . . .

3
4
4 4 5 6 7 7 8 8

Enoncé de la problématique . . . . . . . . . . . . . . . . . . . . . . . . Conduite du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 1.3.2 1.3.3 Equipe du projet . . . . . . . . . . . . . . . . . . . . . . . . . . Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning de réalisation . . . . . . . . . . . . . . . . . . . . . . .

2 Etat de l'art
2.1 Les technologies du Web . . . . . . . . . . . . . . . . . . . . . . . . . .

10
10

TABLE DES MATIÈRES

vi

2.1.1 2.1.2 2.2 2.2.1 2.2.2 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.4 2.4.1 2.4.2 2.4.3 2.4.4

Description des architectures distribuées . . . . . . . . . . . . . Modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dénition d'un inventaire . . . . . . . . . . . . . . . . . . . . . Nécessité d'un inventaire . . . . . . . . . . . . . . . . . . . . . . Vue d'ensemble . . . . . . . . . . . . . . . . . . . . . . . . . . . L'inventaire informatique . . . . . . . . . . . . . . . . . . . . . . L'administration de parc . . . . . . . . . . . . . . . . . . . . . . Le Helpdesk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A propos d'SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . Généralité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . Principe de fonctionnement . . . . . . . . . . . . . . . . . . . .

10 12 14 14 14 15 15 16 16 16 19 19 20 21 21

Notion d'inventaire automatisé . . . . . . . . . . . . . . . . . . . . . . .

Notion du parc informatique et du Helpdesk . . . . . . . . . . . . . . .

Protocole SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Etude de l'existant
3.1 3.2 Mandriva Pulse 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 3.2.3 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.4 3.4.1 3.4.2 Vue d'ensemble . . . . . . . . . . . . . . . . . . . . . . . . . . . Points forts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Points faibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vue d'ensemble . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture d'OCS Inventory NG . . . . . . . . . . . . . . . . . Points faibles d'OCS . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vue d'ensemble . . . . . . . . . . . . . . . . . . . . . . . . . . . Fonctionnalité du GLPI . . . . . . . . . . . . . . . . . . . . . .

24
24 24 24 25 25 26 26 26 28 28 28 28 29

OCS Inventory NG . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

GLPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

TABLE DES MATIÈRES

vii

3.4.3 3.4.4

Point faibles

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

30 30

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

32
33
33 34 34 35 35

5 Conception
5.1 Conception architecturale . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 5.1.2 5.2 5.2.1 5.2.2 5.2.3 Architecture de l'application . . . . . . . . . . . . . . . . . . . . Architecture du site . . . . . . . . . . . . . . . . . . . . . . . . . Conception de la base de données . . . . . . . . . . . . . . . . . Les diagrammes de séquence . . . . . . . . . . . . . . . . . . . . Conception des couches . . . . . . . . . . . . . . . . . . . . . . .

39
39 39 42 43 43 45 51

Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . .

III Réalisation
6 Réalisation
6.1 Environnement et outils de travail . . . . . . . . . . . . . . . . . . . . . 6.1.1 6.1.2 6.2 6.2.1 6.2.2 Environement matériel . . . . . . . . . . . . . . . . . . . . . . . Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . Page d'Authentication Page d'Accueil . . . . . . . . . . . . . . . . . . . . . .

54
55
55 55 56 56 56 57

Principales interfaces graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

TABLE DES MATIÈRES

viii

6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 6.3

Page Détail d'une machine . . . . . . . . . . . . . . . . . . . . . Page de Recherche . . . . . . . . . . . . . . . . . . . . . . . . . Page de Création d'un paquet . . . . . . . . . . . . . . . . . . . Page d'Aectation de paquets . . . . . . . . . . . . . . . . . . . Page de statut de paquets . . . . . . . . . . . . . . . . . . . . .

58 59 60 61 61 62

Problèmes rencontrés . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conclusion générale et Perspectives A Annexe 1 Bibliographie Netographie

63 65 66 67

Liste des gures

1.1 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3.1 3.2 3.3 4.1 4.2 4.3 5.1 5.2 5.3 5.4

Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture 2-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture 3-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Topologie d'un parc informatique . . . . . . . . . . . . . . . . . . . . . Les composantes d'un programme de gestion de helpdesk . . . . . . . . Organisation idéal d'un helpdesk . . . . . . . . . . . . . . . . . . . . . Le protocole SSL/TLS dans son environnement . . . . . . . . . . . . . Phase de négociation SSL . . . . . . . . . . . . . . . . . . . . . . . . . Architecture d'OCS Inventory . . . . . . . . . . . . . . . . . . . . . . . Principe de fonctionnement de GLPI . . . . . . . . . . . . . . . . . . . Synchronisation OCS NG/GLPI . . . . . . . . . . . . . . . . . . . . . . Diagramme de cas d'utilisation de l'administrateur OCSI NG . . . . . . Diagramme de cas d'utilisation de l'administrateur GLPI . . . . . . . . Diagramme de cas d'utilisation de l'agent . . . . . . . . . . . . . . . . . Architecture générale de l'application . . . . . . . . . . . . . . . . . . . Architecture générale de la base de données répartie . . . . . . . . . . . Architecture du site : vue administrateur . . . . . . . . . . . . . . . . . Modèle entité/association . . . . . . . . . . . . . . . . . . . . . . . . .

8 11 12 12 13 15 17 18 20 23 27 29 30 36 37 37 41 42 43 44

LISTE DES FIGURES

x

5.5 5.6 5.7 5.8 5.9

Diagramme de séquence d'authentication de l'administrateur . . . . . Diagramme de séquence d'achage de l'inventaire . . . . . . . . . . . . Diagramme de séquence de consultation d'un inventaire d'une machine Diagramme de séquence de création d'un paquet de déploiement . . . . Diagramme de séquence d'aectation d'un paquet . . . . . . . . . . . .

46 47 47 48 49 50 51 53 57 57 58 59 60 61 61 65

5.10 Diagramme de séquence de téléchargement d'un paquet . . . . . . . . . 5.11 Architecture de la couche présentation . . . . . . . . . . . . . . . . . . 5.12 Diagramme de classe de l'application . . . . . . . . . . . . . . . . . . . 6.1 6.2 6.3 6.4 6.5 6.6 6.7 Page de connexion de l'utilisateur . . . . . . . . . . . . . . . . . . . . . Page d'Acceuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page détail d'une machine . . . . . . . . . . . . . . . . . . . . . . . . . Page de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page de création d'un paquet . . . . . . . . . . . . . . . . . . . . . . . Page d'aectation de paquets . . . . . . . . . . . . . . . . . . . . . . . Page de statut de paquets . . . . . . . . . . . . . . . . . . . . . . . . .

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

Introduction générale
A croissance économique énorme et la dispersion des entreprises gigantesques et multinationales qui caractérisent notre époque accompagnées par le développement technologique, l'augmentation de taille des réseaux et l'informatisation du stockage 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.

L

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 plateformes 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'efcacité 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 existantes. 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 exposant 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 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.

D

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 proposés par VE TUNISIE ciblent les marchés de la maîtrise des communications informatiques, 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 architectures 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 ressources 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, distributeurs/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 Technology.  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 Technology : 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 inventaire 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 problé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éveloppement 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 temps d'approfondir la connaissance du sujet et de dénir les diérentes constituantes 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 existantes. 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.

A

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 modé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 systè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 application 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 maximum 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 automatisé 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 installations 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ériphé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'administrateur 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, surcharge 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, Lansurveyor, 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 informations 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 importante 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 microordinateurs 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 infrastructure, 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 ecaces 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 congurations 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, licences, 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éutiliser des appels et leur suivi pour résoudre des problèmes déjà rencontrés. Le plus important, 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 concevoir 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 utilisateurs, 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 partie 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'analyste 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 transmissions 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 éventuellement 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érication 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 maniè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 obligatoire. 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 message 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 ChangeCipherSpec. 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 fonctionnalité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 préalable. Cette étude consiste à examiner le système auquel nous voulons apporter 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.

U

3.1 Mandriva Pulse 2.0
Ceci est à priori un logiciel de gestion de parc informatique. Nous n'avons malheureusement 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 Mandriva. 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 utilisant 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 information (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'administrateur 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'exploitation, logiciels etc... Il possède une interface conviviale et claire en PHP, qu'il nous est possible de modier 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 informations 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 également 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 facilite 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'inventaire. La gestion des utilisateurs et de l'authentication dans l'interface sont très basiques, 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 utilisateurs. 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 utilisation 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 proposants 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 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 fonctionnels 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.

P

4.1 Les besoins fonctionnels
L'application consiste à développer des interfaces qui permettent de gérer un inventaire d'un parc informatique en se basant sur le noyau d'OCS Inventory NG en liaison avec GLPI.

Module Inventaire

Module télé-déploiement 

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, ).  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

Module Helpdesk 

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.  L'application doit assurer une liaison OCS/GLPI automatique.  L'application doit intégrer le module helpdesk de GLPI avec toutes ses fonctionnalité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'application 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 rapide et assure que les modules seront intégrable et utilisable dans d'autre applications.  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 responsables 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'eectuer 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éploiement, 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 systè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 diffé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 besoins é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, 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.

D

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 logicielles 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 services 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 immé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. 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 scalabilité :

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 modication sur la base locale (insertion, suppression, ou mise à jour) s'eectue automatiquement 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 architecture, 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 relationnelle 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(    

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

#hardwareDEVICEID ).

#HARDWARE_ID,

NAME, IVALUE, TVALUE, COMMENTS,

#TAG

#ID

#hardwareDEVICEID

#NAME

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 messages. 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'inventaire : 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 recours à 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 dossier 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 composantes, 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 manipulation 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 partie réalisation de notre application. Pour cela, nous procéderons, dans ce chapitre à 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.

A

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 applications 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. 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.).

Outil de conception :

Serveur de base de données : Langage de programmation :

MySQL 5 est le serveur de gestion de base de données relationnels utilisé par OCS Inventory NG pour stocker les données. OCS Inventory NG utilise le PHP 5 comme un langage 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 inventorié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 recherche 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 informations 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 imprédictibles que nous avons essayé de surmonter :  Une diculté certaine consistait à comprendre et à reprendre un code déjà existant. 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 php5curl 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 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 informatique d'autre part.

N

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'opportunité 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 nouveaux modules tels que le portage des modules vers la nouvelle version d'OCS Inventory 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] [2]

T. Converse, A. Barr,

, (pp. 1037), Standford,1992. http ://www.stanford.edu/group/scip/avsgt/helpdesk/helpdesk.html (consulté le 10 juillet 2009).

PHP5 and MySQL ,Bible,2004. Software Trends at the Help Desk

[3] [4] [5]

N. Bruton,

uk.net/pages/articles.htm(consulté le 12 juillet 2009).
J. Doléans,

Helpdesk management reporting ,1997b. http ://www.bruton.winLe projet GLPI Le projet GLPI
LOGCRI,2007. LOGCRI,2007. http http

://creativecom://creativecom-

mons.org/(consulté le 20 juillet 2009).
J. Doléans,

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

Sign up to vote on this title
UsefulNot useful