Diplôme en :
SCIENCES DE L’INFORMATIQUE
République Tunisienne
Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
Option :
Génie Logiciel et Système d’Information
Université de Sfax
Faculté des Sciences de Sfax
N° d’ordre : LSI-8
MEMOIRE
présenté à
La Faculté des Sciences de Sfax
en vue de l’obtention du
DIPLOME DE LICENCE EN SCIENCES DE L’INFORMATIQUE
Option :
Génie Logiciel et Système d’Information
par
Raddaoui Yassine
Application Web pour la Gestion de Recrutement
Soutenu le 15/06/2022, devant la commission d’examen :
M. Loukil Noureddine
Mme. Khamkhem Sana
M. Ali Salem
M. Hadhri Abd kader
Président
Rapporteur
Encadrant
Responsable Entreprise
DEDICATION
A travers ce modeste travail, je tiens à exprimer ma plus profonde reconnaissance
À Mes très chers parents, pour tous leurs sacrifices, leur amour, leur tendresse, leur soutien et
leurs prières tout au long de mes études.
À Mes chères sœurs, pour leurs grand amour et leurs soutiens qu’elle trouve ici l’expression
de ma haute gratitude.
À Tous mes professeurs pour leur générosité et leur soutien.
À Mes amis pour leur support moral.
À vous tous,
Je dédie ce travail.
Raddaoui YASSINE
FS-SFAX
Page i
REMERCIEMENT
C’est avec un grand plaisir que je réserve ces quelques lignes pour adresser mes sincères
remerciements aux personnes qui m’ont aidé durant tout le déroulement du stage.
Nous remercions d’abord mon encadrant de ce projet, Mr Ali SALEM pour ses recommandations
judicieuses, sa patience, ses conseils académiques et ses disponibilités qui ont été un atout pour
moi.
Je tiens à remercier également l’ensemble du personnel de la Compagnie de phosphate de Gafsa
pour leur accueil sympathique et leur coopération professionnel tout au long de mon stage, et
en particulier, nous remercions Mr Abd kader Hadhri pour le suivi, les remarques constructifs
et la qualité de l’encadrement dont il ma a fait bénéficier.
Je ne saurais terminer ce rapport sans remercier tous les enseignants de la faculté des
sciences de Sfax pour la qualité de la formation qu’ils nous ont prodigué.
FS-SFAX
Page ii
TABLE DES MATIÈRES
LISTE DES FIGURES
vi
LISTE DES TABLES
vii
LISTE DES ABRÉVIATIONS
viii
INTRODUCTION GÉNÉRALE
1
1
Étude Préalable
3
1.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2
Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2.1
Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2.2
Activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2.2.1
Extraction du phosphate . . . . . . . . . . . . . . . . . . . .
5
1.2.2.2
La Production . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2.2.3
La Commercialisation . . . . . . . . . . . . . . . . . . . . .
6
1.3
Présentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4
Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4.1
Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4.2
Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.5.1
Solutions envisageables . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.5.2
Solution retenue . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.5.3
Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.5.3.1
Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . .
9
1.5.3.2
Besoins non fonctionnels . . . . . . . . . . . . . . . . . . .
10
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
1.5
1.6
2
Analyse et Conception
12
2.1
13
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FS-SFAX
Page iii
TABLE DES MATIÈRES
2.2
Vue statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2.1
Diagramme des cas d’utilisation . . . . . . . . . . . . . . . . . . . . .
13
2.2.1.1
Identification des acteurs . . . . . . . . . . . . . . . . . . .
13
2.2.1.2
Diagramme de cas d’utilisation global . . . . . . . . . . . .
14
2.2.1.3
Diagramme de cas d’utilisation « Gérer Administrateurs » .
15
2.2.1.4
Diagramme de cas d’utilisation « Gérer Spécialités » . . . .
17
2.2.1.5
Diagramme de cas d’utilisation « Gérer Candidats » . . . . .
18
Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . .
20
Vue dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.3.1
. . . . . . . . . . . . . . . . . . . . . . . .
22
2.3.1.1
Diagrammes de séquence « S’authentifier » . . . . . . . . .
22
2.3.1.2
Diagrammes de séquence «Accès au donnés protégées» . . .
25
2.3.1.3
Diagrammes de séquence « Générer Spécialités » . . . . . .
26
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.2.2
2.3
2.4
3
Diagrammes de séquence
Chapitre Réalisation
27
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2
Choix architectural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2.1
Architecture applicative . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2.1.1
Choix d’architecture du web services . . . . . . . . . . . . .
28
3.2.1.2
Choix de la stratégie d’échange de données
. . . . . . . . .
29
3.2.1.3
Choix de technique de stockage des mots de passes . . . . .
30
Architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Environnement du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.3.1
Environnement logiciel
. . . . . . . . . . . . . . . . . . . . . . . . .
32
3.3.2
Technologies et langages de programmation utilisées . . . . . . . . . .
34
Interface de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.4.1
Interfaces relatives aux candidats . . . . . . . . . . . . . . . . . . . .
37
3.4.2
Interfaces relatives aux administrateurs . . . . . . . . . . . . . . . . .
40
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.2.2
3.3
3.4
3.5
CONCLUSION GÉNÉRALE
45
BIBLIOGRAPHIE
46
ANNEXES
49
A.1 Session Cookies vs. JSON Web tokens . . . . . . . . . . . . . . . . . . . . . .
FS-SFAX
49
Page iv
TABLE DES MATIÈRES
A.1.1 Session Cookies vs. JSON Web tokens — L’approche . . . . . . . . .
49
A.1.2 Cookies de session vs JSON Web tokens - Avantages et inconvénients .
53
A.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
A.2 Bcrypt : une norme de sécurité cryptographique . . . . . . . . . . . . . . . . .
55
A.2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
A.2.2 Qu’est-ce que Bcrypt ? . . . . . . . . . . . . . . . . . . . . . . . . . .
55
A.2.3 Comment fonctionne Bcrypt ? . . . . . . . . . . . . . . . . . . . . . .
56
FS-SFAX
Page v
LISTE DES FIGURES
2.1
Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . .
15
2.2
Diagramme du cas d’utilisation « Gérer Administrateurs » . . . . . . . . . . .
16
2.3
Diagramme de cas d’utilisation « Gérer Spécialités » . . . . . . . . . . . . . .
17
2.4
Diagramme de cas d’utilisation « Gérer Candidats » . . . . . . . . . . . . . . .
19
2.5
Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.6
Diagrammes de séquence « S’inscrire » . . . . . . . . . . . . . . . . . . . . .
23
2.7
Diagrammes de séquence « Login » . . . . . . . . . . . . . . . . . . . . . . .
24
2.8
Diagrammes de séquence « Accès au donnés protégées » . . . . . . . . . . . .
25
2.9
Diagrammes de séquence « Générer Spécialités » . . . . . . . . . . . . . . . .
26
3.1
L’architecture REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.2
Architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.3
Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.4
Interface de candidature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.5
Interface de Spécialités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.6
Fiche de candidature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.7
Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.8
Interface de gestion de spécialités . . . . . . . . . . . . . . . . . . . . . . . .
41
3.9
Interface de gestion des administrateurs . . . . . . . . . . . . . . . . . . . . .
41
3.10 Interface de gestion des candidats . . . . . . . . . . . . . . . . . . . . . . . .
42
3.11 Interface des statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.12 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
A.1 Approche basée sur les cookies de session . . . . . . . . . . . . . . . . . . . .
50
A.2 Approche basée sur les JWT JSON Web Token . . . . . . . . . . . . . . . . .
50
A.3 Algorithme de Bcrypt
57
FS-SFAX
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page vi
LISTE DES TABLES
LISTE DES TABLES
1.1
Solution proposée & Critique . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1
Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.2
Description textuelle du cas d’utilisation « Gérer Administrateurs» . . . . . . .
16
2.3
Description textuelle du cas d’utilisation « Gérer Spécialités » . . . . . . . . .
18
2.4
Description textuelle du cas d’utilisation « Gérer Candidats » . . . . . . . . . .
19
3.1
Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.2
Technologies et langages de programmation utilisées . . . . . . . . . . . . . .
36
FS-SFAX
Page vii
LISTE DES ABRÉVIATIONS
JPA Java Persistence API
CPG Compagnie des phosphates de Gafsa
MIME Multipurpose Internet Mail Extensions
JWT JSON Web Tokens
DB DataBase
HTTP Hypertext Transfer Protocol
REST Representational state transfer
XML Extensible Markup Language
URL Uniform Resource Identifier
CLI Command-Line Interface
NPM Node Package Manager
MIT Massachusetts Institute of Technology
RH Ressources Humaines
CV Curriculum Vitae
FS-SFAX
Page viii
INTRODUCTION GÉNÉRALE
De nos jours, l’informatique est considérée comme un outil indispensable à toute entreprise
qui ne veut pas rester en marge de la mondialisation. En effet, elle est apparue depuis longtemps
comme un soutien aux différentes opérations logistiques des entreprises et au besoin croissant
des sociétés en matière d’information. Ce soutien a évolué dans le temps et dans l’espace, et
même, s’est accru grâce à l’amélioration des systèmes informatiques, ainsi qu’à la perpétuelle
performance du matériel informatique. Cela s’est matérialisé notamment par la réduction progressive
des coûts et la rapidité du traitement des données. Cette évolution continue de sorte qu’il est
impossible de gérer une entreprise sérieuse sans l’informatiser. Avec l’introduction de l’informatique,
le monde de l’entreprise trouve les solutions à ses multiples problèmes liés, notamment, au coût
de l’information, à la communication, à l’enregistrement des données et aux différents calculs
comptables. Désormais, les évolutions récentes de l’informatique appellent à reconsidérer la
dynamique structurelle et fonctionnelle des entreprises.
Ainsi, les systèmes d’information doivent être actualisés en permanence suivant la nature
de l’environnement concurrentiel des entreprises. Notre travail se situe dans ce contexte. En
effet, dans le cadre mon stage de fin d’études, la Compagnie des phosphates de Gafsa m’a
confié l’étude, la conception et le développement d’une application web pour la Gestion de
recrutements.
Le présent rapport explique les différentes étapes suivies pour réaliser le travail demandé.
Nous commençons le rapport par un premier chapitre, dans laquelle nous présentons l’organisme
d’accueil ainsi que une étude théorique basée essentiellement sur deux modules à savoir l’étude
de l’existant et de la solution proposée. Le deuxième chapitre traite les problèmes associés
à l’analyse et la conception. La partie réalisation fait l’objet du troisième chapitre. Où, nous
FS-SFAX
Page 1
INTRODUCTION GÉNÉRALE
expliquons nos choix architecturaux, l’environnement matériel et logiciel du travail et certaines
interfaces graphiques de l’application élaborée.
Comme tout rapport, nous clôturons ce travail par une conclusion. Nous récapitulons les
différentes étapes suivies pour l’élaboration de ce projet et nous signalons ses différentes perspectives.
FS-SFAX
Page 2
Chapitre
1
Étude Préalable
Sommaire
1.1
Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2
Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2.1
Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2.2
Activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.3
Présentation du sujet . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4
Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.5
1.6
FS-SFAX
1.4.1
Description de l’existant . . . . . . . . . . . . . . . . . . . . . .
6
1.4.2
Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . .
7
Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.5.1
Solutions envisageables . . . . . . . . . . . . . . . . . . . . . . .
8
1.5.2
Solution retenue . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.5.3
Spécification des besoins . . . . . . . . . . . . . . . . . . . . . .
9
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Page 3
ÉTUDE PRÉALABLE
1.1 Introduction
Dans ce chapitre, nous décrirons le contexte général du projet. Nous présenterons d’abord
l’entreprise au sein de laquelle s’est déroulé le stage. Nous enchaînerons, par la suite, par
l’explication le sujet et ses différents modules.
1.2 Organisme d’accueil
La Compagnie des Phosphates de Gafsa (CPG) est une entreprise publique anonyme à
caractère industriel et commercial. Elle a pour objet l’exploitation des gisements de phosphate
en Tunisie.
— Date de création : 1897
— Effectif (à fin 12/2016) : 6619
— Site web :www.cpg.com.tn
— Nombre de cadres supérieurs (à fin 12/2016) : 538
— Capacité de production : 8 Million de tonnes
— Chiffre d’affaire 2012 : 553 196 milles Dollars[1]
— Rang mondial de Production : 5 ème
1.2.1
Historique
C’était en avril 1885, lors d’une prospection dans la région de Metlaoui, partie occidentale
du sud du pays, que Philippe THOMAS, géologue amateur français, a découvert des couches
puissantes de phosphates de calcium sur le versant Nord de JEBEL THELJA. D’autres prospections
géologiques et des explorations de grande envergure ont suivi cette découverte décisive. Celles-ci
ont révélé l’existence d’importants gisements de phosphates au sud et au Nord de l’île de
Kasserine. A partir de 1896, date de création de "la Compagnie des Phosphates et de Chemin
de Fer de Gafsa," une nouvelle activité industrielle des phosphates a vu le jour dans le pays. Les
FS-SFAX
Page 4
ÉTUDE PRÉALABLE
premières excavations ont commencé dans la région de Metlaoui et vers 1900, la production
des phosphates marchands a atteint un niveau de 200,000 tonnes. En 1996 c’est la fusion
des deux structures commerciales de la Compagnie des Phosphates de Gafsa et du Groupe
Chimique Tunisien. Avec une expérience centenaire dans l’exploitation et la commercialisation
des phosphates tunisiens, la CPG figure parmi les plus gros producteurs de phosphates dans le
monde. [2]
1.2.2
Activités
Le phosphate est la principale richesse du gouvernorat de Gafsa. Cette substance est exploitée
par la Compagnie des Phosphates de Gafsa qui joue un rôle important dans le développement de
son environnement. Les activités de la CPG sont : l’extraction, la production et la commercialisation
du phosphate.
1.2.2.1
Extraction du phosphate
Les méthodes d’extraction étaient au début classiques, par la suite la société a fait recours de
plus en plus aux méthodes mécanisées et beaucoup plus évoluées. Il existe en fait neuf carrières
d’extraction. L’extraction est assurée selon la recette suivante :
− Ciblé : la séparation de gros et fines de tout venant.
− Trié : la séparation manuelle du refus du criblé.
− Broyé : la réduction granulométrique des blocs du minerai.
Étant précisé que le phosphate (BTS : brut, trié, séché) de la compagnie est extrait à partir
de neuf carrières d’extraction. [3]
1.2.2.2
La Production
La compagnie produit deux qualités principales de phosphates naturels marchands :
− Qualité 65-68% filtrée et séchée : utilisée pour la production des engrais chimiques.
− Qualité 60-62% pour l’application directe.
FS-SFAX
Page 5
ÉTUDE PRÉALABLE
A la fin de ce processus de production, le phosphate est soit stocké dans les cuves des usines,
soit chargé dans les wagons pour être expédié vers les locaux et à l’étranger. [4]
1.2.2.3
La Commercialisation
Cette opération se réalise à deux niveaux :
− Local : le phosphate est commercialisé aux usines d’engrais chimiques de Gabes et de
Sfax soit 80% de la totalité de la production.
− Étranger : la C.P.G exporte sa production en Europe, en Asie et en Amérique latine. [5]
1.3 Présentation du sujet
Le sujet de notre stage consiste en la conception et le développement d’une application
web pour la gestion de recrutement au sein de la CPG. l’objectif est d’automatiser le processus
de recrutement commençant par la phase de dépôt de dossiers jusqu’aux affectations du nouvel
recrut dans le département adéquat. Bien sûr, notre application doit offrir aux candidat le service
de suivi des candidatures.
1.4 Étude de l’existant
L’étude de l’existant constitue une étape préliminaire pour la réalisation de toute application.
En effet, elle permet d’analyser, d’évaluer et de critiquer le fonctionnement habituel, tout en
élaborant la liste des solutions possibles afin d’en retenir une comme solution finale. Nous
commencerons ce chapitre par une étude de l’existant. Le reste du chapitre, concernera l’étude
de la solution retenue, les outils et les fonctionnalités développées.
1.4.1
Description de l’existant
La gestion des candidatures au sein de l’entreprise CPG se déroule actuellement de la
manière suivante :
FS-SFAX
Page 6
ÉTUDE PRÉALABLE
− Les dossiers de candidatures sont traités de manière papier et numérique (au format PDF)
ou uniquement sous format papier.
− Les données issues de ces dossiers sont entrées dans un tableau Microsoft Excel et un
premier avis est donné par le responsable qui examine l’intégralité des dossiers.
− Les meilleurs candidats sont sélectionnés parmi le flux des CV reçus.
− Des entretiens et des tests sont planifiés avec les candidats qui ont été choisis et qui vont
être informés par un courrier par la poste.
1.4.2
Critique de l’existant
Le processus de recrutement, mentionné ci-dessus, souffre d’un ensemble d’inconvénients
dont nous citons :
− Nécessite l’intervention humaine sur tout le processus.
− L’entreprise et notamment le service ressources humaines risque d’être submerger par un
nombre inconsidérable de candidatures et ainsi passer à côté d’un candidat intéressant par
manque de temps pour le traitement de ces candidatures.
− Présente un caractère répétitif
− Grande charge de travail
− Multiplicité de bugs
− Manque d’organisation, pas de gestion de visibilité, protection et contrôle des documents.
− Coûts générés par le temps passé par le(s) collaborateur(s) RH ou opérationnels en charge
du recrutement.
1.5 Solutions
Dans cette section nous présentons les différentes solutions prévues au présent problématique.
FS-SFAX
Page 7
ÉTUDE PRÉALABLE
1.5.1
Solutions envisageables
Afin de résoudre les problèmes sus indiqués, plusieurs solutions peuvent être mise en place.
Parmi ces solutions nous citons :
Solution proposée
Le
téléchargement
Critique
et
Nous ne pouvons ni la
l’utilisation d’une application
maintenir
ni
la
modifier
libre à partir du web.
à moins qu’elle soit open
source.
L’achat d’un application web
Le coût de l’achat sera très
prête.
élevé.
Le
développement
nouvelle
application
d’une
qui
Cette solution nécessite un
développement sur mesure.
respecte la procédure déjà
établie.
TABLE 1.1 – Solution proposée & Critique
1.5.2
Solution retenue
Parmi les solutions indiquées, nous avons opté pour le développement d’une nouvelle application
web pour la gestion de recrutement. Elle doit respecter les conditions suivantes :
− Centraliser l’information et les données concernant le recrutement
− Diminuer le temps de saisie des candidatures
− Diminuer le temps de suivi d’une candidature,
− Partager plus facilement l’information des candidatures et les statistiques avec les responsables
de services.
FS-SFAX
Page 8
ÉTUDE PRÉALABLE
1.5.3
Spécification des besoins
Nous présentons, dans cette partie, essentiellement, l’ensemble des fonctionnalités offertes
par le future système et entre autre, les besoins fonctionnels et non fonctionnels.
1.5.3.1
Besoins fonctionnels
Les besoins fonctionnels expriment les actions que doit effectuer le système en réponse aux
demandes (sorties qui sont produites pour un ensemble donné d’entrées). Notre application se
divise en deux grandes parties :
- Partie logique métier ou partie serveur pour la préparation de l’API.
- Partie frontale ou partie cliente pour la réalisation de l’interface graphique.
Besoins fonctionnels au niveau du Serveur :
1− Développer une API REST pour générer des spécialités adéquates avec les candidats.
2− Développer des API REST pour gérer les utilisateurs et leurs rôles.
3− Développer une API REST pour gérer l’authentification :
∗ Inscription.
∗ Connexion.
∗ Déconnexion.
∗ Jeton de connexion à durée limite.
4− Développer des services pour sécuriser les données sensibles, par exemple : hachage et
cryptage des mots de passe.
5− Développer un service de vérification des rôles et des droits d’accès aux services web.
Besoins fonctionnels au niveau du Client :
Ces besoins expriment les différentes fonctionnalités standards offertes aux utilisateurs de l’application
web. Ils peuvent se résumer comme suit :
1− Développer le module d’authentification :
FS-SFAX
Page 9
ÉTUDE PRÉALABLE
∗ Développer l’interface et la logique nécessaire pour la page inscription.
∗ Développer l’interface et la logique nécessaire pour la page s’identifier.
∗ Développer la logique de déconnexion.
∗ Ajouter les contrôles d’accès sur les données.
2− Développer l’interface et la logique nécessaire pour la page du candidature.
2− Développer l’interface et la logique nécessaire pour la page des spécialités.
3− Développer l’interface et la logique nécessaire qui permettent à l’administrateur de gérer
les spécialités , les candidats et les administrateur.
4− Développer l’interface et la logique nécessaires pour la page statistiques.
1.5.3.2
Besoins non fonctionnels
Un besoin non-fonctionnel est une condition qui spécifie les critères qui peuvent être utilisés
pour juger le fonctionnement d’un système, plutôt que des comportements de celui-ci. Cela
devrait être mis en contraste avec les exigences fonctionnelles qui définissent le comportement
spécifique ou les fonctions désirés. Même si ces besoins n’étant pas décisifs au fonctionnement
du système, ils représentent un bon signe sur la nature du système :
− Autonomie du système : le système s’exécute et fonctionne entièrement sans avoir recours
à d’autres applications
− Convivialité : l’interface utilisateur doit être conviviale pour assurer un accès aisé aux
données.
− Ergonomie : l’application doit être ergonomique et facile à utiliser.
− Navigabilité : elle doit être aussi navigable en donnant la possibilité à l’utilisateur d’accéder
aux différentes rubriques à partir de n’importe quelle page grâce à la présence d’un menu.
− Gestion des erreurs : Les erreurs doivent être signalées par des messages d’erreur explicites.
− Sécurisé : Les données des candidats sont seulement accessibles par le(s) opérationnels
en charge du recrutement.
FS-SFAX
Page 10
ÉTUDE PRÉALABLE
1.6 Conclusion
Après avoir fait une analyse de l’existant pour fixer les besoins et les objectifs visés, ce
chapitre a permis de spécifier les besoins fonctionnels et non fonctionnels que l’outil doit offrir
aux utilisateurs. Nous prendrons en détaille notre solution, dans le chapitre suivant, à travers
l’étude conceptuelle.
FS-SFAX
Page 11
Chapitre
2
Analyse et Conception
Sommaire
2.1
Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2
Vue statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3
2.2.1
Diagramme des cas d’utilisation . . . . . . . . . . . . . . . . . .
13
2.2.2
Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . .
20
Vue dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.3.1
2.4
FS-SFAX
Diagrammes de séquence
. . . . . . . . . . . . . . . . . . . . .
22
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
Page 12
ANALYSE ET CONCEPTION
2.1 Introduction
Après avoir fixé les besoins de notre projet, ce chapitre présente la conception. C’est une
phase primordiale menant à optimiser le développement de toute application. En effet, elle
formalise les étapes préliminaires du développement du futur système afin de rendre ce développement
plus fidèle aux besoins. Ainsi, ce chapitre tient compte de deux vues du système : une vue
statique exprimée par un diagramme de classes et des diagrammes de cas d’utilisation et une
vue dynamique exprimée par des diagrammes de séquences.
2.2 Vue statique
A ce niveau, nous exprimons les besoins fonctionnels dégagés précédemment sous la forme
de diagrammes. Ces diagrammes, réalisés à l’aide du langage de modélisation UML, permettent
de mieux structurer les interactions entre les utilisateurs et le système. Par conséquent, ils
améliorent la compréhension du système.
2.2.1
Diagramme des cas d’utilisation
En langage UML, les diagrammes de cas d’utilisation modélisent le comportement d’un
système et permettent de capturer les exigences du système. Les diagrammes de cas d’utilisation
décrivent les fonctions générales et la portée d’un système. Ces diagrammes identifient également
les interactions entre le système et ses acteurs. Les cas d’utilisation et les acteurs dans les
diagrammes de cas d’utilisation décrivent ce que le système fait et comment les acteurs l’utilisent.
[6]
2.2.1.1
Identification des acteurs
Un acteur est l’idéalisation d’un rôle joué par une personne externe, un processus ou une
chose qui interagit avec un système.
FS-SFAX
Page 13
ANALYSE ET CONCEPTION
Acteur
Candidat
Administrateur
Super Administrateur
Fonctionnalités
Après d’être authentifié,il
peut remplir sa demande de
candidature et l’imprimer.
Il consulte les statistiques,
la liste des candidats et
l’imprimer.
Il gère les spécialités, les
administrateurs et consulte
les candidatures et les
statistiques.
TABLE 2.1 – Identification des acteurs
2.2.1.2
Diagramme de cas d’utilisation global
Ayant capturé les besoins fonctionnels de notre application, nous sommes maintenant en
mesure d’illustrer les fonctionnalités recueillies à travers un diagramme des cas d’utilisation
global représenté par la figure 2.1.
FS-SFAX
Page 14
ANALYSE ET CONCEPTION
F IGURE 2.1 – Diagramme de cas d’utilisation global
2.2.1.3
Diagramme de cas d’utilisation « Gérer Administrateurs »
Une fois authentifier, un super-administrateur peut ajouter,supprimer ou modifier les rôles
des administrateurs.
FS-SFAX
Page 15
ANALYSE ET CONCEPTION
F IGURE 2.2 – Diagramme du cas d’utilisation « Gérer Administrateurs »
Titre
Gérer Administrateurs
Acteur
Super-Administrateur
Description des enchaînements
Pré-conditions :
Super-Administrateur
authentifié
Scénario nominal :
1- Après authentification,Le Super-Administrateur demande la formulaire
de la gestion des administrateur.
2- le Super-Administrateur remplit les champs.
3- le Super-administrateur valide en cliquant sur "créer /Supprimer /Modifier".
4- Le Système récapitule les informations saisies et fait la modification voulu.
5-Le Système informe tous les administrateur de cette modification.
Scénario d’exception
E1 : les champs sont erronés ou incomplets :Le formulaire est rechargé en affichant les erreurs .
E2 : Ressource existante : Le formulaire est rechargé en affichant un message "Ressource existante"
Post conditions :
modifications
ont
été
effectuées avec succès
TABLE 2.2 – Description textuelle du cas d’utilisation « Gérer Administrateurs»
FS-SFAX
Page 16
ANALYSE ET CONCEPTION
2.2.1.4
Diagramme de cas d’utilisation « Gérer Spécialités »
Une fois authentifier, un super-administrateur peut ajouter, supprimer des spécialités ou
même modifier les conditions des spécialités.
F IGURE 2.3 – Diagramme de cas d’utilisation « Gérer Spécialités »
FS-SFAX
Page 17
ANALYSE ET CONCEPTION
Titre
Gérer Spécialités
Acteur
Super-Administrateur
Description des enchaînements
Pré-conditions :
Super-Administrateur
authentifié
Scénario nominal :
1- Après authentification, Le Super-Administrateur demande
le formulaire de la gestion des Spécialités.
2- le Super-Administrateur remplit les champs.
3- le Super-administrateur valide en cliquant sur "Ajouter /Supprimer /Modifier".
4- Le système récapitule les informations saisies et réalise la modification désirée.
5-Le Système informe tous les administrateur de cette modification.
Scénario d’exception
E1 : les champs sont erronés ou incomplets
Le formulaire est rechargé en affichant les erreurs.
Post conditions :
Modifications
ont
été
effectuées avec succès
TABLE 2.3 – Description textuelle du cas d’utilisation « Gérer Spécialités »
2.2.1.5
Diagramme de cas d’utilisation « Gérer Candidats »
Une fois authentifié, un administrateur peut consulter la liste des candidats et l’imprimer. Il
peut aussi rechercher un candidats et imprimer sa fiche de candidature.
FS-SFAX
Page 18
ANALYSE ET CONCEPTION
F IGURE 2.4 – Diagramme de cas d’utilisation « Gérer Candidats »
Titre
Gérer Candidats
Acteur
Administrateur
Description des enchaînements
Pré-conditions :
Administrateur authentifié
Scénario nominal :
1- Après authentification, l’administrateur est dirigé vers la page de la gestion des Candidats.
2- L’administrateur clique sur la bouton de la fonctionnalité désiré .
3- Le Système récapitule les informations saisies et réalise les modifications nécessaires ou bien retourne
les informations désirés.
Scénario d’exception
E1 : les champs sont erronés ou incomplets : Le formulaire est rechargé en affichant les erreurs.
Post conditions :
la
tache
désirée
a
été
effectuée avec succès
TABLE 2.4 – Description textuelle du cas d’utilisation « Gérer Candidats »
FS-SFAX
Page 19
ANALYSE ET CONCEPTION
2.2.2
Diagramme de classes
Le diagramme de classes représente la structure statique d’un modèle, à savoir les éléments
(classes et types), la structure interne des éléments et leurs relations les uns par rapport aux
autres.
Il constitue un élément très important de la modélisation car il permet essentiellement de :
- Définir qu’elles seront les composantes du système.
- Représenter l’organisation des données dans les systèmes d’information.
- Structurer le travail de développement de manière très efficace.
Ce diagramme est composé essentiellement de classes et de relations entre les classes qui
constituent la future application et servent à décrire leurs attributs ainsi que leurs comportements
comme le montre le figure 2.5
FS-SFAX
Page 20
ANALYSE ET CONCEPTION
F IGURE 2.5 – Diagramme de classes
FS-SFAX
Page 21
ANALYSE ET CONCEPTION
2.3 Vue dynamique
Dans cette section, nous expliquons le dynamisme du futur système par le biais des diagrammes
de séquences.
2.3.1
Diagrammes de séquence
Les diagrammes de séquence présentent une solution populaire pour la modélisation dynamique.
Ils se basent sur les lignes de vie, les processus et les objets qui vivent simultanément, et les
messages qu’ils échangent entre eux pour réaliser un traitement.
Ces diagrammes sont réalisés, à la fois, par les concepteurs du futur logiciel et les managers des
entreprises pour analyser les besoins du nouveau système ou documenter un processus existant.
Les diagrammes de séquence sont parfois appelés diagrammes d’événements ou scénarios
d’événements.[8]
2.3.1.1
Diagrammes de séquence « S’authentifier »
S’inscrire
L’application envoie les données saisies par l’utilisateur dans le formulaire d’inscription au
serveur. Le contrôleur de serveur vérifie la validation des données et effectue, ensuite, l’appel au
service d’authentification qui vérifie l’existence du rôle et appelle le référentiel du candidat . Le
référentiel de candidat envoie une requête à la base de données pour créer un nouvel utilisateur.
Une vérification de l’existence d’un utilisateur se fait au niveau de la base de données . Si
l’utilisateur n’existe pas, la base de données en créera un nouveau et un message de réussite
sera envoyé à l’utilisateur. Sinon, un message d’erreur lui sera envoyé.
FS-SFAX
Page 22
ANALYSE ET CONCEPTION
F IGURE 2.6 – Diagrammes de séquence « S’inscrire »
S’identifier
L’application client envoie l’identifiant et le mot de passe chiffré de l’utilisateur au serveur.
Le contrôleur fait appel au service d’authentification qui fait de son tour appel au référentiel de
candidat. Celui-ci envoie interroge la base de données pour trouver le candidat. Si le résultat
retourné par la base de données n’est pas vide, c’est-à-dire le candidat existe, le service vérifie
le mot de passe. En cas de succès, le candidat accède à son compte. Dans le cas où le CIN ou le
mot de passe sont incorrects, un message d’erreur sera envoyé.
FS-SFAX
Page 23
ANALYSE ET CONCEPTION
F IGURE 2.7 – Diagrammes de séquence « Login »
FS-SFAX
Page 24
ANALYSE ET CONCEPTION
2.3.1.2
Diagrammes de séquence «Accès au donnés protégées»
L’application client envoie au serveur, une demande d’accès à des données protégées. Si
le client a le droit d’y accéder alors le système autorise l’accès . Sinon, il sera bloqué et un
message d’erreur sera renvoyé.
F IGURE 2.8 – Diagrammes de séquence « Accès au donnés protégées »
FS-SFAX
Page 25
ANALYSE ET CONCEPTION
2.3.1.3
Diagrammes de séquence « Générer Spécialités »
L’application envoie les données saisies par l’utilisateur dans le formulaire de candidature
au serveur. Le contrôleur de serveur vérifie la validation des données puis,le il fait appel au
référentiel de Spécialité. Ce dernier envoie une requête à la base de données pour générer et
envoyer une liste de spécialité adéquate au profil du candidat.
F IGURE 2.9 – Diagrammes de séquence « Générer Spécialités »
2.4 Conclusion
Nous avons présenté, dans ce chapitre, la conception de la future application, d’une manière
détaillée, à travers certains diagrammes UML. Nous présentons, dans le prochain chapitre,la
phase de réalisation.
FS-SFAX
Page 26
Chapitre
3
Chapitre Réalisation
Sommaire
3.1
Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2
Choix architectural . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.3
3.4
3.5
FS-SFAX
3.2.1
Architecture applicative . . . . . . . . . . . . . . . . . . . . . .
28
3.2.2
Architecture technique . . . . . . . . . . . . . . . . . . . . . . .
31
Environnement du travail . . . . . . . . . . . . . . . . . . . . . .
32
3.3.1
Environnement logiciel
. . . . . . . . . . . . . . . . . . . . . .
32
3.3.2
Technologies et langages de programmation utilisées . . . . . .
34
Interface de l’application . . . . . . . . . . . . . . . . . . . . . .
37
3.4.1
Interfaces relatives aux candidats . . . . . . . . . . . . . . . . .
37
3.4.2
Interfaces relatives aux administrateurs . . . . . . . . . . . . .
40
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Page 27
CHAPITRE RÉALISATION
3.1 Introduction
Dans ce chapitre, nous spécifions les architectures applicative et technique adoptées pour la
réalisation de notre application. Puis nous présentons l’environnement matériel et logiciel du
projet. Ensuite, nous exposons la phase d’implantation. Par le biais de quelques prises d’écrans,
nous expliquons le fonctionnement de notre application.
3.2 Choix architectural
Avant d’entamer la conception et la réalisation de tout système informatique, il faut spécifier
à l’avance l’architecture applicative et technique que nous allons suivre tout au long du développement.
Notre choix architectural s’est basé sur les besoins exprimés précédemment afin de réaliser
notre application autour d’une architecture évolutive et qui permet de supporter les objectifs
stratégiques et les processus métiers de l’entreprise.
3.2.1
Architecture applicative
3.2.1.1
Choix d’architecture du web services
Dans notre progiciel, nous avons utilisé l’architecture REST (Representational State Transfer)
ou RESTful est un style d’architecture reposant sur l’utilisation du protocole HTTP en tirant
partie de son enveloppe et de ses en-têtes sans ajout de sur-couche.
Ce paradigme d’architecture se veut parfaitement stateless et laisse donc le soin au client de
gérer les sessions. Il utilise des standards. En particulier :
− URI comme syntaxe universelle pour adresser les ressources,
− HTTP un protocole sans état (stateless) avec un nombre très limité d’opérations,
− Des liens hypermedia dans des documents (X)HTML et XML pour représenter à la fois
le contenu des informations et la transition entre états de l’application,
FS-SFAX
Page 28
CHAPITRE RÉALISATION
− Les types MIME comme text/xml, text/html, image/jpeg, application/pdf, video/mpeg
pour la représentation des ressources.
Bien que l’API REST doive se conformer à ces critères, elle est toujours considérée plus facile
à utiliser qu’un protocole prescrit comme SOAP (Simple Object Access Protocol), qui a des
exigences spécifiques comme la messagerie XML, et la sécurité intégrée et la conformité des
transactions qui le rendent plus lent et plus lourd.
En revanche, REST est un ensemble de directives qui peuvent être mises en œuvre selon les
besoins, rendant les API REST plus rapides et plus légères.
F IGURE 3.1 – L’architecture REST
3.2.1.2
Choix de la stratégie d’échange de données
HTTP est un protocole "sans état", dont le sens où chaque appel http effectué vers un serveur
est comme un nouvel appel, sans mémoire ni "état" des appels précédents.
Dans les applications, nous devons généralement maintenir des "sessions" de connexion, de
sorte qu’une fois l’utilisateur se connecte, il peut continuer à accéder à différentes parties de
l’application sans avoir à se connecter (c’est-à-dire à S’authentifier) encore et encore pour
chaque requête HTTP suivante effectuée. au serveur.
Quant à la gestion de session, il existe principalement deux approches différentes :
− Approche basée sur les sessions ou les cookies
− Approche basée sur JWT (JSON Web Tokens)
FS-SFAX
Page 29
CHAPITRE RÉALISATION
Ces deux approches sont fondamentalement distinctes et complètes pour la gestion des sessions.
Dans l’annexe A.1, nous comparerons et opposerons les deux approches.
3.2.1.3
Choix de technique de stockage des mots de passes
Nous savons que le stockage des mots de passe en clair ne doit jamais être une option.
Au lieu de cela, nous voulons fournir une voie à sens unique (one-way road) vers la sécurité
en hachant les mots de passe. Cependant, nous savons également que le hachage seul n’est
pas suffisant pour atténuer les attaques plus complexes telles que les tables arc-en-ciel(rainbow
tables)[7].
Une meilleure façon de stocker les mots de passe consiste à ajouter le salage (Salting) [11] au
processus de hachage ( ajouter des données aléatoires supplémentaires à l’entrée d’une fonction
de hachage qui rend chaque hachage de mot de passe unique.)
La plate-forme d’authentification idéale intègre ces deux processus, le hachage et Salage.
Il existe de nombreuses fonctions cryptographiques telles que la famille SHA2 et la famille
SHA-3. Les familles SHA nt été conçues pour être rapides en termes de calcul. La rapidité avec
laquelle une fonction cryptographique peut calculer un hachage a une incidence immédiate et
significative sur la sécurité du mot de passe.
Des calculs plus rapides signifient des attaques par brute-force plus rapides, par exemple.
Le matériel moderne sous la forme de CPU et de GPU pourrait calculer des millions, voire des
milliards, de hachages SHA-256 par seconde par rapport à une base de données volée. Au lieu
d’une fonction rapide, nous avons besoin d’une fonction lente à hacher les mots de passe pour
arrêter presque les attaquants. Nous voulons également que cette fonction soit adaptative afin
que nous puissions compenser le futur hardware plus rapide en pouvant faire en sorte que la
fonction s’exécute de plus en plus lentement au fil du temps.
Dans le présent projet, l’intégrité et la sécurité des données sont l’une de nos plus hautes
priorités. Nous utilisons l’algorithme bcrypt pour hacher et saler les mots de passe en toute
sécurité. bcrypt permet de construire une plate-forme de sécurité des mots de passe qui peut
évoluer parallèlement à la technologie matérielle. Ceci pour se prémunir contre les menaces
FS-SFAX
Page 30
CHAPITRE RÉALISATION
que l’avenir peut apporter, telles que les attaquants ayant la puissance de calcul pour déchiffrer
les mots de passe deux fois plus vite.
Nous découvrons dans l’annexe A.2, la conception et les spécifications qui font de bcrypt
une norme de sécurité cryptographique.
3.2.2
Architecture technique
Nous présentons dans la figure 3.2 l’architecture technique de notre projet
F IGURE 3.2 – Architecture technique
On se basant sur l’architecture trois-tiers, nous allons développer notre système qui doit être
divisé en trois couches différentes :
− Couche présentation : Elle correspond à la partie visible et interactive de l’application.
− Couche applicative ou Couche métier : Elle correspond à la partie fonctionnelle de l’application.
C’est elle qui implémente la « logique », et qui décrit les opérations que l’application
opère sur les données en fonction des requêtes des utilisateurs.
− Couche donnée : Elle consiste en la partie gérant l’accès aux de données du système. Ces
données peuvent être propres au système, ou gérées par un autre système.
FS-SFAX
Page 31
CHAPITRE RÉALISATION
3.3 Environnement du travail
Dans cette section, nous présentons les environnements logiciels utilisés dans le cadre de ce
projet.
3.3.1
Environnement logiciel
Pour réaliser notre projet, nous avons eu recours à différents logiciels que nous allons citer
dans le tableau 3.1
Environnement logiciel
Pourquoi je l’ai utilisé ?
Visual Studio Code
C’est un éditeur de code libre et
gratuit, léger, mais puissant. Il est
livré avec un support intégré pour
JavaScript, TypeScript et Node.js et
il possède un écosystème riche en
extensions.
Overleaf
C’est une plateforme en ligne
gratuite permettant d’éditer du
texte
en
LATEX
sans
aucun
téléchargement d’application. En
outre, elle offre la possibilité de
rédiger des documents de manière
collaborative.
FS-SFAX
Page 32
CHAPITRE RÉALISATION
Eclipse
IDE Eclipse donne accès à des
fonctionnalités avancées, comme
un éditeur de code intégré, un
débogueur
et
un
compilateur,
ainsi que le support intégré de
la gestion de gros projets et le
partage des projets au sein d’une
équipe. Eclipse fournit également
la prédiction de texte et la détection
d’erreurs de syntaxe pendant que
vous codez dans l’éditeur.
MySQL Workbench
C’est un logiciel de gestion et
d’administration
de
bases
de
données MySQL. Via une interface
graphique
intuitive,
il
permet,
entre autres, de créer, modifier ou
supprimer des tables, des comptes
utilisateurs, et d’effectuer toutes les
opérations inhérentes à la gestion
d’une base de données.
TABLE 3.1 – Environnement logiciel
FS-SFAX
Page 33
CHAPITRE RÉALISATION
3.3.2
Technologies et langages de programmation utilisées
Technologies
Pourquoi je l’ai utilisées ?
Angular
Framework open source écrit en
JavaScript,qui
m’a
permet
de
créer une applications Web, plus
particulièrement ce qu’on appelle
des " Single Page Applications " :
une applications web accessibles
via une page web unique qui permet
de fluidifier l’expérience utilisateur
et d’éviter les chargements de
pages à chaque nouvelle action.
Spring boot
Pour faire simple, Spring Boot est
un framework de développement
JAVA qui m’a permet d’interagir
avec une base de données,traiter
des requêtes HTTP et écrire des
réponses HTTP,Gérer la sécurité de
l’application..
MySQL
Système de gestion de bases
de données relationnelles SQL
open source stocker, utilisé pour
stocker,récupérer
et
gérer
des
données.
FS-SFAX
Page 34
CHAPITRE RÉALISATION
Angular CLI
C’est une Command Line Interface
(interface en ligne de commande,
en français) développée par les
équipes d’Angular même. Cette
CLI permet de créer des projets
dans lesquels la CLI pourra ajouter
des fichiers et plus exactement
des
entités
Angular.
Il
sera
possible d’ajouter des modules,
des composants, des services ou
bien des directives en une ligne de
commande.
Lombok
rend Java plus cool à nouveau !,Il
fournit un ensemble d’annotations
utiles pour éliminer une grande
quantité de code standard de vos
classes Java. Dans le meilleur
des cas, cinq caractères seulement
peuvent remplacer des centaines de
lignes de code. Le résultat est de
classes Java propres, concises et
faciles à gérer.[?]
Node Package Manager
C’est un outil de gestion de librairie
JavaScript, je l’ai utilisé pour
installer, mettre à jour et enlever des
librairies.
FS-SFAX
Page 35
CHAPITRE RÉALISATION
iText
Bibliothèque Java qui permet de
créer, convertir et manipuler des
documents PDF.
Ng2-charts
Bibliothèque
JavaScript
open-source disponible via npm.
Il m’a aidé à créer des graphiques
accrocheurs dans Angular à l’aide
de Chart.js (Partie Statistique ).
Apache Maven
C’est un outil de gestion et
d’automatisation de production des
projets logiciels Java, utilisé pour
gérer des dépendances vis-à-vis des
bibliothèques nécessaires au projet.
Spring Data(JPA)
Framework
ORM
offre
une
abstraction qui m’a permet de
manipuler uniquement des objets
sans avoir besoin (ou quasiment
pas besoin) de faire du SQL,le
framework va générer les requêtes
SQL et être capable d’effectuer de
nombreuses opérations sur la base
de données, en fonction du code
objet que j’ai implémenté.
Bootstrap
framework qui permet de créer
un site facilement, avec un design
responsive, qui s’adapte à tout type
d’écran.
TABLE 3.2 – Technologies et langages de programmation utilisées
FS-SFAX
Page 36
CHAPITRE RÉALISATION
3.4 Interface de l’application
Dans cette section, nous présentons quelques interfaces graphiques de notre application.
3.4.1
Interfaces relatives aux candidats
Interface d’authentification :
La figure 3.3 présente le point d’entrée de l’application. A travers cette interface un nouvel
utilisateur peut s’inscrire alors qu’un candidat peut accéder à son espace privé. Il suffit sélectionner
son choix et de saisir son numéro de carte d’identité nationale (CIN), son mot de passe et sa
délégation, il sera diriger vers l’interface de candidature.
F IGURE 3.3 – Interface d’authentification
FS-SFAX
Page 37
CHAPITRE RÉALISATION
Interface de candidature
La figure 3.4 présente l’interface de Candidature. Le candidat doit remplir les champs vides
pour qu’il puisse passer vers l’interface de Spécialités 3.5.
F IGURE 3.4 – Interface de candidature
FS-SFAX
Page 38
CHAPITRE RÉALISATION
Interface de spécialités
L’interface de Spécialités (figure 3.5) offre le choix au candidat entre une ou deux spécialités
avant de passer vers l’interface de fiche de candidature.
F IGURE 3.5 – Interface de Spécialités
Fiche de candidature
La figure 3.6 présente l’interface de Candidature. Le candidat peut télécharger sa fiche de
candidature sous la forme pdf en cliquant sur télécharger.
F IGURE 3.6 – Fiche de candidature
FS-SFAX
Page 39
CHAPITRE RÉALISATION
3.4.2
Interfaces relatives aux administrateurs
Interface d’authentification
La figure 3.7 présente l’interface d’authentification. C’est le point d’entrée pour les administrateurs.
Ainsi, un administrateur saisit son matricule et son mot de passe pour qu’il soit diriger vers
l’interface Menu Admin.
F IGURE 3.7 – Interface d’authentification
Interface de gestion de spécialités
La figure 3.8 présente l’interface de gestion de spécialités. L’administrateur peut modifier,
ajouter ou supprimer des spécialités à partir de cette interface.
FS-SFAX
Page 40
CHAPITRE RÉALISATION
F IGURE 3.8 – Interface de gestion de spécialités
Interface de gestion des administrateurs
La figure 3.9 présente l’interface de gestion des administrateurs. Le super administrateur
peut ajouter, supprimer ou modifier les rôles des autres administrateurs à partir de cette interface.
F IGURE 3.9 – Interface de gestion des administrateurs
Interface de gestion des candidats
La figure 3.10 présente l’interface de gestion des candidats. L’administrateur peut imprimer
la liste des candidats ou imprimer les données relatives à un candidat à partir de cette interface.
FS-SFAX
Page 41
CHAPITRE RÉALISATION
F IGURE 3.10 – Interface de gestion des candidats
Interface des statistiques
La figure 3.11 présente l’interface des statistiques. L’administrateur peut consulter les statistiques
à partir de cette interface.
FS-SFAX
Page 42
CHAPITRE RÉALISATION
FS-SFAX
F IGURE 3.11 – Interface des statistiques
Page 43
CHAPITRE RÉALISATION
Interface des notifications :
La figure 3.12 présente l’interface des notifications. L’administrateur peut consulter les
notifications à partir de cette interface.
F IGURE 3.12 – Visual Studio Code
3.5 Conclusion
Dans ce chapitre, nous avons présenté l’architecture de notre application. Aussi, nous avons
détaillé les principales interfaces.
FS-SFAX
Page 44
CONCLUSION GÉNÉRALE
Ce rapport résume notre travail au sein de la Compagnie des Phosphates de Gafsa dans le
cadre du stage de fin d’études pour l’obtention du diplôme de licence en science informatique.
La société nous a proposé de développer une application Web pour la gestion de recrutement
dont le but est d’automatiser le processus de recrutement.
La première étape de notre stage était l’étude de l’existant. Cette étude nous a aidé pour
comprendre de plus en plus la problématique.Non seulement, elle nous a permis définir exactement
les différents besoins fonctionnels et non fonctionnels du futur système. Comme pour tout
application, nous avons réalisé une conception en détaillée de la solution retenue afin de faciliter
l’étape d’implantation. Pour atteindre nos objectif, nous avons utilisé des plateformes et des
technologies d’actualité.
Ce stage m’a permis de renforcer de nombreux concepts comme la gestion efficace du temps
et les compétences en communication. Bien sûr, m’a permis d’apprendre et perfectionner mes
capacités à travers les technologies utilisées le long du stage, tel que Angular, Spring Boot et
MySQL. Notre application adopte la notion d’un site web mono-page (single-page application)
avec chargement dynamique des composants. Nous avons visé à avoir une application web facile
à utiliser et ayant une interface simple et ergonomique.
D’autre part, j’ estime, que le travail réalisé la long de ce stage, m’a permis d’enrichir mon
expérience et de renforcer mes chances de succès dans la vie professionnelle.
J’ai eu l’occasion, durant ce stage, de mettre en valeur ce que j’ai appris au cours de
mes études dans le cadre de cette formation. j’espère également que ce projet m’a donné
FS-SFAX
Page 45
CONCLUSION GÉNÉRALE
suffisamment de compétences et d’expérience pour me permettre de percer dans la vie professionnelle
en toute sérénité.
Comme dernier ajout, bien que l’application développée réponde aux besoins spécifiés,
certaines perspectives peuvent être proposées :
− Les candidats peuvent ajouter les documents à travers le formulaire au lieu de les apporter
le jour d’entretien.
− Au lieu de vérifier les document significatifs des candidats à la main, on peut implémenter
un système de vérification à l’aide de l’intelligence artificiel.
− L’implémentation d’un service qui calcule des scores pour les candidats à l’égard d’un
barème spécifié par la compagnie.
FS-SFAX
Page 46
BIBLIOGRAPHIE
[1] Chiffre d’affaire 2012 CPG. [en ligne].Disponible sur :
https ://fr.wikipedia.org/wiki/Compagnie_des_phosphates_de_Gafsa
[2] Historique. Historique CPG [en ligne]. Disponible sur :
http ://cpg.com.tn/#/historique
[3] Extraction CPG. USENIX. Disponible sur :
https ://fr.wikipedia.org/wiki/Compagnie_des_phosphates_de_Gafsa
[4] Production. Disponible sur :
http ://cpg.com.tn/#/production
[5] Commercialisation. Disponible sur :
http ://cpg.com.tn/#/commercialisation
[6] Diagrammes de cas d’utilisation . Disponible sur :
https ://www.ibm.com/docs/fr/rational-soft-arch/9.5 ?topic=diagrams-use-case
[7] Rainbow table .[en ligne]. Disponible sur :
https ://en.wikipedia.org/wiki/Rainbow_table
[8] UML. Qu’est-ce qu’un diagramme de séquence UML . Disponible sur :
https ://www.lucidchart.com/pages/fr/diagramme-de-sequence-uml
[9] Blowfish. Blowfish [en ligne]. Disponible sur :
https ://https ://en.wikipedia.org/wiki/Blowfish_(cipher)
[10] Cryptographic software. USENIX. Disponible sur :
https ://www.usenix.org/legacy/events/usenix99/provos/provos_html/node1.html
[11] Salage (cryptographie) . Disponible sur :
https ://fr.wikipedia.org/wiki/Salage_(cryptographie)
FS-SFAX
Page 47
BIBLIOGRAPHIE
[12] Hashing in Action : Understanding bcrypt. bcrypt. Disponible sur :
https ://auth0.com/blog/hashing-in-action-understanding-bcrypt/
[13] Bcrypt and Password Security - An Introduction. Disponible sur :
https ://www.youtube.com/watch ?v=O6cmuiTBZVs
[14] Bcrypt Tutorial in Nodejs | Understand Hashing, Salt, Rainbow Tables and Bcrypt
Disponible sur :
https ://www.youtube.com/watch ?v=ro1WmoP4CZs
FS-SFAX
Page 48
ANNEXES
A.1 Session Cookies vs. JSON Web tokens
A.1.1
Session Cookies vs. JSON Web tokens — L’approche
1. Après une authentification réussie, (en cas d’approche session-cookie) le serveur génère
un "cookie", OU (en cas d’approche JWT) le serveur génère un "accessToken"
Une fois que l’utilisateur est "authentifié", c’est-à-dire le serveur vérifie que le nom d’utilisateur/mot
de passe correspond à un de la base de données .
Approche basée sur les cookies de session :
1. Le serveur génère un "SessionId" (le signe avec une "clé secrète"), et
(a) enregistre le SessionId dans une SessionDB, et
(b) envoie un cookie avec le sessionId au navigateur (côté client).
2. Le navigateur (côté client) reçoit le "cookie" dans la réponse du serveur et l’enregistre dans
le stockage "cookie".
3. Le navigateur inclut alors le "cookie" dans chaque demande ultérieure au serveur.
FS-SFAX
Page 49
ANNEXES
F IGURE A.1 – Approche basée sur les cookies de session
Approche basée sur les JWT JSON Web Token :
1. Le serveur a généré un "accessToken", cryptant le "userId" et "expiresIn", avec
l’ ACCESS_TOKEN_SECRET, et envoyez le "accessToken" au navigateur (côté client).
2. Le navigateur (côté client) reçoit le "accessToken" et l’enregistre côté client.
3. Le "accessToken" est inclus dans chaque demande ultérieure au serveur.
F IGURE A.2 – Approche basée sur les JWT JSON Web Token
FS-SFAX
Page 50
ANNEXES
Noter :
- Dans l’approche JWT, l’accessToken lui-même contient le "userId" chiffré et l’accessToken
n’est enregistré dans aucune sessionDB. Étant donné qu’aucune base de données n’est requise
dans le cas de "l’approche jwt", elle est parfois appelée une approche "sans état" de la gestion
des sessions, car aucun "état" ou "session" n’est enregistré dans une base de données (elle est
contenue dans le jeton JWT lui-même ). Les jetons JWT sont parfois appelés « Bearer Tokens
», car toutes les informations sur l’utilisateur, c’est-à-dire "bearer" est contenu dans le jeton.
Dans le cas de l’approche basée sur les cookies de session, le sessionId ne contient aucune
information sur l’ID utilisateur, mais est une chaîne aléatoire générée et signée par la "clé
secrète".
Le sessionId est ensuite enregistré dans une sessionDB. La sessionDB est une table de base de
données qui mappe(maps) "sessionId" "userId".
Étant donné que les identifiants de session sont stockés dans sessionDB, "l’approche des cookies
de session" est parfois appelée une approche stateful "avec état" de la gestion des sessions,
puisque "l’état" ou la "session" est enregistré dans une base de données.
Dans les deux approches, le côté client doit enregistrer en toute sécurité le « cookie » ou le
« jeton jwt ». La principale différence est que dans le cas de l’approche JWT, le serveur n’a pas
besoin de maintenir une base de données de sessionId pour la recherche.
2. Pour maintenir les sessions, chaque demande ultérieure au serveur (en cas d’approche
de cookie de session) doit inclure le "cookie (sessionId)", OU (en cas d’approche JWT)
doit inclure le "accessToken"
Maintenant que l’utilisateur est authentifié (et que le côté client a soit un "cookie" OU un
"accessToken"), disons que l’utilisateur connecté veut un tas d’actions comme modifier ses
données ou les afficher. chaque demande faite au serveur, le serveur fait ce qui suit
-Étapes de l’approche basée sur les cookies de session,
1. Récupérez le "sessionId" de la requête "cookie".
2. Vérifiez l’intégrité de "sessionId" à l’aide de la "clé secrète".
FS-SFAX
Page 51
ANNEXES
Ensuite, recherchez le "sessionId" dans la sessionDB sur le serveur et obtenez le "userId".
3. Recherchez le "userId" dans CandidatDB pour modifier des informations pour cet userId, ou
afficher ses informations .
-Étapes de l’approche basée sur JWT
1. Obtenez le "accessToken" à partir de l’"en-tête" de la requête.
2. Décryptez le "accessToken", c’est-à-dire le JWT, en utilisant
ACCESS_TOKEN_SECRET et obtenez le "userId" (il n’y a pas de recherche de base de données).
3. Recherchez le "userId" dans CandidatDB pour modifier des informations pour cet userId, ou
afficher ses informations .
-Notez donc que dans le cas de l’approche des cookies de session, le serveur devrait maintenir
une liste de toutes les sessions dans sessionsDB. Notez également que cela signifie qu’il y aurait
une recherche de base de données pour obtenir le userId . Les recherches de base de données
sont relativement plus lentes que l’action de décryptage JWT.
Dans le cas de l’approche JWT, étant donné que le jeton JWT lui-même contient les informations
(cryptées) de l’ID utilisateur, nous n’avons pas besoin d’effectuer une "recherche" pour obtenir
l’ID utilisateur. Au moment où le serveur déchiffre le jeton JWT, il obtient l’ID utilisateur.
(REMARQUE : seuls les serveurs qui ont le ACCESS_TOKEN_SECRET partagé peuvent
déchiffrer le jeton JWT).
Cela permet à plusieurs serveurs d’être mis à l’échelle séparément et sans avoir besoin
d’avoir une copie actuelle de la base de données sessionId sur tous les serveurs, ou que tous les
serveurs accèdent à une base de données sessionDB commune.
Tant qu’un serveur a le même ACCESS_TOKEN_SECRET qui a été utilisé pour générer le
jeton JWT, ce serveur peut déchiffrer le jeton JWT et obtenir l’ID utilisateur.
FS-SFAX
Page 52
ANNEXES
A.1.2
Cookies de session vs JSON Web tokens - Avantages et inconvénients
Approche des cookies de session :
Avantages
Lors de la déconnexion, puisque le sessionId est supprimé de la base de données, nous
avons une déconnexion de précision, c’est-à-dire que la déconnexion se produit au moment où
le sessionId est supprimé de la sessionDB.
Inconvénients
-Nécessite une recherche de base de données supplémentaire dans la table sessionId pour
obtenir l’ID utilisateur, les recherches de base de données sont relativement plus lentes que
l’action de décryptage JWT.
-Les serveurs individuels ne peuvent pas être mis à l’échelle séparément car ils devraient
partager la base de données de session.
Approche JWT (JSON Web tokens)
Avantages
Étant donné que l’ID utilisateur est obtenu en déchiffrant le jeton JWT, aucun appel de base de
données n’est requis pour obtenir l’ID utilisateur, donc cette approche est plus rapide.
-Les serveurs peuvent être mis à l’échelle séparément, sans avoir besoin de partager sessionDB.
Cela fait de l’approche JWT une excellente option pour l’architecture de micro-services.
-Le même jeton peut être utilisé pour s’authentifier sur différents serveurs (tant que le serveur a
le access_token_secret), sans avoir besoin de partager sessionDB,
-Cela permet également un serveur d’authentification complètement séparé, qui peut être seul
responsable de l’émission de "accessTokens" et de "refreshTokens".
Inconvénients
-Étant donné que les jetons JWT ne peuvent pas être «invalide» (sans les conserver dans une
base de données partagée), dans l’approche JWT, la précision de la longueur de déconnexion est
définie par la longueur d’expiration du jeton d’accès. Cependant, la durée de vie "access_token"
FS-SFAX
Page 53
ANNEXES
peut être courte (généralement 10 à 15 minutes), de sorte que les jetons sont automatiquement
"invalides" après la durée.
-Surcharge de données :La taille globale d’un JWT est volumineux ce qui le rend plus long
chaque fois que plus de données y sont ajoutées.
Ainsi, si vous ajoutez plus d’informations dans le jeton, cela aura un impact sur la vitesse de
chargement globale et entravera ainsi l’expérience utilisateur.
Cette situation peut être corrigée si les bonnes pratiques de développement sont suivies et que
seulement les données essentielles sont ajoutées au JWT.
A.1.3
Conclusion
La gestion de session dans le projet peut être implémentée soit en utilisant l’approche basée
sur "Session-Cookie" (et est encore utilisée dans de nombreuses applications Web), mais j’ai
choisi l’approche JWT (qui est une approche plus récente et est fréquemment utilisée dans les
applications mobiles et Web ).
FS-SFAX
Page 54
ANNEXES
A.2 Bcrypt : une norme de sécurité cryptographique
A.2.1
Motivation
La technologie évolue rapidement. L’augmentation de la vitesse et de la puissance des
ordinateurs peut profiter à la fois aux ingénieurs qui tentent de créer des systèmes logiciels
et aux attaquants qui tentent de les exploiter. Certains logiciels cryptographiques ne sont pas
conçus pour évoluer avec la puissance de calcul. Comme expliqué précédemment, la sécurité
du mot de passe dépend de la rapidité avec laquelle la fonction de hachage cryptographique
sélectionnée peut calculer le hachage du mot de passe. Une fonction rapide s’exécuterait plus
rapidement lors de l’exécution dans un matériel beaucoup plus puissant.
Ce vecteur d’attaque était bien compris par les cryptographes dans les années 90 et un
algorithme du nom de Bcrypt répondant à ces spécifications de conception a été présenté en
1999 à USENIX. Apprenons comment Bcrypt nous permet de créer des systèmes de stockage
de mots de passe solides.
A.2.2
Qu’est-ce que Bcrypt ?
Bcrypt a été conçu par Niels Provos et David Mazières sur la base du chiffrement Blowfish
cipher[9]
b pour Blowfish et crypt pour le nom de la fonction de hachage utilisée par le système de mot
de passe UNIX.
Crypt est un excellent exemple d’incapacité à s’adapter aux changements technologiques.
Selon USENIX[10], en 1976, crypt pouvait hacher moins de 4 mots de passe par seconde. Étant
donné que les attaquants doivent trouver la pré-image d’un hachage afin de l’inverser, cela a
permis à l’équipe UNIX de se sentir très à l’aise quant à la force de la crypte. Cependant, 20
ans plus tard, un ordinateur rapide avec des logiciels et du matériel optimisés était capable de
hacher 200 000 mots de passe par seconde en utilisant cette fonction !
FS-SFAX
Page 55
ANNEXES
Intrinsèquement, un attaquant pourrait alors mener une attaque complète par dictionnaire
avec une efficacité extrême. Ainsi, une cryptographie qui était exponentielle-ment plus difficile à
casser à mesure que le matériel devenait plus rapide était nécessaire pour entraver les avantages
de vitesse que les attaquants pouvaient obtenir du matériel.
Le chiffrement Blowfish est un chiffrement par bloc rapide sauf en cas de changement de
clés, les paramètres qui établissent la sortie fonctionnelle d’un algorithme cryptographique :
chaque nouvelle clé nécessite le pré-traitement équivalent au chiffrement d’environ 4 kilo-octets
de texte, ce qui est considéré comme très lent par rapport aux autres chiffrements par blocs. Ce
changement de clé lent est bénéfique pour les méthodes de hachage de mot de passe telles
que Bcrypt, car la demande de calcul supplémentaire aide à protéger contre les attaques par
dictionnaire et par brute-force en ralentissant l’attaque.
Bcrypt est capable d’atténuer ces types d’attaques en combinant la phase de configuration
de clé coûteuse de Blowfish avec un nombre variable d’itérations pour augmenter la charge de
travail et la durée des calculs de hachage. son plus grand avantage est que, au fil du temps, le
nombre d’itérations peut être augmenté pour le ralentir, ce qui permet à Bcrypt de s’adapter à la
puissance de calcul. Nous pouvons réduire les avantages que les attaquants peuvent tirer d’un
matériel plus rapide en augmentant le nombre d’itérations pour ralentir Bcrypt .
Bcrypt a été conçu pour le hachage de mot de passe, c’est donc un algorithme lent. C’est
bon pour le hachage de mot de passe car il réduit le nombre de mots de passe par seconde qu’un
attaquant pourrait hacher.
Un autre avantage de Bcrypt est qu’il nécessite un Salt par défaut. Bcrypt vous oblige à
suivre les meilleures pratiques de sécurité car il nécessite un Salt dans le cadre du processus de
hachage. Le hachage combiné avec des salts vous protège contre les attaques de rainbow table !
A.2.3
Comment fonctionne Bcrypt ?
Provos et Mazières, les concepteurs de Bcrypt , ont utilisé la phase de configuration de clé
coûteuse du chiffrement Blowfish pour développer un nouvel algorithme de configuration de
clé pour Blowfish nommé "eksblowfish", qui signifie "expensive key schedule Blowfish".
FS-SFAX
Page 56
ANNEXES
Qu’est-ce que la "configuration de la clé" ? Selon Ian Howson, ingénieur logiciel chez
NVIDIA : "La plupart des chiffrements consistent en une phase de configuration de clé et
une phase de fonctionnement. Lors de la configuration de la clé, l’état interne est initialisé.
Pendant le fonctionnement, le texte chiffré ou le texte en clair d’entrée est chiffré ou déchiffré.
Configuration de la clé uniquement doit être effectué une fois pour chaque clé utilisée".
Bcrypt s’exécute en deux phases :
Dans la première phase, EksBlowfishSetup est appelé avec le coût, le salt et le mot de passe,
pour initialiser l’état d’eksblowfish. La majeure partie du temps de Bcrypt est consacrée à la
planification coûteuse des clés. Ensuite, la valeur 192 bits “OrpheanBeholderScryDoubt” est
chiffrée 64 fois en utilisant eksblowfish en mode ECB avec l’état de la phase précédente. La
sortie est le coût et le sel 128 bits concaténés avec le résultat de la boucle de chiffrement.
F IGURE A.3 – Algorithme de Bcrypt
Le hachage résultant est préfixé par $2a$, $2y$ ou $2b$. Les préfixes sont ajoutés pour
indiquer l’utilisation de Bcrypt et sa version.
Le résultat de Bcrypt atteint les propriétés de base d’une fonction de mot de passe sécurisée
telles que définies par ses concepteurs :
Il est résistant aux pré-images. -Le Salt est suffisamment grand pour atténuer les attaques de
pré-calcul, telles que les tables arc-en-ciel. -Il a un coût adaptable. Les concepteurs de Bcrypt
FS-SFAX
Page 57
ANNEXES
pensent que la fonction conservera sa force et sa valeur pendant de nombreuses années. Sa
conception mathématique rassure les cryptographes sur sa résistance aux attaques.
En ce qui concerne le coût adaptable, nous pourrions dire que Bcrypt est une fonction de
hachage adaptative car nous sommes en mesure d’augmenter le nombre d’itérations effectuées
en fonction d’un facteur clé passé, le coût. Cette adaptabilité est ce qui nous permet de compenser
l’augmentation de la puissance des ordinateurs, et c’est pourquoi on a choisit de l’utiliser pour
hacher les mot de passe. [12][13][14]
FS-SFAX
Page 58
C ONCEPTION ET RÉALISATION D ’ UNE APPLICATION W EB POUR LA G ESTION DE
R ECRUTEMENT
Raddaoui Yassine
Résumé :
Dans le cadre de stage de fin d’études, au sein de la Compagnie des phosphates de Gafsa (CPG),
ce rapport présente la conception et le développement d’une application web pour la gestion de
recrutement. Ce projet vise à automatiser le processus de recrutements au sein de la CPG.
Mots clés : recrutement, application web, Spring boot , Angular
Abstract :
As part of the end-of-studies internship, within the Compagnie des phosphates de Gafsa (CPG),
this report presents the design and development of a web application for recruitment management.
This project aims to automate the recruitment process within the CPG.
Mots clés : recruitment, Web application, Spring boot , Angular
:
‘jÊÓ
®¯ A®‚¯ é»Qå
ú¯ ÉÒªËAK ð ,h QjJË@ ¨ðQå„Ó PA£@ ú¯
QK ñ¢ð ÕæҒ QK Q® JË@ @ Yë QªK é’
. .
„Ë@ Ég@X ­J£ñJË@ éJ ÊÔ« éJÖß @ úÍ@ ¨ðQå„ÖÏ @ @ Yë ¬YîE . ­J£ñJË@ èP@XB IK ð ‡J J¢
. é»Qå
.
.
Angular , Spring boot , I
. K ð ‡JJ.¢ , ­J£ñK : iJKA®ÖÏ @