Rapport Pfe Tekup Latex

République Tunisienne
Ministère de l’Enseignement Supérieur
img/tekup.png et de la Recherche Scientifique img/logo XtendPlex.png
É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 Contexte général du projet 2

1.1 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.3 Solution envisagée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Methodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Méthodologie de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Les rôles dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Analyse et spécification des besoins 7

2.1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Spécification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2 Spécification des besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . 10
2.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Planification de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Backlog product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Répartition des releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Les patrons de conception utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.1 Patrons de création . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.2 Patrons structurels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.3 Patrons comportementaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.4 Patron d’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 Maquette du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6.1 Captures des interfaces de maquette . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6.2 Schéma de navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7 Difficultés rencontrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
iv
2.8 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.8.1 Outils de gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.8.2 Framework de développement et de tests . . . . . . . . . . . . . . . . . . . . . . 27
2.8.3 Système de gestion de base de données . . . . . . . . . . . . . . . . . . . . . . . 28
3 Release 1 : Gestion de l’entreprise et des comptes 30

3.1 Sprint 1 :Module gestion de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.1 Objectifs du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.2 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.5 Diagrammes dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2 sprint 2 :Module gestion des utilisateurs et authentification . . . . . . . . . . . . . . . 41
3.2.3 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.7 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4 Release 2 : Gestion d’activité de ressources humaines 59

4.1 sprint 3 :Module gestion des Congés et des permission des sorties . . . . . . . . . . . . 60
4.1.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2 Sprint 4 :Module gestion de présence et Compte rendu d’activité . . . . . . . . . . . . 74
v
4.2.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5 Release 3 : Gestion d’achat et dépenses 84

5.1 Sprint 5 :Module gestion d’achats et Dépenses . . . . . . . . . . . . . . . . . . . . . . . 85
5.1.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2 sprint 6 :Réalisation du dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.2.4 Analyse du dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.2.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Conclusion générale 107
Bibliographie 109
Webographie 110
vi
Table des figures
1.1 Interface de l’application Zocdoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Interface de l’application Doctolib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Interface de l’application Dokita connect . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Cycle de vie de la méthodologie SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Diagramme cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

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

3.2 Diagramme de classe "Gestion de l’entreprise" . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Diagramme de séquence objet "ajout d’entreprise" . . . . . . . . . . . . . . . . . . . . 34
3.4 interface de création de compte entreprise 1.0 . . . . . . . . . . . . . . . . . . . . . . . 35
vii
Table des figures

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

4.2 Diagramme de classe "Gestion de congé et autorisation . . . . . . . . . . . . . . . . . . 63
4.3 Diagramme de séquence système "Traiter une demande de congé" . . . . . . . . . . . . 64
4.4 Diagramme d’état transition "État d’une demande" . . . . . . . . . . . . . . . . . . . . 65
4.5 interface demande de congé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.6 formulaire de demande de congé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.7 demande de congé ajoutée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.8 interface demande d’autorisation de sortie . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.9 formulaire demande d’autorisation de sortie . . . . . . . . . . . . . . . . . . . . . . . . 70
4.10 interface approbation en attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.11 la demande est acceptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
viii
4.12 interface vue global des congés par utilisateur . . . . . . . . . . . . . . . . . . . . . . . 73
4.13 historique des demandes de sortie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.14 Diagramme de cas d’utilisation "Gestion de présence et compte rendu d’activité" . . . 76
4.15 Diagramme de classe "Gestion de présence" . . . . . . . . . . . . . . . . . . . . . . . . 77
4.16 Diagramme de séquence objet "marquer l’heure d’entrée" . . . . . . . . . . . . . . . . 78
4.17 interface du pointage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.18 Liste du présence après le ClockIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.19 Interface du présence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.20 Compte rendu d’activité du Responsabe RH ’Ali’ . . . . . . . . . . . . . . . . . . . . . 82
4.21 Compte rendu d’activité de l’employé ’Mourad’ . . . . . . . . . . . . . . . . . . . . . . 83
5.1 Diagramme de cas d’utilisation "Gestion d’achats et dépenses" . . . . . . . . . . . . . 86

5.2 Diagramme de classe "Gestion d’achats et dépenses" . . . . . . . . . . . . . . . . . . . 87
5.3 Diagramme de séquence système "traiter une demande d’achat" . . . . . . . . . . . . . 88
5.4 Formulaire d’ajout de fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.5 Formulaire d’ajout d’une dépense périodique . . . . . . . . . . . . . . . . . . . . . . . . 90
5.6 La nouvelle liste des dépenses périodiques . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.7 Interface demande d’achat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.8 Passer une demande d’achat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.9 la nouvelle liste des demandes d’achats . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.10 interface approbation en attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.11 Demande d’achat acceptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.12 Diagramme de cas d’utilisation "Dashboard" . . . . . . . . . . . . . . . . . . . . . . . 98
5.13 Dashboard stagiaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.14 Dashboard Employé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.15 Demande de congé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.16 Demande d’achat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.17 Dashboard Responsable RH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.18 Dashboard Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.19 Statistique des achats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
ix
Liste des tableaux
2.1 Produit backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Répartition des releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32



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‘avènement de l’informatique médicale a marqué une révolution majeure dans le domaine

de la santé, transformant fondamentalement la manière dont les soins de santé sont administrés et
gérés. L’intégration de technologies informatiques au sein du secteur médical a ouvert la voie à des
avancées significatives, améliorant l’efficacité des services médicaux, la qualité des soins et la gestion
des informations médicales. L’informatisation médicale englobe un large éventail d’applications, allant
de la gestion électronique des dossiers médicaux à la télémédecine, en passant par l’analyse de données
massives et l’intelligence artificielle. Ces technologies ont permis une meilleure coordination entre les
professionnels de la santé, favorisant une prise en charge plus rapide et plus précise des patients.
Dans cette ère numérique, les dossiers médicaux électroniques jouent un rôle central, remplaçant
progressivement les archives papier. Cette transition vers une approche informatisée offre non seulement
une accessibilité accrue aux données médicales, mais garantit également la sécurité, la confidentialité
et l’intégrité des informations sensibles des patients. Dans ce contexte s’intègre ce projet qui consiste
à réaliser un système de gestion des rendez-vous médicaux intitulé « MEDONTIME ». On est appelé
à concevoir et développer un système incluant des interfaces claires et faciles afin de mettre en place
une application web pour rapprocher le médecin de ses patients et faciliter le processus de prise de
rendez-vous.
Le présent rapport sera organisé de la manière suivante :
• Contexte général du projet où on va présenter le projet, étudier l’existant et définir la méthodologie
adoptée.
• Analyse et spécifications des besoins où on va identifier les besoins fonctionnels et non fonctionnels
ainsi que les acteurs de l’application.
• Conception et choix technologique où on va la partie conceptuelle du projet, ainsi que les

technologies utilisées tout au long du projet.
• Réalisation où on présenter les interfaces réalisées.
1
Chapitre 1
Contexte général du projet
Plan
1 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Methodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Chapitre 1. Contexte général du projet
Introduction
Dans ce chapitre on présentera une étude préalable qui est une étape essentielle afin d’analyser,
d’évaluer et de critiquer des applications similaires pour proposer une solution adaptée, ainsi qu’on
présentera la méthdlgie adaptée pour effectuer cette application.
1.1 Etude de l’existant
L’étude de l’existant est une phase primordiale pour la réalisation d’un projet. En effet elle
consiste à observer et à analyser les solutions existantes puis à déterminer leurs points faibles et leurs
points forts afin de les prendre en considération lors de la réalisation de l’application en question. Elle
comporte trois parties : description de l’existant, critique de l’existant et la solution envisagée.
1.1.1 Description de l’existant
• Zocdoc : Zocdoc facilite la recherche de professionnels de la santé et la prise de rendez-vous en

ligne. Il propose également des fonctionnalités telles que la vérification de l’assurance maladie et
des avis de patients.
Figure 1.1 : Interface de l’application Zocdoc
• Doctolib : Doctolib est une plateforme populaire de prise de rendez-vous médicaux en ligne.
Les patients peuvent rechercher des professionnels de la santé, consulter leurs disponibilités en
temps réel et prendre rendez-vous instantanément.
3
Figure 1.2 : Interface de l’application Doctolib
• Dokita connect : est une plateforme qui permet aux patients de prendre rendez-vous avec
des médecins, de consulter des informations sur les praticiens et de recevoir des rappels de
rendez-vous.
Figure 1.3 : Interface de l’application Dokita connect
1.1.2 Critique de l’existant
Application Critique
DokitaConnect Les utilisateurs ont salué la convivialité de

DokitaConnect, mais certains ont suggéré des
améliorations en termes de personnalisation des
rappels et de fonctionnalités de suivi médical.
4
Doctolib Doctolib est largement utilisé et apprécié pour

sa facilité d’utilisation. Cependant, certaines
critiques concernent parfois la difficulté à obtenir
des rendez-vous rapidement avec des médecins
très demandés.
Zocdoc Zocdoc est salué pour sa simplicité et son

interface conviviale, mais certains utilisateurs
ont signalé des problèmes de synchronisation
avec les calendriers des médecins, entraînant
parfois des erreurs de disponibilité.
1.1.3 Solution envisagée
En se basant sur l’étude des applications de prise de rendez-vous médicaux, on a choisi de

mettre en place une solution de réservation de consultations médicales en ligne dotée de capacités
de gestion des dossiers médicaux est conçue pour révolutionner l’accès aux soins de santé en offrant
aux utilisateurs une expérience complète et transparente. On répond à la demande croissante de soins
médicaux efficaces et personnalisés en simplifiant la planification des rendez-vous médicaux. En outre,
la gestion sécurisée des dossiers médicaux électroniques crée un environnement de confiance pour les
utilisateurs et garantit l’intégrité des informations médicales.
1.2 Methodologie de travail
Au cours du développement des projets informatiques, il est indispensable de respecter une

démarche bien déterminée pour assurer un bon rendement de développement en termes de qualité et
de productivité. C’est pour cela que le choix de la méthodologie en informatique est primordial. Les
méthodologies de développement suivent une séquence d’étapes ordonnées qui permet d’obtenir un
système informatique performant qui répond aux différents besoins des utilisateurs dans des intervalles
de temps.
1.2.1 Méthodologie de SCRUM
SCRUM est l’une des méthodes les plus utilisées pour la gestion des projets informatiques. Son
objectif est d’offrir plus de souplesse à l’équipe. Un projet qui suit « SCRUM » comporte un « Product
backlog » qui représente une liste ordonnée des fonctionnalités à développer pour atteindre un objectif
bien déterminé. De son tour le « Product backlog » est divisé en un « sprint backlog » qui est basé
5
sur la division des flux de travail en « Sprint » qui est un intervalle de temps généralement entre
deux et quatre semaines. À la fin de chaque sprint il y aura un livrable qui présente de son tour les
fonctionnalités accomplies.
La figure 1.4 représente le parcours de la méthodologie de SCRUM.
Figure 1.4 : Cycle de vie de la méthodologie SCRUM
1.2.2 Les rôles dans SCRUM
La méthodologie d’agile SCRUM implique trois rôles principaux qui sont :
• Product owner : C’est l’expert produit qui représente les parties prenantes et peut être aussi
le client, le propriétaire du projet, ou le chef d’entreprise.
• Scrum master : C’est le chef d’équipe qui assure la compréhension et l’exécution de Scrum. Il
contrôle l’équipe et organise le travail.
• Scrum team : Est un groupe de membres qui travaille sur l’exécution du produit (développeurs,
programmeurs, designers...).
Conclusion
Dans ce premier chapitre, on a défini l’étude de l’existant afin de préciser notre objectif à
atteindre vers la fin accompagnée d’une solution proposée et le choix de la méthodologie appliquée.
Dans le chapitre qui suit, on présentera l’analyse et la spécification des besoins.
6
Chapitre 2
Analyse et spécification des besoins
Plan
1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Planification de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5 Les patrons de conception utilisés . . . . . . . . . . . . . . . . . . . . . . . . 17
6 Maquette du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7 Difficultés rencontrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Chapitre 2. Analyse et spécification des besoins
Introduction
Ce chapitre vise à capter les besoins et les rôles des utilisateurs qui utilisent l’application. Dans
un premier lieu, on commence par définir les acteurs, par la suite on spécifie les besoins fonctionnels
et non fonctionnels. Au niveau de la deuxième partie on va analyser ces besoins par l’insertion de
diagramme des cas d’utilisations global et diagramme de classes.
2.1 Spécification des besoins
2.1.1 Spécification des besoins fonctionnels
2.1.1.1 Identification des acteurs
Un acteur définit un rôle joué par une personne externe qui interagit avec le système. Il peut
être parmi les utilisateurs du système et parmi les responsables de sa configuration
• Administrateur : L’administrateur possède les droits d’ajout, de consultation, de suppression

et de modification des utilisateurs, des réservations, des consultations
• Docteur : Le docteur a le privilège d’accéder, de mettre à jour et de gérer les dossiers médicaux
des patients, de planifier des rendez-vous, et de consulter les réservations liées à sa pratique
médicale.
• Patient : Le patient peut consulter son dossier médical, prendre des rendez-vous en ligne, mettre
à jour ses informations personnelles, et prendre des rendez-vous en fonction des disponibilités des
médecins.
2.1.1.2 Spécification des besoins fonctionnels par acteur
• Administrateur :
— Gérer son profil.
— Consulter son dashboard.
— Gérer les utilisateurs.
— Rechercher un utilisateur.
• Docteur :
8
— Consulter la liste de ses patients.
— Consulter la liste de ses rendez-vous.
— Gérer les dossiers médicaux.
— Gérer les consultations.
— Approuver / Refuser un rendez-vous .
• Patient :
— Consulter la liste de ses rendez-vous.
— Consulter son dossier médical.
— Annuler un rendez-vous.
9
2.1.1.3 Diagramme de cas d’utilisation global
Figure 2.1 : Diagramme cas d’utilisation global
2.1.2 Spécification des besoins non fonctionnels
Les besoins non fonctionnels définissent les options internes essentielles pour améliorer le fonctionnement
du système. Pour cela, notre future application doit répondre aux critères suivants :
• La sécurité : L’application doit garantir la sécurité des données des utilisateurs ce qui
nécessite un mot de passe enregistré dans la base de données crypté et un jeton généré
après chaque authentification. L’utilisateur peut profiter du jeton qui offre un accès à une
ressource spécifique pour une période précise sur notre plateforme.
• 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
10
(SideBar).
• La disponibilité : L’application doit être disponible à tout instant pour être utilisée par
n’importe quel utilisateur, elle doit être accessible facilement via n’importe quel navigateur.
• Performance : Afin d’offrir un service de qualité, l’application doit être performante au

niveau de temps de réponse.
• Fiabilité : Afin d’offrir un service de qualité, l’application doit être performante au niveau
de temps de réponse.
2.2 Diagramme de classe
Ci-dessous dans la figure ??, nous représentons le diagramme de classe global de notre
application. Nous détaillons ses classes dans chaque sprint.
Figure 2.2 : Diagramme de classe global
2.3 Planification de travail
2.3.1 Backlog product
Feature En tant que Je veux Afin de Priorité
Authentification Utilisateur M’authentifier Avoir accès à Priorité

l’application
Gestion des Utilisateur Consulter mon Visualiser les M

utilisateurs dashboard statistiques relatives à
l’application
Admin Consulter Visualiser leurs F
la liste des informations
patients
11
Admin Consulter Visualiser leurs F

la liste des informations
docteurs
Admin Ajouter un Joindre un docteur à F
docteur l’application
Admin Modifier un Mettre à jour ses F
docteur informations
Admin Supprimer un Archiver un utilisateur F
docteur
Admin Chercher un Trouver un utilisateur F
utilisaeur spécifique
Gestion des Patient Créer un RDV Réserver un rendez-vous F

rendez-vous avec un docteur
Patient Consulter mes Visualiser les M
rendez-vous informations de tous
mes rendez-vous
Patient Annuler un Archiver un rendez-vous M
rendez-vous
Docteur Consulter la Visualiser les F
liste de mes informations de mes
rendez-vous rendez-vous
Docteur Approuver / Confirmer ou non un H
Refuser un rendez-vous
RDV
Gestion Docteur Créer un Ajouter des M

des dossier dossier médical informations concernant
médicaux l’état d’un patient
Docteur Modifier un Mettre à jour les M
dossier médical informations de l’état
d’un patient
Docteur Supprimer un Archiver un dossier M
dossier médical médical
12
Docteur Consulter Visualiser la liste des M

les dossier dossiers médicaux
médicaux
Patient Consulter Visualiser quelques
mon dossier informations à propos
médicale mon état
Gestion des Docteur Créer une Ajouter les informations M

consultations consultation d’une consultation
Docteur Modifier une Mettre à jour les M
consultation informations d’une
consultation
Docteur Supprimer une Archiver une M
consultation consultation
Docteur Consulter Visualiser la liste des M
la liste des consultations
consultations
Gestion profil Utilisateur Consulter mon Visualiser mes M

utilisateur profil informations
Utilisateur Changer mon Mettre à jour mon mot M
mot de passe de passe
Utilisateur Supprimer Archiver mon compte M
mon compte
Tableau 2.1 : Produit backlog
2.3.2 Répartition des releases
Release
Nom du Sprint
ID
• Sprint 1 :Authentification
1
• Sprint 2 :Gestion des utilisateurs .
13
Release
Nom du Sprint
ID
• sprint 3 :Gestion des rendez-vous

2
• Sprint 4 :Gestion des dossiers médicaux
• Sprint 5 : Gestion des consiltations

3
• Sprint 6 : Gestion profil utilisateur
Tableau 2.2 : Répartition des releases
2.3.3 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.
14
img/gantt.png.png
Figure 2.3 : Planification des sprints
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.
15
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)
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 [1] :
— 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)[2]
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é
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.
16
• 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.[3] :
On utilise ce patron souvent en utilisant spring boot lors de l’injection de dépendance avec
l’annotation Autowired ou bien Inject.
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.[4] :
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.[5] :
17
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 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.
18
Figure 2.7 : Interface "S’authentifier"
La figure 2.8 représente l’interface dashboard de l’application.
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.
19
img/SchNav_Global.jpg
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.
20
img/SchNav_Stagiaire.jpg
Figure 2.11 : Schéma de navigation d’un stagiaire
• Consultant :
La figure 2.12 représente le schéma de navigation du consultant.
21
img/SchNav_Consultant.jpg
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é.
22
img/SchNav_Employe.jpg
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.
23
img/SchNav_RH.jpg
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.
24
img/ShcNav_Manager.jpg
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
2.8 Environnement de travail
2.8.1 Outils de gestion de projet
• Bitbucket
25
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.[6]
img/bitbucket.jpg
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.[7]
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.
img/jira.png
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.[8]
26
img/discord-logo.jpg
Figure 2.18 : Logo Discord
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.[9]
img/angular-10.png
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.[10]
27
img/spring-boot-logo.png
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.[11]
img/postman.png
Figure 2.21 : Logo postman
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.[12]
28
img/Mysql.png
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.
29
Chapitre 3
Release 1 : Gestion de
l’entreprise et des comptes
Plan
1 Sprint 1 :Module gestion de l’entreprise . . . . . . . . . . . . . 31
2 sprint 2 :Module gestion des utilisateurs et authentification . . 41

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
31
Estimation
(Jour)
Tableau 3.1 : Backlog du Sprint 1
La figure 3.1 représente le diagramme cas d’utilisation du sprint "Gestion de l’entreprise"
img/UCGestionEntreprise.png
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
32
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.
— Un rôle est caractérisé par (id rôle, nom rôle) et peut être attribué à plusieurs utilisateurs.
img/CDGestionEntreprise.PNG
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.
33
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.
img/SOaddEntreprise.png
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.
34
img/Sp1Capture1.PNG
Figure 3.4 : interface de création de compte entreprise 1.0
35
img/Sp1Capture2.PNG
36
img/Sp1Capture3.PNG
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
img/Sp1Capture4.PNG
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.
38
img/Sp1Capture5.PNG
Figure 3.8 : interface poste et département
39
img/Sp1Capture6.PNG
Figure 3.9 : interface ajout du poste
40
img/Sp1Capture7.PNG
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".
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
41
Estimation
(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
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.[13]
42
• 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[14]
La figure 3.11 représente le diagramme cas d’utilisation du sprint "Gestion des utilisateurs
et authentification"
img/UCGestionUtilisateurs.png
Figure 3.11 : Diagramme de cas d’utilisation "Gestion des utilisateurs"
43
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.
— Un rôle est caractérisé par (id rôle, nom rôle) et peut être attribué à plusieurs utilisateurs.
img/CDGestionUtilisateur.PNG
Figure 3.12 : Diagramme de classe "Gestion des utilisateurs"
44
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.
img/SOauthentication.png
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
45
d’un utilisateur.
img/SSaddUser.png
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.
46
img/diagrammeactivitÃľ.jpg
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.
47
img/Sp2Capture1.PNG
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.
48
img/Sp2Capture2.PNG
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".
49
img/Sp2Capture3.PNG
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.
50
img/Sp2Capture4.PNG
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.
51
img/Sp2Capture5.PNG
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.
52
img/Sp2Capture6.PNG
Figure 3.21 : Interface gestion du profil
53
img/Sp2Capture7.PNG
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.
54
img/Sp2Capture8.PNG
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.
55
img/Sp2Capture9.PNG
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.
56
img/Sp2Capture10.PNG
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.
57
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.
58
Chapitre 4
Release 2 : Gestion d’activité de

ressources humaines
Plan
1 sprint 3 :Module gestion des Congés et des permission des sorties 60
2 Sprint 4 :Module gestion de présence et Compte rendu d’activité

74
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".
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.
Estimation
(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
60
Estimation
(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
La figure 4.1 représente le diagramme de cas d’utilisation du sprint "Gestion de congé et

autorisation"
61
img/UCGestionCongÃľ&Sortie.png
Figure 4.1 : Diagramme de cas d’utilisation "Gestion de congé et autorisation"
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).
62
img/CDGestionCongÃľ.PNG
Figure 4.2 : Diagramme de classe "Gestion de congé et autorisation
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é.
63
img/SStimeOff.png
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.
64
img/EtatTransitionAchat.png
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é
65
— 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.
img/Sp3Capture1.PNG
Figure 4.5 : interface demande de congé
La figure 4.6 représente le formulaire de demande de congé.
66
img/Sp3Capture2.PNG
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.
67
img/Sp3Capture3.PNG
Figure 4.7 : demande de congé ajoutée
La figure 4.8 représente l’interface des autorisations de sortie.
68
img/Sp3Capture4.PNG
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.
69
img/Sp3Capture5.PNG
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.
70
img/Sp3Capture7.PNG
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é.
71
img/Sp3Capture8.PNG
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é.
72
img/Sp3Capture9.PNG
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.
73
Figure 4.13 : historique des demandes de sortie
4.2 Sprint 4 :Module gestion de présence et Compte rendu

d’activité
"Gestion de présence et Compte rendu d’activité".
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.
74
Estimation
(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
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

5 5 3
liste des pointages

6 6 1
liste des présences

7 6 1
liste des absences
La figure 4.14 représente le diagramme cas d’utilisation du sprint "Gestion de présence et

compte rendu d’activité".
75
img/UCPointage&Presence.png
Figure 4.14 : Diagramme de cas d’utilisation "Gestion de présence et compte rendu d’activité"
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).
76
img/CDGestionPrÃľsence.PNG
Figure 4.15 : Diagramme de classe "Gestion de présence"
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.
77
img/SOpresence.png
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.
78
img/Sp4Capture1.PNG
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.
79
img/Sp4Capture2.PNG
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.
80
img/Sp4Capture3.PNG
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.
81
img/Sp4Capture5 cra_ali.PNG
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.
82
img/Sp4Capture6 cra_mourad.png
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é".
83
Chapitre 5
Release 3 : Gestion d’achat et

dépenses
Plan
1 Sprint 5 :Module gestion d’achats et Dépenses . . . . . . . . . . 85
2 sprint 6 :Réalisation du dashboard . . . . . . . . . . . . . . . . . 96

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
"Gestion d’achats et Dépenses".
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.
Estimation
(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
85
Estimation
(Jour)
7 En tant que manager je veux gérér les fournisseurs 3 2
La figure 5.1 représente le diagramme de cas d’utilisation du sprint "Gestion d’achats et

dépenses".
img/UCGestionAchat.png
Figure 5.1 : Diagramme de cas d’utilisation "Gestion d’achats et dépenses"
La figure 5.2 représente le diagramme de classe du sprint "Gestion d’achats et dépenses".
86
— 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.
img/CDGestionAchat.PNG
Figure 5.2 : Diagramme de classe "Gestion d’achats et dépenses"
Dans cette section nous allons présenter le diagramme de séquence système "traiter une
demande d’achat"
87
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.
img/SSpurchase.png
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 dépenses périodiques et les demandes d’achats.
La figure 5.4 représente le formulaire d’ajout d’un fournisseur.
88
img/Sp5Capture1.PNG
Figure 5.4 : Formulaire d’ajout de fournisseur
La figure 5.5 représente le formulaire d’ajout d’une dépense périodique.
89
img/Sp5Capture3 addPeriodicDepense.PNG
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.
90
img/Sp5Capture4 depenseAdded.png
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.
91
img/Sp5Capture5 Rh Achat.png
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.
92
img/Sp5Capture6 Rh purchaseDemand.png
Figure 5.8 : Passer une demande d’achat
93
img/Sp5Capture7 Rh purchaseDemand added.png
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.
94
img/Sp5Capture8 Approbation en attente.png
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.
95
img/Sp5Capture9 PurchaseAccepted.png
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.
L’objectif du sixième sprint est de réaliser le dashboard de l’application.
Estimation
(Jour)
96
Estimation
(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

4 2 1
demandes de congés en attentes

5 2 1
demandes de sortie en attentes

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
La figure 5.12 représente le diagramme de cas d’utilisation du sprint "Réalisation du dashboard"
97
img/UCDashboard.png
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.
• 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.
98
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.
99
img/Sp6Capture2 Dash_Maissa.PNG
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é.
100
img/Sp6Capture1 Dash_Mourad.PNG
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.
101
img/Sp6Capture5 DemandeCongÃľ.PNG
Figure 5.15 : Demande de congé
102
img/Sp6Capture6 DemandAchat.PNG
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.
103
img/Sp6Capture4 Dash_Ali.PNG
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
104
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.
img/Sp6Capture3.PNG
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".
105
img/Sp6Capture7 DemandAchatAcceptÃľ.png
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"
106
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
107
Conclusion générale
les membres de l’entreprise.
108
Bibliographie
[B1] Pierre Pezziardi, Référentiel des Pratiques Agiles, édition ebook.2013
109
Webographie
[1] « Architecture Angular. » [Accès le 14/06/2020]. (14/06/2020), adresse : https://

www.apcpedagogie.com/structure-et-architecture-dun-projet-angular/.
[2] « Les modules Angular. » [Accès le 26/04/2020]. (26/04/2020), adresse : https://

www.learn-angular.fr/les-modules-angular/.
[3] « Patron singleton. » [Accès le 14/06/2020]. (14/06/2020), adresse : https://www.

refactoring.guru/fr/design-patterns/singleton.
[4] « Patron Proxy. » [Accès le 15/06/2020]. (15/06/2020), adresse : https : / / www .

refactoring.guru/fr/design-patterns/proxy.
[5] « Patron Etat. » [Accès le 14/06/2020]. (14/06/2020), adresse : https://www.refactoring.

guru/fr/design-patterns/state.
[6] « Bitbucket. » [Accès le 25/04/2020]. (25/04/2020), adresse : https://fr.wikipedia.

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

atlassian.com/fr/software/jira.
[8] « 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.
[9] « C’est quoi Angular ? » [Accès le 25/04/2020]. (25/04/2020), adresse : https : / /

monpetitdev.fr/cest-quoi-angular-definition.
[10] « pring Framework. » [Accès le 25/04/2020]. (25/04/2020), adresse : https://spring.

io/projects/spring-framework.
[11] « Postman. » [Accès le 26/04/2020]. (26/04/2020), adresse : https://blog.webnet.

fr/presentation-de-postman-outil-multifonction-pour-api-web.
[12] « MySQL Database Service. » [Accès le 26/04/2020]. (26/04/2020), adresse : https:

//www.mysql.com/fr.
[13] « 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/.
110
Webographie
[14] « présentation spring security. » [Accès le 26/04/2020]. (26/04/2020), adresse : https:

//www.invivoo.com/securiser-application-spring-boot-spring-security/.
111
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

Rapport Pfe Tekup Latex

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Pfe Tekup Latex

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Ministère de l’Enseignement Supérieur

img/tekup.png et de la Recherche Scientifique img/logo XtendPlex.png

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

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

Conception et développement d’une application

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

Année Universitaire 2020 - 2021

Encadrant professionnel, M. Oussema SLIMANI

Encadrant académique, M. Wissem ELJAOUED

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

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

M. Wael MERSNi et M. Oussema SLIMANI.

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

examiner et juger ce travail.

1 Contexte général du projet 2

2 Analyse et spécification des besoins 7

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

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

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

Conclusion générale 107

1.1 Interface de l’application Zocdoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

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

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

3.5 interface de création de compte entreprise 1.1 . . . . . . . . . . . . . . . . . . . . . . . 36

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

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

2.1 Produit backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Backlog du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.1 Backlog du Sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

— API = Application Programming Interface

— DAO = Data Access Object

— 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

— JSON = JavaScript Object Notation

— JWT = JSON Web Token

— REST = Representational state transfer

— UML = Unified Modeling Language

L‘avènement de l’informatique médicale a marqué une révolution majeure dans le domaine

• Conception et choix technologique où on va la partie conceptuelle du projet, ainsi que les

• Réalisation où on présenter les interfaces réalisées.

Contexte général du projet

1.1 Etude de l’existant

1.1.1 Description de l’existant

• Zocdoc : Zocdoc facilite la recherche de professionnels de la santé et la prise de rendez-vous en

Figure 1.1 : Interface de l’application Zocdoc

Figure 1.2 : Interface de l’application Doctolib

Figure 1.3 : Interface de l’application Dokita connect

1.1.2 Critique de l’existant

DokitaConnect Les utilisateurs ont salué la convivialité de

Doctolib Doctolib est largement utilisé et apprécié pour

Zocdoc Zocdoc est salué pour sa simplicité et son

1.1.3 Solution envisagée

En se basant sur l’étude des applications de prise de rendez-vous médicaux, on a choisi de

1.2 Methodologie de travail

Au cours du développement des projets informatiques, il est indispensable de respecter une

1.2.1 Méthodologie de SCRUM