République Tunisienne Département d’Informatique

Ministère de l’enseignement supérieur et de la

recherche scientifique Année Universitaire : 2023-2024
Université de Gafsa
Faculté des Sciences de Gafsa Code mémoire :16/24

Mémoire de Projet de Fin d’Etude

Présenté en vue de l’obtention du

DIPLÔME DE LICENCE EN SCIENCES DE L’INFORMATIQUE-

GLSI
-------------------------------------------------------------------------
Plateforme de gestion des personnels, formations,
emplois et compétences
-------------------------------------------------------------------------
Réalisé par : Takoua Hichri

Sous la direction de : - Dr. Raik Aissaoui

- Mr Aymen Balti

Soutenu publiquement le 10/06/2024 devant le jury

Président : Mme. Fatma ABBESS

Membre : Mme. Rim AFDHAL

Membre : Mr. Raik Aissaoui

Année Universitaire : 2023/2024

Dédicaces

Je dédie ce travail à toutes les personnes qui ont contribué, de près ou de

loin, à la réalisation de ce projet.

À mon cher papa, à ma chère maman,

pour leur soutien indéfectible, leur amour inconditionnel et leurs
encouragements constants. Votre confiance en moi a été une source
d’inspiration tout au long de ce parcours.

À mes professeurs et encadrants ,

pour leurs précieux conseils, leur disponibilité et leur expertise. Vous avez
su m’orienter et me motiver, et pour cela, je vous en suis profondément
reconnaissante.

À mes amis et collègues,

pour leur camaraderie, leur aide précieuse et leurs moments de partage.
Votre présence a rendu ce voyage plus agréable et moins solitaire.

À mon cher frère et ma petite sœurs ,

Merci pour la joie que vous me procurez.
Enfin, à tous ceux qui, par leurs paroles ou leurs actes, m’ont soutenue
et encouragée durant ces années d’études. Ce travail est autant le vôtre que
le mien.

Takoua HICHRI
i
Remerciements

Je tiens à exprimer ma gratitude à Dieu pour m’avoir doté de

la force et du moral nécessaires à l’accomplissement de ce
travail.
Je remercie profondément mes parents pour leur soutien
indéfectible et leur aide constante en toutes circonstances.
Je suis particulièrement reconnaissante aux membres du jury
qui m’honorent en acceptant de juger ce travail.
Mes remerciements les plus sincères vont à mon encadrant,
Monsieur Raik AISSAOUI, pour ses précieux conseils et
la confiance qu’il m’a accordée tout au long de ce projet.
Je remercie également Monsieur Aymen Balti, mon
encadrant au sein de la société ArabSoft, pour la qualité de son
encadrement et ses conseils avisés, qui ont été d’une aide
inestimable tout au long de ce projet.

Takoua HICHRI
ii
Table des matières

Introduction générale 1
1 Contexte général 3
1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Ses services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Les métiers de ArabSoft . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Étude et critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Description et critique de l’existant . . . . . . . . . . . . . . . . . . 6
1.2.2 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Travail demandé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1 Méthodes agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2 Méthodologie retenue . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.3 Rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
[Link] Product Owner . . . . . . . . . . . . . . . . . . . . . . . . 10
[Link] Scrum Master . . . . . . . . . . . . . . . . . . . . . . . . . 11
[Link] Équipe Scrum . . . . . . . . . . . . . . . . . . . . . . . . . 11
[Link] Daily Standup Meeting . . . . . . . . . . . . . . . . . . . 11
[Link] Scrum Board . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Présentation du diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . 12
2 Sprint 0 : Initiation du projet 13
2.1 Cadrage de besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
[Link] Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . 14
[Link] Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . 15
2.1.2 Diagramme de cas d’utilisation globale . . . . . . . . . . . . . . . . 15
2.2 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

iii
 2.3 Architecture globale de l’application . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.2 Environnement de développement . . . . . . . . . . . . . . . . . . . 19
2.4.3 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Sprint 1 : Authentification, Consulter ses informations 21
3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1 Diagramme de cas d’utilisation raffiné « Sprint 1 » . . . . . . . . . 23
3.2.2 Description de cas d’utilisation raffiné « Sprint1 » . . . . . . . . . . 23
[Link] Description du cas d’utilisation « Authentification » . . 23
[Link] Description du cas d’utilisation « Consulter Ses infor-
mations » . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1 Scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
[Link] Diagramme de séquence « Authentification » . . . . . . 26
[Link] Diagramme de séquence « Consulter ses informations » 27
3.3.2 Diagramme de Classes . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Sprint 2 : Gérer Formations, Gérer utilisateurs, Approuver les de-
mandes de formation 30
4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1 Diagramme de cas d’utilisation raffiné « Sprint 2 » . . . . . . . . . 32
4.2.2 Description de cas d’utilisation raffiné « Sprint 2 » . . . . . . . . . 33
[Link] Description du cas d’utilisation « Créer une demande
de formation » . . . . . . . . . . . . . . . . . . . . . . . 33
[Link] Description du cas d’utilisation « Approuver des de-
mandes de formation » . . . . . . . . . . . . . . . . . 34
4.2.3 Diagramme de cas d’utilisation raffiné « Gérer utilisateurs » . . . . 35
4.2.4 Description de cas d’utilisation raffiné «Sprint 2 :Gérer utilisateurs» 36
[Link] Description du cas d’utilisation « Gérer utilisateurs » . 36
4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.1 Scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
[Link] Diagramme de séquence « Créer une demande de for-
mation » . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

iv
 [Link] Diagramme de séquence « Approuver la demande de
formation » . . . . . . . . . . . . . . . . . . . . . . . . . 41
[Link] Diagramme de séquence « Ajouter utilisateur » . . . . 42
[Link] Diagramme de séquence « Supprimer utilisateur » . . 43
4.3.2 Diagramme de Classes . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5 Sprint 3 : Gestion des emplois et compétences 50
5.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.1 Diagramme de cas d’utilisation raffiné « Sprint 3 » . . . . . . . . . 52
5.2.2 Description de cas d’utilisation raffiné « Sprint 3 » . . . . . . . . . 54
[Link] Description du cas d’utilisation « Gérer les emplois » . 54
[Link] Description du cas d’utilisation « Gérer les compétences
» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.1 Scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
[Link] Diagramme de séquence « Ajouter Emlpoi » . . . . . . 62
[Link] Diagramme de séquence « Supprimer Emploi » . . . . 63
[Link] Diagramme de séquence « Modifier Compétence » . . 64
5.3.2 Diagramme des Classes . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3.3 Description des classes . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Conclusion générale 68

Bibliographie 69

v
Table des figures

1.1 Logo organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Le progiciel SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Cycle de vie SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . . . 16

2.2 Architecture Globale de l’application . . . . . . . . . . . . . . . . . . . . . 18

3.1 Diagramme de cas d’utilisation raffiné "Sprint 1" . . . . . . . . . . . . . . 23

3.2 Diagramme de séquence "S’authentifier" . . . . . . . . . . . . . . . . . . . 26
3.3 Diagramme de séquence "Consulter ses informations" . . . . . . . . . . . . 27
3.4 Diagramme de classe du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Interface Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6 Interface consulter ses informations . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Diagramme de cas d’utilisation raffiné du Sprint 2 "Gestion des formations

et Approuver les demandes de formation" . . . . . . . . . . . . . . . . . . 33
4.2 Diagramme de cas d’utilisation raffiné du Sprint 2 "Gérer utilisateurs" . . 36
4.3 Diagramme de séquence "Créer une demande de formation" . . . . . . . . 41
4.4 Diagramme de séquence "Approuver une demande de formation " . . . . . 42
4.5 Diagramme de séquence "Ajouter utilisateur" . . . . . . . . . . . . . . . . 43
4.6 Diagramme de séquence "Supprimer utilisateur" . . . . . . . . . . . . . . . 43
4.7 Diagramme de classe du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . 44
4.8 Page gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.9 Interface "Modifier un utilisateur" . . . . . . . . . . . . . . . . . . . . . . . 46
4.10 Interface "Supprimer un utilisateur" . . . . . . . . . . . . . . . . . . . . . 46
4.11 Interface "Ajouter un utilisateur " . . . . . . . . . . . . . . . . . . . . . . . 47
4.12 interface "créer une demande de Formation" . . . . . . . . . . . . . . . . . 47

vi
4.13 Interface gérer formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.14 Interface Approuver formation . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.15 Interface Approuver formation . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.16 Interface gérer formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1 Diagramme de cas d’utilisation raffiné du troisième Sprint "Gestion des

emplois" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Diagramme de cas d’utilisation raffiné du troisième Sprint "Gestion des
compétences" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3 Diagramme de séquence "Ajouter Emlpoi " . . . . . . . . . . . . . . . . . . 62
5.4 Diagramme de séquence "Supprimer Emploi" . . . . . . . . . . . . . . . . 63
5.5 Diagramme de séquence "Modifier Compétence" . . . . . . . . . . . . . . . 64
5.6 Diagramme des classe du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . 65
5.7 Interface gérer emplois . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.8 Interface gérer compétence . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

vii
Liste des tableaux

2.1 Backlog du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Description du cas d’utilisation "Authentification" . . . . . . . . . . . . . . 24
3.3 Description du cas d’utilisation "Consulter Ses informations" . . . . . . . . 25
3.4 Description des classes participantes dans le premier sprint . . . . . . . . . 28

4.1 backlog de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Description du cas d’utilisation "Créer une demande de formation" . . . . 34
4.3 Description du cas d’utilisation "Approuver les demandes de formation" . . 35
4.4 Description du cas d’utilisation "Ajouter utilisateur" . . . . . . . . . . . . 37
4.5 Description du cas d’utilisation "Supprimer utilisateur" . . . . . . . . . . . 38
4.6 Description du cas d’utilisation " Modifier utilisateur " . . . . . . . . . . . 39
4.7 Description du cas d’utilisation "Consulter liste utilisateurs" . . . . . . . . 40
4.8 Description des classes participantes dans le deuxième sprint . . . . . . . . 45

5.1 backlog du troisième sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2 Description du cas d’utilisation "Ajouter emploi" . . . . . . . . . . . . . . 54
5.3 Description du cas d’utilisation "Supprimer emploi" . . . . . . . . . . . . . 55
5.4 Description du cas d’utilisation " Modifier emploi " . . . . . . . . . . . . . 57
5.5 Description du cas d’utilisation "Consulter liste emplois" . . . . . . . . . . 57
5.6 Description du cas d’utilisation "Ajouter compétence" . . . . . . . . . . . . 58
5.7 Description du cas d’utilisation "Supprimer compétence" . . . . . . . . . . 59
5.8 Description du cas d’utilisation " Modifier compétence " . . . . . . . . . . 60
5.9 Description du cas d’utilisation "Consulter liste compétences" . . . . . . . 61
5.10 Description des classes participantes dans ce dernier sprint . . . . . . . . . 66

viii
Introduction générale

Introduction générale
L’avènement de la numérisation représente une avancée majeure, comparable à l’im-
pact révolutionnaire de l’imprimerie au XVe siècle. Les ordinateurs ont ouvert les portes
d’un nouveau monde, façonné par des avancées telles que les plate-formes en ligne, les
applications mobiles et le commerce électronique. En l’espace de quelques années, l’essor
exponentiel des technologies numériques a transféré une part significative de nos interac-
tions sociales vers cet univers virtuel.

Cette transition offre des opportunités sans précédent pour les entreprises, les inci-
tant à dématérialiser leurs données et documents. Dans ce contexte, les départements des
ressources humaines (RH) jouent un rôle crucial en favorisant l’adoption d’une culture nu-
mérique au sein de leurs organisations. Cette évolution se traduit par une transformation
des processus internes et des structures organisationnelles, orientées vers la digitalisation.

C’est dans ce paysage en mutation que s’inscrit mon projet de fin d’études, intitulé
« Gestion des personnels : formations, emplois et compétences ». Mené au sein de l’en-
treprise « ArabSoft » en collaboration avec la Faculté des Sciences de Gafsa, ce projet
vise à concevoir une application web innovante. Son objectif est d’améliorer la gestion
des ressources humaines en mettant l’accent sur la formation et le développement des
compétences. En capitalisant sur le potentiel humain, cette initiative contribuera à ren-
forcer la compétitivité de l’organisation, assurant ainsi une adéquation continue entre les
compétences disponibles et les besoins opérationnels.

Ce présent rapport est organisé en cinq chapitres :

—Le premier chapitre, présente le cadre général du projet à savoir la présentation

de l’organisme qui nous a accueilli, la problématique, ainsi que, le travail demandé et la
méthodologie qui nous a permis de la réaliser ;

—Dans le deuxième chapitre, nous exposons le fameux sprint 0, qui constitue la phase
d’initiation d’un projet Scrum. Il traite d’abord le recueil des besoins, et l’élaboration
du Backlog du produit, ensuite, la présentation d’une vue architecturale et conceptuelle
globale de notre application.

—Les trois derniers chapitres , auront le même plan : un Backlog Sprint, cadrage des
besoins, la conception et la réalisation, qui reflètent le déroulement des itérations.

• Le premier Sprint mettra en lumière la partie sécurité et Consulter ses informations.

• Le deuxième abordera La gestion des utilisateurs , gestion des formations et gestion

d’approuver les demandes de formation.

1
Introduction générale

• Enfin ,le troisième Sprint s’occupe la partie de La gestion des emplois et la gestion
des compétences.

2
Chapitre 1
Contexte général

Plan
1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.1 Ses services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.2 Les métiers de ArabSoft . . . . . . . . . . . . . . . . . . . . . 5

1.2 Étude et critique de l’existant . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Description et critique de l’existant . . . . . . . . . . . . . . . 6

1.2.2 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2.3 Travail demandé . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.1 Méthodes agiles . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.2 Méthodologie retenue . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.3 Rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4 Présentation du diagramme de Gantt . . . . . . . . . . . . . . . . . . 12

3
Chapitre 1. Contexte général

Introduction

Ce chapitre vise à situer notre projet dans son contexte général. Nous commence-
rons par présenter l’organisme d’accueil, ARABSOFT. Ensuite, nous décrirons l’étude de
l’existant et ses limites afin d’en déduire la solution proposée. Enfin, nous détaillerons la
méthodologie adoptée pour la réalisation de notre projet.

1.1 Organisme d’accueil

Créé en 1985 par Mohamed TRIKI, ARABSOFT s’est spécialisée dans l’étude, le
développement et la distribution de solutions de gestion notamment pour le secteur public.

Forte d’une expérience de plus d’une trentaine d’années, dans l’édition des solutions
standards et spécifiques, au profit de clients opérant dans des secteurs vitaux tels que
l’énergie, l’eau, la fiscalité, les finances, l’industrie chimique, l’hôtellerie, etc., ARAB-
SOFT a pu éprouver et affiner une méthodologie de gestion des projets fiable et efficace.
ARABSOFT a travaillé avec des experts reconnus dans tous les secteurs

En tant que firme certifié ISO 9001 version 2008, ARABSOFT a construit une relation
de confiance avec ses clients, en les accompagnant dans toutes les étapes de leurs projets
avec un souci constant de qualité. Deux Plans Qualité Projet (PQP) distincts ont été mis
en place pour répondre aux exigences de nos clients [1].

La figure 1.1 présente le logo de ARABSOFT.

Figure 1.1 – Logo organisme d’accueil

1.1.1 Ses services

AJIR : est conçu pour les grandes entreprises à multiples structures disposant d’une
base documentaire comportant les textes réglementaires relatifs aux ressources humaines.

4
Chapitre 1. Contexte général

1.1.2 Les métiers de ArabSoft

La société ArabSoft attache une grande importance à la pluridisciplinarité de ses

équipes :

• Génie logiciel.

• Ingénieur Système.

• La cyber-sécurité.

• Cloud Computing .

Les équipes sont composées de collaborateurs aux compétences complémentaires dont la

synergie garantit aux clients une forte création de valeur.

1.2 Étude et critique de l’existant

Il existe de nombreuses solutions et applications dans le domaine de la gestion des

ressources humaines qui permettent aux entreprises de s’orienter vers les ERP. Ces en-
treprises sont confrontées à plusieurs défis pour intégrer efficacement une grande quantité
d’informations dans des délais de plus en plus courts. Après avoir mené une enquête
auprès des experts métier et consulté la documentation disponible en ligne, nous avons
constaté que SAP SuccessFactors est une solution de premier plan dans ce domaine. SAP,
fondée en 1972 par cinq anciens employés d’IBM, est une société de logiciels allemande et
le principal éditeur mondial de progiciels ERP. SuccessFactors, en tant que composante
de l’offre de SAP, illustre l’engagement de l’entreprise à fournir des solutions complètes
et intégrées pour la gestion des ressources humaines.

La figure 1.2 présente l’interface graphique du progiciel SAP SuccessFactors.

5
Chapitre 1. Contexte général

Figure 1.2 – Le progiciel SAP

1.2.1 Description et critique de l’existant

SAP SuccessFactors est une suite logicielle de gestion des ressources humaines (HRM)
basée sur le cloud, offrant une gamme complète de fonctionnalités pour la gestion des
talents, y compris la gestion des formations, des compétences, des emplois et des perfor-
mances des employés. La solution est conçue pour aider les entreprises à gérer et dévelop-
per leurs talents, améliorer l’engagement des employés et optimiser les processus RH. Les
modules de SuccessFactors couvrent des domaines tels que le recrutement, l’intégration, la
gestion de la performance, l’apprentissage et le développement, ainsi que la planification
de la succession.

Malgré ses nombreux avantages, SAP SuccessFactors présente plusieurs inconvénients

significatifs : :

• Problème de coût : Les coûts initiaux de licence et les frais récurrents de maintenance
sont élevés, ce qui peut être prohibitif pour les petites et moyennes entreprises.

• Complexité de mise en œuvre : La solution est complexe à déployer et nécessite la

participation de nombreux acteurs, ce qui peut entraîner des retards et des coûts
supplémentaires.

• Ergonomie et expérience utilisateur : L’interface utilisateur propriétaire de SAP peut

être peu conviviale, nécessitant une formation supplémentaire pour les utilisateurs
finaux, ce qui peut ralentir l’adoption de la solution.

• Rigueur et flexibilité limitée : La rigidité de la solution rend les modifications et les

6
Chapitre 1. Contexte général

adaptations difficiles, limitant ainsi sa capacité à répondre aux besoins évolutifs des
entreprises.

• Durée d’implémentation : Le processus d’implémentation est souvent long, ce qui

peut retarder les bénéfices attendus de l’adoption de la solution.

• Exigences de licences supplémentaires : Certaines fonctionnalités nécessitent des

licences supplémentaires, ce qui peut augmenter encore les coûts pour l’entreprise.

En outre, sur le plan ergonomique, l’interface de cette application est peu conviviale, ce
qui peut avoir un impact négatif sur l’expérience utilisateur et son utilisation au quotidien.

1.2.2 Solution proposée

Pour répondre aux limitations identifiées dans SAP SuccessFactors et offrir une solu-
tion plus adaptée aux besoins actuels des entreprises en matière de gestion des ressources
humaines, nous proposons de développer une application web innovante qui digitalise les
processus internes de l’entreprise en utilisant des outils de développement modernes. Cette
solution vise à être plus flexible, conviviale et économique tout en répondant aux exigences
de gestion des talents , Cela inclut :

• Gestion des utilisateurs : Permet d’administrer les comptes et les permissions des
utilisateurs de la plateforme, de gérer les accès aux fonctionnalités et aux données
en fonction des rôles et des responsabilités de chaque utilisateur.

• Gestion des emplois et des compétences : Permet de structurer les différents emplois
au sein de l’organisation, d’identifier les compétences requises pour chaque emploi
et de gérer la correspondance entre les compétences des employés et les exigences
d’emploi.

• Gestion des formations : Un module complet pour planifier, suivre et gérer les pro-
grammes de formation des employés.

Dans le cadre de la tâche de Gestion des utilisateurs, notre objectif est d’assurer
une disponibilité élevée et des performances optimales de l’application. L’utilisation de
nouvelles technologies de développement est cruciale pour créer une architecture robuste
et évolutive. L’interaction entre l’utilisateur et l’application revêt une importance capitale
pour favoriser la fidélisation.

Pour ce projet de fin d’études, notre intention est de développer une application web
qui digitalise les processus internes des ressources humaines, tout en réduisant les coûts

7
Chapitre 1. Contexte général

et en offrant des interfaces simples, attrayantes et conviviales. Nous visons à permettre

à l’utilisateur d’éviter les tâches fastidieuses et chronophages liées à la paperasse, en lui
permettant de se concentrer sur des activités plus significatives.

1.2.3 Travail demandé

Dans ce contexte, le travail demandé tout au long de la période de stage consiste à

concevoir et développer une application web visant à digitaliser les processus internes
d’une entreprise. Cette application sera développée en utilisant les derniers outils et tech-
nologies de développement disponibles afin de garantir une solution RH automatisée et
performante. L’objectif ultime est de créer une plateforme qui simplifie et rationalise les
processus RH, permettant ainsi à l’entreprise de gagner en efficacité et en productivité.

Les objectifs de cette application web sont :

• Consulter ses informations.

• La gestion des formations.

• Approuver les demandes de Formation.

• La gestion des utilisateurs.

• La gestion des compétences.

• La gestion des emplois .

1.3 Méthodologie de travail

1.3.1 Méthodes agiles

Il existe de nombreuses méthodes agiles disponibles, y compris les méthodes les plus
populaires :

• Extreme Programming (XP)

Extreme Programming, ou XP, est une méthode agile de gestion de projet particulière-
ment bien adaptée aux projets de développement informatique. Le principe de base de la
méthode XP est de faire travailler en étroite collaboration tous les participants au projet
et de choisir convient aux itérations de développement très courtes. La planification des

8
Chapitre 1. Contexte général

tâches est toujours très flexible, et l’estimation des charges simplifiée par des prévisions
à très court terme. Par conséquent, la correspondance entre les attentes des clients et les
réalisations est garantie. Des fonctionnalités sont fournies régulièrement pour des tests et
des vérifications via des prototypes opérationnels .

• Feature Driven Development (FDD)

Le Développement Dirigé par les Fonctionnalités (Feature-Driven Development en an-

glais) est une méthode de gestion de projet axée sur la gestion des risques. Elle se caracté-
rise par des itérations courtes, centrées sur des fonctionnalités testables par l’utilisateur.
Ainsi, les participants au développement peuvent suivre l’avancement du projet et véri-
fier les fonctionnalités en cours de réalisation. Bien qu’il ne soit pas recommandé de se
focaliser uniquement sur une méthode de programmation spécifique, cette approche met
l’accent sur le développement de fonctionnalités distinctes.

• Adaptive software development (ASD)

ASD (Agile Software Development) est une méthode de développement d’applications

rapide. Elle repose sur l’automatisation et l’industrialisation du plus grand nombre de
processus possibles. Cette méthode utilise des outils de modélisation et met en place une
usine logicielle pour générer automatiquement le maximum de code informatique. Par la
suite, l’atelier de génie logiciel (AGL) permet aux développeurs de modifier les applications
générées. Enfin, l’usine de livraison automatise l’ensemble du processus de déploiement.

• Scrum

La méthode agile Scrum, particulièrement dédiée à la gestion de projets informatiques,

s’est empruntée au rugby. Le principe de Scrum est de pouvoir modifier la direction du
projet au fur et à mesure de l’avancement. Elle se caractérise par des itérations (appelées
sprints) et un formalisme réduit : rôles (Product Owner, Scrum Master, équipe), time-
boxes (scrum quotidien, revue de sprint, planification de release, planification de sprint,
burndown/burnup de release, burndown/burnup de sprint) [2].

La figure 1.3 ci-dessous illustre le cycle de vie de méthode Agile Scrum.

9
Chapitre 1. Contexte général

Figure 1.3 – Cycle de vie SCRUM

1.3.2 Méthodologie retenue

Dans notre projet, nous essayons d’adapter Scrum à nos besoins. Par conséquent, nous
utiliserons toutes les bonnes pratiques suivantes

• Extraction des fonctions à développer après avoir complété la liste de tâches produit ;

• Diviser le projet en un groupe de sprints ;

• Diviser chaque sprint en un ensemble de tâches ;

• Définir une mission à faire hebdomadaire chaque jeudi ;

• Rencontrer l’encadrant de la société tous les jours pour suivre les progrès ;

– Quelles sont les tâches effectuées hier ?

– Quelles sont les difficultés rencontrées ?
– Quelles sont les tâches à faire aujourd’hui ?

1.3.3 Rôles

[Link] Product Owner

Les Product Owners sont les champions de leur produit, ils ne sont pas des chefs de
projet. Chez ARABSOFT c’était le cas de Triki Mohamed . Ils sont concentrés sur la

10
Chapitre 1. Contexte général

compréhension des Opérations Team et exigences du marché, puis ils priorisent les tâches
à réaliser par l’équipe d’ingénieurs en conséquence.

Leurs principales responsabilités étaient :

— Construire et gérer le Product Backlog, et aussi le Sprint Backlog.

— S’assurer que tout le monde comprend les éléments de travail du backlog produit.

— Guider l’équipe dans le développement des différentes features [3].

[Link] Scrum Master

C’était le rôle du CTO Balti Aymen . Il était responsable de s’assurer que l’équipe vit
selon les valeurs et les pratiques de Scrum. Il était toujours là en nous aidant en tant que
coach et poussant à faire de notre mieux afin d’offrir le meilleur produit possible. [3]

[Link] Équipe Scrum

J’appartenais à l’équipe Scrum en tant que développeur , tout le monde assure la

finalisation des différents projets. Donc, front-end, back-end et designer. . . Chacun doit
connaître les tâches des autres coéquipiers [3].

[Link] Daily Standup Meeting

En tant qu’équipe Scrum, tout le monde devait laisser une trace de ses tâches quo-
tidiennes. Le meeting est un vrai rendez-vous, chaque membre de l’équipe répond aux
questions suivantes :

— Qu’as-tu fait hier ?

— Que ferez-vous aujourd’hui ?

— Y’a t-il quelque chose qui bloque la tâche en cours ?

• Sprint Commitment Meeting

Un sprint chez ArabSoft dure trois semaines. A la fin de chaque Sprint nous faisons
un sprint Commitment Meeting tous les Jeudi à 10H. Au cours de cette réunion, nous
commençons par un Sprint Review, où chaque membre de l’équipe partage son écran et
présente l’avancement de ses tâches. Puis un Sprint Planning, où sont présentées les tâches
programmées pour le sprint suivant [4].

11
Chapitre 1. Contexte général

[Link] Scrum Board

• Sprint Backlog

Le Sprint Backlog est une liste de tâches identifiées par l’équipe Scrum à réaliser pendant
le Sprint. Nous sélectionnons ces tâches lors du Sprint Planning, et qui se présentent
généralement sous la forme des user stories où nous attribuons des estimations temporelles
à chacune d’entre elles, chez ArabSoft.

• User Stories

Les User Stories sont des descriptions courtes et simples d’une fonctionnalité racontée du
point de vue d’une personne non-technique qui désire la nouvelle « Feature », généralement
un utilisateur ou un client du système.

1.4 Présentation du diagramme de Gantt

Le diagramme de Gantt théorique qui définit la période de chaque phase :

Figure 1.4 – Diagramme de Gantt

Conclusion

Ce chapitre nous a donné l’opportunité de présenter l’organisation d’accueil ainsi

qu’une brève description du projet à réaliser, en identifiant sa problématique et en suggé-
rant une solution envisagée pour répondre à cette situation. Nous avons également examiné
différentes méthodologies de développement afin de sélectionner celle qui conviendrait le
mieux à notre projet.

Dans le prochain chapitre, nous nous concentrerons sur l’analyse et la spécification des
besoins.

12
Chapitre 2
Sprint 0 : Initiation du projet

Plan
2.1 Cadrage de besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.2 Diagramme de cas d’utilisation globale . . . . . . . . . . . . . 15

2.2 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Architecture globale de l’application . . . . . . . . . . . . . . . . . . . 18

2.4 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . 18

2.4.2 Environnement de développement . . . . . . . . . . . . . . . . 19

2.4.3 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . 19

13
Chapitre 2. Sprint 0 : Initiation du projet

Introduction

Dans ce chapitre, nous abordons la première étape de notre projet, à savoir le sprint
zéro. Nous commençons par répertorier les besoins fonctionnels et non fonctionnels, ainsi
que par définir le cas d’utilisation général. Ensuite, nous détaillons le backlog du produit et
des sprints. Par la suite, nous nous attardons sur la conception d’une structure appropriée
pour l’application. Enfin, nous offrons un aperçu succinct du matériel de base, des tech-
nologies et des langages de programmation utilisés pour mettre en place l’environnement
de travail.

2.1 Cadrage de besoin

Au sein de cette section, nous allons présenter en détail les exigences fonctionnelles
et non fonctionnelles de notre application. Nous identifierons ensuite les divers acteurs
impliqués, pour ensuite définir le diagramme des cas d’utilisation global de l’application.

2.1.1 Analyse des besoins

Nous allons identifier les besoins fonctionnels ainsi que les non fonctionnels.

[Link] Besoins fonctionnels

Après une analyse approfondie du système, cette section se consacre à décrire les
besoins fonctionnels de chaque participant de l’application. Ces exigences sont répertoriées
dans un diagramme de cas d’utilisation. Les besoins des utilisateurs comprennent :

• Authentification sécurisée : Après l’authentification, l’application doit permettre de :

• Consulter ses informations sera gérée par l’utilisateur : l’utilisateur peut consulté
ses informations.

• Gestion des utilisateurs : La gestion des utilisateurs sera gérée par l’administra-
teur système ; l’administrateur peut ajouter, modifier, supprimer et consulter un
utilisateur.

• Gestion des Formations : La gestion des formations permet aux utilisateurs de rem-
plir un formulaire électronique d’une demande de formation. Par la suite il peut
consulter l’état de demande.

14
Chapitre 2. Sprint 0 : Initiation du projet

• Approuver les demandes de formation : Approuver les demandes de formation per-

met l’administrateur de changé l’état de la demande créer par l’utilisateur (Accep-
ter,Refuser).

• Gestion des emplois : La gestion des emplois sera gérée par l’administrateur système ;
l’administrateur peut ajouter, modifier, supprimer un emploi.

• Gestion des compétences : La gestion des compétences sera gérée par l’administra-
teur système ; l’administrateur peut ajouter, modifier, supprimer un compétences.

[Link] Besoins non fonctionnels

Les besoins non fonctionnels décrivent toutes les contraintes qui rendent le fonction-
nement de l’application plus performant et plus efficace.

— Sécurité : La solution doit garantir la sécurité des informations des utilisateurs

grâce à des mécanismes de contrôle d’accès appropriés.

— Fiabilité :L’application doit fonctionner de manière stable, sans erreur, et produire

des résultats précis et fiables.

— Ergonomie et souplesse d’utilisation : Pour une expérience utilisateur opti-

male, l’application doit proposer une interface unifiée, conviviale et ergonomique.

— Simplicité : notre application est caractérisée par l’utilisation simple.

— Instantanéité :L’application doit optimiser les processus pour garantir des temps
de réponse courts.

— Maintenabilité :Le code source de l’application doit être clair et bien documenté
pour permettre des modifications et des évolutions faciles en fonction des besoins de
l’entreprise.

2.1.2 Diagramme de cas d’utilisation globale

Le diagramme de cas d’utilisation globale permet de structurer les besoins des utilisa-
teurs et les objectifs correspondants d’un système

La figure 2.1 illustre toute les cas utilisations de base afin d’avoir une vue globale du
comportement de l’application.

15
Chapitre 2. Sprint 0 : Initiation du projet

Figure 2.1 – Diagramme de cas d’utilisation général

— Consulter ses informations nécessite l’authentification d’utilisateur, cette relation

est réalisée par l’association include entre Consulter ses informations et s’authentifier ;

—Gérer Formations nécessite l’authentification d’administrateur, cette relation est

réalisée par l’association include entre gérer formations et s’authentifier ;

—Approuver les demandes de formation nécessite l’authentification d’administrateur,

cette relation est réalisée par l’association include entre Approuver les demandes de for-
mation et s’authentifier ;

—Gérer utilisateurs nécessite l’authentification d’administrateur, cette relation est réa-

lisée par l’association include entre gérer utilisateurs et s’authentifier ;

—Gérer emplois nécessite l’authentification d’administrateur, cette relation est réalisée

par l’association include entre gérer emplois et s’authentifier ;

—Gérer compétences nécessite l’authentification d’administrateur, cette relation est

réalisée par l’association include entre gérer compétences et s’authentifier ;

2.2 Backlog de produit

Le backlog est une liste de tâches proposées qui définit les caractéristiques du produit,
c’est un artefact fondamentale de la méthodologie Scrum, C’est l’ensemble des caractéris-
tiques techniques ou fonctionnelles qui constituent le produit souhaité.

16
Chapitre 2. Sprint 0 : Initiation du projet

Le tableau 2.1 présente le backlog produit et identifie les différents « User Stories » :

• ID Sprint : présente le numéro de chaque Sprint ;

• User Story : qui décrit les fonctions de l’administrateur et l’utilisateur de la société ;

• Priorité : qui mentionne le niveau de priorité de développement de « User Stories

» suivant le besoin de l’utilisateur.

ID Thème Acteur User Story Priorité

Sprint
S’authentifier Utilisateur En tant qu’utilisateur, je peux Élevée
m’authentifier en toute sécu-
rité.
N°1
En tant qu’utilisateur, je peux Élevée
que mes informations soient en
toute sécurité
En tant qu’utilisateur, je peux Moyenne
avoir la possibilité de rester
connecte dès que je quitte l’ap-
plication.
Consulter ses Utilisateur En tant qu’utilisateur de la so- Élevée
informations ciété je peux consulter mes in-
formations personnelles
Gérer les utili- Administrateur En tant qu’Administrateur de Élevée
sateurs la société je peux gérer les uti-
lisateurs
N°2
Gérer forma- Utilisateur En tant qu’utilisateur de la Élevée
tions société je peux créer une de-
mande de formation
Utilisateur En tant qu’utilisateur de la so- Élevée
ciété je peux consulter l’état de
ma demande
Approuver les Administrateur En tant qu’Administrateur de Élevée
demandes de la société je peux Accepter ou
formation Refuser la demande

17
Chapitre 2. Sprint 0 : Initiation du projet

Gérer emplois Administrateur En tant qu’administrateur de Élevée

la société je peux gérer emplois
Gérer compé- Administrateur En tant qu’administrateur de Élevée
N°3
tences la société je peux gérer compé-
tences

Table 2.1 – Backlog du projet

2.3 Architecture globale de l’application

La figure 2.2 présente l’architecture globale de l’application, qui est composée de deux
sous- applications, Frontend et Backend. Les derniers communiquent à travers des API
REST.

Figure 2.2 – Architecture Globale de l’application

2.4 Environnement de travail

2.4.1 Environnement matériel

Afin de réaliser ce projet, nous avons utilisé un ordinateur portable qui dispose de la
configuration suivante :

18
Chapitre 2. Sprint 0 : Initiation du projet

— ASUS ExpertBook : 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz 2.42 GHz,
Ram :16.0 Go ;

— Système d’exploitation : Windows 11.

2.4.2 Environnement de développement

— HTML 5 : HyperText Markup Language est un langage de balisage pour

représenter les pages web [5] ;

— CSS : Les feuilles de style en cascade pour formater la structure du contenu,

il est responsable sur les styles des textes, des images, des vidéos, des tableaux, etc. . [6]

— Typescript :TypeScript est un langage de programmation libre et open

source développé par Microsoft qui a pour but d’améliorer et de sécuriser la production
de code JavaScript. Il s’agit d’un sur-ensemble syntaxique strict de JavaScript [7].

2.4.3 Environnement logiciel

— Angular : est un framework pour clients, open source, basé sur TypeScript
et codirigé par l’équipe du projet « Angular » chez Google ainsi que par une commu-
nauté de particuliers et de sociétés. Angular est une réécriture complète d’AngularJS,
cadriciel construit par la même équipe. Il permet la création d’applications Web et plus
particulièrement d’applications Web monopages [8].

— Spring Boot :Le Spring Framework est très largement utilisé dans la commu-
nauté Java. Il permet d’accélérer le développement d’applications d’entreprise (notamment
le développement d’applications Web et d’API Web). Mais on trouve des applications ba-
sées sur le Spring Framework dans bien d’autres domaines [9].

— XAMPP : est un ensemble de logiciels permettant de mettre en place un

serveur Web local, un serveur FTP et un serveur de messagerie électronique. Il s’agit d’une
distribution de logiciels libres offrant une bonne souplesse d’utilisation, réputée pour son
installation simple et rapide [10].

— IntelliJ :IntelliJ IDEA également appelé « IntelliJ », « IDEA » ou « IDJ » est

19
Chapitre 2. Sprint 0 : Initiation du projet

un environnement de développement destiné au développement de logiciels informatiques

reposant sur la technologie Java [11].

— Visual Studio Code :est un éditeur de code source développé par Micro-
soft pour Windows, macOs et Linux, Il comprend un support intégré pour JavaScript,
TypeScript et [Link]. Utilisé pour la partie Frontend [12].

— GanttProject :est un logiciel libre de gestion de projet écrit en Java. Il

permet d’éditer un diagramme de Gantt. L’outil GanttProject permet de planifier un
projet à travers la réalisation de diagrammes de Gantt ainsi que des diagrammes de
ressources et des réseaux PERT [13].

— Overleaf : est une plateforme en ligne gratuite permettant d’éditer du texte

en LATEX sans aucun téléchargement d’application. En outre, elle offre la possibilité de
rédiger des documents de manière collaborative, de proposer ses documents directement
à différents éditeurs (IEEE Journal, Springer, etc.) [14].

— Postman : est une application permettant de tester des API, créée en 2012
par Abhinav Asthana, Ankit Sobti et Abhijit Kane à Bangalore pour répondre à une
problématique de test d’API partageable [15].

Conclusion

Dans ce chapitre, nous avons présenté les besoins fonctionnels et non fonctionnels de
notre système ainsi que le cas d’utilisation global. Ensuite, nous avons détaillé le backlog
du produit et des sprints. Nous avons également identifié l’environnement matériel et
logiciel nécessaire pour réaliser notre plateforme. Dans le chapitre suivant, nous nous
concentrerons sur le développement du premier sprint de ce projet.

20
Chapitre 3
Sprint 1 : Authentification, Consulter ses
informations

Plan
3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.1 Diagramme de cas d’utilisation raffiné « Sprint 1 » . . . . . . 23

3.2.2 Description de cas d’utilisation raffiné « Sprint1 » . . . . . . . 23

3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.1 Scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.2 Diagramme de Classes . . . . . . . . . . . . . . . . . . . . . . 27

3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

21
Chapitre 3. Sprint 1 : Authentification, consulter ses informations

Introduction

Dans ce présent chapitre, nous allons présenter le premier sprint. Ce dernier touchera
la partie sécurité, l’authentification et Consulter des informations. En organisant le travail
sur trois parties principales qui sont l’analyse, la conception et la réalisation.

3.1 Backlog du sprint 1

Le tableau 3.1 ci-dessous détaille le backlog de sprint 1

Nous citons que l’Acteur Utilisateur définit l’utilisateur

ID Thème Acteur User Story Priorité

Sprint
Authentification Utilisateur En tant d’administrateur, je peux Élevée
m’authentifier en toute sécurité.
en tant qu’administrateur, je Élevée
peux que mes informations soient
N°1 en toute sécurité
en tant qu’utilisateur je peux Moyenne
avoir la possibilité de rester
connecte des que je quitte l’appli-
cation
Consulter ses in- utilisateur en tant qu’utilisateur de l’appli- Élevée
formations cation je peux consulter mes in-
formations

Table 3.1 – Backlog du sprint 1

3.2 Spécification fonctionnelle

Dans cette partie, nous allons présenter la partie spécification des besoins de notre
«Sprint 1» afin de décrire les résultats attendus en terme de fonctionnalités.

22
Chapitre 3. Sprint 1 : Authentification, consulter ses informations

3.2.1 Diagramme de cas d’utilisation raffiné « Sprint 1 »

Ce sprint, dans un premier lieu, est responsable de consulter ses informations ,il traite
les informations de chaque utilisateurs .

• consulter ses informations nécessite l’authentification d’utilisateur, cette relation est

réalisée par l’association « include » entre s’authentifier et consulter ses informa-
tions ;

La figure 3.1 décrit le diagramme de cas d’utilisation global du premier sprint.

Figure 3.1 – Diagramme de cas d’utilisation raffiné "Sprint 1"

3.2.2 Description de cas d’utilisation raffiné « Sprint1 »

[Link] Description du cas d’utilisation « Authentification »

Le tableau 3.2 fournit une description du cas d’utilisation « Authentification »

Titre Authentification
Acteur L’utilisateur (utilisateur et Administrateur)
Résumé L’outil permet l’authentification de l’administrateur et l’utilisateur
pour protéger le système
Description des enchainements

23
Chapitre 3. Sprint 1 : Authentification, consulter ses informations

Pré conditions
• L’utilisateur doit avoir un compte déjà actif et créé ;

• L’utilisateur doit avoir un rôle spécifique ;

• L’application doit être ouverte sur l’interface d’authentifica-

tion.

Post condi-
tions
• L’utilisateur est connecté à son compte avec les autorisations
associées à son rôle.

Scénario nominale

• L’utilisateur saisie son nom d’utlisateur « username ». ;

• L’utilisateur saisie son mot de passe en respectant des règles

bien définies ;

• L’utilisateur clique sur « Login ».

Scénario alternatif

• Nom d’utilisateur ou mot de passe non valide ;

• L’interface d’authentification est rechargée avec le message

« Le nom d’utilisateur ou le mot de passe est incorrect ».

Table 3.2 – Description du cas d’utilisation "Authentification"

[Link] Description du cas d’utilisation « Consulter Ses informations »

Le tableau 3.3 fournit une description du cas d’utilisation « Consulter Ses informations
»

24
Chapitre 3. Sprint 1 : Authentification, consulter ses informations

Titre Consulter Ses informations

Acteur L’utilisateur
Résumé L’outil permet l’authentification de l’administrateur et l’utilisateur
pour protéger le système
Description des enchaînements
Pré conditions
• L’utilisateur doit avoir un compte déjà actif et créé ;

• L’utilisateur doit avoir un rôle spécifique ;

• L’application doit être ouverte sur l’interface de consulter ses

informations.

Post condi-
tions
• L’utilisateur est connecté à son compte avec les autorisations
associées à son rôle.

Scénario nominale

• L’utilisateur clique sur « Profil». ;

• La page de profil s’affiche avec ses cordonnés. ;

Scénario alternatif

• Échec à cause d’une erreur interne au niveau de l’application

(exemple échec connexion avec la base de données)

Table 3.3 – Description du cas d’utilisation "Consulter Ses informations"

25
Chapitre 3. Sprint 1 : Authentification, consulter ses informations

3.3 Conception

Nous allons, dans cette partie, présenter la partie de conception en exposant les scé-
narios à réaliser.

3.3.1 Scénario

Les diagrammes de séquences sont la représentation graphique en organisant les in-

teractions possibles entre les utilisateurs, les écrans, les objets et les entités intervenantes
au sein du système selon un ordre chronologique dans la formulation Unified Modeling
Language (UML).

[Link] Diagramme de séquence « Authentification »

La figure 3.2 illustre le diagramme de séquence « s’authentifier » qui va traiter la

partie sécurité.

Figure 3.2 – Diagramme de séquence "S’authentifier"

Nous remarquons à travers ce diagramme de séquence, lorsque l’utilisateur saisie son

nom d’utilisateur et son mot de passe et demande de se connecter à l’application, cette
demande est envoyée vers le serveur, elle sera traitée , ses coordonnées seront vérifiés,

26
Chapitre 3. Sprint 1 : Authentification, consulter ses informations

dans ce cas, une condition « alt » est présente , si l’accès à la base de données est accepté,
un msg d’authentification sera créé et envoyé vers l’utilisateur, et par la suite la page
d’accueil de l’application sera affichée.

Sinon, un message d’erreur « nom utilisateur ou mot de passe incorrecte » sera affiché
à l’utilisateur.

[Link] Diagramme de séquence « Consulter ses informations »

La figure 3.3 illustre le diagramme de séquence « Consulter ses informations » qui va

afficher les coordonnées de chaque utilisateur.

Figure 3.3 – Diagramme de séquence "Consulter ses informations"

L’utilisateur commence en cliquant sur le bouton "Profil" dans l’interface. Cette ac-
tion envoie une requête au service utilisateur, qui interroge ensuite la base de données
pour obtenir les informations de l’utilisateur via la méthode getUserById(id). La base de
données traite la demande et renvoie les données au service utilisateur, qui les transmet
à l’interface utilisateur. Enfin, les informations du profil sont affichées à l’utilisateur.

3.3.2 Diagramme de Classes

La figure 3.4 représente le diagramme de classe pour le développement du premier

Sprint.

27
Chapitre 3. Sprint 1 : Authentification, consulter ses informations

Figure 3.4 – Diagramme de classe du Sprint 1

Le tableau 3.4 décrit la description des classe participantes dans le premier sprint.

Classe Description

Utilisateur Présente l’utilisateur (en tant que Administrateur) de

l’application qui appartient à la société.
Role Contient les listes des rôles .
Role-user Contient les Rôles de chaque utilisateur .
Table 3.4 – Description des classes participantes dans le premier sprint

3.4 Réalisation

Dans cette partie, nous allons présenter quelques interfaces de l’application.

Nous commençons par présenter la partie authentification : pour s’authentifier l’utili-

sateur doit saisir son nom d’utilisateur et son mot de passe, et clique sur Login. L’interface
de l’authentification est présentée dans la figure 3.5 .

28
Chapitre 3. Sprint 1 : Authentification, consulter ses informations

Figure 3.5 – Interface Login

Après l’authentification l’utilisateur à le droit de consulter ses informations. L’interface

de consulter ses informations est présentée dans la figure 3.6 .

Figure 3.6 – Interface consulter ses informations

Dans cette platforme on a deux types d’utilisateurs : administrateur et utilisateur,

donc on va présenter les interfaces dans les deux cas.

Conclusion

Au cours de ce sprint, nous avons aborder l’authentification et Consulter ses informa-

tions en passant par l’analyse des spécifications des besoins, la conception et la réalisation.

Dans le chapitre suivant, nous entamerons sur le développement du deuxième sprint .

29
Chapitre 4
Sprint 2 : Gérer Formations, Gérer
utilisateurs, Approuver les demandes de
formation

Plan
4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.1 Diagramme de cas d’utilisation raffiné « Sprint 2 » . . . . . . 32

4.2.2 Description de cas d’utilisation raffiné « Sprint 2 » . . . . . . 33

4.2.3 Diagramme de cas d’utilisation raffiné « Gérer utilisateurs » . 35

4.2.4 Description de cas d’utilisation raffiné «Sprint 2 :Gérer utilisa-

teurs» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3.1 Scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3.2 Diagramme de Classes . . . . . . . . . . . . . . . . . . . . . . 44

4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

30
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

Introduction

Dans ce présent chapitre, nous allons présenter le deuxième sprint. Ce dernier abordera
la gestion des utilisateurs , la gestion des formations et la gestion d’approuver les demandes
de formation . En organisant le travail sur trois parties principales qui sont l’analyse, la
conception et la réalisation.

4.1 Backlog du sprint 2

Le tableau 4.1 présente la backlog de sprint 2. Nous citons que l’Acteur définit l’uti-
lisateur ou l’Administrateur

ID Thème Acteur User Story Priorité

Sprint
Gérer utilisa- Administrateur En tant qu’Administrateur, je Élevée
N°2 teurs peux m’authentifier en toute sé-
curité.
En tant qu’Administrateur, je Élevée
peux gérer utilisateurs
Gérer forma- Administrateur En tant qu’Administrateur, je Élevée
tions peux m’authentifier en toute sé-
curité.
En tant qu’Administrateur, je Élevée
peux consulter la liste de de-
mande de formation.
Utilisateur En tant qu’utilisateur, je peux Élevée
m’authentifier en toute sécurité.
En tant qu’utilisateur, je peux Élevée
créer une demande de formation
En tant qu’utilisateur, je peux Élevée
consulter l’état de ma demande
Approuver les Administrateur En tant qu’Administrateur, je Élevée
demandes de peux Accepter ou Refuser la de-
formation mande.

Table 4.1 – backlog de sprint 2

31
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

Ce sprint s’occupe de la gestion des utilisateurs, il traite la Gestion des utilisateurs,

(ajouter,modifier,supprimer et consulter).

Dans un deuxième lieu, il s’occupe aussi de la gestion des formations, il peut créer les
demandes et consulter son état (Accepter ou Refuser).

Dans la partie gestion des formation, nous avons un acteur qui joue le rôle d’un
utilisateur.

L’acteur utilisateur a la possibilité de :

• Gérer formation nécessite l’authentification de l’utilisateur, cette relation est réalisée

par l’association « include » entre s’authentifier et gérer formations ;

• Après que l’utilisateur créer une demande ,il peut consulter l’état de sa demande ;

Enfin, il s’occupe aussi de Approuver les demandes de formation , il peut Accepter

ou Refuser les demandes . Dans la partie Approuver les demandes de formation,
nous avons un acteur qui joue le rôle d’un administrateur.

Pour l’acteur administrateur a la possibilité de :

• Approuver les demandes de formation nécessite l’authentification de l’administra-

teur, cette relation est réalisée par l’association « include » entre s’authentifier et
Approuver les demandes de formation.

• L’administrateur peut Accepter ou refuser les demandes.

4.2 Spécification fonctionnelle

Dans cette partie, nous allons exposer la partie spécification des besoins de notre «
Sprint 2 » afin de décrire les résultats attendus en terme de fonctionnalités.

4.2.1 Diagramme de cas d’utilisation raffiné « Sprint 2 »

La figure 4.1 illustre le raffinement du cas d’utilisation du Sprint 2 « Gestion des

demandes des formations et Approuver les demandes de formation».

32
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

Figure 4.1 – Diagramme de cas d’utilisation raffiné du Sprint 2 "Gestion des formations
et Approuver les demandes de formation"

4.2.2 Description de cas d’utilisation raffiné « Sprint 2 »

[Link] Description du cas d’utilisation « Créer une demande de formation »

Le tableau 4.2 fournit une description du cas d’utilisation « Créer une demande de
formation »

Titre Création d’une demande de formation

Acteur L’utilisateur
Résumé Offrir la possibilité à un utilisateur de créer une formation et consul-
ter son état.
Description des enchaînements
Pré conditions
• L’utilisateur authentifié. »

Post condi-
tions
• La demande de formation est crée.»

Scénario nominal

33
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

• L’utilisateur clique sur « faire une demande de formation » ;

• Le système affiche à l’écran le formulaire de demande de for-

mation ;

• L’utilisateur saisie les informations de demande ;

• Le système vérifie les informations saisies ;

• Le système est créé la demande ;

• Le système affiche la liste des demandes créer avec son état .

Scénario alternatif

• Échec à cause d’une erreur interne au niveau de l’application

(exemple échec connexion avec la base de données)

Table 4.2 – Description du cas d’utilisation "Créer une demande de formation"

[Link] Description du cas d’utilisation « Approuver des demandes de for-

mation »

Le tableau 4.3 fournit une description du cas d’utilisation « Approuver des demandes
de formation»

Titre Approuver les demandes de formation

Acteur L’administrateur
Résumé Permettre à l’administrateur de consulter les demandes de forma-
tion et soit qu’il accepté ou refusé
Description des enchaînements

34
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

Pré conditions
• L’administrateur authentifié ;

• L’administrateur a la permission «accepter ou refuser la de-

mande de formation».

Post condi-
tions
• Demande de formation accepter ou refuser

Scénario nominal

• L’administrateur choisit la rubrique des demandes de forma-

tion ;

• Le système affiche à l’écran les demandes à valider ;

• L’administrateur valide ou refuse la demande ;

• Le système modifie l’état de la demande à l’écran de l’utilisa-

teur par « acceptée ou refusée ».

Table 4.3 – Description du cas d’utilisation "Approuver les demandes de formation"

4.2.3 Diagramme de cas d’utilisation raffiné « Gérer utilisateurs

»

La figure 4.2 illustre le raffinement du cas d’utilisation du Sprint 2 « Gérer utilisateurs».

35
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

Figure 4.2 – Diagramme de cas d’utilisation raffiné du Sprint 2 "Gérer utilisateurs"

4.2.4 Description de cas d’utilisation raffiné «Sprint 2 :Gérer uti-

lisateurs»

[Link] Description du cas d’utilisation « Gérer utilisateurs »

Le tableau 4.4 fournit une description du cas d’utilisation « Ajouter utilisateur »

Titre Ajouter utilisateur

Acteur L’administrateur
Résumé L’application permet l’ajout des utilisateurs.
Description des enchainements
Pré conditions
• L’administrateur authentifié ;

• L’administrateur a la permission « ajouter utilisateur ».

Post condi-
tions
• L’utilisateur est ajouté.

Scénario nominal

36
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

• L’administrateur clique User list dans le menu principal ;

• L’administrateur clique sur le bouton « add user» ;

• L’administrateur remplit les champs de cet utilisateur ;

• L’administrateur sélectionne le rôle de cet utilisateur ;

• L’administrateur valide en cliquant sur « Create user ».

Scénario alternatif

• Echec à cause d’une erreur interne au niveau de l’application

(exemple échec connexion avec la base de données)

Table 4.4 – Description du cas d’utilisation "Ajouter utilisateur"

Le tableau 4.5 fournit une description du cas d’utilisation « Supprimer utilisateur

»

Titre Supprimer utilisateur

Acteur L’administrateur
Résumé L’application permet la suppression des utilisateurs.
Description des enchainements
Pré conditions
• L’administrateur authentifié ;

• L’administrateur a la permission « supprimer utilisateur ».

Post condi-
tions
• L’utilisateur est supprimé.

Scénario nominal

37
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

• L’administrateur clique user list dans le menu principal ;

• L’administrateur sélectionne l’utilisateur qu’il veut suppri-

mer.

• L’administrateur clique sur le bouton delete .

Scénario alternatif

• Echec à cause d’une erreur interne au niveau de l’application

(exemple échec connexion avec la base de données).

Table 4.5 – Description du cas d’utilisation "Supprimer utilisateur"

Le tableau 4.6 fournit une description du cas d’utilisation « Modifier utilisateur »

Titre Modifier utilisateur

Acteur L’administrateur
Résumé L’application permet la modification de les coordonnées des utili-
sateurs.
Description des enchainements
Pré conditions
• L’administrateur authentifié ;

• L’administrateur a la permission «modifier utilisateur ».

Post condi-
tions
• L’utilisateur est modifié.

Scénario nominal

38
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

• L’administrateur clique user list dans son espace.

• L’administrateur sélectionne l’utilisateur qu’il veut modifier.

• L’administrateur clique sur le bouton update.

• Le système affiche un dialogue qui contient un formulaire des

coordonnées d’un utilisateur

• L’administrateur saisie les nouvelles coordonnées.

• L’administrateur clique sur « save »

Scénario alternatif

• Echec à cause d’une erreur interne au niveau de l’application

(exemple échec connexion avec la base de données).

Table 4.6 – Description du cas d’utilisation " Modifier utilisateur "

Le tableau 4.7 fournit une description du cas d’utilisation « Consulter liste utilisa-
teurs »

Titre Consulter liste utilisateurs

Acteur L’administrateur
Résumé L’application permet l’affichage du liste des utilisateurs.
Description des enchainements
Pré conditions
• L’administrateur authentifié ;

• L’administrateur a la permission « consulter liste utilisateurs

»;

• Liste des utilisateurs est affiché.

39
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

Post condi-
tions
• Liste des utilisateurs est affiché.

Scénario nominal

• L’administrateur consulte son espace ;

• L’administrateur clique sur le bouton « user list » ;

• Le système affiche une liste des utilisateurs.

Table 4.7 – Description du cas d’utilisation "Consulter liste utilisateurs"

4.3 Conception

Nous allons présenter les scénarios à réaliser dans ce sprint 2.

4.3.1 Scénario

[Link] Diagramme de séquence « Créer une demande de formation »

La figure 4.3 illustre le scénario de l’opération création d’une demande de formation

de la part de l’utilisateur.

40
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

Figure 4.3 – Diagramme de séquence "Créer une demande de formation"

Après l’authentification, l’utilisateur va choisir de consulter l’interface formulaire. Une

fois l’utilisateur choisit la page de formulaire, L’utilisateur va saisir ses données,après
clique sur le bouton « send ».

l’interface request va s’afficher une nouvelle demande de formation dont l’état par
défaut :« waiting ».

[Link] Diagramme de séquence « Approuver la demande de formation »

Dans la figure 4.4 le diagramme décrit l’opération validation de demandes de la part

de l’administrateur.

Après l’authentification, l’administrateur va consulter la liste des demandes en attente

de confirmation en passant par son Espace Admin. L’administrateur va consulter la liste
des demandes en attente , dans ce cas, une requête va traiter par la classe « training » et
le recherche va assurer dans la base de donnée.

Une liste des demandes de formation en attente de confirmation sera affiché, dans
ce cas, l’administrateur va choisir de confirmer ou refuser la demande selon le sujet de
formation remplir par l’utilisateur.

Si la demande est confirmée, une requête va traiter et modifier l’état de la demande

et afficher l’écran de l’utilisateur que sa demande est acceptée.

Sinon une requête va traiter et modifier l’état de la demande et afficher l’écran de

l’utilisateur que sa demande est refuser.

41
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

Figure 4.4 – Diagramme de séquence "Approuver une demande de formation "

[Link] Diagramme de séquence « Ajouter utilisateur »

La figure 4.5 illustre le scénario de l’opération Ajouter un utilisateur la part de l’ad-

ministrateur.

Nous remarquons à travers ce diagramme de séquence, l’administrateur va remplir

le formulaire pour ajouter un utilisateur, du côté Frontend, une vérification des champs
établis. Après la validation des champs. Une requête va traiter par la classe Control «
service utilisateur » et l’ajout de cet utilisateur dans la base de donnée va être assuré par
la méthode « add ». Dans le cas de réussir, l’utilisateur sera ajouté. Sinon un message
d’erreur « échec d’ajout ».

42
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

Figure 4.5 – Diagramme de séquence "Ajouter utilisateur"

[Link] Diagramme de séquence « Supprimer utilisateur »

Figure 4.6 – Diagramme de séquence "Supprimer utilisateur"

43
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

La figure 4.6 illustre le scénario de l’opération supprimer un utilisateur de la part de

l’administrateur.

Nous remarquons à travers ce diagramme de séquence, qu’après avoir sélectionner

l’utilisateur à supprimé Une requête va traiter par « Service utilisateur » qui va assurer
la suppression de cet utilisateur dans la base de donnée par la méthode « deleteuser ».

4.3.2 Diagramme de Classes

La figure 4.7 représente le diagramme de classe pour le développement du deuxième

Sprint.

Figure 4.7 – Diagramme de classe du Sprint 2

44
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

Le tableau 4.8 décrit la description des classe participantes dans le deuxième sprint.

Classe Description

Utilisateur Présente l’utilisateur (en tant que Administrateur et

Employé) de l’application qui appartient à la société.

Administrateur Contient les informations de l’utilisateur dont le rôle ad-

ministrateur.
Formation La classe ayant les listes des formations .
Table 4.8 – Description des classes participantes dans le deuxième sprint

4.4 Réalisation

Cette partie présente les différents interfaces de la gestion des utilisateurs .

Figure 4.8 – Page gestion des utilisateurs

Pour modifier les coordonnées d’un utilisateur, l’administrateur va afficher la liste des
utilisateurs et cliquer sur le boutton ’Edit’ d’un utilisateur. il devra ensuite remplir le
formulaire et valider les données.

45
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

La figure 4.9 représente l’interface de la modification d’un utilisateur.

Figure 4.9 – Interface "Modifier un utilisateur"

Pour supprimer un employé, l’administrateur doit cliquer sur le boutton ’supprimer’.

La figure 4.10 représente l’interface de la suppression d’un utilisateur.

Figure 4.10 – Interface "Supprimer un utilisateur"

46
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

La figure 4.11 représente l’interface d’ajout d’un utilisateur

Figure 4.11 – Interface "Ajouter un utilisateur "

Passons maintenant à Gérer formations l’utilisateur doit ouvrir la page en cliquant

sur « Formulaire » dans le menu principal. Pour ajouter une demande de Formation,
l’utilisateur va remplir le formulaire et cliquer sur Send . Comme la montre la figure 4.12.

Figure 4.12 – interface "créer une demande de Formation"

Passons maintenant à le gestion des formations, en fait afin de remplir la formulaire,une

page contient la liste des formations avec une statut par défaut "WAITTING" doit ouvrir.

47
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

L’interface de liste des formations est présentée dans la figure 4.13

Figure 4.13 – Interface gérer formation

Pour consulter la liste des formations l’administrateur doit ouvrir la page formation
dans le menu principal.

l’interface de liste des formations est présentée dans la figure 4.14

Figure 4.14 – Interface Approuver formation

Pour Approuver les demandes de formation l’administrateur doit Approuver la de-

mande et la statuts change de "WAITING" à "ACCEPTED" ou "REFUSED"

L’interface de liste des formations est présentée dans la figure 4.15.

48
Chapitre 4. Sprint 2 : Gérer utilisateurs, Gérer Formations, Approuver les demandes de
formation

Figure 4.15 – Interface Approuver formation

Après que l’administrateur Approuver les demandes de formation l’état sera changer
dans l’interface de Gérer formation (4.16).

Figure 4.16 – Interface gérer formation

Conclusion

Au cours de ce sprint, nous avons aborder la gestion des utilisateurs ,la gestion de
formations et la gestion d’approuver les demandes de formation en passant par l’analyse
des spécifications des besoins, la conception et la réalisation.

À ce stade il reste les deux modules la gestion des emplois et compétences qui feront
le but du suivant sprint.

49
Chapitre 5
Sprint 3 : Gestion des emplois et compétences

Plan
5.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2.1 Diagramme de cas d’utilisation raffiné « Sprint 3 » . . . . . . 52

5.2.2 Description de cas d’utilisation raffiné « Sprint 3 » . . . . . . 54

5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3.1 Scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3.2 Diagramme des Classes . . . . . . . . . . . . . . . . . . . . . . 65

5.3.3 Description des classes . . . . . . . . . . . . . . . . . . . . . . 65

5.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

50
Chapitre [Link] 3 : Gestion des emplois et compétences

Introduction

Dans ce chapitre, nous allons mettre en relief le dernier sprint qui abordera la gestion
des emplois et les compétences.

5.1 Backlog du sprint 3

Le tableau 5.1 présente la backlog du troisième sprint

Nous citons que l’Acteur définit l’Administrateur

ID Thème Acteur User Story Priorité

Sprint
Gérer les emplois Administrateur En tant qu’administrateur, je Élevée
peux m’authentifier en toute
sécurité.
N°3
En tant qu’administrateur, je Élevée
peux consulter gérer des em-
plois.
Gérer les compé- Administrateur En tant qu’administrateur, je Élevée
tences peux gérer les compétences
En tant qu’administrateur, je Élevée
peux m’authentifier en toute
sécurité.

Table 5.1 – backlog du troisième sprint

5.2 Spécification fonctionnelle

Dans cette partie, nous allons exposer la partie spécification des besoins de notre
troisième Sprint afin de décrire les résultats attendus en terme de fonctionnalités.

51
Chapitre [Link] 3 : Gestion des emplois et compétences

5.2.1 Diagramme de cas d’utilisation raffiné « Sprint 3 »

Ce sprint s’occupe de la gestion des emplois, il traite l’ajout, la modification et le

suppression d’un emploi.

Dans un deuxième lieu, il s’occupe aussi du gestion des compétences, il peut ajouter ,
modifier et supprimer une compétence

Dans la partie gestion des emplois

L’administrateur a la possibilité de :

• Gérer les emplois nécessite l’authentification de l’administrateur, cette relation est

réalisée par l’association « include » entre s’authentifier et Gréer emplois.

• L’administrateur peut Ajouter un emploi , Supprimer un emploi , Modifier un emploi

ou Consulter liste des emplois.

La figure 5.1 illustre le raffinement du cas d’utilisation du Sprint 3 « Gestion des

emplois»

Figure 5.1 – Diagramme de cas d’utilisation raffiné du troisième Sprint "Gestion des
emplois"

Pour la partie gestion des compétences, nous avons un acteur qui joue le rôle d’un
administrateur.

L’acteur administrateur a la possibilité de :

52
Chapitre [Link] 3 : Gestion des emplois et compétences

• Gérer les emplois nécessite l’authentification de l’administrateur, cette relation est

réalisée par l’association « include » entre s’authentifier et Gréer compétence.

• L’administrateur peut Ajouter une compétence , Supprimer une compétence , Mo-

difier une compétence ou Consulter liste des compétences.

La figure 5.2 illustre le raffinement du cas d’utilisation du Sprint 3 « Gestion des compé-
tences»

Figure 5.2 – Diagramme de cas d’utilisation raffiné du troisième Sprint "Gestion des
compétences"

53
Chapitre [Link] 3 : Gestion des emplois et compétences

5.2.2 Description de cas d’utilisation raffiné « Sprint 3 »

[Link] Description du cas d’utilisation « Gérer les emplois »

Le tableau 5.2 fournit une description du cas d’utilisation « Ajouter emploi »

Titre Ajouter emploi

Acteur L’administrateur
Résumé L’application permet l’ajout des emplois.
Description des enchaînements
Pré conditions
• L’administrateur authentifié ;

• L’administrateur a la permission « ajouter emploi ».

Post condi-
tions
• l’emploi est ajouté.

Scénario nominal

• L’administrateur clique Job list dans le menu principal ;

• L’administrateur clique sur le bouton « add» ;

• L’administrateur remplit les champs de cet compétence ;

• L’administrateur valide en cliquant sur « add ».

Scénario alternatif

• Échec à cause d’une erreur interne au niveau de l’application

(exemple échec connexion avec la base de données)

Table 5.2 – Description du cas d’utilisation "Ajouter emploi"

54
Chapitre [Link] 3 : Gestion des emplois et compétences

Le tableau 5.3 fournit une description du cas d’utilisation « Supprimer emploi »

Titre Supprimer emploi

Acteur L’administrateur
Résumé L’application permet la suppression des emplois.
Description des enchaînements
Pré conditions
• L’administrateur authentifié ;

• L’administrateur a la permission « supprimer emploi ».

Post condi-
tions
• L’emploi est supprimé.

Scénario nominal

• L’administrateur clique Job list dans le menu principal ;

• L’administrateur sélectionne l’emploi qu’il veut supprimer ;

• L’administrateur clique sur le bouton supprimer ;

• Le système demande la confirmation de la suppression d’em-

ploi ;

• L’administrateur valide en cliquant sur « Confirmer » ;

Scénario alternatif

• Échec à cause d’une erreur interne au niveau de l’application

(exemple échec connexion avec la base de données).

Table 5.3 – Description du cas d’utilisation "Supprimer emploi"

55
Chapitre [Link] 3 : Gestion des emplois et compétences

Le tableau 5.4 fournit une description du cas d’utilisation « Modifier emploi »

Titre Modifier emploi

Acteur L’administrateur
Résumé L’application permet la modification les chapitres ou les session de
l’emploi.
Description des enchaînements
Pré conditions
• L’administrateur authentifié ;

• L’administrateur a la permission «modifier emploi ».

Post condi-
tions
• L’emploi est modifié.

Scénario nominal

• L’administrateur clique Job list dans son espace.

• L’administrateur sélectionne l’emploi qu’il veut modifier.

• L’administrateur clique sur le bouton mettre à jour .

• Le système affiche un dialogue qui contient les chapitres et les

sessions de l’emploi

• L’administrateur saisie les nouvelles modification .

• L’administrateur clique sur «update »

• Le système fait la modification.

Scénario alternatif

• Échec à cause d’une erreur interne au niveau de l’application

(exemple échec connexion avec la base de données).

56
Chapitre [Link] 3 : Gestion des emplois et compétences

Table 5.4 – Description du cas d’utilisation " Modifier emploi "

Le tableau 5.5 fournit une description du cas d’utilisation « Consulter liste emplois
»

Titre Consulter liste emplois

Acteur L’administrateur
Résumé L’application permet l’affichage du liste des emplois.
Description des enchaînements
Pré conditions
• Liste des emplois est affichée.

Post condi-
tions
• Liste des emplois est affichée.

Scénario nominal

• L’administrateur consulte son espace ;

• L’administrateur clique sur le bouton « Job list » ;

• Le système affiche une liste des emplois.

Table 5.5 – Description du cas d’utilisation "Consulter liste emplois"

[Link] Description du cas d’utilisation « Gérer les compétences »

Le tableau 5.6 fournit une description du cas d’utilisation « Ajouter compétence »

Titre Ajouter compétence

Acteur L’administrateur
Résumé L’application permet l’ajout des compétences.
Description des enchaînements

57
Chapitre [Link] 3 : Gestion des emplois et compétences

Pré conditions
• L’administrateur authentifié ;

• L’administrateur a la permission « ajouter compétence ».

Post condi-
tions
• la compétence est ajouté.

Scénario nominal

• L’administrateur clique Skills list dans le menu principal ;

• L’administrateur clique sur le bouton « add» ;

• L’administrateur remplit les champs de cet compétence ;

• L’administrateur valide en cliquant sur « add ».

Scénario alternatif

• Échec à cause d’une erreur interne au niveau de l’application

(exemple échec connexion avec la base de données)

Table 5.6 – Description du cas d’utilisation "Ajouter compétence"

Le tableau 5.7 fournit une description du cas d’utilisation «Supprimer compétence»

Titre Supprimer compétence

Acteur L’administrateur
Résumé L’application permet la suppression des compétence.
Description des enchaînements

58
Chapitre [Link] 3 : Gestion des emplois et compétences

Pré conditions
• L’administrateur authentifié ;

• L’administrateur a la permission « supprimer compétence ».

Post condi-
tions
• La compétence est supprimé.

Scénario nominal

• L’administrateur clique Skills list dans le menu principal ;

• L’administrateur sélectionne la compétence qu’il veut suppri-

mer ;

• L’administrateur clique sur le bouton supprimer ;

• Le système demande la confirmation de la suppression du la

compétence ;

• L’administrateur valide en cliquant sur « Confirmer » ;

Scénario alternatif

• Échec à cause d’une erreur interne au niveau de l’application

(exemple échec connexion avec la base de données).

Table 5.7 – Description du cas d’utilisation "Supprimer compétence"

Le tableau 5.8 fournit une description du cas d’utilisation «Modifier compétence»

Titre Modifier compétence

Acteur L’administrateur
Résumé L’application permet la modification de les chapitres ou les session
de la compétence.

59
Chapitre [Link] 3 : Gestion des emplois et compétences

Description des enchaînements

Pré conditions
• L’administrateur authentifié ;

• L’administrateur a la permission «modifier compétence ».

Post condi-
tions
• La compétence est modifié.

Scénario nominal

• L’administrateur clique Skills list dans son espace.

• L’administrateur sélectionne la compétence qu’il veut modi-

fier.

• L’administrateur clique sur le bouton mettre à jour .

• Le système affiche un dialogue qui contient les chapitres et les

sessions de la compétence

• L’administrateur saisie les nouvelles modification .

• L’administrateur clique sur «update »

• Le système fait la modification.

Scénario alternatif

• Échec à cause d’une erreur interne au niveau de l’application

(exemple échec connexion avec la base de données).

Table 5.8 – Description du cas d’utilisation " Modifier compétence "

60
Chapitre [Link] 3 : Gestion des emplois et compétences

Le tableau 5.9 fournit une description du cas d’utilisation « Consulter liste com-
pétences »

Titre Consulter liste compétences

Acteur L’administrateur
Résumé L’application permet l’affichage du liste des compétences.
Description des enchaînements
Pré conditions
• Liste des compétences est affichée.

Post condi-
tions
• Liste des compétences est affichée.

Scénario nominal

• L’administrateur consulte son espace ;

• L’administrateur clique sur le bouton « Skills list » ;

• Le système affiche une liste des compétences.

Table 5.9 – Description du cas d’utilisation "Consulter liste compétences"

61
Chapitre [Link] 3 : Gestion des emplois et compétences

5.3 Conception

Nous allons présenter les scénarios à réaliser dans ce sprint 3.

5.3.1 Scénario

[Link] Diagramme de séquence « Ajouter Emlpoi »

La figure 5.3 illustre le scénario de l’opération d’ajout d’un emploi .

Figure 5.3 – Diagramme de séquence "Ajouter Emlpoi "

L’administrateur commence en cliquant sur le bouton "add Job" dans l’interface. L’in-
terface demande alors à l’utilisateur de remplir les champs nécessaires et de valider les
informations.

Une fois validées, l’interface envoie une requête au Service Job, qui traite cette requête
et appelle la méthode addJob() pour ajouter le nouvel emploi dans la base de données
(BD : Jobs). Finalement, l’emploi est ajouté à la base de données, complétant ainsi le
processus.

Les composants impliqués sont l’utilisateur, l’interface, le Service Job et la base de

données.

62
Chapitre [Link] 3 : Gestion des emplois et compétences

[Link] Diagramme de séquence « Supprimer Emploi »

La figure 5.4 illustre le scénario de l’opération de supprimer un emploi .

Figure 5.4 – Diagramme de séquence "Supprimer Emploi"

L’administrateur commence par accéder à la liste des emplois. Le composant JobList

demande au Service Job de récupérer tous les emplois en appelant la méthode getAll(),
qui interroge la base de données (BD : Job) et renvoie la liste des emplois.

La liste est alors affichée à l’utilisateur. L’utilisateur sélectionne un emploi à supprimer.

Une alternative (alt) est ensuite déclenchée pour confirmer la suppression. Si l’utilisateur
confirme, la méthode deleteJob() est appelée sur le Service Job, qui demande à la base
de données de supprimer l’emploi. Si la suppression est confirmée, l’emploi est retiré de
la base de données, complétant ainsi le processus.

Les composants impliqués sont l’utilisateur, JobList, Service Job et la base de données.

63
Chapitre [Link] 3 : Gestion des emplois et compétences

[Link] Diagramme de séquence « Modifier Compétence »

La figure 5.5 illustre le scénario de l’opération de modification d’une compétence .

Figure 5.5 – Diagramme de séquence "Modifier Compétence"

L’administrateur commence en cliquant sur le bouton "Skills list" dans l’interface skills
list. L’interface retourne la liste des compétences.

Après l’interface envoie une requête au Service skill, qui traite cette requête et appelle
la méthode getSkillById(idc) pour récupérer les détails de compétence de la base de
données (BD : Skills) et l’afficher dans l’interface .

Puis, l’administrateur change les cordonnées et valider , une requête envoyer vers
service skill et appelle la méthode "updateSkill(skill)" pour enregistrer les modifications.

Finalement la (BD :Skills) retourne la liste des compétences avec les changement
appliquées.

64
Chapitre [Link] 3 : Gestion des emplois et compétences

5.3.2 Diagramme des Classes

La figure 5.6 représente le diagramme des classe utilisé pour le développement du

dernier Sprint.

Figure 5.6 – Diagramme des classe du Sprint 3

5.3.3 Description des classes

Dans cette section nous décrivons les classes participantes dans ce dernier Sprint (Ta-
bleau 5.10 ).

Classe Description

Utilisateur Présente l’utilisateur (en tant que Administrateur) de

l’application qui appartient à la société.
Administrateur Contient les informations de l’utilisateur dont le rôle ad-
ministrateur.
Formations La classe ayant les listes des formations avec son état.
formation-user Contient les demandes de formation de chaque utilisa-
teur.

65
Chapitre [Link] 3 : Gestion des emplois et compétences

emploi La classe ayant les listes des emplois .

emploi-user La classe ayant les listes des emplois de chaque utilisa-
teur.
compétence La classe ayant les listes des compétences .
compétence-user La classe ayant les listes des compétences de chaque uti-
lisateur .
Role Contient les listes des rôles .
Role-user Contient les Rôles de chaque utilisateur .
Table 5.10 – Description des classes participantes dans ce dernier sprint

5.4 Réalisation

Passons maintenant à le gestion des emplois,l’administrateur doit ouvrir la page de

liste des emplois dans le menu principal (figure 5.7).

Figure 5.7 – Interface gérer emplois

66
Chapitre [Link] 3 : Gestion des emplois et compétences

L’interface de gestion des compétences est présentée dans la figure 5.8

Figure 5.8 – Interface gérer compétence

Conclusion

Finalement, grâce à la méthode Scrum, nous avons pu développer notre solution en

toute sécurité, avec une grande flexibilité et une excellente capacité d’adaptation aux
changements, garantissant ainsi la satisfaction de l’entreprise.

67
Conclusion générale

Ce rapport est le résultat du travail réalisé au sein de l’entreprise Arabsoft dans le cadre
d’un projet de fin d’études pour l’obtention du diplôme national de licence en sciences
informatiques à la Faculté des sciences de Gafsa (FSG). Le but de ce projet était de
développer une application web permettant la digitalisation des processus internes d’une
entreprise en utilisant de nouveaux outils de développement, afin de créer une solution de
gestion des personnels, formations, emplois et compétences .

Nous avons utilisé les méthodes agiles pour le suivi et la gestion du projet, en choisis-
sant la méthode Scrum basée sur des sprints. Pour ce rapport, le travail a été accompli
en trois sprints. De plus, la réalisation de cette application web a été très bénéfique à la
fois techniquement et professionnellement.

En conclusion, ce travail a atteint ses objectifs, mais ce n’est que le début d’un long pro-
cessus. Plusieurs fonctionnalités pourraient enrichir notre application, notamment l’ajout
d’un système de messagerie entre les employés et l’administrateur, ainsi qu’une section
pour la gestion de la paie.

68
Bibliographie

[1] ArabSoft. [Link] (Accessed on 05/02/2024).

[2] Méthode agile. [Link]

les-principales-methodes-agiles/. (Accessed on 07/02/2024).

[3] Scrum board. [Link] (Acces-

sed on 11/02/2024).

[4] Scrum model. [Link]

(Accessed on 05/02/2024).

[5] Html. [Link] (Accessed on 14/03/2024).

[6] Css. [Link] (Acces-

sed on 15/03/2024).

[7] Javasript. [Link] (Accessed on

15/03/2024).

[8] Angular. [Link] (Accessed on 15/03/2024).

[9] Spring boot. [Link]

(Accessed on 17/03/2024).

[10] Xampp. [Link] (Accessed on 15/03/2024).

[11] Intellij. [Link] (Accessed on

15/03/2024).

[12] Visual studio code. [Link] (Ac-

cessed on 15/03/2024).

[13] Gantt. [Link] (Accessed on 15/03/2024).

69
Bibliographie

[14] Overleaf. [Link] (Accessed on 15/03/2024).

[15] Postman. [Link] (Accessed on

15/03/2024).

70