République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Institut Supérieur Polytechnique Privé
*******

Projet de Fin d’Études

En vue de l’obtention du Diplôme National d’Ingénieur en Génie Logiciel

Élaboré par :
Chedi Hayouni

Conception et réalisation d’une application micro

services du gestion des resources humaines

Réalisé au sein de

Fondative
Encadré par :

Encadrant(s) universitaire(s) : Encadrant(s) industriel(s) :

Mme Asma Amdouni Mr Mahmoud Abdnadher

Année universitaire
2018 - 2019
 Introduction générale

e poste Ressources Humaines évolue d’une façon importante pour plusieurs raisons : le dé-
L veloppement de l’informatique (exemple : le traitement de présence), l’augmentation de la
compétitivité et la globalisation de l’économie, ce qui demande de grande capacité de réactivité,
de flexibilité et d’innovation. Ce qui implique que les formes «traditionnelles» qui sont appelé
avant la fonction personnel ne permettent plus d’achever le niveau exigé dans le marché.

La naissance des applications informatiques pour la GRH était dans les années 70 qui à com-
mencer par l’apparition des logiciels de gestion de la paie. . . et c’est à partir des années 90 que
les premiers logiciels SIRH (système d’informations ressources humaines) ont apparu.
Un SIRH propose une variété de fonctionnalités permettant d’automatiser différentes procé-
dures liées à la gestion RH : recrutement, paie, gestion administrative, gestion des talents. . .
Une bonne maîtrise de ces tâches est nécessaire pour bénéficier des objectifs attendus de l’im-
plémentation d’un SIRH. Dans ce cadre notre projet intitulé « développement d’une application
multi-services de gestion des ressources humaines » est réalisé au sein de l’entreprise Fondative.

Ce rapport est composé principalement de 6 chapitres :

— Chapitre 1 : Etude préalable

— Chapitre 2 : Planification et architecture

— Chapitre 3 : Sprint 1 « Mise en place de l’architecture »

— Chapitre 4 : Sprint 2 « Gestion des personnels »

— Chapitre 5 : Sprint 3 « Gestion des congés »

— Chapitre 6 : Sprint 4 « Gestion des assurances »

1
 CHAPITRE I

ÉTUDE PRÉALABLE
CHAPITRE I. ÉTUDE PRÉALABLE

I.1 Introduction
a mise en œuvre du projet constitue une étape fondamentale pour une adaptation parfaite,
L Dans ce chapitre, nous allons présenter le cadre du projet, l’étude et la critique du quelques
solutions existantes et nous finissons par la solution proposé et quelques prototypes d’interfaces.

I.2 Présentations du l’université

L’Université Libre de Tunis « ULT », par sa large gamme de programmes d’études aux
trois cycles et ses activités diversifiées de recherche appliquée, a pour mission de former aussi
bien la relève que les personnes en situation d’emploi, de rendre accessible la connaissance de
pointe à tous les milieux sociaux et culturels et de servir la collectivité qui lui exprime ses
besoins.

Figure I.1 – Université Libre de Tunis

I.3 Présentation de l’entreprise

I.3.1 Description

Fondative est une société de services informatiques filiale d’un groupe multinational de
plus de 16 ans d’expérience. Offre une expertise en Symfony, Angular, API-REST, DevOps,
automatisation des tests et développement mobile.

Le centre de développement Fondative offre un ensemble de services tels que :

— La migration des applications web vers Symfony.

— La conception et la mise en place des API-REST conformes aux standards et aux bonnes
pratiques.

— L’assistance technique de meilleur qualité et à haute disponibilité.

— Le développement des applications web sur mesure.

2
CHAPITRE I. ÉTUDE PRÉALABLE

Figure I.2 – Fondative

I.3.2 Organigramme de l’entreprise

Figure I.3 – Organigramme de l’entreprise

I.4 Présentation du projet

I.4.1 Contexte du projet

Ce projet rentre dans le cadre du projet de fin d’études qui vient de conclure notre
formation d’ingénieur à l’Université Libre de Tunis.

3
CHAPITRE I. ÉTUDE PRÉALABLE

I.4.2 Objectif du projet

Ce projet a pour but de mettre en place un système d’information de gestion RH pour

la société Fondative. L’objectif est de concevoir et implémenter une application pour gérer
l’ensemble des processus de gestion des ressources humaines.

I.4.3 L’intérêt de l’application

L’avantage de cette plateforme quelle va être sur mesure pour la société Fondative afin de
répondre à un certains nombres des besoins spécifiques et offrir une flexibilité dans la manipu-
lation de gestion des ressources humaines selon la structure et les ressources de cette entreprise.

I.5 Étude et critique de l’existant

L’étude fonctionnelle du projet constitue une étape fondamentale pour une adaptation
parfaite, pour cela nous avons choisi deux applications similaires de gestion des ressources
humaines Euricia et Bitrix24 pour les étudier afin de dégager l’ensemble des avantages et in-
convénients.

I.5.1 Analyse de la plateforme Euricia

La figure ci-dessous donne une vision sur l’ensemble des salariés avec la possibilité de crée
un nouveau salariée :

Figure I.4 – Liste des salariés Euricia

4
CHAPITRE I. ÉTUDE PRÉALABLE

La plateforme offre un espace personnels pour les salariés dans le quel lui donne la pos-
sibilité d’envoyer une demande de congé ou de consulter l’historique et l’état des demandes
comme le montre la figure 5 :

Figure I.5 – Demande congé Euricia

Figure I.6 – Liste des congés Euricia

La plateforme Euricia offre aussi un module pour la gestion des frais, les figures 7 et
8 illustre les phases d’ajout d’une nouvelle note de frais et la consultation de l’ensemble des
demandes avec l’état de chacune.

5
CHAPITRE I. ÉTUDE PRÉALABLE

Figure I.7 – Nouvelle note de frais Euricia

Figure I.8 – Liste des notes de frais Euricia

I.5.2 Critique de la plateforme Euricia

Après l’analyse détaillée plusieurs avantages et insuffisances ont été détectées :

— La mise à disposition d’un grand nombre d’informations des utilisateurs (département

email fonction. . .)

— Possibilité de filtrer les utilisateurs selon département

6
CHAPITRE I. ÉTUDE PRÉALABLE

— Diversité des modules offerts (gestion des congés et des notes de frais . . .)

— Possibilité d’ajouter des pièces justificatives

— L’absence d’une barre de recherche et la possibilité d’effectuer une recherche spécifique

— Manque d’interactivité entre les pages (il n’y a pas de lien de retour en arrière)

— Absence du module de gestion du temps pour les salariés

— Absence du calendrier de l’entreprise

— Défaillances ergonomiques (Design basique, des logos non significative pour les modules)

I.5.3 Analyse de la plateforme Bitrix 24

Parmi l’ensemble des modules offerts par la plateforme Bitrix 24 on trouve le module de
gestion du calendrier, la figure 6 illustre le calendrier de l’entreprise.

Figure I.9 – Calendrier Bitrix 24

Bitrix 24 offre une visibilité sur le temps de travail pour chaque employé comme le montre
la figure 10.

7
CHAPITRE I. ÉTUDE PRÉALABLE

Figure I.10 – Temps de travail Bitrix 24

La plateforme aussi offre une gestion des taches, l’administrateur peut affecter un ensemble
des taches pour chaque employé et il a une visibilité sur l’ensemble de ces taches soit donc la
rubrique mes taches soit sur le calendrier de l’entreprise.

Figure I.11 – Liste des taches Bitrix 24

On trouve aussi dans Bitrix 24 un module de gestion des employés dans lequel l’adminis-
trateur peut ajouter des nouveaux employés ou consulter la liste des employés déjà existant.

8
CHAPITRE I. ÉTUDE PRÉALABLE

Figure I.12 – Ajouter employé Bitrix 24

Figure I.13 – Liste des employés

I.5.4 Critique de la plateforme Bitrix 24

Après l’analyse détaillée plusieurs avantages et insuffisances ont été détectées :

— La mise à disposition d’un grand nombre d’informations des utilisateurs (département

email fonction. . .).

— Possibilité de filtrer les utilisateurs selon département.

9
CHAPITRE I. ÉTUDE PRÉALABLE

— Un module de gestion des taches simple et riche fonctionnellement.

— L’ajout des salariés se fait de plusieurs façons (invitation par email, ajout manuelle. . .).

— Absence du module de gestion d’assurance.

— Absence du module de gestion de congé.

I.5.5 Synthèse

Les deux plateformes Euricia et Bitrix 24 offre un ensemble de fonctionnalités intéres-

santes mais qui sont pas adaptés à un certain nombre de besoins spécifique pour la société
Fondative ainsi que ses deux plateformes sont payantes et les modules offerts sont limités et
dans une version d’essai.

Dans la prochaine section on va présenter la solution proposé et les déférents scénarios à l’aide
d’un ensemble de maquettes.

I.6 Prototype d’interfaces

I.6.1 Solution proposée

La solution proposée est de concevoir et implémenter une plateforme multi-service de

gestion RH permettant à la société de gérer l’ensemble des processus RH dans l’entreprise :
gestion personnel, gestion des congés, calendrier de l’entreprise et la gestion d’assurance . . ..

L’intérêt de cette plateforme quelle va être sur mesure pour la société Fondative afin de répondre
à un certains nombres des besoins spécifiques et offrir une flexibilité dans la manipulation de
gestion des ressources humaines selon la structure et les ressources de cette entreprise.

I.6.2 Interfaces graphique

Dans cette section on va présenter l’ensemble des maquettes et scénarios pour chaque
module.

I.6.2.1 Module gestion des personnels

X Partie Administrateur :
L’administrateur s’authentifie à l’aide de son email et mot de passe déjà stocké dans la

10
CHAPITRE I. ÉTUDE PRÉALABLE

base des donnés pour accéder à son espace administrateur.

Figure I.14 – Interface de connexion

Après que l’authentification est effectuée avec succès le système redirige l’administrateur
vers une interface de gestion des personnels dans laquelle il a une vision générale sur
l’ensemble des personnels.

Figure I.15 – Liste des personnels

11
CHAPITRE I. ÉTUDE PRÉALABLE

L’administrateur peut voir plus des détail sur un personnel choisi en cliquant sur le bouton
« Détail » ou bien il peut supprimer un personnel à l’aide du bouton « Supprimer ».

Figure I.16 – Détail des personnels

Aussi l’Administrateur à la possibilité de modifié le personnel choisi en cliquant sur bouton

modifié.

Figure I.17 – Modifier un personnel

12
CHAPITRE I. ÉTUDE PRÉALABLE

L’administrateur peut ajouter un nouveau personnel en cliquant sur le bouton «Ajouter»,

le système va le rediriger vers l’interface d’ajout du personnel.

Figure I.18 – Ajouter personnel

X Partie employé :
L’employé s’authentifie à l’aide de son email et mot de passe déjà stocké dans la base des
donnés pour accéder à son espace Personnel.

Figure I.19 – Connexion employé

13
CHAPITRE I. ÉTUDE PRÉALABLE

Le système lui affiche son profil qui contient l’ensemble de ces informations personnelles
et professionnelles.

Figure I.20 – Profil employé

I.6.2.2 Module gestion des congés

X Partie administrateur :
Après avoir authentifié l’administrateur peut accéder au menu «Congé» dans lequel il
va trouver l’ensemble des demandes de congé avec les détails du propriétaire de chaque
demande il peut soit valider la demande soit la refuser

Figure I.21 – Liste des demandes congé

14
CHAPITRE I. ÉTUDE PRÉALABLE

Chaque nouvelle demande sera injectée automatiquement dans ce calendrier.

Figure I.22 – Calendrier de l’entreprise

X Partie employé :
Après avoir authentifié l’employé peut accéder au menu «Congé» il peut choisir d’ajouter
une nouvelle demande de congé en cliquant sur le rubrique « demande congé », le système
va afficher l’interface d’ajout d’une nouvelle demande de congé.

Figure I.23 – Demande congé

15
CHAPITRE I. ÉTUDE PRÉALABLE

Figure I.24 – Liste du congé personnel

I.6.2.3 Module gestion des assurances

X Partie administrateur :
Une fois l’administrateur est authentifié il peut accéder au menu « Assurance » pour gérer
l’ensemble des demandes d’assurance, le système affiche l’interface qui contient la liste des
demandes, l’administrateur peut valider ou refuser une demande il peut aussi voir plus
de détail sur une demande bien déterminé ou bien il peut supprimer une demande.

Figure I.25 – Gestion des demandes d’assurance

16
CHAPITRE I. ÉTUDE PRÉALABLE

X Partie employé :
Dès que l’employé sera authentifié il peut accéder au menu « Assurance » pour ajouter
une nouvelle demande d’assurance, le système va afficher l’interface approprié. L’employé
ajoute l’ensemble des informations relatives à cette demande et la valide.

Figure I.26 – Demande assurance 1

Figure I.27 – Demande assurance 2

17
CHAPITRE I. ÉTUDE PRÉALABLE

L’employé peut consulter ses demandes d’assurance en cliquant sur la rubrique « Mes
demandes », le système va afficher la liste des demandes qui donne quelques informations
sur la demande et son état.

Figure I.28 – Liste des demandes d’assurances

I.7 Conclusion
Dans ce chapitre nous avons mis le projet dans son cadre organisationnel, nous avons
présenté une étude qui a menée à critiquer l’existant et on a proposé une solution à travers
un ensemble de prototype d’interfaces. Dans le chapitre suivant nous allons étudier quelques
méthodologies de travail afin d’adopter une pour la mise en place du projet.

18
 CHAPITRE II

PLANIFICATION & ARCHITECTURE

CHAPITRE II. PLANIFICATION & ARCHITECTURE

II.1 Introduction
ans ce chapitre nous allons dégager l’ensemble des besoins fonctionnels et non fonction-
D nels par suite nous allons étudier quelques méthodologies de travail et nous clôturons le
chapitre avec l’étude de l’architecture de l’application.

II.2 Méthode de travail

II.2.1 Gestion des projets

Dans sa nouvelle forme, la gestion de projet est née au début des années 1950, malgré
que ses racines remontent beaucoup plus loin dans le temps, à la fin du 19ème siècle. Dès lors
que les entreprises ont découvert les intérêts de l’organisation du travail autour de projets,
en reconnaissant l’importance fondamentale de communiquer et de coordonner efficacement le
travail entre les individus, une méthode précise de gestion de projet a en effet émergé. L’objectif
de gestion du projet est de livrer un projet finis dans les délais et sans dépassement du budget.

Figure II.1 – Gestion des projets

II.2.2 Méthodologies de développement

Une méthode de travail pour un logiciel est une manière de structurer, planifier et contrôler
le processus de développement afin de rendre ce développement plus fidèle aux besoins du client.
Il existe de familles de méthodes : les méthodes agiles et les méthodes classiques.

II.2.2.1 Les méthodes agiles

Les méthodes agiles sont des approches de développement informatique permettent d’im-
plémenter des applications en impliquant le client dans toutes les étapes de cycle de vie du

19
CHAPITRE II. PLANIFICATION & ARCHITECTURE

logiciel afin d’obtenir un produit qui répond au maximum aux besoins du client.

Dans les méthodes agiles le développement du logiciel est devisé en un ensemble des étapes
appelé « itération », chaque itération représente un ensemble des besoins fonctionnels fixé par
le client et estimé par le chef de projet en termes de temps de développement.

II.2.2.2 Les méthodes classiques

Les méthodologies classiques de gestion des projets se reposent à planifier le projet de bout
en bout et sont résistantes aux changements, on les dit « prédicatives ». Dans les méthodes
classiques le développement du logiciel se découpe en plusieurs étapes définit dès le démarrage
du projet. La validation d’une étape entraîne le début de la suivante. Cette méthode limite les
retours aux étapes précédentes.

II.2.3 Comparaison entre les méthodes

Il est très critique de bien choisir la bonne méthodologie de travail afin de bien répondre
aux besoins et exigences du client en respectant les délais fixés. Pour cette raison on doit
effectuer une étude comparative entre les approches pour dégager la meilleure méthodologie
qui s’adapte avec notre projet.

Description Points forts Points faibles

XP(eXtreme Est une méthode agile La méthode de l’Extreme

Program- orientée sur l’aspect réa- — Itératif Programming peut dif-
ming) lisation d’une applica- ficilement être pratiquée
— Simple à mettre en
tion, XP est adapté aux avec une équipe de grand
œuvre.
équipes réduites avec des nombre cela rendrait la
— S’articule sur les
besoins changeants. communication et l’orga-
« feedbacks » des
nisation des travaux trop
clients.
complexe. Les équipes
pourraient se retrouver
cloisonnées

20
CHAPITRE II. PLANIFICATION & ARCHITECTURE

2TUP(Two Propose un cycle de La difficulté d’intégré

Track Unified développement en Y. — Itératif (fusionner) l’étude fonc-
Process) Adapté pour des projets tionnelle et technique
— Orienté vers la ges-
de différentes tailles. des deux branches du
tion des risques.
cycle en Y en un seul
— définit clairement
modèle.
les intervenants,
les prototypes et
les livrables.

Scrum Scrum est basée sur le SCRUM s’adapte diffi-

découpage du projet en — Ses processus de cilement aux outils de
un ensemble des sprints, développement gestions de tâches (JIRA,
chaque sprint a une pla- sont simples. TFS,. . .) qui imposent
nification et une estima- des interprétations très
— Basée sur un en-
tion, à la fin de chaque bureaucratiques de
semble des règles
sprint un livrable doit Scrum.
strict et simple et
être livré au client.
l’auto organisation
des membres de
l’équipe.

— Amélioration du
communication.

Tableau II.1 – Tableau comparatif entre les méthodologies de développement

II.2.4 Méthodologie adoptée

Suite à l’étude comparative nous avons constaté que les trois méthodologies étudiées sont
itératif et chaque une se focalise sur une étape bien déterminée du cycle de vie de projet.

Nous avons adopté SCRUM comme Framework de travail car elle satisfait un certain nombre

21
CHAPITRE II. PLANIFICATION & ARCHITECTURE

de conditions :

— Scrum est adoptée aux équipes de petites tailles ce qui nous convient car le travail est
individuel.

— Avec Scrum le client est impliqué dans toutes les phases du projet ce qui est notre cas
notre client est prêt à participer de manière quotidienne à notre projet.

— Scrum garantie l’amélioration de la communication qui l’un des objectif du notre projet
suit à l’ensemble des réunions quotidiennes ou autres.

Un autre point très important que la société d’accueil dans la quel on va développer le projet
a adopté Scrum depuis sa fondation et applique toutes ses règles ce qui nous à encourager à
choisir cette méthodologie.

II.2.4.1 Présentation du Scrum

Scrum est un cadre du projet qui a été créé pour augmenter la productivité de l’équipe
par rapport aux autres méthodologies, Scrum est facile à comprendre mais difficile à maitriser.
La vie d’un projet Scrum est rythmée par un ensemble des itérations et de réunions clairement
définies et strictement limitées dans le temps, chaque itération appelé Sprint.

Figure II.2 – Scrum

Chaque sprint contient un ensemble des besoins fixé par le client qui sont traduites par le
chef du projet en un ensemble des taches à implémenter chaque tache à une estimation et une
priorité, toutes ces informations compose le backlog du sprint qui sera finalement un produit
partiel livrer au client pour le valider.

22
CHAPITRE II. PLANIFICATION & ARCHITECTURE

II.2.4.2 Les rôles SCRUM

Scrum définit généralement trois rôles :

X Le « Product Owner » qui porte la vision du produit à réaliser (représentant généra-

lement le client).

X Le « Scrum Master » son rôle principal est de gérer l’équipe et éliminer les obstacles
pour atteindre les objectifs dans les délais.

X Le « Scrum Team » c’est l’équipe de développement qui réalise le produit.

II.2.4.3 Présentation de l’équipe

Le tableau ci-dessous présente les membres d’équipe qui ont participé à ce projet ainsi
que leurs rôles Scrum :

Rôle Acteur
Product Owner Yessine Ezzine
Scrum Master Mahmoud Abdenadher
L’équipe Dev Hayouni Chédi, Samer selmi, Amira Ben Hadid

Tableau II.2 – Tableau 2

II.3 Étude des besoins

Les besoins fonctionnels et non fonctionnels feront l’objet de cette partie ce qui nous
permettra de concevoir les objectifs de la plateforme.

II.3.1 Besoins fonctionnels

Vu les contraintes temps, architecture et volume de la plateforme, on a choisi de découper

l’application en un ensemble des modules.

II.3.1.1 Module de gestion des personnels

X Gestion des informations des personnels (les informations personnelles et professionnelles).

X Gestion des rôles (les droits d’accès).

X Gestion de la structure de l’organisation des personnels (hiérarchie).

23
CHAPITRE II. PLANIFICATION & ARCHITECTURE

X Gestion du profil employé.

X Gestion des conjoints.

II.3.1.2 Module de gestion des congés

X Gestion des demandes des congés.

X Calcul du solde des congés.

X Paramétrage des jours fériés.

X Ajout du calendrier de l’entreprise.

X Consultation du solde des congés.

X Consultation des états des demandes.

X Gestion des états des demandes des congés (valider / refuser).

X Envoie des emails.

II.3.1.3 Module de gestion des assurances

X Gestion des fiches d’assurances.

X Gestion des états des demandes des congés (valider / refuser).

X Consultation des états des demandes.

X Génération des bordereaux d’assurance.

X Téléchargement des bordereaux d’assurance.

X Envoie des emails.

II.3.2 Besoins non fonctionnels

Par rapport aux besoins fonctionnels précédemment présenté, la solution doit respecter
un ensemble de critères qui ne touchent pas aux objectifs métiers espérés mais contribuent à
une meilleure qualité de la solution obtenue :

X La plateforme doit être extensible et paramétrable pour les futures évolutions et doit être
fonctionnels avec tous plugins ajoutés ultérieurement.

X L’ergonomie : l’application doit offrir une interface conviviale et suffisamment rapide pour
manipuler les différents champs de l’application.

X La sécurité : l’application doit respecter la confidentialité des données.

24
CHAPITRE II. PLANIFICATION & ARCHITECTURE

II.4 Backlog Produit

ID_F Feature Sprint EBP Estimation Priorité

/semaine

Préparation d’environne- Mise en place des envi- 0.5

ment et mise en place de ronnements de dévelop-
l’architecture pement

1 1
Mise en place des micro- 2
services

Développement du Gate- 2
way de l’architecture

Mise en place du système 2

d’authentification

Développement du Configuration du Gate- 0.25

micro-service de la way
gestion des personnels

Développement du partie 2.5

1 2
de la gestion des person-
nels

Développement du ges- 2
tion des conjoints

Développement du ges- 1.75

tion des départements

Configuration du sys- 2
tème du cache redis et
ajout du système de
sécurité

25
CHAPITRE II. PLANIFICATION & ARCHITECTURE

Développement du Configuration du Gate- 0.25

micro-service de la way
gestion des congés

Paramétrage des jours fé- 0.25

riés

2 Ajout du calendrier de 1 3
l’entreprise

Implémentation du script 2
du calcule de solde de
congé

Mise à jour des soldes de 0.25

congé

Gestion des demandes de 1.5

congé

Validation des demandes 1

de congé

Configuration du sys- 1
tème du cache redis et
ajout du système de
sécurité

Développement du Configuration du Gate- 0.25

micro-service de la way
gestion des assurances

3 4
Gestion des demandes 1.5
d’assurances

26
CHAPITRE II. PLANIFICATION & ARCHITECTURE

Paramétrage des types 0.5

d’assurances

Implémentation du 1
script du génération
automatique des borde-
reaux d’assurances

Tableau II.3 – Backlog Produit

II.5 Étude des technologies

II.5.1 Environnement matériel :

Notre application web a été réalisée par un ordinateur fixe ayant les caractéristiques
suivantes :

• Ordinateur Fixe : Dell

• Système d’exploitation : Ubuntu 18.04.

• Processeur : Intel Core i7

• RAM : 8Go

II.5.2 Environnement logiciel :

Les informations concernant les environnements logiciels utilisés seront présentées dans l’annexe
1.

X Visual studio code

X PhpStorm

X Slack

X PowerAMC

II.5.3 Technologies :

Les informations concernant les technologies utilisées seront présentées dans l’annexe 1.

X Symfony 4

27
CHAPITRE II. PLANIFICATION & ARCHITECTURE

X NestJs

X MySql

X Redis

X ReactJs

X redux

II.6 Architecture de l’application

Dans cette partie on va présenter un petit résumé sur l’étude de l’architecture effectuer
dans la partie recherche de notre projet ce qui nous guidé à mettre en place le premier Gateway
de son type avec le Framework Symfony.

II.6.1 Présentation de l’architecture micro-services

L’architecture micro-service est une méthode de développement d’applications logicielles

en tant que suite de services modulables et indépendamment, dans lesquels chaque service exé-
cute un processus unique et communique à travers un mécanisme léger et bien défini.

Les architectures micro-service permettent de développer, de déployer et de gérer opérationnel-

lement des applications distribuées, constitués de services aux fonctionnalités complémentaires,
potentiellement hétérogènes et interopérables.

II.6.2 Types des architectures micro-services

En fait il n’y a pas une architecture bien définit (unifié) pour les micro-services, par
contre il y’a un ensemble des règles (principes) pour mettre en place cette approche. On trouve
généralement deux grandes catégories des micro-services :

X Communication directe client : micro-service

28
CHAPITRE II. PLANIFICATION & ARCHITECTURE

Figure II.3 – Micro-service 1

Dans cette approche, une application client peut adresser des demandes directement à certains
micro-services. Une architecture de communication directe client-micro-service peut convenir à
une petite application.

29
CHAPITRE II. PLANIFICATION & ARCHITECTURE

X Communication à travers une passerelle API

Figure II.4 – Micro-service 2

Contrairement à l’approche précédente cette méthode consiste à mettre en place un « Api

Gateway » qui sera responsable sur la communication entre les micro-services et la partie client
(web ou mobile) donc toutes les requêtes doivent passer par ce micro-service personnalisé. Pour
mieux comprendre les choses il faut savoir que ce « Api Gateway » à principalement comme
rôles :
X Proxy inverse ou routage par passerelle
X Agrégation de demandes
X Intégration de découverte de service
X Authentification et autorisation

II.6.3 Choix de l’architecture

Il y a plusieurs critères de choix qu’il faut prendre en considération pour travailler avec
les micro-services :
X Nombre des micro-services : si le nombre des micro-services dépassent les trois micros
il faut adopter l’architecture basée sur le « Api Gateway » pour minimisé les requêtes
entre le client et la partie back-end ce qui notre cas en prenant en considération qu’il y a
d’autres modules qui vont être ajouté ultérieurement.

30
CHAPITRE II. PLANIFICATION & ARCHITECTURE

X Couplage : lé décomposition des micro-services doit être effectué en tenant compte sur
la règle d’élimination du couplage entre micro-services pour qu’ils soient indépendants,
cette règle impacte directement sur le nombre des micro-services.

X Sécurité : sans passerelle, tous les micro-services doivent être exposés au "monde ex-
térieur", ce qui rend la surface d’attaque plus grande que si nous masquons des micro-
services internes qui ne sont pas directement utilisés par les applications client. Plus la
surface d’attaque est petite, plus notre application peut être sécurisée.

Vu aux conditions qu’on a cité précédemment notre application sera basée sur un « Api-Gateway
» afin de répondre de façon meilleure pour tout ce qui est sécurité et temps de réponse. Dans
la prochaine section on va présenter l’architecture de notre application.

II.6.4 Architecture de l’application

L’architecture de notre application se base sur un « Api-Gateway » mais d’une façon

personnalisé avec d’autre mécanisme qu’on ajouté pour obtenir un résultat plus satisfaisant.

Figure II.5 – Architecture du projet

Comme la montre la figure ci-dessus notre système se compose de trois micro-services

indépendants qui vont répondre chacun à un certain nombre de besoins fonctionnels, le « Api-
Gateway » qui va jouer le rôle du passerelle et contenir le système d’authentification, un système
de cache avec « Redis » qui va centralisé l’ensemble des utilisateurs connectés et qui va garantir

31
CHAPITRE II. PLANIFICATION & ARCHITECTURE

aussi une autre couche de sécurité et finalement à ajouter une troisième couche de sécurité avec
l’autorisation exclusive des adresse IP des micro-services.

II.7 Conclusion
Dans ce chapitre nous avons étudié les méthodologies de travail et les architectures micro-
services et nous avons adopté un choix pour chacun des deux. Dans le prochain chapitre nous
allons entamer la phase de l’implémentation.

32
 CHAPITRE III

Sprint 1 : Mise en place du L’architecture

CHAPITRE III. SPRINT 1 : MISE EN PLACE DU L’ARCHITECTURE

III.1 Introduction
ans ce chapitre nous allons détailler les étapes de mise place de l’architecture micro-service
D ainsi que l’implémentation du « Api-Gateway » et la couche de sécurité.

III.2 Backlog du sprint 1

Les fonctionnalités de ce sprint seront regroupées en un ensemble des User Stories, la
figure ci-dessous représente le backlog du premier sprint.

Estimation
EBP ID_Task EEBP(Task)
/semaine

Se familiariser avec les

Préparation des 1.1
Framework. 0.5
environnements
Installation et configuration des
1.2
environnements de développements.

Création et configuration du
1.3
Mise en place des projet de gestion des personnels.
2
micro-services Création et configuration du
1.4
projet de gestion des congés.
Création et configuration du
1.5
projet de gestion des assurances.

Création et configuration du
1.6
« Api-Gateway ».
Implémentation du Paramétrage des routes des
1.7 2
« Api-Gateway » micro-services.
1.8 Création de la passerelle Api
Implémentation du système
1.9
d’authentification.
Ajout et configuration du système
1.10
de cache « Redis »

31
CHAPITRE III. SPRINT 1 : MISE EN PLACE DU L’ARCHITECTURE

III.3 Préparation des environnements

Nous allons commencer par l’installation des environnements PHP 7.2 et NodeJs 11.14.

Figure III.1 – PHP & NodeJS

Une fois PHP est installé correctement on installe le logiciel de gestion des dépendances
« Composer ».

Figure III.2 – Composer

La dernière étape c’est ajouter PHP et Composer dans la configuration système (variables
path).

32
CHAPITRE III. SPRINT 1 : MISE EN PLACE DU L’ARCHITECTURE

Figure III.3 – Configuration système

III.4 Mise en place des micro-services

Cette étape consiste à créer les micro-services avec les nécessaire afin de pouvoir tester
après le bon fonctionnement du système avec cette architecture, pour pouvoir test les api on va
utiliser la librairie « Swagger » qui va être responsable sur l’exposition de la liste des api dans
la quel on peut tester le fonctionnement de chaque action.

III.4.1 Mise en place du micro de gestion des personnels

Le développement de chaque micro-service est évolutif du coup dans cette étape on va

mettre en place quelques actions pour pouvoir tester le système. Après l’implémentation on

33
CHAPITRE III. SPRINT 1 : MISE EN PLACE DU L’ARCHITECTURE

lance l’interface du projet en local avec l’api « Swager ».

Figure III.4 – Conjoint configuration

Figure III.5 – Département configuration

Figure III.6 – Configuration des Personnels

III.4.2 Mise en place du micro de gestion des congés

De même pour ce micro-service on va implémenter quelques fonctionnalités et les tester

avec la même librairie « swager ».

34
CHAPITRE III. SPRINT 1 : MISE EN PLACE DU L’ARCHITECTURE

Figure III.7 – Gestion des demandes

Figure III.8 – Gestion des types des demandes

Figure III.9 – Gestion des jours fériés

III.4.3 Mise en place du micro de gestion des assurances

Le même applique dans le micro de gestion des congés sera applique ici puisque les deux
micros sont développé avec le même Framework « NestJS ».

35
CHAPITRE III. SPRINT 1 : MISE EN PLACE DU L’ARCHITECTURE

Figure III.10 – Gestion des demandes d’assurances

Figure III.11 – Gestion des types des demandes d’assurances

Figure III.12 – Gestion des bordereaux d’assurances

III.4.4 Implémentation du « Api-Gateway »

Cette partie consiste à mettre le noyau de l’architecture en place pour cela on va commen-
cer par la création et configuration d’un nouveau projet ensuite on s’intéresse à l’implémentation

36
CHAPITRE III. SPRINT 1 : MISE EN PLACE DU L’ARCHITECTURE

de la passerelle et termine par l’ajout de la couche de sécurité.

III.4.4.1 Mise en place du « api-gateway »

De même pour cette partie on va créer un projet qui va jouer le rôle d’orchestrateur dans
l’architecture et on va le tester avec la même librairie.

Figure III.13 – Liste 1 web service « api-gateway »

Figure III.14 – Liste 2 web service « api-gateway »

III.4.4.2 Implémentation de la passerelle

Dans cette étape on va ajouter les configurations des micro-services déjà mis en place
pour que le « Api-Gateway » puisse identifier le requêtes reçu de la partie front vers quel
micro-service seront redirigé.

37
CHAPITRE III. SPRINT 1 : MISE EN PLACE DU L’ARCHITECTURE

Figure III.15 – Passerelle API

Comme le montre la figure ci-dessus chaque micro est considérer comme u service indé-
pendant et à ensemble des api qui lui correspond.

III.4.4.3 Mise en place de la couche sécurité

Dans cette partie on va s’intéresser à sécuriser notre architecture pour cela on va mettre
un système d’authentification classique avec le JWT token afin de sécuriser le api exposé par
le Gateway vers le client.

Figure III.16 – JWT authentication

Pour mieux sécurisé le système on a choisi d’ajouter un système de cache avec « Redis

38
CHAPITRE III. SPRINT 1 : MISE EN PLACE DU L’ARCHITECTURE

» qui va centraliser l’identité de l’utilisateur connecter de façon crypté. Le principe est que
chaque requête rediriger par le « Api-Gateway » n’aura aucune réponse jusqu’à le micro-service
termine la vérification qui consiste à :

X Extraire les informations concernant l’utilisateur de la requête.

X Décrypté ces information.

X Comparer l’information avec celle qui est stocker dans l’instance redis

X Envoyer une réponse.

III.5 Conclusion
Dans ce chapitre nous avons présenté la configuration effectuée ainsi que l’architecture
du système de notre projet, le prochain chapitre on va se concentrer sur la conception et
l’implémentation du premier micro-service.

39
 CHAPITRE IV

Sprint 2 : Gestion des personnels

CHAPITRE IV. SPRINT 2 : GESTION DES PERSONNELS

IV.1 Introduction
ans ce chapitre nous allons analyser et présenter en détails les différents « user stories » du
D sprint 1. On va commencer par l’élaboration du backlog du sprint et on va enchaîner par
la conception et la réalisation et finalement on va présenter le produit partiel livrer un travers
un ensemble des interfaces.

IV.2 Backlog du sprint

Le tableau ci-dessous décrit les différentes « user stories » de ce sprint qui se résume
globalement sur 3 axes :

X Gestion des personnels

X Gestion des départements

X Gestion des conjoints

40
CHAPITRE IV. SPRINT 2 : GESTION DES PERSONNELS

EBP ID_U User story Priorité

Estimation
En tant que administrateur je veux
1.1 ajouter des personnels et les affecter
Gestion des à un département.
2 2.5
personnels En tant que administrateur je veux
1.2
modifier les informations des personnels.
En tant que administrateur je veux
1.3
consulter la liste des personnels.
En tant que administrateur je veux
1.4
supprimer des personnels.

En tant que administrateur je veux

1.5
ajouter des départements.
Gestion des
En tant que administrateur je veux 1 1.75
départements 1.6
modifier des départements.
En tant que administrateur je veux
1.7
consulter des départements.
En tant que administrateur je veux
1.8
supprimer des départements.

En tant que administrateur je veux

1.9 ajouter des conjoints et les affecter à
Gestion des un personnel.
3 2
Conjoints En tant que administrateur je veux
1.10
modifier les informations des conjoints.
En tant que administrateur je veux
1.11
consulter les conjoints d’un personnel.
En tant que administrateur je veux
1.12
supprimer des conjoints.

Tableau IV.1 – Tableau 3

41
CHAPITRE IV. SPRINT 2 : GESTION DES PERSONNELS

IV.3 Analyse

IV.3.1 Diagramme du cas d’utilisation « Sprint 2 »

Figure IV.1 – Cas d’utilisation « sprint 2 »

IV.3.2 Diagramme du cas d’utilisation « Gestion des personnels »

La figure ci-dessous présente le diagramme de d’utilisation détaillé de la gestion des per-

sonnels.

42
CHAPITRE IV. SPRINT 2 : GESTION DES PERSONNELS

Figure IV.2 – Cas d’utilisation «Gestion des personnels»

IV.3.3 Description textuelle du cas d’utilisation «Gestion Person-

nels»

Le tableau ci-dessous présente la description textuelle du cas d’utilisation «Gestion Per-

sonnels».

43
CHAPITRE IV. SPRINT 2 : GESTION DES PERSONNELS

Cas d’utilisation Gestion Personnels

Acteur Administrateur
Précondition L’administrateur doit être authentifié
Le système affiche la liste des personnels.
Post-condition L’administrateur peut ajouter, modifier ou supprimer
des personnels.

-L’administrateur un personnel à partir de la

liste en cliquant sur bouton « modifier ».
-Le système affiche l’interface des détails du personnel.
Scénario nominal
-L’administrateur peut modifier ou supprimer le personnel
en cliquant sur le approprié.
-Le système affiche un message du succès.

-Un champ du formulaire de

modification ou ajout n’est pas rempli.
Scénario alternatif
-L’administrateur entre un email ou username déjà
affecter à un autre personnel.

Tableau IV.2 – Tableau 4

IV.3.4 Diagramme du cas d’utilisation « Gestion des conjoints »

La figure ci-dessous présente le diagramme de d’utilisation détaillé de la gestion des

conjoints.

44
CHAPITRE IV. SPRINT 2 : GESTION DES PERSONNELS

Figure IV.3 – Cas d’utilisation « Gestion des conjoints »

IV.3.5 Description textuelle du cas d’utilisation « Gestion Conjoints

»

Le tableau ci-dessous présente la description textuelle du cas d’utilisation « Gestion

Conjoints ».

45
CHAPITRE IV. SPRINT 2 : GESTION DES PERSONNELS

Cas d’utilisation Gestion Conjoints

Acteur Administrateur
Précondition L’administrateur doit être authentifié
Le système affiche la liste des conjoints pour le
personnel sélectionné.
Post-condition
L’administrateur peut ajouter, modifier ou supprimer
des conjoints.

-L’administrateur choisi un conjoint à partir de la liste en

cliquant sur bouton « modifier ».
-Le système affiche l’interface des détails du conjoint.
Scénario nominal
-L’administrateur peut modifier ou supprimer le conjoint
en cliquant sur le bouton approprié.
-Le système affiche un message du succès.

-Un champ du formulaire de modification ou ajout

Scénario alternatif
n’est pas rempli.

Tableau IV.3 – Tableau 5

IV.3.6 Diagramme du cas d’utilisation « Gestion des départements »

La figure ci-dessous présente le diagramme de d’utilisation détaillé de la gestion des dé-

partements.

46
CHAPITRE IV. SPRINT 2 : GESTION DES PERSONNELS

Figure IV.4 – Cas d’utilisation « Gestion des départements »

IV.3.7 Description textuelle du cas d’utilisation «Gestion départe-

ments»

Le tableau ci-dessous présente la description textuelle du cas d’utilisation « Gestion dé-

partements ».

47
CHAPITRE IV. SPRINT 2 : GESTION DES PERSONNELS

Cas d’utilisation Gestion départements

Acteur Administrateur
Précondition L’administrateur doit être authentifié
Le système affiche la liste des départements.
Post-condition L’administrateur peut ajouter, modifier ou supprimer
des départements.

-L’administrateur choisi un département à partir de la

liste en cliquant sur bouton « modifier ».
-Le système affiche l’interface des détails du département.
Scénario nominal
-L’administrateur peut modifier ou supprimer le département
en cliquant sur le bouton approprié.
-Le système affiche un message du succès.

-Un champ du formulaire de modification ou ajout n’est

Scénario alternatif
pas rempli.

Tableau IV.4 – Tableau 6

48
CHAPITRE IV. SPRINT 2 : GESTION DES PERSONNELS

IV.4 Conception

IV.4.1 Diagramme de séquence « Ajout Personnel »

Figure IV.5 – Diagramme séquence « ajout personnel »

49
CHAPITRE IV. SPRINT 2 : GESTION DES PERSONNELS

IV.4.2 Diagramme de classe candidate «gestion du personnel»

Figure IV.6 – Diagramme classe « Personnel »

IV.5 Test et réalisation

IV.5.1 Partie Personnels

Par défaut le système affiche l’interface de connexion :

Figure IV.7 – Interface de connexion

50
CHAPITRE IV. SPRINT 2 : GESTION DES PERSONNELS

En cliquant sur le bouton « Profile » le système affiche le profil qui regroupe l’ensemble
des informations divisé par catégories.

Figure IV.8 – Profil personnel

Dans son profil chaque utilisateur peut consulter les informations concernant ces conjoints.

Figure IV.9 – Interface gestion des conjoints

IV.5.2 Partie Administrateur

Concernant l’administrateur il peut visualiser la liste des utilisateurs.

51
CHAPITRE IV. SPRINT 2 : GESTION DES PERSONNELS

Figure IV.10 – Interface liste des personnels

L’administrateur peut modifier un personnel en cliquant sur la ligne qui contient l’utili-
sateur concerner le système affiche l’interface de modification :

Figure IV.11 – Interface modification personnel

Le responsable RH peut aussi ajouter un nouveau salarié en cliquant sur le buton « ajouter
employé » :

52
CHAPITRE IV. SPRINT 2 : GESTION DES PERSONNELS

Figure IV.12 – Interface ajouté personnel

L’administrateur peut aussi consulter plus des détails sur les personnels en cliquant sur
le l’icône « Plus », le système doit afficher l’interface contenant les détails de l’employé.

Figure IV.13 – Interface détails employé

IV.6 Conclusion
A la fin de ce chapitre nous avons arrivé à réaliser un produit partiel en tant que livrable
à notre client. Dans le prochain chapitre nous allons concentrer nos efforts pour réaliser un
nouveau sprint de la gestion des congés et des jours fériés.

53
 CHAPITRE V

Sprint 2 : Gestion des congés

CHAPITRE V. SPRINT 2 : GESTION DES CONGÉS

V.1 Introduction
ans ce chapitre nous allons se concentrer sur l’analyse, la conception et l’implémentation
D de la partie la plus critique dans notre projet, on va entamer le chapitre par l’élaboration
du backlog du sprint ensuite on va présenter l’analyse et la conception du sprint et on clôture
avec la partie réalisation.

V.2 Backlog du sprint

Le tableau ci-dessous décrit les différentes « user stories » de ce sprint qui se résume
globalement sur 3 axes :

X Gestion des demandes de congé

X Gestion du calendrier et des jours féries

X Mise en place de la couche sécurité

54
CHAPITRE V. SPRINT 2 : GESTION DES CONGÉS

EBP ID_U User story Priorité

Estimation
En tant que personnel je veux
1.1
ajouter une nouvelle demande de congé.
En tant que personnel je veux
Gestion des 1.2
modifier une demande de congé.
demandes 1 3.5
de congés En tant que personnel je veux
1.3
consulter mes demandes de congé.
En tant que personnel je veux
1.4
supprimer une demande de congé.
En tant que administrateur je veux
1.5
valider une demande de congé.
En tant que administrateur je veux
1.6
refuser une demande de congé.
En tant que administrateur je veux
1.7
affecter une demande de congé.

En tant que administrateur je veux

Paramétrage du 1.8
ajouter des jours fériés.
calendrier et
En tant que administrateur je veux
Implémentation 1.9 2 2.5
modifier des jours fériés.
du script du calcule
de solde de congé En tant que administrateur je veux
1.10
supprimer des jours fériés.
En tant que personnel je veux consulter
1.11
les jours fériés.
En tant que administrateur je veux
1.12 mettre à jour les soldes de congés
de façon automatique.

55
CHAPITRE V. SPRINT 2 : GESTION DES CONGÉS

Ajout et configuration du système

Configuration du système du cache 1.13
de cache redis. 3 1
redis et ajout du système de
Sécuriser les api avec un système
sécurité. 1.14
de sécurité personnalisé basé sur redis.

Tableau V.1 – Tableau 7

V.3 Analyse

V.3.1 Diagramme de cas d’utilisation

Figure V.1 – Cas d’utilisation « Sprint 2 »

V.3.2 Diagramme du cas d’utilisation « Gestion des demandes de

congé »

La figure ci-dessous présente le diagramme de d’utilisation détaillé de la gestion des de-

mandes de congé.

56
CHAPITRE V. SPRINT 2 : GESTION DES CONGÉS

Figure V.2 – Cas d’utilisation « Gestion des demandes de congé »

V.3.3 Description textuelle du cas d’utilisation « Gestion demandes

de congé »

Le tableau ci-dessous présente la description textuelle du cas d’utilisation « Gestion de-

mandes de congé ».

57
CHAPITRE V. SPRINT 2 : GESTION DES CONGÉS

Cas d’utilisation Gestion demandes de congé

Acteur Employé
Précondition L’employé doit être authentifié
Le système affiche l’interface de liste des demandes
du personnel.
Post-condition
L’employé peut ajouter, modifier supprimer des
demandes de congé.

- L’employé choisi une demande à partir de la liste

en cliquant sur bouton « modifier ».
-Le système affiche l’interface des détails de la demande.
Scénario nominal
- L’employé peut modifier ou supprimer la demande en
cliquant sur le bouton approprié.
-Le système affiche un message du succès.

-Un champ du formulaire de modification ou ajout n’est

Scénario alternatif
pas rempli.

Tableau V.2 – Tableau 8

V.3.4 Diagramme du cas d’utilisation « Gestion des jours fériés »

La figure ci-dessous présente le diagramme de d’utilisation détaillé de la gestion des jours

fériés.

58
CHAPITRE V. SPRINT 2 : GESTION DES CONGÉS

Figure V.3 – Cas d’utilisation « Gestion des jours fériés »

V.3.5 Description textuelle du cas d’utilisation « gestion des jours

fériés »

Le tableau ci-dessous présente la description textuelle du cas d’utilisation « Gestion des

jours fériés».

59
CHAPITRE V. SPRINT 2 : GESTION DES CONGÉS

Cas d’utilisation Gestion des jours fériés

Acteur Administrateur
Précondition L’administrateur doit être authentifié
Le système affiche le calendrier de l’entreprise.
L’administrateur peut ajouter, modifier ou supprimer
Post-condition
des jours fériés.
Le système met à jour les soldes de congés.

-L’administrateur choisi un jour férié à partir du

calendrier en cliquant sur bouton « modifier ».
-Le système affiche l’interface des détails du jour férié.
Scénario nominal -L’administrateur peut modifier ou supprimer le jour
férié en cliquant sur le bouton approprié.
-Le système affiche un message du succès.
-Le système met à jours les soldes de congé.

-Un champ du formulaire de modification ou ajout n’est

Scénario alternatif
pas rempli.

Tableau V.3 – Tableau 9

60
CHAPITRE V. SPRINT 2 : GESTION DES CONGÉS

V.4 Conception

V.4.1 Diagramme de séquence « modification jour férié »

Figure V.4 – Diagramme de séquence « Modifier jour férié »

61
CHAPITRE V. SPRINT 2 : GESTION DES CONGÉS

V.4.2 Diagramme de classe candidate « Gestion des congés »

Figure V.5 – Diagramme de séquence « modification jour férié »

V.5 Test et réalisation

En faisant laissant avec le module précédant chaque utilisateur crée le système va lui af-
fecter l’ensemble des types de congé avec leurs soldes initial. Dans ce module l’administrateur
et l’employé ont presque les même droit sauf que l’administrateur peut affecter une demande
de congé pour un employé du coup ils auront presque les même interfaces.

L’administrateur peut consulter la liste des demandes de congés des utilisateurs en cliquant sur
la rubrique congé :

62
CHAPITRE V. SPRINT 2 : GESTION DES CONGÉS

Figure V.6 – Liste des demandes de congé

A ce niveau le responsable Rh peut soit valider une demande soit la refuser en cliquant
sur les butons « valider/refuser », il peut aussi supprimer une demande ou bien la modifier :

Figure V.7 – Modifier demande de congé

Il peut aussi affecter une demande de congé pour un utilisateur la valider en cas ou
l’employé n’as pas justifié son absence :

63
CHAPITRE V. SPRINT 2 : GESTION DES CONGÉS

Figure V.8 – Affecter une demande de congé

Pour bien collaborer entre les membres d’équipe les employés ont une visibilité sur toutes
les demandes des congés et les jours fériés dans le calendrier d’entreprise :

Figure V.9 – Calendrier de l’entreprise

64
CHAPITRE V. SPRINT 2 : GESTION DES CONGÉS

Seul l’administrateur peut gérer le calendrier :

Figure V.10 – Ajout jour férié

V.6 Conclusion
Le résultat de ce chapitre est tout un système de gestion de congé qui prend en consi-
dération plusieurs conditions, ce produit sera livrer à notre client à fin de le valider. Dans le
prochain chapitre on va concentrer sur la réalisation de la dernière partie du notre système
d’information.

65
 CHAPITRE VI

Sprint 3 : Gestion des Assurances

CHAPITRE VI. SPRINT 3 : GESTION DES ASSURANCES

VI.1 Introduction
ans ce chapitre nous allons mettre en place le dernier module du notre projet et livrer
D notre produit pour le client. Nous allons commencer par la présentation du backlog du
sprint par la suite nous allons nous concentrer sur l’analyse et la conception de ce sprint et on
termine par la présentation du quelques interfaces de notre application.

VI.2 Backlog du sprint

Le tableau ci-dessous décrit les différentes « user stories » de ce sprint qui se résume
globalement sur 2 axes :

X Gestion des demandes d’assurance

X Génération des bordereaux d’assurances et mise en place de la couche de sécurité

EBP ID_U User story Priorité

Estimation
Gestion des de- 1.1 En tant que personnel je veux
mandes d’assu- ajouter une nouvelle demande
rances d’assurance

1.2 En tant que personnel je veux 1 2

modifier une demande d’assu-
rance

1.3 En tant que personnel je veux

consulter mes demandes d’as-
surance

1.4 En tant que personnel je veux

supprimer une demande d’as-
surance

66
CHAPITRE VI. SPRINT 3 : GESTION DES ASSURANCES

1.5 En tant que administrateur

je veux valider une demande
d’assurance

1.6 En tant que administrateur je

veux réclamer une demande
d’assurance

Génération des 1.7 Le système doit générer un

bordereaux d’as- bordereau chaque 15 jours
surances et mise 2 1
en place de la
couche sécurité

1.8 Le système doit mettre à jour

les bordereaux en cas d’ajout
d’une nouvelle assurance

1.9 Ajout et configuration du sys-

tème de cache redis

1.10 Sécuriser les api avec un sys-

tème de sécurité personnalisé
basé sur redis

Tableau VI.1 – Tableau 10

67
CHAPITRE VI. SPRINT 3 : GESTION DES ASSURANCES

VI.3 Analyse

VI.3.1 Diagramme du cas d’utilisation« Sprint 3»

Figure VI.1 – Diagramme du cas d’utilisation « Sprint 3»

68
CHAPITRE VI. SPRINT 3 : GESTION DES ASSURANCES

VI.3.2 Diagramme du cas d’utilisation«Gestion des demandes d’as-

surance»

Figure VI.2 – Diagramme du cas d’utilisation « Gestion des demandes d’assurance»

VI.3.3 Description textuelle du cas d’utilisation«Gestion demandes

d’assurance»

Le tableau ci-dessous présente la description textuelle du cas d’utilisation « Gestion de-

mandes d’assurance ».

69
CHAPITRE VI. SPRINT 3 : GESTION DES ASSURANCES

Cas d’utilisation Gestion demandes d’assurance

Acteur Employé
Précondition L’employé doit être authentifié
Le système affiche l’interface de liste des
demandes du personnel.
Post-condition
L’employé peut ajouter, modifier ou supprimer
des demandes d’assurance.

- L’employé choisi une demande à partir de la liste

en cliquant sur bouton « modifier ».
-Le système affiche l’interface des détails de la demande.
Scénario nominal
- L’employé peut modifier ou supprimer la demande
en cliquant sur le bouton approprié.
-Le système affiche un message du succès.

-Un champ du formulaire de modification ou ajout n’est

Scénario alternatif
pas rempli.

Tableau VI.2 – Tableau 11

70
CHAPITRE VI. SPRINT 3 : GESTION DES ASSURANCES

VI.4 Conception

VI.4.1 Diagramme de séquence«Modification demande d’assurance»

Figure VI.3 – Diagramme de séquence « modification demande d’assurance »

71
CHAPITRE VI. SPRINT 3 : GESTION DES ASSURANCES

VI.4.2 Diagramme de classe candidate«Gestion des assurances»

Figure VI.4 – Diagramme de classe candidate « Gestion des assurances»

VI.5 Test et réalisation

Ce module est généralement réalisé pour les salarié l’intervention de l’administrateur sera
seulement pour la validation des demandes d’assurances.

VI.5.1 Partie Employé

Le salarié peut consulter la liste des demandes d’assurances :

72
CHAPITRE VI. SPRINT 3 : GESTION DES ASSURANCES

Figure VI.5 – Liste des demandes d’assurance

L’employé peut aussi voir plus des détails pour une demande en cliquant sur le bouton
détails :

Figure VI.6 – Détails demande d’assurance

Chaque personnel peut bien sur modifier ou supprimer une demande d’assurance en cli-
quant sur le bouton modifier ou bien sur l’icône supprimer dans la liste des assurances.

73
CHAPITRE VI. SPRINT 3 : GESTION DES ASSURANCES

VI.5.2 Partie Responsable RH

Le responsable RH peut ajouter des demandes aussi mais son rôle principale et la gestion
de la validation des demandes :

Figure VI.7 – Validation demande d’assurance

Il peut aussi télécharger les bordereaux générer automatiquement chaque 15 jours par le
système en cliquant sur le bouton « Télécharger Bordereau » :

Figure VI.8 – Télécharger bordereau

74
CHAPITRE VI. SPRINT 3 : GESTION DES ASSURANCES

VI.6 Conclusion
En clôturant ce chapitre nous avons réalisé un produit finit qui répond à l’ensemble
des besoins fixé dans le cahier des charges et qui va être livré à notre client qui peut tester
maintenant les différant scénarios de l’application.

75
 Conclusion générale

La majorité des applications de gestion des ressources humaines qui existent dans la mar-
ché sont soit payantes soit incomplète dans ce cadre notre projet est réaliser au sein de la société
Fondative pour laquelle nous avons créé la première version de son système d’information.

Ce projet était livrer dans les délais fixer par nos encadrants universitaire et professionnel mal-
gré les difficultés technique qu’on à trouver dans sa réalisation.

Ce projet nous a donné l’opportunité de maitriser plusieurs nouvelles technologies comme Sym-
fony 4, NestJS, ReactJS et plusieurs autres et aussi nous avons travaillé avec une équipe pro-
fessionnel qui nous à guider, finalement ce projet étais une très bonne expérience dans notre
carrière.

Perspectives
Des nouveaux modules vont être ajoutés pour ce projet en tant que continuité du système
d’information et d’autres améliorations vont parvenir à notre application.

L’architecture qu’on a mis on place va être amélioré est contribué en tant que la première so-
lution d’architecture micro-services pour le Framework Symfony.

76