République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Institut Supérieur des Etudes

Technologiques de Kélibia

Rapport de Projet de Fin d’Études

Diplôme : Licence appliquée en informatique
Spécialité : Développement de systèmes d’information

Réalisé par

Nizar BEN BRAHIM

Gestion De Mobilité Interne

Encadrant professionnel : Monsieur Khalil AIT AMMAR Consultant senior

Monsieur Nader BEN SLIMA Consultant senior

Encadrant académique : Madame Itimed BOUAZIZ

Réalisé au sein de Sopra HR Software

Année Universitaire 2017 - 2018

 République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Institut Supérieur des Etudes

Technologiques de Kélibia

Rapport de Projet de Fin d’Études

Diplôme : Licence appliquée en informatique
Spécialité : Développement de systèmes d’information

Réalisé par

Nizar BEN BRAHIM

Gestion De Mobilité Interne

Encadrant professionnel : Monsieur Khalil AIT AMMAR Consultant senior

Monsieur Nader BEN SLIMA Consultant senior

Encadrant académique : Madame Itimed BOUAZIZ

Réalisé au sein de Sopra HR Software

Année Universitaire 2017 - 2018

 Encadrant Entreprise

J’autorise l’étudiant à déposer son rapport de stage en vue d’une soutenance.

Signature et cachet

Encadrant ISET

J’autorise l’étudiant à déposer son rapport de stage en vue d’une soutenance.

Signature
Dédicaces

Je dédie ce modeste travail à . . .

À la mémoire de mon père Moncef
l’être le plus cher au monde en témoignage de mon respect, à mon amour et
mon plus grand rattachement, a l’âme de mon très cher père. Aucune dédicace
ne saurait exprimer l’amour, l’estime, le dévouement que j’ai toujours eu pour
vous. Ce travail est le fruit de tes sacrifices que tu as consentis pour mon
éducation et ma formation.
À ma très chère mère Fatiha
affable, honorable, aimable : Tu représentes pour moi le symbole de la bonté par
excellence, la source de tendresse et l’exemple du dévouement qui n’a pas cessé
de m’encourager et de prier pour moi. Ta prière et ta bénédiction m’ont été
d’un grand secours à bien mener mes études.
À mes très chers frères Foued , Mourad et à ma chére soeur Asma ,
Qui m’ont épargnées le moindre effort pour me soutenir tout au long de mes
études, qu’ils trouvent ici l’expression de ma profonde gratitude et ma
reconnaissance infinie.
À tous mes amis
Pour tous les agréables moments qu’on a vécus ensemble.
À tous ceux qui me sont chers.
À tous ceux qui m’aiment.
À tous ceux que j’aime.

Nizar

i
Remerciements

Je tiens à remercier dans un premier temps, toute l’équipe pédagogique de

Institut Supérieur des Etudes Technologiques de Kélibia et les intervenants pro-
fessionnels responsables de ma formation d’ingénieur en génie logiciel, pour avoir
assuré la partie théorique de celle-ci. Je présente aussi mes sincères reconnais-
sances et gratitude à Madame Itimed BOUAZIZ pour son inspiration, son
support concernant la mission évoquée dans ce rapport, qu’elle m’a apporté lors
des différents suivis. Je remercie tout particulièrement Monsieur Nader BEN
SLIMA et Monsieur Khalil AIT AMMAR de m’avoir intégré rapidement au
sein de l’entreprise et m’avoir accordé toute leur confiance, pour le temps qu’ils
m’ont consacré tout au long de cette période, sachant répondre à toutes mes inter-
rogations, et sans oublier leur participation au cheminement de ce rapport. Mes
remerciements s’adressent également à tous les membres de la société Sopra HR
Software pour leur hospitalité et leurs encouragements. Finalement, je saisis cette
occasion pour remercier les membres du jury en espérant qu’ils trouvent dans ce
rapport les qualités de clarté et de motivation qu’ils attendent.

ii
Table des matières

Introduction générale 1

1 Présentation du cadre du projet 3

1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Présentation de Sopra HR . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Présentation de l’équipe « Outsourcing Service Delivrey » . . . . . . . . 4
1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Analyse et spécification des besoins 8

2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 L’équipe Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Modélisation du contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Modélisation des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Initialisation du projet 16
3.1 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.1 Architecture physique de l’application . . . . . . . . . . . . . . . . . . . . 16
3.1.2 Architecture logicielle de l’application . . . . . . . . . . . . . . . . . . . . 17
3.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1 Diagramme de paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.2 Le diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3 Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Environnements de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

iii
 3.3.2 Activiti Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Outil de gestion de version : SVN . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Mise en œuvre du sprint 1 : Gestion des profils 24

4.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1 Description textuelle « S’authentifier » . . . . . . . . . . . . . . . . . . . 26
4.2.2 Raffinement et description du cas d’utilisation «Gérer Profil» . . . . . . . 27
4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.1 Diagramme de séquence « Authentification » . . . . . . . . . . . . . . . . 30
4.3.2 Diagramme de séquence « Injection de fichiers » . . . . . . . . . . . . . . 31
4.3.3 Conception graphique des maquettes . . . . . . . . . . . . . . . . . . . . 32
4.4 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5.1 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5.2 Accueil Utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5.3 Profil Candidat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6 Tests et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Mise en œuvre du sprint 2 : Gestion des annonces 39

5.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.1 Raffinement de cas d’utilisation « Gérer Annonce » . . . . . . . . . . . . 42
5.2.2 Raffinement de cas d’utilisation « Consulter Annonce » . . . . . . . . . . 44
5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3.1 Processus BPMN 2.0 du « Processus de validation des annonces ». . . . . 45
5.3.2 Diagrammes de séquence du « Statuer les annonces » . . . . . . . . . . . 46
5.3.3 Conception graphique des maquettes . . . . . . . . . . . . . . . . . . . . 48
5.4 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.5.1 Créer annonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.5.2 Statuer annonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.5.3 Consulter et filtrer annonce . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.6 Test et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

iv
6 Mise en œuvre du sprint 3 : Gestion des candidatures 54
6.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.1 Raffinement de cas d’utilisation « Postuler Spontanément » . . . . . . . 56
6.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3.1 Modélisation du processus « Postuler spontanément » . . . . . . . . . . . 58
6.3.2 Diagrammes de séquence du processus « Postuler pour une annonce » . . 59
6.4 Conception graphique des maquettes . . . . . . . . . . . . . . . . . . . . . . . . 61
6.5 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.6.1 L’envoi d’une candidature spontanée . . . . . . . . . . . . . . . . . . . . 64
6.6.2 L’envoi d’une candidature sur annonce . . . . . . . . . . . . . . . . . . . 66
6.6.3 Consulter mes candidatures . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.6.4 Test et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Conclusion générale et perspectives 70

Bibliographie 71

v
Table des figures

1.1 Sopra Steria et ses solutions RH . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Cycle de vie de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Diagramme de contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 Architecture physique de la solution . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Architecture logicielle de l’application . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Diagramme de paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6 Activiti Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Raffinement du CU « Gérer Profil » . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Diagramme de séquence Authentification . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Diagramme de séquence d’injection de fichiers . . . . . . . . . . . . . . . . . . . 32
4.4 Profil utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5 Formations Candidat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6 Compétences Candidat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.7 Diagramme de classes du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.8 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.9 Accueil Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.10 Accueil Gestionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.11 Accueil Candidat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.12 Profil Candidat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.13 Injecter CV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 Raffinement du CU « Gérer annonces » . . . . . . . . . . . . . . . . . . . . . . . 42

5.2 Raffinement du CU « Consulter annonces » . . . . . . . . . . . . . . . . . . . . 44
5.3 Processus de validation des annonces . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 Diagramme de séquence « Consulter annonces en attente » . . . . . . . . . . . . 47
5.5 Diagramme de séquence « Statuer annonce » . . . . . . . . . . . . . . . . . . . . 47

vi
5.6 Maquette « Création Annonce » . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.7 Maquette « Statuer les annonces » . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.8 Maquette « Consulter et filtrer Annonce » . . . . . . . . . . . . . . . . . . . . . 49
5.9 Diagramme de classes du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.10 Interface « Créer annonce » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.11 Notification gestionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.12 Consulter / refuser annonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.13 Mail et notification du manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.14 Interface « Consulter et filtrer annonces » . . . . . . . . . . . . . . . . . . . . . 53

6.1 Raffinement du CU « Postuler Spontanément » . . . . . . . . . . . . . . . . . . 57

6.2 Processus « Postuler spontanément » . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3 Diagramme de séquence « Postuler pour une annonce » . . . . . . . . . . . . . . 60
6.4 Diagramme de séquence « Consulter liste des candidatures » . . . . . . . . . . . 61
6.5 Maquette « Postuler Spontanément » . . . . . . . . . . . . . . . . . . . . . . . . 62
6.6 Maquette « Statuer les candidatures sur les annonces » . . . . . . . . . . . . . . 62
6.7 Diagramme de classes du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.8 Interface « Postuler spontanément » . . . . . . . . . . . . . . . . . . . . . . . . 64
6.9 Notification du candidature spontanée . . . . . . . . . . . . . . . . . . . . . . . 65
6.10 Consulter et statuer candidature spontanée . . . . . . . . . . . . . . . . . . . . . 65
6.11 Notifier candidat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.12 Consulter annonce en détail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.13 Message d’erreur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.14 Consulter les candidatures sur annonce . . . . . . . . . . . . . . . . . . . . . . . 67
6.15 Type de messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.16 Consulter candidatures effectuées . . . . . . . . . . . . . . . . . . . . . . . . . . 68

vii
Liste des tableaux

2.1 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Description textuelle du cas d’utilisation « S’authentifier » . . . . . . . . . . . . 26
4.3 Description textuelle du cas d’utilisation « Gérer profil » . . . . . . . . . . . . . 28

5.1 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2 Description textuelle du cas d’utilisation « Gérer annonce » . . . . . . . . . . . 43
5.3 Description textuelle du cas d’utilisation « Consulter annonce » . . . . . . . . . 44

6.1 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.2 Description textuelle du cas d’utilisation « Postuler spontanément » . . . . . . . 57

viii
Introduction générale

L’élan, l’empressement et la dynamique d’un nouveau besoin de recrutement et d’une nou-

velle quête de talents au sein d’une entreprise nous incitent tout naturellement à foncer. Bien
que l’objectivité et le professionnalisme soient essentiels à la réalisation des objectifs d’un pro-
cessus de recrutement, ils ne suffisent pas à eux seuls. La réussite d’un recrutement est aussi
fonction d’une gestion efficace.

Plébiscitée par de plus en plus d’entreprises, la gestion de mobilité interne s’impose dans des
structures de toutes tailles comme un mode d’organisation particulièrement efficace. L’utilité
d’une solution logicielle en gestion de mobilité interne est indéniable pour une entreprise qui
désire augmenter sa productivité.

Les logiciels de gestion de recrutement interne sont devenus essentiels à l’organisation et à

la mise en œuvre des activités de recrutement de l’entreprise. Suivi et coordination des candi-
datures, contrôle des flux d’offres d’emploi internes, respect des modèles de données et maîtrise
des profils candidats : ces outils polyvalents sont adaptés aux besoins des petites entreprises
comme des grandes structures.

L’objectif de ce projet est de fournir à Sopra HR Software un outil lui permettant d’assurer
le processus de gestion de recrutement interne. Cet outil consiste aussi à définir les processus
de travail de chacun des individus concernés par cette fonction. Aussi optimiser l’utilisation des
ressources humaines allouées au processus de mobilité.

Pour mener à termes ce projet nous avons dû effectuer des choix techniques et méthodolo-
giques, identifier les différents besoins du projet, réaliser une conception détaillée du projet et
enfin implémenter la solution. D’où le présent rapport qui se résume en six chapitres.

Le premier chapitre consistera en une présentation générale qui présentera la société d’ac-
cueil et les différents besoins liés au projet et énoncera le choix de la méthodologie, à savoir la
méthode SCRUM, que nous avons appliquée tout au long de la création de l’application.

1
Introduction générale

Dans le deuxième chapitre, nous commencerons par la présentation du sprint 0. Nous présen-
terons l’étude fonctionnelle du système à travers l’identification des acteurs principaux ainsi que
les besoins fonctionnels et non fonctionnels du projet, puis présenter le diagramme de contexte et
de cas d’utilisation global. Nous clôturons le chapitre par la présentation du backlog du produit.

Le troisième chapitre sera consacré à la réalisation du premier sprint, nous commencerons

donc par la présentation du backlog du sprint. Nous passerons ensuite à la présentation de la
conception préliminaire du projet et le prototype graphique de l’application.
Et nous terminerons par les études fonctionnelle, statique et dynamique des histoires choisies
dans ce sprint, puis les tests et la présentation des interfaces BOOTSTRAP réalisées.

Dans le quatrième chapitre nous passerons au deuxième sprint, nous commencerons donc par
la présentation du backlog du sprint. Ensuite, nous présenterons les études fonctionnelle, sta-
tique et dynamique, et nous terminerons par les tests et la présentation des interfaces BOOTS-
TARP réalisées.

En partant sur le même principe que le chapitre précédent, nous réaliserons un sprint par
chapitre, le cinquième et le sixième chapitre représenteront donc les deux derniers sprints du
projet.

Enfin, pour le chapitre réalisation, nous présenterons l’environnement matériel et logiciel du

travail.

Finalement, nous clôturerons notre rapport par une conclusion qui offre une synthèse du
travail réalisé ainsi que les perspectives envisagées.

2
 Chapitre 1

Présentation du cadre du projet

Introduction
Avant de traiter le sujet de notre projet, nous commençons tout d’abord par présenter
l’organisme d’accueil « Sopra HR Software » et son domaine d’activité. Nous donnons ensuite,
une vue globale sur le sujet, son thème ainsi qu’une description de la solution proposée. La
dernière partie sera consacrée pour décrire la méthodologie de travail adoptée.

1.1 Présentation de l’organisme d’accueil

Notre stage de fin d’études a été effectué au sein de l’unité organisationnelle Outsourcing
Service Delivery (OSD) de l’entreprise SOPRA HR SOFTWARRE.

1.1.1 Présentation de Sopra HR

Sopra HR Software, filiale de Sopra Steria, est une SSII spécialisée dans le domaine de
création des progiciels de gestion des ressources humaines dans le secteur privé et publique.
La figure 1.1 montre les solutions offertes par Sopra Steria dans ce domaine ainsi qu’une vue
globale sur son historique [1].

Figure 1.1: Sopra Steria et ses solutions RH

3
Chapitre 1. Présentation du cadre du projet

En effet, Sopra HR Software est issue de la fusion de plusieurs entités qui sont :

• acquisition de HR Access par Sopra Steria en 2013 ;

• intégration de HCM IBM en 2014 ;

• et enfin, la création de la filiale Sopra HR Software en 2015.

Les solutions offertes par Sopra HR Software couvrent les sujets de gestion administrative
et paie, gestion des temps et des activités, espaces Collaboratifs et finalement la gestion des
talents [2].

1.1.2 Présentation de l’équipe « Outsourcing Service Delivrey »

L’équipe OSD a pour mission d’accompagner ses clients tout au long du cycle de vie de
leurs projets. Elle permet de :

• faire le suivi de la facturation ;

• animer le comité de suivi et de pilotage ;

• assurer le suivi de la paie ;

• tester et livrer les produits ;

• négocier le renouvellement des contrats.

1.2 Présentation du projet

Dans cette section du chapitre, nous nous sommes focalisés sur la description du contexte
de notre projet, suivi d’une présentation de la problématique et de la solution proposée.

1.2.1 Contexte du projet

La phase de recrutement représente une tâche primordiale que chaque entreprise doit passer
par dans le but de trouver un candidat qui correspond mieux aux besoins d’un poste donné.
Avant de passer au recrutement en externe, plusieurs entreprises optent pour le recrutement en
interne qui présente plusieurs avantages pour l’entreprise et pour le salarié :

• pour l’entreprise : avec la mobilité interne, elle offre à ses collaborateurs des opportu-
nités d’évolution et s’assure de la fidélité de ses salariés. Avec ce genre de recrutement, le
cursus d’intégration et le risque de la non-adéquation avec le poste est réduit vu que le
salarié appartient déjà à l’entreprise. Elle peut avoir rapidement un collaborateur opéra-
tionnel ;

4
Chapitre 1. Présentation du cadre du projet

• pour le salarié : la mobilité interne représente une source de motivation pour le salarié.
En effet, ce dernier aura la possibilité d’évoluer sans changer d’employeur et de continuer
sa carrière professionnelle dans un contexte connu.

1.2.2 Problématique

Dans cette section, nous allons présenter la problématique menant à la réalisation de ce

projet avant de passer à la description de la solution proposée. Interne comme externe, le
recrutement présente une tâche difficile et délicate à effectuer. L’évolution du marché de travail
a prouvé que les méthodes de recrutement classiques sont devenues obsolètes. D’où le besoin de
migrer vers les systèmes informatiques. En effet, le nombre d’outils de gestion de recrutement
interne augmente considérablement ces dernières années, mais les logiciels gratuits ne sont pas
parfaitement adaptés aux besoins de Sopra HR Software, alors que les logiciels propriétaires
sont très couteux. Ces derniers sont basés sur l’utilisation des algorithmes de correspondance
entre les critères d’un poste et les profils des candidats. C’est ce qu’on appelle le « matching »
et qui a pour objectif de trier les candidatures et les annonces selon un ordre de correspondance
afin de faciliter la tâche des gestionnaires de recrutement ainsi que celle des candidats. Les
outils de matching sont devenus des systèmes complexes et qui subissent plusieurs problèmes à
savoir l’inexactitude de mise en correspondance entre les profils candidat et les annonces.
Il existe plusieurs façons pour faire la correspondance notamment :

• clustering ou encore le partitionnement des données : qui représente une tâche

du data mining (l’exploration des données). Le clustering est une méthode d’analyse
des données qui permet de diviser automatiquement un ensemble d’instances en sous-
ensemble d’instances ayant des caractéristiques communes. Pour son implémentation, il
existe divers algorithmes à savoir K-means et DBScan ;

• calcul de score : c’est un algorithme qui repose sur l’évaluation des compétences métier
adaptées aux besoins du poste. Un score sera affecté à chaque candidat et qui présente
sa correspondance avec l’annonce publiée. Les candidatures seront alors classées selon la
performance des candidats au poste. Grâce à cet algorithme, le candidat n’est pas jugé
dans l’absolu, mais bien sur la validation des compétences et sur son adéquation au poste.

1.2.3 Solution proposée

Pour remédier à ce genre de problème, nous proposons une solution avec des fonctionnalités
qui permettent non seulement de faciliter la tâche de recrutement mais aussi de la rendre

5
Chapitre 1. Présentation du cadre du projet

automatisée grâce à l’utilisation des Worfklows. Parmi les tâches à automatiser, nous citons
le processus de postulation et de gestion des candidatures, la publication des annonces et la
planification des entretiens. Notre solution se base aussi sur la création des profils pour éviter
le problème d’extraction des informations à partir des CVs et aussi pour accroître le taux de
fiabilité de notre algorithme de matching qui sera basé sur l’algorithme de calcul de score comme
décrit dans la partie précédente.

1.3 Méthodologie de travail

La finalisation des projets dans les délais de livraison représente le souci majeur que chaque
équipe de développement doit respecter. Le changement brusque ou l’évolution des besoins est
un problème souvent fréquenté lors de la construction du logiciel et qui a un impact direct sur
les durées consacrées pour la réalisation des projets. Pour éviter ce genre de situations, il faut
utiliser une méthode agile pour la gestion du cycle de vie de notre projet. Nous avons opté pour
la méthode de Scrum vu les avantages qu’elle offre.
Scrum est un Framework d’organisation de développement de produits de moyenne et haute
complexité et qui est basé sur les Sprints qui permettent la répartition du projet en itérations
qui peuvent aller d’une à quatre semaines. L’équipe Scrum est composée de [3] :

• product Owner : représente le client et les utilisateurs du projet. Il a pour objectif de

créer le backlog et de le mettre à jour en cas de besoin. Donc son rôle est de définir le
produit, de prioriser et valider les fonctionnalités ;

• scrum Master : : s’assure que les principes et les valeurs de Scrum sont respectés. Il est
responsable de la bonne compréhension et la mise en œuvre de cette méthode et il facilite
aussi la communication au sein de l’équipe ;

• l’équipe de développement : constituée généralement de 6 à 10 personnes et qui ont

pour objectif d’accomplir des tâches demandées.

La première étape consiste à découper le projet en fonctionnalités qui sont listées dans un
backlog sous forme de tableau. Chaque jour, l’équipe se réunit pour la « mêlée quotidienne
» d’une durée de quinze minutes et dans le but de synchroniser l’équipe, de mettre au point
les tâches en cours et d’identifier les points de blocage. A la fin de chaque sprint, l’équipe
de développement se réunit pour effectuer « la revue du sprint » pour rappeler les objectifs
et indiquer les fonctionnalités du sprint. Après, l’équipe révise le rendu du sprint pour des
petites rectifications et améliorations pour classer la tâche comme « valide ». En suivant le
même enchaînement pour tous les sprints, on aura finalement la version « release » du travail

6
Chapitre 1. Présentation du cadre du projet

demandé et qui présente la version finale à être livrée au client.

La figure 1.2 illustre le déroulement du processus de Scrum [4] :

Figure 1.2: Cycle de vie de Scrum

Conclusion
Au cours de ce chapitre, nous avons présenté le cadre général de notre projet. Dans un
premier temps, nous avons décrit l’organisme d’accueil « Sopra HR Software » et le thème de
notre sujet. Ensuite, nous avons décrit d’une manière générale les objectifs de notre solution
ainsi que la méthode de développement Scrum. Le chapitre suivant sera consacré pour l’étude
et l’analyse des besoins de notre projet.

7
 Chapitre 2

Analyse et spécification des besoins

Introduction
Afin de garantir la réussite et l’efficacité de notre projet, nous définissons avec précision les
besoins de notre future solution. Ce chapitre liste, dans un premier lieu, les différents acteurs de
notre application suivi d’une description de l’équipe Scrum. Ensuite, nous identifions les besoins
fonctionnels en se basant sur un Backlog produit. Et finalement, ce chapitre sera clôturé par la
modélisation des différents diagrammes de cas d’utilisation.

2.1 Identification des acteurs

Généralement l’acteur représente une entité externe qui interagit avec le système. Notre
application est destinée pour trois acteurs qui sont :
Manager : le Manager d’une unité organisationnelle. Il utilise l’application pour demander la
création des annonces, gérer la liste des candidatures spontanées et les dates d’entretiens.
Gestionnaire : le Gestionnaire de recrutement. Il utilise notre solution afin de rédiger et gérer
les annonces. C’est lui le responsable de sélection des candidatures et de validation d’affectation
d’un candidat à un poste ou non. Il planifie aussi les dates d’entretiens.
Candidat : c’est un collaborateur de l’entreprise disposant d’un compte dans l’application de
mobilité interne. Il l’utilise dans le but de gérer son profil, de consulter les offres, de postuler
et de suivre l’état de ses candidatures.

8
Chapitre 2. Analyse et spécification des besoins

2.2 L’équipe Scrum

L’objectif de chaque équipe consiste à délivrer un incrément du produit potentiellement
livrable à la fin de chaque Sprint. Notre équipe est divisée comme suit :

Product Owner (PO) : Nader BEN SLIMA.

Scrum Master (SM) : Khalil AIT AMMAR.

Équipe de développement : Nizar BEN BRAHIM et Bilel AOUISSAOUI.

2.3 Identification des besoins

L’analyse des besoins permet de rechercher, ordonner et décrire les fonctionnalités de notre
système pour avoir une vision claire sur les besoins souhaités. Tout au long de cette partie, nous
décrivons notre backlog produit ainsi que les besoins non-fonctionnels que notre application doit
fournir.

2.3.1 Backlog Produit

Le backlog produit contient la liste de toutes les fonctionnalités attendues d’un produit. Il
est élaboré et mis à jour par le Product Owner. Notre backlog a été élaboré avant le lancement
des sprints, dans la phase de préparation et contient les éléments suivants :

• Feature : notre projet est divisé en quatre features qui contiennent un ensemble d’his-
toires utilisateurs à savoir Gestion des candidatures GC, Gestion des profils GP ou Gestion
des annonces GA ;

• user story : elle décrit une fonctionnalité désirée par le client ;

• ID User sotry : c’est un nombre unique et auto-incrémenté pour chaque user story ;

• Story point : il est estimé par l’équipe lors d’une séance de planning pocker et qui
représente l’effort nécessaire pour la réalisation d’une histoire utilisateur ;

• Priorité : priorité par rapport aux attentes du client. Nous nous sommes basés sur la
méthode de « MoSCoW ». En effet, MoSCoW signifie :

M (Must) : doit être fait.

S (Should) : devrait être fait.

C (Could) : pourrait être fait.

W (won’t) : ne sera pas fait cette fois mais sera fait plus tard.

9
Chapitre 2. Analyse et spécification des besoins

Dans le tableau 2.1, nous présentons la liste des histoires utilisateurs ainsi que leurs estima-
tions.

Tableau 2.1: Backlog du produit

Feature ID User Story Priorité Story

User Point
Story
GP GP1 En tant que Gestionnaire je veux m’authentifier. M 23
GP GP2 En tant que Manager je veux m’authentifier. M 23
GP GP3 En tant que Candidat je veux m’authentifier. M 23
GP GP4 En tant que Gestionnaire je veux consulter et modifier C 23
mes informations personnelles.
GP GP5 En tant que Manager je veux consulter et modifier mes C 23
informations personnelles.
GP GP6 En tant que Candidat je veux consulter et modifier mes M 23
informations personnelles.
GP GP7 En tant que Candidat je veux gérer la liste de mes M 23
compétences, mes formations ainsi que la liste de mes
expériences.
GP GP8 En tant que Candidat, je veux télécharger et mettre à M 23
jour mon CV ainsi que ma lettre de motivation.
GA GA1 En tant que Manager, je veux créer des annonces. M 23
GA GA2 En tant que Manager, je souhaite consulter et filtrer la C 23
liste des annonces.
GA GA3 En tant que Manager, je veux recevoir un mail et une S 23
notification en temps réel indiquant la validation ou non
de mon annonce.
GA GA4 En tant que Gestionnaire, je veux publier des an- M 23
nonces.
GA GA5 En tant que Gestionnaire je veux être notifié lors de S 23
la création d’une nouvelle annonce par le Manager.
GA GA6 En tant que Gestionnaire, je veux statuer les annonces M 23
des Managers.

10
Chapitre 2. Analyse et spécification des besoins

GA GA7 En tant que Gestionnaire, je souhaite consulter et fil- C 23

trer la liste des annonces.
GA GA8 En tant que Candidat veux consulter, enregistrer et S 23
retirer les annonces de mon panier.
GC GC1 En tant que Candidat je veux postuler pour une an- M 23
nonce précise.
GC GC2 En tant que Candidat je veux envoyer une candidature M 23
spontanée.
GC GC3 En tant que Candidat je veux consulter et filtrer mes S 23
candidatures.
GC GC4 En tant que Candidat je veux être notifié de l’état de S 23
mes candidatures.
GC GC5 En tant que Manager je veux être notifié des candi- C 23
datures spontanées destinées à mon unité organisation-
nelle.
GC GC6 En tant que Manager je veux consulter la liste des can- M 23
didatures spontanées triées et les statuer.
GC GC7 En tant que Manager je veux consulter et filtrer la liste S 23
des candidats sélectionnés.
GC GC8 En tant que Gestionnaire je veux consulter la liste des M 23
candidatures sur les annonces triée et les statuer.
GC GC9 En tant que Gestionnaire je veux consulter et filtrer S 23
la liste des candidats sélectionnés.

2.3.2 Besoins non fonctionnels

Un besoin non fonctionnel est considéré comme une contrainte qui dépend d’un service
du système telle que les contraintes de l’environnement et de l’implémentation, la facilité de
maintenance, la rapidité et la fiabilité. Ce type de besoin dépend généralement de critères de
performances [5].

11
Chapitre 2. Analyse et spécification des besoins

Pour des raisons de performance et de fiabilité, notre application doit assurer les besoins non
fonctionnels suivants :

• ergonomie : étant donné que notre application sera destinée aux collaborateurs de Sopra
HR Software, nous avons choisi de développer des pages Web qui respectent la même
architecture que celle d’un projet populaire dans l’entreprise « 4you ». Du coup, les
utilisateurs ne trouvent pas une difficulté à naviguer entre les différentes pages ;

• sécurité : l’accès à l’application et la consommation des Web services doivent être sécu-
risés et contrôlés en tenant compte des droits d’accès et des permissions. C’est pour cette
raison que nous nous sommes basés sur Spring Security et JWT ;

• responsive : notre application doit être responsive pour qu’elle fonctionne sur tout type
de dispositif . Ce besoin sera assuré grâce à l’utilisation de Bootstrap ;

• modularité et extensibilité : le système doit tenir en compte la possibilité de son

extension par l’ajout de nouvelles fonctionnalités ;

• maintenabilité : diminuer l’effort nécessaire pour localiser et corriger un défaut dans

l’application. Il faut donc structurer et organiser convenablement le code source.

2.4 Modélisation du contexte

Le diagramme de contexte est utilisé dans le but de synthétiser les échanges de messages
entre le système et ses différents acteurs qui sont représentes par la figure 2.1.

12
Chapitre 2. Analyse et spécification des besoins

Figure 2.1: Diagramme de contexte

2.5 Modélisation des besoins fonctionnels

Dans cette section, nous illustrons les différents diagrammes de cas d’utilisation. Nous en-
tamons l’illustration par le diagramme de cas d’utilisation global qui contient toutes les fonc-
tionnalités de notre application et nous clôturons par le raffinement et la description textuelle
de quelques cas d’utilisation.
La figure 2.2 représente le diagramme de classe global qui sera explicité au fur et à mesure.

13
Chapitre 2. Analyse et spécification des besoins

Figure 2.2: Diagramme de cas d’utilisation global

2.6 Planification des sprints

Le travail sera planifié selon un ensemble de sprints. La durée de chaque sprint varie entre
deux et quatre semaines. Chaque sprint présente une phase de test durant laquelle nous validons
les cas d’utilisation que nous avons terminés. Après une réunion avec l’équipe, nous avons

14
Chapitre 2. Analyse et spécification des besoins

identifié trois sprints :

Notre travail sera divisé en trois sprint. En effet, chaque sprint dure entre deux et quatre
semaines et qui sera clôturé par une phase de test et de validation.
Après une réunion effectuée avec toute l’équipe, nous avons identifié nos quatre sprints qui sont
présentés par le tableau 2.2.

Tableau 2.2: Planification des sprints

Sprint Nom du sprint Période

Sprint 1 Gestion des profils Du 05-03 au 30-03
Sprint 2 Gestion des annonces Du 02-04 au 01-05
Sprint 3 Gestion des candidatures et postulation Du 02-05 au 01-06

Conclusion
Tout au long de chapitre, nous avons identifié l’équipe Scrum, les acteurs de notre système,
les besoins fonctionnels et non fonctionnels ainsi que le Backlog produit. Ensuite, nous avons
analysé les différents besoins à travers des diagrammes de cas d’utilisation d’UML. Le chapitre
suivant sera consacré à l’initialisation de notre projet dans lequel nous illustrons l’architecture
de notre solution.

15
 Chapitre 3

Initialisation du projet

Introduction
La phase de conception consiste à modéliser une solution qui résout les problèmes rencontrés
pendant la phase d’analyse des besoins. Ce chapitre est consacré à l’étude de l’architecture
proposée par notre solution, le diagramme de paquetage ainsi que le diagramme de composants.
Et finalement, nous présentons la structure de l’application via le diagramme de classes .

3.1 Architecture de la solution

Nous présentons, dans cette partie, l’architecture physique et logicielle de notre solution.

3.1.1 Architecture physique de l’application

Pour la réalisation de notre solution on a opté pour l’architecture de type « trois tiers » qui
est partagé entre :

• le client : qui représente le navigateur web utilisé par l’utilisateur de notre application ;

• le serveur : qui reçoit toutes les requêtes de la part des clients, les traite en faisant appel
à la couche de base des données ;

• le serveur de base des données : qui permet de partager les données stockées avec la
couche métier.

La figure 3.1 présente les différents tiers de l’architecture de notre solution.

16
Chapitre 3. Initialisation du projet

Figure 3.1: Architecture physique de la solution

3.1.2 Architecture logicielle de l’application

Notre solution se compose de trois couches différentes : couche de présentation, couche

métier et couche d’accès aux données. La figure 3.2 illustre l’architecture logicielle de notre
application.

Figure 3.2: Architecture logicielle de l’application

17
Chapitre 3. Initialisation du projet

Partie Front End :

Étant donné que nous avons adopté le Framework Angular, la partie Front de notre application
est basée sur le motif MVC fournissant une organisation rigoureuse et flexible :

• La vue d’une application basée sur Angular est créée avec des fragments HTML dont
chaque composant est caractérisé par son propre bout de code HTML.

• Le modèle : Il s’agit des classes .ts responsable du maintien des données qui vont être
traité par le contrôleur.

• Le contrôleur permet d’établir la synchronisation et la jonction entre la vue et le mo-

dèle. Il représente les composants ayant l’extension .ts et les services.

Partie Back end :

Pour la partie Back end, notre choix s’est orienté vers Spring Boot comme nous l’avons déjà
évoqué dont les différents parties sont :

• Couche Web : elle est basée sur des Web services de type REST sur le protocole HTTP,
tout en utilisant le format d’échange de données JSON. Elle permet la communication
entre la partie client et la couche métier ;

• Couche métier : cette couche contient la partie fonctionnelle qui est présentée par
l’ensemble d’opérations et de services offerts par notre application. On trouve aussi dans
cette partie le moteur de workflow Activiti qui a pour objectif de gérer les différents
processus dans notre application ;

• Couche DAO : elle permet la persistance et la récupération des données grâce à l’utili-
sation de Jpa et Hibernate qui ont pour but de faire la correspondance ente nos Objets
Java et les tables correspondantes dans la base de données ;

Le développement de la partie frontale a été effectué grâce à l’utilisation des frameworks

Angular et Bootstrap ainsi que l’utilisation de Html5 et css3.

18
Chapitre 3. Initialisation du projet

3.2 Conception détaillée

Dans cette partie nous illustrons le diagramme de paquetage, de déploiement ainsi que le
diagramme de composants.

3.2.1 Diagramme de paquetages

Le diagramme de paquetages illustré dans la figure 3.3 est un diagramme structurel d’UML
qui représente les paquetages ou encore les espaces de noms qui composent un système, ainsi
que les relations qui lient ces différents paquetages.

Figure 3.3: Diagramme de paquetages

3.2.2 Le diagramme de déploiement

Les diagrammes de déploiement modélisent l’architecture physique d’un système. Ils af-
fichent aussi les relations entre les composants matériels et logiciels du système, ainsi que la
distribution physique du traitement.
Le diagramme de la figure 3.4 montre la manière avec laquelle nous avons déployé notre
application en fonction des différents composants.

19
Chapitre 3. Initialisation du projet

Figure 3.4: Diagramme de déploiement

Nous avons utilisé deux types de lien de communication qui sont les suivants :

• Http, Json : ce lien représente la communication entre le navigateur du client et notre

serveur via le protocole http tout en utilisant le format d’échange de données JSON ;

• JDBC : c’est une API qui permet l’accès, à partir des programmes Java, à des données
sous formes de tableau.

3.2.3 Diagramme de composants

Les diagrammes de composants représentent la structure du système logiciel qui décrit

les composants du logiciel, leurs interfaces et leurs dépendances. La figure 3.5 représente le
diagramme de composants de notre application.

Figure 3.5: Diagramme de composants

20
Chapitre 3. Initialisation du projet

3.3 Environnements de travail

Tout au long de cette partie, nous allons présenter les technologies, les langages ainsi que
les outils utilisés lors de la phase de développement. Ensuite, nous donnons une description
détaillée sur l’API Activiti Workflow.

3.3.1 Environnement logiciel

• Spring : c’est un Framework de développement d’applications, qui se base généralement

sur un conteneur qui implémente l’inversion de contrôle Ioc. Ce conteneur Ioc prend en
charge la gestion des dépendances et le cycle de vie des objets. Spring a aussi recourt à
la programmation orientée aspect AOP ;

• Spring Boot : représente un projet qui a été mis en œuvre dans le but de faciliter le
développement et la configuration d’un projet Spring ;

• Spring Security : utilisé pour assurer l’authentification et la gestion des rôles de l’ap-
plication ;

• Json Web Token (jwt) : c’est un standard qui définit dans la RFC 7519. Il permet
l’échange sécurisé de jetons, appelés tokens, entre plusieurs parties. Cette sécurité se
traduit par la vérification de l’intégrité des données à l’aide d’une signature numérique.
Elle s’effectue par l’algorithme HMAC ou RSA ;

• Java : c’est le langage de programmation orientée objet utilisé lors du développement ;

• JEE : c’est une édition dédiée à la réalisation d’applications pour entreprises et qui
contient les APIs de base de Java ;

• Java Persistence API (JPA) : c’est le standard utilisé pour faire la correspondance
entre les objets et les tables ;

• Hibernate : c’est un Framework qui fait la correspondance(mapping) entre les objets

Java et les tables de notre base de données. Hibernate représente une implémentation de
JPA ;

• JavaScript Object Notation (JSON) : c’est le format d’échange de données utilisé

dans notre application. JSON est issue du langage de programmation JavaScript ;

• Angular : c’est un Framework JavaScript qui respecte l’architecture MVC (Model View
Controller)/MVVM (Model View ViewModel) côté client et qui étend le HTML pour le
rendre dynamique. Il permet de développer ses propres balises et attributs HTML ;

• Html : représente le langage de balisage utilisé pour la création des pages Web.

21
Chapitre 3. Initialisation du projet

• Css : c’est le langage qui permet d’insérer des règles dans les pages Web afin de gérer leurs
présentations. Ces règles portent essentiellement sur le positionnement, l’alignement des
éléments, les polices de caractères, les couleurs, les marges et espacements, les bordures
ainsi que les images de fond .

• Bootstrap : il a été créé en 2011 par Twitter comme une solution à usage interne pour
répondre aux besoins de l’équipe de développement. C’est un Framework Css et JavaScript
qui permet la création des applications Web.

• BPMN 2.0 (Business Process Model notation) : c’est une norme de notation pour
la modélisation des processus.

• UML (Unified Modeling Language) : pour concevoir notre système, nous avons
choisi UML comme langage de modélisation. Ce choix est basé sur les points forts de ce
dernier et sur les divers diagrammes qu’il propse.

3.3.2 Activiti Workflow

Activiti présente un projet open source de gestion des processus métiers. Lancé en 2010
sous licence Apache, Activiti est un moteur de Workflow qui permet d’implémenter le nouveau
standard BMPN 2.0 crée par l’OMG (Object Management Group).

Figure 3.6: Activiti Workflow

L’API Activiti est constituée de quatre composants qui sont :

• Activiti Engine : c’est le moteur de cette API. Il est composé d’un ensemble de biblio-
thèques permettant la gestion des processus BPM. La définition des modèles se fait grâce
à un fichier crée en XML. Cette API permet de créer facilement les classes Java et les
Unit tests ;

• Activiti Modeler : il permet de compose le Workflow en Bpmn. Il est basé sur le

modeleur de Signavio .

• Activiti Explorer : ce composant permet de déployer les définitions des processus et de

lancer des nouvelles instances.

• Activiti Designer : il est représenté par un module d’extension Eclipse qui permet de
développer les Workflows.

22
Chapitre 3. Initialisation du projet

Cette API se base sur plusieurs services parmi lesquelles on cite les plus importantes :

• RepositoryService : c’est le premier service nécessaire pour travailler avec cette API.
Il offre des opérations de gestion des définitions et de déploiement des processus.

• RuntimeService : il permet de créer une instance de processus d’après son identifiant

de définition précisé dans le fichier XML et de rechercher des instances d’un processus
donné. Ce module est destiné à l’exécution des tâches créées.

• FormService : ce module soumet les propriétés des formulaires associés aux étapes
initiales.

• TaskService : il permet de créer et de rechercher les tâches créées

3.4 Outil de gestion de version : SVN

Lors d’un travail en équipe, l’utilisation d’un outil de gestion des versions est indispensable.
C’est pour cette raison que nous avons utilisé Subversion (SVN) qui représente un logiciel de
contrôle des versions et de gestion de code source.
SVN offre plusieurs fonctionnalités à savoir :

• garder un historique des différentes versions des fichiers d’un projet ;

• permettre le retour à une version antérieure quelconque

• garder un historique des modifications avec leur nature, leur date ainsi que leur auteur ;

• permettre à des utilisateurs distincts et souvent distants de travailler ensemble sur les
mêmes fichiers

Conclusion
A travers ce chapitre, nous avons décrit l’architecture ainsi que les différents diagrammes
de notre application. Ensuite, nous avons détaillé les différents outils utilisés. En arrivant à ce
stade, nous pouvons dire que nous avons pu présenter la future application. Les deux premières
phases d’analyse et de conception constituent une préparation pour la phase de réalisation, qui
va être le sujet de notre prochain chapitre.

23
 Chapitre 4

Mise en œuvre du sprint 1 : Gestion

des profils

Introduction
Le présent chapitre consiste à présenter les différentes étapes de la réalisation de notre
premier Sprint : Gestion des profils. Dans un premier lieu, nous allons présenter le backlog
produit de ce sprint. Ensuite, nous détaillons la conception de ce dernier, tout en se basant sur
les maquettes ainsi que les diagrammes de séquence. Et finalement, nous clôturons par la partie
réalisation, dans laquelle nous décrivons quelques interfaces de notre solution.

4.1 Backlog du sprint 1

Le tableau 6.1 illustre le backlog produit de notre premier sprint ainsi que les différentes
tâches effectuées pour chaque histoire utilisateur.

Tableau 4.1: Backlog du sprint

ID Tâches Estimation
(h/h)
GP1 Analyse : préparation de la maquette d’authentification. 1
GP2
GP3

24
Chapitre 4. Mise en œuvre du sprint 1 : Gestion des profils

Développement de la partie Backend : création des ser- 24

vices en utilisant Spring Security et JWT pour la gestion de
l’authentification et la récupération des rôles pour la gestion
des sessions.
Développement de la partie Frontend : création des ser- 6
vices avec Angular pour la communication avec la partie ba-
ckend et pour la gestion de l’authentification et des sessions
selon le rôle de l’utilisateur connecté.
Design : développement de l’interface d’authentification . 6

GP4 Analyse : préparation de la maquette du profil utilisateur. 2

GP5
GP6
Développement de la partie Backend : création des 12
contrôleurs pour la lecture et la modification des informations
personnelles.
Développement de la partie Frontend : création des ser- 8
vices pour assurer la communication avec la partie backend
et la couche de données.
Design : développement de l’interface du profil utilisateur. 8

GP7 Analyse :préparation de la maquette d’authentification. 2

Développement de la partie Backend : création des ser- 6
vices pour la lecture, l’ajout, la modification et la suppression
des données du candidat.
Développement de la partie Frontend : création des ser- 4
vices pour assurer la mise à jour des compétences, expériences,
certificats et formations.
Design : développement de l’interface du profil candidat. 8

GP8 Analyse : analyser et choisir l’emplacement des CVs et des 1

LMs.

25
Chapitre 4. Mise en œuvre du sprint 1 : Gestion des profils

Développement de la partie Backend : création du ser- 5

vice « StorageService » qui permet la gestion de stockage et
de récupération des fichiers. Aussi, la création du Web service
qui utilise le service décrit précédemment.
Développement de la partie Frontend : implémentation 5
du service qui permet la manipulation des fichiers du candidat.
Design : création des composants nécessaires pour le télé- 4
chargement, l’affichage et la manipulation des fichiers.

4.2 Analyse
4.2.1 Description textuelle « S’authentifier »

Le tableau 4.2 montre la description textuelle du cas d’utilisation « S’authentifier ».

Tableau 4.2: Description textuelle du cas d’utilisation « S’authentifier »

Cas d’utilisation S’authentifier

Objectif Accéder aux fonctionnalités de l’application.
Acteurs Utilisateur
Pré condition L’utilisateur possède déjà un compte.
Post condition Génération d’un jeton à l’utilisateur authentifié et l’en-
voyer.
Scénario nominal 1. L’utilisateur saisit son username et son mot de passe,
2. Le système vérifie les données saisies,
3. Le système récupère le rôle associé à l’utilisateur au-
thentifié avec succès,
4. Le système lui permet d’accèder à son espace person-
nel.
Scénario d’exception 1. L’utilisateur n’a pas saisi les bons identifiants,
2. Le système renvoie un message d’erreur et signale à
l’utilisateur de recommencer.

26
Chapitre 4. Mise en œuvre du sprint 1 : Gestion des profils

4.2.2 Raffinement et description du cas d’utilisation «Gérer Profil»

La figure 4.1 illustre le diagramme de cas d’utilisation « Gérer Profil Candidat» d’une
manière détaillée.

Figure 4.1: Raffinement du CU « Gérer Profil »

27
Chapitre 4. Mise en œuvre du sprint 1 : Gestion des profils

Le tableau 4.3 montre la description textuelle du cas d’utilisation « Gérer Profil ».

Tableau 4.3: Description textuelle du cas d’utilisation « Gérer profil »

Cas d’utilisation Gérer profil

Objectif Gérer les informations des profils utilisateurs.
Acteurs Utilisateur, Candidat.
Pré condition L’utilisateur s’est authentifié.
Post condition Changement des informations du profil effectué avec succès.

28
Chapitre 4. Mise en œuvre du sprint 1 : Gestion des profils

Scénario nominal Consulter les informations personnelles :

1. L’utilisateur accède à ses informations personnelles,
2. Le système affiche la page contenant toutes ses informa-
tions,
3. L’utilisateur choisit de modifier ses informations,
4. Le système affiche l’interface de modification,
5. L’utilisateur effectue des changements et valide,
6. Le système sauvegarde les changements et affiche un mes-
sage de succès.
Modifier photo :
1. L’utilisateur choisit de modifier sa photo,
2. Le système affiche une interface dans laquelle l’utilisateur
est demandé à joindre sa photo,
3. L’utilisateur joint une photo et valide,
4. Le système sauvegarde la nouvelle photo et affiche un mes-
sage de succès.
Si l’utilisateur connecté possède le rôle Candidat il
peut soit :
Consulter son CV ou sa lettre de motivation LM :
1. L’utilisateur choisit de modifier son CV ou sa LM,
2. Le système affiche une interface dans laquelle l’utilisateur
est demandé à joindre un fichier sous format PDF,
3. L’utilisateur joint le fichier et valide,
4. Le système sauvegarde le nouveau fichier et affiche un mes-
sage de succès,
5. L’utilisateur choisit de supprimer son CV ou sa LM,
4. Le système supprimer le fichier et affiche un message de
succès.
Gérer son profil Candidat :
1. Le candidat choisit de gérer son profil,
2. Il choisit de consulter ses compétences, ses formations, ses
expériences ou encore ses certificats,

29
Chapitre 4. Mise en œuvre du sprint 1 : Gestion des profils

3. Le système affiche une interface contenant le type d’infor-

mations choisi,
4. Il choisit de modifier, supprimer ou encore ajouter de nou-
velles informations,
5. Le système sauvegarde les changements et affiche un mes-
sage de succès.
Scénario d’exception 1. L’utilisateur saisit des informations incorrectes. Le système
affiche un message d’erreur.

4.3 Conception
Dans cette partie, nous illustrons les différents diagrammes de notre sprint. Et finalement,
nous décrivons les différentes maquettes dans le but d’avoir une vision claire sur les futures
interfaces.

4.3.1 Diagramme de séquence « Authentification »

Le diagramme de séquence est un diagramme d’interaction qui montre en détail la façon

dont les opérations sont effectuées. Il est organisé en fonction du temps. La figure 4.2 illustre le
diagramme de séquence de notre première histoire utilisateur qui se résume par l’authentification
et la gestion des rôles.
Cette tâche a été effectuée grâce à l’utilisation de Spring Security et de JWT. Au début,
l’utilisateur saisi son nom utilisateur, qui est unique, et son mot de passe. Ensuite, le système
se charge de retourner à l’utilisateur son rôle, vérifie si le mot de passe saisi est conforme
à celui stocké dans la base de données. Si c’est le cas, un jeton crypté, qui contient le nom
de l’utilisateur et son rôle, est construit. Sinon un message d’erreur est affiché. Un test sera
effectué sur le jeton, à chaque fois que l’utilisateur veille accéder à n’importe quelle page de
notre application, pour vérifier s’il a le droit d’y accéder ou non.

30
Chapitre 4. Mise en œuvre du sprint 1 : Gestion des profils

Figure 4.2: Diagramme de séquence Authentification

4.3.2 Diagramme de séquence « Injection de fichiers »

Chaque utilisateur peut mettre à jour sa photo de profil. Alors que le Candidat, en plus
de la photo, il peut mettre à jour son CV ainsi que sa lettre de motivation. Nous décrivons,
comme illustré par la figure 4.3, le diagramme de séquence d’injection de CV ou d’une LM par le
Candidat. Ce dernier commence par choisir un fichier à partir de son dispositif et le télécharge.
Si tout se passe bien, son profil est mis à jour. Sinon un message d’erreur est affiché.

31
Chapitre 4. Mise en œuvre du sprint 1 : Gestion des profils

Figure 4.3: Diagramme de séquence d’injection de fichiers

4.3.3 Conception graphique des maquettes

Afin d’avoir une idée sur les futures pages de notre solution, nous avons modélisé des ma-
quettes avec l’outil Balsamiq. Ces maquettes ont aussi pour but de se mettre d’accord, dès le
début, avec le client sur les futures interfaces et de bien comprendre les besoins souhaités. En
effet, nous avons préparé trois interfaces graphiques pour bien comprendre le premier Sprint.
La première maquette, commune pour tout type d’utilisateur, contient les informations de base
d’un utilisateur. La figure 4.4 illustre la maquette de profil utilisateur.

Figure 4.4: Profil utilisateur

32
Chapitre 4. Mise en œuvre du sprint 1 : Gestion des profils

Nous passons maintenant au profil Candidat, celui qui contient encore trois interfaces au
plus de celle déjà décrite dans la partie précédente. En effet, ces interfaces ne sont affichées
qu’aux utilisateurs possédant le rôle « Candidat ».
La figure 4.5 décrit la maquette des « Formations Candidat» et à partir de laquelle il peut gérer
ses formations.

Figure 4.5: Formations Candidat

La figure 4.6 illustre la future interface des « Compétences Candidat» et à partir de laquelle
il peut gérer ses compétences tout en indiquant le niveau de chacune.

Figure 4.6: Compétences Candidat

La dernière maquette ressemble à la maquette « Formations Candidat » déjà illustrée. A

partir de laquelle, le candidat peut ajouter, modifier ou encore supprimer ses expériences. Il
doit mentionner pour chaque expérience le titre du poste, la société, la date de début et la date
de fin. Ces dernières interfaces permettent de créer automatiquement un profil pour le candidat

33
Chapitre 4. Mise en œuvre du sprint 1 : Gestion des profils

avec lequel il pourra postuler aux annonces et avoir un score pour chaque candidature. Ce score
est calculé à partir des informations déjà fournies dans les formations, les compétences et les
expériences.

4.4 Diagramme de classes

Le diagramme de classes permet de décrire la structure interne tout en montrant les diffé-
rentes classes, leurs attributs, leurs méthodes, ainsi que les différentes relations structurelle entre
ces classes. La figure 4.7 décrit le diagramme de classes que nous avons utilisé pour développer
le premier sprint.

Figure 4.7: Diagramme de classes du sprint 1

4.5 Réalisation
Dans cette section nous allons présenter à travers un enchaînement de captures d’écran
prises à partir des interfaces de notre solution, des scénarios d’exécution donnant un aperçu
général sur les fonctionnalités de notre système.

4.5.1 Authentification

Au lancement de l’application, l’utilisateur est invité à s’authentifier tout en saisissant ses co-
ordonnées afin d’accéder à sa session. La page d’accueil de l’application n’est accessible qu’après
une saisie correcte du nom d’utilisateur et de son mot de passe. La page d’authentification est
illustrée par la figure 4.8.

34
Chapitre 4. Mise en œuvre du sprint 1 : Gestion des profils

Figure 4.8: Interface d’authentification

4.5.2 Accueil Utilisateur

Après l’authentification avec succès, un test s’effectue sur le rôle de l’utilisateur pour bien
afficher la page d’accueil qui lui correspond. Vu que notre application contient trois rôles dif-
férents, donc il y’aura trois pages différentes à afficher. La figure 4.9 présente la page d’accueil
destinée au rôle Manager. En fait, chaque utilisateur de ce type a le droit de :

• créer des annonces qui seront validées par le Gestionnaire ;

• gérer la liste des candidatures spontanées destinées pour son unité organisationnelle ;

• visualiser en détails la liste des candidatures sélectionnées qui concernent les annonces
qu’il a publiées.

Figure 4.9: Accueil Manager

35
Chapitre 4. Mise en œuvre du sprint 1 : Gestion des profils

Si l’utilisateur connecté possède le rôle « Gestionnaire », il peut :

• créer des annonces qui seront publiées automatiquement ;

• gérer toutes les annonces enregistrées dans la base de données ;

• statuer les annonces créées par les managers ;

• gérer toutes les candidatures effectuées pour des annonces ;

• consulter la liste des candidats sélectionnés ;

La figure 4.10 montre la page d’accueil de profil Gestionnaire.

Figure 4.10: Accueil Gestionnaire

Et finalement, nous exposons par la figure 4.11 la page d’accueil de profil Candidat qui peut
soit accéder à la liste des annonces, postuler spontanément ou voir ses notifications.

Figure 4.11: Accueil Candidat

36
Chapitre 4. Mise en œuvre du sprint 1 : Gestion des profils

4.5.3 Profil Candidat

Comme illustré par la figure 4.12, le candidat peut accéder à son profil dans le but de mettre
à jour ses informations personnelles, son CV et sa lettre de motivation. Il peut aussi gérer ses
formations, ses compétences, ses expériences ainsi que ses certificats.

Figure 4.12: Profil Candidat

Si le candidat choisit de mettre à jour son CV, il accède à l’interface de modification qui
est illustrée par la figure 4.13. Après avoir téléchargé un CV, il peut le visualiser et il finit soit
par valider l’ajout, soit par l’annuler.

Figure 4.13: Injecter CV

37
Chapitre 4. Mise en œuvre du sprint 1 : Gestion des profils

4.6 Tests et validation

Pour clôturer ce sprint, nous avons assisté à une réunion de revue de sprint. Au cours de
laquelle, le Scrum master nous a rappelé l’objectif de ce Sprint tout en décrivant la liste des
histoires utilisateurs. Ensuite, nous avons effectué une démonstration, que nous l’avons déjà
préparé, de la partie réalisée. Et finalement, le Product Owner a intervenu pour évaluer les
résultats du Sprint et nous donner son impression sur la partie développée. Tout en se basant
sur les remarques et les demandes de toute l’équipe, nous avons dégagé les corrections suivantes :

• la suppression du bouton en haut indiquant le rôle de l’utilisateur ;

• l’ajout de la possibilité de téléchargement de certificat pour les candidats ;

• l’utilisation du « local storage » dans la partie frontale pour y stocker des informations
qui concernent l’utilisateur connecté et éviter du coup de refaire une requête http lorsque
nous avons besoin de ces informations encore une fois.

Conclusion
Tout au long de ce chapitre, nous avons décrit les différentes phases par lesquelles notre
sprint a passé par, afin de le réaliser. Nous avons décrit son backlog produit au début, suivi de
la modélisation des diagrammes et des maquettes. Et finalement, nous avons décrit les interfaces
obtenues ainsi que les remarques dégagées lors de la revue de sprint. Le chapitre suivant a pour
objectif de décrire le sprint « Gestion des annonces ».

38
 Chapitre 5

Mise en œuvre du sprint 2 : Gestion

des annonces

Introduction
Tout au long de ce chapitre, nous décrivons les différentes étapes par lesquelles nous nous
sommes passés pour réaliser ce sprint. Nous entamons ce chapitre par une présentation du
Backlog produit. Ensuite, nous détaillons la partie conception par la présentation de quelques
diagrammes. Finalement, nous clôturons par décrire quelques interfaces de notre application et
la partie test et validation.

5.1 Backlog du sprint 2

Le tableau 5.1 décrit le Backlog produit de notre deuxième sprint tout en détaillant les
tâches effectuées pour le réaliser.

Tableau 5.1: Backlog du produit

ID Tâches Estimation
(h/h)
GA1 Analyse : préparation de la maquette d’authentification. 2
Développement de la partie Backend : modélisation du 8
processus « Validation des annonces » à l’aide du plugin «
Activiti Designer ». Création du Web service de création d’an-
nonce et de lancement du processus.

39
Chapitre 5. Mise en œuvre du sprint 2 : Gestion des annonces

Développement de la partie Frontend : préparation du 6

service de création d’annonce qui, communiquant avec le ser-
vice déjà créé en backend, débute le processus.
Design : développement de l’interface de création d’annonce. 8
Test : tests fonctionnels sur le processus et sur son démarrage. 3
Aussi, nous avons effectué des tests qui concernent l’ajout
d’une annonce dans la base de données dont l’état est « En
Attente ».
GA2 Analyse : modélisation de la maquette « Consulter et filtrer 2
GA7 les annonces ».
GA8

Développement de la partie Backend :création des 6

contrôleurs qui permettent de récupérer la liste des annonces
publiées (avec l’état « Validé ») et de filtrer les annonces selon
le choix de l’utilisateur.
Développement de la partie Frontend : création des ser- 6
vices pour la consommation des données retournées de la par-
tie backend. L’ajout des méthodes de filtrage.
Design : création de l’interface de consultation et de filtrage 5
des annonces.
GA3 Analyse : préparation du contenu des mails et des notifica- 1/2
GA5 tions..

Développement de la partie Backend : l’ajout de la confi- 6

guration du Websocket pour la gestion des notifications en
temps réel. Aussi, nous avons créé le service d’envoi de mails
et nous l’avons lié avec les deux tâches services de notre pro-
cessus BPMN.
Développement de la partie Frontend : création du ser- 4
vice Websocket qui reste en écoute pour la récupération et
l’affichage des notifications reçues.

40
Chapitre 5. Mise en œuvre du sprint 2 : Gestion des annonces

Design : création d’un composant qui contient toutes les no- 3

tifications. L’ajout d’une alerte qui contient le contenu d’une
notification reçue en temps réel.
GA4 Analyse : la réutilisation de la maquette de création d’an- 0
nonce destinée au Manager.
Développement de la partie Backend : création du ser- 2
vice de l’ajout d’une annonce dans la base de données avec
l’état « Validée ».
Développement de la partie Frontend : la préparation 1
du service qui permet l’ajout d’une annonce.
Design : création des composants réutilisation de l’interface 1
de création d’annonce destinée au Manager et son adaptation
pour ce besoin.

GA6 Analyse : préparation des maquettes de consultation de 1

toutes les annonces en attente et de chacune en détails.
Développement de la partie Backend : modification ef- 5
fectuée au niveau du processus BPMN pour manipuler la dé-
cision du Gestionnaire et l’ajout d’une catégorie pour la ré-
cupération des tâches en cours. L’implémentation du service
qui retourne toutes les annonces dont l’état est « en attente
».
Développement de la partie Frontend : l’ajout des fonc- 4
tions qui permettent l’affichage d’une annonce en détails, la
validation et le refus.
Design : la préparation des interfaces de gestion des annonces 5
en attente.

GA9 Analyse : modélisation des maquettes de consultation des 1

annonces publiées et enregistrées.
Développement de la partie Backend : l’ajout de ser- 3
vices qui permettent la récupération et l’enregistrement des
annonces.

41
Chapitre 5. Mise en œuvre du sprint 2 : Gestion des annonces

Développement de la partie Frontend : l’implémentation 3

du service de récupération et d’enregistrement des annonces.
Design : développement de deux interfaces pour la visualisa- 5
tion des annonces publiées et enregistrées.

5.2 Analyse
5.2.1 Raffinement de cas d’utilisation « Gérer Annonce »

La figure 5.1 illustre le diagramme de cas d’utilisation « Gérer Annonce » d’une manière
détaillée :

Figure 5.1: Raffinement du CU « Gérer annonces »

42
Chapitre 5. Mise en œuvre du sprint 2 : Gestion des annonces

Nous interprétons le cas d’utilisation « Gérer annonce » par le tableau 5.2.

Tableau 5.2: Description textuelle du cas d’utilisation « Gérer annonce »

Cas d’utilisation Gérer Annonce

Objectif La publication et la gestion des annonces.
Acteurs Gestionnaire
Pré condition L’utilisateur est authentifié.
L’utilisateur possède le rôle Gestionnaire.
Post condition Création d’annonce effectuée avec succès.
Changement de l’état des annonces validées ou refusées.
Scénario nominal Créer Annonce :
1. Le gestionnaire accède à l’interface d’ajout d’une an-
nonce,
2. Le système affiche le formulaire d’ajout,
3. Le gestionnaire remplit le formulaire,
4. Le système vérifie si le gestionnaire a saisi les
bonnes informations et affiche un message de succès.
Statuer Annonce :
1. Le gestionnaire accède à l’interface des annonces en
attente,
2. Le système affiche la liste des annonces créées par les
managers,
3. Le gestionnaire choisit d’accepter l’annonce,
4. Le système sauvegarde l’annonce avec l’état « Validé
» et affiche un message de succès.
5. Sinon, le gestionnaire choisit de refuser l’annonce,
6. Le système affiche le formulaire des raisons de refus,
7. Le gestionnaire mentionne les raisons de refus,
8. Le système sauvegarde l’annonce avec l’état « Refusé
» et affiche un message de succès.
Scénario d’exception 1. Le gestionnaire n’a pas saisi les bonnes informations,
2. Le système renvoi un message d’erreur.

43
Chapitre 5. Mise en œuvre du sprint 2 : Gestion des annonces

5.2.2 Raffinement de cas d’utilisation « Consulter Annonce »

La figure 5.2 illustre le diagramme de cas d’utilisation « Consulter Annonce » d’une manière
détaillée :

Figure 5.2: Raffinement du CU « Consulter annonces »

Nous interprétons le cas d’utilisation « Gérer annonce » par le tableau 5.3.

Tableau 5.3: Description textuelle du cas d’utilisation « Consulter annonce »

Cas d’utilisation Consulter Annonce

Objectif La publication et la gestion des annonces.
Acteurs Utilisateur
Pré condition L’utilisateur est authentifié.
La table des annonces n’est pas vide.
Post condition Liste affichée avec succès.
Filtres effectués avec succès.

44
Chapitre 5. Mise en œuvre du sprint 2 : Gestion des annonces

Scénario nominal Créer Annonce :

1. L’utilisateur accède à la page des annonces,
2. Le système affiche la liste des annonces dont l’état est
« Validé »,
3. L’utilisateur choisit de filtrer la liste retournée,
4. Il peut effectuer ce filtre avec les critères qu’il choisit,
5. Le système affiche seulement la liste avec les critères
choisis,
6. Si l’utilisateur possède le rôle Candidat, il a le droit
de marquer les annonces comme enregistrées,
4. Le système sauvegarde que l’annonce a été ajoutée au
panier du candidat connecté.
Scénario d’exception 1. La table annonce est vide, le système affiche un mes-
sage indiquant que la base est vide,

5.3 Conception
Nous décrivons, dans cette section du chapitre, la modélisation des différents diagrammes
sur lesquels nous nous sommes basés pour bien comprendre le fonctionnement du processus «
Validation des annonces » qui présente la tâche primordiale de ce sprint.

5.3.1 Processus BPMN 2.0 du « Processus de validation des an-

nonces ».

Le processus de « Validation des annonces », modélisé en BMPN 2.0 avec le plugin « Designer
» d’eclipse, est décrit par la figure 5.3. En effet, ce processus contient deux tâches utilisateurs
et une tâche service qui sont :

• créer annonce : c’est la première tâche de notre processus, effectuée par le Manager,
elle présente le point d’entrée de notre processus. A partir de laquelle, le Manager remplit
un formulaire de création d’annonce et une notification sera envoyée automatiquement au
Gestionnaire, en temps réel, pour lui informer qu’une nouvelle annonce est en attente ;

45
Chapitre 5. Mise en œuvre du sprint 2 : Gestion des annonces

• traiter annonce : cette tâche sera faite par le Gestionnaire. Il peut soit valider l’annonce
du Manager, qui sera publiée automatiquement, soit la refuser. Une notification sera
envoyée automatiquement au Manager en question pour lui informer de l’état de son
annonce ;

• envoyer mail d’acceptation ou de refus : sont présentés par deux tâches services qui
nous permettent d’envoyer automatiquement, selon la décision du Gestionnaire, un mail
lui indiquant l’acceptation ou le refus ainsi que les raisons pour lesquelles son annonce a
été refusée.

Figure 5.3: Processus de validation des annonces

5.3.2 Diagrammes de séquence du « Statuer les annonces »

Comme décrit dans la partie précédente, le manager crée une demande de publication d’an-
nonce et c’est au gestionnaire de la valider ou non. Pour statuer les annonces, le gestionnaire
accède à la page de validation pour consulter la liste des annonces dont l’état est « en attente
». La figure 5.4 schématise l’enchaînement de la consultation.
Après avoir consulté toutes les annonces en attente, le gestionnaire peut valider ou refuser
les annonces. S’il accepte la demande, l’annonce sera enregistrée la base avec l’état « Validé ».
S’il refuse, il doit mentionner les raisons de refus et l’annonce sera enregistrée dans la base avec
l’état « Refusé ». Une notification et un mail seront envoyés automatiquement au manager en
question pour lui informer de l’état de son annonce.
La figure 5.5 illustre le diagramme de séquence « Statuer annonce ».

46
Chapitre 5. Mise en œuvre du sprint 2 : Gestion des annonces

Figure 5.4: Diagramme de séquence « Consulter annonces en attente »

Figure 5.5: Diagramme de séquence « Statuer annonce »

47
Chapitre 5. Mise en œuvre du sprint 2 : Gestion des annonces

5.3.3 Conception graphique des maquettes

Après avoir effectué des recherches concernant les champs nécessaires d’une annonce, nous
avons établi la maquette de création d’annonce qui est la même pour les deux rôles : Manager
et Gestionnaire.
La figure 5.6 montre la maquette « Création annonce ».

Figure 5.6: Maquette « Création Annonce »

Nous passons maintenant à la maquette de validation des annonces, à partir de laquelle

le Gestionnaire consulte les annonces en détails pour décider de les valider ou non. Avant de
refuser une annonce, il est obligé de saisir les raisons de refus.
La figure 5.7 présente la maquette de validation ou non des annonces.

48
Chapitre 5. Mise en œuvre du sprint 2 : Gestion des annonces

Figure 5.7: Maquette « Statuer les annonces »

La maquette décrite par la figure 5.8 présente l’interface de consultation des annonces qui
est commune pour tout type d’utilisateur sauf le bouton radio en haut, il est seulement destiné
aux Candidats. Ce bouton permet, selon le choix du Candidat, de trier les annonces selon la
correspondance avec son profil. Comme décrit dans la figure, l’Utilisateur de l’application peut
effectuer un filtre sur les annonces tout en choisissant des critères qui concernent les expériences,
les formations ou encore les compétences. Il peut aussi effectuer des recherches en saisissant des
mots clés.

Figure 5.8: Maquette « Consulter et filtrer Annonce »

49
Chapitre 5. Mise en œuvre du sprint 2 : Gestion des annonces

5.4 Diagramme de classes

La figure 5.9 décrit le diagramme de classes que nous avons utilisé pour développer la
deuxième sprint.

Figure 5.9: Diagramme de classes du sprint 2

5.5 Réalisation
Nous allons présenter, dans cette partie, à travers un enchaînement de captures d’écran des
scénarios d’exécution sur des fonctionnalités choisies de notre sprint.

5.5.1 Créer annonce

La figure 5.10 présente l’interface « Créer Annonce » qui est commune pour les deux rôles
Gestionnaire et Manager. La seule différence entre les deux, du point de vue fonctionnel, est le
fait que l’annonce du Gestionnaire sera publiée automatiquement, alors que celle du Manager
doit être validée avant sa publication. A partir de cette interface, l’utilisateur remplit le formu-
laire et il est demandé, pour certains champs, de fournir les priorités qui nous seront utiles lors
du calcul de score des candidatures.

50
Chapitre 5. Mise en œuvre du sprint 2 : Gestion des annonces

Figure 5.10: Interface « Créer annonce »

Lors de la création d’une nouvelle annonce par un Manager, le Gestionnaire reçoit, en temps
réel, une notification, comme décrite par la figure 5.11, lui indiquant qu’une nouvelle annonce
est en attente.

Figure 5.11: Notification gestionnaire

5.5.2 Statuer annonce

Après avoir lu les notifications, le Gestionnaire accède à la page de gestion des annonces
pour les statuer. A partir de cette interface, il peut voir en détails chacune à part. Pour valider
l’annonce, le Gestionnaire n’a qu’à choisir le bouton Accepter, alors que pour la refuser, il lui
faut la saisie des raisons pour lesquelles cette annonce a été refusée.
La figure 5.12 illustre l’interface de « Voir Annonce en Détail » et celle qui permet le refus
d’annonce.

51
Chapitre 5. Mise en œuvre du sprint 2 : Gestion des annonces

Figure 5.12: Consulter / refuser annonce

Après avoir décidé la validation ou non de l’annonce par le Gestionnaire, un mail et une
notification, comme décrits dans la figure 5.13, seront communiqués automatiquement au Ma-
nager en question pour lui informer de l’état de sa demande de publication d’annonce et des
raisons de refus en cas de rejet.

Figure 5.13: Mail et notification du manager

5.5.3 Consulter et filtrer annonce

Tout type d’utilisateur peut consulter et effectuer des filtres sur la liste des annonces pu-
bliées.
La figure 5.14 présente la page de consultation des annonces pour le rôle Candidat. Ce qui
la différencie par rapport aux deux autres, c’est le fait que le Candidat peut enregistrer des
annonces, celles qui sont marquées par des étoiles sur la figure.

52
Chapitre 5. Mise en œuvre du sprint 2 : Gestion des annonces

Figure 5.14: Interface « Consulter et filtrer annonces »

5.6 Test et validation

Après avoir développé les interfaces nécessaires ainsi que leurs implémentations, nous avons
eu comme d’habitude une réunion de revue de sprint. Comme prévu, le Scrum master a rappelé
l’objectif de ce sprint et le Product Owner a évalué les résultats du sprint. Les remarques que
nous avons dégagées après cette réunion sont les suivantes :

• l’ajout des priorités qui concernent les champs de l’annonce afin de calculer les scores des
candidatures ;

• la possibilité d’effectuer des recherches par mot clé.

Conclusion
Dans ce chapitre, nous nous sommes intéressés à la réalisation des fonctionnalités de notre
sprint. Nous avons décrit les différentes étapes de cette réalisation ainsi que les interfaces de
notre solution. Le chapitre suivant sera consacré pour expliquer en détails le sprint trois qui est
destiné pour la « Gestion des candidatures et postulation ».

53
 Chapitre 6

Mise en œuvre du sprint 3 : Gestion

des candidatures

Introduction
Dans ce chapitre, nous présentons la réalisation de notre troisième sprint : Gestion des
candidatures.
Dans un premier lieu, nous décrivons les tâches de chaque histoire utilisateur.
Dans un deuxième lieu, nous schématisons l’enchaînement de ce sprint grâce aux diagrammes
de conception.
Finalement, nous décrivons cet enchaînement avec la présentation des interfaces de la solution.

6.1 Backlog du sprint 3

Le tableau 6.1 décrit le Backlog produit de notre troisième sprint tout en détaillant les
tâches effectuées pour le réaliser.
Nous interprétons le cas d’utilisation « Gestion des candidatures » par le tableau 6.1.

Tableau 6.1: Backlog du produit

ID Tâches Estimation
(h/h)
GC1 Analyse : modification de la maquette de consultation d’une 1
annonce en détails.

54
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

Développement de la partie Backend : modélisation du 7

processus « Gestion des candidatures » à l’aide du plugin
« Activiti Designer ». Création d’une méthode qui permet
de calculer le score d’une candidature selon les priorités de
l’annonce dans le service de matching.
Développement de la partie Frontend : implémentation 2
du service d’envoi de candidature et de lancement du proces-
sus.
Design : modification de l’interface de consultation d’an- 3
nonce en détail et l’ajout de nouveaux composants tels que
les alertes et les barres de progression.
GC2 Analyse : modélisation de la maquette « Postuler spontané- 3
ment ».
Développement de la partie Backend : modélisation du 6
processus, utilisation du StorageService pour joindre les CVs
et les LMs. Création d’une méthode qui permet de calculer le
score du candidat dans le service de matching.
Développement de la partie Frontend : création d’un 6
service qui a pour but de gérer l’upload des CVs et des LMs,
et de lancer le processus.
Design : développement de l’interface d’envoi de candidature 4
spontanée.
GC3 Analyse : modélisation de la maquette de consultation de 1
l’historique des candidatures.
Développement de la partie Backend : création du 2
contrôleur d’extraction des candidatures effectuées par un
candidat donné.
Développement de la partie Frontend : implémentation 2
d’un service permettant l’extraction, l’affichage et le filtrage
des candidatures effectuées.
Design : création d’un composant qui affiche les candidatures 3
selon les critères de filtrage.

55
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

GC6 Analyse : modélisation de la maquette de consultation des 1

GC8 candidatures.

Développement de la partie Backend : l’implémentation 3

des services liés avec le processus BPMN qui permet d’extraire
les candidatures en attente et de les valider ou non.
Développement de la partie Frontend : création des ser- 7
vices d’extraction des candidatures et de tri selon les scores.
Aussi, le calcul des rangs des candidats.
Design : développement d’une interface pour l’affichage des 4
candidatures.

6.2 Analyse
6.2.1 Raffinement de cas d’utilisation « Postuler Spontanément »

La figure 6.1 illustre le diagramme de cas d’utilisation « Postuler Spontanément » d’une

manière détaillée :
Nous interprétons le cas d’utilisation « Postuler Spontanément » par le tableau 6.2.

56
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

Figure 6.1: Raffinement du CU « Postuler Spontanément »

Tableau 6.2: Description textuelle du cas d’utilisation « Postuler spontanément »

Cas d’utilisation Postuler spontanément

Objectif Envoyer une candidature spontanée.
Acteurs Candidat
Pré condition L’utilisateur est authentifié.
L’utilisateur possède le rôle Candidat.
Post condition Candidature spontanée envoyée avec succès.
Scénario nominal 1. Le candidat accède à la page Postuler spontanément,
2. Il choisit l’unité organisationnelle, la localisation, le
poste et le secteur d’activité,
3. Il joint son CV et sa LM et valide sa candidature,
4. Le système vérifie si le candidat n’a pas effectué une
candidature spontanée avec les mêmes critères et affiche
un message de succès.

57
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

Scénario d’exception 1. Le candidat a déjà effectué une candidature spontanée

avec ces critères,
2. Le système renvoie un message d’erreur.

6.3 Conception
Cette section du chapitre est consacrée à présenter les différents diagrammes du sprint
« Gestion des candidature ». Nous l’entamons par la présentation du processus « Postuler
Spontanément ».

6.3.1 Modélisation du processus « Postuler spontanément »

La figure 6.2 schématise les étapes d’envoi d’une candidature spontanée. En effet, le can-
didat commence par remplir un formulaire qui sera testé pour vérifier s’il a déjà effectué une
candidature avec les mêmes critères ou non. Si la candidature existe déjà, un message d’erreur
sera affiché et le processus est terminé. Dans le cas inverse, un score sera calculé, grâce au ser-
vice de matching, et affecté à la candidature. Ensuite, une notification sera envoyée au manager
de l’unité organisationnelle que le candidat a choisie pour valider ou non sa demande. Enfin,
un mail et une notification seront envoyés au candidat en question.

Figure 6.2: Processus « Postuler spontanément »

58
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

6.3.2 Diagrammes de séquence du processus « Postuler pour une

annonce »

Après avoir consulté la liste des annonces, le candidat choisit une pour effectuer sa candida-
ture. Tout le processus « Postuler pour une annonce », dès l’envoi d’une candidature jusqu’à sa
validation ou son refus, est implémenté aussi avec Activiti Workflow. Alors, pour commencer,
le candidat choisit le bouton « Postuler » à partir de l’interface « Consulter annonce en détail
». Les données sont récupérées grâce à une requête http de type Post et qui seront testées pour
bien vérifier que le candidat n’a pas effectué une candidature pour cette annonce. S’il a déjà
effectué une candidature, un message d’erreur est affiché. Dans le cas inverse, un score sera cal-
culé avec le service de matching. Chaque candidature possède son propre score qui est calculé à
partir des priorités fournies dans l’annonce. En effet, ce score se compose de trois autres à savoir
le score des compétences, des expériences et celui des formations. Une fois le score est affecté,
la candidature sera stockée dans la base avec l’état « en cours » et nous appelons la méthode «
startProcessInstanceByKey ». Cette dernière fait appel au « RuntimeService » d’Activiti pour
commencer le processus « candidatureProcess ».
Le processus reste bloqué jusqu’à la prise de décision du gestionnaire.
La figure 6.3 illustre le diagramme de séquence « Postuler pour une annonce ».

59
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

Figure 6.3: Diagramme de séquence « Postuler pour une annonce »

Après la phase d’envoi des candidatures, le gestionnaire accède à la page de consultation des
candidatures pour les visualiser en détails. En effet, dès qu’il accède à cette page une requête http
de type Get est exécutée pour extraire les données. Cette dernière fait appel au TaskService
d’Activiti pour récupérer toutes les tâches dont la catégorie est « enAttenteCandidature »
où toutes les candidatures sont stockées. Enfin, un simple parcours de la liste retournée afin
d’extraire toutes les candidatures. La figure 6.4 présente pour récupérer toutes les candidatures.

60
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

Figure 6.4: Diagramme de séquence « Consulter liste des candidatures »

Une fois la liste est retournée, elle sera triée selon les scores des candidatures tout en calculant
le rang de chacune. Cela est assuré grâce à l’utilisation d’un service créé dans la partie frontale.

6.4 Conception graphique des maquettes

Dans la partie précédente, nous avons modélisé les différentes fonctionnalités du sprint. C’est
ce qui nous a permis d’avoir une vision claire sur les futures interfaces. Dans cette section, nous
modélisons les différentes maquettes de ce sprint. Le candidat peut postuler sur une annonce
précise, lorsqu’il la consulte en détail. Il peut aussi effectuer une candidature spontanée tout en
choisissant la localisation, l’unité organisationnelle ou encore le secteur d’activité. Il doit aussi
joindre son CV et sa LM. La figure 6.5 présente la maquette « Postuler spontanément ».

61
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

Figure 6.5: Maquette « Postuler Spontanément »

Lorsqu’un candidat postule spontanément ou pour répondre à une offre publiée, un score sera
automatiquement affecté à sa candidature. Ce score nous sera utile pour trier les candidatures.
Lorsque le gestionnaire accède à la page de validation des annonces, il peut visualiser une liste
triée selon les scores des candidatures. A partir de cette interface, il peut valider ou refuser les
candidatures.
La figure 6.6 décrit la future interface, destinée au gestionnaire pour gérer les candidatures sur
les annonces.

Figure 6.6: Maquette « Statuer les candidatures sur les annonces »

62
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

Le manager est la personne responsable de la gestion des candidatures spontanées destinées

à son unité organisationnelle. Lui aussi accède à une interface qui ressemble à celle décrite
là-dessus pour statuer ce type de candidature.

6.5 Diagramme de classes

La figure 6.7 décrit le diagramme de classes que nous avons utilisé pour développer la
troisième sprint.

Figure 6.7: Diagramme de classes du sprint 3

63
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

6.6 Réalisation
Cette section est consacrée à présenter, grâce à un enchaînement de captures d’écran, les
deux scénarios de base de notre sprint qui sont :

• envoyer une candidature spontanée ;

• postuler pour une annonce précise ;

Et finalement, nous donnons une brève description sur la page de consultation des candidatures
effectuées destinées aux candidats.

6.6.1 L’envoi d’une candidature spontanée

Le candidat accède à la page d’envoi de candidature spontanée, comme illustrée par la figure
6.8. Pour postuler, il doit choisir la localisation, le secteur d’activité, l’unité organisationnelle
et le poste souhaité. Pour chaque candidature spontanée, il doit joindre son CV ainsi que sa
LM. Et finalement, il peut confirmer ou non sa disponibilité à la mobilité.

Figure 6.8: Interface « Postuler spontanément »

Si la candidature est bien passée, le candidat reçoit une notification, comme décrit dans la
figure 6.9.

64
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

Figure 6.9: Notification du candidature spontanée

Après avoir reçu la notification, le manger accède à la page de gestion des candidatures
spontanées. Dans laquelle la liste des candidatures est triée selon le score. Alors, il choisit une
pour visualiser toutes les informations du candidat ainsi que son rang.
La figure 6.10 présente l’interface de consultation d’une candidature spontanée en détail.

Figure 6.10: Consulter et statuer candidature spontanée

65
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

Après le parcours des informations du candidat en détail, le manger valide ou refuse la

candidature, alors une notification et un mail seront envoyés automatiquement au candidat en
question pour lui informer l’état de sa candidature.
La figure 6.11 illustre le mail et la notification envoyés au candidat dans le cas d’acceptation.

Figure 6.11: Notifier candidat

6.6.2 L’envoi d’une candidature sur annonce

Pour postuler sur une annonce, le candidat consulte la liste des annonces publiées. Il choi-
sit une pour visualiser toutes ses informations à savoir son titre, son unité organisationnelle,
l’expérience et les compétences requises, etc. La figure 6.12 présente l’interface de consultation
d’une annonce en détail.

Figure 6.12: Consulter annonce en détail

66
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

Si le candidat a déjà postulé pour une annonce précise un message d’erreur lui sera envoyé.
La figure 6.13 montre le message d’erreur qui sera affiché.

Figure 6.13: Message d’erreur

Les candidatures sur les annonces seront gérées par le gestionnaire des ressources humaines.
Il accède à la page de gestion des candidatures, où une liste contenant toutes les candidatures
sur annonce est triée selon un score, qui est calculé tout en se basant sur les priorités choisies
dans l’annonce. Il a la possibilité de filtrer les candidatures par annonce comme illustré par la
figure 6.14.

Figure 6.14: Consulter les candidatures sur annonce

Alors, pour statuer une candidature le gestionnaire consulte en détails les informations du
candidat comme décrit dans la section de gestion des candidatures spontanées. Après avoir
parcouru tous les détails des candidats, il peut soit valider leurs candidatures, soit les refuser.

67
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

La figure 6.15 présente les deux messages affichés après avoir décidé l’état des candidatures.

Figure 6.15: Type de messages

Lors de la décision du gestionnaire à propos de la candidature effectuée, le candidat en

question reçoit une notification et un mail, lui indiquant l’état de sa candidature sur annonce.

6.6.3 Consulter mes candidatures

Après avoir effectué des candidatures, quel que soit leurs types, le candidat peut consulter
l’historique de ses candidatures effectuées.
La figure 6.16 présente la page contenant cet historique.

Figure 6.16: Consulter candidatures effectuées

Comme décrit par la figure, le candidat peut effectuer des filtres sur ses candidatures tout en
se basant soit sur la date, soit sur les formations, les expériences ou encore sur les technologies.
Il peut aussi voir la date de postulation et l’état de la candidature. Les candidatures, dont l’état
est « En-Cours » ne sont pas encore traitées.

68
Chapitre 6. Mise en œuvre du sprint 3 : Gestion des candidatures

6.6.4 Test et validation

Après avoir développé les interfaces nécessaires ainsi que leurs implémentations, nous avons
eu comme d’habitude une réunion de revue de sprint. Comme prévu, le Scrum master a rappelé
l’objectif de ce sprint et le Product Owner a évalué les résultats du sprint. Les remarques que
nous avons dégagées après cette réunion sont les suivantes :

• l’ajout des priorités qui concernent les champs de l’annonce afin de calculer les scores des
candidatures ;

• la possibilité d’effectuer des recherches par mot clé.

Conclusion
Dans ce chapitre, nous nous sommes intéressés à la réalisation des fonctionnalités de notre
sprint. Nous avons décrit les différentes étapes de cette réalisation ainsi que les interfaces de
notre solution.

69
Conclusion générale et perspectives

Tout au long de notre projet, nous avons passé par différentes étapes pour sa création. Dans
un premier lieu, nous avons commencé par une présentation du cadre du projet. Ensuite, nous
avons décrit les besoins fonctionnels et non fonctionnels de notre système. Après, nous avons
établi les différents diagrammes qui expliquent d’une manière raffinée le fonctionnement du
projet. Et finalement, nous avons procédé aux choix techniques du langage de développement
ainsi que les outils utilisés.

Ce présent projet a pour objectif la création et l’intégration de plusieurs workflows dans

le logiciel de gestion scolaire et universitaire en ligne « SquareSchools ». Les workflows crées
permettent de faciliter certaines tâches et de les rendre automatiques telles que la gestion des
demandes ou encore l’envoi des emails de relance.

Malgré sa courte durée, ce stage, nous a donnée l’occasion d’avoir une idée sur la vie
professionnelle en intégrant l’équipe de One Square. Nous avons aussi appris de nouveaux
concepts et de nouvelles technologies. Ce stage a été une bonne opportunité pour développer
nos compétences en développement Web et d’apprendre à créer et intégrer les workflows.

Certes, notre projet peut supporter plusieurs perspectives afin de faciliter d’autres tâches
pour le logiciel en ligne « SquareSchools ». L’une des perspectives prévue est le fait de créer un
worfklow qui permet d’envoyer non seulement des emails mais aussi des SMS aux parents, aux
enseignants ou encore aux étudiants. Une autre proposition est de créer un workflow qui envoi
automatiquement des emails contenant le support du cours aux étudiants.

70
Bibliographie

[1] Sopra Steria. Les solutions ressources humaines de SOPRA STERIA. Disponible sur :
<https ://[Link]/>. Consulté le 21 Avril 2018.

[2] Sopra Steria. Ressources Humaines. Disponible sur : <

https ://[Link]/fr/nos-activites/software/ressources-humaines>. Consulté
le 21 Avril 2018.

[3] Thierry PIGOT. Scrum en moins de 10 minutes. Disponible sur : <https ://[Link]-
[Link]/scrum-en-moins-de-10-minutes/>. Consulté le 22 Avril 2018.

[4] Florent LOTHON. Guide de démarrage de Scrum – l’Agiliste. Disponible sur : <
https ://[Link]/guide-de-demarrage-scrum/>. Consulté le 22 Avril 2018.

[5] Abdelkerim Douiri. Etude et développement d’une application de messagerie électronique.

Disponible sur :<http ://[Link]/06/10/3605/>, 2010. Page consultée le
22 Avril 2018

[6] Carina Roels. Débutez l’analyse logicielle avec UML. Disponible

sur :<https ://[Link]/courses/debutez-l-analyse-logicielle-avec-uml/uml-c-
est-quoi >,04 Septembre 2017 . Page consultée le 31 octobre 2017.

[7] IBM. Définition des cas d’utilisation. Disponible sur :<https ://[Link]/support
/knowledgecenter/fr/SSWMEQ_2.0.0/[Link]/topics/t_define_ucs.html>.
Page consultée le 31 octobre 2017.

[8] Edrwa Soft. UML cas d’utilisation. Disponible sur :<https ://[Link]/fr/uml-
[Link]>. Page consultée le 31 octobre 2017.

[9] DocWiki. Définition des diagrammes d’activités UML 2.0. Disponible sur :<http ://doc-
[Link]/RADStudio/Tokyo/fr>, 14 Novembre 2013. Page consultée le 01
novembre 2017.

[10] DocWiki. Définition des diagrammes de séquence UML 1.5 . Disponible sur :<http ://doc-
[Link]/RADStudio/Tokyo/fr>, 14 Novembre 2013. Page consultée le 02
novembre 2017.

[11] Jean-Michel Doudoux. Développons en JAVA. Disponible

sur :<https ://[Link]/java/dej/[Link]>, 2016. Page consultée
le 05 novembre 2017.

71
Bibliographie

[13] Castel Dennis,Sarzeaud Floriane,Takahashi Atsushi. Disponible sur :<http ://gardeux-

[Link]/Documents/ProjetJEE/TCS_Jaxb_Wicket/[Link]>, 2013. Page
consultée le 05 novembre 2017.

[14] CastelSTARXPERT. Activiti vs Bonita. Disponible sur :<http ://[Link]/PDF

/Activiti_vs_Bonita.pdf>, 2011. Page consultée le 05 novembre 2017.

[15] Cyrille Chausson. Avec Activiti, Alfresco glisse progressivement vers la licence Apache »,
LeMAgIT, 18 mai [Link] consultée le 06 ovembre 2017.

[17] [Link]. Présentation de PostgreSQl. Disponible sur :< http ://[Link]-

[Link]/polys/reseaux-DG/[Link]>. Page consultée le 05 novembre 2017.

[17] [Link]. Cours n10 : Diagramme de paquetages. Disponible sur :< http ://remy-
[Link]/UML/Cours/[Link]>. Page consultée le 05 novembre 2017.
<Ref : http ://[Link]/UML/Cours/[Link] consulté le 20/05>

72
 PÌl›
™mt§ .One Square T·JAn˜ T•rK˜A £dyfn œ ©@˜ ¤ ¨fyO˜ Prt˜ CAV ¨ r§rqt˜ @¡ t•
–˜Ð Ÿ› |rŒ˜ ¤ . SquareSchools ›Ažr ¨ Workflow › ¤ “l¤ œymO ¨ Š¤rKm˜ @¡ ‘d¡
¤ Eclipse IDE  dtFA Spring CAV  ™m`˜ @¡ r§wW œ .Ty¶Aql Ahl`¤ Ahm˜ {` ™yhs w¡
Designer dˆAsm˜ ›Ažrb˜ ™Sf Workflow œymO œ d’¤ .AžAyb˜ dˆ w’ ­C  A\n• PostgreSQL
.Eclipse  b›
Designer ,PostgreSQL ,Eclipse ,Spring ,Workflow : y Af› Aml•

Résumé
Ce travail a été réalisé dans le cadre du projet de fin d’études afin d’obtenir le
diplôme de licence appliquée en informatique, il a été réalisé au sein de l’entreprise
Sopra HR Software, nous avons essayé d’être fidèle aux exigences citées dans le
cahier des charges. L’objectif de ce travail est de trouver une solution qui permet
d’améliorer les façons d’exécution teste automatiques, pour se faire nous avons mis
en place une solution d’orchestration et d’industrialisation d’exécution des tests
automatiques.
Mots clés : Workflow, Spring, Eclipse, PostgreSQL, Designer.

Abstract
The present report was drafted in the context of the summer internship. This
project was made within the start-up One Square. The objective of our work con-
sists in conceiving, creating and integrating workflows into an on-line software «
SquareSchools » in order to facilitate certain tasks and make them automatic.
Our work was developed with the Spring framework by using Eclipse as IDE and
PostgreSQL as DBMS. Workflows were modelled by using to the plugin designer
installed under Eclipse.
Keywords : Workflow, Spring, Eclipse, PostgreSQL, Designer.

[Link]/
: w˜ 72 277 091 : Ah˜ 8090 :W˜ ¤ “§rV Áibi˜´M
Route Oued Khatf, Kélibia 8090, Nabeul Tél: 72 277 090 Site:[Link]/