République Tunisienne Licence en : fondamentale en

Ministère de l’Enseignement Supérieur informatique multimédia

et de la Recherche Scientifique

Option :
Université de Sfax Analyse de donnés
(Big Data)
École supérieur d’informatique
et de multimédia de Sfax

Rapport du projet de fin d’année

présenté à

L’École supérieur d’informatique et de

multimédia de Sfax
Option :
Analyse des donnés
(Big Data)

Réalisé par:

Dammak Yessine

Conception et Réalisation d’un Référentiel de Gestion des

Données Collaborateurs

Encadrant Entreprise:

Ellouze Haitham

Orange Restricted
 Rémerciment
Avant de présenter mon projet, nous dédions d’abord ce travail à toute personne qui a
investi ne serait-ce que quelques moments pour me supporter au cours de cette aventure dont
nous sommes très fiers.

Nous tenons à remercier de tout cœur Mr Haithem Ellouze pour son professionnalisme,
dévouement et support continu qui m’a permis de livrer un projet de qualité et d’apprendre le
vrai savoir-faire du métier.
 Sommaire
Introduction Générale......................................................................................................1
Chapitre 1 : Cadre général...............................................................................................2
Introduction........................................................................................................2
1.1 Présentation de l’entreprise..................................................................2
1.1.1 Sofrecom Tunisie.....................................................................2
1.1.2 Domaines d’activités de Sofrecom Tunisie.............................3
1.1.3 Charte Organisationnelle de Sofrecom Tunisie.......................3
1.2 Contexte du projet.................................................................................4
1.3 Introduction du sujet.............................................................................4
1.3.1 Problématique..........................................................................4
1.4 Méthodologie de travail.........................................................................5
1.4.1 Choix de la méthodologie Agile..............................................5
1.4.2 Scrum..................................................................................61.5
..........................................................................Plan de travail
.................................................................................................7
Conclusion...........................................................................................................7
Chapitre 2 : Sprint 0 : Analyse et Conception...............................................................8
Introduction........................................................................................................8
2.1 Analyse des besoins................................................................................8
2.1.1 Identification des acteurs.........................................................8
2.1.2 Besoins fonctionnels................................................................8
2.1.3 Besoins non fonctionnels.........................................................9
2.1.4 Diagramme de cas d’utilisation global....................................9
2.2 Conception : Diagramme de classe....................................................10
2.3 Planification des sprints......................................................................11
2.4 Architecture de l’application..............................................................12
2.4.1 Architecture physique............................................................12
2.4.2 Architecture logicielle...........................................................13
2.5 Environnement de travail...................................................................14
2.5.1 Environnement matériel.........................................................14
2.5.2 Environnement logiciel..........................................................14
 2.5.3 Environnement de développement........................................16
Conclusion.........................................................................................................16
Chapitre 3 : Sprint 1: Authentification et Accès..........................................................17
Introduction......................................................................................................17
3.1 Prérequis...............................................................................................17
3.1.1 Json Web Token....................................................................17
3.1.2 Contrôle d'accès basé sur les rôles.........................................18
3.2 Spécifications fonctionnelles...............................................................19
3.3 Sprint Planning....................................................................................20
3.3.1 Sprint Backlog.......................................................................20
3.3.2 Sprint 1 Goal: Contrôle d'accès basé sur les rôles.................20
3.4 Sprint Revue.........................................................................................21
3.4.1 Réalisation...................................................................21,22,23
3.4.2 Tests du Sprint 1....................................................................24
3.5 Sprint Rétrospective............................................................................24
Conclusion.........................................................................................................24
Bibliographie...................................................................................................................25

Figures
Figure 1. Sofrecom à l'international............................................................................................2
Figure 2. Structure de Sofrecom Tunisie....................................................................................3
Figure 3. Organigramme Managérial..........................................................................................4
Figure 6. Méthodes de gestion de projet.....................................................................................5
Figure 7. Framework Scrum.......................................................................................................6
Figure 8. Planification du projet par Sprints...............................................................................7
Figure 9. Diagramme de cas d’utilisation global........................................................................9
Figure 10. Diagramme de classe...............................................................................................10
Figure 11. Architecture n-tiers..................................................................................................13
Figure 12. Architecture multicouche........................................................................................13
Figure 13. Architecture en composants.....................................................................................13
Figure 14. Logo draw.io............................................................................................................14
Figure 15. Logo PlantUML.......................................................................................................14
Figure 16. Logo Microsoft Word..............................................................................................15
Figure 17. Logo Microsoft Teams..............................................................................................15
Figure 18. Logo GitHub.............................................................................................................15
Figure 19. Logo Visual Studio Code........................................................................................15
Figure 20. Logo MySQL Workbench.......................................................................................15
Figure 21. Logo Eclipse IDEA.................................................................................................15
Figure 22. Logo Bruno..............................................................................................................15
Figure 23. Logo Angular...........................................................................................................16
Figure 24. Logo Spring Boot....................................................................................................16
Figure 25. Fonctionnement du JWT pour l’authentification.....................................................18
Figure 26. Auth Guard pour le contrôle d’accès.......................................................................18
Figure 27. Spring Security Pre Authorize.................................................................................19
Figure 28. Raffinement du cas d’utilisation « S’authentifier ».................................................19
Figure 29. Raffinement du cas d’utilisation « Gestion des Utilisateurs ».................................19
Figure 30. Sprint Backlog 1......................................................................................................20
Figure 31. Interface d’authentification......................................................................................21
Figure 32. Bouton de déconnexion...........................................................................................22
Figure 33. Interface de gestion d’utilisateurs............................................................................22
Figure 34. Interface d'ajout d'Utilisateur...................................................................................23
Figure 35. Rubriques par rôle...................................................................................................23
Figure 37. Test de l'authentification avec Bruno......................................................................24

Tableaux
11
12
14
14,15,16
 Acronymes

JWT: JSON Web Token (Jeton Web JSON)

KPI: Key Performance Indicator (Indicateur Clé de Performance)

PMO: Project Management Officer (Responsable de la Gestion de Projet)

API: Application Programming Interface (Interface de Programmation d'Application)

SPA: Single Page Application (Application Monopage)

IDE: Integrated Development Environment (Environnement de Développement Intégré)

 Introduction Générale
Ce rapport de stage offre une exploration approfondie d'un projet ambitieux réalisé au
sein de Sofrecom Sfax , une entité reconnue pour son excellence dans le domaine du conseil
et de l'ingénierie télécom. L'opportunité de participer à ce stage a été une expérience
enrichissante, non seulement en raison de l'environnement stimulant et des défis techniques
rencontrés, mais aussi grâce à la possibilité d'appliquer et de perfectionner des compétences
clés dans un cadre professionnel et technique.

Le projet au cœur de ce rapport concerne la conception et la mise en œuvre d'une

solution innovante pour améliorer la gestion de données collaborateurs au sein de l'entreprise.
Ce sujet a été choisi en réponse à un besoin identifié au sein de Sofrecom Tunisie, illustrant
ainsi l'importance d'une approche proactive et centrée sur l'utilisateur dans la résolution de
problématiques complexes.

Ce rapport est structuré de manière à offrir une vue d'ensemble complète du projet,
depuis son origine jusqu'à sa réalisation. Il commence par une présentation de l'entreprise et
de son contexte, suivi d'une introduction détaillée du sujet traité ainsi que la réalisation des
différents composants du projet.

1
 Chapitre 1

Cadre général
Introduction
Dans ce chapitre, nous allons décrire l’entité d’accueil au sein de laquelle nous avons
effectué notre stage d’été , nous mettrons en évidence le contexte du projet, nous définirons
brièvement notre solution/sujet tout en analyser l’existant, nous introduiront la méthodologie
adaptée et nous établirons le plan de travail adapté tout au long du projet.

1.1 Présentation de l’entreprise

1.1.1 Sofrecom Tunisie

Pour plus de 50 ans, Sofrecom est devenu l’un des leaders internationaux en
télécommunication. Etant partie du groupe Orange, Sofrecom est muni d’un savoir-faire
unique des métiers du numérique. Etant implantée sur plusieurs continents et ayant plus de
200 clients dans plus de 100 pays.

Figure 1. Sofrecom à l’international [1]

2
 Lancé en 2012, Sofrecom Tunisie est la plus importante filiale du groupe Sofrecom
dans la zone MEA devenu une partie prenant très importante du conseil et d’ingénierie en
télécommunications.

Avec plus de 400 experts, Sofrecom Tunisie fournit à ses clients des services cogitant
autour de plusieurs métiers informatiques et managériaux.

1.1.2 Domaines d’activités de Sofrecom Tunisie

Sofrecom a pu valider son expertise dans trois domaines :

 Développement IT : Ingénierie, Validation et intégration, Gestion de projets et de
plates-formes, Architecture, Design de logiciels et services.
 Conseil Business : Transformation digitale, Services financiers mobiles, Capacity
building and change Management . . .
 Conseil en IT et Networks : Conseil EGov et smartGov, Sécurité, Design de
Réseaux, Transformation de Réseaux, Optimisation Coûts et Investissement Réseaux,
E-Santé . . .

1.1.3 Charte Organisationnelle de Sofrecom Tunisie

Nous présentons ici la charte organisationnelle de l’entreprise. Notons que nous avons
été placés dans la direction Orange Wholesale

Figure 2. Structure de Sofrecom Tunisie

1.2 Contexte du projet

3
 Dans le contexte de stage d’été pour l’obtention du diplôme au sein de Sofrecom
Tunisie et dans la direction Orange Wholesale dont l’un de ses spécificités le développement
de solutions « from scratch », notre projet a pour objectif la conception et la réalisation d’un
référentiel interne de gestion de collaborateurs.

1.3 Introduction du sujet

1.3.1 Problématique

Au sein de Sofrecom, le Project Management Officer (PMO), responsable de la

gestion des collaborateurs de la direction technique, et celui qui gère les mouvements des
collaborateurs inter domaines, inter département, inter projet et avec les autres directions, ces
mouvements sont appelés dans notre contexte des mobilités.

Figure 3. Organigramme Managérial

De ce fait, le PMO collabore de bout en bout avec les managers (responsable pôle),
chefs de départements et directeurs en guise d’assurer la bonne gestion des ressources
(collaborateurs). Il a donc beaucoup de réunions à gérer, une base de données collaborateurs à
toujours mettre à jour.

Et finalement, il a comme mission de reporter l’état actuel aux directeurs, d’où un

besoin constant d’extraire les graphes et charts de différents indicateurs clés de performance
(Key Performance Indicators) à base de ces données.

Notamment, on parle de KPIs opérationnels tels que :

 Taux de départ.
 Taux de séniorité.
 Attractivité des départements.
 Répartitions des compétences par pool de compétences.

Ainsi, nous avons identifié un besoin de gérer les données collaborateurs ainsi que
leurs mouvements entre les différents directions, départements et pôles.

4
1.4 Méthodologie de travail
Pour mieux réaliser et implémenter notre solution, nous avons besoin d'opter pour une
méthodologie.

1.4.1 Choix de la méthodologie Agile

Dans la gestion de projet, deux méthodes se présentent : la méthode classique et la

méthode agile.

Figure 4. Méthodes de gestion de projet

La méthode classique se définit par un aspect linéaire qui passe par l'initiation ou
spécification des besoins, la planification, l'implémentation, la vérification et la clôture. Ce
qui ne convient pas à la nature de notre projet qui nécessite une méthode plus flexible et
ayant plus de “aller-retour” avec notre utilisateur final afin de mieux cerner le besoin.
Par ailleurs, la méthode agile se définit par un aspect itératif et incrémental par lequel
le projet passe par un cycle court de développement qui se répète au fur et à mesure, sans
avoir un cahier de charge initial complet.
Nous avons donc adopté pour le Framework Scrum Agile afin de réaliser notre projet
à l’adéquat.

1.4.2 Scrum

Scrum est un framework pour développer et maintenir des produits complexes et/ou
changeants. Autrement dit, Scrum est un framework de gestion de projet qui permet de

5
délivrer des produits de la plus grande valeur ajoutée dans une approche itérative et
incrémentale. [3]
Considérée “un environnement de gestion de projet” plus qu’une méthodologie, la
méthodologie Scrum n’impose aucune pratique bien déterminée et laisse à l’équipe la libre
main des décisions à prendre et prochaines étapes par rapport au développement du produit
ou solution.

Figure 5. Framework Scrum

Tout d’abord, l’équipe est composée de :
 Product Owner : Le Product Owner est responsable de maximiser la valeur du produit
résultant du travail de l'équipe de développement. Il gère le Product Backlog, en définissant
et en priorisant les fonctionnalités et les tâches à réaliser. Il veille à ce que l'équipe de
développement comprenne bien les éléments du Product Backlog et les objectifs du produit.
 Scrum Master : Le Scrum Master est responsable de promouvoir et de soutenir Scrum en
aidant tout le monde à comprendre la théorie, les pratiques, les règles et les valeurs de
Scrum. Il sert l'équipe de développement en supprimant les obstacles et en facilitant les
événements Scrum comme les mêlées quotidiennes, les rétrospectives et les revues de
sprint.
 Equipe Scrum / Equipe de dev : L'équipe de développement est composée de
professionnels qui travaillent à la création d'un incrément de produit potentiellement
livrable à la fin de chaque sprint. L'équipe de développement est auto-organisée et
interfonctionnelle, ce qui signifie que les membres possèdent toutes les compétences
nécessaires pour accomplir le travail sans dépendre d'autres personnes en dehors de l'équipe.

Grâce au feedback continu et collaboration avec l’utilisateur final ou client, en Scrum,

nous avons toujours la possibilité de “pivoter” et “se réorienter” de sprint en sprint, et ce pour
livrer la solution la plus “fonctionnelle” que possible afin de collecter plus d’information de
notre client pour le prochain incrément.

Comme défini dans la figure 6 ci-dessus, la réalisation de la solution s’effectue d’une

manière périodique où chaque cycle s’appelle Sprint. Chaque sprint dure entre 2 et 4
semaines. Et au début de chaque Sprint, nous faisons notre planification de Sprint.

6
 A la fin de chaque Sprint, il y a lieu la Sprint Revue, cet événement Scrum réunit
toute l'équipe Scrum y compris le Product Owner, en invitant nos stakeholders / parties
prenantes, où le but est de faire la démonstration du travail effectué toute au long du Sprint,
ainsi pour collecter leurs feedbacks.
A la fin de chaque Sprint également, toute l'équipe se réunit à la Rétrospective ou
chacun s’exprime d’une manière libre et transparente sur le déroulement du Sprint, ainsi que
sur les choses s’étant bien passées et les difficultés rencontrées. L’objectif c’est l'amélioration
continue des prochains Sprints.
Pour un meilleur suivi, nous effectuons également une mêlée quotidienne (daily
meeting ou standup quotidien) où chacun exprime son avancement, problèmes et blocages
rencontrés pour un meilleur partage de connaissance, savoir-faire et visibilité d’avancement
par toute l’équipe.
Nous trouvons toutes nos fonctionnalités dans le Product Backlog, défini par le
Product Owner et duquel on extrait nos tâches pour le prochain Sprint, dans le Sprint
Backlog.
L’orchestration des différentes cérémonies et réunions ainsi que les Sprints se fait par
le Scrum Master.

1.5 Plan de travail

Nous avons planifié la réalisation de notre solution en Sprints, dépendants l’un de
l’autre d’une manière itérative, nous avons suivi ce déroulement :

Figure 6. Planification du projet par Sprints

Conclusion
Dans ce chapitre, nous avons compris notre besoin, choisi la méthodologie de travail et
planifié notre projet.
Au cours des prochains chapitres, nous expliquerons la réalisation et la mise en place des
différents Sprints. Nous commençons par le premier Sprint : Sprint 0 concernant l’analyse et
conception.

7
 Chapitre 2
Sprint 0 : Analyse et Conception
Introduction

Dans ce chapitre, nous examinerons les besoins satisfaits par notre solution, tant
fonctionnels que non fonctionnels. Nous définirons également la conception, l’architecture
logique et l’architecture physique de notre application. Enfin, nous conclurons ce chapitre en
décrivant l’ensemble de l’environnement de travail dans lequel nous avons mené ce projet.

1.6 Analyse des besoins

Dans cette partie, nous allons définir chacun des acteurs, besoins fonctionnels et
besoins non fonctionnels.

1.6.1 Identification des acteurs

Seuls ces quatre acteurs ont accès à notre plateforme :

 Administrateur : responsable de la gestion globale des utilisateurs faisant partie de
l’équipe support/IT.
 PMO : c’est le Project Management Officer qui sera capable de gérer les
collaborateurs, accéder au jeu de données configurable, gérer les mobilités et générer
les Indicateurs Clés de Performance KPIs.
 Directeur : Le Directeur peut générer les Indicateurs Clés de Performance KPIs.

 Manager : Le Manager, responsable de son pôle ou responsable de son département,

peut gérer les collaborateurs qui lui sont affectés.

1.6.2 Besoins fonctionnels

Afin d’assurer la bonne gestion des données collaborateurs, notre solution proposée
respectera les spécifications qui suivent :
 Gestion des Utilisateurs.
 Authentification.
 Gestion des Collaborateurs.
 Génération des Indicateurs Clés de Performances KPIs.
 Gestion des Mobilités.
 Configuration et jeu de données.
 Ces besoins seront notamment satisfaits par notre application, mais sont l’objet de
plusieurs améliorations opérationnelles dans d’autres futurs cas possibles.

1.6.3 Besoins non fonctionnels

8
 En plus des besoins fonctionnels, notre application doit assurer, d’un point de vue non
fonctionnel :
 La sécurité : Les données traitées par l’application sont très cruciales donc
nécessitent une haute sécurité d’accès. Pour ce fait, on va implémenter un accès de
contrôle par rôle et utiliser les Web Tokens pour l’accès.
 La maintenabilité : Afin d’assurer que les futurs développeurs de pouvoir maintenir
l’application, on a opté pour une documentation appropriée.
 La Fiabilité : Les données sont très sensibles, on opte donc à un backup régulier de
base de données.
 L’utilisabilité : L’ergonomie joue un rôle important dans l’utilisabilité de la
plateforme. Dans ce contexte, on fait en sorte que chaque fonctionnalité soit
accessible en 3 clics maximum depuis la page d’accueil.

Ces besoins non fonctionnels permettront l’évolution continue de notre application

ainsi que sa scalabilité dans ces futures itérations.

1.6.4 Diagramme de cas d’utilisation global

Dans cette partie, nous utiliserons le diagramme UML de case d’utilisation du

système comme suite :

Figure 7. Diagramme de cas d’utilisation global

9
1.7 Conception : Diagramme de classe

Figure 8. Diagramme de classe

Ci-dessus, nous présentons le diagramme de classe de notre application.

10
1.8 Planification des sprints
Pour le bon déroulement de notre projet, nous avons opté à la planification par sprints
suivante :

Sprint Tâches et/ou fonctionnalités

Sprint 0 Analyse et Conception

Sprint 1 Accès

Tableau 1. Planification des Sprints

Nous allons détailler chaque fonctionnalité en plusieurs User Stories dans le tableau
suivant, afin de les rendre plus compréhensibles.
Pour estimer la complexité de nos User Stories, nous avons utilisé la séquence de
Fibonacci (1 ; 2 ; 3 ; 5 ; 8 ; 13). De plus, nous avons attribué une priorité à chacune de nos
User Stories comme suit :
 H : Haute priorité.
 M : Moyenne priorité.
 F : Faible priorité.

Par la suite, nous présentons le Product Backlog qui contient :

 Fonctionnalité : qui regroupe plusieurs User Stories ayant une même thématique.
 ID : permettant d’identifier chaque User Story.
 User Story : description textuelle de la User Story au format “En tant que… je
peux…”.
 Priorité : indique le niveau de priorité de la User Story.
 Story Points : définit la complexité de la User Story.

11
 Fonctionnalité ID User Story Priorité Story
Points

Authentification et #US1 En tant que visiteur, H 13

Accès je peux m’authentifier.

#US2 En tant que visiteur, H 3

je peux me déconnecter.

#US3 En tant qu’administrateur, M 3

je peux créer un nouveau
compte.

#US4 En tant qu’administrateur, M 5

je peux modifier un compte.

#US5 En tant qu’administrateur, M 5

je peux supprimer un compte.

Total Story Points du Sprint 1 29

Tableau 2. Product Backlog

Remarque : L’authentification est accessible à tout utilisateur.

1.9 Architecture de l’application

Dans cette partie, nous allons définir l’architecture physique de l’application ainsi que
ses architectures logiques.

1.9.1 Architecture physique

En tant qu’application web, nous avons opté pour une architecture permettant
une communication depuis l’utilisateur (navigateur), au serveur de présentation
(frontend), au serveur d’application (backend) jusqu’au serveur de base de données.

12
 Figure 9. Architecture n-tiers

1.9.2 Architecture logicielle

En termes d’architecture logicielle, nous avons appliqué le principe de séparation de

préoccupation et donc opté pour l’architecture multicouche pour le serveur d’application
démontrée dans la figure suivante :

Figure 10. Architecture multicouche

Par rapport au serveur de présentation, nous optons pour l’architecture en composants

définie par la figure qui suit :

Figure 11. Architecture en composants

13
 Dans cette partie, nous avons défini l’architecture de l’application, logicielle et
physique.

1.10 Environnement de travail

Dans ce qui suit, nous allons présenter les différents environnements de travail que
nous avons adopté lors de la réalisation du projet et notamment l’environnement matériel,
logiciel et de développement ainsi que les outils et technologies utilisés.

1.10.1 Environnement matériel

Pendant le stage, nous avons travaillé sur une machine avec la configuration suivante :

Spécification Détails

RAM 16,0 Go

Processeur Intel Core i5-6300

Stockage 250 Go (Disque dur)

Système d’exploitation Windows 10 Entreprise

Tableau 3. Environnement matériel

1.10.2 Environnement logiciel

Dans cette partie, nous allons présenter les différents logiciels dont nous avons fait usage
pendant la réalisation du projet.

Figure 12. Logo draw.io  Draw.io : Un outil de modélisation

graphique utilisé pour créer des
diagrammes UML, des flux de
travail, des plans d'architecture
logicielle, etc.

Figure 13. Logo  PlantUML : Un outil qui permet de

PlantUML générer des diagrammes UML à
partir de texte simple, facilitant la
documentation et la communication
entre les développeurs.

14
Figure 14. Logo Microsoft  Microsoft Word: Microsoft Word
Word est un logiciel de traitement de texte
développé par Microsoft qui permet
de créer et d'éditer des documents
professionnels.

Figure 15. Logo Microsoft  Microsoft Teams : Une plateforme

Teams de collaboration en ligne qui facilite
la communication et la coordination
au sein d'une équipe.

Figure 16. Logo GitHub  GitHub : Une plateforme de

gestion de version et de partage de
code, utilisée par les développeurs
pour collaborer sur des projets
logiciels.

Figure 17. Logo Visual  Visual Studio Code: Un éditeur de

Studio Code code léger mais puissant, supportant
de nombreux langages de
programmation et intégrant des
fonctionnalités de développement
comme la débogage et la gestion de
versions.

Figure 18. Logo MySQL  MySQL Workbench : Un outil

Workbench pour gérer et interroger des bases de
données SQL, offrant des
fonctionnalités avancées pour
l'analyse de données.

Figure 19. Logo Eclipse  Eclipse IDE : c’est est un

environnement de développement
intégré (Integrated Development
Environment) open-source
principalement utilisé pour le
développement de logiciels en Java
et offre une large gamme de
fonctionnalités.

Figure 20. Logo Bruno  Bruno : C'est un client d'API open

source qui permet de tester et
d'utiliser des API de manière
décentralisée et hors ligne.

15
 1.10.3 Environnement de développement

Figure 21. Logo Angular  Angular : Un framework conçu

par Google pour construire des
applications web SPA (Single Page
Application) dynamiques et
performantes.

Figure 22. Logo Spring  Spring Boot : Un framework Java

Boot simplifiant le développement
d'applications Spring, en
fournissant une configuration
automatique et minimale.

Tableau 4. Environnement logiciel

Conclusion
Ce chapitre a permis de définir les besoins fonctionnels et non fonctionnels ainsi que
la conception de l’application en termes de classes et d’entités.
Nous avons également présenté l'architecture logicielle et physique de l'application,
planifié les différents sprints et détaillé nos tâches sous forme de User Stories.
De plus, nous avons défini l’environnement de travail nécessaire à la réalisation de ce
projet. Toutes ces étapes constituent le résultat du Sprint 0, dédié à l’analyse des besoins et à
la conception de notre application.
Les chapitres suivants décriront en détail la réalisation des différents sprints.

16
 Chapitre 3

Sprint 1 Authentification et Accès

Introduction
Dans ce chapitre, nous détaillerons le travail accompli lors du premier Sprint, focalisé
sur la mise en place du système d'authentification et de gestion des utilisateurs. Ces
fonctionnalités sont essentielles pour assurer le bon fonctionnement de toute application web.

3.1 Prérequis
Avant de présenter la réalisation de ce Sprint 1, nous allons définir quelques termes,
auxquels nous avons été amenés à comprendre afin d’implémenter la fonctionnalité
d’authentification et gestion d’accès.
Après, nous allons présenter le Product Backlog du Sprint 1, après on va enchaîner
avec le Sprint Planning, le Sprint Revue incluant le travail réalisé, et le Sprint Rétrospective.

1.10.4 JSON Web Token

Le JWT (JSON Web Token) est un standard qui permet de transmettre de manière
sécurisée des informations entre des parties sous forme d'objet JSON. Il est souvent utilisé
pour l’authentification et l’autorisation dans le contexte de développement des applications
web. [4]
Le JWT est composé de trois parties : Header (en-tête), payload et signature.

Fonctionnement du JWT
Pour se connecter, l’utilisateur fournit ses identifiants ou credentials (nom
d’utilisateur et mot de passe) au serveur (backend).
Dans le cas où les informations fournies sont valides, le serveur génère un JWT
contenant ces informations et le renvoie au client (frontend).
Le JWT est stocké dans les Cookies en tant que HTTPOnly Cookies, pour des
mesures de sécurité et qui sont illisibles par le frontend.
Pour chaque requête ultérieure vers le serveur (backend), le client inclut le JWT dans
l’en-tête de la requête. Cela permet au serveur de vérifier l’identité de l’utilisateur pour
accéder aux ressources demandées.
Si le JWT n’est pas validé, le serveur renvoie une réponse d’erreur.

17
 On peut observer le fonctionnement du JWT dans la figure qui suit :

Figure 23. Fonctionnement du JWT pour l’authentification

1.10.5 Contrôle d’accès basé sur les rôles

Pour chaque utilisateur, on a attribué un rôle spécifique (Admin, Manager, Directeur

ou PMO). Et donc on donne différentes fonctionnalités pour chaque rôle.

Au niveau client (frontend), on utilise les Guards afin de définir pour chaque route,
qui y a accès.

Figure 24. Auth Guard pour le contrôle d’accès

18
 Au niveau serveur (backend), on utilise l'autorisation de Spring Sécurité
@preauthorize.

Figure 25. Spring Security Pre Authorize

3.2 Spécifications fonctionnelles

Dans cette partie, on va définir les spécifications fonctionnelles de l’authentification et
de la gestion Utilisateurs.

Figure 26. Raffinement du cas d’utilisation « S’authentifier »

19
 Figure 27. Raffinement du cas d’utilisation « Gestion des Utilisateurs »
3.3 Sprint Planning
3.3.1 Sprint Backlog

Pendant la cérémonie de planification du Sprint 1 (Sprint Planning), nous avons défini

les tâches à faire par le biais du Sprint Backlog 1.
Pour un meilleur avancement, nous avons opté dans ce Sprint 1 à avoir les 4 épics
suivants :
 Création des projets : Considérant que nous sommes en début de réalisation, on
commence tout d’abord par la préparation des projets de l’application et leur création,
notamment l’application backend et l’application frontend.
 Sécurité : Nous allons mettre en place un système de sécurité côté serveur et côté
client.
 Accès : Nous prenons en compte ici de l’accès en tant que fonctionnalité.
 Utilisateur : Nous mettons en place la gestion Utilisateur.

Figure 28. Sprint Backlog 1

3.3.2 Sprint 1 Goal : contrôle d'accès basé sur les rôles

Pendant le Sprint 1 Planning, nous avons fixé comme objectif principal du Sprint le
contrôle d’accès basé sur les rôles. Autrement dit, après ce Sprint, il est prévu d’avoir
l’authentification et l’accès à notre application, basé sur le rôle de l’utilisateur.

20
3.4 Sprint Revue
Ci-dessous, nous présentons les différentes interfaces que nous avons réalisées
pendant ce Sprint 1.
Nous avons effectué la Sprint Revue, durant laquelle nous avons invité les différentes
parties prenantes (Stakeholders) afin de leur démontrer le travail effectué tout au long du
Sprint 1 et de collecter leur retour et feedbacks. Toute l’équipe Scrum est présente pendant
cette réunion.

3.4.1 Réalisation

Dans cette partie, nous présenterons la réalisation des différentes interfaces de notre
application concernant l’authentification et la gestion utilisateur.

Figure 29. Interface d’authentification

C’est l’interface d’authentification, où l’utilisateur doit écrire son mot de passe ainsi
que son identifiant (Cuid est le terme utilisé au sein de l’entreprise pour identifier les
collaborateurs).

21
 Figure 30. Bouton de déconnexion

Par le biais de ce bouton, l’utilisateur peut à tout moment se déconnecter et être

redirigé vers l’interface d’authentification.

Figure 31. Interface de gestion d’utilisateur

En tant qu’administrateur, l’utilisateur peut gérer les différents utilisateurs.

22
 Figure 32. Interface d'ajout d'Utilisateur

Par ce formulaire, l’administrateur peut ajouter un nouvel Utilisateur.

Figure 33. Rubriques par rôle

Comme démontré dans la figure ci-dessus, pour chaque rôle, on a des rubriques bien
spécifiques et des fonctionnalités bien spécifiques.

A la fin du Sprint, les différentes parties prenantes ont donné un retour sur le travail
effectué, qui a été positif, ainsi que des remarques d’amélioration.

23
3.4.2 Tests du Sprint 1

Nous avons testé nos différentes fonctionnalités, côté serveur, en utilisant Bruno :

Figure 34. Test de l'authentification avec Bruno

3.5 Sprint Rétrospective

La Sprint Rétrospective est une réunion organisée à la fin de chaque sprint durant
laquelle l'équipe Scrum examine ce qui s'est passé pendant le sprint précédent. Elle offre une
opportunité pour l'équipe de s'auto-évaluer, de partager ses expériences, de discuter des
forces et des faiblesses observées, ainsi de définir des plans d’action pour opter à une
démarche d'amélioration continue pour le prochain sprint.

Conclusion
En guise de conclusion, nous avons traité le Sprint 1 pendant ce chapitre. Au cours
duquel nous avons fait face à plusieurs obstacles et difficultés auxquels nous avons appris
beaucoup de savoir-faire en y remédiant.

Nous avons bien mis en place l’aspect sécurité de notre application en utilisant des
outils standards tels que Spring Security, JWT et Angular Guard afin d’assurer la sécurité de
nos utilisateurs et données.

24
 Bibliographie
(1) https://www.sofrecom.com/a-propos-de-nous/nos-bureaux.html
(2) https://www.qrpinternational.fr/blog/glossaire/scrum-cest-quoi-definition-scrum/
(3) https://www.atlassian.com/fr/agile/scrum
(4) https://jwt.io/introduction
(5) https://support.atlassian.com/jira-software-cloud/docs/view-and-understand-the-
velocity-chart/
(6) https://docs.github.com/fr/actions/about-github-actions/understanding-github-actions

25
26