Mémoire de Projet de Fin D'étude Diplôme D'ingénieur D'état Génie Informatique MOKRINI Yassir

Académie Internationale Mohammed VI de l’Aviation civile
Mémoire de projet de fin d’étude

Pour l’obtention du
Diplôme d’ingénieur d’état

Spécialité :
Génie informatique
Elaboré par :
MOKRINI Yassir
Sujet :
Mise en place d’une solution de centralisation des

données
Encadré par :
➢ M HAIN Mustapha Tuteur interne

➢ M MOUSGHI Redouan Encadrant externe
Dédicaces
Du profond de mon cœur je dédie ce travail à tous ceux qui me sont chers,
Mes parents :
Que ce travail soit l’expression de ma reconnaissance de vos sacrifices consentis, votre soutien moral et matériel que
vous n’avez cessé de prodiguer.
Vous avez tout fait pour mon bonheur et ma réussite.
Que Dieu vous préserve en bonne santé et vous accorde une longue vie.
Mon frère et ma sœur :
J’espère que j’ai été à la hauteur de vous attentes. Que ce travail soit l’expression de mes profondes affections.
Je suis ravi de vous avoir à mes cotés durant mon cursus académique
Mes camarades de classe GI 13 et 14 :
C’était un grand honneur de vous rencontrer et d’étudier avec vous durant mes années du cycle d’ingénieur à
L’AIAC
A mes chers professeurs :
Je vous remercie pour votre temps que vous avez consacré et le savoir que vous nous avez transmis tout au long de
notre formation à l’AIAC
Au Staff Administratif :
Je vous remercie pour avoir veiller à la qualité de notre formation en tant que futurs ingénieurs au sein de
l’établissement et aux efforts consacré pour notre réussite
A toute personne qui a contribué à mon éducation, à toute personne m’ayant aidé un jour, à travers un conseil, à
tous ceux qui ont contribué de près ou de loin à la réussite de ce projet.
MOKRINI Yassir
Remerciements
De prime abord, Merci à Dieu pour sa bonté et sa gratitude sans lesquelles je ne pourrai en
aucun cas être ici.
Ensuite, je tiens à remercier M. Redouane EL MOUSGHI et Mme. Amal BENDDRISS pour
leurs accueils, leurs orientations, leurs conseils ainsi que leurs précieuses directives et la
confiance qu’ils m’ont accordé tout au long du stage.
Je tiens à remercier vivement M. Mustapha Hain pour les conseils qu’il m’a prodigué et son
judicieux encadrement.
Mes remerciements vont également à mes professeurs de la filière génie informatique, le
chef de filière M. Adil REDOUANE et à l’ensemble des professeurs et cadres administratifs de
l’Académie Internationale Mohamed VI de l’Aviation Civile, pour la qualité de la formation
qu’ils m’ont assurée.
Nous espérons que ce projet de fin d’étude sera à la hauteur des attentes des membres de
jury.
Au terme de ce projet de fin d’étude, je tiens à présenter mes sincères remerciements à
tous ceux ou celles qui de près ou de loin ont contribué à sa réalisation.
Résumé
Le présent mémoire rend compte des travaux effectués lors de mon projet de fin d’études
au sein de la société MercureIT.
Il était question, lors de ce projet, de concevoir et développer une plateforme de

centralisation des données, pour assurer la sécurité et la disponibilité de celles-ci, pour les
exploitées par la suite dans des projets BI.
Cette solution permettra donc de préserver les donner dans un serveur distant en tout
sécurité afin de les exploiter plus tard.
Ainsi, elle offrira maintes fonctionnalités : permettre aux différents acteurs de collaborer
entre eux, la disponibilité des données et leurs sécurités, permettre aux utilisateurs de
consulter les travaux de leurs collègues de la même équipe et la possibilité d’importer et
exporter leurs travaux pour continuer hors ligne.
Pour atteindre les objectifs du projet, j’ai utilisé un ensemble d’outils et technologies. Pour
la gestion de projet j’ai opté pour la méthode Scrum vu sa complémentarité, pour la
modélisation j’ai utilisé le langage UML et j’ai exploité l’outil draw.io pour réaliser les différents
diagrammes. En outre j’ai fait le choix d’utiliser SqlServer comme SGBDR, et les technologies
de développement Spring pour la partie backend et Angular pour la partie frontend.
Mots-clés: BI, UML,Scrum,Drow.io,SqlServer,Spring,Angular

abstract
This thesis reports on the work carried out during my end of studies project within the
company MercureIT.
It was a question, during this project, of designing and developing a data centralization
platform, to ensure its security and availability, for subsequent use in BI projects.
This solution will therefore allow the data to be stored safely on a remote server in order
to be used later.
Thus, it will offer many functionalities: allow the different actors to collaborate with each
other, the availability of data and their security, allow users to consult the work of their
colleagues from the same team and the possibility of importing and exporting their work to
continue offline.
To achieve the objectives of the project, I used a set of tools and technologies. For project
management I opted for the Scrum method given its complementarity, for modeling I used the
UML language and I used the draw.io tool to create the different diagrams. In addition, I made
the choice to use SqlServer as a relational database management system
, and Spring development technologies for the backend part and Angular for the frontend part.
key words: BI,UML,Scrum,Drow.io,SqlServer,Spring,Angular

‫ملخص‬
‫است ضمن رشكة ‪.MercureIT‬‬ ‫ر‬
‫تتناول هذه األطروحة العمل الذي أنجزته خالل مشوع نهاية در ي‬
‫المشوع عن تصميم وتطوير منصة مركزية البيانات ‪ ،‬لضمان أمانها وتوافرها ‪ ،‬لستخدامها‬‫لقد كان سؤال خالل هذا ر‬
‫ً‬
‫لحقا‪.‬‬ ‫مشوعات ‪.BI‬‬ ‫ً‬
‫لحقا ف ر‬
‫وبالتال ‪ ،‬سيسمح هذا الحل بتخزين البيانات بأمان عىل خادم بعيد ليتم استخدامها‬
‫ي‬ ‫ي‬
‫وبالتال ‪ ،‬سيوفر العديد من الوظائف‪ :‬السماح للجهات الفاعلة المختلفة بالتعاون مع بعضها البعض ‪ ،‬وتوافر البيانات‬
‫ي‬
‫وأمانها ‪ ،‬والسماح للمستخدمي بالتشاور مع عمل زمالئهم من نفس الفريق وإمكانية استياد وتصدير أعمالهم لمواصلة‬
‫خارج الخط‪.‬‬
‫المشوع ‪ ،‬استخدمت مجموعة من األدوات والتقنيات‪ .‬بالنسبة إلدارة ر‬
‫المشوع ‪ ،‬اخيت طريقة سكروم‬ ‫لتحقيق أهداف ر‬
‫ً‬
‫نظرا لتكاملها ‪ ،‬وللتصوير ‪ ،‬استخدمت لغة ‪ UML‬واستخدمت أداة ‪ draw.io‬إلنشاء الرسوم البيانية المختلفة‪ .‬باإلضافة إل‬
‫الخلف و‬
‫ي‬ ‫ذلك ‪ ،‬لقد اخيت استخدام ‪ SqlServer‬كنظام إلدارة قواعد البيانات العالئقية ‪ ،‬وتقنيات تطوير ‪ Spring‬للجزء‬
‫األمام‪.‬‬
‫ي‬ ‫‪ Angular‬للجزء‬
‫‪key words: BI,UML,Scrum,Drow.io,SqlServer,Spring,Angular‬‬

Liste des abréviations
Abréviation Désignation
API Application Programming Interface
BI Business intelligence
DAO Data Access Object
DTO Data transfer Object
IHM Interface Homme Machine
IoC Inversion Of control
HTML Hypertext Markup language
HTTP Hypertext Transfer Protocol
JAR Java Archive
JDBC Java Data base Connectivity
JSON JavaScript Output notation
JWT JSON Web Token
MVC Model Vue Controller
POM Project Object Model
SQL Structured Query language
SGBDR Système de gestion de base de données
relationnelle
SPA Single Page Application
REST REpresentational State Transfer
UML Unified Modeling Lagunage
XML eXtensible Markup Language
Liste des Tableaux
Tableau 1: registre des risques 16
Tableau 2: description des rôles du système 21
Tableau 3:Description cas d’utilisation "authentification" 22
Tableau 4: Description cas d’utilisation gestion des datasets 23
Tableau 5:description cas d'utilisation gerer les utilisateur 23
Tableau 6:description du cas d'utilisation "gestion des workflows" 24
Tableau 7:description cas d'utilisation "envoyer/lire message" 24
Tableau 8:Description cas d’utilisation "manipulation des datasets" 25
Tableau 9:Description cas d’utilisation "importer/exporter datadsets" 25
Tableau 10:Description cas d’utilisation consulter les vues des datsets 26
Tableau 11:Description de la classe user 32
Tableau 12: Description de la classe rôle 32
Tableau 13: Description de la classe privilège 32
Tableau 14:Description de la classe dataset 33
Tableau 15: description de la classe attribut 33
Tableau 16: description de la classe cell 33
Liste des figures
Figure 1 : organigramme de l’entreprise 4
Figure 2 : schéma d’un système BI 6
Figure 3: mise en place de solution 7
Figure 4:Méthodes agiles en fonction de la taille du projet 9
Figure 5: vue du processus scrum 10
Figure 6: Taches du Product Owner 11
Figure 7:scrume backlog 12
Figure 8: sprints du projet 13
Figure 9: diagramme Gantt 15
Figure 10:matrice des risques 17
Figure 11 : cas d'utilisation administrateur utilisateur 22
Figure 12 diagramme de séquence d'authentification 27
Figure 13 : DIAGRAMME de séquence de création des datasets 28
Figure 14: diagramme de séquence attribution des droit au datset 29
Figure 15: Diagramme de séquence de suppression d’un utilisateur 29
Figure 16: Diagramme de séquence de messagerie 30
Figure 17:diagramme de classes du système 31
Figure 18:architecture 3-tiers 36
Figure 19:architecture du modèle MVC2 38
Figure 20:architecture d'une application Spring Boot 40
Figure 21:architecture de Spring Security 41
Figure 22:explication du fonctionnement de Jwt 43
Figure 23:detail de fonctionnement d jwt cote client 44
Figure 24: Etude comparative des Framework de mapping objet relationnel 45
Figure 25:architecture full-Stack angular Spring boot 50
Figure 26:structur du projet Spring Boot 51
Figure 27:structure d'un projet angular 52
Figure 28: interface d'authentification 53
Figure 29:interface d'inscription 54
Figure 30: espace d'accueil admin 55
Figure 31:espace d'accueil utilisateur 55
Figure 32:interface de création datset 56
Figure 33:interface d'attribution des droits 57
Figure 34:interface de messagerie 57
Figure 35:interface de manipulation de dataset 58
Table de Matières
DEDICACES ....................................................................................................................................................... 2
REMERCIEMENTS ............................................................................................................................................. 3
RESUME ........................................................................................................................................................... 4
ABSTRACT ........................................................................................................................................................ 5
‫ ملخص‬................................................................................................................................................................ 6
LISTE DES ABREVIATIONS ................................................................................................................................. 7
LISTE DES TABLEAUX ........................................................................................................................................ 8
LISTE DES FIGURES ........................................................................................................................................... 9
TABLE DE MATIERES ...................................................................................................................................... 10
INTRODUCTION GENERALE .............................................................................................................................. 1
CHAPITRE 1 ...................................................................................................................................................... 2
1. PRESENTATION DE L’ORGANISME D’ACCUEIL ........................................................................................................ 3
1.1. Infrastructure ...................................................................................................................................... 3
1.2. Les activités de l’entreprise ................................................................................................................. 3
1.3. Organigramme ................................................................................................................................... 4
1.4. Clients de la société............................................................................................................................. 5
2. PROBLEMATIQUE ............................................................................................................................................ 6
3. METHODOLOGIE DE TRAVAIL ............................................................................................................................. 7
3.1. Présentation SCRUM : ......................................................................................................................... 9
3.1.1. Backlog ...................................................................................................................................................... 11
3.1.2. Sprints ....................................................................................................................................................... 13
4. MANAGEMENT DU PROJET .............................................................................................................................. 13
4.1. Planification du projet :..................................................................................................................... 13
4.2. Diagramme de Gantt ........................................................................................................................ 14
4.3. Matrice des risques ........................................................................................................................... 16
CHAPITRE 2 .................................................................................................................................................... 19
1. DIAGRAMME CAS D’UTILISATION...................................................................................................................... 20
1.1. Identification des acteurs .................................................................................................................. 20
1.2. Diagramme de cas d’utilisation ........................................................................................................ 21
2. DIAGRAMME DE SEQUENCES ........................................................................................................................... 26
2.1. Diagramme de séquence d’authentification ..................................................................................... 27
2.2. Diagramme de séquence de création des datasets .......................................................................... 28
2.3. Diagramme de séquence d’attribution des droits sur les datset ...................................................... 29
2.4. Diagramme de séquence de suppression d’un utilisateur ................................................................ 29
2.5. Diagramme de séquence de messagerie .......................................................................................... 30
3. DIAGRAMME DE CLASSES ................................................................................................................................ 30
CHAPITRE 3 .................................................................................................................................................... 35
1. ARCHITECTURE LOGICIEL DU SYSTEME ............................................................................................................... 36
2. TECHNOLOGIE ET FRAMEWORK ........................................................................................................................ 37
2.1. La technologie JEE ............................................................................................................................. 37
2.2. Design Pattern MVC et valeur ajoutée de MVC2 .............................................................................. 37
2.3. Choix du Framework Spring boot ...................................................................................................... 38
2.4. Json Web Token (JWT) ...................................................................................................................... 42
2.5. Choix de la Framework Hibernate..................................................................................................... 45
2.6. Choix de SQL server ........................................................................................................................... 45
2.7. Choix de maven ................................................................................................................................. 46
2.8. Javascript .......................................................................................................................................... 46
2.9. Framework Angular .......................................................................................................................... 46
2.10. Choix de Angular ........................................................................................................................... 47
2.11. Choix de git ................................................................................................................................... 49
3. STRUCTURE DU PROJET ................................................................................................................................... 50
Structure du projet Spring boot : .................................................................................................................. 51
Structure du projet Angular .......................................................................................................................... 52
4. DESCRIPTION DES IHMS ................................................................................................................................. 53
4.1. Interface d’authentification .............................................................................................................. 53
4.2. Interface d’inscription ....................................................................................................................... 54
4.3. Espaces d’accueil pour administrateur ............................................................................................. 54
4.4. Espace d’accueil pour utilisateur normal .......................................................................................... 55
4.5. Interface de création des datsets ...................................................................................................... 56
4.6. Interface d’attribution des droits aux utilisateur .............................................................................. 57
4.7. Interface de messagerie .................................................................................................................... 57
4.8. Interface manipulation des dataset .................................................................................................. 58
CONCLUSION GENERALE ................................................................................................................................ 59
BIBLIOGRAPHIES ............................................................................................................................................ 60
WEBOGRAPHIES ............................................................................................................................................ 61
ANNEXES ....................................................................................................................................................... 62
ANNEXE A : ORGANISATION DU PROJET..................................................................................................................... 63
1. Rôles et responsabilité .......................................................................................................................... 63
2. Organisation de réunion ....................................................................................................................... 63
3. Démarche de développement ............................................................................................................... 63
ANNEXE B : TECHNOLOGIES ET OUTILS UTILISES .......................................................................................................... 65
1. Technologie ........................................................................................................................................... 65
1.1. Spring boot .................................................................................................................................................... 65
1.2. Hibernate....................................................................................................................................................... 66
1.3. Spring Security ............................................................................................................................................... 67
1.4. Angular .......................................................................................................................................................... 67
2. Outils ..................................................................................................................................................... 68
2.1. Git .................................................................................................................................................................. 68
2.2. Apache Maven ............................................................................................................................................... 68
Introduction générale
L’informatique décisionnelle (en anglais : DSS pour Decision Support System ou encore BI
pour Business Intelligence) désigne les moyens, les outils et les méthodes qui permettent de
collecter, consolider, modéliser et restituer les, matérielles ou immatérielles, d'une entreprise
en vue d'offrir une aide à la décision et de permettre aux responsables de la stratégie
d'entreprise d’avoir une vue d’ensemble de l’activité traitée.
Mais pour qu’un système BI soit opérationnel, il doit être alimenter par des données
précises, souvent c’est données son stoker dans les ordinateurs personnels des différents
acteurs de ce système, et dans la plupart des cas ces données stoker dans les terminaux locaux
rencontre plusieurs menaces qui peuvent aboutir à la perte définitive de la donnée (ex : perte
ou vole de l’ordinateur attaque cybercriminel …). Donc si les données sont les éléments
importons pour l’aide a la décision il faut les garder en sécurité jusqu’à exploitation par le
système BI.
C’est dans ce cadre j’ai effectué mon stage de fin d’études au sein de la société MercureIT
qui consiste en une immersion opérationnelle dans une équipe, portant sur les nouvelles
technologies de l’information et de la communication. Ce stage cible à concevoir et à
développer une solution pour augmenter la sécurité et la disponibilité des données
Le présent rapport est une synthèse du travail effectué durant mon stage. Il s’articule
autour de trois chapitres. Le premier chapitre définit le contexte général du projet, à savoir, la
présentation de l’organisme d’accueil ainsi que la présentation du projet. Le deuxième chapitre
détaille les spécifications fonctionnelles. Le troisième chapitre a comme objectif la
présentation des différents outils et technologies utilisés pour réaliser le projet.
1|P a g e
Chapitre 1
Contexte général du projet
Nous commençons ce chapitre par une description de l’organisme

d’accueil. Nous présentons ensuite l’objectif du projet. Enfin nous décrivons le
processus de développement suivi et la planification du projet.
2|P a g e
Introduction
Dans ce chapitre, nous situons le projet dans son environnement organisationnel et
contextuel. Nous commençons par introduire l’organisme d’accueil, avant de présenter une
vue générale du projet. Nous exposons à la fin la démarche adoptée pour sa réalisation.
1. Présentation de l’organisme d’accueil
1.1. Infrastructure
MERCURE IT est une société de conseil et d’ingénierie informatique qui propose des
logiciels d’informatique de gestion et des services pour les petites et moyennes entreprises
(PME) créée en 2008, réactive et disponible plaçant la satisfaction client au centre de ses
motivations.
1.2. Les activités de l’entreprise

MERCURE IT met l'accent sur la complémentarité entre sens du service, respect des
engagements et volonté de faire évoluer ces clients. Ces valeurs, communes à ces équipes,
leurs permettent d'offrir un service complet et de proximité à ces clients.
La société aujourd’hui offre des différents services complets :
- Consulting :
Notre offre de Conseil, est basée sur une approche métier couplée d’une expertise
technique, pour anticiper et accompagner vos besoins.
- E-commerce :
Que vous ayez déjà une activité et que vous vouliez la développer, ou que vous souhaitiez
vous lancer dans la vente en ligne, nous somme capable d’étudier avec les solutions les plus
efficaces et les plus pérennes.
- Ingénierie applicative :
Nous offrons des services de développement applicatif et logiciel sur mesure, prenant en
compte les dernières technologies.
- Accompagnement :
Maîtrise d'ouvrage, Maîtrise d’œuvre, organisation... Nous analysons les contextes pour
préconiser méthodes et solutions.
3|P a g e
1.3. Organigramme
MERCURE IT est une société de service à taille humaine, réactive et disponible plaçant la
satisfaction client au centre de ses motivations.
La connaissance du marché, les compétences de ces collaborateurs, le partage de valeurs

telles que l’écoute, le respect des engagements, et la priorité donnée à la qualité de service
sont autant d’ingrédients qui la permettent de prendre en charge vos projets avec une grande
sérénité.
L’entreprise s’organise de la manière suivante :
F IGURE 1 : ORGANIGRAMME DE L ’ENTREPRISE
4|P a g e
1.4. Clients de la société
Donc comme nous avons vu précédemment la société MercuerIT opère dans plusieurs
domaines de l’informatique ce qui lui donne avantage dans le marché pour attirer plusieurs
clients cherchant ses services.
Parmi ces principales clientes on peut citer :
Ichara conseil
Banque marocaine pour le commerce et l'industrie
Union Marocaine de Banques
Société générale Maroc
Viadia
5|P a g e
2. Problématique
L’informatique décisionnelle est l'informatique à l'usage des décideurs et des dirigeants

d'entreprises. Elle désigne les moyens, les outils et les méthodes qui permettent de collecter,
consolider, modéliser et restituer les données, matérielles ou immatérielles, d'une entreprise
en vue d'offrir une aide à la décision et de permettre à un décideur d’avoir une vue d’ensemble
de l’activité traitée selon le schémas suivant :
F IGURE 2 : SCHEMA D ’UN SYSTEME BI
Or cette représentation comporte un risquée, car les données brutes dans les terminaux
locaux des différents acteurs du système sont susceptibles a la perte (vol de l’ordinateur, virus,
oublie de l’ordinateurs quelques part …..).
Donc comment peut-t-on protéger ces ressources du système jusqu’à leurs exploitation ?
et comment peut-t-on permettre aux différents utilisateurs de collaborer avec aisance ?
6|P a g e
Donc pour remédier à ce problème, on a décidé de mettre en place une plate-forme pour
centraliser ces données, d’une manière sécurisée et efficace comme le montre le schéma ci-
dessous :
F IGURE 3: MISE EN PLACE DE SOLUTION
Donc comme vous pouvez voire la différence le système BI au paravent extrait les données
a exploité des différents terminaux locaux des utilisateur, mais cette solution permet aux
différents su système de faire leur travail via une plate-forme centralisée qui permet
d’augmenter la sécurité et la disponibilité des données, et leur permet aussi de télécharger les
fichiers de données pour continuer leurs travails hors ligne et les chargés sur la plate-forme
par la suite.
3. Méthodologie de travail
Au sein de l’entreprise la méthodologie du travail appliqué c’est la méthode agile
La méthodologie Agile se base sur des cycles de développements courts et des

spécifications fonctionnelles « volatiles » (amenées à changer au cours du développement). Il
7|P a g e
existe plusieurs méthodes agiles, telles que XP, SCRUM, Crystal Clear, etc. mais ont toutes pour
objectif d’augmenter la satisfaction du client tout en facilitant les développements.
Les méthodes de développement Agile correspondent efficacement à l’approche de

développement pour l’entreprise. C’est une méthode de développement proche des attentes
clients et basée sur l’amélioration continue du système.
En effet, la solution de faire des spécifications sur plusieurs semaines qui seraient figées ne
s’avère pas efficace à mercureIT. Nous avons donc choisi la méthode Agile parce que le besoin
n’est pas exprimé précisément, c’est une discussion avec le fonctionnel qui évolue tout au long
du projet. Nous pouvons ainsi être plus proches du besoin fonctionnel.
La méthode Agile recommande parmi ses nombreux principes :
- Parvenir à la satisfaction du client par le biais d’un cycle rapide, récurrent et

incrémental de versions fonctionnelles.
- Se montrer apte à prendre en compte les changements de dernière minute à tout

moment du projet.
- Mettre en place une coopération quotidienne entre développeurs et chefs de projet

technique et fonctionnel.
- Motiver les développeurs par un environnement, un soutien et une confiance toujours

présents.
- Faire simple, mais pas simpliste.
- Laisser l’équipe s’organiser au mieux de ses possibilités.
Ces principes sont résumés en quatre points :
-Les individus et leurs interactions plutôt que les processus et les outils.
- Le logiciel qui fonctionne plutôt que la documentation complète.
- La coopération avec le client plutôt que la négociation du contrat.
- Répondre au changement plutôt que suivre un plan.
Ainsi, les méthodes agiles promeuvent de nouvelles méthodes de développement basées

sur l’expérience de chacun, la communication entre toutes les personnes impliquées dans le
8|P a g e
projet, et la flexibilité des plannings. De nombreuses méthodes répondent à ces
caractéristiques, le graphique suivant présente ces méthodes recensées dans le Manifeste
Agile, ainsi que leur usage en fonction de la taille du projet :
F IGURE 4:METHODES AGILES EN FONCTION DE LA TAILLE DU PROJET
3.1. Présentation SCRUM :

Né en 1996 grâce aux travaux de Ken Schwaber et Jeff Sutherland, Scrum est considéré
comme un processus de développement, et s’est inspiré des méthodes collectives du Rugby
(le nom « Scrum » signifiant « Mêlée »). « Considéré » comme un processus, mais n’en est pas
vraiment un, ni même une méthode (au sens Agile). En effet, les fondateurs désignent Scrum
de la façon suivante : « Scrumis not aprocess or a methodology, but apath. »
Cette méthode décrit un chemin à suivre pour atteindre un but ainsi qu’un cadre de travail.
Afin d’obtenir une méthodologie complète, il est nécessaire d’associer Scrum à une autre
méthodologie Agile telle que eXtremeProgramming (ou XP). Le graphique suivant détaille la
voie à suivre pour obtenir la release d’une application :
9|P a g e
F IGURE 5: VUE DU PROCESSUS SCRUM
Comme dit dans la partie précédente, une méthode Agile fonctionne par itération de
développements cours, au sens Scrum, ces itérations sont nommées « Sprints ». Un Sprint est
d’une durée fixée, ne change jamais et se doit d’être inférieur à 6 semaines.
Le Product Backlog énumère les exigences du client sur un produit et sont triés par priorité.
Un Sprint Backlog est une tâche liée à un Product Backlog et à réaliser par l’équipe pendant
un Sprint. Durant un Sprint, toutes les tâches de développement, de la conception à la recette,
doivent être réalisées afin de produire en fin de Sprint un produit potentiellement livrable.
Une équipe, au sens Scrum, est constituée des développeurs, mais aussi de deux personnes
possédantes chacune un rôle précis et important : Le Product Owner, et le Scrum Master. Le
Product Owner est le représentant des clients et utilisateurs et est chargé de définir les
caractéristiques du produit développé par l’équipe (le Product Backlog). Plus précisément, il se
doit d’identifier les exigences d’un produit, de les prioriser pour définir chaque Sprint Backlog
de chaque Sprint, et de fournir les détails à l’équipe. Son but est défini l’objectif d’une release
et de prendre les décisions liées au planning de cette release. Pour effectuer ces tâches, le
Product Owner doit être une personne proche du métier visé par le produit, doit avoir une
relation confiance avec les clients et utilisateurs, et être ouvert à tout changement.
10 | P a g e
Le graphique ci-dessous résume les tâches de ce rôle :
F IGURE 6: T ACHES DU PRODUCT OWNER
Le Scrum Master, ou couramment appelé « Chef de Projet », a pour responsabilité de

garantir l’application du processus Scrum. Pour cela, il se doit de planifier les Sprints et éliminer
les obstacles que peuvent rencontrer l’équipe de développement. Enfin, il est l’animateur des
Daily Scrum Meeting, réunions d’équipe quotidiennes permettant d’effectuer une revue du
sprint :
- Qui a fait quoi la veille ?
- Qui fera quoi ce jour-ci ?
- Obstacles rencontrés, ou possibles ;
- Modification de la planification, évènements imprévus.
Un Scrum Master doit savoir être à l’écoute de son équipe, être apte à les motiver et à
favoriser la communication entre les membres. Il doit donc réellement s’intégrer dans le
développement et être professionnellement proche des développeurs. Enfin, il doit protéger
l’équipe de toute interaction extérieure, telles que le client et les utilisateurs.
3.1.1. Backlog
Pour résumer, le backlog scrum est destiné à recueillir tous les besoins du client que
l’équipe projet doit réaliser. Il contient donc la liste des fonctionnalités intervenant dans la
constitution d’un produit, ainsi que tous les éléments nécessitant l’intervention de l’équipe
11 | P a g e
projet. Tous les éléments inclus dans le backlog scrum sont classés par priorité indiquant
l’ordre de leur réalisation.
Les éléments figurent dans le back log suivant :
F IGURE 7: SCRUME BACKLOG
La constitution du backlog scrum commence par la matérialisation et la définition des

objectifs du produit, des utilisateurs ciblés et des différents acteurs du projet. Une liste
d’exigences sera ensuite établie. Elles peuvent être fonctionnelles ou non fonctionnelles.
Chaque exigence va être analysée par l’équipe de développement puis le coût de sa réalisation
va être évalué lors du planning poker scrum.
12 | P a g e
Une liste de fonctionnalités va être extraite de cette liste d’exigences et elles vont être
classées par ordre de priorité de réalisation. Cet ordonnancement est effectué en fonction de
la valeur ajoutée que les fonctionnalités apportent au produit. C’est cette liste de
fonctionnalité ordonnée qui constitue le backlog scrum.
3.1.2. Sprints
La méthode se caractérise par le partitionnement du projet en incréments, nommés «
sprint ».
Les sprints peuvent durer de quelques heures à quelques semaines (avec une préférence
pour deux semaines).
Chaque sprint commence par une estimation suivie d’une planification opérationnelle. Le
sprint se termine par une démonstration de ce qui a été réalisé.
Avant de démarrer notre projet, nous avons réalisé une analyse de ce qui doit être produit,
nous avons découpé le projet en 3 Sprints principaux :
F IGURE 8: SPRINTS DU PROJET
4. Management du projet
4.1. Planification du projet :

Pour mieux gérer les étapes de projet dans le cadre de l’espace temporel alloué au stage,
l’élaboration d’un plan d’assurance qualité s’avère d’une nécessité primordiale. Ce plan
13 | P a g e
permet d’identifier rôles et responsabilités et permet d’assurer le bon déroulement du projet
comme il permet de mesurer son avancement.
4.2. Diagramme de Gantt

La planification temporelle est une étape avant-projet qui non seulement permet de
délimiter le périmètre du projet mais aussi de prévoir le déroulement des activités tout au long
de la période de stage. La figure suivante présente le détail de cette planification à travers les
diagrammes de Gantt.
14 | P a g e
F IGURE 9: DIAGRAMME GANTT
15 | P a g e
Description :
Le déroulement du stage est comme suit :
- Une période de formation qui a duré un mois (du 10/02/2020 au 20/03/2020), dans
laquelle on a appris des modules de Spring, comme Spring boot, Spring Security et
Spring cloud.
- Une étape de planification de durée de 2semaines et demi (du 23/03/2020 au
08/04/2020), sur les méthodologies de travail et l’organisation de l’équipe.
- Une période d’analyse et conception de durée d’une semaine et demi (du
09/04/2020 au 20/04/2020), dans laquelle on a conçu nos diagrammes UML.
- Une période d’une semaine (du 21/04/2020 au 26/04/2020) sur laquelle on s’est mis
d’accord sur les technologies, avec lesquelles on va travailler, comme l’outil git, la
Framework Angular pour le développement du front end.
- Du 27/04/2020 au 30/06/2020 : on a réalisé les 3 sprints du projet.
4.3. Matrice des risques

- Registre des risques :
Numéro de risque Description
R1 Spécifications (cahier des charges) ambigüe
R2 Évolution des technologies
R3 Demandes de changements au cours du
projet
R4 Manque d’expertise de la maîtrise d’œuvre
R5 Mauvaise installation
R6 Conflits entre les membres d’équipe
R7 Rupture de stage cause de la pandémie
T ABLEAU 1: REGISTRE DES RISQUES
Ce tableau liste les principaux risques rencontrer lors de la réalisation du projet.
16 | P a g e
- Matrice des risques :
F IGURE 10:MATRICE DES RISQUES
On peut placer les risques dans la matrice selon deux paramètres, la gravité de son
impact, et sa probabilité.
La matrice des risques ce devise en 3 zones :
• Zone Jaune:
On considère ici le risque comme minimal et ne requiert aucune action.
Mais on doit être vigilant, car un risque peut changer de statuts et peux donc passer
d’une zone à l’autre.
• Zone Orange:
On considère que les risques de cette zone sont gérables.
Pour ces risques-là vous pouvez, planifier des actions préventives et/ou correctives.
Pour remédier aux risques (R1, R2, R3) nous avons envisager les solutions suivantes :
- R1 on doit poser plus de question pour clarifier les choses.

- R2 avoir accès aux documentations des nouvelles technologies.
- R3 nous avons employé la méthode Scrum pour nous aider sur ce risque.
17 | P a g e
• Zone Rouge:
On considère ici le risque comme dangereux et nécessite impérativement une

intervention.
Pour éviter ce risque l’équipe a décidé d’employer des outils pour collaborer à distance
comme la plate-forme Microsoft-teams.
Conclusion
Dans ce chapitre, nous avons présenté dans un premier temps une vue globale sur
l’organisme d’accueil, et dans un second temps, nous avons décrit le contexte et les objectifs
de notre projet. Enfin nous avons expliqué le processus de développement adopté pour la mise
en place de la solution. Sur la base de ce processus, nous avons établi un planning de travail
afin de donner une idée sur le déroulement du projet.
18 | P a g e
Chapitre 2
Analyse et conception
Dans ce chapitre, nous présentons l’analyse et détaillons les spécifications pour

la réalisation des sprints du projet et l’ensemble des cas d’utilisations de ces
sprints.
19 | P a g e
Introduction
La partie Analyse et Spécification a pour objectif la capitalisation de la connaissance du
métier du système à réaliser. Dans cette partie nous avons capturé les besoins fonctionnels du
système tout en définissant les activités attendues des différents utilisateurs par rapport au
système.
1. Diagramme cas d’utilisation
Les cas d’utilisations permettent de représenter les différentes fonctionnalités offertes par
le système à l’utilisateur.
Les cas d’utilisation constituent un moyen de recueillir et de décrire les besoins des acteurs
du système. Ils peuvent être aussi utilisés ensuite comme moyen d’organisation du
développement du logiciel, notamment pour la structuration et le déroulement de tests du
logiciel.
Un cas d’utilisation peut être considéré comme une collection de scénario possible qui
représente l’interaction entre les acteurs et le système.
1.1. Identification des acteurs

La première étape du formalisme UML utilisé consiste en l’identification des acteurs
interagissant avec le système. Afin d’organiser ces interactions nous les avons classés en «
Rôles ». En se basant sur les besoins fonctionnels recensés, nous avons identifié les rôles
suivants :
-Administrateur.
-Utilisateur.
Chaque rôle remplie une mission assumée par des entités externes au système qui peuvent
être un ou plusieurs acteurs. La table suivante présente les missions des rôles identifiés.
20 | P a g e
Acteurs Missions
Administrateur -gérer les utilisateurs
-gérer les workflows
-géré les datasets
-envoyer/lire les message
Utilisateur -manipuler les datasets
-importer/exporter les datasets
- envoyer/lire les message
-consulter des vue
T ABLEAU 2: DESCRIPTION DES ROLES DU SYSTEME
1.2. Diagramme de cas d’utilisation

Après avoir identifié les rôles et leurs missions dans la section précédente, il est nécessaire
de déterminer pour chaque rôle les cas d’utilisations qui lui sont dédiés.
La figure qui suit présente les cas d’utilisations du système pour les deux rôles.
21 | P a g e
F IGURE 11 : CAS D'UTILISATION ADMINISTRATEUR UTILISATEUR
- Description cas d’utilisation authentification :
Sommaire d’identification
Titre : authentification
Objectif : Ce cas d’utilisation permet à l’utilisateur de se connecter à l’application pour
pouvoir bénéficier de ses fonctionnalités.
Acteurs : - Administrateur
-utilisateur
Description Scenarios
Préconditions : aucune
Postconditions : utilisateur existe dans la base de données
Scenario nominal : se connecter sur la plate-forme
T ABLEAU 3:DESCRIPTION CAS D ’UTILISATION "AUTHENTIFICATION "
22 | P a g e
- Description cas d’utilisation gérer les datasets :
Titre : gérer les datasets
Objectif : ce cas d’utilisation permet la création, la suppression, et la modification des
datasets.
Acteurs : administrateurs
Description scenarios
Préconditions : authentification réussite
Postcondition : utilisateur est un administrateur
Scenario nominal : remplir le formulaire de création des datasets.
Suppression des datatsets
Ajouter ou supprimer de attributs du dataset
Attribuer les droits des datasets aux utilisateurs
T ABLEAU 4: DESCRIPTION CAS D ’UTILISATION GESTION DES DATASETS
- Description cas d’utilisation gérer les utilisateurs :
Titre : gérer les utilisateurs
Objectif : ce cas d’utilisation permet de supprimer modifier les utilisateurs
Acteurs : administrateur
Précondition : authentification réussite
Postcondition : utilisateur doit être un administrateur
Scenario nominal : voir la liste des utilisateurs, supprimer les utilisateurs, modifier les
utilisateur
T ABLEAU 5: DESCRIPTION CAS D 'UTILISATION GERER LES UTILISATEUR
23 | P a g e
- Description cas d’utilisation gérer les workflows :
Titre : gérer les workflows
Objectif : ce cas d’utilisation permet de créer supprimer modifier les workflows
Acteurs : administrateur
Postcondition : utilisateur doit être un administrateur
Scenario nominal : ajouter des répertoires des workflows, supprimer les répertoires,
affecter les droits aux utilisateurs sur ces workflows
T ABLEAU 6: DESCRIPTION DU CAS D 'UTILISATION "GESTION DES WORKFLOWS "
- Description du cas d’utilisation envoyer et recevoir les messages :
Titre : envoyer et recevoir les messages
Objectif : ce cas d’utilisation permet aux différents utilisateurs de collaborer entre eux
Acteurs : administrateur utilisateur
Postcondition : aucune
Scenario nominale : envoyer un message a un ou plusieurs destinataires
Lire les messages de l’émetteur
T ABLEAU 7: DESCRIPTION CAS D 'UTILISATION "ENVOYER /LIRE MESSAGE "
24 | P a g e
- Description cas d’utilisation manipuler les datasets :
Titre : manipuler les datsets
Objectif : ce cas d’utilisation permet aux utilisateurs d’ajouter du contenu aux datasets
Acteurs : utilisateur
Scenario nominal : insérer des donnes dans le dataset les stocker dans le workflow
T ABLEAU 8:DESCRIPTION CAS D ’UTILISATION "MANIPULATION DES DATASETS "
- Description cas d’utilisation importer/exporter datadsets :
Titre : importer/exporter dataset
Objectif : ce cas d’utilisation permet de télécharger des datasets de la plate-forme et pour
travailler sans connexion et les charger ensuite
Acteurs : utilisateurs
Scenario nominal : télécharger des datasets de la plate-forme et les charger sur la
plateforme
T ABLEAU 9:DESCRIPTION CAS D ’UTILISATION "IMPORTER /EXPORTER DATADSETS "
25 | P a g e
- Description cas d’utilisation consulter les vues des datsets :
Titre : consulter des vues datsets
Objectif : ce cas d’utilisation permet de voir des datasets ou une partie des datsests sans
les modifier
Acteurs : utilisateur
Scenario nominale : avoir une vue sur les dataset sans pouvoir les modifier
T ABLEAU 10:DESCRIPTION CAS D ’ UTILISATION CONSULTER LES VUES DES DATSETS
2. Diagramme de séquences
Les diagrammes de séquences sont des diagrammes d’interactions qui permettent de

modéliser les scénarios. Ils ont pour objectif de mieux représenter les interactions entre les
objets du projet, selon un point de vue temporel.
26 | P a g e
2.1. Diagramme de séquence d’authentification
F IGURE 12 DIAGRAMME DE SEQUENCE D 'AUTHENTIFICATION
Description :
L’utilisateur est dirigé vers l’interface d’authentification, puit il saisit ses identifiant et il
clique sur le bouton de connexion, interface contrôle si le champs son remplient sinon elle
demande de ressaisir les identifiant, si oui le système vérifie si l’utilisateur existe dans la base
de données, si oui il est redirigé vers son espace de travail ,si non un message d’erreur s’affiche.
27 | P a g e
2.2. Diagramme de séquence de création des datasets
F IGURE 13 : DIAGRAMME DE SEQUENCE DE CREATION DES DATASETS
Description :
L’administrateur fait appel à l’interface de création des dataset, il saisit le nom de dataset
et confirme une vérification de l’existence de dataset est effectuée, puit il est redirigé vers
l’interface de création des attributs pour cette dataset, il ajoute les attributs nommer et typer
et confirme l’enregistrement puit la dataset est enregistrée dans la base de données.
28 | P a g e
2.3. Diagramme de séquence d’attribution des droits sur les datset
F IGURE 14: DIAGRAMME DE SEQUENCE ATTRIBUTION DES DROIT AU DATSET
Description :
L’administrateur demande la liste des datasat, il sélectionne la datasat affiche ces détails,
puis il clique sur la liste des utilisateurs, dans le menu détail il sélectionne les utilisateurs il leur
attribut les droits d’accès et clique sur confirmer, ensuite les la configuration et enregistrer sur
la base de données.
2.4. Diagramme de séquence de suppression d’un utilisateur
F IGURE 15: D IAGRAMME DE SEQUENCE DE SUPPRESSION D ’UN UTILISATEUR
29 | P a g e
Description :
L’administrateur demande la liste des utilisateurs, il sélectionne un utilisateur puit il clique

sur l’icône supprimer un pop-up de confirmation est affiché, il confirme la suppression, puit
l’utilisateur es supprimer.
2.5. Diagramme de séquence de messagerie
F IGURE 16: D IAGRAMME DE SEQUENCE DE MESSAGERIE
Description :
L’émetteur va sur l’interface de messageries il sélectionne les destinataires, puit i saisie
l’objet et le corps du message, et appuie sur envoyer le message sera enregistrer et une
notification de réception va s’afficher chez le récepteur.
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.
Alors que le diagramme de cas d'utilisation montre un système du point de vue des acteurs,
le diagramme de classes en montre la structure interne. Il permet de fournir une
représentation abstraite des objets du système qui vont interagir pour réaliser les cas
d'utilisation.
30 | P a g e
F IGURE 17:DIAGRAMME DE CLASSES DU SYSTEME
A partir de l’étude conceptuelle précédente des différents diagrammes de séquences système

de la solution, on a pu identifier pour chaque étape du processus métier global une classe qui
contient les attributs des champs à saisir, l’identification de ces classes est présentée comme
suit :
- Une classe « User » qui contient les informations des utilisateurs de la plate-forme
- Une classe « Rôle » qui gère les rôles attribuer aux utilisateurs
- Une classe « privilège » qui gère les types d’accès à la plate-forme
- Une classe « right » pour sécuriser l’accès à la plate-forme
- Une classe « dataset » qui permet la création et la gestion composée d’une ou plusieurs
attributs
- Une classe « attribut » qui contient les champs de l’attribut qui est composer de cellules
- Une énumération « datatype » de type de données pour les attributs
31 | P a g e
- Description de la classe user
Attribut Type Description

Id int Identifiant utilisateur
username String Nom utilisateur
email String Email de lutilisateur
password String Mot de passe de l’utilisateur
enabled Boolean Vérifier si le compte de
l’utilisateur est activé
tokenExpired Boolean Vérifier si le jeton d’accès est
valable
roles List<Role> Les roles que peut prendre
un utilisateur
T ABLEAU 11:DESCRIPTION DE LA CLASSE USER
- Description de la classe Rôle

Id int Identifiant du rôle
roleName String Nom du rôle
Privilèges List<privilège> Les privilèges attribuer à ce
rôle
Users List<user> Les utilisateurs qui ont ce
rôle
T ABLEAU 12: DESCRIPTION DE LA CLASSE ROLE
- Description de la classe privilège

Id int Identifiant du privilège
PrivilegeName String Nom du privilège
Roles Lise<rôle> Les rôles qui ont ce privilège
T ABLEAU 13: DESCRIPTION DE LA CLASSE PRIVILEGE
32 | P a g e
- Description de la classe dataset

Id int Identifiant du dataset
name String Nom du datset
Location String Emplacement du datset
Attributs List<attribut> Les attributs composant la
dataset
T ABLEAU 14:DESCRIPTION DE LA CLASSE DATASET
- Description de la classe attribut

Id int Identifiant du dataset
Name String Nom de l’attribut
datatype datatypeEnum Type de données de
l’attribut
Cells List<cell> Les cellules composant
l’attribut
T ABLEAU 15: DESCRIPTION DE LA CLASSE ATTRIBUT
- Description de la classe cell

value String Valeur de la cellule
datatype datatypeEnum Type de données de la
cellule
T ABLEAU 16: DESCRIPTION DE LA CLASSE CELL
33 | P a g e
Conclusion
Dans ce chapitre on s’est focalisé sur l’aspect fonctionnel et conceptuel du projet. D’abord
nous avons décrit la solution proposée, puis nous avons effectué une étude fonctionnelle avec
une vue d’ensemble des uses cases, ainsi nous avons présenté les diagrammes de séquence
pour chaque étape du processus et finalement nous avons présenté le diagramme de classe
de notre application.
34 | P a g e
Chapitre 3
Réalisation et implémentation
Ce chapitre abordera la réalisation et l’implémentation de la solution proposée. Les quatre

premières parties de ce chapitre entamera la réalisation de l’application, et la dernière partie
présentera son implémentation.
35 | P a g e
Introduction
Dans ce présent chapitre, nous présentons l’étude technique réalisée afin de se
préparer à l’implémentation du projet. L’environnement de développement mis en place est
présenté en quatre premières parties, suivies de la partie dédiée aux IHM de notre solution.
1. Architecture logiciel du système

L'architecture logicielle du système est une architecture 3-tiers. Il s'agit d'un modèle logique
d'architecture applicative ayant pour objectif la modélisation d’une application sous forme
d’un empilement de trois couches logicielles :
• La présentation des données : dite aussi « léger » du faite qu’elle est responsable de
l'affichage et le dialogue avec l'utilisateur ;
• Le traitement métier des données : correspondant à la mise en œuvre d’un ensemble
d’objets afin de donner une vision sur le modèle de stockage des données de l’application.
C’est au niveau de cette couche où se trouvent toutes les règles de gestion, et toute
l’intelligence de la démarche.
• L'accès aux données persistantes : correspondant aux données qui sont destinées à être
conservées sur la durée, voire de manière définitive.
La figure suivante illustre un exemple des différents niveaux d’une architecture trois tiers :
F IGURE 18:ARCHITECTURE 3- TIERS
36 | P a g e
2. Technologie et Framework
2.1. La technologie JEE

La plateforme Java Enterprise Edition est un ensemble de technologies coordonnées qui
permettent de réduire d’une manière très significative le coût et la complexité du
développement, du déploiement et de la gestion des applications multi-tiers.
Construite à la base de la plateforme Java Standard Edition (Java SE), Java EE ajoute des
fonctionnalités permettant d’avoir une plateforme Java complète, stable, sécurisée et rapide.
2.2. Design Pattern MVC et valeur ajoutée de MVC2

Une architecture MVC cherche à séparer trois choses : le Modèle, les Vues et les
contrôleurs. Les contrôleurs permettent de répondre aux actions de l'utilisateur. Chaque
contrôleur est associé à une vue : cette dernière permet de présenter l'information retournée
à l'utilisateur. Bien entendu, l'information renvoyée est dépendante des actions d'entrées de
l'utilisateur (capturées par les contrôleurs). Les liens (les traitements) sont réalisés par le
modèle (la logique métier).
Le modèle MVC2 est un peu « l’extension » de MVC. Ce nouveau modèle reprend les
concepts de base de MVC mais y ajoute une notion supplémentaire de façon à mieux séparer
les taches, et donc à rendre le code encore plus clair et maintenable.
La principale différence réside dans la couche « contrôleur ». Il n’y aura plus qu’un seul point
d’entrée dans le programme : Le contrôleur principal. Dans MVC 1, il fallait implémenter autant
de contrôleurs que nécessaire et que la requête fasse appel directement au bon contrôleur.
Dans MVC2, le point d’entrée ne servira plus à traiter directement la requête mais à déléguer
cette tâche à un autre contrôleur spécialisé.
37 | P a g e
La figure ci-dessous qui représente l’architecture du modèle MVC 2 :
F IGURE 19:ARCHITECTURE DU MODELE MVC2
2.3. Choix du Framework Spring boot

- Framework Spring boot
Les applications Java sont généralement composées d'un certain nombre d'objets qui
collaborent avec eux pour former la bonne application. Les objets dans une application
peuvent ainsi être considérés comme ayant des dépendances entre eux.
Le Framework Spring prend les meilleures pratiques qui ont fait leurs preuves au fil des ans
dans de nombreuses applications et formalisées comme des modèles de conception, et codifie
effectivement ces modèles comme des objets de première classe qu’un architecte ou
développeur peut emporter et intégrer dans sa propre application.
- Valeur ajouter de Spring boot
Spring Boot est un sous projet de Spring qui vise à rendre Spring plus facile d'utilisation en
élimant plusieurs étapes de configuration. L'objectif de Spring Boot est de permettre aux
développeurs de se concentrer sur des tâches techniques et non des tâches de configurations,
de déploiements, etc. Ce qui a pour conséquences un gain de temps et de productivité (avec
Spring Boot, il est très facile de démarrer un projet n-tiers).
38 | P a g e
Spring Boot apporte à Spring une très grande simplicité d'utilisation :
Il facilite notamment la création, la configuration et le déploiement d'une application

complète. On n'a plus besoin des fichiers XML à configurer (pas besoin du fichier du descripteur
de déploiement web.xml dans le cas d'une application web). Nous verrons plus bas comment
cela est possible.
Spring Boot permet de déployer très facilement une application dans plusieurs
environnements sans avoir à écrire des scripts. Pour ce faire, une simple indication de
l'environnement (développement ou production) dans le fichier de propriétés (.properties)
suffit à déployer l'application dans l'un ou l'autre environnement. Ceci est rendu possible grâce
à la notion de profil à déclarer toujours dans le fichier de propriétés. Je vous présenterai des
exemples de cas d'utilisation.
Spring Boot possède un serveur d'application Tomcat embarqué afin de faciliter le

déploiement d'une application web. Il est possible d'utiliser un serveur autre ou externe, grâce
à une simple déclaration dans le fichier pom.xml. 4. Spring Boot permet de mettre en place un
suivi métrique de l'application une fois déployée sur le serveur afin de suivre en temps réel
l'activité du serveur, ceci grâce à Spring-boot-starter.
- Architecture d’une application Spring boot

Une application Spring boot se compose principalement de :
• Fichiers HTML, JS et web pages pour toutes interactions avec l’utilisateur
• Les services REST qui représentent un style d'architecture pour développer des services
web. Une API qui respecte les principes REST est appelée API-RESTful. Les principes clés
de REST impliquent la séparation de l'API en ressources logiques. En effet, une
ressource est un objet ou une représentation d'objets contenant éventuellement des
données. La manipulation de ces ressources repose sur le protocole HTTP à travers les
méthodes d'actions GET, POST, PUT, DELETE.
• Les Services Métier et les DAO, pour la gestion des Transactions au niveau des Services
Métier (utilisation des Transaction Manager de Spring boot) et pour la configuration de
l’interface JPA et son implémentation Hibernate.
• SGBD utilisé pour garantir la persistance des données dans notre base de données.
39 | P a g e
• Le serveur Tomcat est un serveur Apache couplé avec un moteur web java, il permet
d’avoir la possibilité d’exécuter notre programme écrit en java.
La figure ci –dessous représente les interactions entre les différents éléments d’une application
Spring boot :
F IGURE 20:ARCHITECTURE D 'UNE APPLICATION SPRING BOOT
- Spring Security
Spring Security est l’un des modules de sécurité de Spring Framework.
Il s’agit d’une infrastructure de sécurité Java SE / Java EE qui fournit une authentification, une
autorisation, une authentification unique et d’autres fonctionnalités de sécurité pour les
applications Web ou les applications d’entreprise. On peut aussi s’authentifier avec Spring
Security en utilisant un jeton
40 | P a g e
- Valeur ajoutée de Spring Security
Spring Security fournit une solution complète en matière de sécurité pour les applications Java
JEE. Ce module permet de configurer toute la sécurité sur l’ensemble d’un système sans être
dépendant de l’environnement.
La figure ci –dessous représente l’architecture de la configuration de Spring Security :
F IGURE 21:ARCHITECTURE DE SPRING SECURITY
WebSecurityConfigurerAdapter est le nœud de notre implémentation de sécurité. Il fournit

des configurations HttpSecurity pour configurer les cors, csrf, la gestion de session, les règles
pour les ressources protégées. Nous pouvons également étendre et personnaliser la
configuration par défaut qui contient les éléments ci-dessous.
- L'interface UserDetailsService a une méthode pour charger l'utilisateur par nom
d'utilisateur et renvoie un objet UserDetails que Spring Security peut utiliser pour
l'authentification et la validation.
- UserDetails contient les informations nécessaires (telles que : nom d'utilisateur, mot de
passe, autorités) pour créer un objet d'authentification.
41 | P a g e
- UsernamePasswordAuthenticationToken obtient {nom d'utilisateur, mot de passe} de la
demande de connexion, AuthenticationManager l'utilisera pour authentifier un compte.
- AuthenticationManager a un DaoAuthenticationProvider (avec l'aide de
UserDetailsService & PasswordEncoder) pour valider l'objet
UsernamePasswordAuthenticationToken. En cas de succès, AuthenticationManager renvoie
un objet d'authentification entièrement rempli (y compris les autorisations accordées).
- OncePerRequestFilter effectue une seule exécution pour chaque demande à notre API. Il
fournit une méthode doFilterInternal () que nous implémenterons en analysant et validant
JWT, en chargeant les détails de l'utilisateur (en utilisant UserDetailsService), en vérifiant
Authorizaion (en utilisant UsernamePasswordAuthenticationToken).
- AuthenticationEntryPoint intercepte une erreur non autorisée et renvoie un 401 lorsque
les clients accèdent aux ressources protégées sans authentification.
Le référentiel contient UserRepository & RoleRepository pour fonctionner avec la base de
données, sera importé dans Controller.
2.4. Json Web Token (JWT)

Définition
JSON Web Token (JWT) est un standard ouvert défini dans la RFC 7519. Il permet l'échange
sécurisé de jetons (tokens) entre plusieurs parties. Cette sécurité de l’échange se traduit par la
vérification de l’intégrité des données à l’aide d’une signature numérique. Elle s’effectue par
l'algorithme HMAC ou RSA.
Valeur ajouter du jwt

Le grand avantage de JWT (Token-based Authentication) est que nous stockons le jeton
côté client : stockage local pour navigateur, trousseau pour IOS et SharedPreferences pour
Android… Nous n'avons donc pas besoin de construire un autre projet backend qui prend en
charge les applications natives ou un module d'authentification supplémentaire pour les
utilisateurs d'applications natives.
Il y a trois parties importantes d'un JWT: en-tête, charge utile, signature. Ensemble, ils sont
combinés à une structure standard : header.payload.signature.
Fonctionnement du jwt
42 | P a g e
F IGURE 22:EXPLICATION DU FONCTIONNEMENT DE J WT
Le client envoie ces identifiant au serveur, le serveur crée un jeton avec un clé secrète et
l’envoie au client, le client envoie une requête d’authentification avec le jeton en entête, le
serveur valide le jeton et accepte l’authentification.
43 | P a g e
La figure ci-dessus explique le fonctionnement en détail de l’authentification avec jwt cote
client :
F IGURE 23:DETAIL DE FONCTIONNEMENT D JWT COTE CLIENT
Le composant App est un conteneur utilisant un routeur. Il obtient le jeton utilisateur et les
informations utilisateur du stockage de session du navigateur via token-storage.service. La
barre de navigation peut alors s'afficher en fonction de l'état et des rôles de connexion de
l'utilisateur.
Les composants de connexion et d'enregistrement ont un formulaire pour les données de
soumission (avec prise en charge de la validation de formulaire). Ils utilisent token-
storage.service pour vérifier l'état et auth.service pour envoyer des demandes de connexion /
inscription.
auth.service utilise Angular HttpClient (service $ http) pour effectuer des demandes
d'authentification.
Chaque requête HTTP par le service $ http sera inspectée et transformée avant d'être
envoyée par auth-interceptor.
La composante d'accueil est publique pour tous les visiteurs.
Le composant de profil obtient les données utilisateur du stockage de session.
Les composants BoardUser, BoardModerator, BoardAdmin seront affichés en fonction des
rôles du stockage de session. Dans ces composants, nous utilisons user.service pour obtenir
des ressources protégées de l'API.
44 | P a g e
2.5. Choix de la Framework Hibernate
Le tableau suivant illustre la comparaison entre les Framework libre de mapping objet
relationnel :
Produit Castor OJB Hibernate

Version/Date 0.9.5.3 1.0 3.0
Documenté Moyen Bien Très Bien

GUI Oui Oui Oui
Support EJB Non Oui Oui
Héritage/Polymorphisme Non Oui Oui
API de Requêtes Non Oui Oui
Système de cache Oui Oui Oui
F IGURE 24: E TUDE COMPARATIVE DES F RAMEWORK DE MAPPING OBJET RELATIONNEL
D’après cette étude, nous remarquons que Hibernate et OJB sont les mieux placés. Nous
préférons travailler avec Hibernate puisqu’il est le mieux documenté en plus de sa stabilité et
maturité. En effet nous remarquons que Hibernate est dans sa version 3.0 alors qu’OJB est
encore dans sa version 1.0.
2.6. Choix de SQL server
• Permet de transformer des données complexes : Créez de puissants modèles de

données qui peuvent facilement être compris et analysés.
• Moderniser les rapports : Créer des rapports Power BI, des KPI et des rapports paginés
entièrement interactifs depuis un portail Web moderne unique, avec la possibilité de
pouvoir y accéder par un appareil mobile
• Utilise une solution de veille stratégique hybride : Connectez-vous à vos données sur
place à partir du nuage. Aucun déplacement des données n’est nécessaire.
• Utilise une plate-forme de veille stratégique éprouvée : Tirez avantage de l’évolutivité,
de l’accès à des données sécurisées et d’outils familiers.
45 | P a g e
2.7. Choix de maven
Maven est un outil open-source très populaire de build pour les projets Java, conçu pour
supprimer les tâches difficiles du processus de build. Maven utilise une approche déclarative,
où le contenu et la structure du projet sont décrits, plutôt qu'une approche par tâche utilisée
par exemple par Ant ou les fichiers make traditionnels. Cela aide à mettre en place des
standards de développements au niveau d'une société et réduit le temps nécessaire pour
écrire et maintenir les scripts de build.
Chaque projet ou sous-projet est configuré par un POM qui contient les informations
nécessaires à Maven pour traiter le projet (nom du projet, numéro de version, dépendances
vers d'autres projets, bibliothèques nécessaires à la compilation, noms des contributeurs etc.).
Ce POM se matérialise par un fichier pom.xml à la racine du projet.
2.8. Javascript
JavaScript est un langage de programmation de scripts principalement employé dans les
pages web interactives mais aussi pour les serveurs avec l'utilisation (par exemple) de Node.js.
C'est un langage orienté objet à prototype, c'est-à-dire que les bases du langage et ses
principales interfaces sont fournies par des objets qui ne sont pas des instances de classes,
mais qui sont chacun équipés de constructeurs permettant de créer leurs propriétés, et
notamment une propriété de prototypage qui permet de créer des objets héritiers
personnalisés. En outre, les fonctions sont des objets de première classe. Le langage supporte
le paradigme objet, impératif et fonctionnel.
2.9. Framework Angular
Angular est un Framework de développement Web, open-source, développé et géré par

Google. Ce Framework a été mis en place pour répondre à la plupart des défis rencontrés dans
le développement des applications Web à une seule page.
A cet égard, l’Angular est devenu largement utilisé dans le développement des applications
à une seule page extrêmement robustes et adaptables. La structure SPA est composée en
JavaScript et permet d’utiliser le langage HTML en tant que langage modèle. Il assemble des
applications Web riches et naturelles et offre en outre aux développeurs Web le choix de
développer des applications côté client. En offrant une panoplie d’éléments, Angular
46 | P a g e
Framework a acquis une admiration extraordinaire pour lui-même, ce qui l’a rendu très
populaire parmi les services de développement d’applications Web.
2.10. Choix de Angular

Voici les principales raisons sur lesquelles on s’est basé pour choisir angular :
Haute performance
Robustesse, facilité d’utilisation et de maintenance, fonctionnalités spontanées et

compétences pour construire de nouvelles fonctionnalités sont peu de choses qui font
d’Angular le meilleur choix parmi les développeurs web. Il est alimenté par des fonctionnalités
comme la liaison de données, les filtres, les animations, la gestion d’étendues, le client API, les
directives, le routage, la désinfection du contenu, la validation des formulaires et bien d’autres
choses encore. De toute évidence, quand un problème se pose, les développeurs ne sont pas
prêts à investir des heures d’enquête. En attendant, ils devraient avoir la capacité de déployer
des améliorations mineures sans lever le petit doigt.
Lors de la sélection d’un framework, l’un des composants clés pris en compte par les
concepteurs de sites Web est le fait que, lorsqu’ils doivent créer un nouvel élément ou inclure
un élément, le système l’aide ou le gâche. Avec Angular, vous pouvez être complètement
assuré que vous auriez la productivité de faire de nouveaux éléments, avec le cadre donnant
une aide complète sur chaque étape. En attendant, lorsque le groupe communautaire devient
solide et substantiel, il peut par conséquent vaincre quelques problèmes à l’intérieur du cadre.
Il fabrique des bibliothèques mutuelles qui travaillent avec le cadre et le rendent d’autant plus
intense et instinctif.
DOM a un balisage dans Angular
Le système évalue le balisage juste au moment où le code HTML a été empilé dans DOM.
La simplicité, la compréhension des applications existantes et l’extensibilité sont trois

avantages importants. Vous pouvez travailler avec Angular dans un rapport HTML fondamental
à partir d’un framework d’enregistrement de voisinage. En outre, il vous permet de construire
47 | P a g e
des attributs personnalisés et des éléments qui peuvent développer le vocabulaire HTML
fondamental.
Complet
Le meilleur aspect concernant Angular est que c’est une réponse complète pour un
développement frontal cohérent. Les développeurs n’ont pas besoin de s’embarrasser de
n’importe quelle autre structure ou module, et peuvent sans effort créer des applications web
pilotées par les données utilisant ce framework JavaScript. Les activités REST vous permettent
de converser rapidement avec vos clients à partir du serveur et d’obtenir les informations
vraiment nécessaires pour vous connecter aux pages Web. Avec Angular, cette fonctionnalité
se transforme en objets JavaScript simples et instinctifs, en suivant la conception MVVM
(Model-View -View Model). Avec ce système, il devient sensiblement facile de structurer le
code source en suivant les fonctionnalités MVVM ou Model-View-Controller.
Un autre composant important d’Angular est qu’il peut développer HTML et le travailler
comme XML. Cela donne divers résultats imaginables pour les attributs et les étiquettes. De
plus, avec cette dépendance et cette liaison de données, chaque composant de l’exemple
MVVM peut être transmis naturellement sur l’interface utilisateur. Cela limite les exigences
pour les getters / setters, les wrappers et les déclarations de classe. De cette manière, Angular
vous donne une chance d’exprimer vos données aussi efficacement avec des primitives
JavaScript, ou comme ahurissant au moyen de types personnalisés.
Gestion des dépendances
Angular rend très simple l’organisation de choses comme les dépendances et le chargement
dynamique, et les utilise au besoin sans se soucier de l’instance et de l’espace de noms. Vous
avez juste à le nommer et l’Angular sera exact pour vous, il prend également soin du cycle de
vie complet des objets. Ainsi gère les dépendances d’une manière exceptionnelle.
Pour tester, le Framework vous permet d’isoler l’application en modules cohérents qui peuvent
avoir des conditions les uns sur les autres, mais qui sont indépendamment installés. Cela
adopte une stratégie stratégique de test car elle ne donne que les modules dont vous avez
besoin. Actuellement, puisque les conditions sont injectées, vous pouvez avoir une supervision
48 | P a g e
courante comme Angular $ HTTP et l’échanger sans effort avec $ httpBackend mépris pour un
test réussi.
2.11. Choix de git
- Permet la modularisation : Git permet une modularisation aisée de son projet. Que
vous soyez sur un projet de petite, moyenne ou grande taille, le besoin est sans cesse
présent de développer des fonctionnalités en parallèle. Git permet à l’aide des
branches de facilement atteindre vos fins.
- Permet d’annuler vos erreurs : dans votre éditeur de code, vous avez l’habitude
d’annuler vos modifications (CTRL+Z, CTRL+Y, …). Mais dès que vous fermez l’éditeur,
impossible d’annuler ce que vous venez à peine de modifier. Git apporte une solution
avec les commits avec la possibilité de passer d’un commit à un autre.
- Permet de travailler en mode déconnecté : nous n’avons pas internet à tout moment.
Nous ne sommes pas au boulot tout le temps. Mais quand on utilise Git, puisqu’on a
tout le code sur notre poste de travail, on peut continuer le développement partout où
on sera.
- Permet d’éviter des pertes de données : si vous travaillez à plusieurs sur un projet,
concilier vos modifications –quand on n’utilise pas un outil moderne– est très critique.
Il est difficile à vue d’œil d’identifier les modifications apportées par un collaborateur,
de comparer deux fichiers, ou de faire l’intégration de ces modifications. Avec Git, vous
identifiez clairement les modifications des autres collaborateurs, ce qu’ils ont ajouté ou
retranché, et pourquoi ils l’ont fait. Et lorsqu’ultérieurement une modification devient
critique, vous pouvez repartir en arrière sur une version préalable du fichier grâce à
l’historique des modifications.
49 | P a g e
3. Structure du projet
Dans cette partie nous représentons la structure de notre projet qui décrit les différents
modules en phase de développement.
La figure ci- dessous explique l’architecture du projet entier full-stack :
F IGURE 25:ARCHITECTURE FULL -S TACK ANGULAR SPRING BOOT
- Spring Boot exporte REST Apis à l'aide de Spring Web MVC et interagit avec la base de
données SQL Server à l'aide de Spring Data SQL Server
- Le client angulaire envoie des requêtes HTTP et récupère les réponses HTTP, affiche les
données sur les composants. Nous utilisons également le routeur angulaire pour naviguer vers
les pages.
50 | P a g e
Structure du projet Spring boot :
F IGURE 26:STRUCTUR DU PROJET SPRING B OOT
La structure du projet est la suivante :

• Dossier src/main/java qui contient nos principaux packages, chacun contient : notre
application main, les contrôleurs qui gère l’acheminement des requetés http , les entités de
base , les repositories coté persistance JPA , les services REST et les classes qui implémentes
les services Rest, la configuration de Spring Security et la configuration de JWT
• Dossier de classes de tests JUnit
51 | P a g e
•Dossier des fichiers CSS, JavaScript et les templates HTML
• Fichier application.properties qui contient les règles de gestion de base de données et du
Framework Spring boot
• Ficher pom.xml qui contient les dépendances utilisées pour le développement du projet
Structure du projet Angular
F IGURE 27:STRUCTURE D 'UN PROJET ANGULAR
La structure du projet est la suivant :
• Le répertoire e2e(end to end): contient les fichiers de configuration du projet
52 | P a g e
• Le répertoire node_module : contient les dépendances externe du projet (librairie
javascript,css,…)
• Le répertoire src : contient le code source relatif au projet
- Le répertoire app : contient la logique applicative du projet à savoir le package
core/module qui contient l’ensemble des modules importer de angular material, le
package Framework qui contient les services et model des entités de notre application
et la configuration de l’authentification par JWT, et le package views qui contient les
composantes de la page web de l’application
- Le répertoire assets contient les fichiers media que nous avons utiliser pour
l’application
- Le répertoire environments : contient les variables d’environnement (globale) du projet
4. Description des IHMs
4.1. Interface d’authentification

Dans le but de l’organisation et la sécurisation de l’accès à l’application, vu qu’elle n’est pas
ouverte en totalité qu’à un nombre restreint de personnes et pour un souci de traçabilité, une
authentification se voit nécessaire.
F IGURE 28: INTERFACE D 'AUTHENTIFICATION
53 | P a g e
Pour accéder à l’application, l’utilisateur doit tout d’abord s’authentifier en saisissant son
nom d’utilisateur et son mot de passe annuaire. L’application vérifie si les informations saisies
sont erronées ou vraies et réachemine l’utilisateur vers l’espace adapté.
4.2. Interface d’inscription

Pour les nouveaux utilisateurs de la plate-forme ils doivent impérativement via une
interface d’inscription
F IGURE 29:INTERFACE D 'INSCRIPTION
L’utilisateur doit insérer ces identifiant pour la plate-forme en plus de son email puit il va
recevoir un email pour activer sa session.
4.3. Espaces d’accueil pour administrateur

Après une authentification réussite l’administrateur est réacheminé vers la page d’accueil
administrateur
54 | P a g e
F IGURE 30: ESPACE D 'ACCUEIL ADMIN
Le menu à gauche représente les fonctionnalités attribuées à l’administrateur de la plate-

forme à savoir consulter son profile gérer les utilisateurs, les datasets et les workflows et le
service de messagerie
4.4. Espace d’accueil pour utilisateur normal

Après une authentification réussite l’utilisateur est réacheminé vers la page d’accueil
utilisateur
F IGURE 31:ESPACE D 'ACCUEIL UTILISATEUR
55 | P a g e
Le menu à gauche représente les fonctionnalités attribuées à l’utilisateur de la plate-forme
à savoir consulter son profile gérer la liste des datasets à laquelle il a droit, importer des dataset
dans la liste, accéder aux datasets pour les manipuler et le service de messagerie
4.5. Interface de création des datsets
F IGURE 32:INTERFACE DE CREATION DATSET
L’administrateur doit donner un nom au dataset puit il peut ajouter autant d’attributs qu’il
veut à l’aide du bouton add (icone plus en vert) ensuit il doit les nommer et les typer puit il
appuie sur le bouton save(icone disquette noir) et la dataset sera créer .
56 | P a g e
4.6. Interface d’attribution des droits aux utilisateur
F IGURE 33:INTERFACE D 'ATTRIBUTION DES DROITS
L’administrateur doit entrer dans le workflow spécifier et appuyer sur ajouter utilisateurs
Il aura une interface avec deux colonnes une de tous les utilisateurs et l’autre pour les
utilisateurs invités pour ajouter un utilisateur aux invités soit il sélectionne l’utilisateur et
appuie sur la flèche orientée vers la droite au milieu de la page soit il utilise la fonctionnalité
de « drag and drope » lorsqu’il a fini il doit appuyer sur done pour enregistrer les modifications
4.7. Interface de messagerie
F IGURE 34:INTERFACE DE MESSAGERIE
57 | P a g e
Cette interface permet aux différents utilisateurs de communiquer entre eux, l’utilisateur
doit entre les usernames des destinataires puit écrire son message enfin il appuie sur send
pour envoyer le message.
4.8. Interface manipulation des dataset
F IGURE 35:INTERFACE DE MANIPULATION DE DATASET
L’utilisateur accède au dataset ou il va opérer un tableau va s’afficher ou il va insérer les

données pour ajouter une ligne il doit appuyer sur add (bouton en plus en vert) pour
supprimer une ligne il doit appuyer sur remouve en rouge les cellules du tableau sont
éditable pour télécharger le tableau il doit appuyer sur le bouton excel.
Conclusion
Dans ce chapitre nous avons vu les différentes technologies utiliser pour réaliser ce projet, les
phases de sa réalisation, sa structure et les interfaces qui permettent à l’utilisateur d’interagir
facilement avec la plate-forme
58 | P a g e
Conclusion générale
Mon projet de fin d’études, effectué au sein de la société Mercure IT et précisément au
sein de l’équipe développement Java, consiste à la mise en place d’une solution de
centralisation de données en faisant l’étude, l’analyse, la conception et la réalisation de cette
application web.
Les objectifs majeurs de notre solution sont : permettre de sécuriser les données et assurer
leurs disponibilités à tout moment, pour les exploiter dans des projets BI, et aussi donner la
possibilité aux utilisateurs de collaborer entre eux et même de travailler hors ligne.
En guise de perspective pour notre solution, nous proposons d’y ajouter un mécanisme de
règle de gestion pour les datasets, cela va permettre à l’administrateur d’être plus précis sur
les contraintes des dataset, ce qui engendrera une réduction des erreurs lors de l’insertion des
données par l’utilisateur de la plate-forme. On va rajouter des fonctionnalités qui seront utile
pour l’utilisateur lors de son travail sur la plate-forme comme les options de filtrer les datasets,
et faire de calcules arithmétique.
59 | P a g e
Bibliographies
Become a ninja with Angular
Java Design patterns
Hibernate 3.0 Gestion optimale de la persistance dans les applications Java/J2EE, Anthony
PATRICIO
Spring In Action, New York, Manning Publications Co., 2011,426, Craig Walls
60 | P a g e
Webographies
Why Learn the Spring Framework?
https://springframework.guru/learn-spring/
Angular 7 + Spring Boot JWT Authentication Example
https://www.javainuse.com/spring/ang7-jwt
Spring Boot Security Auto-Configuration
https://www.baeldung.com/spring-boot-security-autoconfiguration
Spring boot
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/
angular spring boot Jwt
https://bezkoder.com/angular-spring-boot-jwt-auth/
Cours Spring boot M YOUSSFI
https://fr.slideshare.net/mohamedyoussfi9/mohamed-youssfi-support-architectures-
logicielles-distribues-bases-sue-les-micro-services-avec-spring-boot
Sécurité des Applications Web avec Json Web Token (JWT)
https://fr.slideshare.net/mohamedyoussfi9/scurit-des-applications-web-avec-json-web-
token-jwt
Model View Controller
https://sites.google.com/site/floriangrisoni/informatique/design-pattern-mvc
Java Entreprise Edition
http://www.jmdoudoux.fr/java/dej/chap-j2ee-javaee.htm#j2ee-javaee-1
Angular tutorial
https://angular.io/tutorial
61 | P a g e
Annexes
Annexe A : Organisation du projet

Annexe B : Technologies et outils utilisé
62 | P a g e
Annexe A : organisation du projet
1. Rôles et responsabilité
L’organisation du projet est la suivante :
• Cote MercureIT :
Responsable Rôle
M MOUSGHI Redouan Encadrant externe
• Cote AIAC :
Responsable Rôle
M HAIN Mustapha Tuteur
2. Organisation de réunion
Chaque réunion sera verbalisée par un compte rendu synthétisant l’état d’avancement du
projet et tous les points et décisions prises. Ce compte rendu sera envoyé à l’encadrant du
projet et les membres d’équipe projet.
Les réunions seront effectuées vers la fin de chaque phase du développement.

Objectifs :
• Définir les objectifs à réaliser pour la prochaine phase.
• Procéder à l’évaluation de l’état d’avancement pour chacune des ressources ainsi que
le niveau de réalisation des objectifs prédéfinis.
• Identifier les problèmes rencontrés et apporter les solutions qui s’imposent.
• Assurer la coordination des différentes structures et le suivi opérationnel du projet.
• Réajuster la planification en cas de nécessité.
3. Démarche de développement
Chaque attente du client peut être atteinte indépendamment des autres. L'utilisation d'un
cycle de vie permettant de développer chacun des modules de bout en bout séparément est
donc appropriée. Le produit final sera donc livré par lots successifs. Pour cette raison on a
adopté la méthode SCRUM de gestion de projet.
63 | P a g e
Le schéma ci-dessous représente une vue synthétique du processus SCRUM du projet
Description des étapes de chaque Sprint :

• Etude du besoin : Dans cette étape, on analyse les expressions des besoins et on en déduit
la problématique puis on choisit le cycle de vie à adopter, on définit le planning et on fait des
préparatifs des technologies qu’on aura besoin.
• Définir les fonctionnalités (Product Backlog) : Cette étape permet de définir précisément
l’ensemble des fonctionnalités, d'étudier l'interface homme-machine du système, de se former
aux outils utilisés.
• Modéliser : Cette étape permet de modéliser la problématique, de définir l'architecture

interne de l’application, d'acquérir et d'installer les outils de programmation.
• Développer : Cette étape consiste à coder les objets créés dans la partie modélisation.
• Tester : cette phase permet à l’aide des plans de tests, de tester le produit développé dans
l’ordre suivant : tests techniques et les tests fonctionnels.
64 | P a g e
Annexe B : technologies et outils utilisés
1. Technologie
1.1. Spring boot
Spring Boot est un framework qui facilite le développement d'applications fondées sur
Spring en offrant des outils permettant d'obtenir une application packagée en jar,
totalement autonome. L’utilité majeure du framework est de rassurer une auto-
configuration, cette fonctionnalité est la plus importante de Spring Boot. Elle permet
de configurer automatiquement votre application à partir des jars trouvés dans votre
Classpath. En d'autres termes, en important des dépendances, Spring Boot va consulter
cette liste puis produira la configuration nécessaire pour que tout fonctionne
correctement. Ainsi, la deuxième utilité majeure du Spring boot est les starters qui
viennent compléter l'auto-configuration et font gagner énormément de temps,
notamment lorsqu'on commence le développement d'un Microservice. Un starter va
apporter à votre projet un ensemble de dépendances, communément utilisées pour
un type de projet donné.
L'autre énorme avantage est la gestion des versions. Plus besoin de chercher quelles
versions sont compatibles puis de les ajouter une à une dans le pom.xml ! Il vous suffit
d'ajouter une simple dépendance au starter de votre choix. Cette dépendance va alors
ajouter, à son tour, les éléments dont elle dépend, avec les bonnes versions.
65 | P a g e
1.2. Hibernate
Hibernate est un Framework open source gérant la sauvegarde et la restauration des objets de
la base de données. C'est-à-dire qu'il consiste en un programme capable de se terminer sans
que ses données et son état d'exécution ne soient perdus.
Il est adaptable en terme d'architecture, il peut donc être utilisé aussi bien dans un
développement client lourd, que dans un environnement web léger de type Apache Tomcat
ou dans un environnement J2EE complet : WebSphere, JBoss Application Server et Oracle
WebLogic Server.
Hibernate apporte, en plus, une solution aux problèmes d'adaptation entre le paradigme objet
et les SGBD en remplaçant les accès à la base de données par des appels à des méthodes objet
de haut niveau.
Hibernate est un outil ORM (Object Relational Mapping) qui est une technique de
programmation qui mappe l'objet aux données stockées dans la base de données. De plus,
Hibernate implémente les spécifications de JPA (Java Persistence API) pour la persistance des
données, cette spécification Java fournit certaines fonctionnalités et standard aux outils ORM.
Le package javax.persistence contient les classes et les interfaces JPA.
66 | P a g e
1.3. Spring Security
Spring Security est un Framework de sécurité léger qui fournit une authentification 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.
1.4. Angular
Angular (communément appelé "Angular 2+" ou "Angular v2 et plus") est un Framework côté
client, open source, basé sur TypeScript, et co-dirigé par l'équipe du projet « Angular » à
Google et par une communauté de particuliers et de sociétés. Angular est une réécriture
complète de AngularJS, cadriciel construit par la même équipe.
67 | P a g e
2. Outils
2.1. Git
Git est un logiciel de gestion de versions décentralisé. C'est un logiciel libre créé par Linus
Torvalds, auteur du noyau Linux, et distribué selon les termes de la licence publique générale
GNU version 2. En 2016, il s’agit du logiciel de gestion de versions le plus populaire qui est
utilisé par plus de douze millions de personnes.
2.2. Apache Maven

Apache Maven est un outil de gestion et de compréhension de projets logiciels. Basé sur le
concept de modèle d'objet de projet (POM), Maven peut gérer la construction, les rapports
et la documentation d'un projet à partir d'une information centrale.
L'objectif recherché est de produire un logiciel à partir de ses sources, en optimisant les
tâches réalisées à cette fin et en garantissant le bon ordre de fabrication.
68 | P a g e

Mémoire de Projet de Fin D'étude Diplôme D'ingénieur D'état Génie Informatique MOKRINI Yassir

Transféré par

Droits d'auteur :

Formats disponibles

Mémoire de Projet de Fin D'étude Diplôme D'ingénieur D'état Génie Informatique MOKRINI Yassir

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mémoire de Projet de Fin D'étude Diplôme D'ingénieur D'état Génie Informatique MOKRINI Yassir

Transféré par

Droits d'auteur :

Formats disponibles

Académie Internationale Mohammed VI de l’Aviation civile

Mémoire de projet de fin d’étude

Diplôme d’ingénieur d’état

Mise en place d’une solution de centralisation des

➢ M HAIN Mustapha Tuteur interne

Vous avez tout fait pour mon bonheur et ma réussite.

Mon frère et ma sœur :

Mes camarades de classe GI 13 et 14 :

A mes chers professeurs :

Il était question, lors de ce projet, de concevoir et développer une plateforme de

Mots-clés: BI, UML,Scrum,Drow.io,SqlServer,Spring,Angular

key words: BI,UML,Scrum,Drow.io,SqlServer,Spring,Angular

‫‪key words: BI,UML,Scrum,Drow.io,SqlServer,Spring,Angular‬‬

Contexte général du projet

Nous commençons ce chapitre par une description de l’organisme

1. Présentation de l’organisme d’accueil

1.2. Les activités de l’entreprise

La société aujourd’hui offre des différents services complets :

La connaissance du marché, les compétences de ces collaborateurs, le partage de valeurs

L’entreprise s’organise de la manière suivante :

F IGURE 1 : ORGANIGRAMME DE L ’ENTREPRISE

Parmi ces principales clientes on peut citer :

Banque marocaine pour le commerce et l'industrie

Union Marocaine de Banques

Société générale Maroc

L’informatique décisionnelle est l'informatique à l'usage des décideurs et des dirigeants

F IGURE 2 : SCHEMA D ’UN SYSTEME BI

F IGURE 3: MISE EN PLACE DE SOLUTION

Au sein de l’entreprise la méthodologie du travail appliqué c’est la méthode agile

La méthodologie Agile se base sur des cycles de développements courts et des

Les méthodes de développement Agile correspondent efficacement à l’approche de

La méthode Agile recommande parmi ses nombreux principes :

- Parvenir à la satisfaction du client par le biais d’un cycle rapide, récurrent et

- Se montrer apte à prendre en compte les changements de dernière minute à tout

- Mettre en place une coopération quotidienne entre développeurs et chefs de projet

- Motiver les développeurs par un environnement, un soutien et une confiance toujours

- Faire simple, mais pas simpliste.

- Laisser l’équipe s’organiser au mieux de ses possibilités.

Ces principes sont résumés en quatre points :

- Le logiciel qui fonctionne plutôt que la documentation complète.

- La coopération avec le client plutôt que la négociation du contrat.

- Répondre au changement plutôt que suivre un plan.

Ainsi, les méthodes agiles promeuvent de nouvelles méthodes de développement basées

Agile, ainsi que leur usage en fonction de la taille du projet :

F IGURE 4:METHODES AGILES EN FONCTION DE LA TAILLE DU PROJET

3.1. Présentation SCRUM :

F IGURE 6: T ACHES DU PRODUCT OWNER

Le Scrum Master, ou couramment appelé « Chef de Projet », a pour responsabilité de

- Qui a fait quoi la veille ?

- Qui fera quoi ce jour-ci ?

- Obstacles rencontrés, ou possibles ;

- Modification de la planification, évènements imprévus.

Les éléments figurent dans le back log suivant :

F IGURE 7: SCRUME BACKLOG

La constitution du backlog scrum commence par la matérialisation et la définition des

F IGURE 8: SPRINTS DU PROJET

4.1. Planification du projet :

4.2. Diagramme de Gantt

Le déroulement du stage est comme suit :