Gestion des actifs applicatifs

Université Sultan Moulay Slimane
Ecole Nationale des Sciences Appliquées
-Khouribga-
Projet de ﬁn d’études
En vue de l’obtention du diplôme
INGÉNIEUR D’ÉTAT
Filiére : Génie Informatique
Présenté par
ABALLAGH Safa
Conception et Développement d’une
application web de gestion des actifs
applicatifs
Soutenu le 17 juillet 2020, devant le jury :
Pr Omar EL BENAY ENSA Khouribga Président
Pr Nidal LAMGHARI ENSA Khouribga Examinateur
Mr Saad BOURASSI Royal Air Maroc Encadrant Externe
Pr Mostafa SAADI ENSA Khouribga Encadrant Interne

Dédicace
Je dédie ce travail à ma famille, mes parents et mes amis et à toutes les personnes
qui m’ont aidée de loin ou de près tout au long de ce PFE.
Merci à vous Tous.
2

Remerciements
Je remercie Dieu, l’Unique, Le puissant, Lui qui nous gratiﬁe de ses Bienfaits à
tout moment et à tout instant.
Plusieurs personnes remarquables m’ont aidée pendant la réalisation de ce projet.
Je leur en suis profondément reconnaissante.
Mes remerciements chaleureux à mes deux encadrants, Mr Saad Bourassi et Mr
Saadi Mostafa, pour leur assistance et soutient et leurs conseils qui m’ont aidée tout
au long de ma période de stage.
Merci à mes professeurs de l’école nationale des sciences appliquées de Khouribga,
pour leurs conseils et leur formation.
Mille mercis à ma famille, mes amis, à ceux et à celles qui m’ont aidée et soutenue
et qui sans eux ce travail n’aura pas vu le jour.
3

Résumé
Le présent rapport a été élaboré suite à un projet de ﬁn d’études eﬀectué au sein
du siège social de la Royal Air Maroc. Il s’inscrit dans le cadre de la formation pour
l’obtention du Diplôme d’ingénieur d’Etat en Génie Informatique.
L’objectif de ce projet est de modéliser et développer une application Web dédiée
à la gestion des actifs applicatifs déployés au sein des data centers de la royal air
maroc.
Cette application est développée selon une méthodologie agile « dynamique software
development» en utilisant le micro framework Spring boot et la librairie Reactjs.
Mots clés : dynamique software development, spring boot,reactjs .
4

Abstract
This report was produced as a part of an end of study project realized within
the Royal Air Maroc headquarter in order to obtain the diploma of state engineer
of software engineering.
The project is about the development of a web application dedicated to the mana-
gement of software assets of the data center department of the Royal Air Maroc.
The application is developed using an agile methodology called dynamic software
development and using the spring boot framework and the reactjs library.
Keywords : dynamique software development, spring boot,reactjs.
5

Table des matières
Liste des abréviations 8
Liste des tableaux 9
Liste des figures 10
Introduction Générale 12
1 Contexte général du projet 14
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . 14
1.2.1 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.2 Fiche technique de l’entreprise . . . . . . . . . . . . . . . . . . 15
1.2.3 Département Data Center : . . . . . . . . . . . . . . . . . . . 15
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.1 Cadre général du projet . . . . . . . . . . . . . . . . . . . . . 17
1.3.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5 Conduite du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5.1 Processus de développement . . . . . . . . . . . . . . . . . . . 19
1.5.2 Présentation des incréments . . . . . . . . . . . . . . . . . . . 20
1.6 Planning prévisionnel (GANTT) . . . . . . . . . . . . . . . . . . . . . 22
2 Analyse des besoins 23
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Definition du contexte . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Décomposition en packages . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Les Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . 25
2.4.1 Consultation des inventaires . . . . . . . . . . . . . . . . . . . 25
6

TABLE DES MATIÈRES
2.4.2 Gestion des utilisateurs : . . . . . . . . . . . . . . . . . . . . . 28
2.4.3 Gestion des inventaires . . . . . . . . . . . . . . . . . . . . . . 30
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3 Etude Conceptuelle 33
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.1 Scénario d’ajout d’un nouvel utilisateur . . . . . . . . . . . . . 33
3.2.2 Scénario d’authentiﬁcation d’un utilisateur . . . . . . . . . . . 34
3.2.3 Scénario d’accès aux ressources . . . . . . . . . . . . . . . . . 35
3.2.4 Scénario aﬃchage des fonctionnalités de l’application . . . . . 36
3.3 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4 Etude technique 38
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Architecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Coté Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.2 Coté Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5 Réalisation 44
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Interfaces graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.1 Gestion des inventaires . . . . . . . . . . . . . . . . . . . . . . 44
5.2.2 Gestion des utilisateurs : . . . . . . . . . . . . . . . . . . . . . 54
5.2.3 Gestion des commentaires . . . . . . . . . . . . . . . . . . . . 57
5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Conclusion Générale 60
Webographie 61
7

Liste des abréviations
Acronyme Signiﬁcation
API Application Programming Interface
BD Base de données
DSDM Dynamic Systems Development Method
DOM Document Object Model
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
IDE Integrated Development Environment
JPA Java Persistance API
JSON JavaScript Object Notation
JSX JavaScript XML
JWT Json Web Token
REST Representational State Transfer
SGBDR Système Gestion de Base Données Relationnelle
SQL Structered Query Language
XML Extensible Markup Language
8

Liste des tableaux
Table 1.1 Fiche technique de la RAM . . . . . . . . . . . . . . . . . . . . . 15
Table 1.2 Processus de la DSDM . . . . . . . . . . . . . . . . . . . . . . . 20
Table 2.1 Description du cas d’utilisation "afficher les informations d’un
actif" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Table 2.2 Description du cas d’utilisation "Consulter les commentaires d’un
actif" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Table 2.3 Description du cas d’utilisation "gérer les commentaires" . . . . . 27
Table 2.4 Description du cas d’utilisation "ajouter un utilisateur" . . . . . 28
Table 2.5 Description du cas d’utilisation "Modifier les informations d’un
utilisateur" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Table 2.6 Description du cas d’utilisation "Modifier les rôles d’un utilisateur" 29
Table 2.7 Description du cas d’utilisation "ajouter un actif" . . . . . . . . . 30
Table 2.8 Description du cas d’utilisation "Modifier les informations d’un
actif" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 2.9 Description du cas d’utilisation "Supprimer un actif" . . . . . . . 31
9

Liste des figures
Figure 1.1 Logo de la RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 1.2 DOSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 1.3 Département Data Center . . . . . . . . . . . . . . . . . . . . . 16
Figure 1.4 Processus DSDM . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 1.5 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 2.1 Diagramme de contexte . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 2.2 Diagramme de packages . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 2.3 Use case consultation des inventaires . . . . . . . . . . . . . . . 25
Figure 2.4 Use case gestion des utilisateurs . . . . . . . . . . . . . . . . . . 28
Figure 2.5 Use case gestion des inventaires . . . . . . . . . . . . . . . . . . 30
Figure 3.1 Scénario d’enregistrement d’un utilisateur . . . . . . . . . . . . . 34
Figure 3.2 Scénario d’authentification . . . . . . . . . . . . . . . . . . . . . 34
Figure 3.3 scénario d’accès aux ressources . . . . . . . . . . . . . . . . . . . 36
Figure 3.4 scénario affichage des fonctionnalités . . . . . . . . . . . . . . . . 36
Figure 3.5 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 4.1 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figure 4.2 Logo Spring boot . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figure 4.3 Outil postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 4.4 Logo React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 5.1 Home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 5.2 Inventaire des serveurs . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 5.3 Ajouter un nouveau serveur . . . . . . . . . . . . . . . . . . . . 46
Figure 5.4 Détails d’un serveur . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 5.5 Modifier un serveur . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 5.6 Inventaire des bases données . . . . . . . . . . . . . . . . . . . . 47
Figure 5.7 Ajouter une nouvelle base données . . . . . . . . . . . . . . . . . 48
10

LISTE DES FIGURES
Figure 5.8 Afficher la description d’une base données . . . . . . . . . . . . . 49
Figure 5.9 Modifier une base données . . . . . . . . . . . . . . . . . . . . . 49
Figure 5.10 Inventaire des services web . . . . . . . . . . . . . . . . . . . . . 50
Figure 5.11 Ajouter un nouveau service web . . . . . . . . . . . . . . . . . . 50
Figure 5.12 Afficher la description d’un service web . . . . . . . . . . . . . . 51
Figure 5.13 Modifier un service web . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 5.14 Inventaires des applications . . . . . . . . . . . . . . . . . . . . . 52
Figure 5.15 Ajouter une nouvelle application . . . . . . . . . . . . . . . . . . 52
Figure 5.16 Afficher les détails d’une applications . . . . . . . . . . . . . . . 53
Figure 5.17 Modifier une application . . . . . . . . . . . . . . . . . . . . . . 54
Figure 5.18 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 5.19 Espace utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figure 5.20 Liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . 55
Figure 5.21 Modifier un utilisateur . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 5.22 Ajouter un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 5.23 Liste des commentaires d’un actif . . . . . . . . . . . . . . . . . 58
Figure 5.24 Ajouter un commentaire . . . . . . . . . . . . . . . . . . . . . . 59
11

Introduction Générale
De nos jours, l’utilisation des logiciels de gestion des processus métiers ainsi que
le développement des logiciels sur mesure sont reconnus dans la plupart des do-
maines y compris le domaine aérien.
Ce domaine robuste a fait appel à l’informatique vers la fin des années 70, ce qui a
non seulement facilité le processus de travail quotidien des établissements aériennes
et des agences de voyages mais a bouleversé radicalement le secteur. Les grandes
compagnies aériennes ont opté pour un système de réservation informatisé. L’ex-
ploitation de ce dernier fut la première étape vers l’informatisation de ce secteur.
Aujourd’hui, l’existence d’un département informatique au sein des compagnies aé-
riennes est devenue vitale, son rôle ne consiste pas seulement à la gestion du parc
informatique et l’administration de ce dernier mais aussi à la recherche et le déve-
loppement des nouvelles solutions à des problématiques internes pour l’ensemble des
départements de l’organisme.
A la Royal Air Maroc (RAM) et plus précisément à la Direction Organisation Sys-
tème d’Information (DOSI), où c’est durant quatre mois déroulés mon projet de fin
d’étude, le département data center qui prend charge de l’administration et la ges-
tion des ressources informatiques déployées aux seins des data centers de la RAM,
se trouve face à une problématique de gestion des actifs applicatifs.
Pour répondre à cette problématique, le présent rapport comporte cinq chapitres
présentant la démarche suivie pour la mise au point d’un système de gestion des
actifs applicatifs :
— Le premier chapitre présente une description générale de l’entreprise et du
département au sein de lesquelle le projet de fin d’études s’est effectué et une
description du projet plus la stratégie de conduite qui a été adoptée pour le
mettre en place.
12

LISTE DES FIGURES
— Le deuxième chapitre présente une analyse des besoins fonctionnels.
— Le troisième chapitre présente l’étude conceptuelle du projet.
— le quatrième chapitre présente L’étude thechnique du projet.
— Le dernièr chapitre concerne la réalisation du projet, où nous allons présenter
les interfaces graphiques de notre application frontend.
13

Chapitre 1
Contexte général du projet
1.1 Introduction
Le présent chapitre constitue une présentation abrégée de la Royal Air Maroc et
du département data center, ainsi une explication détaillée de la problématique et
de l’objectif de notre projet et du processus de travail adopté pour la réalisation de
celui-ci.
1.2 Présentation de l’organisme d’accueil
1.2.1 Présentation générale
Royal Air Maroc, dont le logo (ﬁgure 1.1), est la principale compagnie aérienne
marocaine et la deuxième en Afrique, société anonyme née le 28 Juin 1957, suite à
la fusion d’Air Atlas et d’Air Maroc, qui avait donné lieu à la création de la Com-
pagnie Chériﬁenne de Transport Aérien. L’Etat marocain accorde à la Compagnie
la concession de l’exclusivité de l’exploitation des transports aériens intérieurs et
internationaux.
14

CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET
Figure 1.1: Logo de la RAM
1.2.2 Fiche technique de l’entreprise
ci-dessous, un tableau qui représente la ﬁche technique de la royal air maroc :
Siège social Boulevard Moulay Abdellah Cherif, Casa-
blanca 20200.
Forme juridique Société anonyme
Téléphone 05224-89797
Site web https ://www.royalairmaroc.co.ma
Date de création 29 juin 1957
Capital social 3 628 127 000 DHS
Secteur d’acti-
vité
Transports aériens.
Table 1.1: Fiche technique de la RAM
1.2.3 Département Data Center :
Le département Data Center est un département parmi les départements de la
DOSI « Direction Organisation et Système d’information » de la Royal Air Maroc.
Figure 1.2: DOSI
Le département Data Center a pour rôles :
15

— Mettre en oeuvre, administration et assurance de la disponibilité des infra-
structures IT, serveurs, SGBDR et applications techniques dans les meilleures
conditions de sécurité de qualité et de coût.
— Installation et administration des applications "métiers" hébergés dans les
Data-Center RAM dans les meilleures conditions de sécurité, de qualité et
de coût.
— Assurance des travaux de production et diﬀusion des résultats conformément
aux procédures livrées par les départements DOSI-CE et DOSI-CM (Etude et
développement).
— Assure la veille technologique et réglementaire dans son domaine, propose et
met en oeuvre les évolutions jugées nécessaires.
Figure 1.3: Département Data Center
16

1.3 Présentation du projet
1.3.1 Cadre général du projet
Comme étant le cas dans plusieurs entreprises aériennes, l’exploitation des solu-
tions informatiques au sein de la royal air maroc est indispensable.
La gestion de ces ressources applicatifs est très importante, ce qui rend nécessaire
la disposition d’une solution de gestion interactive et facile à utiliser.
1.3.2 Problématique
Avec la croissance du service informatique ainsi que la diversité des applications
déployées au sein du data center de la Royal Air Maroc, la gestion de ces actifs appli-
catifs d’une manière traditionnelle ainsi que le partage des informations concernant
ces actifs entre les différents collaborateurs de l’entreprise devient d’autant plus dif-
ficile.
Le département data-center de la Royal air Maroc est l’unité qui prend charge de
l’installation et de l’administration des applications hébergées dans les data-center
RAM. Jusqu’à nos jours, le département ne dispose d’aucune solution de gestion de
ces ressources, et traite le suivi des inventaires et le partage d’information concer-
nant les logiciels d’une manière traditionnelle par le partage des fichiers (pdf,excel..)
entre les collaborateurs ce qui n’est pas toujours pratique.
L’utilisation d’une application permet de faciliter la tâche et de rendre le partage
d’information plus flexible.
1.3.3 Objectifs
Mon projet consiste à concevoir et mettre en place une solution à la probléma-
tique, répondant aux objectifs suivants :
— Centraliser l’ensemble des informations des actifs applicatifs afin de les rendre
accessible à l’ensemble des collaborateurs de l’entreprise.
— Rendre le partage d’information plus facile et bien structuré.
— Une bonne gestion des utilisateurs.
17

1.4 Spécification des besoins
• L’application doit permettre à l’ensemble de ses utilisateurs les fonctionnalités
suivantes :
— Authentification des utilisateurs.
— La gestion des utilisateurs telle que l’ajout, la modification et la consul-
tation de la liste des utilisateurs.
— Création et gestion des inventaires des serveurs, bases données, applica-
tions et services web.
— Importation des fichiers par les utilisateurs et exportation et consultation
de ces derniers.
— Ajout et consultation des commentaires concernant les actifs
• l’application doit prendre en charge les différents besoins de ses utilisateurs
selon leurs rôles :
— Administrateur : Qui sera en charge de la gestion des utilisateurs.
— Administrateurs serveur : Qui seront en charge de la gestion d’inventaire
des serveurs.
— Administrateurs base données : Qui seront en charge de la gestion d’in-
ventaire de bases données.
— Administrateurs applicatif : Qui seront en charge de la gestion d’inven-
taire des applications et services web.
— Simples utilisateurs : Consultation des inventaires, ajout des commen-
taires et téléchargement des fichiers.
1.5 Conduite du projet
Le bon choix du processus de développement logiciel conduit à la bonne réalisa-
tion du projet. Après avoir identifié les besoins de notre projet et lister les fonction-
nalités à rajouter. Nous avons vu qu’il sera plus pratique d’adopter une méthode avec
une approche agile qui va nous permettre de s’ajuster rapidement aux changements
tout en garantissant des livraisons fréquentes pour assurer le bon fonctionnement
de la plateforme, en plus notre projet et de petite taille, donc une méthode agile et
parfaitement convenable.
18

1.5.1 Processus de développement
Parmi les méthodes agiles existantes nous avons choisis de travailler avec la mé-
thode dynamic software development. L’utilisation de ce modèle exige l’implication
continue de l’utilisateur pour mieux comprendre les besoins fonctionnels de l’ap-
plication. La méthode est incrémentale ce qui est bénéfique pour nous est va nous
permettre d’assurer des livrables le plus souvent et assurer des feedbacks pour amé-
liorer l’application.
1.5.1.1 Présentation du processus
Dynamic software development est une méthode de développement agile déve-
loppée en Grande-Bretagne en 1994 .Son succès est dû à la philosophie «que tout
projet doit être aligné sur des objectifs stratégiques clairement définis et se concen-
trer sur la livraison rapide »
La méthode s’appuie sur neuf principes de base :
— Implication des utilisateurs ;
— Autonomie de l’équipe du projet ;
— L’adéquation avec le besoin ;
— Visibilité du résultat, livraison rapide et fréquente ;
— Développement itératif et incrémental ;
— Réversibilité ;
— Synthèse ;
— Tests continue ;
— Coopération.
Le processus de la méthode repose sur quatre étapes essentielles comme le montre
la figure suivante :
19

Figure 1.4: Processus DSDM
Ci-dessous un tableau qui représente les détails de chaque étape de la méthode
DSDM :
Étude de faisabi-
lité
Déterminer s’il est opportun de faire le projet
en question. Evaluation des coûts et de la
valeur ajoutée attendue.
Étude business Spécification des fonctionnalités que l’appli-
cation doit apporter. Spécification des utili-
sateurs qui sont concernés par l’application.
Définition de l’architecture du système.
Modèle fonction-
nel itératif
Développement d’une manière itérative.
Mise en œuvre Mise en production de l’application afin de
la mettre à disposition des utilisateurs.
Table 1.2: Processus de la DSDM
1.5.2 Présentation des incréments
Pour le développement de ce projet, nous avons choisi de travailler avec une
méthode incrémentale. Après avoir identifier les fonctionnalités attendues de notre
application, nous allons présenter les incréments et les fonctionnalités à développer
pour chaque incrément.
• Premier incrément :
20

Le premier incrément est réservé à la gestion de l’inventaire serveur les fonc-
tionnalités à implémenter sont :
— Ajout d’un serveur ;
— Modification d’un serveur ;
— Suppression d’un serveur ;
— Consultation des informations d’un serveur.
• Deuxième incrément :
Le deuxième incrément est dédié à la gestion des inventaires concernant les
bases données et les web services :
— Ajout d’une base de données /web Service ;
— Modification d’une base de données /web Service ;
— Suppression d’une base de données /web Service ;
— Consultation les informations d’une base de données / web Service.
• Troisième incrément :
Le troisième incrément est réservé aux gestionnaire d’applications :
— Ajout d’une application ;
— Modification d’une application ;
— Suppression d’une application ;
— Consultation des informations d’une application.
• Quatrième incrément :
Le quatrième incrément est réservé à la gestion des utilisateurs :
— Ajout, modification et suppression des utilisateurs ;
— Gestion des rôles ;
— Authentification des utilisateurs.
• Cinquième incrément :
Le dernier incrément est réservé à la gestion des commentaires et des attach-
ments :
— Ajout, modification et suppression d’un commentaire ;
— Ajout des attachements à un commentaire.
21

1.6 Planning prévisionnel (GANTT)
La planification est l’activité qui consiste à organiser le déroulement des diffé-
rentes étapes d’un projet. Elle nous permet de suivre la concrétisation des objectifs
et la réalisation des différentes tâches, parallèlement à la gestion et à l’affectation
des ressources.
Pour la plannification de mon projet, je me suis basée sur le diagramme de gantt. Ce
diagramme est couramment utilisé en management projet, il permet de représenter
les tâches et visualiser l’état d’avancement des activités du projet.
La colonne de gauche du diagramme énumère toutes les tâches à effectuer ainsi
que la date du début et du fin de chaque tâche, tandis que la ligne d’en-tête repré-
sente les unités de temps. Chaque tâche est matérialisée par une barre horizontale,
dont la position et la longueur représentent la date de début, la durée et la date de fin.
Ci-dessous la planification par diagramme de Gantt de mon projet :
Figure 1.5: Diagramme de Gantt
Conclusion
Dans ce chapitre, nous avons traité le cadre générale du projet. Nous avons
commencé par une présentation de l’organisme d’accueil. Ensuite, nous avons dé-
taillé la problématique et l’objectif du projet pour ensuite présenter les spécifications
fonctionnelles de l’application. Nous avons conclus par une présentation de la mé-
thodologie adoptée pour assurer une bonne conduite du projet.
22

Chapitre 2
Analyse des besoins
2.1 Introduction
Le deuxième chapitre est consacré à l’étude analytique des besoins fonctionnels
de notre projet. l’analyse des besoins fonctionnels d’un système est une phase impor-
tante du développement logiciel. Son importance réside dans l’utilité de comprendre
les attentes des clients futurs utilisateurs afin de livrer une application qui répond
à leurs besoins. Pour cela nous allons commencer par une définition du contexte du
projet. Ensuite, nous allons découper le système en packages. Et enfin, nous allons
détailler les fonctionnalités de chaque package en utilisant les diagrammes de cas
d’utilisation.
2.2 Definition du contexte
La définition du contexte est notre première étape d’analyse. Elle consiste à dé-
finir les acteurs de l’application. Pour cela nous allons utiliser un diagramme de
contexte.
Un acteur représente un rôle joué par une personne ou une chose externe qui inter-
agit avec le système. Il peut être utilisateur direct ou indirect du système ou bien un
responsable de sa maintenance ou un autre système en interaction avec le système
en question.
23

CHAPITRE 2. ANALYSE DES BESOINS
Figure 2.1: Diagramme de contexte
2.3 Décomposition en packages
La deuxième étape d’analyse consiste à décomposer notre système, présenté en
boite noire dans le diagramme précedent, en packages. Pour cela nous allons utiliser
un diagramme de packages.
Un package est un domaine fonctionel qui represente une famille de fonctionnalités
utilisée par un ou plusieurs acteurs à la fois.
Figure 2.2: Diagramme de packages
24

2.4 Les Diagrammes de cas d’utilisation
Le diagramme de cas d’utilisation est le premier diagramme UML constitué
d’un ensemble d’acteurs qui agit sur des cas d’utilisation et qui décrit sous la forme
d’actions et des réactions, le comportement d’un système du point de vue utilisateur.
Dans cette partie nous allons présenter les diagrammes de cas d’utilisation de chaque
package.
2.4.1 Consultation des inventaires
Figure 2.3: Use case consultation des inventaires
2.4.1.1 Description du cas d’utilisation Consulter inventaire
• Aﬃcher les informations d’un actif :
25

Identification
Objectif : cette fonctionnalité permet aux utilisateurs d’afficher les informations
d’un actif.
acteur(s) : Simple utilisateur et Administrateur-actif
précondition :
— l’acteur est authentifié.
— l’acteur consulte l’inventaire d’actif
Description des scénarios
Scénario nominal :
— l’acteur ouvre l’inventaire d’un actif
— l’acteur affiche les informations d’un actif.
Scénario Alternatif :
Le système affiche une liste vide. aucun actif n’est enregistrer dans cet inventaire
Table 2.1: Description du cas d’utilisation "afficher les informations d’un actif"
• Consulter les commentaires d’un actif :
Identification
objectif : cette fonctionnalité permet d’afficher les commentaires concernant un
actif.
acteurs : Administrateur-actif et simple utilisateur
précondition :
— l’acteur consulte l’inventaire de l’actif.
Scénario nominal :
— l’acteur sélectionne un actif.
— l’acteur accède aux commentaires de cet actif.
— le système affiche les commentaires concernant l’actif.
— Selon le choix de l’acteur, lance le téléchargement des documents d’un com-
mentaire.
Le système affiche une liste de commentaires vide, aucun commentaire n’est enre-
gistré pour cet actif.
Table 2.2: Description du cas d’utilisation "Consulter les commentaires d’un actif"
• Gérer les commentaires d’un actif :
26

Identification
Objectif : cette fonctionnalité permet aux utilisateurs de gérer leurs commentaires
concernant un actif.
acteur(s) : Simple utilisateur et Administrateur-actif
précondition :
— l’acteur consulte l’inventaire d’actif.
— l’acteur accède à la liste des commentaires d’un actif
Scénarios nominals :
• scénario "Ajouter commentaire " :
— l’acteur ouvre le formulaire d’ajout d’un commentaire.
— l’acteur saisie son commentaire.
— l’acteur confirme l’ajout
— le système enregistre le commentaire
• scénario "Ajouter des documents à son commentaire" :
— l’acteur sélectionne son commentaire.
— l’acteur ouvre le formulaire d’ajout des documents.
— l’acteur ajoute les documents.
— l’acteur valide son ajout.
— le système enregistre les documents
• scénario "Modifier son commentaire" :
— l’acteur sélectionne son commentaire
— l’acteur ouvre le formulaire de modification
— l’acteur modifie son commentaire
— l’acteur valide ses modifications.
— le système enregistre les modifications.
• scénario "Supprimer son commentaire" :
— l’acteur sélectionne le commentaire à supprimer
— le système affiche un message de confirmation
— l’acteur confirme la suppression
— le système supprime le commentaire
Le système vérifie les champs avant l’ajout du commentaire.
L’acteur ne dispose d’aucun commentaire.
La taille du document dépasse la limite autorisée.
Table 2.3: Description du cas d’utilisation "gérer les commentaires"
27

2.4.2 Gestion des utilisateurs :
Figure 2.4: Use case gestion des utilisateurs
2.4.2.1 Description du cas d’utilisation Gestion des utilisateurs
• Ajouter un utilisateur :
Identiﬁcation
Objectif : cette fonctionnalité permet d’ajouter un nouvel utilisateur.
acteur(s) : Administrateur
précondition :
Scénario nominal :
— l’acteur ouvre le formulaire d’ajout d’un nouvel utilisateur.
— l’acteur saisie les informations du nouvel utilisateur.
— l’acteur valide l’ajout.
— le système enregistre le nouvel utilisateur.
L’utilisateur existe déjà dans la base de données
Table 2.4: Description du cas d’utilisation "ajouter un utilisateur"
• Modiﬁer les informations d’un utilisateur :
28

Identification
objectif : cette fonctionnalité permet de modifier les informations d’un utilisateur.
acteurs : Administrateur
précondition :
Scénario nominal :
— l’acteur sélectionne un utilisateur.
— l’acteur ouvre le formulaire de modification de cet utilisateur.
— l’acteur saisie les modifiactions.
— l’acteur valide les modifications.
— le système enregistre les modifications
Le système vérifie les données saisies, affiche un message d’erreur.
Table 2.5: Description du cas d’utilisation "Modifier les informations d’un utilisa-
teur"
• Modifier les rôles d’un utilisateur :
Identification
objectif : cette fonctionnalité permet de modifier les rôles d’un utilisateur.
acteurs : Administrateur
précondition :
Scénario nominal :
— l’acteur sélectionne un utilisateur.
— l’acteur ouvre le formulaire de modification des rôles de cet utilisateur.
— l’acteur modifie les rôles.
Table 2.6: Description du cas d’utilisation "Modifier les rôles d’un utilisateur"
29

2.4.3 Gestion des inventaires
Figure 2.5: Use case gestion des inventaires
2.4.3.1 Description du cas d’utilisation gestion des inventaires
• Ajouter un actif :
Identification
Objectif : cette fonctionnalité permet d’ajouter un nouvel actif.
acteur(s) : Administrateur-actif
précondition :
— L’acteur ouvre l’inventaire de l’actif.
Scénario nominal :
— l’acteur ouvre le formulaire d’ajout d’un nouvel actif.
— l’acteur saisie les informations du nouvel atif.
— l’acteur valide l’ajout.
— le système enregistre le nouvel actif.
Le système vérifie les données saisies,affiche un message d’erreur.
Table 2.7: Description du cas d’utilisation "ajouter un actif"
30

• Modifier un actif :
Identification
objectif : cette fonctionnalité permet de modifier les informations d’un actif.
acteurs : Administrateur-actif
précondition :
— l’acteur ouvre l’inventaire de l’actif.
Scénario nominal :
— l’acteur sélectionne un actif.
— l’acteur ouvre le formulaire de modification de cet actif.
— l’acteur saisie les modifiactions.
Table 2.8: Description du cas d’utilisation "Modifier les informations d’un actif"
• Supprimer un actif :
Identification
objectif : cette fonctionnalité permet de supprimer un actif.
acteurs : Administrateur-actif
précondition :
Scénario nominal :
— l’acteur sélectionne l’actif à supprimer.
— le système affiche un message de confirmation .
— l’acteur confirme la suppression.
— le système supprime l’actif.
Le système vérifie si l’actif est en relation avec d’autres actif. Si oui il affiche un
message d’erreur.
Table 2.9: Description du cas d’utilisation "Supprimer un actif"
31

2.5 Conclusion
Dans ce chapitre, nous avons présenté l’anylise des besoins fonctionnels de notre
projet. D’abord, nous avons commencé par la déﬁnition du contexte qui est une
représentation des acteurs du système. Ensuite, nous avons découpé le système en
packages suivant les fonctionnalités de notre application. Enﬁn, nous avons détaillé
les fonctionnalités de chaque package en utilisant le diagramme des cas d’utilisation.
32

Chapitre 3
Etude Conceptuelle
3.1 Introduction
Le troisième chapitre constitue une étude conceptuelle du projet. la phase de
conception est une étape importante dans le développement informatique. Dans la-
quel est décrit de manière non ambigue le fonctionnement future du système en
utilisant un langage de modélisation. Pour cela nous allons utiliser le langage de
modélisation UML qui est un langage visuel constitué d’un ensemble de schémas
qui donnent chacun une vision différente du projet à traiter.
3.2 Diagrammes de séquence
Le Diagramme de séquence est un diagramme qui permet de décrire, dans le
cadre d’un cas d’utilisation, comment les éléments du système interagissent entre
eux et avec les acteurs selon un ordre chronologique.
3.2.1 Scénario d’ajout d’un nouvel utilisateur
Ce diagramme représente le scénario d’ajout d’un nouvel utilisateur. L’adminis-
trateur demande le formulaire d’ajout d’un utilisateur. Le Frontend affiche le formu-
laire, l’administrateur saisie les données du nouvel utilisateur et valide sa demande.
Le Frontend vérifie si tout les champs obligatoires sont remplies, si oui il envoie une
requête POST contenant les données(Email, UserName, Password et rôles) au ba-
ckend. Ce dernier vérifie si ces données existent déjà sur le système. Si oui il renvoie
33

CHAPITRE 3. ETUDE CONCEPTUELLE
un message d’erreur. Si non il enregistre l’utilisateur et renvoie un message de succée
au Frontend.
Figure 3.1: Scénario d’enregistrement d’un utilisateur
3.2.2 Scénario d’authentiﬁcation d’un utilisateur
Figure 3.2: Scénario d’authentiﬁcation
34

Le scénario représente l’authentification d’un utilisateur. L’utilisateur demande
le formulaire d’authentification, la partie Frontend l’affiche. L’utilisateur saisie ses
données d’authentification et valide sa demande. La partie Frontend envoie en pre-
mier lieu une requête POST contenant les données d’authentification (username,
password), la partie Backend recoie la demande puis vérifie les données. S’elles sont
valides, elle authentifie l’utilisateur et génére un JWT qui va être envoyer en re-
ponse à la requête. Sinon elle envoie un message d’erreur que le frontend va afficher
à l’utilisateur.
3.2.2.1 JWT
JWT acronyme de Json web Token est couramment utilisé pour implémenter
des mécanismes d’authentification stateless, qui ne stocke pas les sessions utilisa-
teurs dans le contexte de l’application. JWT est un jeton permettant d’échanger des
informations de manière sécurisée. Ce jeton est composé de trois parties, un header,
un payload (les “claims”) et une signature.
Le header indique l’algorithme utilisé pour générer la signature ainsi que le type de
jeton dont il s’agit.
Le payload contient les informations que l’on souhaite transmettre.
la signature est la dernière partie du jeton, elle est créée à partir du header et du
payload générés et d’un secret et permet de vérifier la légitimité du token. Une si-
gnature invalide implique systématiquement le rejet du token.
3.2.3 Scénario d’accès aux ressources
Le troisième scénario concerne le processus d’accès aux données par un client
HTTP. l’utilisateur demande l’accès aux ressources en utilisant un client HTTP.
Le client envoie la requête http contenant le JWT de l’utilisateur dans la partie
Header. Le Backend vérifie le JWT et les autorités de l’utilisateur. Si l’utilisateur à
le droit d’accéder à ces ressources le Backend les renvoie en réponse, sinon il envoie
un message d’autorité non garantie.
35

Figure 3.3: scénario d’accès aux ressources
3.2.4 Scénario affichage des fonctionnalités de l’application
Le quatrième scénario concerne l’affichage des fonctionnalités. L’utilisateur com-
mence d’abord par s’authentifier. Puis accède aux inventaires. L’application Fron-
tend récupère les informations de l’utilisateur du LocalStorage de navigateur puis
affiche les fonctionnalités suivant les rôles de l’utilisateur.
Figure 3.4: scénario affichage des fonctionnalités
3.3 Diagramme de classes
Le diagramme de classes 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
36

diagramme de classes montre la structure interne du système. Il permet de fournir
une représentation abstraite des objets du système qui vont interagir ensemble pour
réaliser les cas d’utilisation.
Figure 3.5: Diagramme de classes
3.4 Conclusion
L’étude conceptuelle réalisée dans ce chapitre met en evidence le fonctionne-
ment future de notre application. Cette étude est réalisée à l’aide de deux types de
diagrammes UML dont le diagramme de séquences et le diagramme de classes. Le
premier diagramme nous a permit de décrir l’ensemble des interactions entre les élé-
ments du système lors de l’éxécution d’une fonctionnalité. Le deuxième diagramme
nous a permit de réaliser une présentation de la structure interne du système.
37

Chapitre 4
Etude technique
4.1 Introduction
Le quatrième chapitre constitue une étude technique du projet. Dans cette étude
nous allons entamer l’architecture générale de notre projet et nous allons présenter
toutes les technologies utilisées pour la realisation de ce dernier.
4.2 Architecture du projet
Notre application adopte une architecture client-serveur dans laquel une appli-
cation est éxecutée par deux composants logiciels distincts. Cette approche présente
beaucoup d’avantages dont le principal est la séparation claire des responsabilités
entre les deux composants et l’indépendance technologique et topologique de cha-
qun.
Le shéma ci-dessous represente l’architecture globale de notre projet :
38

CHAPITRE 4. ETUDE TECHNIQUE
Figure 4.1: Architecture globale
Le backend, qui represente la partie serveur, est une application Restful. Ce type
d’application suit le style architectural REST qui permet de centraliser des services
partagés, et profite des méthodes HTTP (GET, POST, PUT, DELETE) pour défi-
nir des spécifications d’échange de ressources facilement intégrables à tout système.
Comme le montre le shéma, le backend implémente la logic métier de notre projet
dans la couche service. La couche service utilise la couche persistance qui est la
couche dédiée aux interactions avec la base de données. La dernière couche englobe
les controlleurs REST, elle prend charge des requetes clients, les traite en utilisant
la couche service et renvoie les ressources convenables à chaque requêtes.
Le frontend, qui represente la partie client, est un client REST. Il implémente
les interfaces utilisateurs clients et consome l’api rest de notre application serveur
en utilisant un client http pour l’envoie des requêtes et la reception des ressources.
4.3 Technologies utilisées
4.3.1 Coté Backend
4.3.1.1 Spring boot
Spring boot est un micro framework qui facilite la création des applications
fondues sur Spring. Spring Boot adopte le principe convention plutot que configu-
ration qui est une pratique informatique qui tend à faire décroître le nombre de
décisions qu’un développeur doit prendre. Pour cela Spring Boot offre des outils
39

Figure 4.2: Logo Spring boot
permettant d’obtenir une application packagée en jar, totalement autonome et des
fonctionnalités dans les deux principales sont l’auto-configuration et les starters.
L’auto-configuration permet d’éviter la creation des fichiers de configuration xml
de Spring, Spring boot crée automatiquement la configuration et l’ajoute à l’ap-
plicationContext. Les starters facilitent la gestion des dépendances. Ils permettent
d’importer un ensemble de dépendances selon la nature de l’application à développer
afin de démarrer rapidement.
4.3.1.2 Spring Data JPA
Spring data JPA est un projet Spring reposant sur Spring Data. Son objectif est
de réduire le cout économique de la couche d’accès aux données en réduisant l’effort
d’écriture du code d’implémentation en particulier pour les méthodes CRUD et de
recherche.
Spring data JPA adopte la notion des repositories qui sont des interfaces à écrire
par le développeur. Spring Data JPA fournit automatiquement les implémentations
nécessaires aux fonctions déclarées.
4.3.1.3 Spring security
Spring Security est un Framework de sécurité léger qui fournit une authentifi-
cation et un support d’autorisation afin de sécuriser les applications Spring. Il est
livré avec des implémentations d’algorithmes de sécurité populaires.
4.3.1.4 PostMan
Pour tester notre application Backend, nous avons utilisé l’outil Postman. Post-
man est un logiciel qui offre la possibilité de tester les api rest. A l’aide de son
40

application bureau, on peut créer, enregistrer et envoyer toutes sortes de requêtes
et les personnaliser. Pour tester notre application nous avons créé une collection des
requêtes que nous avons sauvegardée et utilisée à chaque fois quand voulait tester
notre api.
Figure 4.3: Outil postman
4.3.2 Coté Frontend
4.3.2.1 React.js
Figure 4.4: Logo React
ReactJS est une bibliothèque JavaScript frontend et open-source responsable
seulement de la couche vues d’une application. React est utilisé pour créer des in-
terfaces utilisateurs à base de composants réutilisables.
Les composants react sont crées à partir d’une classe ou bien d’une fonc-
tion JavaScript et fournissent des petites pièces HTML valables à être réutiliser. Un
composant peut être inclus dans un autre composant pour permettre la creation des
41

applications complexes à partir des simples bloques de code JavaScript. Les compo-
sants peuvent maitenenir un état interne "state".
Le principale avantage de React est son implementation d’un DOM virtuel "React
DOM" qui est une represenation du DOM en JavaScript. Quand l’état d’un compo-
sant change React Dom prend charge de mettre à jour le Dom afin qu’il correspond
aux éléments react.
JSX est une extention syntaxique de JavaScript utilisée pour la production des
éléments react. Sa syntaxe ressemble à HTML et XML, sauf qu’en HTML et XML
on parle d’attribut alors qu’en JSX ils sont appelés props. Dans le cas des compo-
sants imbriqués, les props permettent de partager les données entres les composants,
un composant père peut passer des données au composant fils à partir des props de
ce dernier.
L’utilisation de JSX n’est pas du tout obligatoire mais plutot très recommender
pour sa lisibilité et son optimisation comparé au code traditionnel JavaScript.
React router est une extention react de gestion des routes. Son rôle est d’as-
socier les composants react à des urls à l’aide de son composant "route" qui prend
en props le path et le composant react qu’on veut lui associer. Il est aussi possible
de configurer plusieurs routes à la foie en utilisant le composant "switch".
4.3.2.2 Axios
est une librairie JavaScript fonctionnant comme un client HTTP basé sur des
promesses (promise-based) leger. Elle permet la communication avec des API dis-
tantes en utilisant des requêtes HTTP.
Axios est promise-based, cela veut dire qu’il renvoie un objet promesse qui repré-
sente la complétion ou l’échec d’une opération et auquel on attache des callbacks au
lieu de les passer à la fonction elle même.
42

4.3.2.3 Jest
Jest est un framework JavaScript de tests unitaires qui se caractérise par la sim-
plicité. Il permet d’écrire des tests avec une API accessible, familière et riche en
fonctionnalités qui donne des résultats rapides et lisibles .Sa simplicité réside dans
son instalation et sa conﬁguration faciles en comparaison avec d’autres frameworks
de test.
De plus, Jest est conçue pour React. Il vient avec un nouvel outil qui est le test
par snapshot qui permet de capturer un composant et sauvegarder son nom dans
un ﬁchier puis le comparer à chaque exécution du test sur le composant avec le
dom instancié s’il détecte un changement il le signal. Cela permet de détecter plus
facilement de potentielles regressions.
4.4 Conclusion
L’étude téchnique du projet constitue une étude de l’architecture générale de
l’application et une présentation des technologies utilisées. Notre application adopte
une architecture client-serveur est constituée de deux composants logiciels distincts
dont chacun ses propres caractéristiques et responsabilités. Dans ce chapitre nous
avons expliqué l’architecture, détaillé les responsabilités et présenté les téchnologies
utilisées pour le développement de chaqun des deux composants de notre applica-
tion.
43

Chapitre 5
Réalisation
5.1 Introduction
Le dernier chapitre est réservé à la réalisation du projet. Dans ce chapitre nous
allons présenter les interfaces graphiques de notre application.
5.2 Interfaces graphiques
Figure 5.1: Home page
5.2.1 Gestion des inventaires
L’application oﬀre la possibilité de gérer quatre types d’actifs dont les serveurs,
les base données, les web services et les applications. Dans cette partie nous allons
présenter les interfaces de chaque inventaire.
44

CHAPITRE 5. RÉALISATION
5.2.1.1 Inventaire serveur :
Figure 5.2: Inventaire des serveurs
Les boutons "Nouveau serveur" et "Poubelle" ne sont visibles que pour l’admi-
nistrateur serveur.
En cliquant sur le bouton Nouveau Serveur le modèle d’ajout s’aﬃche et l’adminis-
trateur serveur peut maintenant saisir les informations du nouveau serveur.
45

Figure 5.3: Ajouter un nouveau serveur
En cliquant sur les ﬂèches vertes, le modèle contenant la description du serveur
ainsi que les listes des actifs appartenant au serveur s’aﬃchent.
Figure 5.4: Détails d’un serveur
46

En cliquant sur le bouton "stylo" le modèle de modification s’affiche et l’admi-
nistrateur serveur peut maintenant modifier les informations du serveur. Le bouton
n’est visible que pour l’administrateur serveur.
Figure 5.5: Modifier un serveur
5.2.1.2 Inventaire base données :
Figure 5.6: Inventaire des bases données
47

Les boutons "Nouvelle base données" et "Poubelle" ne sont visibles que pour l’ad-
ministrateur base données.
En cliquant sur le boutton "Nouvelle base données" le modèle d’ajout s’affiche et
l’administrateur base donnée peut maintenant saisir les informations de la nouvelle
base données.
Figure 5.7: Ajouter une nouvelle base données
En cliquant sur les flèches vertes, le modèle contenant la description de la BD
s’affiche.
48

Figure 5.8: Afficher la description d’une base données
En cliquant sur le bouton "stylo" le modèle de modification s’affiche et l’adminis-
trateur base données peut maintenant modifier les informations de la base données.
Le bouton n’est visible que pour l’administrateur base données.
Figure 5.9: Modifier une base données
49

5.2.1.3 Inventaire web services :
Figure 5.10: Inventaire des services web
Les boutons "Nouveau web service" et "Poubelle" ne sont visibles que pour l’ad-
ministrateur applicatif.
En cliquant sur le bouton "Nouveau web service" le modèle d’ajout s’aﬃche et l’admi-
nistrateur applicatif peut maintenant saisir les informations du nouveau web service.
Figure 5.11: Ajouter un nouveau service web
50

En cliquant sur les flèches vertes, le modèle contenant la descripion du service
web s’affiche.
Figure 5.12: Afficher la description d’un service web
nistrateur applicatif peut maintenant modifier les informations du web service. Le
bouton n’est visible que pour l’administrateur applicatif.
Figure 5.13: Modifier un service web
51

5.2.1.4 Inventaire applications :
Figure 5.14: Inventaires des applications
Les boutons "Nouvelle application" et "Poubelle" ne sont visibles que pour l’ad-
ministrateur applicatif.
En cliquant sur le bouton "Nouvelle application" le modèle d’ajout s’aﬃche et l’ad-
ministrateur applicatif peut maintenant saisir les informations de la nouvelle appli-
cations.
Figure 5.15: Ajouter une nouvelle application
52

En cliquant sur les flèches vertes, une nouvelle page s’affiche contenant les in-
formations détailées de l’application dont la base données utilisée, le serveur dans
lequel l’application est déployée, et les services web que l’application utilise etc.
Figure 5.16: Afficher les détails d’une applications
nistrateur applicatif peut maintenant modifier les informations de l’application. Le
bouton n’est visible que pour l’administrateur applicatif.
53

Figure 5.17: Modifier une application
5.2.2 Gestion des utilisateurs :
5.2.2.1 Authentification :
Figure 5.18: Login
Dans cette interface l’utilisateur saisie son username et mot de passe afin de
s’authentifier. Le système ensuite le redérige vers son espace personnel après son
authentification.
54

5.2.2.2 Espace utilisateur :
Cette interface affiche les informations de l’utilisateur authentifié.
Figure 5.19: Espace utilisateur
5.2.2.3 Liste des utilisateurs :
Cette interface n’est disponible que pour l’administrateur de l’application.
Figure 5.20: Liste des utilisateurs
En cliquant sur le bouton "stylo" le modèle de modification d’un utilisateur s’af-
55

fiche et l’administrateur peut maintenant modifier les informations d’un utilisateur
ainsi que ses rôles.
Figure 5.21: Modifier un utilisateur
5.2.2.4 Enregistrement d’un utilisateur :
En cliquant sur le bouton "Nouvel utilisateur" le modèle d’ajout d’un nouvel
utilisateur s’affiche et l’administrateur peut maintenant saisir les informations du
nouvel utilisateur.
56

Figure 5.22: Ajouter un utilisateur
5.2.3 Gestion des commentaires
En cliquant sur le bouton "Bulle de commentaire" bleu de n’importe quel actif,
le modèle des commentaires s’aﬃche et liste les commentaires de cet actif.
57

Figure 5.23: Liste des commentaires d’un actif
Le bouton de "pièces jointes" affiche la liste des documments attachés au com-
mentaire, et si l’utilisateur authentifié est propriétaire du commentaire un bouton
plus qui permet d’attacher un document s’affiche.
En cliquant sur le bouton "Nouveau Commentaire" le modèle d’ajout s’affiche et
l’utilisateur peut maintenant ajouter un commentaire à la liste des commentaires de
l’actif.
58

Figure 5.24: Ajouter un commentaire
5.3 Conclusion
Dans ce chapitre, nous avons présenté l’application frontend réalisée de notre
projet. Les interfaces présentées peuvent être améliorées en ajoutant de nouvelles
fonctionnalités adaptées aux besoins des futurs utilisateurs de l’application.
59

Conclusion générale
Dans le cadre de mon projet de ﬁn d’étude, j’ai conçu de développer une applica-
tion de gestion des actifs applicatifs en réponse à la problématique du département
datacenter de la Royal Air Maroc. Le présent manuscrit détaille toutes les étapes
par lesquelles je suis passée pour arriver au résultat attendu. J’ai essayé tout au long
de mon travail de construire une application concrète en utilisant la méthodologie
agile "dynamic software development". Ce travail peut être amélioré, en lui ajoutant
quelques modules ou interfaces pour mieux l’adapter aux besoins de l’utilisateur.
Au cours de la réalisation de mon projet, j’ai été astreinte par quelques limites
notamment, la contrainte de l’état pandemic du monde qui était relativement un
obstacle devant la conduite normale du projet.
60

Webographie
— 3/06/2020 :
— spoonless.github.io
— https ://openclassrooms.com/fr/courses/4668056-construisez-des-microservices/512242
decouvrez-le-framework-spring-boot
— 11/06/2020 :
— https ://blog.ippon.fr/2017/10/12/preuve-dauthentiﬁcation-avec-jwt/
— 23/06/2020 :
— https ://openclassrooms.com/fr/courses/2035826-debutez-lanalyse-logicielle-
avec-uml/2035851-uml-c-est-quoi
— 28/06/2020 :
— https ://medium.com/@mnu/automatiser-les-tests-dintégration-de-votre-
api-avec-postman-et-newman-1051546f3ﬀe
— https ://blog.myagilepartner.fr/index.php/2017/07/23/dsdm-dynamic-systems-
development-method/
— https ://www.agilebusiness.org/page/whatisdsdm
— https ://fr.reactjs.org/docs/getting-started.html
61

Gestion des actifs applicatifs

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Gestion des actifs applicatifs

Similaire à Gestion des actifs applicatifs (20)

Gestion des actifs applicatifs