orchestration et virtualisation de réseau de la caisse
TRANSCRIPT
1
MEMOIRE
DE STAGE DE FIN D’ETUDES Pour l’obtention du
«Mastère professionnel en Nouvelles Technologies des
Télécommunications et Réseaux (N2TR)»
Présenté par :
Akrem HAMMAMI
Titre Orchestration et Virtualisation de réseau de la
Caisse Nationale d’Assurance Maladie
Soutenu le : 12 / 07 / 2018
Devant le jury :
Présidente : Mme. BOUSNINA Ines
Encadreur : Mr. BEN BRAIEK Ezzedine (UVT)
Mr. BEN GAIED Mohsen (CNAM)
Rapporteuse : Mme. AMMARI Imen
Année Universitaire : 2017 / 2018
2
Résumé
Dans le cadre de mon projet de fin d’études à l’Université Virtuelle de Tunis (UVT) et
en vue de l’obtention du titre de Mastère en Nouvelles Technologies des Télécommunications
et Réseaux, j’ai effectué un stage de quatre mois à la CNAM.
Durant mon séjour dans ladite société, j’avais pour mission de concevoir et de réaliser
une application d'orchestration et de virtualisation des équipements réseaux en suivant des
étapes qui commencent par l’étude de l’existant ensuite l’étape de la conception jusqu'à
l’étape de la réalisation.
« As part of my graduation project at the Tunisian Virtual University (UVT) and in
order to obtain the title of Master in New Technologies of Telecommunications and
Networks, I did a four-month internship at the CNAM.
During my stay in this company, my mission was to design and implement an
application of orchestration and virtualization of network equipment by following steps that
begin with the study of the existing then the design stage up to 'at the stage of the
realization. »
3
Dédicace
A ma Chère Mère Latifa
A mon Père Lotfi
A ma Femme Meriem
A mon fils Mohamed Amine
A ma nouvelle née Nour
Dont le mérite, les sacrifices et les qualités humaines
m’ont permis de vivre ce jour.
A mon Frère et mes sœurs
Haithem, Anissa, Oumaima
A tous les gens qui m'aiment......
(Akrem Hammami)
4
Remerciements
Au terme de ce projet de fin d’études, j’adresse mes sincères remerciements
à Monsieur Ezzedine Ben Braiek, mon encadreur de l’UVT pour son
encadrement.
Je tiens à remercier également Monsieur Mohsen Ben Gaied, chef de
service à la Caisse Nationale d’Assurance Maladie, pour m’avoir proposé ce
projet, pour son suivi et ses remarques qui m’ont permis de mener à bien ce
travail.
Mes remerciements s’adressent également à l’administration et aux
professeurs de l’UVT pour les moyens qu’ils ont mis à notre disposition afin
d’élaborer ce travail.
Je souhaite exprimer enfin ma gratitude et mes vifs remerciements à ma
famille et mes amis pour leurs soutiens.
Pour finir, je remercie les membres du jury qui ont accepté d’évaluer mon
projet. Je leurs présentons toute mes gratitudes et mes profonds respects.
5
Table des matières
Introduction Générale .............................................................................................................7
Chapitre I : Présentation générale ......................................................................................... 10
I.1. Présentation de l’organisme d’accueil ......................................................................... 10
I.2. Contexte ..................................................................................................................... 12
I.3. Problématique ............................................................................................................. 13
I.4. Travail à réaliser ......................................................................................................... 13
I.5. Méthodologie de conception ....................................................................................... 14
I.6. Langage de conception................................................................................................ 14
I.7. Conclusion .................................................................................................................. 15
Chapitre II – Etude préalable et spécification des besoins ..................................................... 17
II.1. Etude préalable .......................................................................................................... 17
II.2. Spécification des besoins ........................................................................................... 22
II.3. Conclusion ................................................................................................................ 27
Chapitre III – Conception ..................................................................................................... 29
III.1. Conception architecturale ......................................................................................... 29
III.2. Conception détaillée ................................................................................................. 31
III.3. Conclusion ............................................................................................................... 38
Chapitre IV – Réalisation ..................................................................................................... 40
IV.1. Environnement matériel ........................................................................................... 40
IV.2. Environnement logiciel ............................................................................................ 40
IV.3. Outils de développement .......................................................................................... 41
IV.4. Interfaces de l’application ........................................................................................ 43
IV.5. Conclusion ............................................................................................................... 52
Conclusion Générale ............................................................................................................ 53
Netographie .......................................................................................................................... 54
6
Liste des figures Figure I.1 : Organigramme de la CNAM..................................................................................11
Figure I.2 : Structure de la direction Systèmes, Réseaux et Maintenances Informatiques.......12
Figure I.3 : Modèle en Cascade................................................................................................14
Figure II.1 : Architecture de réseau de la CNAM.....................................................................19
Figure II.2 : Diagramme de cas d’utilisation généralisé...........................................................24
Figure II.3 : Diagramme de cas d’utilisation de gestion des utilisateurs..................................25
Figure II.4 : Diagramme de cas d’utilisation de gestion des préférences.................................25
Figure II.5 : Diagramme de cas d’utilisation de gestion des produits.......................................26
Figure II.6 : Diagramme de cas d’utilisation de configuration et d'administration..................26
Figure III.1 : Architecture 2 tiers (Client-serveur)....................................................................29
Figure III.2 : Schéma de l'architecture MVC............................................................................30
Figure III.3 : Diagramme de déploiement.................................................................................31
Figure III.4 : Diagramme de paquetage....................................................................................32
Figure III.5 : Diagramme de classe de la couche Model...........................................................32
Figure III.6 : Modèle relationnel de la Base de Données..........................................................34
Figure III.7 : Diagramme de séquence de processus d’authentification...................................36
Figure III.8 : Diagramme de séquence de processus d'ajout d'un utilisateur............................36
Figure III.9 : Diagramme de séquence de processus de modification d'un équipement...........37
Figure III.10 : Diagramme de séquence de processus de supervision......................................38
Figure IV.1 : Interface d’authentification.................................................................................43
Figure IV.2 : Interface d'accueil de l'administrateur................................................................44
Figure IV.3 : Interface de gestion des utilisateurs.....................................................................44
Figure IV.4 : Interface d’ajout d’un utilisateur.........................................................................45
Figure IV.5 : Interface d’accueil de modification d’un utilisateur............................................46
Figure IV.6 : Interface de suppression d’un utilisateur.............................................................46
Figure IV.7 : Interface de liste des utilisateurs.........................................................................47
Figure IV.8 : Interface de gestion des préférences....................................................................48
Figure IV.9 : Interface de gestion des centres...........................................................................49
Figure IV.10 : Interface d’ajout d’un équipement....................................................................49
Figure IV.11 : Interface de création d'une affectation..............................................................50
Figure IV.12 : Interface d'administration et de configuration...................................................51
Figure IV.13 : Interface de cartographie...................................................................................52
7
Introduction Générale
Le système d’information et les réseaux sont aujourd’hui un élément critique de la
compétitivité de l’entreprise. De mauvaises performances de ceux-ci se déclinent en pertes de
productivité et les indisponibilités de service se traduisent en pertes de vente, irrégularités
d’exploitation ou interruption de la production. La qualité du service global rendu aux
utilisateurs doit être garantie, ce qui implique la maîtrise d’un ensemble complexe de
systèmes, réseaux, middleware et applications. On compte sur les services offerts par les
réseaux pour transactions bancaire, les recherches web, la téléconférence, etc. Ces services
sont de ce fait devenus indispensable. Pour s'assurer que les services rendus par les réseaux
soient convenable, il est nécessaire de surveiller et d'agir quand une erreur se produit. Pour ce
faire, il faut obtenir les données de gestion des équipements des réseaux et, si nécessaire,
contrôler ces équipements d'où l'utilité de recourir aux outils d'orchestration et
d'administration des réseaux.
Ce projet a été réalisé dans le cadre de la mise en place d'un outil d'administration
réseau de la Caisse Nationale d’Assurance Maladie. Il consiste à concevoir et mise en place
un système d’orchestration réseaux qui permet à la fois de collecter des données sur les
routeurs, les firewalls et les commutateurs, afficher l'état de chaque équipement et l'accéder.
Et afin de faciliter l'administration et le contrôle de tout les équipements réseaux de la
CNAM développés sur tout le territoire Tunisien, il m’a été confié de concevoir et de
développer une application d'orchestration et de virtualisation de réseau de la CNAM. En
faite, avec cette application, le réseau peut être provisionné de manière orchestrée. Elle offre
un concept fondamental qui sert à automatiser les réseaux définis. L'automatisation permet de
provisionner des services réseaux rapides et à grande échelle, en réduisant le risque d'erreur
humaine.
8
Pour cela, et après avoir effectué des recherches et grâce à des informations collectées,
nous avons élaboré notre vision de l’application, son architecture, ainsi que les outils et les
technologies utiles. Dans ce cadre, notre travail est établi sur quatre chapitres principaux dont
on parle: Le premier chapitre est une présentation générale de ce projet, le deuxième est une
étude des besoins de la solution adoptée et identification des acteurs ainsi que leurs cas
d’utilisation. Le troisième chapitre est la conception détaillée où nous allons adopter une
architecture logicielle, modéliser les différentes entités de notre application par les
diagrammes de classes, étudier les différents scénarios et mettre en place notre application
d'orchestration réseau tout en modélisant différents composants et leurs fonctionnements.
Dans le dernier chapitre, nous présenterons l’environnement de développement qui aide à
réaliser notre projet.
9
Chapitre I Présentation générale
10
Chapitre I : Présentation générale
Ce chapitre comportera une brève présentation de l’organisme qui a accepté de
m’accueillir et m’a donné la chance de réaliser mon projet de fin d’études, citant son origine,
ses objectifs, son organisation, sa structure et quelque notion de sujet.
I.1. Présentation de l’organisme d’accueil
Crée sous la forme d’un établissement public à caractère non administratif, la Caisse
Nationale d’Assurance Maladie (CNAM) possède la personnalité morale autrement dit, elle
est autonome et dispose d’un budget qui l’est aussi. Placée sous la tutelle du ministère des
affaires sociales et de la solidarité et des Tunisiens à l’étranger, la CNAM est la troisième
caisse sociale aux coté de la CNSS et de la CNRPS mais agissant dans un seul domaine, à
savoir l’assurance maladie.
D’ailleurs, son personnel est issu de ces deux caisses puisque conformément à l’article
9 de la loi du 2 août 2004, les agents de la CNSS et de la CNRPS exerçants dans le domaine
de l’assurance maladie sont intégrés à la CNAM.
I.1.1. Missions
La CNAM a été créée en vertu de la loi 71/2004 du 2 août 2004 ayant instituée le
régime d’assurance maladie. Les missions de la CNAM portent sur :
La gestion des régimes légaux : régimes des repartions des dommages résultants des
accidents de travail et des maladies professionnelles dans les secteurs public et privé.
La gestion des autres régimes légaux d’assurance maladie prévus par la législation
en vigueur (couverture de la longue maladie et régime de remboursement CNRPS).
L’octroi des indemnités de maladie et de couches prévu par les régimes de sécurité
sociale.
La gestion des conventions bilatérales en matière d’octroi des soins.
La gestion du «régime assurance maladie » institué par la loi 2004-71 du 2 août
2004
Comportant un régime de base et éventuellement un régime complémentaire.
11
I.1.2. Objectifs
La CNAM est organisée en structures régionales chargées de l’octroi des prestations et
structures centrales chargées essentiellement du suivi de l’activité et de son évaluation. La
CNAM a pour objectifs :
Une meilleure qualité des services rendus aux bénéficiaires et aux différents
utilisateurs du système (délais, procédures, accueil).
La maîtrise des frais de gestion.
La maîtrise des dépenses et le maintien de l’équilibre du régime.
La gestion rationnelle du nouveau régime.
I.1.3. Organigramme de la CNAM
La figure I.1 présente l’organigramme de la caisse nationale d’assurance
maladie (CNAM) :
Figure I.1 : Organigramme de la CNAM
12
I.1.4. Structure de la Direction Systèmes, Réseaux et Maintenance Informatique :
La direction systèmes, réseaux et maintenances informatiques gère l'ensemble des
ressources informatiques. Elle s'occupe également de l'assistance quotidienne des utilisateurs
(réparation des pannes, installation des logiciels et des anti-virus, gestion du matériel
informatique, administration du réseau, etc.).
La figure I.2 présente la répartition et l’organisation de la direction Systèmes, Réseaux
et Maintenances Informatiques :
Figure I.2 : Structure de la direction Systèmes, Réseaux et Maintenances Informatiques
I.2. Contexte
Les réseaux informatiques, sont des éléments essentiels et primordiaux des
technologies actuelles des transmissions des données entre sites éloignés, leur traitement et
leur restitution, touchent de plus en plus notre vie courant. La gestion des réseaux
informatiques est toujours un travail pénible, laborieux, sujet aux erreurs et dont la complexité
est sans cesse croissante en raison de l’évolution des technologies et du matériel qui entre en
compte. D’une part, les équipements qui forment le réseau doivent se comporter comme un
groupe ; cependant, chacune de ces machines est gérée et configurée individuellement.
D'autre part, l’évolution fulgurante du nombre de dispositifs, la complexité des
configurations, les besoins spécifiques de chaque service, le nombre même de services qu’un
réseau doit être capable de supporter, et le fait que les données traversent généralement des
réseaux hétérogènes appartenant à plusieurs opérateurs, rendent cette tâche de plus en plus
difficile. Nous pouvons aisément comprendre la nécessité de nouvelles approches au
problème de gestion de configuration réseau.
13
C’est dans ce contexte, l'outil de l'administration réseau assure une gestion des
ressources réseau de manière efficace, un accès rapide aux menu de configuration des
équipements et il permet aux administrateurs réseau de surveiller les tendances, de planifier la
capacité et d'optimiser les performances.
I.3. Problématique
Au terme d’une réunion entre le directeur centrale de l’informatique de la CNAM,
mon encadrant et moi-même, nous avons convenu qu'il y a des difficultés de surveillance, de
maintient et de gestion des réseaux informatiques. A l'heure actuelle, la Caisse Nationale
d’Assurance Maladie dispose d'un important lot d'équipements réseaux (routeurs, switchers,
firewalls…) qui suit le nombre de centres régionaux, locaux et des maisons des affaires
sociales. Des dysfonctionnements ou de mauvaises performances de réseau peuvent
occasionner une perte de productivité au sein de la CNAM. Une bonne exploitation impose la
gestion d'éléments essentiels comme le coût, la qualité de service et la réactivité des systèmes.
Pour le service réseau, mission d'autant plus complexe qu'un administrateur de réseau doit
souvent gérer un ensemble de systèmes hétérogènes, avec protocoles standards et
technologies variés.
I.4. Travail à réaliser
Il nous revient alors de proposer une solution informatique à même de résoudre les
difficultés que connaît le service informatique dans la gestion des équipements réseaux. De ce
faite, l’idée générale du projet consiste à concevoir un outil applicatif qui pourra de façon
concrète nous permettre de faire la gestion des routeurs, des commutateurs et des firewalls et
le monitoring de tous ces équipements. Ainsi, la CNAM a exprimé un besoin pressant de
mettre à niveau son système d’information et d’adopter un système efficace et ouvert afin de
remédier aux problèmes d’orchestration des équipements réseaux.
Cette application va nous permettre de :
Lister et identifier tous les équipements réseaux existants dans l’architecture du
système actuel de la CNAM ;
Superviser les états des équipements réseaux ;
Accéder à tous les produits répartis sur le territoire d'une même interface ;
Faciliter l’accès à chaque équipement réseau ;
Faire la configuration de chaque équipement réseau ;
14
I.5. Méthodologie de conception
Il existe différents types de cycles de développement entrant dans la réalisation d'un
logiciel. Ces cycles prendront en compte toutes les étapes de la conception d'un logiciel. Le
type de méthode le plus utilisé aujourd’hui dans tous les domaines qui nécessitent de
concevoir avant de produire quelque chose. Pour parvenir à un produit fini, on passe par
plusieurs phases du cadrage du projet jusqu’à la livraison finale. Cette méthode présente de
nombreux avantages, notamment celui de sécuriser le planning du projet puisque l’on
verrouille chacune des étapes les unes après les autres : on s’entend sur ce que l’on va faire
(cadrage), on le conçoit dans les grandes lignes (conception générale) puis dans le détail
(conception détaillée) avant de le produire (production), de le tester (tests/corrections) et de le
livrer (livraison).
Elle permet également de bien s’entendre sur les attendus du projet et elle est très
facile à expliciter à un groupe de travail. Enfin, bien menée, elle permet d’éviter les dérives en
termes de planning : il est facile de visualiser que si une étape se décale, les suivantes sont
impactées. La figure I.3 présente les différentes étapes du modèle en cascade.
Figure I.3 : Modèle en Cascade
I.6. Langage de conception
Dans le but de concevoir un système extensible, évolutif, modulaire et orienté objet, le
langage UML s’est imposé comme un outil performant afin d’élaborer ce projet. En effet, ce
langage permet de mener la phase de conception tout en bénéficiant de la puissance et de la
simplicité de ses diagrammes. Le choix d’UML, comme outil de modélisation des flux et les
différentes actions de l’application, peut être justifié par plusieurs raisons :
15
UML facilite la compréhension et la communication d’une modélisation objet,
La notation UML s'impose comme un standard de fait à l'heure actuelle sur le marché,
Il est adopté par les grands constructeurs de logiciel du marché,
L’utilisation d’UML offre l’avantage de disposer de vues de haut niveau d'abstraction,
Pour favoriser la communication entre utilisateurs, spécialistes et informaticiens.
I.7. Conclusion
L’application proposée devra donc être à mesure d’apporter une solution concrète à la
prise en charge des différents problèmes d'orchestration de réseau de la CNAM. Pou cela, on
va passer au chapitre suivant pour faire une étude préalable et spécifier les besoins.
16
Chapitre II
Etude préalable Et
Spécification des besoins
17
Chapitre II – Etude préalable et spécification des besoins
Ce chapitre détaille les spécifications pour la réalisation de l’application
d’orchestration et de virtualisation de réseau de la CNAM. Il décrit l’ensemble des cas
d’utilisations du système. En effet, le présent chapitre définira les interactions entre les
utilisateurs et l’application proposée tout au long du cycle de vie des équipements réseaux.
II.1. Etude préalable
L’étude préalable du projet consiste principalement à recenser l’existant c'est-à-dire les
solutions informatiques déjà mises en œuvre dans l’entreprise et à recenser les
besoins notamment en termes de fonctionnalités nouvelles du logiciel. Elle peut être
l’occasion d’une étude de rentabilité du projet.
II.1.1. Etude de l’existant
La Caisse Nationale d’Assurance Maladie possède un grand nombre de routeurs, de
switchers et de serveurs qui sont installés au niveau du site central, des centres régionaux, des
centres locaux, des maisons d’affaires sociales et des maisons de services.
L’architecture réseau de la CNAM est articulée autour de 3 couches :
La couche Core : est constituée :
D’un cluster de deux Firewalls Cisco PIX 525. Ce cluster gère le routage entre les
différentes zones ainsi que les listes d’accès aux différentes ressources du système
d’information.
D’un cluster de deux switchers Cisco 4503 et qui a pour rôle de fédérer les
différentes connexions des switchers d’accès à la couche cœur du système
d’information.
La couche Accès : est constituée de :
Un ensemble de switchers de différentes marques et modèles répartis sur les étages
du bâtiment qui héberge le Data Center.
Un point d’accès Wifi, installé dans le 7ème étage du bâtiment.
18
La couche Edge : est constituée de :
Un cluster de deux Firewalls Fortigate FG200B. Ce cluster est divisé en deux
domaines virtuels (VDOM) ; un VDOM pour la navigation internet et un VDOM
pour le trafic inter-sites/inter-systèmes de la CNAM.
Un firewall Cisco PIX 525 pour gérer le DMZ de la CNAM où est publié un
serveur Web et un serveur de messagerie.
Des équipements d’accès aux routeurs des partenaires de la CNAM comme la
CNSS et la CNRPS ainsi que les réseaux de ses directions régionales. Ces
équipements sont gérer par les différents fournisseurs de service comme Tunisie
Télécom, Orange, Ooredoo.
Les connexions WAN qui relient la CNAM à ses différents partenaires et fournisseurs
de services sont principalement :
Une connexion au réseau internet assurée par deux ADSL 8 Mbps chacune,
Une connexion MPLS composée d’une liaison fibre optique de 50 Mbps et assurant
l’interconnexion des différentes directions régionales au Data Center,
Deux liaisons spécialisées de 2 Mbps chacune et assurant la connexion du DC de la
CNAM à la CNSS et la CNRPS,
Une liaison ADSL de 4 Mbps et faisant office de support d’accès aux passerelles SMS
de deux fournisseurs de services : Ooredoo et Orange,
Une connexion Wimax de 2 Mbps assurée par le fournisseur Orange pour la
publication du site Web et le serveur de messagerie de la CNAM.
La figure II.1 illustre l’architecture LAN/WAN de la CNAM
19
Figure II.1 : Architecture de réseau de la CNAM
20
I.1.2. Critiques de l’existant
Avant de plonger dans l’étude proprement dite de la solution, il est indispensable de
prendre du recul et de faire un résumé des problèmes concrets existants que rencontrent au
jour le jour nos différents acteurs. Les administrateurs réseau de la Caisse Nationale
d’Assurance Maladie utilisent les lignes de commandes via l’interface MS-DOS de Windows
ou bien le logiciel PUTTY pour accéder aux routeurs ou switchers ou firewalls se qui entraine
parfois l’oublie des mots de passe. De plus, ils ne peuvent pas supervisés tous les équipements
en temps réel et en même temps et de vérifier leurs états. C’est donc dans cette optique qu’une
petite enquête a été menée auprès de ces personnes et la plupart des problèmes recensés sont
les suivants :
Pour un très grand nombre de routeurs, de switchers à gérer, l’administrateur est
incapable de vérifier leurs disponibilité (en ligne ou pas), de déterminer la qualité des
services qu’ils offrent, ni détecter la défaillance des équipements.
Le seul moyen de détecter ces anomalies ne peut se faire que par la réception des
différentes plaintes et réclamations des agents de centres régionaux ou locaux distants.
Nombreux sont les problèmes que rencontre un centre lors d’une panne d’équipement
causant une coupure globale au niveau du réseau. D’une part, Celle-ci contrariait les
assurés en créant un retard au niveau du service au guichet, mais aussi un retard pour
fixer ce problème puisqu’il fallait contacter la direction informatique afin de régler
cette défaillance technique et cela prenait assez de temps. D’autre part, il existe en
Tunisie plus de 65 centres CNAM qui ont besoin d’être constamment suivis mais le
manque d’informaticiens ne permet pas de remplir cette tache.
II.1.3. Solutions Web existantes
Le logiciel libre est aujourd'hui aux portes des administrations qui sont maintenant
confrontées à des choix. Bien que le modèle dominant soit souvent celui du logiciel
propriétaire, de nombreux arguments montrent chaque jour un peu plus que les logiciels libres
sont une alternative crédible.
Il existe évidemment des obstacles à l'adoption des logiciels libres dans la CNAM et
parmi ces obstacles, on trouve que les meilleurs logiciels libres sont matures, mais d'autres
n'ont pas encore atteint le stade de la version 1.0. Il convient donc de bien vérifier auprès de
son conseiller si le produit choisi est mature et si la communauté pouvant le supporter est bien
active.
21
La direction informatique de la CNAM a utilisé plusieurs logiciel libre comme le
PRTG (Paessler Router Traffic Grapher) [N1] comme outil open source pour superviser le
réseau mais ce dernier a présenté plusieurs contraintes, parmi ces contraintes, une partie
d’administration des équipements est manquante, une documentation incomplète et
parcellaire, manque de souplesse pour modifier certains comportements et la documentation
recommande de modifier le code source.
De plus l'intégration d'une application open source est rarement maîtrisée, ce qui peut
entraîner des coûts imprévus ou dévaluer des actifs logiciel. Ces risques découlent d'une
réutilisation insouciante ou imprudente de l'open source et peuvent survenir tout au long du
cycle de vie du logiciel, de l'écriture du code à la distribution du logiciel final. Ils ont pour
origine les problèmes de compatibilité de licence, mais aussi d'obsolescence des composants
et de vulnérabilité logicielle.
II.1.4. Solution proposée et retenu
L’administration, la gestion et la supervision des équipements réseaux distants
représentent un souci important pour l’administrateur. Le système actuel de gestion du réseau
au sein de la CNAM présente plusieurs contraintes. Alertée, la direction informatique de la
CNAM a pris conscience de ce problème qui risque de ternir l’image de la société auprès du
reste des directions et des centres régionaux et locaux. De ce fait, nous avons jugé nécessaire
de mettre en place un outil pour contrôler le fonctionnement du réseau, d’étudier les données
collectées et de définir des mécanismes déclenchant des alertes lors de détection des
problèmes. Elle a donc décidé la mise en place d’un outil applicatif qui pourra grâce aux
différentes fonctionnalités qu’il offre, faciliter la gestion et la configuration des équipements
réseaux, alertés les administrateurs en cas de panne ou de coupure.
En effet, une nouvelle application en environnement graphique et utilisant une base de
données fait l'objet d'une étude pour la gestion du réseau informatique de la CNAM. Réaliser
une base de données ainsi qu’une interface graphique associée, qui rend transparent pour
l’administrateur la gestion de la base. Cette interface devra être la plus simple et intuitive
possible de façon à ne nécessiter aucun apprentissage particulier. Aussi la maintenance et la
mise à jour de cette interface devra être facile dés lors qu’on possède les fichiers sources.
22
II.2. Spécification des besoins
Cette phase consiste à comprendre le contexte du système. Il s'agit de déterminer les
fonctionnalités et les acteurs les plus pertinents, de préciser les risques les plus critiques et
d'identifier les cas d'utilisation initiaux.
II.2.1. Besoins fonctionnels
Avant de parler du fonctionnement proprement dit du système, il est nécessaire de
définir dans un premier temps les fonctionnalités qui seront implémentées au sein dudit
système. Ainsi, cette étape décrira ce que nous attendons de notre application. Puis, tout ceci
sera modélisé sous forme de diagramme à l’aide du langage de modélisation UML, en ce que
nous appellerons par la suite cas d’utilisation. De ce fait, s’il faut redéfinir concrètement les
fonctionnalités de notre système, nous pouvons tout simplement dire que notre application
doit être capable de :
Gestion des utilisateurs : il s’agit d’un outil permettant d’effectuer les opérations de
gestion telles que l’ajout, la modification, la suppression et le listage.
Gestion des préférences : il s’agit d’un outil permettant pour chaque utilisateur la
gestion des centres, gestion des types, gestion des marques et la gestion des modèles
en effectuant les opérations de l'ajout, la modification, la suppression et le listage.
Gestion des produits : il s’agit d’un outil permettant d’effectuer les opérations de
gestion des équipements telles que l’ajout, la modification, la suppression et le listage
et les opérations d'affectation d'un équipement.
Configuration et administration : il s'agit d'un outil permettant la visualisation des
états, la configuration et l'administration des équipements qui sont déjà connectés,
consulter l'historique et les statistiques.
II.2.2. Besoins non fonctionnels
Nous entendons par là les besoins qui caractérisent le système. Autrement dit, il s’agit
de définir un ensemble de critères essentiels pour le bon fonctionnement de notre application.
Il est à noter cependant qu’ils peuvent être exprimés en matière de performance, de type de
matériel ou le type de conception. Dans le cadre de notre travail, nous pouvons citer par
exemple :
23
Ergonomie : L’interface de l’application doit être simple et utilisable afin que
l’utilisateur puisse l’exploiter sans se référer à des connaissances particulières, en
d’autres termes, notre application doit être lisible et facile à manipuler par n’importe
quel utilisateur ;
Sécurité : L’application devra assurer la sécurité des utilisateurs. D’où la nécessité de
procéder à l’authentification des agents et administrateurs tout en assurant la
confidentialité de leurs données ;
Maintenabilité : C’est-à-dire qu’il doit y avoir une possibilité d’ajouter de nouvelles
fonctionnalités ou de modifier celles existantes ;
Rapidité et intégrabilité dans d’autres applications : L’application devra être
rapide et assure que les modules seront intégrables et utilisables dans d’autres
applications ;
II.2.3. Besoins architecturaux
Pour notre application nous avons besoins d’un réseau local, intranet et d’une
architecture 2 tiers/niveaux. Ce type d'architecture caractérise les environnements client-
serveur où le poste client demande une ressource au serveur qui la fournit à partir de ses
propres ressources. L’application d'administration et de supervision doit être accessible
uniquement à partir des postes d'un réseau local, ou bien d'un ensemble de réseaux bien
définis, et invisibles (ou inaccessibles) de l'extérieur.
Dans l'architecture à 2 niveaux, on a généralement une architecture partagée entre :
Un poste client : l'ordinateur demandeur de ressources, équipée d'une interface
utilisateur (généralement un navigateur web) chargée de la présentation ;
Un serveur physique : sur ce serveur, il sera installé un serveur d'application et un
serveur de base de données. Le serveur d’application est chargé de fournir la ressource
mais faisant appel au serveur de données, qui ce dernier fournissant au serveur
d'application les données dont il a besoin.
II.2.4. Diagramme de cas d’utilisation
Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner
une vision globale du comportement fonctionnel d'un système logiciel. Avant de modéliser
nos besoins fonctionnels, nous allons préciser les différents acteurs qui vont interagir avec
notre application.
24
II.2.4.a. Identification des acteurs
Au niveau de cette section, nous présentons les différents acteurs susceptibles
d’utiliser cette application, mais tout d’abord, nous donnons une définition du concept acteur.
Un acteur représente l'abstraction d'un rôle joué par des entités externes (utilisateur, dispositif
matériel ou autre système) qui interagissent directement avec le système étudié. La mise en
marche du système nécessite essentiellement trois acteurs :
Administrateur : L’administrateur a le droit de gérer les utilisateurs, de définir les
rôles et les privilèges des utilisateurs du système. De plus, il peut gérer les produits, gérer les
préférences et configurer et administrer les équipements.
Utilisateur : Son rôle consiste à gérer les produits, gérer les préférences et configurer
et administrer les équipements.
II.2.4.b. Diagramme de cas d’utilisation général
La figure II.2 présente le diagramme de cas d'utilisation généralisé. L’administrateur
peut utiliser l'interface "gestion des utilisateurs" pour ajouter des comptes utilisateurs et gérer
leurs accès à l'application. L'administrateur ainsi que l'utilisateur, après l'authentification,
peuvent gérer les mêmes interfaces tels que l'interface de gestion des préférences, l'interface
de gestion des produits et l'interface de configuration et d'administration.
Figure II.2 : Diagramme de cas d’utilisation généralisé
25
Le diagramme de cas d'utilisation de gestion des utilisateurs représenté par la figure
II.3 nous définit certaines fonctionnalités de l'administrateur comme l'ajout d'un utilisateur,
modification des utilisateurs, suppression des utilisateurs et le listage des utilisateurs.
Figure II.3 : Diagramme de cas d’utilisation de gestion des utilisateurs
La figure II.4 nous illustre le diagramme de cas d'utilisation de gestion des
préférences. Cette interface nous permet de gérer les centres, gérer les modèles, gérer les
marques et gérer les types.
Figure II.4 : Diagramme de cas d’utilisation de gestion des préférences
26
Le diagramme de cas d'utilisation de gestion des produits représenté par la figure II.5
englobe la gestion des équipements qui se présente par l'ajout, la modification, la suppression
et le listage des produits et la gestion des affectation qui se présente par la création, la
modification, la suppression des équipements et le listage des équipements affectés et des
équipements non affectés.
Figure II.5 : Diagramme de cas d’utilisation de gestion des produits
La figure II.6 nous illustre le diagramme de cas d'utilisation de configuration et
administration. L'utilisateur peut configurer et administrer tous les produits. Cette interface de
configuration et administration englobe plusieurs fonctionnalités comme l'affichage des
équipements avec leurs états, consulter l'historique, la recherche et les statistiques.
Figure II.6 : Diagramme de cas d’utilisation de configuration et d'administration
27
II.3. Conclusion
Ce chapitre présente une phase indispensable pour l’étude et l’analyse de notre
application. Nous avons défini les différents besoins fonctionnels, non fonctionnels et
architecturaux, nous avons présenté le diagramme de cas d’utilisation général.
Nous entamerons dans le chapitre suivant la conception de cette application qui
comporte diagramme de paquetage, diagramme de séquence et diagramme de classe.
28
Chapitre III
Conception
29
Chapitre III – Conception
L’étape de conception définit généralement les structures et les modèles à suivre lors
de la phase d’implémentation de l’application. C’est la phase où nous préparons l’architecture
logicielle de l’application, et où nous définissons la structure de l’application.
III.1. Conception architecturale
La structuration du système peut être vue sous différents angles, selon que l’on
considère :
le découpage « logique » hors de tout contexte d’exécution (machines, OS et réseaux)
le découpage « physique » (prenant en compte le contexte d’exécution)
III.1.1. Architecture physique
Dans le domaine informatique, l'architecture physique (également nommée
architecture technique) décrit l'ensemble des composants matériels supportant l'application.
Pour notre application, on va choisir un environnement client/serveur, cela signifie que des
machines clientes (des machines faisant partie du réseau) contactent un serveur, une machine
généralement très puissante en termes de capacités d'entrée-sortie, qui leur fournit des
services. Ces services sont des programmes fournissant des données telles que l'heure, des
fichiers, une connexion, etc. La Figure III.1 montre l’architecture technique générale et le
contexte de déploiement de l’application.
Figure III.1 : Architecture 2 tiers (Client-serveur)
30
Cette architecture est basée sur deux composants essentiels :
Le Client : C’est une machine (faisant partie du réseau), communiquant avec le
serveur pour la récupération d’un service donné.
Le Serveur d’application : Ce serveur est chargé de fournir la ressource mais en
faisant appel au serveur de données.
Le serveur d’application et la logique applicative (l’ensemble des traitements
nécessaires pour répondre aux besoins des utilisateurs) se trouvent sur une même
machine.
III.1.2. Architecture logique
Notre application se base sur l’architecture MVC (Modèle / Vue / Contrôleur).
L'architecture MVC est une façon d'organiser une interface graphique d'un programme. Elle
consiste à distinguer trois entités distinctes qui sont, le modèle, la vue et le contrôleur
présentés dans la figure III.2 ayant chacun un rôle précis dans l'interface. L'organisation
globale d'une interface graphique est souvent délicate. Bien que la façon MVC d'organiser une
interface ne soit pas la solution miracle, elle fournit souvent une première approche qui peut
ensuite être adaptée. Elle offre aussi un cadre pour structurer une application. Dans
l'architecture MVC, les rôles des trois entités sont les suivants :
Modèle : données (accès et mise à jour)
Vue : interface utilisateur (entrées et sorties)
Contrôleur : gestion des événements et synchronisation
Figure III.2 : Schéma de l'architecture MVC
31
III.1.3. Diagramme de déploiement
Le diagramme de déploiement représenté dans la figure III.3 décrit la disposition
physique des ressources matérielles qui composent le système et montre la répartition des
composants sur ces matériels.
Figure III.3 : Diagramme de déploiement
III.2. Conception détaillée
La conception détaillée fournit la structure interne des composants logiciels utilisés
dans le module d’analyse structurelle.
III.2.1. Conception de l’aspect statique
Après l’élection des besoins exprimés sous la forme de fonctionnalités modélisées
comme des cas d’utilisation et sous la forme de scénarios modélisés dans des diagrammes
d’activité, nous pouvons modéliser la structure logique du système, c’est-à-dire les aspects
statiques du système.
Cette modélisation est en grande partie effectuée dans un diagramme de classes, avec
éventuellement un diagramme de paquetage montrant des configurations spécifiques du
système dans des conditions particulières.
III.2.1.a. Diagramme de paquetage
Le diagramme paquetage présenté dans la figure III.4 fournit une description détaillée
l’interaction des packages existants dans notre projet entre eux ainsi il nous aide à mieux
comprendre le mécanisme de fonctionnement de notre application.
32
Figure III.4 : Diagramme de paquetage
III.2.1.b. Diagramme de classe
Le diagramme de classe est considéré comme le plus important de la modélisation
orientée objet, il est le seul obligatoire lors d’une telle modélisation. Le diagramme de classes
du package model de la figure III.5 montre la structure interne du système.
Figure III.5 : Diagramme de classe de la couche Model
33
III.2.1.c. Conception de la Base de données
A partir du diagramme de classe de la package model, nous avons conçu une base de
données relationnelle, il est important de clairement définir toutes les tables qui la
composent :
Table utilisateur (matricule, prenom, nom, tel, email, password, id_profil)
Table profil (id_profil, lib_profil)
Table centre (code_centre, lib_centre, tel_centre, adresse_centre, lat, lng)
Table equipement (num_serie, designation, statut, adresse_ip, id_marque, id_type,
code_centre)
Table type (id_type, lib_type)
Table marque (id_marque, lib_marque)
Table modele (id_modele, lib_modele, id_marque)
Table gerer (matricule, num_serie, date_debut, date_fin)
Table affecter (num_serie, code_centre, date_debut_affec, date_fin_affec ,adress_ip)
La figure III.6 présente la relation entre les tables de notre base de données, en faite la
mise en relation de tables permet de relier les données d’une table à celles d’une autre table et
ainsi d’établir une base de données de type relationnelle. Les relations entre des tables
permettent d’utiliser les données d’une table dans une autre et d’éviter ainsi la saisie
redondante d’informations.
34
Figure III.6 : Modèle relationnel de la Base de Données
III.2.2. Conception de l’aspect dynamique
La modélisation des aspects dynamiques de l’analyse consiste en la connaissance des
messages échangés entre les objets, de l’ordre de ces interactions, ainsi que des changements
d’états significatifs des objets.
III.2.2.a. Les règles de gestion
Pour obtenir un résultat dans un traitement, il est souvent nécessaire d'inclure des
règles de gestion dans le modèle conceptuel. A partir de ces règles de gestion, une réflexion
doit être réalisée quant aux règles d'organisation de la base de données à construire. Pour
notre application voici quelques règles de gestion qui vont être définis :
Règle 1: Si au moins un des champs de l'interface d'authentification ne sont pas remplis alors
le message et même dans tous les champs de saisie de l'application, le message "Vous avez
oublié de remplir un champ" va être affiché.
Règle 2: Si un matricule ou un mot de passe n'est pas valide dans l'interface de
l'authentification alors un message "Mauvais matricule / mot de passe. Merci de
recommencer" va être affiché.
Règle 3: Si dans l'interface "ajout d'un utilisateur" on saisie un matricule n'est pas numérique
alors un message "Merci de vérifier le matricule" va être affiché.
35
Règle 4: Si dans l'interface "ajout d'un utilisateur" on saisie une adresse email n'a pas la
forme d'un email alors un message "Vous devez entrer une adresse de messagerie valide"
va être affiché.
Règle 5: Si dans l'interface "ajouter un équipement" on ajout un numéro de série qui déjà
existe alors un message "Numéro de série déjà existant" va être affiché.
Règle 6: Si dans l'interface "créer une affectation" on saisie une adresse IP n'a pas la forme
d'une adresse IP alors un message "Veuillez modifier la valeur pour correspondre au
format demandé" va être affiché.
Règle 7: Si dans l'interface "statistique" on introduit une période qui n'est pas valable ou des
données non valables alors un message d'erreur s'affichera.
III.2.2.b. Diagramme de séquence
Un diagramme de séquence est un document graphique qui montre pour des scénarios
de cas d'utilisation précis, les événements générés et les interactions entre objets en se basant
sur des messages ordonnés. Chaque message transitant sur un lien est symbolisé par une
flèche porteuse d'une expression. La lecture se fait de haut en bas, et l'ordre chronologique
doit respecter ce sens. La réalisation de diagramme de séquence permet de lister les méthodes
dont on aura besoin lors de la phase de développement.
Le diagramme de séquence de la figure III.7 illustre le processus d’authentification
d’un utilisateur. L'utilisateur va remplir le formulaire d'authentification, il y aura une
authentification sur les données saisies. Si les informations sont correctes, selon le profil
utilisateur ou administrateur une page d'accueil s'affichera. Si les informations sont
incorrectes, un message d'erreur s'affichera et il va retrouver la page d'authentification.
36
Figure III.7 : Diagramme de séquence de processus d’authentification
Le diagramme de la figure III.8 illustre le processus d'ajout d'un utilisateur au sein du
l’application bien sûr qui doit être précédé par une authentification. Ce processus se déroule
de la même manière pour la modification, la suppression et la recherche d'un utilisateur. En
faite, l'utilisateur rempli le formulaire d'ajout d'un utilisateur Après la vérification, si les
informations sont correctes alors l'opération s'effectuera, sinon un message d'erreur
s'affichera.
Figure III.8 : Diagramme de séquence de processus d'ajout d'un utilisateur
37
Le diagramme de la figure III.9 illustre le processus de modification d’un équipement
au sein de l’application bien sûr qui doit être précédé par une authentification. Ce processus se
déroule de la même manière pour la suppression d’un équipement. En faite, l'utilisateur
sélectionne le numéro de série à modifier, la page de modification s’affiche avec les
informations de l’équipement sélectionné. Une fois que les informations modifiés sont
correctes alors l’opération de sauvegarde d’effectue, sinon un message d'erreur s'affichera.
Figure III.9 : Diagramme de séquence de processus de modification d'un équipement
Le diagramme de la figure III.10 illustre le processus de supervision au sein de
l’application bien sûr qui doit être précédé par une authentification. Après authentification,
l’utilisateur va choisir l’interface de supervision et d'administration qui va afficher les
positions géographiques de tous les équipements ainsi que leurs états.
38
Figure III.10 : Diagramme de séquence de processus de supervision et d'administration
III.3. Conclusion
Dans ce chapitre nous avons fait la description des diagrammes de classe, de séquence
et de paquetage afin de délimiter le cadre de notre travail et de préparer un terrain favorable
pour la prochaine étape.
Maintenant, notre application est prête à être codée. Dans le chapitre suivant, nous
allons nous intéresser à l’implémentation de notre système en se basant sur la conception
détaillée réalisée dans ce chapitre.
39
Chapitre IV
Réalisation
40
Chapitre IV – Réalisation
Dans ce chapitre, nous allons évoquer une phase cruciale de notre projet, qui est
l’implémentation de l’application. Nous commencerons par la représentation de
l’environnement matériel et logiciel et les différents outils de développement utilisés. Enfin,
nous représenterons des captures d’écran qui illustrent notre travail.
IV.1. Environnement matériel
Pour la réalisation de notre application, Nous avons utilisé deux PC, dont les
configurations sont les suivantes :
Poste serveur :
OS : Windows 8
RAM : 8 Go
Disque Dur : 1To
Processeur : i5
Poste client :
OS : Windows 7
RAM : 2 Go
Disque Dur : 500 Go
Processeur : i3
IV.2. Environnement logiciel
Pour réaliser notre projet, nous avons eu recours à une multitude des logiciels :
Outil de développement :
o Langage de programmation : PHP.
o Langage de mise en forme : CSS
o SGBD : MySQL server.
Outil de conception : UML Diagrammer.
Système d'exploitation : Windows 8, Windows 7
41
IV.3. Outils de développement
Les outils de développement désignent un ensemble d’outils destinés à nous aider à
créer et à développer des pages Web.
IV.3.a Langage de programmation PHP
PHP est un langage de script utilisé le plus souvent côté serveur : dans cette
architecture, le serveur interprète le code PHP des pages web demandées et génère du code
(HTML, XHTML, CSS par exemple) et des données (JPEG, GIF, PNG par exemple) pouvant
être interprétés et rendues par un navigateur. PHP peut également générer d'autres formats
comme le WML, le SVG, le PDF. [N2]
Il a été conçu pour permettre la création d'applications dynamiques, le plus souvent
développées pour le Web. PHP est le plus souvent couplé à un serveur Apache bien qu'il
puisse être installé sur la plupart des serveurs HTTP tel que IIS. Ce couplage permet de
récupérer des informations issues d'une base de données, d'un système de fichiers (contenu de
fichiers et de l'arborescence) ou plus simplement des données envoyées par le navigateur afin
d'être interprétées ou stockées pour une utilisation ultérieure.
C'est un langage peu typé et souple et donc facile à apprendre par un débutant mais, de
ce fait, des failles de sécurité peuvent rapidement apparaître dans les applications.
Pragmatique, PHP ne s'encombre pas de théorie et a tendance à choisir le chemin le plus
direct. Néanmoins, le nom des fonctions (ainsi que le passage des arguments) ne respecte pas
toujours une logique uniforme, ce qui peut être préjudiciable à l'apprentissage
IV.3.b Langage de mise en forme CSS
Le terme CSS [N3] est l'acronyme anglais de Cascading Style Sheets qui peut se
traduire par "feuilles de style en cascade". Le CSS est un langage informatique utilisé sur
l'internet pour mettre en forme les fichiers HTML ou XML. Ainsi, les feuilles de style, aussi
appelé les fichiers CSS, comprennent du code qui permet de gérer le design d'une page en
HTML.
Bien que l'HTML puisse être mis en forme à l'aide de balises prévus à cet effet, de nos
jours il est plus judicieux d'utiliser le CSS et de n'utiliser le XHTML que pour le contenu.
L'avantage de l'utilisation d'un fichier CSS pour la mise en forme d'un site réside dans
la possibilité de modifier tous les titres du site en une seule fois en modifiants une seule partie
du fichier CSS. Sans ce fichier CSS, il serait nécessaire de modifier chaque titre de chaque
page du site (difficilement envisageable pour les énormes sites de plusieurs milliers de pages).
42
IV.3.b Base de données MYSQL
MYSQL est un système de gestion de bases de données relationnelles (SGBDR). Il est
distribué sous une double licence GPL et propriétaire [N4] .Il fait partie des logiciels de
gestion de base de données les plus utilisés au monde3, autant par le grand public
(applications web principalement) que par des professionnels, en concurrence avec Oracle,
Informix et Microsoft SQL Server.
MySQL est un serveur de bases de données relationnelles SQL développé dans un
souci de performances élevées en lecture, ce qui signifie qu'il est davantage orienté vers le
service de données déjà en place que vers celui de mises à jour fréquentes et fortement
sécurisées.
Afin de bénéficier des outils indiqués dans le paragraphe ci-dessus, on a installé en
local le pack EasyPHP qui regroupe les applications suivantes :
Le serveur web Apache
Le serveur de base de données MySQL
Le serveur d'application PHP
L’outil phpMyAdmin permettant de gérer des bases MySQL
43
IV.4. Interfaces de l’application
Un exemple d’interfaces est représenté par les figures suivantes :
Figure IV.1 : Interface d’authentification
Pour bénéficier des services de mon application chaque utilisateur doit saisir son
matricule et un mot de passe valide. Ce dernier sera redirigé soit pour l’interface des
administrateurs, ou l'interface des utilisateurs selon son profil.
Dans la fenêtre de la figure IV.2, on trouve l'interface d'accueil de l'administrateur. Par
cette interface on peut accéder aux différentes modules, tel que la gestion des utilisateurs, la
gestion des équipements, la gestion préférences et l'administration et la configuration.
44
Figure IV.2 : Interface d'accueil de l'administrateur
Dans la fenêtre de la figure IV.3, on trouve l'interface de gestion des utilisateurs. Par
cette interface on peut accéder aux différentes fonctionnalités, tel que l'ajout, la modification,
la suppression et le listage des utilisateurs.
Figure IV.3 : Interface de gestion des utilisateurs
45
Après l’affichage de la fenêtre de la figure IV.4 on doit la remplir par les informations
demandées ci-dessous (matricule, nom, prénom, centre, téléphone, email, mot de passe,
profil). Si tous les champs sont remplis, on clique sur le bouton valider pour enregistrer les
informations. Un contrôle se fait sur le format de l'adresse email.
Figure IV.4 : Interface d’ajout d’un utilisateur
Après l’affichage de la fenêtre de la figure IV.5 on sélectionne le matricule de
l'utilisateur à partir d'une liste déroulante pour modifier l’une ou toute ses informations (profil,
nom, prénom, téléphone, email, mot de passe), sauf le matricule qui est inchangeable.
Cette interface semble à l'interface d'accueil de suppression d'un utilisateur, c'est à dire
l'administrateur doit sélectionner le matricule pour passer à l'interface de suppression.
46
Figure IV.5 : Interface d’accueil de modification d’un utilisateur
Après l’affichage de la fenêtre de la figure IV.6 toute les informations de l'utilisateur à
supprimer sont affichés (profil, centre, matricule, nom, prénom, téléphone, email, mot de
passe) qui ne sont pas modifiables. Après le clic sur le bouton valider la suppression
d'effectuera et un message s'affichera pour valider que l'opération de suppression a été bien
faite.
Figure IV.6 : Interface de suppression d’un utilisateur
47
La figure IV.7 présente l'interface de liste de tous les utilisateurs avec toutes les
informations nécessaires (profil, matricule, nom, prénom, téléphone, email, mot de passe)
affichés dan un tableau.
Figure IV.7 : Interface de liste des utilisateurs
La figure IV.8 présente l'interface de gestion de préférence. On trouve quatre boutons,
gestion des centres, gestion des types, gestion des marques et finalement gestion des modèles.
48
Figure IV.8 : Interface de gestion des préférences
Dans la fenêtre de la figure IV.9, on peut faire la gestion des centres à partir de ces
modules (ajout, modification, suppression, listage) qu'on les trouves les mêmes pour la
gestion des types, la gestion des marques et la gestion des modèles.
Figure IV.9 : Interface de gestion des centres
49
Après l’affichage de la fenêtre de la figure IV.10, interface d'ajout d'un équipement, on
doit remplir ou sélectionner les champs nécessaires par les informations demandées ci-
dessous (Numéro de série, libellé, Type, Marque, Modèle). Si tous les champs sont remplis,
on clique sur le bouton valider pour enregistrer les informations.
Figure IV.10 : Interface d’ajout d’un équipement
50
Dans la fenêtre de la figure IV.11 interface de création d'affectation, on doit la remplir
par les informations demandées ci-dessous (Numéro de série, centre, adresse IP et date
d'affectation). Si tous les champs sont remplis, on clique sur le bouton valider pour enregistrer
les informations. Un contrôle se fait sur le format de adresse IP.
Figure IV.11 : Interface de création d'une affectation
51
Dans la fenêtre de la figure IV.12, on peut faire l'accès à la cartographie, consulter
l'historique des accès aux équipements, lire les statistiques, ainsi qu'on trouve un bouton pour
accéder à des liens utiles.
Figure IV.12 : Interface d'administration et de configuration
52
Après l’affichage de la fenêtre de la figure IV.13, interface d'administration et de
configuration. Cette interface nous permet de visualiser tous les équipements répartis sur tout
le territoire tunisien en affichant l'emplacement de chaque équipement ainsi que son état. Par
un simple clic sue le marker, une étiquette apparaît pour afficher des informations comme
l'adresse de localisation et l'adresse IP. On trouve aussi sur cette interface un tableau qui
affiche le matériel hors service.
Figure IV.13 : Interface de cartographie
IV.5. Conclusion
Dans ce chapitre de réalisation, nous avons présenté une étude de l’environnement
logiciel et matériel utilisé pour développer notre projet, ainsi que les technologies employées.
Nous avons, par la suite, présenté les interfaces les plus significatives de notre application.
Cette exécution nous a permis de confronter les idées théoriques de la conception et de
vérifier et comparer les résultats prévus avec le travail réalisé.
53
Conclusion Générale
Il n'est pas envisageable d'avoir un réseau comportant un nombre important
d'équipements réseaux sans avoir une image de l'état de santé de celui-ci. IL faut une console
de supervision et d'administration qui regroupe tous les produits et affiche leurs états. Le
monitoring du réseau de la CNAM consiste donc d’une part à lister et à localiser tous les
équipements réseau de l’entreprise, d’autre part à vérifier leurs états et à les accéder pour faire
les configurations nécessaires. Ces opérations peuvent être effectuées par une personne
qualifiée, mais bien souvent ce travail soit pénible et laborieux. Pour dépasser tout cela, il est
nécessaire qu’un ou plusieurs outils soient mis en place au sein de l’entreprise afin d’avoir un
suivi régulier du réseau de la CNAM et d'anticiper sur les ruptures des accès et les
défaillances de ses ressources.
Au sein de la CNAM, mon travail a consisté à concevoir et à mettre en place une
application pour l'orchestration et la virtualisation du réseau. Cette application présente
plusieurs avantages. Parmi ces avantages est d'accéder à tous les produits répartis sur le
territoire d'une même interface de façon que le réseau soit provisionné de manière orchestrée
et de superviser les états de tous les équipements connectés et installés.
Ce stage a été également l’occasion de découvrir le dynamisme et l’enthousiasme qui
caractérise les équipes de la CNAM. Les réunions régulières effectuées avec mon encadrant
dans la société et à l’école m’ont permis de mettre en œuvre les concepts de gestion de projets
acquis à l’UVT.
Les perspectives possibles à la suite du présent projet sont multiples et couvrent
plusieurs aspects, tels que rendre l’application accessible de l’extérieur de la CNAM, de plus
la possibilités de l'envoie des notifications en cas de panne par des emails .
54
Netographie
[N1] : https://www.fr.paessler.com/prtg consulté le 23/03/2018
[N2] : www.phpdebutant.org/article118.php consulté le 12/04/2018
[N3] : http://glossaire.infowebmaster.fr/css/ consulté le 02/05/2018
[N4] : https://fr.wikipedia.org/wiki/MySQL consulté le 20/05/2018
55
56