République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

École Supérieur Privée d’ingénierie et de technologie

TEK-UP

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques

Spécialité : Génie Logiciel et Systèmes d’Information

Réalisé par

Ali MEHRI

Conception et développement d’une application

web de gestion des ressources humaines

Encadrant professionnel : Monsieur Prénom NOM Ingénieur Informatique

Encadrant académique : Monsieur Wissem Eljaoued Maître Assistant

Année Universitaire 2020 - 2021

J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.

Encadrant professionnel, M. Oussema SLIMANI

Signature et cachet

J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.

Encadrant académique, M. Wissem ELJAOUED

Signature
Dédicace

Je dédie ce travail à :

Mes chers parents, ma soeur, mes frères , mes amis, à mes enseignants et à toute ma famille,
sans leurs encouragements et sacrifices, rien de cela n’aurait été possible.

Toute ma reconnaissance...

ii
Remerciements

Il est particulièrement agréable, avant de présenter cette oeuvre, d’exprimer

toute ma gratitude envers les personnes qui de près ou de loin m’ont apporté
leur aide inestimable lors de la réalisation de ce projet.

Je tiens tout particulièrement à remercier mes tuteurs de stage dans la société

Xtendplex ,

M. Wael MERSNi et M. Oussema SLIMANI.

J’adresse, mes sincères remerciements à mon encadrant académique,

M. Wissem ELJAOUED,

Je tiens aussi à remercier tous les membres du jury pour avoir bien voulu

examiner et juger ce travail.

Merci.

iii
Table des matières

Introduction générale 1

1 Cadre du projet 3
1.1 Cadre général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Contexte et Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Étude de l’application Open Time Clock . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Étude de l’application IceHRM . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.3 Étude de l’application snapHRM . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Synthèse pour le choix de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Méthodologie de gestion de projet à adopter . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.1 Méthodologie de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.2 Les rôles dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.3 Méthodologie de conception à adopter . . . . . . . . . . . . . . . . . . . . . . . 13

2 Analyse et spécification des besoins 14

2.1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Spécification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.2 Spécification des besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . 18
2.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Planification de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Répartition des releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.2 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Les patrons de conception utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.1 Patrons de création . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.2 Patrons structurels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.3 Patrons comportementaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.4 Patron d’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

iv
 2.6 Maquette du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6.1 Captures des interfaces de maquette . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6.2 Schéma de navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7 Difficultés rencontrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.8 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8.1 Outils de gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8.2 Framework de développement et de tests . . . . . . . . . . . . . . . . . . . . . . 30
2.8.3 Système de gestion de base de données . . . . . . . . . . . . . . . . . . . . . . . 31

3 Release 1 : Gestion de l’entreprise et des comptes 32

3.1 Sprint 1 :Module gestion de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.1 Objectifs du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.2 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.3 Spécification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.5 Diagrammes dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 sprint 2 :Module gestion des utilisateurs et authentification . . . . . . . . . . . . . . . 39
3.2.1 Objectifs du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.2 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.3 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.4 Spécification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.5 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.6 Diagrammes dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.7 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 Release 2 : Gestion d’activité de ressources humaines 52

4.1 sprint 3 :Module gestion des Congés et des permission des sorties . . . . . . . . . . . . 53
4.1.1 Objectifs du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1.2 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1.3 Spécification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1.4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1.5 Diagrammes dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.1.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Sprint 4 :Module gestion de présence et Compte rendu d’activité . . . . . . . . . . . . 63

v
 4.2.1 Objectifs du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.2 Backlog du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.3 Spécification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2.5 Diagrammes dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5 Release 3 : Gestion d’achat et dépenses 70

5.1 Sprint 5 :Module gestion d’achats et Dépenses . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.1 Objectifs du sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.2 Backlog du sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.3 Spécification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 72
5.1.4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1.5 Diagrammes dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.1.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2 sprint 6 :Réalisation du dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.1 Objectifs du sprint 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.2 Backlog du sprint 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.3 Spécification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2.4 Analyse du dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Conclusion générale 86

Bibliographie 87

Webographie 88

vi
Table des figures

1.1 Carte filiale de XtendPlex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Interface du site Open Time Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Interface du site iceHRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Interface de l’application snapHRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Cycle de vie de la méthodologie SCRUM [1] . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Diagramme cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Diagramme de classe global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Architecture logique Back-End (Spring-Boot) . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Architecture logique Front-End (Angular)[3] . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.7 Interface "S’authentifier" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.8 Interface "Dashboard" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.9 Interface "Présence" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.10 Schéma de navigation de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.11 Schéma de navigation d’un stagiaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.12 Schéma de navigation d’un consultant . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.13 Schéma de navigation d’un employé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.14 Schéma de navigation d’un responsable RH . . . . . . . . . . . . . . . . . . . . . . . . 28
2.15 Schéma de navigation d’un manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.16 Logo Bitbucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.17 Logo Bitbucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.18 Logo Discord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.19 Logo Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.20 Logo springBoot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.21 Logo postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.22 Logo MySql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1 Diagramme de cas d’utilisation "Gestion de l’entreprise" . . . . . . . . . . . . . . . . . 34

3.2 Diagramme de classe "Gestion de l’entreprise" . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Diagramme de séquence objet "ajout d’entreprise" . . . . . . . . . . . . . . . . . . . . 36

vii
Table des figures

3.4 interface de création de compte entreprise 1.0 . . . . . . . . . . . . . . . . . . . . . . . 36

3.5 interface de création de compte entreprise 1.1 . . . . . . . . . . . . . . . . . . . . . . . 37
3.6 interface de création de compte entreprise 1.2 . . . . . . . . . . . . . . . . . . . . . . . 37
3.7 Page paramètre d’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.8 interface poste et département . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.9 interface ajout du poste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.10 interface profil entreprise fixer le nombre de jours de congé . . . . . . . . . . . . . . . 39
3.11 Diagramme de cas d’utilisation "Gestion des utilisateurs" . . . . . . . . . . . . . . . . 41
3.12 Diagramme de classe "Gestion des utilisateurs" . . . . . . . . . . . . . . . . . . . . . . 42
3.13 Diagramme de séquence objet "Authentification" . . . . . . . . . . . . . . . . . . . . . 43
3.14 Diagramme de séquence système "Ajout utilisateur" . . . . . . . . . . . . . . . . . . . 44
3.15 Diagramme d’activité "Réinitialisation du mot de passe" . . . . . . . . . . . . . . . . . 45
3.16 interface équipe par département . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.17 Formulaire d’ajout d’utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.18 L’employé est ajouté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.19 L’email contenant les coordonnées de connexion . . . . . . . . . . . . . . . . . . . . . . 47
3.20 Profil utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.21 Interface gestion du profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.22 Changement du mot de passe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.23 Page équipe de l’employé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.24 Modifier employé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.25 Changement du rôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.26 Page équipe du responsable RH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1 Diagramme de cas d’utilisation "Gestion de congé et autorisation" . . . . . . . . . . . 55

4.2 Diagramme de classe "Gestion de congé et autorisation . . . . . . . . . . . . . . . . . . 56
4.3 Diagramme de séquence système "Traiter une demande de congé" . . . . . . . . . . . . 57
4.4 Diagramme d’état transition "État d’une demande" . . . . . . . . . . . . . . . . . . . . 58
4.5 interface demande de congé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6 formulaire de demande de congé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.7 demande de congé ajoutée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.8 interface demande d’autorisation de sortie . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.9 formulaire demande d’autorisation de sortie . . . . . . . . . . . . . . . . . . . . . . . . 61
4.10 interface approbation en attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

viii
4.11 la demande est acceptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.12 interface vue global des congés par utilisateur . . . . . . . . . . . . . . . . . . . . . . . 62
4.13 historique des demandes de sortie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.14 Diagramme de cas d’utilisation "Gestion de présence et compte rendu d’activité" . . . 65
4.15 Diagramme de classe "Gestion de présence" . . . . . . . . . . . . . . . . . . . . . . . . 66
4.16 Diagramme de séquence objet "marquer l’heure d’entrée" . . . . . . . . . . . . . . . . 67
4.17 interface du pointage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.18 Liste du présence après le ClockIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.19 Interface du présence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.20 Compte rendu d’activité du Responsabe RH ’Ali’ . . . . . . . . . . . . . . . . . . . . . 69
4.21 Compte rendu d’activité de l’employé ’Mourad’ . . . . . . . . . . . . . . . . . . . . . . 69

5.1 Diagramme de cas d’utilisation "Gestion d’achats et dépenses" . . . . . . . . . . . . . 72

5.2 Diagramme de classe "Gestion d’achats et dépenses" . . . . . . . . . . . . . . . . . . . 73
5.3 Diagramme de séquence système "traiter une demande d’achat" . . . . . . . . . . . . . 74
5.4 Formulaire d’ajout de fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.5 Formulaire d’ajout d’une dépense périodique . . . . . . . . . . . . . . . . . . . . . . . . 75
5.6 La nouvelle liste des dépenses périodiques . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.7 Interface demande d’achat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.8 Passer une demande d’achat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.9 la nouvelle liste des demandes d’achats . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.10 interface approbation en attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.11 Demande d’achat acceptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.12 Diagramme de cas d’utilisation "Dashboard" . . . . . . . . . . . . . . . . . . . . . . . 80
5.13 Dashboard stagiaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.14 Dashboard Employé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.15 Demande de congé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.16 Demande d’achat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.17 Dashboard Responsable RH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.18 Dashboard Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.19 Statistique des achats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

ix
Liste des tableaux

1.1 Points forts et points faibles de l’application Open Time Clock . . . . . . . . . . . . . 8

1.2 Points forts et points faibles de l’application IceHRM . . . . . . . . . . . . . . . . . . . 9
1.3 Points forts et points faibles de l’application SnapHRM . . . . . . . . . . . . . . . . . . 11

2.1 Répartition des releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2 Backlog du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1 Backlog du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2 Backlog du Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.1 Backlog du Sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2 Backlog du Sprint 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

x
Liste des abréviations

— API = Application Programming Interface

— DAO = Data Access Object

— DI = Dependency Injection

— DTO = Data Transfer Object

— GLSI = Génie Logiciel et Système d’Information

— GRH = Gestion des Ressources Humaines

— HRM = Human Ressource Management

— HTTP = Hypertext Transfer Protocol

— IT = Information Technology

— JSON = JavaScript Object Notation

— JWT = JSON Web Token

— REST = Representational state transfer

— RH = Ressources Humaines

— UML = Unified Modeling Language

xi
Introduction générale

L’essor de l’informatique et des technologies numériques a profondément bouleversé nos sociétés

et, transcende l’ensemble des activités humaines. De nos jours, la majorité de ces activités a été
simplifiée et automatisée grâce à l’informatique. Ce phénomène, parfois qualifié de « révolution numérique
», permet aujourd’hui le traitement et l’échange d’informations entre les individus, grâce à des logiciels
et des réseaux informatiques.
Ainsi, les entreprises du monde entier utilisent aujourd’hui des logiciels de gestion, leur permettant
d’effectuer des tâches complexes rapidement.
C’est dans ce contexte que le projet « Xhrm » a vu le jour. Ce projet propose une solution de
gestion des ressources humaines, utilisable en tout lieu. Le projet « Xhrm » consiste en une application,
permettant de mettre à disposition des clients (les entreprises) un outil de gestion de leurs ressources
humaines (RH), présentant des fonctionnalités diverses et utiles en toutes circonstances.
L’objectif de cette application est, d’une part, de simplifier et d’accélérer le processus RH, et
d’autre part, d’améliorer la communication entre les employés (la communication au sein d’une même
entreprise) en la rendant plus fluide et flexible.
L’entreprise de services informatiques XtendPlex, a à cœur ces valeurs d’agilité et d’amélioration
des processus RH, et a donc accepté d’allouer toute la logistique nécessaire à la réalisation de ce projet.
Le présent rapport sera organisé de la manière suivante :
• Dans un premier chapitre, nous présenterons le cadre du projet.Il sera constitué d’une présentation
du contexte général ainsi que d’une étude de l’existant, réalisée à partir de trois projets similaires.
Ce premier chapitre contiendra aussi une présentation de la méthode de gestion de projet et de
la méthode de conception que nous avons choisi d’adopter.

• Le second chapitre présentera une analyse et une spécification des besoins, fonctionnels et non
fonctionnels, réalisés à partir de l’identification des acteurs de l’application. Il exposera aussi
le diagramme de cas d’utilisation globale, ainsi que le diagramme de classes de l’application, la
répartition des releases et l’architecture de l’application.

• Le troisième chapitre portera sur la Release 1 : « Gestion de l’entreprise et des comptes », qui a
consisté en la réalisation d’un Sprint 1 portant sur la création du compte de l’entreprise, compte
du Manager et la gestion des postes et des départements, ainsi que la réalisation d’un Sprint 2,
portant sur la gestion des utilisateurs, l’authentification et la gestion des rôles.

• Dans un quatrième chapitre, nous présenterons la Release 2, « Gestion d’activité de ressources

humaines », qui comprend le Sprint 3, portant sur la gestion des demandes de congé et des

1
Introduction générale

demandes d’autorisation de sortie, et le Sprint 4, portant sur la gestion de présence, le pointage

et le compte-rendu d’activité.

• Enfin, dans un cinquième et dernier chapitre, nous présenterons la Release 3, « Gestion d’achat et
de dépenses », comprenant le Sprint 5, portant sur la gestion des demandes d’achats, la gestion
des fournisseurs et la gestion des dépenses périodiques, ainsi que le Sprint 6, portant sur la
réalisation d’un Dashboard de suivi des dépenses et de la présence.

2
 Chapitre 1

Cadre du projet

Plan
1 Cadre général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Synthèse pour le choix de la solution . . . . . . . . . . . . . . . . . . . . . . 11

4 Méthodologie de gestion de projet à adopter . . . . . . . . . . . . . . . . . . 12

Chapitre 1. Cadre du projet

Introduction

Dans ce chapitre, nous situons le projet dans son cadre global. Nous commençons par présenter
l’entreprise dans laquelle nous avons réalisé notre stage de projet de fin d’étude. Puis, nous expliquons
les objectifs du projet et nous analysons trois applications web existantes. Enfin, nous présentons la
méthodologie de projet que nous adoptons ainsi que l’environnement de travail.

1.1 Cadre général du projet

1.1.1 Présentation de l’organisme d’accueil

1.1.1.1 XtendPlex Group

L’entreprise XtendPlex Group fondée en 2014 est au carrefour de la technologie des systèmes
d’information, du conseil et de la finance de marché. Grâce à une stratégie claire, elle propose une
assistance globale et cohérente aussi bien en conseil qu’en formation et expertise.

Le groupe est basé à Tunis et dispose de bureaux à Paris et kowloon

Figure 1.1 : Carte filiale de XtendPlex

1.1.1.2 Service

L’entreprise XtendPlex Group fournit une expertise et des techniques fonctionnelles, guidée
en permanence par l’envie de résoudre les problèmes des entreprises de ses clients en fournissant des
solutions et des conseils qui peuvent être classifiés selon trois axes : [1]

4
Chapitre 1. Cadre du projet

• Solutions publicitaires : Filière qui..

• Consulting : A travers...

• Produits et services pour la Finance et l’IT : De la direction générale..

1.1.2 Contexte et Objectifs du projet

1.1.2.1 Contexte

La gestion des ressources humaines (HRM) occupe une place importante dans l’entreprise car
elle améliore la communication entre les différents intervenants et favorise une parfaite compréhension
de l’entreprise, favorisant ainsi le développement des organisations professionnelles. Dans ce contexte
l’idée de notre projet fin d’étude est de concevoir et mettre en place une application de gestion des
ressources humaines XHRM

1.1.2.2 Objectifs du projets

L’enjeu principal de notre application est la gestion des ressources humaines est d’assurer toutes
les tâches qui permettent d’accompagner et d’aider les différents services internes en matière de gestion
des ressources humaines et non seulement ça elle permet aussi à faciliter le travail du département
finance grâce au module achat et dépense.
Il s’agit aussi d’un module de gestion des achats et dépenses, ainsi qu’une partie administrative.
Le soutien des collaborateurs dans leurs conditions de travail dans leurs vies dans l’entreprise
est un objectif essentiel et d’offrir au manager une vue globale.

1.2 Étude de l’existant

L’étude de l’existant est une étape indispensable, elle permet d’extraire les forces et les faiblesses
des applications existantes. Cela nous aidera à la réalisation de notre projet. Nous avons choisi
d’analyser trois applications existantes.

• L’application « Open Time Clock »

• L’application « IceHRM »

• L’application « SnapHRM »

1.2.1 Étude de l’application Open Time Clock

Adresse (URL) : https ://www.opentimeclock.com/

5
Chapitre 1. Cadre du projet

1.2.1.1 Description

Cette application a pour but le suivi des pointages, des présences, des congés payés ainsi que la
gestion des comptes des employés, la gestion des factures, la gestion des événements... Le public ciblé
de cette application est les entreprises (petite, moyenne ou grande entreprise).
Il existe une application pour le Web et une version pour le mobile (Android/iOS).

• remarque : La société ‘Xtendplex’ utilise l’application ‘Open time Clock’ comme outil de
gestion des ressources humaines. La question qui se pose pourquoi xtendplex veut changer cette
application ?

• L’application "Open time Clock" n’est pas bien sécurisée puisqu’il existe des sessions avec
login seulement et sans mot de passe.

• L’entreprise veut développer une application avec accès gratuit pour les startups et les mini
entreprises.

• Cette application manque des fonctionnalités comme la gestion des achats et des dépenses,
Dashboard manager. . .

• L’entreprise Xtendplex veut avoir un environnement intérieur qui s’adapte à leurs besoins.

• Interface du site : C’est l’interface d’accueil qui contient la description du site.

Figure 1.2 : Interface du site Open Time Clock

1.2.1.2 Étude fonctionnelle

Les principales fonctionnalités proposées par l’application, tout en les reliant aux acteurs qui
en bénéficient.

• Employé :

— Pointer (clock in/clock out) possibilité de pointer en utilisant un nom, la reconnaissance

faciale, un pin ou un QR code.

6
Chapitre 1. Cadre du projet

— Consulter ses heures de travail.

— Consulter sa fiche de paie (les heures payées).

— Échanger des messages avec toute l’équipe du travail.

— Modifier son profil.

— Enregistrer sa localisation.

— Consulter les quarts de travail programmés.

— Demander une autorisation de sortie/un congé.

• Administrateur :

— Gérer ses employés ainsi que les managers (ajouter, supprimer et modifier des profils).

— Consulter les absences et les retards des employés et des managers.

— Consulter les fiches de paie.

— Gérer les quarts de travail programmés.

— Gérer les départements (ajouter, supprimer et modifier).

— Gérer les autorisations de sorties/congés.

— Consulter les absences.

— Consulter la localisation lors du pointage.

1.2.1.3 Points forts et points faibles

Points forts Points faibles

— Facile à utiliser.

— Facile à installer.
— Le site n’est pas sécurisé.
— Application gratuite/payante.
— La composition des différentes interfaces
— Un temps de chargement moyen des pages
du site n’est pas homogène.
(Les liens s’ouvrent rapidement).
— L’application dispose deux acteurs
— Les employés peuvent utiliser un
seulement
ordinateur, tablette/iPad et smartphone
(Android and iPhone) pour le pointage.

7
Chapitre 1. Cadre du projet

Points forts Points faibles

Tableau 1.1 : Points forts et points faibles de l’application Open Time

Clock

1.2.2 Étude de l’application IceHRM

Adresse (URL) : http ://icehrm.com

1.2.2.1 Description

‘ICE HRM’ est un système de gestion des ressources humaines qui souhaite simplifier la gestion
des ressources humaines. Il existe une version Web et une version mobile (Android/iOS).

• Interface du site : La figure 1.3 représente l’interface d’accueil du site vitrine IceHRM.

Figure 1.3 : Interface du site iceHRM

1.2.2.2 Étude fonctionnelle

Les principales fonctionnalités offertes par l’application, tout en les associant aux acteurs qui
en bénéficient.

• Manager :

— Gérer les employés (ajouter, supprimer et modifier les profils des employés).

— Gérer les fiches de paie.

— Gérer et consulter les congés (approuver ou ignorer une demande de congé).

— Gérer les candidatures.

— Gérer les formations.

— Gérer les clients (enregistrer les informations des clients pour chaque projet).

8
Chapitre 1. Cadre du projet

— Gérer les départements (ajouter ou supprimer des départements).

— Consulter les absences.

— Suivre les candidatures.

— Suivre l’avancement des projets.

— Gérer les dépenses (approuver ou ignorer les dépenses enregistrées par les employés).

• Employé :

— Consulter ses absences.

— Demander une autorisation de sortie/un congé.

— Consulter les événements.

— Demander une autorisation pour participer à un événement.

— Échanger des messages (avec toute l’équipe).

— Modifier son profil.

— Suivre les projets sur lesquels il travaille.

— Enregistrer ses dépenses.

1.2.2.3 Points forts et points faibles

Points forts Points faibles

— Application payante.
— Les liens s’ouvrent rapidement.
— La page d’accueil est trop compliquée.
— L’employé ou l’administrateur peuvent
— L’application dispose deux acteurs
naviguer facilement.
seulement

Tableau 1.2 : Points forts et points faibles de l’application IceHRM

1.2.3 Étude de l’application snapHRM

1.2.3.1 Description

’Snaphrm’ est une application de gestion des ressources humaines pour les petites et moyennes
entreprises, avec lesquelles vous pouvez gérer les congés, les présences, la participation aux événements,
la masse salariale, les dépenses, les projets ...
Il existe une version Web et une version mobile (Android/iOS).

9
Chapitre 1. Cadre du projet

• Interface de l’application : La figure 1.4 représente l’interface d’accueil de l’application qui

contient un dashboard qui présente toutes les fonctionnalités pour l’admin.

Figure 1.4 : Interface de l’application snapHRM

1.2.3.2 Étude fonctionnelle

Les principales fonctionnalités proposées par l’application, tout en les reliant aux acteurs qui
en bénéficient.

• Manager :

— Gérer son profil.

— Gérer les employés (ajouter, supprimer et modifier les profils des employés).

— Gérer les évènements et les vacances.

— Gérer les fiches de paie.

— Gérer et consulter les congés (approuver ou ignorer une demande de congé).

— Gérer les départements (ajouter ou supprimer des départements).

— Consulter les absences.

— Suivre l’avancement des tâches de chaque employé.

— Gérer les dépenses (approuver ou ignorer les dépenses enregistrées par les employés).

— Gérer les candidatures.

• Employé :

— Gérer son profil (consulter et modifier ses informations).

— Pointer (en cliquant).

— Consulter ses absences.

— Demander une autorisation de sortie/un congé.

10
Chapitre 1. Cadre du projet

— Consulter les évènements (calendrier).

— Demander une autorisation pour participer à un événement.

— Échanger des messages (avec toute l’équipe).

— Suivre les projets sur lesquels il travaille.

— Enregistrer ses dépenses.

— Consulter les membres de chaque département.

1.2.3.3 Points forts et points faibles

Points forts Points faibles

— Application payante (il y a une version

— L’employé ou l’administrateur peuvent gratuite si le nombre d’employés ne
naviguer facilement. dépasse pas 5

— Application simple et facile à utiliser. — L’application dispose deux acteurs

seulement

Tableau 1.3 : Points forts et points faibles de l’application SnapHRM

1.3 Synthèse pour le choix de la solution

Après l’analyse de trois applications, nous avons conclu que l’application de la gestion des
ressources humaines doit répondre aux besoins suivants :

• Utiliser le maximum possible d’interface simple et bien organiser pour faciliter l’expérience de
l’utilisateur.

• Assurer que toutes les fonctionnalités seront gratuites.

• Répartir l’application selon le système des rôles.

• Faciliter le travail d’un responsable des ressources humaines et aider l’administrateur (PDG de
l’entreprise) à consulter la situation de son entreprise.

• Réaliser une application spécifique ciblant la gestion des ressources humaines d’une mini entreprise
ou d’une startup répondant à certains besoins fonctionnels.

11
Chapitre 1. Cadre du projet

1.4 Méthodologie de gestion de projet à adopter

1.4.1 Méthodologie de SCRUM

Nous recherchons toujours la méthode la plus efficace et la plus rapide de mettre en œuvre
notre projet. Pour cela, nous utilisons des méthodes agiles. Scrum est le cadre agile le plus simple.
Scrum garantit la meilleure vue d’ensemble de notre projet et vise à réduire les difficultés, telles que
le manque de planification, le travail est effectué à travers un cycle court appelé Sprint. Dans Sprint,
notre équipe travaille à partir d’une liste d’éléments appelée Backlog" [B1].
Nous avons choisit la méthodologie SCRUM qui fait partie de la méthodologie Agile pour
différentes raisons parmi lesquelles :

• La transparence.

• La tolérance aux différents changements.

• Les besoins ne sont pas bien connus au départ ils ont été changés par la suite.

• La présence du mêlée quotidien qui permet de bien résoudre les problèmes et de trouver des
solutions rapidement.

La figure 1.5 représente le parcours de la méthodologie de SCRUM.

Figure 1.5 : Cycle de vie de la méthodologie SCRUM [1]

1.4.2 Les rôles dans SCRUM

La méthodologie d’agile SCRUM implique trois rôles principaux qui sont :

• Product owner : C’est le représentant des clients et des utilisateurs et c’est lui qui est l’expert
métier de l’équipe. C’est à lui de définir et prioriser la liste des fonctionnalités du produit et

12
Chapitre 1. Cadre du projet

effectuer l’analyse nécessaire pour la prise des décisions.

• Scrum master : C’est le garant de la méthodologie de SCRUM, qui garantit que tout le
monde peut maximiser ses capacités en éliminant les obstacles, et en protégeant l’équipe des
perturbations externes. Par ailleurs il garantit que l’équipe chargée du projet adopte les principes
et les valeurs de SCRUM.

• Équipe : L’équipe rassemble tous les rôles généralement nécessaires à un projet, elle est organisée
et reste inchangée pendant la durée d’un sprint.

1.4.3 Méthodologie de conception à adopter

La modélisation du système d’information a pour but de permettre aux entreprises de communiquer

avec des services ou des entreprises spécialisées dans l’informatique et de décrire leurs opérations et
leurs besoins. Le modèle peut être résumé de manière claire et compréhensible pour tout le monde.
Pour cela, nous avons choisi le langage de modélisation UML (Unified Modeling Language), car il
s’appuie sur la standardisation et pour la diversité de ses diagrammes. Ce qui permet de réaliser une
analyse détaillée des besoins, des vues statiques et dynamiques...

Conclusion

Dans ce chapitre, nous avons présenté le projet dans son cadre général, nous passons maintenant
à la spécification des besoins.

13
 Chapitre 2

Analyse et spécification des besoins

Plan
1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Planification de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Les patrons de conception utilisés . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Maquette du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7 Difficultés rencontrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

8 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Chapitre 2. Analyse et spécification des besoins

Introduction

Dans ce chapitre, nous présentons une analyse des besoins fonctionnels et non fonctionnels de
notre applications en précisant les différents acteurs de notre système, le diagramme de classe et la
planification de travail. Nous allons ainsi présenté l’architecture et les maquettes utilisées.

2.1 Spécification des besoins

2.1.1 Spécification des besoins fonctionnels

2.1.1.1 Identification des acteurs

Dans cette partie, nous allons commencer par définir les différents acteurs qui contribuent dans
notre application ainsi que la définition de leurs rôles.
Dans l’application XHRM, les acteurs sont : Manager, Responsable RH, Employé, Consultant,
Stagiaire. Il faut bien noter que chaque rôle possède les permissions du rôle précédent, par exemple
le consultant peut faire tout ce qu’un stagiaire peut faire et il possède de plus les permissions d’un
consultant et l’employé peut faire tout ce qui peut un consultant et un stagiaire et il a davantage de
permissions.

• Stagiaire C’est une personne saisonnière donc son rôle va lui permet d’avoir le moindre de
permissions tels que marquer la présense et la gestion du profil...

• Consultant : C’est un prestataire de services de conseil et ce n’est pas un élément permanent

dans l’entreprise .Il a plus de permissions que le stagiaire mais son rôle reste restreint.

• Employé C’est une personne permanente dans l’entreprise ce qu’il permet d’avoir plus des
permissions que les deux rôles précédents tels que passer une demande de congé ou bien demande
d’achat.

• Responsable RH : C’est qui conseille le personnel des entreprises et coordonne toutes les
activités dans divers domaines des ressources humaines donc son rôle lui permet d’accèder aux
informations des employés de leur entreprise ainsi qu’il peut répondre aux demandes de sortie et
de congé.

• Manager : C’est le super admin le propriétaire de l’entreprise, le rôle le plus important.Il

supervise et dirige l’entreprise son rôle lui donne l’accés à tous les modules de l’application il
peut aussi gérer les rôles des autres utilisateurs.

15
Chapitre 2. Analyse et spécification des besoins

2.1.1.2 Spécification des besoins fonctionnels par acteur

• Stagiaire :

— Gérer son profil.

— Consulter son dashboard.

— Marquer l’heure d’entrée.

— Marquer l’heure de sortie.

— Consulter sa liste de pointage.

— Rechercher un utilisateur.

— Consulter son dashboard.

— Demander une autorisation de sortie.

— consulter l’équipe de son département.

• Consultant :

— Consulter son compte rendu d’activité.

• Employé :

— Demander un congé.

— Demander un achat.

• Responsable RH :

— Gérer les comptes des employés.

— Consulter les absences et les présences.

— Gérer les congés.

— Gérer les autorisations de sortie.

— Consulter les équipe de tous les départements.

• Manager :

— Gérer les rôles des utilisateurs.

— Gérer les demandes d’achat.

— Gérer les fournisseurs.

— Gérer les dépenses périodiques.

— Gérer le compte de son entreprise.

16
Chapitre 2. Analyse et spécification des besoins

2.1.1.3 Diagramme de cas d’utilisation global

Figure 2.1 : Diagramme cas d’utilisation global

17
Chapitre 2. Analyse et spécification des besoins

Notons qu’un utilisateur peut être un consultant, un stagiaire, un employé, un manager ou un

responsable ressources humaines.

2.1.2 Spécification des besoins non fonctionnels

La spécification des besoins ne se limite pas à l’identification des acteurs et à la définition des
besoins fonctionnels. D’autres limites doivent être définies pour faciliter l’utilisation, afin de mieux
comprendre la structure et la fonctionnalité et assurer une bonne expérience utilisateur.
Étant donné que notre application Web est destinée aux employés, ses interfaces doivent être
ergonomiques pour faciliter la navigation sur le site et pour que l’utilisateur comprenne les caractéristiques
et la structure.

• La navigation (l’expérience utilisateur) : Notre application devrait fournir à l’utilisateur

le confort de navigation (un bon système de navigation), permettant de minimiser l’efforts pour
atteindre la partie qu’il cherche. Ce dernier doit s’éloigner en un seul clic et revenir facilement à
la section précédente ou dans la position de départ grâce à un fil d’Ariane (SideBar).

• L’accessibilité (responsivité) : L’accès à l’application couvre un grand nombre de visiteurs

avec différents matériels. Cette accessibilité est principalement liée à la taille et à la résolution de
l’écran. Pour ce faire, vous devez vous assurer une expérience de lecture idéale pour l’utilisateur,
quelle que soit la gamme d’appareil grâce à la responsive design.

• L’interactivité : L’échange entre l’application et l’utilisateur doit être simple et facile. Le

but principal de ce critère est de surmonter les obstacles afin de garantir une bonne étape de
découverte jusqu’à la construction d’une relation entre l’employé et l’administrateur.

• L’harmonie et la clarté : Respecter la charte graphique dans notre application est essentiel
pour l’harmonie, la cohérence graphique, la visibilité et la lisibilité des textes et du contenu de
chaque page.

• La rapidité : Le système doit agir rapidement dans les différentes demandes envoyées par les
utilisateurs.

• La sécurité et l’intégrité :

• Le système garantit le contrôle d’accès.

• Chaque utilisateur ne contribue qu’aux pages autorisées par son rôle.

2.2 Diagramme de classe

Ci-dessous dans la figure 2.2, nous représentons le diagramme de classe global de notre application.
Nous détaillons ses classes dans chaque sprint.

18
Chapitre 2. Analyse et spécification des besoins

Figure 2.2 : Diagramme de classe global

2.3 Planification de travail

2.3.1 Répartition des releases

19
Chapitre 2. Analyse et spécification des besoins

Release
Nom du Sprint
ID

• Sprint 1 :Gestion de l’entreprise.

1
• Sprint 2 :Gestion des utilisateurs et authentification.

• sprint 3 :Module gestion des Congés et des permissions des sorties

2
• Sprint 4 :Module gestion de présence et Compte rendu d’activité

• Sprint 5 : Module gestion d’achats et Dépenses.

3
• Sprint 6 : Réalisation du Dashboad.

Tableau 2.1 : Répartition des releases

2.3.2 Planification des sprints

La figure 2.3 représente le diagramme de Gantt illustrant la répartition du travail tout au long
de la période de stage.

Figure 2.3 : Planification des sprints

20
Chapitre 2. Analyse et spécification des besoins

2.4 Architecture de l’application

2.4.1 Architecture logique

L’architecture logique de notre application est divisée en deux parties, une partie Back-end et
une partie Front-end.
La partie Front-end est basée sur le fameux Framework modulaire Angular. Chaque module
est composé d’un composant contenant la logique de base de la page et un template qui traite de la
vue de l’application. Un composant injecte la couche service, une couche d’abstraction qui permet de
gérer le logique métier de l’application. Il assure la communication avec les services du backend, via
les requêtes HTTP. Les données échangées entre la partie Front-end et la partie Back-end sont de type
JSON.
La partie Back-end est basé sur le Framework Spring boot. Son conteneur constitue le cœur de
ce Framework. Il obtient ses instructions sur les objets à instancier, configurer et assembler en lisant
les métadonnées de configuration fournies.
La figure 2.4 représente l’architecture logique de Spring-Boot

Figure 2.4 : Architecture logique Back-End (Spring-Boot)

21
Chapitre 2. Analyse et spécification des besoins

2.4.1.1 Architecture logique d’ Angular

Angular est un Framework pour créer la partie Front End des applications web en utilisant
HTML et JavaScript ou TypeScript compilé en JavaScript.Une application Angular se compose de [2] :

— Un à plusieurs modules dont un est principal.

— Chaque module peut inclure :

• Des composant web : La partie visible de l’application Web (IHM)

• Des services pour la logique applicative : Les composants peuvent utiliser les services
via le principe de l’injection des dépendances.

• Les directives : un composant peut utiliser des directives

• Les pipes : utilisés pour formater l’affichage des données dans els composants.

La figure 2.5 représente l’architecture logique d’Angular :

Figure 2.5 : Architecture logique Front-End (Angular)[3]

2.4.2 Architecture physique

Notre application repose sur une architecture 3-tiers. La figure 2.6, représente les interactions
entre les différents niveaux, ainsi que l’architecture physique que nous avons adopté

22
Chapitre 2. Analyse et spécification des besoins

Figure 2.6 : Architecture physique

Notre application est divisée en quatre couches :

• La couche présentation des données contient les composants graphiques de l’application et

tous les interfaces.

• Le REST API qui garantit le lien entre les composants graphiques et les composants métiers
dans notre application, En s’appuyant sur le protocole HTTP hors ligne, les utilisateurs peuvent
simplement y accéder via un autre élément du SI et des applications clientes.

• La couche métier des données correspond à la mise en place de l’ensemble de la logique

applicative et des règles de gestion.

• La couche accès aux données correspond aux données qui sont destinées à être conservées
dans la base de données.

2.5 Les patrons de conception utilisés

2.5.1 Patrons de création

2.5.1.1 Patron Singleton

Singleton est un patron de conception de création qui garantit que l’instance d’une classe n’existe
qu’en un seul exemplaire, tout en fournissant un point d’accès global à cette instance.[4] :
On utilise ce patron souvent en utilisant spring boot lors de l’injection de dépendance avec
l’annotation Autowired ou bien Inject.

23
Chapitre 2. Analyse et spécification des besoins

2.5.2 Patrons structurels

2.5.2.1 Patron Proxy

Le Proxy est un patron de conception structurel qui vous permet d’utiliser un substitut pour un
objet. Elle donne le contrôle sur l’objet original, vous permettant d’effectuer des manipulations avant
ou après que la demande ne lui parvienne. Ce patron de conception vous propose de créer une classe
Proxy qui a la même interface que l’objet du service original. Vous passez ensuite l’objet procuration à
tous les clients de l’objet original. Lors de la réception d’une demande d’un client, la procuration crée
l’objet du service original et lui délègue la tâche.[5] :
Nous avons utilisé ce patrons plusieurs fois dans la partie backend avec les classes DTO Data
Transfer Object.

2.5.3 Patrons comportementaux

2.5.3.1 Patron État

État est un patron de conception comportemental qui permet de modifier le comportement d’un
objet lorsque son état interne change. L’objet donne l’impression qu’il change de classe.[6] :
Nous avons utilisé ce patrons lors du traitements des demandes (congés ,sorties ,achats) chacun
de ces objets posséde un état et il change de comportement dès qu’on change son état.

2.5.4 Patron d’architecture

2.5.4.1 Patron Data Access Object DAO

C’est un patron qui permet d’encapsuler et de centraliser l’accès à la base de données et le lien
entre l’application et le système de stockage. Le plus grand avantage de ce patron est qu’il permet
de mieux maitriser les changements susceptibles d’être opérés sur le système de stockage à savoir une
migration d’un système à un autre. Un objet DAO fournit des opérations basiques (CRUD) comme la
lecture, la mise à jour, la création, l’affichage et la suppression d’une entité sans exposer les détails de
la base de données.

2.5.4.2 Patron Dependency Injection DI

L’injection de dépendance est un design pattern qui permet de solutionner la problématique

de communication entre les classes. il minimise les dépendances entre les composants et les modifier
facilement, l’architecture est ainsi faiblement couplée et le potentiel de réutilisation de ces composants
est plus élevé. L’objet dépendant n’a plus besoin de chercher et instancier le composant logiciel dont

24
Chapitre 2. Analyse et spécification des besoins

il dépend pour faire son travail, il suit de décrire son interface et l’injecteur décide quel composant
concret satisfait les exigences et l’injecte dans l’objet dépendant. Dans une architecture classique,
l’objet dépendant décide lui-même quelles classes concrètes il va utiliser. Dans notre cas, nous avons
utilisé ce patron pour gérer les dépendances entre les objets d’accès aux données et les objets métiers
et entre les objets métiers et les objets service de hauts niveaux.

2.6 Maquette du projet

Dans cette partie nous allons présenter en premier lieu la maquette de l’application qui est
réalisée avec Adobe Xd par le designer de XtendPlex et en second lieu le schéma de navigation de
l’application.

2.6.1 Captures des interfaces de maquette

La figure 2.7 représente l’interface login de l’application.

Figure 2.7 : Interface "S’authentifier"

La figure 2.8 représente l’interface dashboard de l’application.

25
Chapitre 2. Analyse et spécification des besoins

Figure 2.8 : Interface "Dashboard"

La figure 2.9 représente l’interface du pointage dont laquelle un utilisateur peut marquer sa
présence et il trouve aussi une liste de sa fréquentation pour cette semaine là.

Figure 2.9 : Interface "Présence"

2.6.2 Schéma de navigation

Le Schéma de navigation est une technique visuelle qui nous aiderons à comprendre le contenu
d’une application.

2.6.2.1 Schéma de navigation de l’application

La figure 2.10 représente le schéma de navigation global de l’application il nous montre toutes
les pages de l’application.

26
Chapitre 2. Analyse et spécification des besoins

Figure 2.10 : Schéma de navigation de l’application

2.6.2.2 Schéma de navigation par acteur

Les figures suivantes représentent les schémas de navigation par acteurs selon la spécification
des besoins qu’on l’a réalisé au début de ce chapitre.

• Stagiaire :

La figure 2.11 représente le schéma de navigation du Stagiaire.

Figure 2.11 : Schéma de navigation d’un stagiaire

• Consultant :

La figure 2.12 représente le schéma de navigation du consultant.

Figure 2.12 : Schéma de navigation d’un consultant

• Employé :

La figure 2.13 représente le schéma de navigation de l’employé.

27
Chapitre 2. Analyse et spécification des besoins

Figure 2.13 : Schéma de navigation d’un employé

• responsable RH :

La figure 2.14 représente le schéma de navigation du responsable Rh.

Figure 2.14 : Schéma de navigation d’un responsable RH

• Manager :

La figure 2.15 représente le schéma de navigation du manager.

Figure 2.15 : Schéma de navigation d’un manager

2.7 Difficultés rencontrées

La principales difficulté rencontrée c’est que nous avons préparé la partie Front-end à partir du
zéro en se basant sur les maquettes fournies par l’équipe de design de Xtendplex. En effet la réalisation
de chaque sprint se divise en trois parties partie Back-end, intégration de la maquette en HTML et
CSS et la partie Front-end ce qui engendre une perte de temps considérable

28
Chapitre 2. Analyse et spécification des besoins

2.8 Environnement de travail

2.8.1 Outils de gestion de projet

• Bitbucket

Bitbucket est un service d’hébergement Web et de gestion du développement logiciel,planification,

collaboration autour du code, et intégration. il s’appuie sur le logiciel de gestion de version
décentralisée Git.[7]

Figure 2.16 : Logo Bitbucket

• Jira Software

Jira est une plateforme de gestion de projet destinée au développement logiciel. Elle permet de
préparer, matérialiser et suivre les développements des teams SCRUM.[8]

la figure 2.17 montre une capture de jira qui contient les tâches terminées et les tâches en cours
de sprint 1.

Figure 2.17 : Logo Bitbucket

• Discord

Discord permet aux membres de l’équipe de discuter entre eux en tête-à-tête ou en groupe via
un serveur. Nous l’utilisons pour envoyer des messages directs, passer des appels vidéo, discuter
avec la voix et même partager lécran.[9]

Figure 2.18 : Logo Discord

29
Chapitre 2. Analyse et spécification des besoins

2.8.2 Framework de développement et de tests

• Angular

Angular est un framework open source, écrit en JavaScript, qui permet la création d’applications
Web, en particulier les «applications à une seule page» : Des applications Web accessibles via une
seule page Web, rendant l’expérience utilisateur plus fluide et évitant les pages Chargées chaque
nouveau action.[10]

Figure 2.19 : Logo Angular

• Spring Boot

Spring est un Framework, qui fournit un modèle complet de programmation et de configuration

pour les applications d’entreprise modernes basées sur Java, sur tout type de plate-forme de
déploiement.[11]

Figure 2.20 : Logo springBoot

• Postman

Postman est une solution pour interroger ou tester webservices et API. Il permet de construire et
d’exécuter des requêtes HTTP, de les stocker dans un historique afin de pouvoir les rejouer, mais
surtout de les organiser en Collections. Nous avons utilisé cet outil pour tester le fonctionnement
de la partie Backend.[12]

Figure 2.21 : Logo postman

30
Chapitre 2. Analyse et spécification des besoins

2.8.3 Système de gestion de base de données

• MySQL Database

MySql est un système de gestion de bases de données relationnelles (SGBDR). Ce système est
distribué sous une double licence GPL(licence publique générale) et propriétaire. Il est parmi les
logiciels de gestion de base de données les plus utilisés au monde.[13]

Figure 2.22 : Logo MySql

Conclusion

La phase de spécification des besoins est une phase très importante dans le cycle de vie d’un
projet, car elle offre une vue plus claire du système et des principales caractéristiques à atteindre. Par
conséquent, nous avons introduit le backlog produit et la planification des releases pour passer à la
phase de conception.

31
 Chapitre 3

Release 1 : Gestion de l’entreprise et

des comptes

Plan
1 Sprint 1 :Module gestion de l’entreprise . . . . . . . . . . . . . . . . . . . . 33

2 sprint 2 :Module gestion des utilisateurs et authentification . . . . . . . . . 39

Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

Introduction

Au cours de ce chapitre, nous allons présenter les différentes étapes de réalisation du premier
sprint "Gestion de l’entreprise", et du deuxième sprint "Gestion des utilisateurs et authentification".

3.1 Sprint 1 :Module gestion de l’entreprise

Dans cette section nous allons présenter les différents étapes de la réalisation du premier sprint.

3.1.1 Objectifs du sprint 1

L’objectif du premier sprint est de développer le module « Gestion de l’entreprise » qui permet
au manager de gérer le compte de son entreprise (créer ,compléter et modifier) et de créer son propre
compte.

3.1.2 Backlog du sprint 1

Estimation
Id Fonctionnalités Priorité
(Jour)

En tant que manager je veux créer un compte

1 pour mon entreprise afin d’utiliser les services 1 2
offerts par l’application "XHRM"

En tant que manager je veux créer un compte

2 manager afin de pouvoir gérer mon entreprise et 2 2
ajouter mes collaborateurs

En tant que manager je veux compléter le profil

3 3 2
de mon entreprise

En tant que manager je veux modifier le profil

4 3 2
de mon entreprise

En tant que manager je veux Gérer les

5 3 2
départements de mon entreprise

En tant que manager je veux gérer les postes par

6 4 1
département

Tableau 3.1 : Backlog du Sprint 1

33
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

3.1.3 Spécification des besoins fonctionnels

La figure 3.1 représente le diagramme cas d’utilisation du sprint "Gestion de l’entreprise"

Figure 3.1 : Diagramme de cas d’utilisation "Gestion de l’entreprise"

3.1.4 Diagramme de classe

La figure 3.2 représente le diagramme de classe du sprint "Gestion de l’entreprise"

— Une entreprise est caractérisée par (id Entreprise, nom Entreprise, Activité Entreprise, email,
adresse, nombre de Personnel, téléphone, nombre de jours de congés), peut contenir plusieurs
départements.

— Un département est caractérisé par (id département, nom département) peut contenir plusieurs
postes.

— Un poste est caractérisé par (id poste, nom poste), peut contenir plusieurs utilisateurs.

— Un utilisateur est caractérisé par (id utilisateur, nom, prénom, nom d’utilisateur, mot de passe,
email, adresse, téléphone, sexe, date de naissance, date d’arrivée, statut civil, discord, facebook,
linkedin, slack, twitter), peut avoir un seul rôle.

34
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

— Un rôle est caractérisé par (id rôle, nom rôle) et peut être attribué à plusieurs utilisateurs.

Figure 3.2 : Diagramme de classe "Gestion de l’entreprise"

3.1.5 Diagrammes dynamiques

Dans cette section nous allons présenter les diagrammes UML dynamique pour ce sprint.

3.1.5.1 Diagramme de séquence objet "Ajout d’entreprise"

La figure 3.2 illustre le diagramme de séquence objet de l’inscription.

Dans ce diagramme nous allons décrire le cas d’utilisation "ajout d’entreprise" avec les différents
composants inclus dans cette processus, commençant par l’interaction entre le composant et le service
dans la partie front-end passant par l’ Api Rest et enfin l’interaction entre les classes côté serveur.

35
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

Figure 3.3 : Diagramme de séquence objet "ajout d’entreprise"

3.1.6 Réalisation

Pour mieux comprendre le fonctionnement de notre projet, nous allons présenter les différents
fonctions de l’application "XHRM"en se basant sur un scénario.
Dans ce contexte pour s’inscrire à l’application "XHRM" monsieur "Mohamed" doit remplir le
formulaire d’inscription qui est composé de trois parties , la première partie est pour les coordonnées
générales ,la deuxième est pour l’entreprise et la dernière c’est pour le compte principal qui va avoir le
rôle Manager. Les trois premières figures nous montrent le formulaire d’inscription.
Voir les figures 3.4,3.5 et 3.6.

Figure 3.4 : interface de création de compte entreprise 1.0

36
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

Figure 3.5 : interface de création de compte entreprise 1.1

Figure 3.6 : interface de création de compte entreprise 1.2

Après l’inscription, l’application emmène le manager vers la page paramètre de l’entreprise pour
qu’il puisse compléter les informations de son entreprise comme nous illustre la figure 3.7.

37
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

Figure 3.7 : Page paramètre d’entreprise

Les trois prochaines captures dans les figures 3.8, 3.9 et 3.10. vont nous montrer que la page
"paramètre d’entreprise" offre aussi au manager la possibilité de gérer les postes et les départements
de son entreprise et aussi elle le permet de fixer le nombre des jours de congés qu’un employé peut
l’avoir pendant une année.

Figure 3.8 : interface poste et département

38
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

Figure 3.9 : interface ajout du poste

Figure 3.10 : interface profil entreprise fixer le nombre de jours de congé

3.2 sprint 2 :Module gestion des utilisateurs et authentification

Dans cette section nous allons présenté les différents étapes permettant la réalisation du sprint
"Gestion des utilisateurs et authentification".

3.2.1 Objectifs du sprint 2

L’objectif du deuxième sprint est de développer le module « Gestion des utilisateurs » qui
permet aux utilisateurs d’authentifier et gérer leurs profils et permet aux responsable RH de gérer les
comptes des utilisateurs

39
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

3.2.2 Backlog du sprint 2

Estimation
Id Fonctionnalités Priorité
(Jour)

En tant qu’utilisateur je veux m’authenifier afin

1 1 4
de connecter à l’application.

En tant que responsable RH je veux gérer les

2 comptes utilisateurs afin d’ajouter des nouveaux 2 2
utilisateurs ou les supprimer

3 En tant qu’utilisateur je veux gérer mon profil 3 2

En tant qu’utilisateur je veux changer mon mot

4 3 1
de passe

En tant qu’utilisateur je veux consulter l’équipe

5 3 1
de mon département

En tant que responsable RH je veux consulter

6 3 1
toutes les équipes

En tant qu’utilisateur je veux réinitialiser mon

7 mot de passe afin de récupérer mon compte en 4 3
cas d’oubli de mot de passe

En tant que Manager je veux changer les rôle des

8 utilisateurs afin de leurs accorder ou révoquer 4 3
des privilèges

Tableau 3.2 : Backlog du Sprint 2

3.2.3 Technologies utilisées

Pour Réaliser la partie authentification de notre projet nous avons principalement nous basé
sur ces deux technologies :

• JSON Web Token

Un JSON Web Token est un jeton d’accès, qui permet un échange sécurisé de donnée entre deux ou
plusieurs parties. Les JWT sont particulièrement appréciés pour les opérations d’identification.
Cette sécurité se traduit par la vérification de l’intégrité des données à l’aide d’une signature
numérique, qui vérifie si le message a été modifié pendant le transfert, et authentifie également
l’expéditeur du JWT dans le cas d’un jeton signé avec une clé privée.[14]

40
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

• Spring Security

Spring Security est un Framework de sécurité, dans le cadre d’authentification et de contrôle

d’accès puissant des applications basées sur spring. La véritable force de Spring Security réside
dans la facilité avec laquelle, elle peut être étendue pour répondre aux besoins personnalisées[15]

3.2.4 Spécification des besoins fonctionnels

La figure 3.11 représente le diagramme cas d’utilisation du sprint "Gestion des utilisateurs et
authentification"

Figure 3.11 : Diagramme de cas d’utilisation "Gestion des utilisateurs"

3.2.5 Diagramme de classe

La figure 3.12 représente le diagramme de classe du sprint "Gestion des utilisateurs et authentification"

— Un utilisateur est caractérisé par (id utilisateur, nom, prénom, nom d’utilisateur, mot de passe,
email, adresse, téléphone, sexe, date de naissance, date d’arrivée, statut civil, discord, facebook,
linkedin, slack, twitter), peut avoir un seul rôle.

41
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

— Un rôle est caractérisé par (id rôle, nom rôle) et peut être attribué à plusieurs utilisateurs.

Figure 3.12 : Diagramme de classe "Gestion des utilisateurs"

3.2.6 Diagrammes dynamiques

3.2.6.1 Diagramme de séquence objet "Authentification"

La figure 3.13 représente le diagramme de séquence objet de l’authentification d’un utilisateur

à son espace dans l’application "XHRM".
Dans ce diagramme nous illustrons les différents interactions entre l’utilisateur et les composants
de notre projet.

42
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

Figure 3.13 : Diagramme de séquence objet "Authentification"

3.2.6.2 Diagramme de séquence système "Ajout utilisateur"

La figure 3.14 représente le diagramme de séquence système de l’ajout d’un utilisateur qui peut
être réalisé par l’acteur Responsable RH ou bien par le Manager.
Ce diagramme nous montre l’interaction de l’acteur avec le système pour réaliser l’ajout d’un
utilisateur.

43
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

Figure 3.14 : Diagramme de séquence système "Ajout utilisateur"

3.2.6.3 Diagramme d’activité "Réinitialisation du mot de passe"

La figure 3.15 représente le diagramme d’activité de la réinitialisation du mot de passe.

Ce diagramme nous décrit le cas d’utilisation "Réinitialisation du mot de passe" et les différents
interactions entre l’utilisateur, le système et la base de donnés commençant par l’affichage de l’interface
de réinitialisation jusqu’au stockage du nouveau mot de passe.
On note que l’utilisateur doit fournir un nom d’utilisateur valide pour qu’il puisse passer à
l’interface de réinitialisation.

44
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

Figure 3.15 : Diagramme d’activité "Réinitialisation du mot de passe"

3.2.7 Réalisation

La figure 3.16 représente la page équipe de l’application qui nous permet de gérer les utilisateurs.

45
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

Figure 3.16 : interface équipe par département

Après avoir inscrire à l’application monsieur "Mohamed" veut ajouter ses employés dans l’application
et pour cela il doit remplir le formulaire d’ajout d’utilisateur comme nous montre la figure 3.17 .On
peut constater que les champs département et poste sont présentés par une liste déroulante.

Figure 3.17 : Formulaire d’ajout d’utilisateur

Après la validation du formulaire l’utilisateur "Ali" avec le rôle Employé est ajouté avec succès
à l’entreprise de monsieur "Mohamed".

46
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

Figure 3.18 : L’employé est ajouté

Avec l’ajout de l’utilisateur l’application envoie un email instantanément contenant les coordonnées
de connexion (nom d’utilisateur et mot de passe) vers l’adresse mail fournie dans le formulaire comme
nous indique la figure 3.19.

Figure 3.19 : L’email contenant les coordonnées de connexion

Maintenant on va déconnecter le compte de "Mohamed" le manager et on va connecter par le

compte de "Ali" l’employé. La figure 3.20 représente la page profil utilisateur.

47
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

Figure 3.20 : Profil utilisateur

La page profil permet l’utilisateur de compléter et modifier les informations de son profil ,elle
lui permet aussi de changer ses coordonnées de connexion comme nous illustrent les deux prochaines
captures, voir figures 3.21 et 3.22.

Figure 3.21 : Interface gestion du profil

48
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

Figure 3.22 : Changement du mot de passe

Maintenant on va revenir à la page équipe mais cette fois ci par le compte de "Ali" qui possède le
rôle Employé et on peut rapidement constater qu’il ne peut pas ni ajouter ni voir les autres utilisateurs
hormis son département.

Figure 3.23 : Page équipe de l’employé

On déconnecte le compte de "Ali" et on reconnecte une autre fois par le compte de "Mohamed".
On remarque que "Mohamed" peut voir les utilisateurs de tous les départements aussi il peut les
supprimer ou modifier leurs rôles.

49
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

Figure 3.24 : Modifier employé

La figure 3.25 montre "Mohamed" qui va changer le rôle de "Ali" et lui attribuer le rôle
Responsable RH.

Figure 3.25 : Changement du rôle

Maintenant on connecte par le compte de "Ali" qui est maintenant un responsable RH et on

remarque par la figure 3.26 qu’il peut ajouter des utilisateurs.

50
Chapitre 3. Release 1 : Gestion de l’entreprise et des comptes

Figure 3.26 : Page équipe du responsable RH

Conclusion

Au cours de ce chapitre, nous avons présenté la réalisation de la première release "Gestion de

l’entreprise et des comptes". Pour ce faire, nous avons passé par l’analyse, la conception et la réalisation
des deux premièrs sprints.

51
 Chapitre 4

Release 2 : Gestion d’activité de

ressources humaines

Plan
1 sprint 3 :Module gestion des Congés et des permission des sorties . . . . . 53

2 Sprint 4 :Module gestion de présence et Compte rendu d’activité . . . . . 63

Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Introduction

Dans ce chapitre, nous allons présenter les différentes étapes de réalisation du troisième sprint
"Gestion des Congés et des permission des sorties", et du quatrième sprint "Gestion de présence et du
compte rendu d’activité".

4.1 sprint 3 :Module gestion des Congés et des permission des

sorties

Dans cette section nous allons présenter les différents étapes de la réalisation du sprint "Gestion
des Congés et des permission des sorties".

4.1.1 Objectifs du sprint 3

L’objectif du troisième sprint est de développer le module « Gestion des congés et permission de
sorties » qui permet en premier lieu aux utilisateurs de gérer leurs demandes de sorties et en deuxième
lieu aux employés de gérer leurs demandes de congés et qui permet au responsable RH de gérer toutes
ces demandes.

4.1.2 Backlog du sprint 3

Estimation
Id Fonctionnalités Priorité
(Jour)

En tant qu’employé je veux passer une demande

1 1 1
de congé

En tant qu’employé je veux consulter l’état de

2 2 1
ma demande de congé

En tant qu’employé je veux consulter l’historique

3 3 1
de mes demandes de congés

4 En tant qu’employé je veux consulter mes congés 4 1

En tant qu’utilisateur je veux passer une

5 5 1
demande d’autorisation de sortie

En tant qu’utilisateur je veux consulter l’état de

6 6 1
ma demande de sortie

53
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Estimation
Id Fonctionnalités Priorité
(Jour)

En tant qu’employé je veux consulter l’historique

7 7 1
de mes demandes d’autorisations de sortie

En tant qu’utilisateur je veux annuler ma

8 8 1
demande

En tant que responsable RH je veux consulter la

9 9 1
liste des demandes en attentes

En tant que responsable RH je veux accepter une

10 10 1
demande

En tant que responsable RH je veux refuser une

11 10 1
demande

En tant que responsable RH je veux consulter

12 l’historique des congés prises par chaque 11 3
utilisateur

Tableau 4.1 : Backlog du Sprint 3

4.1.3 Spécification des besoins fonctionnels

La figure 4.1 représente le diagramme de cas d’utilisation du sprint "Gestion de congé et

autorisation"

54
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Figure 4.1 : Diagramme de cas d’utilisation "Gestion de congé et autorisation"

4.1.4 Diagramme de classe

La figure 4.2 représente le diagramme de classe du sprint "Gestion de congé et autorisation".

— Un utilisateur peut avoir plusieurs congés. Un congé est caractérisé par (id congé, nombre de
jours, date début, raison).

— Un utilisateur peut avoir plusieurs autorisations de sortie. Une autorisation est caractérisée par
(id autorisation, nombre d’heures, date, heure de sortie).

55
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Figure 4.2 : Diagramme de classe "Gestion de congé et autorisation

4.1.5 Diagrammes dynamiques

Dans cette partie nous allons présenter un diagramme séquence système pour la procédure de
traitement d’une demande de congé et un diagramme état transition pour montrer les différents état
qu’une demande peut l’avoir.

4.1.5.1 Diagramme de séquence système "Traiter une demande de congé"

La figure 5.3 représente le diagramme de séquence système de la procédure de traitement d’une

demande de congé entre les deux acteurs Employé et Responsable RH avec le système.
Ce diagramme nous montre les différents interactions entre les deux acteurs Employé et Responsable
Rh avec le système afin de décrire toute la procédure du demande de congé.

56
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Figure 4.3 : Diagramme de séquence système "Traiter une demande de congé"

4.1.5.2 Diagramme d’état transition "État d’une demande"

La figure 4.4 représente le diagramme d’état transition d’une demande. La demande peut avoir
quatre état comme nous montre le diagramme suivant.

57
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Figure 4.4 : Diagramme d’état transition "État d’une demande"

4.1.6 Réalisation

Avant de commencer la partie réalisation de ce sprint on doit se rappeler des comptes déjà crées
pour l’entreprise XtendPlex de monsieur "Mohamed ". Jusqu’à maintenant on a le compte "Mohamed
" avec le rôle Manager et le compte de "Ali" qui possède maintenant le rôle Responsable RH. Il faut
noter que nous avons ajouté deux autres utilisateurs, "Mourad " avec le rôle Employé et "Maissa" avec
le rôle Stagiaire.
Ces quatre comptes vont nous accompagner pour le reste du rapport alors si l’on récapitule on
a:

— Compte "Mohamed " avec le rôle Manager

— Compte "Ali" avec le rôle Responsable Rh

— Compte Mourad avec le rôle Employé

— Compte "Maissa" avec le rôle Stagiaire

La figure 4.5 représente l’interface d’autorisation. On est maintenant connecté avec le compte
de Mourad et puisqu’il possède le rôle Employé ,on peut remarquer qu’il y a deux onglets qui sont
affichés, la première est pour la section congé et la deuxième est pour les autorisations de sortie.

58
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Figure 4.5 : interface demande de congé

La figure 4.6 représente le formulaire de demande de congé.

Figure 4.6 : formulaire de demande de congé

La figure 4.7 nous montre que la demande de congé passée par Mourad est enregistrée avec
succès.

59
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Figure 4.7 : demande de congé ajoutée

La figure 4.8 représente l’interface des autorisations de sortie.

Figure 4.8 : interface demande d’autorisation de sortie

La figure 4.9 représente le formulaire de demande d’une autorisation de sortie. Après avoir
demander un congé avec une durée de trois jours monsieur Mourad a passé aussi une demande
d’autorisation de sortie pour une durée de deux heures pour le 28 juin.

60
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Figure 4.9 : formulaire demande d’autorisation de sortie

Maintenant nous changeons du compte et nous allons connecter avec le compte de "Ali" qui
possède le rôle responsable RH comme vous pouvez voir dans la navbar. En regardant la figure 4.10
on constate rapidement qu’il y a deux onglets de plus sont ajoutés à la section Autorisation qui sont
"Approbation en attente" et "vue global". Dans cette figure nous sommes dans l’onglet "Approbation
en attente" dont on y trouve les deux demandes de monsieur Mourad.

Figure 4.10 : interface approbation en attente

Dans la figure 4.11 Monsieur "Ali" le responsable Rh a accepté la demande de sortie et il va

aussi accepter la demande de congé.

61
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Figure 4.11 : la demande est acceptée

Maintenant en naviguant à l’onglet "Vue global" comme nous illustre la figure 4.12 on trouve
la liste de tous les utilisateurs avec pour chacun le nombre de jours de congé restants et si vous vous
rappelez bien dans le premier sprint dans la figure 3.10 nous avons montré que le manager a fixé le
nombre de jours de congé à 20. Tous les utilisateurs possèdent leurs 20 jours hormis Mourad qui a pris
3 jours et on trouve aussi le détail de son congé.

Figure 4.12 : interface vue global des congés par utilisateur

On reconnecte maintenant avec le compte de Mourad pour trouver que sa demande a été
acceptée.

62
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Figure 4.13 : historique des demandes de sortie

4.2 Sprint 4 :Module gestion de présence et Compte rendu d’activité

Dans cette section nous allons présenter les différents étapes de la réalisation du sprint "Gestion
de présence et Compte rendu d’activité".

4.2.1 Objectifs du sprint 4

L’objectif du quatrième sprint est de développer le module « Gestion de présence et Compte

rendu d’activité » qui permet aux utilisateurs de faire le pointage et de consulter leurs listes de présence.
De plus, permettant au manager et aux responsables RH de consulter les listes de présences de tous
les employés de l’entreprise.

4.2.2 Backlog du sprint 4

Estimation
Id Fonctionnalités Priorité
(Jour)

En tant qu’utilisateur je veux marquer l’heure

1 1 1
d’entrée afin de marquer ma présence

En tant qu’utilisateur je veux marquer l’heure

2 2 1
de sortie

En tant qu’utilisateur je veux consulter ma liste

3 3 1
de présence

63
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Estimation
Id Fonctionnalités Priorité
(Jour)

En tant que consultant je veux consulter mon

compte rendu d’activité par mois afin d’avoir un
4 4 5
rapport sur mon activité de chaque jour de ce
mois

En tant que responsable RH je veux consulter la

5 5 3
liste des pointages

En tant que responsable RH je veux consulter la

6 6 1
liste des présences

En tant que responsable RH je veux consulter la

7 6 1
liste des absences

Tableau 4.2 : Backlog du Sprint 4

4.2.3 Spécification des besoins fonctionnels

La figure 4.14 représente le diagramme cas d’utilisation du sprint "Gestion de présence et compte
rendu d’activité".

64
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Figure 4.14 : Diagramme de cas d’utilisation "Gestion de présence et compte rendu d’activité"

4.2.4 Diagramme de classe

La figure 4.15 représente le diagramme de classe du sprint "Gestion de présence et compte rendu
d’activité".

— Un utilisateur doit avoir une liste de pointage. Une liste de pointage est caractérisée par (id
pointage, heure d’entrée, heure de sortie, date).

65
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Figure 4.15 : Diagramme de classe "Gestion de présence"

4.2.5 Diagrammes dynamiques

4.2.5.1 Diagramme de séquence objet "marquer l’heure d’entrée"

La figure 5.3 représente le diagramme de séquence objet du cas d’utilisation "marquer l’heure
d’entrée".
Ce diagramme représente les différents interactions de l’acteur avec les composants du projet
afin de marquer son présence.

66
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Figure 4.16 : Diagramme de séquence objet "marquer l’heure d’entrée"

4.2.6 Réalisation

Pour la réalisation du quatrième sprint nous allons nous connecter avec le compte de "Maissa"
qui possède le rôle Stagiaire. Ce qu’on remarque en premier lieu c’est que notre sidebar manque deux
éléments puisqu’un utilisateur avec le rôle stagiaire ne peut pas faire ni des achats ni de consulter
son compte rendu d’activité. La figure 4.17 représente la page présence et plus précisément l’onglet
pointage.

Figure 4.17 : interface du pointage

La figure 4.18 nous montre que "Maissa" a marqué son présence. On note aussi que Mourad a
marqué son présence pour aujourd’hui.

67
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Figure 4.18 : Liste du présence après le ClockIN

En connectant avec le compte de "Ali" le Responsable Rh on remarque qu’un autre onglet

apparaît dans la page présence. La figure 4.19 représente l’onglet présence dont on y trouve la liste des
utilisateurs présents.

Figure 4.19 : Interface du présence

Maintenant on va visiter une nouvelle page dans notre application, et comme nous montre la
figure 4.20 c’est l’interface du compte rendu d’activité. En fait le compte rendu d’activité contient
l’activité de l’utilisateur jour par jour et il est représenté par un calendrier sur une période que
l’utilisateur peut la choisie (mois, semaine ou jour).
Ici on a le compte rendu d’activité de "Ali" il a joint l’entreprise le 22 juin il n’a aucun absence
ni des congés ou des permissions de sortie.

68
Chapitre 4. Release 2 : Gestion d’activité de ressources humaines

Figure 4.20 : Compte rendu d’activité du Responsabe RH ’Ali’

Dans la figure 4.21 on trouve le compte rendu de Mourad on doit se rappeler d’abord que
dans la réalisation du sprint précédent Mourad a pris un congé d’une période de 3 jours et aussi une
permission de sortie pour le 28 juin.

Figure 4.21 : Compte rendu d’activité de l’employé ’Mourad’

Conclusion

Au cours de ce chapitre, nous avons présenté la réalisation de la deuxième Release "Gestion

d’activité de ressources humaines". Pour ce faire, nous avons passé par l’analyse, la conception et la
réalisation des deux sprints "Gestion des Congés et des permission des sorties" et "Gestion de présence
et du compte rendu d’activité".

69
 Chapitre 5

Release 3 : Gestion d’achat et

dépenses

Plan
1 Sprint 5 :Module gestion d’achats et Dépenses . . . . . . . . . . . . . . . . . 71

2 sprint 6 :Réalisation du dashboard . . . . . . . . . . . . . . . . . . . . . . . . 78

Chapitre 5. Release 3 : Gestion d’achat et dépenses

Introduction

Dans ce chapitre, nous allons présenter la réalisation du Sprint 5 "Gestion des achats et des
dépenses", et sprint 6 "Réalisation du Dashboard". Nous allons commencer par l’identification des
objectifs du Sprint, le backlog du sprint, la spécification des besoins et la réalisation.

5.1 Sprint 5 :Module gestion d’achats et Dépenses

Dans cette section nous allons présenter les différents étapes de la réalisation du sprint "Gestion
d’achats et Dépenses".

5.1.1 Objectifs du sprint 5

L’objectif du cinquième sprint est de développer le module « Gestion d’achats et Dépenses »

permettant aux employés d’enregistrer une demande d’achat et au manager de répondre à ces demandes
et de gérer les fournisseurs ainsi que les dépenses périodiques de son entreprise.

5.1.2 Backlog du sprint 5

Estimation
Id Fonctionnalités Priorité
(Jour)

En tant qu’employé je veux passer une demande

1 1 2
d’achat

2 En tant qu’employé je veux gérer ma demande d’achat 2 2

En tant qu’employé je paux gérer ajouter un

fournisseur si afin de pouvoir passer une demande
3 3 2
d’achat si ce fournisseur n’existe pas dans la liste des
fournisseurs

En tant que manager je veux consulter la liste des

4 4 1
achats

En tant que manager je veux répondre aux demandes

5 5 1
d’achats

En tant que manager je veux gérer les dépenses

6 6 3
périodique de mon entreprise

7 En tant que manager je veux gérér les fournisseurs 3 2

Tableau 5.1 : Backlog du Sprint 5

71
Chapitre 5. Release 3 : Gestion d’achat et dépenses

5.1.3 Spécification des besoins fonctionnels

La figure 5.1 représente le diagramme de cas d’utilisation du sprint "Gestion d’achats et

dépenses".

Figure 5.1 : Diagramme de cas d’utilisation "Gestion d’achats et dépenses"

72
Chapitre 5. Release 3 : Gestion d’achat et dépenses

5.1.4 Diagramme de classe

La figure 5.2 représente le diagramme de classe du sprint "Gestion d’achats et dépenses".

— Un utilisateur peut passer une ou plusieurs commandes. Une commande est caractérisée par (id
commande, date) et peut contenir plusieurs produits.

— Un produit est caractérisé par (id produit, nom produit, description, lien, prix).

— Un fournisseur est caractérisé par (id fournisseur, nom, téléphone, adresse, email, site web) et
peut avoir un ou plusieurs produits.

— Une dépense périodique est caractérisé par (id dépense, nom, note, période) et elle appartient à
une seule entreprise.

Figure 5.2 : Diagramme de classe "Gestion d’achats et dépenses"

73
Chapitre 5. Release 3 : Gestion d’achat et dépenses

5.1.5 Diagrammes dynamiques

Dans cette section nous allons présenter le diagramme de séquence système "traiter une demande
d’achat"

5.1.5.1 Diagramme de séquence système "traiter une demande d’achat"

La figure 5.3 représente le diagramme de séquence système de la procédure de traitement d’une

demande d’achat qui nous montre les interactions entre l’employé et le manager avec le système afin
de traiter une demande d’achat.

Figure 5.3 : Diagramme de séquence système "traiter une demande d’achat"

5.1.6 Réalisation

Pour la réalisation du sprint "Gestion d’achats et dépenses" nous allons nous connecter avec
le compte de "Mohamed" qui possède le rôle Manager car seul le manager peut gérer les fournisseurs

74
Chapitre 5. Release 3 : Gestion d’achat et dépenses

dépenses périodiques et les demandes d’achats.

La figure 5.4 représente le formulaire d’ajout d’un fournisseur.

Figure 5.4 : Formulaire d’ajout de fournisseur

La figure 5.5 représente le formulaire d’ajout d’une dépense périodique.

Figure 5.5 : Formulaire d’ajout d’une dépense périodique

La figure 5.6 nous montre La nouvelle liste des dépenses périodiques après l’ajout de l’allocation
du bureau.

75
Chapitre 5. Release 3 : Gestion d’achat et dépenses

Figure 5.6 : La nouvelle liste des dépenses périodiques

Maintenant on va passer une demande d’achat et cette fois-ci nous avons choisi de nous connecter
avec le compte de "Ali" le responsable Rh.
La figure 5.7 nous montre la page des achats et dépenses avec le compte de "Ali" et comme
vous voyez seul l’onglet d’achat est visible pour cet utilisateur.

Figure 5.7 : Interface demande d’achat

Les deux prochaines captures vont nous montrer l’utilisateur "Ali" qui va réaliser une demande
d’achat.

76
Chapitre 5. Release 3 : Gestion d’achat et dépenses

Figure 5.8 : Passer une demande d’achat

Figure 5.9 : la nouvelle liste des demandes d’achats

Nous reconnectons maintenant avec le compte de "Mohamed" et on visite l’onglet "Approbation

en attente". Et voilà on trouve la demande d’achat passée par "Ali" comme nous montre la figure 5.10.

77
Chapitre 5. Release 3 : Gestion d’achat et dépenses

Figure 5.10 : interface approbation en attente

La figure 5.11 représente la liste des demandes en attentes après que "Mohamed" a accepté la
demande.

Figure 5.11 : Demande d’achat acceptée

5.2 sprint 6 :Réalisation du dashboard

Dans cette section nous allons présenter les différents étapes de la réalisation du Dashboard.

5.2.1 Objectifs du sprint 6

L’objectif du sixième sprint est de réaliser le dashboard de l’application.

5.2.2 Backlog du sprint 6

78
Chapitre 5. Release 3 : Gestion d’achat et dépenses

Estimation
Id Fonctionnalités Priorité
(Jour)

En tant qu’utilisateur je veux consulter la liste

1 2 1
des anniversaire de mes collègues pour ce mois.

En tant qu’utilisateur je veux consulter l’état de

2 3 1
mon profil

En tant qu’employé je veux voir la liste des

3 1 2
utilisateurs connectés

En tant que responsable RH je veux gérer les

4 2 1
demandes de congés en attentes

En tant que responsable RH je veux gérer les

5 2 1
demandes de sortie en attentes

En tant que responsable RH je veux consulter la

6 1 1
statistique des utilisateurs présents

En tant que manager je veux gérer les demandes

7 2 1
d’achats en attentes

En tant que manager je veux consulter la

8 1 1
statistique des dépenses périodiques par an

En tant que manager je veux consulter la

9 1 1
statistique des achats effectués

Tableau 5.2 : Backlog du Sprint 6

5.2.3 Spécification des besoins fonctionnels

La figure 5.12 représente le diagramme de cas d’utilisation du sprint "Réalisation du dashboard"

79
Chapitre 5. Release 3 : Gestion d’achat et dépenses

Figure 5.12 : Diagramme de cas d’utilisation "Dashboard"

5.2.4 Analyse du dashboard

Le dashboard de notre application est composé par sept éléments qui sont répartis sur deux
colonnes. Les éléments de la première colonne :

• La section de salutation : cette section contient un message de bienvenue pour l’utilisateur

connecté et elle est visible à tous les rôles de l’application.

80
Chapitre 5. Release 3 : Gestion d’achat et dépenses

• La section des statistiques : cette section contient trois types de statistiques qui sont tous
visibles au manager mais seulement une est visible pour le responsable RH.

• La section des demandes en attentes : Dans l’application Xhrm nous avons trois types
de demandes (les demandes de congés ,les demandes de sortie et les demandes d’achats) pour
cette section Nous voulons donner au responsable Rh et le manager la possibilité de répondre
les demandes en attentes directement à partir du dashboard. Cette section est bien évidemment
visible que pour le responsable RH et le manager.

Les éléments de la deuxième colonne :

• La section d’heure et date : Cette section contient l’heure et la date d’aujourd’hui et elle est
visible pour tous les utilisateurs.

• La section des anniversaires du mois : Cette section contient la liste des anniversaires des
employés de l’entreprise pour le mois présent et elle est visible pour tous les utilisateurs.

• La section de la liste des présences : Cette section contient la liste des utilisateurs qui ont
marqué leur présence pour ce jour et elle est visible pour les utilisateurs qui ont le rôle employé
ou un rôle supérieur.

• La section de l’état du profil : Cette section contient l’état du profil de l’utilisateur ,il va
trouver aussi dans cette section son poste dans l’entreprise et son rôle dans l’application et elle
est visible pour tous les utilisateurs.

5.2.5 Réalisation

Pour la partie réalisation du sprint "Réalisation de dashboard" nous allons chaque fois représenter
une capture de dashboard d’un utilisateur et on va commencer par le dashboard de "Maissa" la
stagiaire.
La figure 5.13 représente le dashboard de "Maissa" la stagiaire.

81
Chapitre 5. Release 3 : Gestion d’achat et dépenses

Figure 5.13 : Dashboard stagiaire

Maintenant nous connectons avec le compte de "Mourad" qui possède le rôle Employé et donc
il va voir de plus la section "liste des présences".
La figure 5.14 représente le dashboard de "Mourad" l’employé.

Figure 5.14 : Dashboard Employé

On passe maintenant au dashboard du Responsable Rh mais avant de déconnecter le compte

de "Mourad" nous allons passer une demande de congé et une demande d’achat comme nous montrent
les deux prochaines captures.

82
Chapitre 5. Release 3 : Gestion d’achat et dépenses

Figure 5.15 : Demande de congé

Figure 5.16 : Demande d’achat

Connectant maintenant avec le compte de "Ali" qui possède le rôle Responsable Rh et on

remarque que deux sections de plus s’affichent. La première c’est la section de statistique mais seule
la statistique des utilisateurs présents est visible pour le responsable Rh. La deuxième c’est la section
des demandes en attentes et on trouve dans la partie des demandes de congé la demande passée par
"Mourad" dans la figure 5.15.
La figure 5.17 représente le dashboard de "Ali" le responsable.

83
Chapitre 5. Release 3 : Gestion d’achat et dépenses

Figure 5.17 : Dashboard Responsable RH

La figure 5.18 représente le dashboard de "Mohamed" le manager. Il n’y a pas des nouvelles
sections mais on remarque que dans la section statistique deux nouvelles statistiques apparaissent, et
dans la section demandes en attentes il y a une onglet de plus pour les demandes d’achats.
Puisque toutes les statistiques sont présentes maintenant nous allons les décrire.
Tout d’abord le pourcentage des utilisateurs présents, on doit se rappeler que seulement "Mourad"
et "Maissa" parmi les quatre utilisateurs qui ont marqué leurs présences on peut aussi remarquer ça
en voyant la section "Équipe présent" et donc c’est pour cela on a juste 50% des utilisateurs présents.
Ensuite on a la statistique des dépenses périodique par an on se rappelle dans la réalisation du
sprint "Gestion d’achat et dépenses" "Mohamed" le Manager a ajouté une dépense périodique pour
l’allocation du bureau avec un montant de 1500 mensuel vous pouvez le voir dans la figure 5.5. Donc
si on fait nos calculs et multiplier le montant de 1500 par 12 mois on va trouver le résultat affiché dans
la deuxième statistique.
Enfin la dernière statistique "le total d’achat", jusqu’à maintenant on a une seule demande
d’achat acceptée, celle passée par "Mourad" dans le sprint précédent vous pouvez le voir dans la figure
5.8. Dans cette demande, "Mourad" a demandé d’acheter 10 ordinateur portable dont le prix de l’unité
est 3500. Et pour cela on trouve ce résultat affiché dans la troisième statistique.

84
Chapitre 5. Release 3 : Gestion d’achat et dépenses

Figure 5.18 : Dashboard Manager

Maintenant on va accepter la deuxième demande d’achat passée par "Mourad" dans la figure
5.16. Dans cette demande "Mourad" veut acheter 3 écran dont le prix de l’unité est 620.
la figure 5.19 nous montre la nouvelle valeur de la troisième statistique après que "Mohamed"
le manager a accepté la demande d’achat de "Mourad".

Figure 5.19 : Statistique des achats

Conclusion

Au cours de ce chapitre, nous avons présenté la réalisation de la troisième et la dernière

Release "Gestion d’achat et dépenses". Pour ce faire, nous avons passé par l’analyse, la conception
et la réalisation du sprint "gestion d’achats et Dépenses" et par l’étude et la réalisation du sprint
"Réalisation du Dashboard"

85
Conclusion générale

Ce rapport présente notre projet de fin d’étude au sein de Tek-Up University et marque
l’aboutissement de notre parcours d’enseignement supérieur. Il nous a permis de mettre en pratique
les connaissances acquises tout au long de notre cursus universitaire, y compris pendant notre stage au
sein de l’entreprise XtendPlex. L’entreprise XtendPlex nous a proposé de développer une application
de gestion des ressources humaines, ayant pour objectif de prendre en charge la gestion des ressources
humaines en simplifiant la gestion du personnel et certaines tâches administratives.
Dans ce rapport, nous avons détaillé l’ensemble des étapes de réalisation du projet, pendant
lequel nous avons pris soin de construire notre application de façon incrémentale et itérative en
utilisant la méthode agile Scrum. Cette méthode, largement utilisée de nos jours notamment par les
entreprises numériques innovantes, permet d’obtenir d’améliorer la célérité et la qualité du processus
de développement d’un projet et de répondre au mieux à la satisfaction des clients.
Durant le stage réalisé auprès de XtendPlex, nous avons pu réaliser six modules de l’application
Xhrm portant respectivement sur :

• La gestion de l’entreprise

• La gestion des utilisateurs et authentification

• La gestion des congés et des autorisations de sortie

• La gestion de présence et compte rendu d’activité

• La gestion des achats et dépenses

• Le Dashboard

L’ensemble de ces fonctionnalités se trouvant ainsi pris en charge par l’application, la gestion des
ressources humaines devient plus simple et plus fluide au quotidien pour les utilisateurs de l’application
en question.
Ce projet n’est pas voué à rester figé dans le temps et des pistes d’amélioration nous apparaissent
déjà sous la forme de nouvelles fonctionnalités qui pourront être ajoutées afin de compléter l’excellente
base que constitue déjà notre application, il s’agira par exemple de la gestion des salaires et des
factures, d’une implémentation de la partie planification ayant pour objectif l’organisation des tâches
des employées ainsi que, l’élaboration d’une fonctionnalité de messagerie instantanée qui permettra
d’améliorer la communication entre les membres de l’entreprise.

86
Bibliographie

[B1] Pierre Pezziardi, Référentiel des Pratiques Agiles, édition ebook.2013

87
Webographie

[1] « image pour comprendre la méthode Agile Scrum. » [Accès le 02/04/2020]. (2/04/2020), adresse :
https://www.tuleap.org/fr/agile/comprendre-methode-agile-scrum-10-minutes/.

[2] « Architecture Angular. » [Accès le 14/06/2020]. (14/06/2020), adresse : https://www.apcpedagogie.

com/structure-et-architecture-dun-projet-angular/.

[3] « Les modules Angular. » [Accès le 26/04/2020]. (26/04/2020), adresse : https://www.learn-

angular.fr/les-modules-angular/.

[4] « Patron singleton. » [Accès le 14/06/2020]. (14/06/2020), adresse : https://www.refactoring.

guru/fr/design-patterns/singleton.

[5] « Patron Proxy. » [Accès le 15/06/2020]. (15/06/2020), adresse : https://www.refactoring.

guru/fr/design-patterns/proxy.

[6] « Patron Etat. » [Accès le 14/06/2020]. (14/06/2020), adresse : https://www.refactoring.

guru/fr/design-patterns/state.

[7] « Bitbucket. » [Accès le 25/04/2020]. (25/04/2020), adresse : https : / / fr . wikipedia . org /

wiki/Bitbucket.

[8] « Bref aperçu de Jira. » [Accès le 25/04/2020]. (25/04/2020), adresse : https://www.atlassian.

com/fr/software/jira.

[9] « Quest-ce que Discord. » [Accès le 25/04/2020]. (25/04/2020), adresse : https://www.pocket-

lint . com / fr - fr / applications / actualites / 151534 - quest - ce - que - la - discorde - et -
comment-utiliser-lapplication-gratuite-de-chat-textuel-voip.

[10] « C’est quoi Angular ? » [Accès le 25/04/2020]. (25/04/2020), adresse : https://monpetitdev.

fr/cest-quoi-angular-definition.

[11] « pring Framework. » [Accès le 25/04/2020]. (25/04/2020), adresse : https : / / spring . io /

projects/spring-framework.

[12] « Postman. » [Accès le 26/04/2020]. (26/04/2020), adresse : https : / / blog . webnet . fr /

presentation-de-postman-outil-multifonction-pour-api-web.

[13] « MySQL Database Service. » [Accès le 26/04/2020]. (26/04/2020), adresse : https : / / www .
mysql.com/fr.

[14] « présentation Jwt. » [Accès le 26/04/2020]. (26/04/2020), adresse : https://www.ionos.fr/

digitalguide/sites-internet/developpement-web/json-web-token-jwt/.

88
Webographie

[15] « présentation spring security. » [Accès le 26/04/2020]. (26/04/2020), adresse : https://www.

invivoo.com/securiser-application-spring-boot-spring-security/.

89
Résumé
Le présent rapport synthétise le travail effectué dans le cadre du projet de fin d’études pour
l’obtention du diplôme national d’ingénieur en informatique au sein de l’entreprise Xtendplex.
L’objectif de ce travail est la conception et l’implémentation d’une application web de gestion
des ressources humaines. Cette application consiste d’une part, de simplifier et d’accélérer le
processus RH, et d’autre part, d’améliorer la communication entre les employés.

Mots clés : Ressources humaines, Spring Boot, Angular, Application web

Abstract
This document summarizes the work carried out as part of the end-of-study project for obtaining
the national software engineering degree during the internship completed within the company
Xtendplex. The main idea behind this project is to design and implement a Human Resources
management web application. This web application is mainly used to accelerate the Human
Resources process and improve the communication between the team members.

Keywords : Human ressource, Spring Boot, Angular, Web application