Rapportlaouinisarrapfevf 180628200603

Code : 353 Année Universitaire : 2016 / 2017
Université de la Manouba
École Supérieure d’Économie Numérique
Rapport
de Projet de Fin d'Études
Présenté en vue de l'obtention du Diplôme de

Mastère professionnel en Modélisation, Bases de Données
et Intégration des Systèmes
Sujet
Modélisation et Dématérialisation des Processus

Métier (BPM) de GRH Administrative
Élaboré par :
Sarra LAOUINI
Organisme d'accueil
Encadré par
ESEN M. Chiheb BEN NSIR

Société Mlle Siwar GUEMRI
Dédicaces
A l’âme de mon cher père Mohamed Ali
Parce que sans toi, je n’arriverai pas à avoir ce que j’ai, je te porterais à jamais dans mon cœur
et dans mon esprit, tes mots resteront éternellement dans ma mémoire écrite. Que Dieu, le
tout puissant, puisse t’avoir dans sa sainte miséricorde.
A celle qui m'a porté dans son ventre neuf mois
Et à qui continue de le faire chaque jour, à celle qui est restée éveillée alors que moi je dormais,
à celle sans qui je ne serais pas là, et à qui je dois tout ceci, à celle qui ne m’a jamais privé de
son amour ni de son attention, même lorsque j’étais loin de les mériter. A ma bien-aimée
Latifa tout ce que j'ai fait, c'est grâce à toi et pour toi.
A ma petite sœur Chaima
Avec qui je partage une joie de vivre et une harmonie paisible qui illumine mes journées.
A mes très chers oncles Mounir, Mouhamed, Hechmi, Sadok et Allala
Aucune dédicace ne saurait exprimer l’amour, l’estime, le dévouement et le respect que j’ai
toujours eu pour vous.
A toute mon adorable famille
Pour leur patience et leur soutien qu’ils n’ont cessés d’apporter au cours de ma formation et
pour ses aident à franchir les épreuves difficiles.
A tous mes meilleur(e)s ami(e)s
Pour tous les moments inoubliables que nous avons passés ensemble. J’espère que notre amitié
durera éternellement.
SARRA
i
Remerciements
Je remercie tout d'abord Dieu tout puissant de m'avoir donné l'ardeur, l'énergie et la patience
d'achever ce modeste travail.
Je tiens à exprimer ma gratitude aux membres du jury pour l'honneur qu'ils m'ont fait d'accepter
de juger mon travail.
Je tiens à présenter mes reconnaissances et mes remerciements les plus sincères à mon
encadrant à l’École Supérieure d’Économie Numérique, Monsieur Chiheb BEN NSIR pour le
temps consacré à la lecture et aux réunions qui ont rythmé les différentes étapes de mon projet.
Les discussions que nous avons partagées m’ont permis, non seulement d’orienter mon travail
d’une manière pertinente mais aussi de garder le bon moral tout au long du stage. Je le remercie
pour sa suivie journalière par le journal PFE, aussi pour sa disponibilité à encadrer ce travail à
travers ses critiques et ses recommandations
Je remercie aussi Monsieur Jameleddine El KAMEL, le directeur de l'entreprise BNS

Engineering, qui a veillé à ce que les conditions de travail soient optimales, pour son temps
généreusement donné et sans qui ce travail n'aurait pas vu le jour.
Je tiens également à remercier Madame Siwar GUEMRI, pour avoir assuré l'encadrement de
ce travail et pour ses qualités humaines et professionnelles et son aide précieuse.
Je tiens à remercier aussi M Sami BEN HAMOUDA, pour son encadrement, pour ses conseils
qui m'ont été utiles et pour sa disponibilité durant la période de stage de fin d'études.
J'adresse mes sincères remerciements à mes collègues de travail Issa BEN MANSOUR,
Oussama AYARI et LAHMEDI Sawssen qui m'ont apporté leur support moral et intellectuel
et avec lesquels j'ai pu développer mon esprit d'équipe, mon organisation dans le travail ainsi
que mon professionnalisme.
Finalement, toutes mes gratitudes s’adressent et à tous ceux qui ont contribué de près ou de loin
pour je puisse mener à bien ma formation de mastère, à leur tête mes parents, mes professeurs
et mes amis et particulièrement l’équipe administrative et mes enseignants à l’École Supérieure
d’Économie Numérique.
ii
Table des matières
Introduction générale............................................................................................................................... 1
Chapitre 1 ................................................................................................................................................ 3
Étude de projet......................................................................................................................................... 3
Introduction ......................................................................................................................................... 4
1. Présentation de l’organisme d’accueil ......................................................................................... 4
1.1. Fiche d’identité de BNS ENGINEERING .......................................................................... 4
1.2. Activités de BNS ENGINEERING ..................................................................................... 5
2. Présentation du projet .................................................................................................................. 5
2.1. Cadre du projet .................................................................................................................... 5
2.2. Etude de l’existant ............................................................................................................... 6
2.3. Solution à proposer .............................................................................................................. 8
3. Choix de la méthodologie de développement............................................................................ 10
3.1. La méthodologie de Travail Scrum ................................................................................... 10
3.2. Les langages de modélisation ............................................................................................ 12
3.3. Environnement de travail .................................................................................................. 13
Conclusion ......................................................................................................................................... 15
Chapitre 2 .............................................................................................................................................. 16
Planification et architecture ................................................................................................................... 16
Introduction ....................................................................................................................................... 17
1. Recueil des besoins ................................................................................................................... 17
1.1. Identification des acteurs ................................................................................................... 17
1.2. Les besoins fonctionnels.................................................................................................... 19
1.3. Les besoins non fonctionnels............................................................................................. 20
1.4. Diagramme de cas d’utilisation globale ............................................................................ 21
2. Prototypage des interfaces ......................................................................................................... 22
3. Pilotage du projet avec Scrum ................................................................................................... 25
2.1. Technique utilisée.............................................................................................................. 25
2.2. Répartition des rôles .......................................................................................................... 25
2.3. Backlog du produit ............................................................................................................ 25
2.4. Planification des sprints ..................................................................................................... 27
4. Choix Architectural ................................................................................................................... 28
4.1. Architecture applicative..................................................................................................... 28
iii
4.2. Architecture technique....................................................................................................... 29
Conclusion ......................................................................................................................................... 29
Chapitre 3 .............................................................................................................................................. 30
Sprint 1 - Les missions principales de GRH ......................................................................................... 30
Introduction ....................................................................................................................................... 31
1. Backlog du sprint....................................................................................................................... 31
2. Capture des besoins ................................................................................................................... 33
2.1. Diagramme de cas d'utilisation du Sprint 1 ....................................................................... 33
2.2. Raffinement des cas d’utilisation ...................................................................................... 34
2.3. Descriptions textuelles des cas d’utilisation ...................................................................... 40
3. Analyse ...................................................................................................................................... 45
3.1. Diagrammes de séquence systèmes ................................................................................... 45
3.2. Diagrammes des classes participantes ............................................................................... 48
4. Conception................................................................................................................................. 50
4.1. Diagrammes de séquences détaillés .................................................................................. 50
4.2. Diagramme de classes du sprint 1 ..................................................................................... 52
5. Implémentation .......................................................................................................................... 52
5.1. La génération de la BD plus le dictionnaire de données ................................................... 52
5.2. Diagramme de composants................................................................................................ 57
5.3. Les interfaces du Sprint 1 .................................................................................................. 57
6. Test ............................................................................................................................................ 60
6.1. Tests de validation ............................................................................................................. 60
6.2. Test unitaires ..................................................................................................................... 61
Conclusion ......................................................................................................................................... 62
Chapitre 4 .............................................................................................................................................. 63
Sprint 2 – Gestion du recrutement ......................................................................................................... 63
Introduction ....................................................................................................................................... 64
3. Analyse ...................................................................................................................................... 71
iv
4. Conception................................................................................................................................. 74
4.1. Diagrammes de BPMN 2.0................................................................................................ 75
4.2. Diagrammes de séquences détaillés .................................................................................. 77
4.3. Diagramme de classes du sprint 2 ..................................................................................... 78
5. Implémentation .......................................................................................................................... 78
5.1. La génération de la BD plus le dictionnaire des données .................................................. 79
5.2. Diagramme de composants................................................................................................ 82
5.3. Les interfaces du Sprint 2 .................................................................................................. 83
6. Test ............................................................................................................................................ 85
6.1. Tests de validation ............................................................................................................. 86
6.2. Test unitaires ..................................................................................................................... 86
Conclusion ......................................................................................................................................... 88
Chapitre 5 .............................................................................................................................................. 89
Sprint 3 – Les flux de ............................................................................................................................ 89
travaux RH ............................................................................................................................................ 89
Introduction ....................................................................................................................................... 90
3. Analyse ...................................................................................................................................... 97
4. Conception................................................................................................................................. 99
4.1. Diagrammes de BPMN 2.0................................................................................................ 99
4.2. Diagrammes de séquences détaillés ................................................................................ 103
4.3. Diagramme de classes du sprint 3 ................................................................................... 104
5. Implémentation ........................................................................................................................ 104
5.1. La génération de la BD plus le dictionnaire de données ................................................. 105
5.2. Diagramme de composants.............................................................................................. 109
5.3. Les interfaces du Sprint 3 ................................................................................................ 110
6. Test .......................................................................................................................................... 112
v
6.1. Tests de validation ........................................................................................................... 112
6.2. Test unitaires ................................................................................................................... 113
Conclusion ....................................................................................................................................... 114
Conclusion et Perspectives .................................................................................................................. 115
Annexe A : Passage du diagramme de classes UML au modèle relationnel ....................................... 116
Bibliographie et webographie.............................................................................................................. 118
vi
Liste des figures
Figure 1 FICHE D'IDENTITE DE BNS .......................................................................................................... 4
Figure 2 Interface demande de congé dans l'Odoo ................................................................................ 6
Figure 3 Exemple d'interface Du PGI SAP ................................................................................................ 7
Figure 4 Diagramme de cas d'utilisation globale .................................................................................. 22
Figure 5 Interface d'authentification..................................................................................................... 23
Figure 6 Interface principale du module RH.......................................................................................... 23
Figure 7 Interface affectation contrat ................................................................................................... 23
Figure 8 Interface Gestion des employés .............................................................................................. 24
Figure 9 Interface d'ajout d'employé .................................................................................................... 24
Figure 10 Interface liste congés............................................................................................................. 24
Figure 11 PLANIFICATION DES SPRINTS ................................................................................................ 27
Figure 12 Le modèle REST [31] .............................................................................................................. 28
Figure 13 Schéma de l'architecture 3-tierces adoptée ......................................................................... 29
Figure 14 DIAGRAMME DE CAS D'UTILISATION DU SPRINT 1 ............................................................... 34
Figure 15 DIAGRAMME DE CAS D'UTILISATION "Gérer employé" ........................................................ 35
Figure 16 DIAGRAMME DE CAS D'UTILISATION "Gérer les enfants" .................................................... 35
Figure 17 DIAGRAMME DE CAS D'UTILISATION "Gérer les pièces jointes"........................................... 36
Figure 18 DIAGRAMME DE CAS D'UTILISATION "Gérer les services" .................................................... 36
Figure 19 DIAGRAMME DE CAS D'UTILISATION "Gérer les département " .......................................... 37
Figure 20 DIAGRAMME DE CAS D'UTILISATION "Gérer les postes" ...................................................... 37
Figure 21 DIAGRAMME DE CAS D'UTILISATION "Gérer les carrières" .................................................. 37
Figure 22 DIAGRAMME DE CAS D'UTILISATION "Gérer les contrats" ................................................... 38
Figure 23 DIAGRAMME DE CAS D'UTILISATION "Gérer les avancements" ........................................... 38
Figure 24 DIAGRAMME DE CAS D'UTILISATION "Gérer les affaires administratives" ........................... 39
Figure 25 DIAGRAMME DE CAS D'UTILISATION "Gérer les utilisateurs"............................................... 39
Figure 26 DIAGRAMME DE CAS D'UTILISATION "Gérer les rôles" ........................................................ 39
Figure 27 DIAGRAMME DE SEQUENCES SYSTEME DU CAS "S'AUTHENTIFIER" .................................... 45
Figure 28 DIAGRAMME DE SEQUENCES SYSTEME DU CAS "AJOUTER EMPLOYE"................................ 46
Figure 29 DIAGRAMME DE SEQUENCE SYSTEME DU CAS " LISTER LES UTILISATEURS " ...................... 46
Figure 30 DIAGRAMME DE SEQUENCE SYSTEME DU CAS "MODIFIER EMPLOYE" ................................ 47
Figure 31 DIAGRAMME DE SEQUENCE SYSTEME DU CAS "CONSULTER LES DETAILS D'UN EMPLOYE" 47
Figure 32 DIAGRAMME DE SEQUENCE SYSTEME DU CAS " SUPPRIMER UTILISATEUR" ....................... 48
Figure 33 DIAGRAMME DE CLASSES PARTICIPANTES DU MODULE "Gérer employé" .......................... 49
Figure 34 DIAGRAMME DE CLASSES PARTICIPANTES DU MODULE "Gérer contrat" ............................ 49
Figure 35 DIAGRAMME DE CLASSES PARTICIPANTES DU MODULE "Gérer utilisateur" ....................... 50
Figure 36 DIAGRAMME DE SEQUENCE OBJET DU CAS " S'authentifier " .............................................. 51
Figure 37 DIAGRAMME DE CLASSE DU SPRINT 1 .................................................................................. 52
Figure 38 Diagramme de composants du cas d’utilisation « Gérer employé » .................................... 57
Figure 39 Interface d’authentification .................................................................................................. 58
Figure 40 Interface ajouter employé ..................................................................................................... 58
Figure 41 Interfaces la listes des employés ........................................................................................... 59
Figure 42 Interface de suppression d’un employé ................................................................................ 59
vii
Figure 43 Interface d’ajout d’un contrat ............................................................................................... 60
Figure 44 Interface de la Lister des utilisateurs .................................................................................... 60
Figure 45 code Ajouter Poste ................................................................................................................ 61
Figure 46 Ajouter une poste avec POST ................................................................................................ 62
Figure 47 code d’afficher tous les postes .............................................................................................. 62
Figure 48 Lister tous les poste avec GET ............................................................................................... 62
Figure 50 DIAGRAMME DE CAS D'UTILISATION "Gérer les candidats" ................................................. 66
Figure 51 DIAGRAMME DE CAS D'UTILISATION " Gérer les postes à pourvoir "................................... 66
Figure 52 DIAGRAMME DE CAS D'UTILISATION " Gérer les offres d'emploi " ...................................... 67
Figure 53 DIAGRAMME DE CAS D'UTILISATION " Gérer les demandes de stage " ............................... 67
Figure 54 DIAGRAMME DE CAS D'UTILISATION " Traiter les demandes de stages " ............................ 68
Figure 55 DIAGRAMME DE CAS D'UTILISATION " Gérer les demandes d'emploi " ............................... 68
Figure 56 DIAGRAMME DE CAS D'UTILISATION " Traiter les demandes de stages " ............................ 68
Figure 57 DIAGRAMME DE SEQUENCE SYSTEME DU CAS " Ajouter demande de stage " .................... 72
Figure 58 DIAGRAMME DE SEQUENCE SYSTEME DU CAS " Consulter tableau de bord "..................... 72
Figure 59 DIAGRAMME DE SEQUENCE SYSTEME DU CAS " Traiter demande d'emploi " ..................... 73
Figure 60 DIAGRAMME DE CLASSES PARTICIPANTES DU MODULE "Gérer candidat" .......................... 74
Figure 61 DIAGRAMME DE CLASSES PARTICIPANTES DU MODULE "Traiter demande d'emploi" ........ 74
Figure 62 Diagramme de BPMN 2.0 de la demande de stage ............................................................... 75
Figure 63 Diagramme de BPMN 2.0 de la demande d'emploi .............................................................. 76
Figure 64 DIAGRAMME DE SEQUENCE OBJET DU CAS " Traiter demande d’emploi " ......................... 77
Figure 65 DIAGRAMME DE CLASSE DU SPRINT 2 .................................................................................. 78
Figure 66 Diagramme de composants du cas d’utilisation « Gérer candidat » .................................... 83
Figure 67 Interface Ajouter Candidat .................................................................................................... 84
Figure 68 Interface La liste des candidats ............................................................................................. 84
Figure 69 Interface d’Ajouter offre de recrutement ............................................................................. 85
Figure 70 Interface de modifier demande d'emploi ............................................................................. 85
Figure 71 méthode d'ajouter demande stage ....................................................................................... 86
Figure 72 l'ajoute d’une demande de stage .......................................................................................... 87
Figure 73 code GET les demandes de stage .......................................................................................... 87
Figure 74 L'affichage du résultat du méthode GET ............................................................................... 88
Figure 76 DIAGRAMME DE CAS D'UTILISATION "Gérer les absences" .................................................. 92
Figure 77 DIAGRAMME DE CAS D'UTILISATION "Gérer les demandes d'absence"............................... 92
Figure 78 DIAGRAMME DE CAS D'UTILISATION " Traiter les demandes d’absence " ........................... 93
Figure 79 DIAGRAMME DE CAS D'UTILISATION " Gérer les demandes de congé " .............................. 93
Figure 80 DIAGRAMME DE CAS D'UTILISATION " Traiter la demandes de congé " .............................. 94
Figure 81 DIAGRAMME DE CAS D'UTILISATION " Gérer les formations " ............................................. 94
Figure 82 DIAGRAMME DE CAS D'UTILISATION " Gérer les demandes de formation " ........................ 95
Figure 83 DIAGRAMME DE CAS D'UTILISATION " Traiter les demandes de formation " ...................... 95
Figure 84 DIAGRAMME DE SEQUENCE SYSTEME DU CAS " Établir un état d’absence "....................... 97
Figure 85 DIAGRAMME DE SEQUENCE SYSTEME DU CAS " Traiter la demande de congé " ................ 98
Figure 86 DIAGRAMME DE CLASSES PARTICIPANTES DU MODULE "Traiter demande de congé" ....... 99
Figure 87 Diagramme de BPMN 2.0 de la demande de congé............................................................ 100
viii
Figure 88 Diagramme de BPMN 2.0 de la demande d'absence .......................................................... 101
Figure 89 Diagramme de BPMN 2.0 de la demande de formation ..................................................... 102
Figure 90 DIAGRAMME DE SEQUENCE OBJET DU CAS " Ajouter demande de congé " ...................... 103
Figure 91 DIAGRAMME DE CLASSE DU SPRINT 3 ................................................................................ 104
Figure 92 Diagramme de composants du cas d’utilisation « Gérer les demandes de congé » ........... 109
Figure 93 Interface d'établir un état d'absence .................................................................................. 110
Figure 94 Interface d'ajouter une demande de congé ........................................................................ 110
Figure 95 Interface le tableau de bord ................................................................................................ 111
Figure 96 Interface traiter demande congé 1 ..................................................................................... 111
Figure 97 Interface Traiter demande congé 2 ..................................................................................... 112
Figure 98 Code traiter demande ......................................................................................................... 113
Figure 99 Traiter décision .................................................................................................................... 113
Figure 100 le résultat d'affecter l'observation à une demande .......................................................... 114
Figure 101 Règle de passage d’une classe et id .................................................................................. 116
Figure 102 Les associations ................................................................................................................. 116
Figure 103 Association de type N :M .................................................................................................. 116
Figure 104 Association de type 1 : N ................................................................................................... 117
Figure 105 Association de type 1 : 1.................................................................................................... 117
Figure 106 Héritage ............................................................................................................................. 117
ix
Liste des Tableaux
Tableau 1 Tableau d'identification des acteurs..................................................................................... 17
Tableau 2 BACKLOG DU PRODUIT ......................................................................................................... 25
Tableau 3 BACKLOG DU SPRINT 1 ......................................................................................................... 31
Tableau 4 Description textuelle du cas « S’authentifier » .................................................................... 40
Tableau 5 Description textuelle du cas « Ajouter employé » ............................................................... 40
Tableau 6 Description textuelle du cas « Affecter enfant à l’employé » .............................................. 41
Tableau 7 Description textuelle du cas « Lister les contrats » .............................................................. 42
Tableau 8 Description textuelle du cas « Consulter les détails d’un employé » ................................... 42
Tableau 9 Description textuelle du cas « Modifier avancement » ........................................................ 43
Tableau 10 Description textuelle du cas « Supprimer utilisateur » ...................................................... 44
Tableau 11 Description textuelle du cas « Rechercher employé » ....................................................... 44
Tableau 12 Table "employé " ................................................................................................................ 53
Tableau 13 Table « Contrat » ................................................................................................................ 54
Tableau 14 Table « Département » ....................................................................................................... 54
Tableau 15 Table « Poste ».................................................................................................................... 54
Tableau 16 Table « Avancement » ........................................................................................................ 54
Tableau 17 Table « Enfant » .................................................................................................................. 55
Tableau 18 Table « Pièce jointe employé » ........................................................................................... 55
Tableau 19Table « Type_pièce_jointe »................................................................................................ 55
Tableau 20 Table « Gouvernorat » ........................................................................................................ 56
Tableau 21 Table « Utilisateur »............................................................................................................ 56
Tableau 22 Table « Rôle » ..................................................................................................................... 56
Tableau 23 Table « Autority » ............................................................................................................... 56
Tableau 24 résultats du test .................................................................................................................. 61
Tableau 25 BACKLOG DU SPRINT 2 ....................................................................................................... 64
Tableau 26 Description textuelle du cas « Ajouter demande de stage ».............................................. 69
Tableau 27 Description textuelle du cas « Modifier demande d'emploi » ........................................... 69
Tableau 28 Description textuelle du cas « Consulter le tableau de bord » .......................................... 70
Tableau 29 Description textuelle du cas « Traiter demande d’emploi » .............................................. 71
Tableau 30 Table "candidat " ................................................................................................................ 79
Tableau 31 Table pièce jointe candidat................................................................................................. 79
Tableau 32 Table type pièce jointe ....................................................................................................... 79
Tableau 33 Table demande stage.......................................................................................................... 80
Tableau 34 Table Historique stage ........................................................................................................ 80
Tableau 35 Table Demande_emploi...................................................................................................... 80
Tableau 36 Table Historique_emploi .................................................................................................... 81
Tableau 37 Table Offre_emploi ............................................................................................................. 81
Tableau 38 Table poste_pouvoir ........................................................................................................... 82
Tableau 39 Table poste ......................................................................................................................... 82
Tableau 40 Table département ............................................................................................................. 82
Tableau 41 résultats du test .................................................................................................................. 86
Tableau 43 BACKLOG DU SPRINT 3 ....................................................................................................... 90
x
Tableau 44 Description textuelle du cas « Établir un état d’absence » ................................................ 95
Tableau 45 Description textuelle du cas « Traiter la demande de congé » .......................................... 96
Tableau 46 Table Historique_conge .................................................................................................... 105
Tableau 47 Table demande_conge ..................................................................................................... 105
Tableau 48 Table pièce_jointe ............................................................................................................ 106
Tableau 49 Table Absence ................................................................................................................... 106
Tableau 50 Table demande_absence .................................................................................................. 106
Tableau 51 Table Historique_absence ................................................................................................ 107
Tableau 52 Table demande_formation ............................................................................................... 107
Tableau 53 Table formation ................................................................................................................ 108
Tableau 54 Table Historique_formation ............................................................................................. 108
Tableau 55 résultats du test ................................................................................................................ 112
xi
Liste des acronymes
API : Application Programming Interface. En français « Interface de Programmation
Applicative »
AVD : Avis de la Direction et annotation
BPM : Business Process Management, que l'on peut traduire en français « gestion des
processus métiers »
DARH : Directeur de l’Administration et des Ressources Humaines
ERP : Enterprise Ressource Planning
GED : Gestion Electronique des Documents
GRH : Gestion des Ressources Humaines
IHM : Interface homme-machine
PGI : Progiciel de Gestion Intégré
PME : Petites et Moyennes Entreprises
RH : Ressources Humaines
xii
Introduction générale
Nous vivons l’époque de la transformation digitale des entreprises. Ces transitions numériques
sont vitales pour garder la compétitivité, l’efficacité et la pérennité de l’entreprise.
Pourtant la révolution numérique est en marche, il y apparaît cependant que beaucoup

d'entreprises sont peu ou mal organisées dans l'accompagnement de cette transformation. Il est
donc indispensable pour l’entreprise d’envisager une transformation profonde de son
organisation, de ses processus, de sa culture, de son système et des compétences attendues.
C’est pour cette raison, les entreprises cherchent à informatiser leurs services en termes de
gestion des flux, de dématérialisation des procédures, et de digitalisation des processus métier
associés en raison des bénéfices multiples qu’elle confère : l’optimisation des fonctionnements,
la réduction des coûts, le gain de temps, les gains de productivité, etc.
Particulièrement, le rôle des ressources humaine au cœur de l’organisation dans le cadre de

cette transition numérique est fondamentale car la révolution numérique touche les
compétences managériales, la structure de l’entreprise, son organisation et ses processus
métiers. Les RH doivent vivre cette révolution, mais surtout savoir l’accompagner sans créer
d’inégalités dans l’entreprise. Donc il est nécessaire de veiller à ce que l’ensemble du personnel
puisse acquérir de nouvelles compétences, ainsi de favoriser un nouveau modèle d’organisation
interne.
Dans ce contexte et dans le cadre de notre projet de fin d’études nous allons développer un
système de gestion des ressources humaines qui s’intégrera avec d’autre modules dans un ERP
adapté nativement au contexte des entreprises tunisiennes. Notre solution vise à gérer
et dématérialiser les processus métier de la GRH tel que les employés, les contrats, le
recrutement, les demandes établies dans l’entreprise.
Le présent rapport décrit les différentes étapes de la réalisation de cette solution durant la
période de stage. De ce fait, ce rapport comporte cinq chapitres :
Le premier chapitre « Étude de projet » sera réserver pour le contexte général du projet à
travers la présentation de l’organisme d’accueil ainsi que l’étude de l’existant et la
méthodologie du travail adoptée.
Le second chapitre « Planification et architecture » appelé aussi sprint 0, portera sur

l’identification des besoins, le prototypage des interfaces graphiques pour mettre notre
1
application dans son contexte, ensuite nous découpons notre projet en fonctionnalités, puis la
planification des sprints à réaliser et finalement l’architecture utilisée.
Le troisième chapitre « Sprint 1- les mission principales de GRH » présente les étapes de la
réalisation du premier sprint de ce projet.
Le quatrième chapitre « Sprint 2- Gestion du recrutement » est dédié à la présentation du

deuxième sprint de notre projet en respectant les principes fondamentaux de Scrum.
Le dernier chapitre « Sprint 3- les flux de travaux RH » sera consacré pour le développement
du troisième sprint toujours en respectant les principes fondamentaux de Scrum.
2
Chapitre 1
Étude de projet
Chapitre 1 Étude de projet
Introduction
L’étude du projet est une étape primordiale pour la connaissance de l’environnement dans
laquelle s’est déroulé le stage de fin d’études ainsi que la présentation du projet. Ce chapitre
sera consacré tout d’abord à la présentation de l’entreprise BNS Engineering au sein de laquelle
j’ai effectué mon projet.
Et par la suite une présentation de contexte général du projet que m’a confié BNS Engineering
comme projet de fin d’études. Cette présentation inclura une étude de l’existant, la
problématique de projet, et la solution que j’ai proposé, aussi bien le choix de la méthodologie
de développement que je vais suivre pour la réalisation de ce projet.
1. Présentation de l’organisme d’accueil

[1]
BNS ENGINEERING est une Société à Responsabilité Limitée (SARL). Fondée en 2010,
elle dispose une forte expertise et un savoir-faire qui sont développés au fil des années, reconnus
sur le marché national et international, BNS ENGINEERING accorde une haute importance à
la maitrise totale des processus métier et le développement de connaissances spécialisées afin
d’aboutir à des solutions à haute valeur ajoutée.
BNS ne cesse de s’affirmer sur les marchés tunisiens et africains comme un acteur de référence
dans le monde des solutions à haute valeur ajoutée (ERP Métiers, e-Finance, e-Government),
des progiciels du marché financier, des prestations de conception et de développement et de
conseil en organisation et ingénierie des systèmes d’Information.
1.1. Fiche d’identité de BNS ENGINEERING
Figure 1 FICHE D'IDENTITE DE BNS
4
1.2. Activités de BNS ENGINEERING

Ses pôles d’activité s’articulent autour des domaines métiers :
▪ L’Administration (dématérialisation des formalités administratives).
▪ Finances : marché financier (la Bourse, les intermédiaires en bourse, les sociétés de
gestion) les Banques (services Titre).
▪ Commerce et Distribution : Dématérialisation des processus métiers, Systèmes
d’information de Gestion (ERP), portails d’entreprise.
▪ Ingénierie et Solutions Métiers : Agriculture, Météorologie, Environnement.
BNS ENGINEERING a participé à la réussite de plusieurs projets informatiques en Tunisie et

en Afrique. Outre son activité sur le marché local, BNS ENGINEERING dispose d’une offre
d’externalisation de services informatiques à forte valeur ajoutée conformes aux standards de
qualité et aux exigences du marché international. C’est grâce à ces valeurs que BNS a pu gagner
la confiance de partenaires stratégiques en Afrique. [1]
2. Présentation du projet
La transition numérique pour les employés de l’entreprise en mettant à leur disposition les outils
et les moyens nécessaires à cette transformation digitale est devenue nécessaire pour pouvoir
accompagner le développement technologique dans le monde. C’est dans ce contexte s'inscrit
notre projet dans le cadre de la réalisation d’un stage de fin d’études et dont le titre est «
Modélisation et Dématérialisation des Processus Métier (BPM) de GRH_ADMINISTRATIVE
» qui vise à développer un module de gestion de la ressource humaine administrative. Il vient à
conclure ma formation de Mastère professionnel en Modélisation, Bases de Données et
Intégration des Systèmes à l’Ecole Supérieure d’Economie Numérique et a été réaliser au sein
de la société BNS ENGINEERING.
2.1. Cadre du projet

Le module de ressources humaines sera intégré avec les autres modules qui doivent être
développés au sein la société BNS telle que le module de paie, de comptabilité, de trésorerie,
de vente, d'achat, d’administration et de configuration, composantes nativement intégrées pour
construire un ERP spécifiques aux entreprises tunisiennes avec une base de données unique afin
d’assurer la cohérence entre les différents services de l’entreprise.
5
2.2. Etude de l’existant

L’étape de l'étude des solutions existantes est essentielle pour la mise en œuvre de tout projet
informatique ou autre, et qui permet d’éplucher les fonctionnalités déjà développées et surtout
d’identifier leurs différentes lacunes. Dans cette section, nous allons procéder tout d'abord par
faire le tour des différents aspects liés à l’état de l’art en matière de RH. Nous présentons une
brève description dédiée à la GRH des modules proposés par la communauté Odoo, par le
progiciel SAP et par le logiciel SaaS. Ensuite, nous extrairons les problématiques.
2.2.1. La plateforme OpenERP/Odoo

L’Odoo est la plus populaire des solutions Open Source des ERP, destinée aux PME, qui permet
de gérer la plupart des aspects fonctionnels d'une entreprise telle que la gestion de la
comptabilité, de la paie, de la ressource humaine, etc. S'inscrivant dans la lignée des logiciels
libres générant des profits, la solution est gratuite à la base, mais tout support ou service est
facturé et nécessite l'intervention de l'éditeur. En plus, la migration de données, lors du passage
d'une version à une autre, nécessite forcément la souscription d’un contrat de support. Le
module GRH, proposé par la communauté Odoo, est très limité fonctionnellement et nécessite
beaucoup de développement pour l’adapter au contexte national. Sa couverture fonctionnelle
est réduite aux fonctions suivantes :
▪ La gestion des contrats
▪ La gestion des congés
▪ La gestion des personnels
▪ La gestion des feuilles de présence.
Cette figure représente une capture d’écran de l’Interface demande de congé dans l'Odoo.
Figure 2 Interface demande de congé dans l'Odoo
6
2.2.2. La plateforme SAP

SAP appartient à la famille des ERP propriétaires. C’est un système dans lequel les différentes
fonctions de l'entreprise sont corrélées entre elles à travers l'utilisation d'un système
d'information centralisé sur la base d'une configuration client/serveur. Et parmi les
fonctionnalités offertes par cet ERP, nous allons citer :
▪ Chaîne logistique
▪ Commerce
▪ Développement durable
▪ Externalisation et approvisionnement
▪ Gestion financière
▪ Gestion des actifs
▪ Marketing
▪ Ressources humaines [2]
Dans ce cadre le module gestion des ressources humaines permet de :
▪ Gérer chaque employé d'un point de vue administratif

▪ Gérer les recrutements, suivre tout le recrutement dans sa durée de vie
▪ Gérer les évolutions du personnel
▪ Gérer les paies, les frais de déplacements
▪ Gérer les formations, etc.
Cette figure représente une capture d’écran d'interface Du PGI SAP.
Figure 3 Exemple d'interface Du PGI SAP
7
2.2.3. Critique de l’existant

La critique constitue une étape essentielle, pour porter un jugement objectif afin de découvrir
les insuffisances rencontrées lors de l'étude des solutions existantes.
Au vu de ce que nous avons vu, les solutions citées auparavant ont fait preuve d’efficacité mais
ils ont certaines défaillances qui se manifestent par leur complexité et leur rigidité associées à
leur lourdeur de mise en œuvre et d’exploitation, ainsi que les entreprises tunisiennes se
retrouvaient face à des problèmes liés au coûts, à l'adaptation selon leurs besoins et à
l'intégration entre les différentes applications informatiques.
2.3. Solution à proposer
Dans le but d’atténuer les problèmes cités dans la section précédente la solution consiste à
développer un module de gestion administrative des ressources humaines, spécifique aux
besoins des entreprises tunisiennes, bâti sur un socle technologique ouvert facilitant la
dématérialisation totale de l’ensemble des processus de ce domaine. Ce module fera partie des
modules d'un ERP en cours de réalisation au sein de la société BNS ENGINEERING. Le projet
s’est déroulé en deux étapes :
▪ Dans la première étape, il s’agit d’étudier, d’analyser, de normaliser puis de modéliser

en BPMN 2.0, les processus relatifs à la gestion administrative et de la carrière dans une
entreprise cliente sélectionnée par BNS ENGINEERING.
▪ La seconde étape consiste à dématérialiser totalement les processus « Zéro papier ».
De ce fait, notre solution doit être bâtie sur une architecture qui offre un PGI pouvant généraliser
et industrialiser les intégrations, les maintenances et les évolutions du périmètre fonctionnel des
entreprises. Ce module du PGI sera capable de gérer toutes les fonctions standards de gestion
administrative des ressources humaines d’une entreprise tunisienne, et elle assurera plusieurs
interfaces accessibles par les utilisateurs, chacun suivant son profil et ses droits d’accès.
2.3.1. Concepts liés à la solution à proposer

Nous continuons à définir quelques notions théoriques en relation avec notre solution pour
mener décrire clairement notre projet et faire comprendre ses différentes parties.
▪ La dématérialisation des processus
La dématérialisation des processus est l’acte de transformer un flux de documents papier, ainsi
que les traitements qui lui sont appliqués, en flux numériques et traitements automatisés.
8
Comme exemples les plus connus, nous pouvons citer la dématérialisation des factures, la
dématérialisation des procédures administratives. La dématérialisation des processus présente
plusieurs avantages, notamment la réduction des coûts et des temps de traitement, la
sécurisation des flux, l’homogénéisation des processus documentaires et de faire, une meilleure
réponse aux contraintes légales et réglementaires de plus en plus fortes. [3]
▪ Processus Métier
Un processus métier est un ensemble d'activités et des tâches liées qui, une fois achevées,
permettra d'atteindre un objectif organisationnel et qui trouvera leur fin dans la prestation d'un
service ou d'un produit à un client. Le processus doit comprendre des entrées clairement définies
et une seule sortie. Ces entrées sont constituées de tous les facteurs qui contribuent (directement
ou indirectement) à la valeur ajoutée d'un service ou d'un produit. Ces facteurs peuvent être
classés dans les processus de gestion, les processus opérationnels et les processus opérationnels
de soutien. [4]
▪ Workflow
Workflow, littéralement "flux de travaux", est la représentation sous forme de flux des
opérations à réaliser pour accomplir l'ensemble des tâches ou activités regroupées en un même
processus métier. Le workflow permet la modélisation des processus métier dans le cadre d'une
démarche plus globale BPM Business Process Management. [5]
▪ BPMN 2.0
Business Process Model and Notation est une méthode de modélisation de processus d'affaires
pour décrire les flux d'activités et les procédures d'une organisation sous forme d'une
représentation graphique standardisée.
La notation consiste en un ensemble de symboles graphiques représentant des actions, des flux
ou des comportements dans un processus.
Le BPMN est facilement compréhensible par :
▪ L’analyste métier qui modélise les processus conceptuellement

▪ Les développeurs en charge de rendre exécutable le processus modélisé
▪ Les utilisateurs finaux qui utilisent et suivent la réalisation des processus. [6]
9
3. Choix de la méthodologie de développement

Afin d'avoir une qualité convenable d'un projet et respecter les délais fixés au préalable, il est
nécessaire d'introduire une méthodologie de développement. Dans ce projet, nous allons
adopter la méthodologie agile et plus spécifiquement la méthode Scrum, vu que nous allons
développer un produit permettant de répondre à des problèmes complexes et Scrum permet de
faire face à la complexité par l’empirisme.
3.1. La méthodologie de Travail Scrum

La méthode Scrum ou plus exactement le cadre méthodologique Scrum est de loin la méthode
Agile la plus utilisée dans le monde. Expérimentée en 1993, elle bénéficie aujourd’hui de
nombreux retours d’expérience. Les conférences, communautés, formations, blogs, outils et
ouvrages à son sujet ne manquent pas. [7]
La méthodologie Scrum est donc un cadre de travail permettant la gestion du développement

d’applications complexes. Le principe de cette méthode est de développer un logiciel de
manière incrémentale en maintenir une liste totalement transparente des demandes d’évolutions
ou de corrections à implémenter « backlog ». Avec des livraisons très fréquentes, toutes les 4
semaines en général. Pour cela, la méthode s’appuie sur des développements itératifs « sprints
» à un rythme constant d’une durée de 2 à 4 semaines. Le sprint englobe les activités d’analyse,
de conception, de test et de développement. Au cours de ce dernier l’équipe de développement
soulève des questions métiers.
Concrètement, cette méthode nécessite 4 types de réunions :
▪ Les réunions quotidiennes : chaque jour, toute l’équipe se réunit, pendant 15 minutes
environ pour répondre aux 3 questions suivantes : qu’ai-je fait hier ? Que vais-je faire
aujourd’hui ? Y a-t-il un obstacle gênant aujourd’hui ?
▪ Les réunions de planifications : toute l’équipe se réunit pour décider des fonctionnalités
qui vont composer le sprint suivant et mettre à jour la liste générale.
▪ Les réunions de revue de travail : lors de cette réunion, chacun présente ce qu’il a fait
pendant la durée du sprint. Il s’agit d’une réunion informelle de 2 heures environ à
laquelle participe toute l’équipe.
▪ Les réunions de rétrospectives : à chaque fin de sprint, l’équipe fait le point sur ce qui a
bien fonctionné et sur ce qui a moins bien fonctionné. Lors de cette réunion d’une durée
10
de 15 à 30 minutes où chacun est invité et parle en son nom, un vote de confiance est
organisé pour décider des améliorations à apporter.
L’avantage de la méthode est de réduire au strict minimum la documentation afin de gagner en

productivité.
3.1.1. Pourquoi Scrum ?

Le choix de Scrum comme une méthodologie de pilotage pour notre projet s’est basé sur les
atouts de ce dernier qui sont :
Méthode itérative et incrémentielle : cela permet d’éviter « l’effet tunnel », c’est-à-dire le fait
de ne voir le résultat qu’à la livraison finale et rien ou presque rien pendant toute la phase de
développement, si fréquent dans les développements avec le cycle en V.
Adaptabilité maximale pour du développement de produits et d’applications : la composition

séquentielle du contenu des sprints permet d’ajouter une modification ou une fonctionnalité qui
n’était pas prévue au départ. C’est principalement cela qui rend cette méthode “agile”.
Méthode participative : chaque membre de l’équipe est invité à s’exprimer et il peut participer
à toutes les décisions prises sur le projet. Il est donc plus impliqué et plus motivé.
Augmentation de la communication : en travaillant dans la même salle de développement, ou

en étant connecté avec différents moyens de communication, l’équipe peut communiquer
facilement et échanger d’avis sur les obstacles afin de les supprimer au plus tôt.
Augmentation de la productivité : en supprimant certaines “contraintes” des méthodes

classiques comme la documentation ou la formalisation exagérée, SCRUM permet d’augmenter
la productivité de l’équipe. En ajoutant à cela la qualification de chaque module permettant
d’en déterminer un chiffrage, chacun peut se positionner par rapport à la productivité moyenne
de l’équipe.
3.1.2. L’équipe et les Rôles

La méthode SCRUM AGILE fait intervenir 3 rôles principaux qui sont :
Product owner : Dans la majorité des projets, le responsable produit (product owner) est le
responsable de l’équipe projet client. C’est lui qui va définir et prioriser la liste des
fonctionnalités du produit et choisir la date et le contenu de chaque sprint sur la base des valeurs
(charges) qui lui sont communiquées par l’équipe.
11
ScrumMaster : Véritable facilitateur sur le projet, il veille à ce que chacun puisse travailler au
maximum de ses capacités en éliminant les obstacles et en protégeant l’équipe des perturbations
extérieures. Il porte également une attention particulière au respect des différentes phases de
SCRUM.
Equipe : d’une taille allant de 4 à 10 personnes en général, l’équipe regroupe tous les rôles
habituellement nécessaires à un projet, à savoir l’architecte, le concepteur, le développeur, le
testeur, etc. L’équipe s’organise elle-même et elle reste inchangée pendant toute la durée d’un
sprint. [8]
3.1.3. Les artefacts

Les artéfacts de Scrum représentent soit du travail soit de la valeur fournissant ainsi de la
transparence et des opportunités pour l'inspection et l'adaptation.
Product Backlog : Appelé aussi carnet du produit, est une liste ordonnée de tout ce qui pourrait
être requis dans le produit. Il est destiné à recueillir tous les besoins du client que l’équipe projet
doit réaliser. Tous les éléments inclus dans le backlog scrum sont classés par priorité indiquant
l’ordre de leur réalisation. C'est l'artefact le plus important de Scrum. Les principaux critères
de classification des fonctionnalités à considérer sont :
▪ La priorité : représente le degré d’importance et d’indisponibilité d’une
fonctionnalité d’un cas d’utilisation par rapport au nombre total de cas d’utilisation.
▪ L’effort : est l’estimation initiale de la quantité de travail nécessaire pour la réalisation
d’un cas d’utilisation. Il est généralement calculé en nombre de jours/homme.
Planification du sprint : La planification du sprint est l’ensemble des items qui se déroule à
chaque début de sprint. L’objectif de la planification est de mettre l’équipe en situation de
planifier le sprint en se préparant le planning de travail et en se mettant le choix de la durée de
chaque sprint selon la complexité du projet et la taille de l'équipe.
3.2. Les langages de modélisation

Un langage de modélisation est un langage artificiel qui peut être utilisé pour exprimer de
l'information ou de la connaissance ou des systèmes dans une structure qui est définie par un
ensemble cohérent de règles.
3.2.1. Unified Modeling Langage UML
La notation UML est un langage visuel constitué d’un ensemble de schémas, appelés des
diagrammes, qui donnent à chacun une vision différente du projet à traiter. UML nous fournit
12
donc des diagrammes pour représenter le logiciel à développer : son fonctionnement, sa mise
en route, les actions susceptibles d’être effectuées par le logiciel, etc. [9]
Comme logiciel de
conception, nous avons choisi PowerAMC.
3.2.2. Business Process Model Notation BPMN

La BPMN est une norme de notation pour la modélisation de processus. Son objectif est de
fournir un cadre permettant de décrire un processus d’une manière commune à tous les
utilisateurs et ce, indépendamment de l’outil utilisé. [10] Comme logiciel workflow nous avons
utilisé le moteur workflow Activiti et pour la modélisation on a opté pour Bizagi.
3.3. Environnement de travail

3.3.1. Environnement logiciel
Pour réaliser notre projet, nous avons eu recours à des outils de développements, des logiciels,
configurés et installés sur un système d'exploitation Windows 8 professionnel 64bits. Ces outils
de développements et ces logiciels sont :
▪ Spring STS
L'outil SPRING TOOL SUITE est un environnement de développement basé sur Eclipse qui
est adapté afin de faciliter le développement d’applications Spring. Il offre un environnement
prêt à utiliser pour mettre en œuvre le débogage, l’exécution et le déploiement des applications
Spring. [11] Nous utiliserons pour notre projet l'IDE STS dans sa version 3.8.3.
▪ Bizagi
Bizagi Process Modeler est une suite BPM (BPMS) gratuite permettant de modéliser les
processus d’une entreprise, tout en respectant la notation BPMN, dans le but d’automatiser les
processus afin de rendre le métier de l’entreprise plus agile. [12]
Nous utiliserons pour notre
projet Bizagi Modeler dans sa version 3.1.
▪ Activiti
Activiti est un moteur de workflow destiné à exécuter des processus métier modélisés en
BPMN2.0. Il est écrit en Java et s'exécute dans un conteneur web de type Tomcat. [13]
▪ Alfresco
Alfresco est une solution d’ECM, elle permet aux entreprises de créer leur outil de
dématérialisation, et elle propose l’ensemble des fonctionnalités attendues du domaine de la
gestion documentaire : métadonnées, types de documents, workflow documentaire et avancé
[14]
(avec un logiciel compagnon Activiti). Nous utiliserons pour notre projet Alfresco-
community-installer dans sa version 64bits.
13
▪ Bower
Bower c’est donc un outil de management de librairies pour le web. Il s’installe avec la
commande : npm install -g bower. [15]
▪ Standard CMIS
Le standard CMIS permet l'interconnexion entre une GED Open Source et un CMS. Il s’agit
d’une norme émergente, pour homogénéiser les accès à une gestion de contenu, notamment
documentaire. Cette norme consiste à proposer un accès technique homogène aux outils de
gestion des contenus qui propose cette interface. [16]
▪ Oracle Database
C’est est un système de gestion de base de données relationnelle (SGBDR) qui depuis
l'introduction du support du modèle objet dans sa version 8 peut être aussi qualifié de système
[17]
de gestion de base de données relationnel-objet (SGBDRO). Nous utiliserons pour notre
projet Oracle XE Edition dans sa version 12g.
▪ Apache MAVEN
C’est est un outil pour la gestion et l'automatisation de production des projets logiciels Java en
général et Java EE en particulier. Maven utilise un paradigme connu sous le nom de Project
Object Model (POM) afin de décrire un projet logiciel, ses dépendances avec des modules
externes et l'ordre à suivre pour sa production. [18] Nous utiliserons pour notre projet MAVEN
dans sa version 3.3.9.
▪ PowerAMC
C’est est un logiciel de conception créé par la société SAP, qui permet de modéliser les
traitements informatiques et leurs bases de données associées. [19] Nous utiliserons pour notre
projet PowerAMC dans sa version 12.
3.3.2. Choix technique
Les Framework et langages de programmation qui seront utilisés sont :
Spring : Le Framework Spring est une boite à outils très riche permettant de structurer,
d'améliorer et de simplifier l'écriture d'application JEE et qui prend en charge l'infrastructure
complète pour le développement d'applications Java. [20]
SpringBoot : est un projet ou un micro framework qui a notamment pour but de faciliter la
configuration d’un projet Spring et de réduire le temps alloué au démarrage d’un projet, surtout
que le Spring est malheureusement connu pour sa configuration qui peut s’avérer complexe et
fastidieuse. [21]
Spring security : est un Framework qui met l'accent sur la fourniture de l'authentification et
l'autorisation d'applications Java. Comme tous les projets de printemps, la puissance réelle de
14
la sécurité Spring se trouve dans la facilité avec laquelle il peut être étendu pour répondre aux
besoins personnalisés. [22]
AngularJS : AngularJS est un framework JavaScript qui étend le HTML pour le rendre
dynamique, et permet de développer ses propres balises et attributs HTML. C’est un framework
qui se veut extensible et qui pousse vers un développement structuré, en couches, le but n’étant
pas d’ajouter de simples animations au DOM, mais bien d’apporter un aspect applicatif au front-
office. [23]
Hibernate : est un framework permettant de résoudre le problème d'adaptation entre le
paradigme objet et les SGBD. [24] Nous utiliserons pour notre projet Hibernate dans sa version
4.
Bootstrap : Bootstrap est un framework CSS, mais pas seulement, puisqu'il embarque
également des composants HTML et JavaScript. Il comporte un système de grille simple et
efficace pour mettre en ordre l'aspect visuel d'une page web. [25]
HTML, CSS, JavaScript, JQuery et Ajax : Ce sont des langages utiles pour la création d'une
page web.
Conclusion
Au cours de ce chapitre, nous avons pu présenter l'organisme qui nous a accueilli durant la
période de notre stage de fin d'études et de mettre le projet dans son contexte. En second lieu,
nous avons évoqué l'étude de l'existant, après nous avons passé à la solution qu’on avait
proposée ainsi que l'état de l'art. Dans ce qui suit, nous avons étudié le processus de
développement que nous allons suivre tout au long de stage ainsi que l’environnement de
travail.
15
Chapitre 2
Planification et architecture
Chapitre 2 planification et architecture
Introduction
Après avoir introduit l’étude de notre projet, nous entreprendrons ce chapitre avec la
planification générale du projet. Appelée aussi Sprint 0, au cours de laquelle nous allons
identifier les profiles des utilisateurs et déterminer les différentes fonctionnalités du projet pour
pouvoir produire un backlog du produit qui servira ultérieurement à la réussite des sprints du
projet. Enfin, nous allons présenter l’architecture utilisée pour mener à bien ce projet.
1. Recueil des besoins

Cette section est destinée à la spécification des besoins fonctionnels et non fonctionnels de la
solution ainsi que l’identification des acteurs, qui est une étape indispensable pour la réalisation
de notre projet.
1.1. Identification des acteurs

« Un acteur représente l'abstraction d'un rôle joué par des entités externes (utilisateur, dispositif
matériel ou autre système) qui interagissent directement avec le système étudié. » [26]
Dans ce projet, nous avons identifié deux types d’acteurs qui interagissent avec cette solution :
L’utilisateur : C’est l’acteur principale de notre progiciel, auquel l’administrateur peut affecter
plusieurs profils et selon ce dernier, il peut gérer ses cas d’utilisation.
L'administrateur : C’est le gérant de ce module du progiciel. Il a le droit de gérer les affaires

administratives.
Dans le tableau 1 nous allons présenter la liste des acteurs ainsi que leurs profils et leurs
fonctionnalités
Tableau 1 Tableau d'identification des acteurs
Acteur Profil Les fonctionnalités

La gestion des demandes des
Agent de saisie employés et des demandes
Utilisateur des candidats.
17
Acteur Profil Les fonctionnalités
Directeur La consultation des

employés et de leurs
carrières. La consultation et
le traitement des demandes
des employés
Responsable RH La gestion des employés. La
consultation et le traitement
des demandes des employés.
Chef de service personnel La gestion des carrières des

employés. La consultation et
Utilisateur le traitement des demandes
des employés.
Agent de service personnel La consultation et le

traitement des demandes des
employés. Consulter
l’organigramme de
l’entreprise. Gérer les
services.
DARH La consultation et le
employés.
Responsable du recrutement La gestion du recrutement.
Agent de traitement La consultation et le

employés.
Directeur RH La consultation et le
employés.
Chef hiérarchique La consultation et le

employés.
18
La gestion des utilisateurs.

La gestion des rôles.
Administrateur Administrateur
L’affectation des droits
d’accès.
1.2. Les besoins fonctionnels

Un besoin fonctionnel exprime une action que doit effectuer le système en réponse à une
demande. Dans notre contexte, nous allons énumérer les différents besoins de GRH que doit
assurer le progiciel à concevoir.
1.2.1. Gestion des employés

Le système doit permettre à l’utilisateur en tant que responsable RH d’ajouter, de rechercher,
de modifier ou supprimer un employé ainsi que les informations liées à l’employé tel que les
pièces jointes de l’employé et ses enfants. Et il doit permettre à l’utilisateur en tant que directeur
de consulter les employés.
1.2.2. Gestion des affaires administratives

Le système doit permettre à l’administrateur d’ajouter, modifier, supprimer et lister les
utilisateurs et les rôles. Ainsi il doit permettre à l’administrateur d’affecter les droits d’accès
aux utilisateurs.
1.2.3. Gestion des services

Le système doit permettre à l’utilisateur en tant qu’agent de service personnel, d’ajouter,
modifier, supprimer et lister les départements et les postes de l’entreprise.
1.2.4. Consulter l’organigramme de l’entreprise

Le système doit permettre à l’utilisateur en tant qu’agent de service personnel de consulter
l’organigramme de l’entreprise.
1.2.5. Gestion de la carrière

Le système doit permettre à l’utilisateur en tant que chef de service personnel de gérer les
carrières des employés, tel que leurs contrats et leurs avancements. Ainsi le système doit
permettre à l’utilisateur en tant qu’employé de consulter sa carrière.
1.2.6. Gestion du recrutement

Le système doit permettre à l’utilisateur en tant que responsable du recrutement de gérer les
postes à pourvoir, gérer les offres du recrutement, gérer les candidats et les pièces jointes des
19
candidats. Ainsi il doit permettre à l’utilisateur en tant qu’agent de service personnel,

responsable du recrutement, directeur et agent de traitement de traiter les demandes, et à
l’utilisateur en tant qu’employé de postuler à une offre du recrutement.
1.2.7. Gestion des congés

Le système doit permettre à l’utilisateur en tant qu’agent de saisie d’ajouter une demande de
congé d’un employé, de consulter l’état de la demande envoyée et de consulter les congés.
Ainsi, il doit permettre à l’utilisateur en tant que responsable RH, chef de service personnel,
agent de service personnel, agent de traitement, directeur, directeur RH et DARH de traiter les
demandes et sur ce, l’utilisateur peut accepter, ces demandes ou les refuser.
1.2.8. Gestion des absences

Le système doit permettre à l’utilisateur en tant qu’agent de saisie d’ajouter une demande
d’absence d’un employé et de consulter l’état de la demande envoyée. Et il doit permettre à
l’utilisateur en tant que responsable RH, chef de service personnel, agent de service personnel,
agent de traitement, directeur, directeur RH et DARH de traiter les demandes et sur ce,
l’utilisateur peut accepter, ces demandes ou les refuser. Ainsi, le système doit générer
systématiquement les états d’absences et il doit permettre à l’utilisateur en tant que responsable
RH d’établir les états d’absences.
1.2.9. Gestion de la formation

Le système doit permettre à l’utilisateur en tant qu’agent de saisie d’ajouter une demande d’un
employé de participation à la formation, de consulter l’état de la demande envoyée, de consulter
les formations organisées au sein de l’entreprise. Ainsi, le système doit permettre à l’utilisateur
en tant que chef de service personnel, agent de traitement et directeur de traiter les demandes.
Et il doit permettre à l’utilisateur en tant que responsable RH d’ajouter, modifier, supprimer
une formation, et de consulter les demandes des employés.
1.3. Les besoins non fonctionnels

Les besoins non fonctionnels sont les besoins qui caractérisent le système. Ce sont des besoins
qui ont un aspect visible pour l’utilisateur, mais qui ne sont pas reliés directement au
comportement du système. Les besoins non fonctionnels de notre progiciel à concevoir se
décrivent comme suit :
20
1.3.1. Ergonomie
Le progiciel doit fournir une interface ergonomique et conviviale (une interface facile à
manipuler, des boutons ainsi que des libellés significatifs, un design agréable etc…) afin de
garantir l'exploitation facile de ses services.
1.3.2. Extensibilité
L’extensibilité est une spécification très importante pour le progiciel. L’architecture doit
supporter les extensions de nouvelles fonctionnalités sans pour autant la modifier énormément.
Le code devra être ferme à la modification et ouvert à l’extension.
1.3.3. Fiabilité
Le progiciel devra être opérationnel d'une façon continue et robuste. Les données transmises
sont très critiques, et la perte de l'information ne peut pas être tolérée.
1.3.4. Modularité
Le progiciel doit être bien structurée en module pour assurer une meilleure lisibilité, une
diminution du risque d'erreur et une possibilité de tests sélectifs.
1.3.5. Sécurité
Le progiciel doit fournir un espace sécurisé pour ses utilisateurs. Ainsi l’attribution des droits
d’accès appropriés aux différents acteurs du système, et il doit garantir la sécurité des données.
1.4. Diagramme de cas d’utilisation globale

Les diagrammes de cas d'utilisation illustrent et définissent le contexte et les exigences d'un
système entier, ou des parties essentielles d'un système. Ces diagrammes identifient également
les interactions entre le système et ses acteurs. [27]
Nous présentons dans La figure 5 notre diagramme du cas d’utilisation global décrivant les
grandes fonctionnalités du module RH du progiciel de point de vue des acteurs, mais ce
diagramme général ne montre pas de façon détaillée le dialogue entre les acteurs et
les différents profils de chaque utilisateur. Dans les chapitres qui suivent, nous détaillerons,
avec raffinement itératif, les différents cas d’utilisation et nous mettrons les différents acteurs
par profil.
Nous allons dans figure 4 de présenter le diagramme des cas d’utilisation générale.
21
Figure 4 Diagramme de cas d'utilisation globale
2. Prototypage des interfaces

Le prototypage est la clé de voûte du développement itératif. Il présente la partie visible du
logiciel, c’est à dire les fenêtres de l’application ou la page d’accueil du site. Le prototype
permet de réaliser un test de perception. [28]
Comme outil de prototypage, nous avons choisi Balsamiq Mockups pour présenter quelques
maquettes prévisionnelles des interfaces à réaliser, ces figures 5,6,7,8, 9 et 1 se dessous
représentent des exemples des interfaces réalisées avec ce logiciel :
22
Figure 5 Interface d'authentification
Figure 6 Interface principale du module RH
Figure 7 Interface affectation contrat
23
Figure 8 Interface Gestion des employés
Figure 9 Interface d'ajout d'employé
Figure 10 Interface liste congés
24
3. Pilotage du projet avec Scrum

La nécessité d'utiliser une méthodologie Agile, qui semble être la mieux adéquate à ce genre de
projets informatique. Pour diriger ce projet avec Scrum, nous avons besoin dès le départ
d’indiquer l'équipe de travail ainsi que les rôles attribués à chacun d'entre-eux, les backlog du
produit et la planification des sprints.
2.1. Technique utilisée

Souvent, pour assurer un meilleur projet Scrum, les membres de l'équipe BNS Engineering font,
recours à une technique « TODO List » consiste à utiliser un tableau qui divise les taches sur 3
colonnes. Une colonne To Do (à faire), l’autre colonne Doing (en cours), et la dernière Done
(Fait).
2.2. Répartition des rôles

Dans le contexte de notre projet, le rôle de Product Owner est attribué à mon encadrante dans
la société, l'équipe de développement est représentée par moi-même et le rôle de Scrum Master
est attribué au Directeur de la société.
2.3. Backlog du produit

En se fondant sur ce que nous avons expliqué au chapitre 1, nous avons élaboré le Backlog du
produit de notre projet dans le tableau 2.
Tableau 2 BACKLOG DU PRODUIT
Histoire d’utilisateur Description Effort Priorité

(Story)
Authentification En tant qu’utilisateur je veux m’authentifier afin 4 11
d’accéder à l’espace de travail dans l’ERP
Gérer les utilisateurs En tant qu'administrateur je veux pouvoir ajouter, 2 8
modifier, supprimer et lister les utilisateurs
Gérer les rôles En tant qu’administrateur je veux pouvoir ajouter, 2 9

modifier, supprimer et lister les rôles
Affecter les droits d’accès En tant qu’administrateur je veux affecter les droits 2 10
d’accès
Gérer les employés En tant que responsable ressource humaine je veux 3 1
pouvoir ajouter, modifier, supprimer, lister et consulter les
détail d’un employé
Gérer les enfants de En tant que responsable ressource humaine je veux 2 7
pouvoir affecter un enfant à l’employé, ainsi que
l’employé
modifier, supprimer et lister les enfants
25
Gérer les pièces jointes de En tant que responsable ressource humaine je veux 4 6
pouvoir affecter une pièce jointe à l’employé, ainsi que
l’employé
modifier, supprimer et lister les pièces jointes
Gérer les départements de En tant qu’agent service personnel je veux pouvoir 2 2
ajouter, modifier, supprimer et lister les départements
l’entreprise
Gérer les postes de En tant qu’agent service personnel je veux pouvoir 2 3
ajouter, modifier, supprimer et lister les postes
l’entreprise
Gérer les contrats En tant qu’agent service personnel je veux pouvoir 2 4
affecter un contrat à un employé, ainsi que consulter,
lister, modifier et résilier un contrat
Gérer les avancements En tant que responsable du recrutement je veux pouvoir 2 5
affecter l’avancement d’un employé, ainsi que modifier,
supprimer et lister les avancements
Gérer les postes à pourvoir En tant que responsable du recrutement je veux pouvoir 2 12
ajouter, modifier, supprimer, consulter et lister les postes
à pourvoir
Gérer les offres d'emploi En tant que responsable du recrutement je veux pouvoir 2 13
ajouter, modifier, supprimer, consulter et lister les offres
d'emploi
Gérer les candidats En tant que responsable du recrutement je veux pouvoir 2 14

ajouter, modifier, supprimer, consulter et lister les
candidats
Gérer les pièces jointes du En tant que responsable du recrutement je veux pouvoir 4 15
affecter une pièce jointe au candidat, ainsi que modifier,
candidat
supprimer, consulter et lister les pièces jointe
Gérer les demandes de stages En tant qu’agent de saisie je veux pouvoir ajouter, 2 16
modifier, supprimer, et lister les demandes de stages
Traiter les demandes de En tant que responsable du recrutement ou directeur je 4 17

veux pouvoir consulter le tableau de bord ainsi que
stages
consulter et traiter la demande de stage
Gérer les demandes du En tant qu’agent de saisie je veux pouvoir ajouter, 2 18
modifier, supprimer et lister les demandes du recrutement
recrutement
Traiter les demandes du En tant que responsable de recrutement ou directeur je 4 19

veux pouvoir consulter le tableau de bord, ainsi que
recrutement
consulter et traiter la demande du recrutement
Gérer les congés En tant qu’agent de saisie je veux pouvoir ajouter, 2 20

modifier, consulter et lister les demandes de congé
Traiter les congés En tant que responsable RH, DARH, chef hiérarchique, 4 21
chef service personnel, directeur RH, ou directeur je veux
pouvoir consulter le tableau de bord, ainsi que consulter et
traiter la demande de congé
26
Gérer les demandes En tant qu’agent de saisie je veux pouvoir ajouter, 2 23

modifier, consulter et lister les demandes d’absence
d’absence
Traiter les absences En tant que responsable RH, chef hiérarchique, DARH, 4 24
ou directeur je veux pouvoir consulter le tableau de bord,
ainsi que consulter et traiter la demande d’absence
Gérer les absences En tant que responsable ressource humaine je veux 2 22

pouvoir établir et lister les états d’absence
Gérer les demandes de En tant qu’agent de saisie je veux pouvoir ajouter, 2 26

modifier, consulter et lister les demandes de participation
formation
au formation
Traiter les demandes de En tant que responsable RH, DARH ou directeur je veux 3 27
pouvoir consulter le tableau de bord, ainsi que consulter et
formation
traiter les demandes de la formation
Gérer les formations En tant qu’agent de saisie je veux pouvoir ajouter, 2 25

modifier, supprimer, consulter et lister les formations
Consulter l’organigramme En tant qu’utilisateur je veux pouvoir consulter 1 28

de l’entreprise l’organigramme de l’entreprise
2.4. Planification des sprints

Pour notre module PGI de gestion administrative des ressources humaines, nous avons choisi
d'implémenter 3 sprints. Le premier sprint sera nommé « les missions principales de GRH », le
seconde sera nommé « Gestion du recrutement » et le dernier sera nommé « Les flux de travaux
RH ». La figure 11 illustre la planification des sprints pour le module PGI.
Figure 11 PLANIFICATION DES SPRINTS
27
4. 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 de
développement. Notre choix architectural s'est porté sur les besoins exprimés précédant afin de
réaliser notre ERP autour d'une architecture évolutive, urbanisée et qui permet de supporter les
objectifs stratégiques et les processus métiers de l’entreprise.
4.1. Architecture applicative

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
[29]
partie de son enveloppe et de ses en-têtes sans ajout de surcouche. 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,
▪ Les types MIME comme text/xml, text/html, image/jpeg, application/pdf, video/mpeg
pour la représentation des ressources. [30]
Figure 12 Le modèle REST [31]
28
4.2. Architecture technique

Nous présenterons dans la Figure 13 L'architecture technique de notre projet :
Figure 13 Schéma de l'architecture 3-tierces adoptée
On se fondait sur l'architecture trois-tiers nous allons développer notre système qui doit être
divisé en trois couches différentes [32] :
▪ Couche présentation : Elle correspond à la partie de l’application visible et interactive
avec les utilisateurs. Elle relaie les requêtes de l'utilisateur à destination de la couche
métier, et en retour lui présente les informations renvoyées par les traitements de cette
couche.
▪ Couche applicative ou Couche métier : Elle correspond à la partie fonctionnelle de
l’application, celle 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, effectuées
au travers de la couche présentation.
▪ Couche donnée : Elle consiste en la partie gérant l'accès aux gisements de données du
système. Ces données peuvent être propres au système, ou gérées par un autre système.
Conclusion
Dans ce chapitre, nous avons commencé par énoncer les différents besoins spécifiés dans le
cahier des charges qui nous a été communiqué avec la société BNS ENGINEERING. Pour
mieux cerner le travail demandé et le résultat attendu, nous avons eu recours à des réunions
avec les différents employés de l'entreprise ce qui nous aider à l'élaboration du carnet du produit
(backlog product) et à la maitrise des différents processus métier.
29
Chapitre 3
Sprint 1 - Les missions

principales de GRH
Chapitre 3 Sprint 1 – les missions principales de GRH
Introduction
Au cours de ce chapitre, nous allons déclencher une nouvelle sprint nommée « Les missions
principales de GRH ». Ce premier sprint se présente comme le plus prioritaire des sprints.
Tout d'abord, et avant de se lancer dans un sprint, il faut identifier le but de ce dernier en terme
métier. De ce fait, nous avons décidé après une réunion avec le propriétaire du produit le but
suivant : « terminer le développement de la partie qui concerne les affaires administratives, la
gestion des employés ainsi que les ressources liées aux employés tels que les contrats, la
position dans l’organigramme et l’avancement de l’employé ».
1. Backlog du sprint
Dans le backlog de ce sprint du tableau 3, nous citons les différentes fonctionnalités (User
stories) en leur attribuant des efforts. Dans ce contexte, le terme effort désigne l'estimation de
temps de travail nécessaire pour développer une fonctionnalité. Cette estimation est présentée
par un nombre de jours qui varie d'un cas d'utilisation à un autre.
Tableau 3 BACKLOG DU SPRINT 1
Thème Story (fonctionnalité) Estimation

Authentification S’authentifier 3
Affecter les droits d’accès 1

Gérer les utilisateurs : Ajouter utilisateur 1
Gérer les utilisateurs : Lister les 1
utilisateurs
Gérer les utilisateurs : Modifier 1
Gérer les affaires utilisateur
administratives Gérer les utilisateurs : Rechercher 1
utilisateur
Gérer les utilisateurs : Supprimer 1

utilisateur
Gérer les rôles : Lister les rôles 1
Gérer les rôles : Ajouter rôle 1
Gérer les rôles : Modifier rôle 1
31
Gérer les rôles : Supprimer rôle 1
Ajouter employé 3
Lister les employés 1
Consulter détail employé 1
Modifier employé 1
Gérer les employés Supprimer employé 1
Gérer les enfants : Affecter enfant à 1

l’employé
Gérer les enfants : Lister les enfant 1
Gérer les enfants : Modifier enfant 1
Gérer les enfants : Supprimer enfant 1
Gérer les pièces jointes : Affecter pièce 3

jointe à l’employé
Gérer les pièces jointes : Lister les 2

pièces jointes
Gérer les pièces jointes : Modifier 1
pièces jointes
Gérer les pièces jointes : Supprimer 1

pièce jointe
Gérer les départements : Ajouter 1

département
Gérer les départements : Lister les 1
départements
Gérer les services de Gérer les départements : Modifier 1
département
l’entreprise Gérer les départements : Supprimer 1
département
Gérer les postes : Ajouter poste 1
Gérer les postes : Lister les postes 1
Gérer les postes : Modifier poste 1
32
Gérer les postes : Supprimer poste 1
L’organigramme de Consulter l’organigramme de l’entreprise 1

l’entreprise
Gérer les contrats : Affecter contrat à 1
l’employé
Gérer les contrats : Lister les contrats 1
Gérer les contrats : Consulter détail 1

contrat
Gérer les contrats : Modifier contrat 1
Gérer les carrières
Gérer les contrats : Résilier contrat 1
Gérer les avancements : Affecter 1

avancement à l’employé
Gérer les avancements : Lister les 1

avancements à l’employé
Gérer les avancements : Modifier 1
avancement
Gérer les avancements : Supprimer 1
avancement
Nous passons dans ce qui suit au noyau de notre projet : les activités et le cycle de
développement. Dans un sprint, nous devons extraire cinq activités principales qui sont la
capture des besoins, l’analyse, la conception, l’implémentation et le test. Tout au long de ce
sprint, nous respectons ces activités pour construire le plan de notre travail.
2. Capture des besoins

La capture de besoins est la première démarche de chaque sprint. Dans notre cas, cette démarche
sera traduite par un diagramme de cas d’utilisation global du sprint 1, des diagrammes de cas
d’utilisation raffinés, ainsi que leurs descriptions textuelles.
2.1. Diagramme de cas d'utilisation du Sprint 1

Nous illustrons dans la figure 14 le diagramme du cas d'utilisation du notre premier sprint.
Ensuite, nous allons montrer le raffinement de chaque cas d’utilisation dans la prochaine
section.
33
Figure 14 DIAGRAMME DE CAS D'UTILISATION DU SPRINT 1
2.2. Raffinement des cas d’utilisation

L'une des méthodes de Scrum, qu'il interprète à segmenter une histoire utilisateurs en un
ensemble de tâches, comme le cas d’utilisation « lister les employés » que nous avons dévissé
en trois tâches : « Consulter détail employé » « Modifier employé » et « supprimer employé ».
De ce fait, et afin de mieux suivre la méthodologie Scrum, nous avons découpé les cas
d'utilisons en sous cas, ainsi que nous avons les raffinés pour bien assimiler et élaborer une
description des différents scénarios possibles du sprint courant.
2.2.1. Cas d’utilisation « Gérer les employés »

Comme le montre le diagramme de cas d’utilisation clarifié par la figure 15, le cas d’utilisation
« gérer les employés » est raffiné dans ce sprint en quatre cas histoires « Lister les employés »,
« Ajouter employé », « Gérer les enfants de l’employé », et « Gérer les pièces jointes de
l’employé ». Ainsi que nous avons illustré dans ce cas les différents profils de l’utilisateur de
cette fonctionnalité. On note que les cas « gérer les affaires administratives », « gérer les
carrières », et « gérer l’organigramme » suivent la même logique.
34
Figure 15 DIAGRAMME DE CAS D'UTILISATION "Gérer employé"
▪ Cas d’utilisation « Gérer les enfants » et « Gérer les pièces jointes de l’employé »
Nous avons fait raffiné dans les figures 16 et 17 les sous cas d’utilisation « Gérer les enfants »
et « Gérer les pièces jointes de l’employé » du cas d’utilisation « Gérer les employés ».
Figure 16 DIAGRAMME DE CAS D'UTILISATION "Gérer les enfants"
35
Figure 17 DIAGRAMME DE CAS D'UTILISATION "Gérer les pièces jointes"
2.2.2. Cas d’utilisation « Gérer les services »

Nous allons ainsi représenter les sous cas d’utilisation de « gestion des services » dans la figure
18.
Figure 18 DIAGRAMME DE CAS D'UTILISATION "Gérer les services"
▪ Les cas d’utilisation « Gérer les départements » et « Gérer les postes »

Nous avons fait raffiné dans les figures 19 et 20 les sous cas d’utilisation « Gérer les
départements » et « Gérer les postes » du cas d’utilisation « Gérer les services ».
36
Figure 19 DIAGRAMME DE CAS D'UTILISATION "Gérer les département "
Figure 20 DIAGRAMME DE CAS D'UTILISATION "Gérer les postes"
2.2.3. Cas d’utilisation « Gérer les carrières »
Figure 21 DIAGRAMME DE CAS D'UTILISATION "Gérer les carrières"
▪ Les cas d’utilisation « Gérer les contrats » et « Gérer les avancements »

Nous avons fait raffiné dans les figures 22 et 23 les sous cas d’utilisation « Gérer les contrats »
et « Gérer les avancements » du cas d’utilisation « Gérer les carrières ».
37
Figure 22 DIAGRAMME DE CAS D'UTILISATION "Gérer les contrats"
Figure 23 DIAGRAMME DE CAS D'UTILISATION "Gérer les avancements"
2.2.4. Cas d’utilisation « Gérer les affaires administratives »

La figure 24 illustre le cas d’utilisation « Gérer les affaires administratives » :
38
Figure 24 DIAGRAMME DE CAS D'UTILISATION "Gérer les affaires administratives"
▪ Les cas d’utilisation « Gérer les utilisateurs » et « Gérer les rôles »

Nous avons fait raffiné dans les figures 25, 26 et 27 les sous cas d’utilisation « Gérer les
utilisateurs », « Gérer les rôles » et « Gérer les droits d’accès » du cas d’utilisation « Gérer les
affaires administratives ».
Figure 25 DIAGRAMME DE CAS D'UTILISATION "Gérer les utilisateurs"
Figure 26 DIAGRAMME DE CAS D'UTILISATION "Gérer les rôles"
39
2.3. Descriptions textuelles des cas d’utilisation

Afin d’avoir une description approfondie des cas d’utilisation, nous avons choisi de vous
présenter les descriptions textuelles de ces derniers. Et pour des raisons de simplification, nous
traiterons dans ce qui suit uniquement les cas d’utilisation :
« Ajouter employé », « Affecter enfant à l’employé », « Lister les contrats », « Consulter les
détails d’un employé », « Modifier avancement », « Supprimer utilisateur », « Rechercher
employé » et « S’authentifier » puisqu’ils sont similaires aux autres cas d’utilisation de ce
projet.
2.3.1. Description textuelle du cas « S’authentifier »

Le tableau suivant représente la description du cas d’utilisation « s’authentifier » :
Tableau 4 Description textuelle du cas « S’authentifier »
Cas d’utilisation S’authentifier

Acteurs Tout utilisateur
Précondition Néant
Post-condition Accès à l’espace utilisateur
Scénario principal 1-L’utilisateur introduit son login et son mot de passe
2-le système vérifie les données saisies
3-le système redirige l’utilisateur vers son espace dans
l’ERP.
Scénario alternatif 2-a-L’utilisateur saisit des données manquantes
2-1-Le système affiche un message d’erreur précisant
quelles données sont manquantes
2-2-L’utilisateur introduit les données manquantes
2-3-Reprise de l’étape 2 du scénario principal
2-b- Les données saisies sont invalides
2-1-le système affiche un message d’erreur précisant le
type de l’erreur
2-2-L’utilisateur réintroduit les données
2-3-Reprise de l’étape 2 du scénario principal
2.3.2. Description textuelle du cas « Ajouter employé »

Le tableau suivant représente le raffinement du cas d’utilisation « Ajouter employé » :
Tableau 5 Description textuelle du cas « Ajouter employé »
Cas d’utilisation Ajouter employé

Acteurs Responsable RH
Précondition Acteur authentifié
40
Post-condition Nouvel employé ajouté

Scénario principal 1-L'acteur demande d’ajouter un employé
2-Le système affiche le formulaire d’ajout
3-L’acteur remplit les champs nécessaires et valide l’ajout
4-Le système vérifie les données saisies
5-Le système ajoute le nouvel employé
6-Le système redirige l’acteur vers la liste des employés.
Scénario alternatif 4-a-Le système saisit des données manquantes

4-a-1-Le système affiche un message d’erreur
4-a-2-Reprise de l’étape 3 du scénario principal
4-b- -Le système saisit des données invalides (de types ou
formats invalides)
4-b-1-Le système affiche un message d’erreur
4-b-2-Reprise de l’étape 3 du scénario principal
2.3.3. Description textuelle du cas « Affecter enfant à l’employé »

Le tableau suivant représente le raffinement du cas d’utilisation «Affecter enfant à l’employé»
Tableau 6 Description textuelle du cas « Affecter enfant à l’employé »
Cas d’utilisation Affecter enfant à l’employé

Post-condition Nouvel enfant ajouter et affecter à l’employé
Scénario principal 1-L'acteur demande d’affecter enfant à un employé

2-Le système affiche le formulaire d’ajout avec une liste
d’option par tous les employés
3-L’acteur remplit les champs nécessaires, choisit l’employé
et valide l’ajout
5-Le système ajoute le nouvel enfant de l’employé
6-Le système redirige l’acteur vers la liste des enfants.
41

formats invalides)
2.3.4. Description textuelle du cas « Lister les contrats »

Le tableau suivant représente le raffinement du cas d’utilisation « Lister les contrats » :
Tableau 7 Description textuelle du cas « Lister les contrats »
Cas d’utilisation Lister les contrats
Acteurs Chef de service personnel
Post-condition Liste des contrats affichée
Scénario principal 1-L'acteur demande la liste des contrats à consulter

2-Le système affiche la liste des contrats
Scénario alternatif 2-a-aucun résultat

2-a-1-le système affiche un message de type « aucun
résultat trouvé »
2.3.5. Description textuelle du cas « Consulter les détails d’un employé »

Le tableau suivant représente le raffinement du cas d’utilisation « Consulter les détails d’un
employé » :
Tableau 8 Description textuelle du cas « Consulter les détails d’un employé »
Cas d’utilisation Consulter les détails d’un employé
Acteurs Responsable RH, directeur

Liste des employés affichée
Post-condition Les détails d’un employé affichée
Scénario principal 1-L'acteur choisit un employé et demande leurs détails à

consulter.
42
2-Le système affiche les détails d’un employé choisi par

l’acteur.
2.3.6. Description textuelle du cas « Modifier avancement »

Le tableau suivant représente le raffinement du cas d’utilisation « Modifier avancement » :
Tableau 9 Description textuelle du cas « Modifier avancement »
Cas d’utilisation Modifier avancement
Acteurs Chef de service personnel

Liste des avancements affichée
Post-condition Avancement mis à jour
Scénario principal 1-L'acteur choisit l’avancement à modifier et valide son

choix
2-Le système affiche le formulaire de modification
contenant les données actuelles d’avancement
3-L'acteur modifie les champs voulus et valide la
modification
5-Le système enregistre la modification d’avancement
6-Le système redirige l’acteur vers la liste des avancements

formats invalides)
2.3.7. Description textuelle du cas « Supprimer utilisateur »

Le tableau suivant représente le raffinement du cas d’utilisation « Supprimer utilisateur » :
43
Tableau 10 Description textuelle du cas « Supprimer utilisateur »
Cas d’utilisation Supprimer utilisateur
Acteurs Administrative

Liste des utilisateurs affichées
Post-condition Utilisateur supprimé
Scénario principal 1-L'acteur choisit l’utilisateur à supprimer et valide.

2- le système affiche un message de confirmation de
suppression
3-l'acteur valide la suppression
4-le système supprime l’utilisateur
5-le système redirige l’acteur vers la liste des utilisateurs
restants
Scénario alternatif 3-a-l'acteur annule son choix
3-a-1-le système annule la suppression
2.3.8. Description textuelle du cas « Rechercher employé »

Le tableau suivant représente le raffinement du cas d’utilisation « Rechercher employé » :
Tableau 11 Description textuelle du cas « Rechercher employé »
Cas d’utilisation Rechercher employé
Acteurs Responsable RH, directeur

Liste des employés affichées
Formulaire de recherche disponible
Post-condition Liste d’employé ou un seul employé affiché
Scénario principal 1-L'acteur saisi les critères de recherche

2- le système cherche les employés répondants aux critères
mentionnés.
3-le système affiche la liste des employés

2-a-1-le système affiche une Liste vide
2-a-2-reprise de l’étape 1 du scénario nominal
44
3. Analyse
Le modèle d'analyse doit fournir des spécifications fonctionnelles totales du système que l'on
veut développer sans aucune référence à l'environnement de développement. La phase de
[33]
développement (conception & implémentation) sera conduite à partir de ce modèle. Cette
analyse est présentée à travers les diagrammes de séquence système et les diagrammes de
classes participantes.
3.1. Diagrammes de séquence systèmes

Pour modéliser la vue dynamique de notre système, nous avons fait appel au digramme de
séquence d'UML. Ce diagramme permet d'illustrer les échanges entre les acteurs et le système
par des messages présentés dans un ordre chronologique.
Nous avons choisi de conserver la même logique d'appliquer l’approche de simplification
appliquée dans les descriptions textuelles des cas d’utilisation, alors, nous avons sélectionné
quelques exemples des diagrammes de séquence système pour les traiter.
3.1.1. Diagramme de séquences système du cas « S’authentifier »

La figure 27 montre le diagramme de séquence système du cas d’utilisation « S’authentifier ».
Figure 27 DIAGRAMME DE SEQUENCES SYSTEME DU CAS "S'AUTHENTIFIER"
45
3.1.2. Diagramme de séquences système du cas « Ajouter employé »

La figure 28 montre le diagramme de séquence système du cas d’utilisation «Ajouter employé».
Figure 28 DIAGRAMME DE SEQUENCES SYSTEME DU CAS "AJOUTER EMPLOYE"
3.1.3. Diagramme de séquences système du cas « Lister les utilisateurs »

La figure 29 montre le diagramme de séquence système du cas d’utilisation « Lister les
utilisateurs ».
Figure 29 DIAGRAMME DE SEQUENCE SYSTEME DU CAS " LISTER LES UTILISATEURS "
46
3.1.4. Diagramme de séquences système du cas « Modifier employé »

La figure 30 montre le diagramme de séquence système du cas d’utilisation «Modifier
employé».
Figure 30 DIAGRAMME DE SEQUENCE SYSTEME DU CAS "MODIFIER EMPLOYE"
3.1.5. Diagramme de séquences système du cas « Consulter les détails d’un

employé »
La figure 31 montre le diagramme de séquence système du cas d’utilisation « Consulter les
détails d’un employé »
Figure 31 DIAGRAMME DE SEQUENCE SYSTEME DU CAS "CONSULTER LES DETAILS D'UN EMPLOYE"
47
3.1.6. Diagramme de séquences système du cas « Supprimer utilisateur »

La figure 32 montre le diagramme de séquence système du cas d’utilisation « Supprimer
utilisateur »
Figure 32 DIAGRAMME DE SEQUENCE SYSTEME DU CAS " SUPPRIMER UTILISATEUR"
3.2. Diagrammes des classes participantes

Le diagramme de classes participantes permet d'effectuer la jonction entre les cas d’utilisation,
le modèle du domaine et l’interface avec l’utilisateur. Ainsi, ce diagramme modélise trois types
de classes d'analyse qui sont :
▪ Les classes de dialogues : ce sont les classes qui permettent les interactions entre l'IHM
et les utilisateurs.
▪ Les classes de contrôles : ce sont les classes qui modélisent la cinématique de
l'application. Elles contiennent les actions à effectuer et servant à contrôler.
▪ Les classes entités : ce sont les classes métier, qui proviennent directement du modèle
du domaine. [34]
Pour la modélisation de nos diagrammes de classes participantes, nous avons choisi d'ajouter
aux noms des classes dialogues « UI » pour désigner « User Interface » et « C » aux noms des
classes contrôles. Nous notons que vu le grand nombre d’attributs des classes à traiter, et pour
48
simplifier les diagrammes, nous ne mettrons au niveau des classes « dialogues » que
l’identifiant et les opérations.
3.2.1. Diagramme des classes participantes du module « gérer employé »
Figure 33 DIAGRAMME DE CLASSES PARTICIPANTES DU MODULE "Gérer employé"
3.2.2. Diagramme des classes participantes du module « gérer contrat »
Figure 34 DIAGRAMME DE CLASSES PARTICIPANTES DU MODULE "Gérer contrat"
49
3.2.3. Diagramme des classes participantes du module « gérer utilisateur »
Figure 35 DIAGRAMME DE CLASSES PARTICIPANTES DU MODULE "Gérer utilisateur"
4. Conception
Après avoir terminé la phase de la capture des besoins et la phase d'analyse, nous entamons
dans cette section la phase de conception. Elle se traduit par les diagrammes de séquence
détaillés et le diagramme de classes du sprint 1.
4.1. Diagrammes de séquences détaillés

Nous modélisons dans cette section le cas d’utilisation « S'authentifier » pour voir de près les
détails de ce cas et leur ordre chronologique.
50
4.1.1. Diagramme de séquence du cas « S'authentifier »
Figure 36 DIAGRAMME DE SEQUENCE OBJET DU CAS " S'authentifier "
51
4.2. Diagramme de classes du sprint 1

La figure 40 illustre le diagramme de classes global de ce sprint.
Departement
Poste
1..* 1..* Utilisateur - id : Long
Role Affecter - id : Long
- id : Long - departement : String
- id_role : Long 1..1 - poste : String
- role : String - login : String
- password : String
1..1
- dateCreation : Date
- activation : Boolean contenir contenir
1..* 1..*
1..*
Contrat
Avancement - id : Long
Avoir
- id : Long 1..* - type_contrat : String
- echelon : int 1..* affecter - date_debut : Date
- echelle : String tenir - date_fin : Date
- date_avancement : Date - niveau_qualification : String
1..1 1..1 1..1 - régime_payment : String
- activation : Boolean
Employe
- id : Long
- matricule : String
Piéce_jointe_employe
- nom : String
- id : Long - prenom : String
- label : String 1..* Posséder - num_cin : Long
- url : String
1..1 - date_naissance : Date
- nom : String - lieu : String
- genre : String
- adresse_electronique : String
1..* - num_tel : String
- sit_fam : String
- num_permis : Long
Avoir - note : int
- categorie_diplome : String
appartenir
- rue : String
0..* - ville : String
1..1
- code_postale : int
- date_debut : date 1..1 Avoir
type pièce jointe - nom_conjoint : String
- id : Long - prenom_conjoint : String
- type_pièce : String - cin_conjoint : Long
1..1 - num_cnss_conjoint : Long
- num_cnrps_conjoint : Long 0..*
Gouvernorat - fonction_conjoint : String Enfant
- id : Long - image : Byte
- id : Long
- gouvernorat : String - nom : String
- prenom : String
- date_naissance : Date
- situation_enfant : String
Figure 37 DIAGRAMME DE CLASSE DU SPRINT 1
5. Implémentation
Dans cette phase d'implémentation, nous présenterons la génération de la BD plus le
dictionnaire de données et le diagramme de composants, ainsi que les interfaces graphiques des
histoires utilisateurs que nous avons réalisés durant ce sprint.
5.1. La génération de la BD plus le dictionnaire de données
52
Tableau 12 Table "employé "
Champs Types Contraintes

Id Long PRIMARY KEY, IDENTITY,
NOT NULL
Matricule Varchar(Max) NOT NULL
Nom Varchar(Max) NOT NULL
Prenom Varchar(Max) NOT NULL
Num_cin Long NOT NULL
Date_naissance Date --
Lieu Varchar(Max) --
Genre Varchar(Max) NOT NULL
Adresse_electonique Varchar(Max) NOT NULL
Num_tel Varchar(Max) NOT NULL
Slt_fam Varchar(Max) NOT NULL
Note Int --
Categorle_diplome Varchar(Max) NOT NULL
Rue Varchar(Max) --
Ville Varchar(Max) --
Code_postale Int --
Date_debut Date --
Nom_conjoint Varchar(Max) --
Prenom_conjoint Varchar(Max) --
cin_conjoint Long --
Num_cnss_conjoint Long --
Num_cnrps_conjoint Long --
fonction_conjoint Varchar(Max) --
Image Byte --
53
Id_gouvernerat Long FOREIGN KEY
Tableau 13 Table « Contrat »

NOT NULL
type_contrat Varchar(Max) NOT NULL
Date_debut Date NOT NULL
Date_fin Date NOT NULL
Niveau_qualification Varchar(Max) --
Regime_payment Varchar(Max) NOT NULL
Id_employe Long FOREIGN KEY
Id_departement Long FOREIGN KEY
Id_poste Long FOREIGN KEY
Tableau 14 Table « Département »

NOT NULL
Département Varchar(Max) NOT NULL
Tableau 15 Table « Poste »

NOT NULL
Poste Varchar(Max) NOT NULL
Tableau 16 Table « Avancement »
54

NOT NULL
Echelon Int NOT NULL
Echelle Varchar(Max) NOT NULL
Date_avancement Date --
Tableau 17 Table « Enfant »

NOT NULL
Prenon Varchar(Max) --
Date_naissance Date --
Situation_enfant Varchar(Max) --
Tableau 18 Table « Pièce jointe employé »

NOT NULL
Label Varchar(Max) NOT NULL
url Varchar(Max) NOT NULL
Id_type_piece Long FOREIGN KEY
Tableau 19Table « Type_pièce_jointe »
55

NOT NULL
Type_piece Varchar(Max) NOT NULL
Tableau 20 Table « Gouvernorat »

NOT NULL
Gouvernorat Varchar(Max) NOT NULL
Tableau 21 Table « Utilisateur »

NOT NULL
Login Varchar(Max) NOT NULL
Password Varchar(Max) NOT NULL, HASHED
Date_creation Date --
Activation Boolean --
Tableau 22 Table « Rôle »

NOT NULL
Role Varchar(Max) NOT NULL
Nous notons que « Authority » est une table de jointure c’est-à-dire table intermédiaire entre la
table « utilisateur » et la table « rôle ».
Tableau 23 Table « Autority »

Id_utilisateur Long FOREIGN KEY
Id_role Long FOREIGN KEY
56
5.2. Diagramme de composants

Nous présentons dans cette section un diagramme de composant afin d'illustrer l'organisation
du système du point de vue des éléments logiciels comme les modules, les données ou encore
d'éléments de configuration.
5.2.1. Diagramme de composants du cas d’utilisation « Gérer les employés »
Figure 38 Diagramme de composants du cas d’utilisation « Gérer employé »
5.3. Les interfaces du Sprint 1

Dans cette étape, nous allons donner une idée sur les différentes interfaces produites durant ce
sprint.
57
5.3.1. Interface d’authentification

La figure 39 présente l'interface d'authentification au module GRH de l’ERP. Si l'utilisateur
saisie un login et un mot de passe existants dans la base de données du module GRH, il sera
redirigé vers son espace, sinon l'accès est refusé et un message d'erreur sera affiché.
Figure 39 Interface d’authentification
5.3.2. Interface Ajouter Employé

La figure 40 présente l’interface d’ajout d’un employé.
Figure 40 Interface ajouter employé
58
5.3.3. Interface de la Liste des employés

L’interface 41 représente L’interface de la liste des employés.
Figure 41 Interfaces la listes des employés
5.3.4. Interface de Suppression d’un employé

La figure 42 présente l’interface de suppression d’un employé.
Figure 42 Interface de suppression d’un employé
5.3.5. Interface Ajouter contrat

La figure 43 présente l’affectation d’un contrat à l’employé.
59
Figure 43 Interface d’ajout d’un contrat
5.3.6. Interface de la liste des utilisateurs

L’interface présente dans la figure 44 représente la gestion des utilisateurs et les droits d’accès
de ses utilisateurs.
Figure 44 Interface de la Lister des utilisateurs
6. Test
Pour valider ce sprint, nous avons déroulé des tests afin de vérifier le bon fonctionnement des
histoires utilisateurs réalisées durant ce sprint.
6.1. Tests de validation

Ce tableau représente 2 scénarios des tests associés au sprint 1.
60
Tableau 24 résultats du test
Scénarios
Cas de Test Démarche Comportement Résultat

attendu
Présenter toutes les Apparition d’employé Conforme.

informations dans le ajouté dans la liste des
formulaire d’ajout. employés
Test d’ajout d’un Ne pas présenter toutes Affichage d’une Conforme.
employé. les informations dans erreur.
le formulaire d’ajout.
Présenter toutes les Apparition le Conforme.

informations à département modifié
modifier dans le dans la liste des
formulaire d’ajout. départements
Test de modifier un
département Ne pas présenter les Apparition le Conforme.
informations à modifié département avec les
dans le formulaire de informations déjà
modifier. existés.
6.2. Test unitaires

A ce niveau, nous allons procéder à des tests unitaires du première Sprint. En utilisant l’outil
permettant d’exécuter des appels HTTP à un serveur « POSTMAN ».
Figure 45 code Ajouter Poste
61
Figure 46 Ajouter une poste avec POST
Figure 47 code d’afficher tous les postes
Figure 48 Lister tous les poste avec GET
Conclusion
Le premier sprint réalisé durant ce chapitre nous a permis de toucher de plus près le secteur des
ressources humaines, d'appliquer ce que nous avons appris dans le génie logiciel et de pratiquer
le développement informatique avec des technologies qui occupent une place importante dans
le monde.
62
Chapitre 4
Sprint 2 – Gestion du
recrutement
Chapitre 4 Sprint 2 – gestion du recrutement
Introduction
Ce chapitre est consacré au deuxième sprint, nous suivons le même principe que le sprint
précédent, alors nous commençons par définir le but suivant : « terminer le développement de
la partie qui concerne la gestion des candidats, la gestion des postes à pourvoir, la gestion des
offres et des demandes d'emploi, et la gestion des demandes de stages.
Ce Backlog du sprint représente les fonctionnalités du Sprint 2 ainsi que leurs estimations.
Story (fonctionnalité) Estimation
Ajouter candidats 1
Lister les candidats 1
Consulter détail candidats 1
Modifier candidat 1
Supprimer candidat 1
Affecter pièce jointe au candidat 3
Lister les pièces jointes 1
Modifier pièces jointes 1
Supprimer pièce jointe 1
Ajouter poste à pourvoir 1
Lister les postes à pourvoir 1
Modifier poste à pourvoir 1
Supprimer poste à pourvoir 1
Ajouter offre d’emploi 1
Lister des offres d’emploi 1
64
Modifier offre d’emploi 1
Supprimer offre d’emploi 1
Gérer les demandes de stage 1
Gérer les demandes d’emploi 1
Consulter le tableau de bord 4
Traiter les demandes de stages 3
Traiter les demandes d’emploi 4

Nous illustrons dans la figure 49 le diagramme du cas d’utilisation du notre deuxième sprint
« Gérer le recrutement ». Ensuite, nous allons montrer le raffinement de chaque cas d’utilisation
dans la prochaine section.
65
Dans cette section nous allons présenter le diagramme de cas d’utilisation du deuxième Sprint,
le raffinement et la description textuelle de quelques cas d’utilisation.
2.2.1. Cas d’utilisation « Gérer les candidats »
Figure 50 DIAGRAMME DE CAS D'UTILISATION "Gérer les candidats"
▪ Cas d’utilisation « Gérer les pièces jointes du candidat »

Le raffinement du sous cas d’utilisation « Gérer les pièces jointes du candidat » est similaire à
celui du cas « Gérer les pièces jointes de l’employé ».
2.2.2. Cas d’utilisation « Gérer les postes à pourvoir »
Figure 51 DIAGRAMME DE CAS D'UTILISATION " Gérer les postes à pourvoir "
66
2.2.3. Cas d’utilisation « Gérer les offres d'emploi »
Figure 52 DIAGRAMME DE CAS D'UTILISATION " Gérer les offres d'emploi "
2.2.4. Cas d’utilisation « Gérer les demandes de stage »
Figure 53 DIAGRAMME DE CAS D'UTILISATION " Gérer les demandes de stage "
2.2.5. Cas d’utilisation « Traiter les demandes de stages »
Le sous cas d’utilisation « Traiter la demande de stage » va être représenter dans la section
suivante par un diagramme de bpmn 2.0.
67
Figure 54 DIAGRAMME DE CAS D'UTILISATION " Traiter les demandes de stages "
2.2.6. Cas d’utilisation « Gérer les demandes d’emploi »
Figure 55 DIAGRAMME DE CAS D'UTILISATION " Gérer les demandes d'emploi "
2.2.7. Cas d’utilisation « Traiter les offres d’emploi »
Figure 56 DIAGRAMME DE CAS D'UTILISATION " Traiter les demandes de stages "
68

En suivant la même démarche que le premier sprint et pour éviter les répétitions, nous
présenterons dans cette section la description textuelle des cas d'utilisation suivants : « Ajouter
demande de stage », « Modifier demande d’emploi », « Consulter le tableau de bord »,
« Consulter le tableau de bord »" et « Traiter demande d’emploi ».
2.3.1. Description textuelle du cas « Ajouter demande de stage »

Tableau 26 Description textuelle du cas « Ajouter demande de stage »
Cas d’utilisation Ajouter demande de stage

Acteurs Agent de saisie
Post-condition Nouvel demande ajouté
Scénario principal 1-L'acteur choisit d’ajouter une demande de stage
3-L’acteur choisit le candidat, remplit les champs
nécessaires et valide l’ajout de la demande
5-Le système ajoute la nouvelle demande de stage
6-Le système redirige l’acteur vers la liste des demandes de
stages.

formats invalides)
2.3.2. Description textuelle du cas « Modifier demande d’emploi »

Tableau 27 Description textuelle du cas « Modifier demande d'emploi »
Cas d’utilisation Modifier demande d’emploi
Acteurs Agent de saisie
69
Liste des avancements affichée
Post-condition Avancement mis à jour
Scénario principal 1-L'acteur choisit la demande à modifier et valide son choix

2-Le système affiche le formulaire de modification
contenant les données actuelles de demande
3-L'acteur modifie les champs voulus et valide la
modification
5-Le système enregistre la modification de demande
6-Le système redirige l’acteur vers la liste des demandes

formats invalides)
2.3.3. Description textuelle du cas « Consulter le tableau de bord »

Tableau 28 Description textuelle du cas « Consulter le tableau de bord »
Cas d’utilisation Consulter le tableau de bord
Acteurs Agent de saisie, Responsable du recrutement, Responsable

RH, directeur
Post-condition Le tableau de bord affiché
Scénario principal 1-L'acteur demande le tableau de bord à consulter

2-Le système affiche le tableau de bord

2-a-1-le système affiche un message de type « aucun
résultat trouvé »
70
2.3.4. Description textuelle du cas « Traiter demande d’emploi »

Tableau 29 Description textuelle du cas « Traiter demande d’emploi »
Cas d’utilisation Traiter demande d’emploi

Acteurs Agent de saisie, Responsable du recrutement, Responsable
RH, directeur
Précondition Acteur authentifié, Tableau de bord affiché
Post-condition La demande traitée
Scénario principal 1-L'acteur choisi une demande à traiter
2-Le système affiche le formulaire contenant les données
actuelles de la demande et des champs vides.
3-L’acteur remplit les champs nécessaires et valide sa
décision
5-Le système enregistre la décision sur la demande
6-Le système redirige l’acteur vers le tableau de bord.

formats invalides)
3. Analyse
Dans cette partie, nous allons illustrer les diagrammes UML qui nous ont aidés au
développement de ce sprint à commencer par les diagrammes des séquences systèmes.

Nous allons traiter à ce niveau les digrammes de séquence systèmes suivant : « Ajouter
demande de stage », « Consulter tableau de bord » et « Traiter demande d’emploi ».
71
3.1.1. Diagramme de séquences système du cas « Ajouter demande de stage »
Figure 57 DIAGRAMME DE SEQUENCE SYSTEME DU CAS " Ajouter demande de stage "
3.1.2. Diagramme de séquences système du cas « Consulter tableau de bord »
Figure 58 DIAGRAMME DE SEQUENCE SYSTEME DU CAS " Consulter tableau de bord "
72
3.1.3. Diagramme de séquences système du cas « Traiter demande d’emploi »
Figure 59 DIAGRAMME DE SEQUENCE SYSTEME DU CAS " Traiter demande d'emploi "

Comme dans le sprint précédent, nous allons modéliser quelques digrammes des classes
participantes du sprint 2.
73
3.2.1. Diagramme des classes participantes du module « gérer candidat »
Figure 60 DIAGRAMME DE CLASSES PARTICIPANTES DU MODULE "Gérer candidat"
3.2.2. Diagramme des classes participantes du module « Traiter demande

d’emploi »
Figure 61 DIAGRAMME DE CLASSES PARTICIPANTES DU MODULE "Traiter demande d'emploi"
4. Conception
A ce niveau, nous allons présenter les diagrammes de bpmn, les diagrammes de séquence
détaillés et le diagramme des classes du Sprint 2.
74
4.1. Diagrammes de BPMN 2.0

Le BPMN 2.0 est un langage graphique permet de modéliser des diagrammes représentant le
déroulement et l’enchainement des tâches. Il indique les étapes de décision et la transition d’un
flux d’activités. Dans notre cas les différentes décisions qui doivent être effectuées par
l’utilisateur sont :
Ci : complément d’information : la demande transférée vers l’acteur responsable, qui introduira
les informations demandées et passerra la main à l’acteur suivant.
Rejet : Si la demande ne vérifie pas certaines conditions de validité.
Accepter : La demande vérifie les conditions nécessaires.
Signature : La demande est signée.
Nous notons que à travers ce digramme nous pouvons voir qui effectue quoi en regardant dans
quel couloir se situe la tâche.
4.1.1. Diagramme de BPMN 2.0 de la demande de stage

Dans La figure 54 nous avons modélisé le diagramme de bpmn2.0 de la demande de stage.
D’abord L’utilisateur doit remplir le formulaire de la demande qui a comme profil « Agent de
saisie ». Ensuite, la demande s’affiche dans le tableau de bord de tous les utilisateurs qui
possèdent comme profil « Responsable de recrutement ». Et finalement l’utilisateur peut choisir
sa décision.
Figure 62 Diagramme de BPMN 2.0 de la demande de stage
75
4.1.2. Diagramme de BPMN 2.0 de la demande d’emploi

La figure 63 respecte la même logique que le diagramme de bpmn2.0 de la figure 62.
Figure 63 Diagramme de BPMN 2.0 de la demande d'emploi
76

4.2.1. Diagramme de séquence du cas « Traiter demande d’emploi »
Figure 64 DIAGRAMME DE SEQUENCE OBJET DU CAS " Traiter demande d’emploi "
77

type pièce jointe
- id : Long
1..1 - type_pièce : String
avoir
0..*
Piéce_jointe_candidat
- id : Long HistoriqueStage
- label : String - id : Long
1..* - url : String - dateDecision : Date
- nom : String - decideur : String
- type_piece : int - decision : String
- signataire : String
Posséder - motif : String
1..*
candidat posséder
- id : Long
1..1 - cin : String 1..1
- nom : String
- prenom : String DemandeStage
- genre : String - id : Long
- date_naissance : Date 1..1 avoir - date_demande : Date
- adresse_electronique : String 1..* - date_debut : Date
avoir - num_tel : Long - date_fin : Date
- adresse : String - Periode : String
1..1 - etat_civil : String - Etablissement : String
- etat : String
1..*
DemandeEmploi
- id : Long offre_emploi
- date_demande : Date - id : Long
- description : String - description_poste : String
- dateDecision : Date 1..* contenir 1..1 - date_limite : Date
- decideur : String - date_debut : Date Poste à pourvoir
- decision : String - duree_contrat : String
1..* disposer - id : Long
- singnataire : String - diplome : String
1..1 - description_poste : String
- motif : String - experience_prof : String
- nationalite : String
- ageLimite : int
1..1 1..* 1..*
posséder contenir
contenir
1..*
HistoriqueEmploi
- id : Long 1..1 1..1
- dateDecision : Date
- decideur : String Poste Departement
- decision : String - id : Long - id : Long
- singnataire : String - poste : String - departement : String
- motif : String
5. Implémentation
Dans cette partie du chapitre, nous allons présenter le dictionnaire des données, le diagramme
de composant ainsi que les interfaces du deuxième Sprint.
78
5.1. La génération de la BD plus le dictionnaire des données

Tableau 30 Table "candidat "

NOT NULL
Cin Varchar (Max) NOT NULL
Nom Varchar (Max) NOT NULL
Prenom Varchar(Max) --
Genre Varchar(Max) --
Date_de_naissance Date --
Adresse_ectronique Varchar(Max) NOT NULL
Num_tel Long --
Adresse Varchar(Max) --
Etat_civil Varchar(Max) --
Tableau 31 Table pièce jointe candidat

NOT NULL
Label Varchar(Max) NOT NULL
Nom Varchar(Max) --
Id_type_pièce Long FOREIGN KEY
Id_candidat Long FOREIGN KEY
Tableau 32 Table type pièce jointe

NOT NULL
type_pièce Varchar(Max) NOT NULL
79
Tableau 33 Table demande stage

NOT NULL
Date_demande Date NOT NULL
Periode Varchar(Max) --
Etablissement Varchar(Max) NOT NULL
Etat Varchar(Max) --
Tableau 34 Table Historique stage

NOT NULL
DateDecision Date NOT NULL
Decideur Varchar(Max) NOT NULL
Decision Varchar(Max) NOT NULL
Signataire Varchar(Max) NOT NULL
Motif Varchar(Max) --
Id_demande_stage Long FOREIGN KEY
Tableau 35 Table Demande_emploi

NOT NULL
Description Varchar(Max) --
80
Id_offre_emploi Long FOREIGN KEY
Tableau 36 Table Historique_emploi

NOT NULL
Motif Varchar(Max) NOT NULL
Id_demande_emploi Long FOREIGN KEY
Tableau 37 Table Offre_emploi

NOT NULL
Decription_poste Date NOT NULL
Date_Limite Varchar(Max) --
Date_debut Varchar(Max) NOT NULL
Duree_contrat Double --
Diplome Varchar(Max) --
81
Experince_prof Varchar(Max) --
Nationalite Varchar(Max) --
Age_limit Int --
Droit_civique Varchar(Max) --
Apptitude_physique Varchar(Max) --
Id_poste_pourvoir Long FOREIGN KEY
Tableau 38 Table poste_pouvoir

NOT NULL
Description_poste Varchar(Max) NOT NULL
Id_poste Long FOREIGN KEY
Id_departement Long FOREIGN KEY
Tableau 39 Table poste

NOT NULL
Poste Varchar(Max) NOT NULL
Tableau 40 Table département

NOT NULL
Département Varchar(Max) NOT NULL

A ce stade et comme le sprint président, nous allons présenter un diagramme de composants.
82
5.2.1. Diagramme de composants du cas d’utilisation « Gérer les candidats »
Figure 66 Diagramme de composants du cas d’utilisation « Gérer candidat »
Nous présentons dans cette section les différentes interfaces élaborées dans le sprint 2.
83
5.3.1. Interfaces d’ajouter ou modifier candidat
La figure 67 représente l’interface d’ajout d’un candidat par le responsable de recrutement.
Figure 67 Interface Ajouter Candidat
5.3.2. Interface de la Liste des candidats
La figure 68 représente l’interfaces de la liste des candidats.
Figure 68 Interface La liste des candidats
5.3.3. Interface d’ajouter une offre de recrutement
La figure 69 représente l’interface d’ajouter ou modifier une offre de recrutement.
84
Figure 69 Interface d’Ajouter offre de recrutement
5.3.4. Interface Modifier demande d’emploi
La figure 70 représente l’interface de modifier une demande de formation.
Figure 70 Interface de modifier demande d'emploi
6. Test
Comme dans le sprint précédent, nous allons représenter les tests de validation ainsi que les
tests unitaires du Sprint 2.
85
Le tableau 41 représente les scénarios associés au deuxième sprint.
Scénarios

attendu
Présenter toutes les Apparition de Conforme.

informations dans le candidat ajouté dans
formulaire d’ajout. la liste des candidats.
Test d’ajout d’un
Ne pas présenter Affichage d’une Conforme.
candidat
toutes les erreur.
informations dans le
formulaire d’ajout.
Choisir l’offre à Offre supprimer de Conforme

supprimer. la liste des offres de
Supprimer Offre re recrutements.
recrutement
Offre n’est pas Affichage d’une Conforme
supprimer. erreur.
6.2. Test unitaires
Comme le sprint président, nous allons procéder à des tests unitaires du deuxième Sprint.
Nous commençons par le code ensuite nous présentons le résultat par l’outil POSTMAN.
Cette méthode représente l’ajout dans demande et le lancement du process.
Figure 71 méthode d'ajouter demande stage
86
La figure 73 représente le résultat avec POSTMAN.
Figure 72 l'ajoute d’une demande de stage
La méthode de la figure 74 représente le code d’affichage des demandes de stage.
Figure 73 code GET les demandes de stage
Le résultat dans la figure 75.
87
Figure 74 L'affichage du résultat du méthode GET
Conclusion
Nous arrivons à la fin de développement du deuxième sprint qui concerne la gestion du
recrutement. Suivant le même plan de travail, nous présenterons dans le chapitre qui suit le
dernier sprint de ce projet.
88
Chapitre 5
Sprint 3 – Les flux de

travaux RH
Chapitre 5 Sprint 3 – Les flux de travaux RH
Introduction
Dans les sprints précédents, nous avons pu mettre en œuvre les fonctionnalités principales de
la GRH ainsi que les fonctionnalités liées au recrutement. Dans ce sprint, nous nous
intéresserons à toutes les autres fonctionnalités incluent les flux de travaux.
Le but de ce sprint était la réalisation des parties qui concerne les absences, la demande du
congé, la demande d'absences et la formation dans l'entreprise. De ce fait et en suivant la même
démarche adoptée pour les Sprints précédents, nous allons détailler les différentes phases de
développement au cours de ce sprint.
En partant par le même principe des sprints précédents, nous présentons dans ce tableau le
backlog du sprint 3.
Story (fonctionnalité) Estimation
Établir un état d’absence 1
Lister les états d’absence 1
Consulter les détails d’un état d’absence 1
Ajouter formation 1
Lister les formations 1
Modifier formation 1
Supprimer formation 1
Ajouter demande d’absence 1
Lister les demandes d’absence 1
Modifier la demande d’absence 2
Consulter la demande d’absence 1
Ajouter demande de congé 1
Lister les demandes de congé 1
Modifier la demande de congé 2
Consulter la demande de congé 1
90
Ajouter demande de formation 2
Lister les demandes de formation 1
Modifier la demande de formation 1
Consulter la demande de formation 1
Consulter le tableau de bord 4
Traiter la demande d’absence 3
Traiter la demande de congé 4
Traiter la demande de formation 3

Nous illustrons dans la figure 75 le diagramme du cas d’utilisation du notre troisième sprint.
91

2.2.1. Cas d’utilisation « Gérer les absences »
Nous notons que le sous cas d'utilisation « Établir un état d'absence » doit être effectué dans le
cas de non-fonctionnement du système de pointage.
Figure 76 DIAGRAMME DE CAS D'UTILISATION "Gérer les absences"
2.2.2. Cas d’utilisation « Gérer les demandes d’absences »
Figure 77 DIAGRAMME DE CAS D'UTILISATION "Gérer les demandes d'absence"
92
2.2.3. Cas d’utilisation « Traiter la demande d’absence »
Figure 78 DIAGRAMME DE CAS D'UTILISATION " Traiter les demandes d’absence "
2.2.4. Cas d’utilisation « Gérer les demandes de congé »
Figure 79 DIAGRAMME DE CAS D'UTILISATION " Gérer les demandes de congé "
93
2.2.5. Cas d’utilisation « Traiter la demande de congé »
Figure 80 DIAGRAMME DE CAS D'UTILISATION " Traiter la demandes de congé "
2.2.6. Cas d’utilisation « Gérer les formations »
Figure 81 DIAGRAMME DE CAS D'UTILISATION " Gérer les formations "
94
2.2.7. Cas d’utilisation « Gérer les demandes de formation »
Figure 82 DIAGRAMME DE CAS D'UTILISATION " Gérer les demandes de formation "
2.2.8. Cas d’utilisation « Traiter les demandes de formation »
Figure 83 DIAGRAMME DE CAS D'UTILISATION " Traiter les demandes de formation "

En conservant toujours le même principe que les sprints précédents, nous traitons dans cette
section la description textuelle des cas d'utilisation suivants : « Établir un état d’absence » et «
Traiter la demande de congé ».
2.3.1. Description textuelle du cas « Établir un état d’absence »
Tableau 43 Description textuelle du cas « Établir un état d’absence »
Cas d’utilisation Établir un état d’absence

Post-condition Nouvel état d’absence établie
Scénario principal 1-L'acteur demande d’ajouter une demande de congé
95
3-L’acteur remplit les champs nécessaires et valide l’ajout
5-Le système ajoute la nouvelle demande
6-Le système redirige l’acteur vers la liste des demandes.
4-b- -Le système saisit des données invalides (de types ou formats
invalides)
2.3.2. Description textuelle du cas « Traiter la demande de congé »
Tableau 44 Description textuelle du cas « Traiter la demande de congé »
Cas d’utilisation Traiter la demande de congé

Acteurs Directeur RH, chef hiérarchique, DARH, responsable RH,
directeur, chef de service personnel
Précondition Acteur authentifié, Tableau de bord affiché
Post-condition La demande traiter
Scénario principal 1-L'acteur choisit une demande à traiter
2-Le système affiche le formulaire contenant les données

actuelles de la demande et des champs vides.
3-L’acteur remplit les champs nécessaires et valide sa décision
5-Le système enregistre la décision sur la demande
6-Le système redirige l’acteur vers le tableau de bord.
4-b- -Le système saisit des données invalides (de types ou formats
invalides)
96
3. Analyse
Nous allons traiter à ce niveau les digrammes de séquence systèmes et le diagramme de classe
participante.

3.1.1. Diagramme de séquences système du cas « Établir un état d’absence »
Figure 84 DIAGRAMME DE SEQUENCE SYSTEME DU CAS " Établir un état d’absence "
97
3.1.2. Diagramme de séquences système du cas « Traiter la demande de congé »
Figure 85 DIAGRAMME DE SEQUENCE SYSTEME DU CAS " Traiter la demande de congé "
98

3.1.3. Diagramme des classes participantes du module « traiter demande de
congé »
Figure 86 DIAGRAMME DE CLASSES PARTICIPANTES DU MODULE "Traiter demande de congé"
4. Conception
Comme le deuxième sprint nous allons présenter dans cette section les diagrammes de BPMN,
les diagrammes de séquence détaillés et le diagramme des classes du Sprint 3.
4.1. Diagrammes de BPMN 2.0
En suivant la même démarche adoptée au cours du sprint 2, nous présentons dans cette section
tous les digrammes de BPMN 2.0 utilisé dans ce sprint.
4.1.1. Diagramme de BPMN 2.0 de la demande de congé
Dans La figure 71 nous avons modélisé le diagramme de BPMN 2.0 de la demande de congé.
99
Figure 87 Diagramme de BPMN 2.0 de la demande de congé
100
4.1.2. Diagramme de BPMN 2.0 de la demande d’absence
Dans La figure 72 nous avons modélisé le diagramme de BPMN 2.0 de la demande d’absence.
Figure 88 Diagramme de BPMN 2.0 de la demande d'absence
101
4.1.3. Diagramme de BPMN 2.0 de la demande de formation
Dans La figure 73 nous avons modélisé le diagramme de BPMN 2.0 de la demande d’absence.
Figure 89 Diagramme de BPMN 2.0 de la demande de formation
102

4.2.1. Diagramme de séquence du cas « Ajouter demande de congé »
Figure 90 DIAGRAMME DE SEQUENCE OBJET DU CAS " Ajouter demande de congé "
103

HistoriqueConge
- id : Long
- decideur : String
- decision : String
- singnataire : String Employe
- motif : String - id : Long
- matricule : String
1..*
- nom : String
- prenom : String Absence
posséder
- num_cin : Long - id_absence : Long
- date_naissance : Date - periode : String
1..1 - lieu : String - date_debut : Date
Demande_conge - genre : String - date_fin : Date
- adresse_electronique : String
- id : Long
- num_tel : String
- type_conge : String
- sit_fam : String 0..*
- date_depart : Date
- num_permis : Long
- date_retour : Date
- note : int
- raison_demande : String
- categorie_diplome : String
- piéce_justificative : String 0..* demander
- rue : String
- dateDecision : Date 1..1
- ville : String
- decideur : String avoir
- code_postale : int
- decision : String 1..1
- date_debut : date
- singnataire : String
- nom_conjoint : String
- motif : String
- prenom_conjoint : String
1..1 - cin_conjoint : Long 1..1
- num_cnss_conjoint : Long
avoir 1..1
- num_cnrps_conjoint : Long
1..* - fonction_conjoint : String
- image : Byte
Piéce_jointe demander
- id : Long 0..* demander
0..*
- label : String
Demande_absence
- url : String Demande_formation
- nom : String - id : Long
- id : Long
- type_piece : String - periode : String
- raison_formation : String Formation - date_debut : Date
- date_demande : Date - id : Long - date_fin : Date
- dateDecision : Date - sujet : String
1..* contenir - raison : String
- decideur : String
1..1 - date_debut : Date - piéce_justificative : String
- decision : String - date_fin : Date - dateDecision : Date
- singnataire : String - formateur : String - decideur : String
- motif : String
- decision : String
- motif : String
1..1
1..1
posséder
1..* posséder
HistoriqueFormation
1..*
- id : Long
HistoriqueAbsence
- decideur : String - id : Long
- decision : String - dateDecision : Date
- singnataire : String - decideur : String
- motif : String - decision : String
- motif : String
5. Implémentation
Dans cette section nous allons présenter le dictionnaire des données, le diagramme de
composant ainsi que les interfaces du troisième Sprint.
104
5.1. La génération de la BD plus le dictionnaire de données

Tableau 45 Table Historique_conge

NOT NULL
Id_demande_conge Long FOREIGN KEY
Tableau 46 Table demande_conge

NOT NULL
Type_conge Date NOT NULL
Date_depart Date NOT NULL
Date_retour Date NOT NULL
Raison_demande Varchar(Max) NOT NULL
Pièce_justificative Varchar(Max) --
105
Tableau 47 Table pièce_jointe

NOT NULL
label Varchar(Max) NOT NULL
Nom Varchar(Max) --
Type_pièce Int NOT NULL
Id_demande_conge Long FOREIGN KEY
Tableau 48 Table Absence

NOT NULL
periode Varchar(Max) NOT NULL
Tableau 49 Table demande_absence

NOT NULL
periode Date NOT NULL
Raison Varchar(Max) NOT NULL
Pièce_justificative Varchar(Max) --
106
Tableau 50 Table Historique_absence

NOT NULL
Id_demande_absence Long FOREIGN KEY
Tableau 51 Table demande_formation

NOT NULL
Raison_formation Varchar(Max) NOT NULL
107
Id_formation Long FOREIGN KEY
Tableau 52 Table formation

NOT NULL
Sujet Varchar(Max) NOT NULL
Formateur Varchar(Max) --
Tableau 53 Table Historique_formation

NOT NULL
Id_demande_formation Long FOREIGN KEY
108

5.2.1. Diagramme de composants du cas d’utilisation « Gérer les demandes de
congé »
Figure 92 Diagramme de composants du cas d’utilisation « Gérer les demandes de congé »
109

5.3.1. Interface d’établir un état d’absence d’un employé
La figure 93 représente l’interface d’établit l’état d’absence d’un employé au cas de

disfonctionnement de système de pointage.
Figure 93 Interface d'établir un état d'absence
5.3.2. Interface d’ajouter une demande de congé
La figure 93 représente l’interface d’ajouter une demande de congé.
Figure 94 Interface d'ajouter une demande de congé
110
5.3.3. Interface de Consulter le tableau de bord
L’interface présente dans la figure 95 représente le tableau de bord.
Figure 95 Interface le tableau de bord
5.3.4. Interface Traiter Demande
Les figures 96 et 97 représente les interfaces du formulaire de traitement d’une demande.
Figure 96 Interface traiter demande congé 1
111
Figure 97 Interface Traiter demande congé 2
6. Test
Nous présentons dans ce qui suit quelques tests de validation et tests unitaires que nous avons
effectué pour valider ce sprint.

Ce tableau représente quelques scénarios associés au sprint 3.
Scénarios

attendu
Présenter toutes les Apparition de la Conforme.

informations dans le formation ajoutée
formulaire d’ajout. dans la liste des
Test d’ajout d’un formations.
formation
Ne pas présenter Affichage d’une Conforme.
toutes les erreur.
informations dans le
formulaire d’ajout.
Consulter tableau de Demande Traiter et Conforme

bord, choisir une supprimer du tableau
demande et de bord pour le
Présenter toutes les profil qui attribuer la
décision.
112
Test de traiter informations dans le

demande Congé formulaire d’ajout.
Demande ne pas La demande reste Conforme

traiter dans le tableau de
bord
6.2. Test unitaires

Ce Niveau est consacré aux cas des test unitaires.
La figure 98 présente la méthode d’affecter la décision à une demande.
Figure 98 Code traiter demande
Les figure 99 et 100 présente les résultats avec l’outil POSTMAN.
Figure 99 Traiter décision
113
Figure 100 le résultat d'affecter l'observation à une demande
Conclusion
Avec ce dernier chapitre, nous arrivons à la fin de développements du module « les flux de
travail RH ». De ce fait, nous avons terminé la réalisation de ce sprint.
114
Conclusion et perspectives
Conclusion et Perspectives
Tout au long de notre projet de fin d'études, nous avons pu réaliser une solution de gestion des
flux de ressource humaine intégrant nativement un moteur workflow et assurant les interactions
avec un système GED. Le présent rapport couvre l’étude, la conception et l’implémentation de
notre solution. En appliquant la méthodologie Scrum, nous avons développé notre application
sprint par sprint.
Cette solution permet de gérer les missions principales du RH, de gérer le recrutement et de
gérer les fonctionnalités dans un environnement workflows tel que la demande de congé,
d'absence, et de formation. Aussi, elle permet d'automatiser et de dématérialiser tous les
processus liés à la gestion administrative des ressources humaines, de substituer les documents
et les dossiers en format papier par des dossiers électroniques. Ainsi, cette plateforme permet
de migrer les procédures basées sur la circulation de l'information en mode papier vers le mode
électronique afin d'améliorer la productivité, réduire les coûts et gagner du temps. Cette solution
devra aider les utilisateurs et les différents intervenants à collaborer sur des dossiers communs.
Durant la phase de réalisation de notre projet, nous nous sommes familiarisés au Framework
JEE AngularJS-Spring et à l’utilisation des techniques workflow (BPMN 2.0 et Activiti) et
GED, consommant les web services de type REST.
Les difficultés rencontrées lors de ce travail concernent principalement la montée en

compétence sur le socle de haut niveau technologique. Ce projet nous a permis d’approfondir
nos connaissances dans les bonnes pratiques de développement logiciel et la production de la
documentation. Au-delà de l’aspect technique, ce projet innovant nous a permis d’acquérir de
bonnes connaissances de la réalité du milieu professionnel. Nous nous sommes également
adaptés au teamwork et au travail collaboratif grâce aux contacts avec les membres de l’équipe
BNS ENGINEERING.
Finalement, notre travail ne s’arrête pas à ce niveau, en effet il sera nécessaire d’enrichir
fonctionnellement la solution à travers l’adjonction de nouveaux modules à l’ERP,
particulièrement liées à la gestion des processus de mobilité des employés ainsi qu’à la gestion
des compétences des ressources humaines.
115
Annexe
Annexe A : Passage du diagramme de classes UML au modèle

relationnel
Le choix du modèle logique dépend du choix du SGBD. Nous allons utiliser dans ce projet le
modèle relationnel. Pour passer du modèle conceptuel au modèle logique relationnel nous
appliquons les règles de transformation suivantes : [35]
Figure 101 Règle de passage d’une classe et id
Figure 102 Les associations
Figure 103 Association de type N :M
116
Annexe
Figure 104 Association de type 1 : N
Figure 105 Association de type 1 : 1
Figure 106 Héritage
117
Bibliographie et webographie
[1] « BNS ENGINEERING » http://www.bns.tn Consulté le 05/02/2017
[2] http://www.maformationsap.com/sap.html & https://www.sap.com/france/index.html
Consulté le 03/01/2017
[3] http://www.icdc.caissedesdepots.fr/Dematerialisation-des-processus-et-archivage Consulté
le 21/02/2017
[4] http://fr.appian.com/about-bpm/definition-of-a-business-process/ Consulté le 21/02/2017
[5] http://wayofcode.fr/implmentation-de-services-web-rest-avec-le-framework-spring/
[6] https://fr.wikipedia.org/wiki/Business_process_model_and_notation
&http://bonitasoft.developpez.com/tutoriels/business-process-management/guide-ultime-
bpmn2/ Consulté le 28/02/2017
[7] http://www.agiliste.fr/guide-de-demarrage-scrum/ Consulté le 03/06/2017
[8] https://www.pentalog.fr/notre_demarche/methode-agile-scrum.htm Consulté le 03/06/2017
[9]https://openclassrooms.com/courses/debutez-l-analyse-logicielle-avec-uml/uml-c-est-quoi
[10] http://www.bpms.info/bpmn-la-norme-du-bpm/ Consulté le 04/04/2017
[11] https://spring.io/tools/sts Consulté le 15/03/2017
[12] http://www.bpms.info/outils-d-architecture-d-entreprise/#Bizagi Consulté le 21/02/2017
[13] https://fr.wikipedia.org/wiki/Activiti_(logiciel) Consulté le 15/03/2017
[14] http://www.open-source-guide.com/Solutions/Applications/Ged-ecm/Alfresco &
http://www.starxpert.fr/PDF/10_cas_usage_alfresco.pdf Consulté le 21/02/2017
[15] http://blog.xebia.fr/2013/06/05/jai-essaye-bower-loutil-de-gestion-des-dependances-
front-end/ Consulté le 20/03/2017
[16] http://www.pulsar-informatique.com/services/ged-open-source/modalites-d-acces-d-une-
ged/interoperabilite-et-ged/standard-cmis Consulté le 15/03/2017
[17] https://fr.wikipedia.org/wiki/Oracle_Database Consulté le 16/03/2017
[18] https://fr.wikipedia.org/wiki/Apache_Maven Consulté le 16/03/2017
[19] https://fr.wikipedia.org/wiki/PowerAMC Consulté le 16/03/2017
[20] http://docs.spring.io/spring/docs/4.3.3.RELEASE/spring-framework-
reference/html/overview.html & http://jean-luc.massat.perso.luminy.univ-amu.fr/ens/jee/tp-
spring.html Consulté le 03/16/2017
[21] http://www.groupeafg.com/spring-boot-kesako/ Consulté le 26/03/2017
[22] https://projects.spring.io/spring-security/ Consulté le 26/03/2017
118
[23] https://www.synbioz.com/blog/introduction_a_angularjs Consulté le 26/03/2017

[24] http://gardeux-vincent.eu/Documents/ProjetJEE/JMB_Hibernate_Stripes/hibernate2.html
[25] https://openclassrooms.com/courses/prenez-en-main-bootstrap/mise-en-route-8 Consulté
le 26/03/2017
[26] F. V. Pascal Roques, « UML2 en action de l'analyse des besoins à la conception ». Edition
Eyrolles, 2007.
[27]
https://www.ibm.com/support/knowledgecenter/fr/SS8PJ7_9.1.2/com.ibm.xtools.modeler.doc
/topics/cucd.html Consulté le 15/04/2017
[28] http://www.usabilis.com/ressources/prototypage-maquettage/ Consulté le 15/04/2017
[29] http://wayofcode.fr/implmentation-de-services-web-rest-avec-le-framework-spring/
[30] http://www.figer.com/publications/REST.htm#.WOk0sdI1_IU Consulté le 05/04/2017
[31]
http://www.prideparrot.com/blog/archive/2012/3/creating_a_rest_service_using_asp_net_web
_api Consulté le 05/04/2017
[32] https://wikimonde.com/article/Architecture_trois_tiers Consulté le 05/04/2017
[33] http://www-igm.univ-mlv.fr/~dr/COURS/analyse/node6.html Consulté le 16/04/2017
[34] http://laurent-audibert.developpez.com/Cours-UML/?page=mise-en-oeuvre-uml Consulté
le 16/04/2017
[35] http://docplayer.fr/13702624-Chapitre-3-le-modele-relationnel.html Consulté le
16/05/2017
119
‫الملخص‬
‫يندرج هذا التقرير كجزء من مشروع التخرج المنجز في شركة األنظمة المعلوماتية بهدف الحصول على الماجستير المهني‬
‫ هذا المشروع يعنى بتصميم وبرمجة برنامج تطبيق ويب بهدف التصرف‬.‫الملتميديا وقواعد البيانات ودمج المنظومات‬
.‫البشرية‬ ‫ يسمح هذا التطبيق بإدارة التنظيم اإلداري للموارد‬.‫وإدارة الموارد البشرية‬
Résumé
Le présent rapport été élaboré dans le cadre du projet de fin d’étude au sein de la société BNS
ENGINEERING, afin d’obtenir le diplôme de Mastère professionnel en Modélisation, Bases
de Données et Intégration des Systèmes. Notre projet permet de concevoir et mettre en œuvre
un système de gestion des flux des ressources humaines. Cette solution permet la gestion
administrative des ressources humaines.
Mots-clés : ERP, JEE, GRH, Workflow, RESTful
Abstract
This report was prepared as the final of studies project to obtain a Master's Degree in Modeling,
Databases and Systems Integration. Our graduation project aims to design and implement an
application that dematerializes the business processes (BPM) of Human Resources
Administration, handle requests and manage the workflow. This solution will allow Treasury
configuration and setting, manage the movements and manage the bank reconciliations.
Keywords : ERP, JEE, GRH, Workflow, RESTful

Rapportlaouinisarrapfevf 180628200603

Transféré par

Droits d'auteur :

Formats disponibles

Rapportlaouinisarrapfevf 180628200603

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapportlaouinisarrapfevf 180628200603

Transféré par

Droits d'auteur :

Formats disponibles

Code : 353 Année Universitaire : 2016 / 2017

Présenté en vue de l'obtention du Diplôme de

Modélisation et Dématérialisation des Processus

ESEN M. Chiheb BEN NSIR

A celle qui m'a porté dans son ventre neuf mois

A ma petite sœur Chaima

A mes très chers oncles Mounir, Mouhamed, Hechmi, Sadok et Allala

A tous mes meilleur(e)s ami(e)s

Je remercie aussi Monsieur Jameleddine El KAMEL, le directeur de l'entreprise BNS

AVD : Avis de la Direction et annotation

DARH : Directeur de l’Administration et des Ressources Humaines

ERP : Enterprise Ressource Planning

GED : Gestion Electronique des Documents

GRH : Gestion des Ressources Humaines

IHM : Interface homme-machine

PGI : Progiciel de Gestion Intégré

PME : Petites et Moyennes Entreprises

Pourtant la révolution numérique est en marche, il y apparaît cependant que beaucoup

Particulièrement, le rôle des ressources humaine au cœur de l’organisation dans le cadre de

Le second chapitre « Planification et architecture » appelé aussi sprint 0, portera sur

Le quatrième chapitre « Sprint 2- Gestion du recrutement » est dédié à la présentation du

1. Présentation de l’organisme d’accueil

1.1. Fiche d’identité de BNS ENGINEERING

Figure 1 FICHE D'IDENTITE DE BNS

1.2. Activités de BNS ENGINEERING

BNS ENGINEERING a participé à la réussite de plusieurs projets informatiques en Tunisie et

2.1. Cadre du projet

2.2. Etude de l’existant

2.2.1. La plateforme OpenERP/Odoo

Figure 2 Interface demande de congé dans l'Odoo

2.2.2. La plateforme SAP

Dans ce cadre le module gestion des ressources humaines permet de :

▪ Gérer chaque employé d'un point de vue administratif

Cette figure représente une capture d’écran d'interface Du PGI SAP.

Figure 3 Exemple d'interface Du PGI SAP

2.2.3. Critique de l’existant

2.3. Solution à proposer

▪ Dans la première étape, il s’agit d’étudier, d’analyser, de normaliser puis de modéliser

2.3.1. Concepts liés à la solution à proposer

▪ La dématérialisation des processus

Le BPMN est facilement compréhensible par :

▪ L’analyste métier qui modélise les processus conceptuellement

3. Choix de la méthodologie de développement

3.1. La méthodologie de Travail Scrum

La méthodologie Scrum est donc un cadre de travail permettant la gestion du développement

Concrètement, cette méthode nécessite 4 types de réunions :

L’avantage de la méthode est de réduire au strict minimum la documentation afin de gagner en

3.1.1. Pourquoi Scrum ?

Adaptabilité maximale pour du développement de produits et d’applications : la composition

Augmentation de la communication : en travaillant dans la même salle de développement, ou

Augmentation de la productivité : en supprimant certaines “contraintes” des méthodes

3.1.2. L’équipe et les Rôles

3.1.3. Les artefacts

3.2. Les langages de modélisation

3.2.2. Business Process Model Notation BPMN

3.3. Environnement de travail

1. Recueil des besoins

1.1. Identification des acteurs

L'administrateur : C’est le gérant de ce module du progiciel. Il a le droit de gérer les affaires