Rapport

Introduction générale
Grace à la diversité des moyens de l’administration des entreprises, le développent de

traitement des informations est devenus de plus en plus une nécessité indispensable. C’est pour
cela, la stratégie de mettre en place un processus Rh cède à assurer l’accélération, la
centralisation et la précision de traitement d’information en garantissant un tel niveau de sécurité
et stabilité à fin de faciliter les taches administratives et les rendre plus efficaces.
Dans ce cadre, la société « SmartUp » adopte la création et l’implémentation d’un système

de communication entre la direction des ressources humaines et les employés. Ce système va
diminuer les charges du travail responsable Rh, et via se système les employés peuvent accéder
facilement à leurs informations personnelles et professionnelles.
Ce rapport s'articule autour de quatre chapitres qui présentent l'ensemble des travaux
réalisés au cours de ce projet.
Le premier chapitre « Contexte général », consiste à présenter le cadre général du projet,

une présentation de l’organisme d’accueil, une étude de l’existant et la solution proposé ainsi le
choix de la méthodologie de conception.
Dans le deuxième chapitre « Analyse et spécification des besoins », on se concentre sur la

les différents types des besoins : fonctionnels et non fonctionnels. Ainsi l’extraction des
différents futurs utilisateurs du système, pour arriver enfin à mettre une vue sur l’utilisation
générale du système et leurs scénarios.
Dans le troisième chapitre « Conception et choix technologiques », consiste à exposer la

conception du système selon une présentation de l’architecture utilisé et de clôturer par les choix
technologiques.
Le dernier chapitre « Réalisation », sera dédié à une description de l’implémentation tel
que les outils de développements et les interfaces de l’application.
Le rapport se termine par une conclusion générale qui synthétise le travail réalisé.
Chapitre 1 : Contexte générale
Introduction :
Dans ce premier chapitre, On doit tout d’abord mettre le projet dans son cadre, ensuite
on va présenter l’organisme d’accueil.
Par suite, on va extraire les problématiques qui sont à l’origine de la demande de la

réalisation de notre travail, ainsi la solution proposé tout en précisant la méthodologie de
conception suivie.
1.1. Cadre générale :
Le présent projet « Architecture micro-services pour le développent d’une application

portail Rh » est choisi comme projet de fin d’étude pour l’obtention de diplôme national
d’ingénieur en Téléinformatique de l’Institut Supérieure de l’Informatique et de Technique de
Communication de Hammam Sousse (ISITCom) qui était réaliser au sein de la société
« SmartUp». Mon stage s’est déroulé sur une période de six mois. Cette période a été consacrée
principalement à l’étude conceptuelle de l’application, à l’apprentissage des outils et au
développement.
1.2. Organisme d’accueil :
1.2.1. Présentation :
Société : SmartUp
Adresse : 53, Rue des minéraux La Charguia 1, 2035 Tunis –Tunisie
Téléphone : +216 70 132 152

Fax : +216 70 200 901
Figure 1:logo de société "Smart Up"
1.2.2. Services
Les axes d’expertise de SmartUp sont :
 Conseil en systèmes d’informations intégrés

 Rationalisation des processus
 Mise en place et intégration de solution innovantes
 Développements spécifiques
 Formations avec des méthodologies approuvées
 Consulting et développement sur mesure
 Maitrise des coûts
1.3. Etude de l’existant :
La gestion Rh comprend des fonctions administratives et opérationnelles. Dans ce projet,

on va étudier les tâches suivantes :
 Demander un congé
 Demander un frais personnel
 Demander une avance de salaire
 Consulter des documents administratifs (fiche de paie, solde de congé….)
 Gérer les employés
Le processus Rh du sein de l’entreprise « SmartUp» se déroule actuellement de la
manière classique suivante : les dossiers des employés et les demandes sont réalisés sous format
papier.
Pour mieux comprendre le processus existant, on va expliquer le déroulement de
quelques tâches:
La procédure de demande de congé actuel est :
 L’employé doit remplir une demande de congé sous format papier et la déposé au
chef du service.
 Le chef du service doit signer cette demande et la déposé au chef du personnel.
 Le chef du personnel doit aussi signer cette demande et la déposé au directeur
général.
 Le directeur général doit signer cette demande et la déposé au service Rh qui
prend le relève.
 Le service Rh doit vérifier la demande et doit informer l’employé par un email.
1.4. Problématiques :
Cette étude présente un certain nombre de difficultés et d’insuffisances qui peuvent

aboutir à des défaillances dans des le processus de travail de la direction Rh.
Parmi les difficultés détectées, on peut citer :
 Difficultés de classement d’archivage et de suivi des dossiers car la majorité des
ressources sont sous format papier.
 Difficulté de la mise à jour des documents.
 La relation entre les employés et l’administration Rh est réduite.
 Perte de temps entre les services.
 Difficultés de consultation directement les documents administratifs.
 Le volume de travail administratif devient très important pour le service Rh.
1.5. Solution proposée :

 Besoins et objectifs :
- Minimiser les traitements sur support papier.
- Centraliser tous les échanges entre les employés et la direction Rh.
- Facilités l’accès direct aux documents.
- Réduire le volume de travail pour le service Rh.
 Solution envisagée :
Pour atteindre les objectifs exprimés précédemment, une application de portail Rh de
communication transactionnelle entre l’employé et la direction des ressources humaines
s’impose.
1.6. Choix de méthodologies :

Tout d’abord, pour réaliser ce projet on a opté à l’utilisation du langage de
modélisation unifié « UML » c’est un langage qui fournit une méthode normalisée de
modélisation graphique et textuel, qui nous aide à concevoir notre système cible.
Pour garantir le bon déroulement de ce projet, il est indispensable de choisir une
méthode de conception.
1.6.1. Comparaison :
Avant d’adopter une méthode de conception, on doit d’abord faire une comparaison
entre les différentes méthodes existantes, préciser tous les points forts et les points faibles de
chacune, ensuite déterminer celle qui soit convenable pour notre système cible. Ci-dessous un
tableau qui résume cette comparaison :
Méthodologies Description Points forts Points faibles

- Promu par - Itératif ; - Sa mise en
Rational ; - Exprime le œuvre est
- Cible des dialogue entre assez floue ;
projets formés les différents - Pas de
RUP
de plus de 10 intervenants couvrante des
(Rational Unified
personnes ; du projet ; différents
Process)
- Peut être à la - Propose phases en aval
fois un outil plusieurs et en amont du
prêt à l’emploi modèles de développemen
et peut être documents qui t.
une spécifient des
méthodologie. projets types.
- S’articule - Itératif ; - Assez plus
autour d’une - Dépose une superficiel sur
architecture ; grande place à les phases
- Cycle de la technologie situés en aval
développemen et à la gestion et en amont du
2TUP
t en Y ; des risques ; développemen
(Two Truck Unified
- Cible pour - Exprime les t ;
Process)
toutes les profils des - Ne présente
tailles des intervenants, pas des
projets. les prototypes documents
et les types.
plannings.
- Cible des - Itératif ; - Sa mise en
projets formés - Donne une œuvre est
au moins de importance assez floue ;
10 personnes ; aux aspects - Pas de
XP
- techniques ; couvrante des
(eXterme Programming)
- Innovant : différents
programmatio phases en aval
n en duo. et en amont du
développemen
t.
- Méthode - Donne la - La mise en

agile ; confiance aux œuvre du
- Se base sur développeurs ; développemen
des sprints - Chaque sprint t n’est pas
(itérations) de a un objectif précisée ;
Scrum
développemen précis et - Une forte
t. fournis une pression sur
fonctionnalité l’ensemble des
testée. membres de
l’équipe.
Tableau 1:Tableau comparatif des différentes méthodologies de conception
On peut conclure après cette comparaison, de choisir de suivre la méthode 2TUP dans
notre travail.
1.6.2. Le processus 2TUP :

 Définition de 2TUP :
2TUP (Two Truck Unified Process) implémente le processus unifié, c’est une méthode de
développement qui considérer le cycle de vie d’un logiciel sous forme incrémentale et itérative à
fin de s’adapter aux changements continuels dans l’organisation du système d’information à
représenter. En sens, il renforce le contrôle sur les capacités d’évolution et de correction de tels
systèmes.
 Description de la méthode 2TUP :
La méthode 2TUP sépare initialement les phases techniques de phases fonctionnelles
avant de les regrouper dans la phase de réalisation.
La figure ci-dessous présente les différentes phases de développement :
Figure 2: Modéle en Y(1)
La branche gauche est la branche fonctionnelle, qui contient deux phases :

- Capture des besoins fonctionnels : produit le modèle des besoins centrés sur les
fonctionnalités attendues des utilisateurs. Elle exprime, au plus tôt le risque de
produire un système inadapté aux utilisateurs.
- L’analyse : C’est l’étude en détail des besoins fonctionnels pour obtenir une idée
sur le système à réaliser en termes de métier.
La branche droite est la branche technique, qui intègre deux phases :
- La capture des besoins technique : Contient toutes les contraintes sur la
conception du système ainsi il recense les contraintes sur les choix de
dimensionnant. Il expose la spécification des outils ainsi la structure des
matériels et les prés requis d’architecture technique.
- La conception générique : Exprime les composants nécessaires à la fabrication de
l’architecture technique. Elle est complètement indépendante et différente de la
branche gauche (la branche fonctionnelle). Son objectif est de réutiliser le même
mécanisme pour tout le système. Cette conception permet de former le squelette
du système : réaliser un prototype qui soit validé avec le principe de codage et les
tests.
La branche du milieu intègre quatre phases :
- La conception préliminaire : permet l’application des concepts qui sont liés aux
fonctionnalités du système et l’intégration des composants techniques avec le
système, c’est-à-dire, l’intégration des fonctions métiers et applicatives, qui sont
définit dans la phase de conception générique, dans l’architecture technique.
- La conception détaillée, qui permet à étudier la réalisation de chaque
composant.
- L’étape de codage : qui produit ces composants et test les unités de code réalisé.
- L’étape de recette : qui permet la validation de fonctionnalités du système
développé.
Conclusion :
Dans ce chapitre, on a essayé de présenter la société ainsi que les différentes difficultés
existantes et les solutions attendus, ensuite on a parlé de la méthodologie à suivre pour arriver à
mettre en place notre projet.
Cette partie est très nécessaire car, on pourra facilement, grâce à elle, d’extraire dans le
chapitre qui suit notre spécification des besoins tels que les besoins fonctionnels et non
fonctionnels.
Chapitre 2 : Analyse et Spécification des besoins
Introduction :
Avant de commencer ce chapitre, et en se rapportant au chapitre précédent, on peut dire
que la spécification des besoins, qui constitue une étape déterminante dans la réalisation de notre
projet, ne sera détecté qu’après l’étude des problématiques de l’existant.
Dans ce chapitre, on commence, tout à d’abord, par l’étude des besoins fonctionnels,
ainsi que la définition des besoins non fonctionnels (ou dites techniques), après on fera
l’extraction des différents acteurs du ce système pour arriver, enfin, à réaliser le diagramme de
cas d’utilisation et à identifier les scénarios.
2.1. Spécification des besoins :

La spécification des besoins est une phase très importante et nécessaire pour le
développement de notre application. Cette phase est la traduction des besoins des utilisateurs sous
la forme de documentations techniques et conceptuelles. Il définit les besoins fonctionnels et non
fonctionnels de notre application, ainsi l’extraction des cas d’utilisation proposés par le sujet pour
mettre en valeur le raisonnement conceptuel.
2.1.1. Besoins fonctionnels :
A ce niveau, on va étudier les différentes fonctionnalités attendues du futur système et

ceci en le décomposant sous la forme des modules :
 Gérer les employés :
L’administrateur de l’application aura la main de traiter les informations des différents
employés, ce traitement lui permet de :
- Ajouter un nouvel employé
- Supprimer un employé
- Consulter un employé
- Modifier les informations d’un employé
L’administrateur Rh aura la main de :
- Activer un employé
- Désactiver un employé
- Consulter un employé
Selon ces options :

L’administrateur de l’application pourra ajouter un nouvel employé en tapant ses
informations personnelles, à ce niveau l’administrateur Rh pourra activer cet employé et lui
attribuer un mot de passe qui est généré automatiquement par le système.
En effectuant une recherche, l’administrateur de l’application et l’administrateur Rh
auront la possibilité de consulter les informations des différents employés. A ce niveau,
l’administrateur de l’application pourra sélectionner un employé et modifier ses informations,
ainsi l’administrateur Rh pourra désactiver un employé. La suppression des employés se fait en
supprimant un employé qui n’est plus actif.
 Demander un congé :
Le système doit fournir les fonctionnalités suivantes pour ses employés et aussi pour
l’administrateur de l’application de :
- Ajouter un congé
- Consulter les congés
- Supprimer un congé
- Modifier un congé
- Consulter les congés
- Valider les congés
Pour valider un congé, l’employé et l’administrateur de l’application doivent remplir le
formulaire de la demande de congé qui sera validé par l’administrateur Rh en tapant les
informations nécessaires tels que la date début, la date fin, le type de congé ( le type de congé soit
géré par l’administrateur de l’application tels que il pourra ajouter, modifier, supprimer, consulter
les types de congé).
L’employé et l’administrateur de l’application auront la main de consulter et de suivre
ces congés.
Suite à une recherche (par statut ou par date de demande), l’administrateur Rh aura la
possibilité de consulter les demandes de différents employés.
Si la demande ne sera pas valider, l’employé pourra supprimer cette demande.
 Demander une avance sur salaire :

- Ajouter une demande d’avance
- Consulter les demandes d’avance
- Supprimer une demande d’avance
- Modifier une demande d’avance
- Consulter les demandes d’avance
- Valider les demandes d’avance
Pour valider cette demande, l’employé et l’administrateur de l’application doivent
remplir le formulaire de la demande d’une avance de salaire qui sera validé par l’administrateur
Rh en tapant les informations nécessaires tels que le montant…
ces demandes.
Si la demande ne sera pas valider, l’employé pourra supprimer ou modifier cette
demande.
 Demander un frais personnel :

- Ajouter une demande de frais
- Consulter les demandes de frais
- Supprimer une demande de frais
- Modifier une demande de frais
- Consulter les demandes de frais
- Valider les demandes de frais
remplir le formulaire de la demande de frais personnel qui sera validé par l’administrateur Rh en
tapant les informations nécessaires tels que le montant, la date de mission
ces demandes.
demande.
 Demander modification des informations personnelles :
- Ajouter une demande de modification
- Consulter les demandes de modification
- Supprimer une demande de modification
- Modifier une demande de modification
- Consulter les demandes de modification
- Valider les demandes de modification
remplir le formulaire de la demande de modification des informations personnelles qui sera
validé par l’administrateur Rh en tapant les informations nécessaires tels que la description, le
type de modification ( le type de modification soit géré par l’administrateur de l’application tels
qu’il pourra ajouter, modifier, supprimer, consulter les types de modification).
ces demandes.
demande.
 Consulter des documents administratifs :

Le système doit donner la main aux employés et administrateur de l’application de
consulter les documents administratifs tels que :
- Consulter bulletin de paie
- Consulter solde de congé
- Consulter attestation de salaire
L’option de consultation des documents administratifs permet à l’employé et à
l’administrateur de l’application de consulter et de suivre facilement ses propres documents tels
que : bulletin de paie, solde de congé, attestation de salaire.
 Gérer les notifications :
Pour faciliter la communication, le système doit avoir un espace pour les notifications.
Pour cela, il doit donner la main à l’administrateur Rh de :
- Consulter les notifications
- Créer une notification
- Supprimer une notification
L’employé aura la main de :
- Consulter les notifications
Lors de validation des demandes, l’administrateur Rh pourra créer une notification (qui
sera envoyé par un email) informant l’employé demandeur de l’état de sa demande (accepter ou
refuser).
Lors de l’activation d’un nouvel employé, une notification sera envoyée par un email à
l’employé concerné, de la part de l’administrateur Rh, contient le mot de passe et le login.
L’administrateur Rh pourra consulter ou supprimer les notifications. Aussi l’employé de
consulter les notifications.
2.1.2. Besoins non fonctionnels :
Après la spécification des besoins fonctionnels, on doit passer maintenant à exprimer et

à identifier les besoins non fonctionnels (besoins techniques).
L’identification des besoins non fonctionnels caractérise les fonctionnalités offertes par
le système aux utilisateurs. Parmi les besoins techniques, on peut citer :
 Ergonomie :
L’application doit fournir des interfaces utilisateurs conviviales, bien structurés de point
de vue contenu informationnel.
 La modularité :
L’application doit décomposer en module (déterminer dans la partie des besoins
fonctionnels), pour faciliter la gestion des différentes parties du système. Chaque module doit être
réalisé indépendamment.
 La fiabilité :
L’application doit exécuter correctement. En effet toute information qui lui est retournée
doit être certaine.
 La performance :
L’application doit être performante, c’est-à-dire, à travers ces fonctionnalités on prend à
toutes les exigences de l’utilisateur d’une manière optimale.
 La disponibilité :
L’application doit être disponible pour être utilisée à tout instant.
 La sécurité :
L’application doit fournir la sécurité au niveau d’accès compte personnel ainsi lors du
traitement de données. Elle doit aussi garantir la confidentialité et l’intégrité des informations et
des données des utilisateurs.
2.2. Identifications des acteurs :
Après l’extraction et l’étude des besoins fonctionnels attendus par le système, on est
arrivé à dégager trois acteurs principaux : un administrateur Rh (responsable du service Rh,
AdminRh), un administrateur de l’application (le manager, AdminApp) et (Employé).
Le tableau ci-dessous illustre toutes les opérations existantes et les utilisateurs
concernés :
Opérations
N° Module Consulter Ajouter Modifier Supprimer Activer/Désactiver Valider
1 Gérer les AdminApp
AdminRh
employés AdminApp AdminApp AdminApp AdminRh ____
2 Demander un AdminApp AdminApp AdminApp AdminApp

AdminRh Employé Employé Employé
congé ____ AdminRh
Employé
3 Demander AdminApp AdminApp AdminApp AdminApp

avance salaire ____ AdminRh
Employé
4 Demander un AdminApp AdminApp AdminApp AdminApp

frais personnel AdminRh Employé Employé Employé ____ AdminRh
Employé
5 Demander AdminApp AdminApp AdminApp AdminApp

modification
Employé
informations ____ AdminRh
personnelles
6 Consulter des AdminApp ____ ____ ____ ____ ____
Employé
documents
7 Gérer les AdminRh AdminRh ____ AdminRh ____ ____
Employé
notifications
Tableau 2: L'utilisation des opérations de système par les acteurs
2.3. Diagrammes des cas d’utilisation et identifications des scénarios :

2.3.1. Diagramme globale des cas d’utilisation :
A ce niveau, on doit présenter les fonctionnalités globales du système qui sont extraites
précédemment sous la forme d’un diagramme de cas d’utilisation qui relie les trois acteurs.
La figure ci-dessous illustre le diagramme de cas d’utilisation dans sa vue globale pour
cadrer les différents cas à traiter par la suite:
Figure 3:diagramme des cas d'utilisation globale
2.3.2. Cas d’utilisation «Gérer les employés » :

2.3.2.1. Diagramme de cas d’utilisation :
Dans la figure ci-dessous, on présente le diagramme des cas d’utilisations « Gérer les
employés » :
Figure 4:Diagramme de cas d'utilisation « Gérer les employés »
2.3.2.2. Identification du scénario :
Le tableau suivant résume les scénarii réalisés par les acteurs identifiés par les acteurs
identifiés au niveau du cas d’utilisation « Gérer les employés » :
 Cas d’utilisation : « Ajouter un nouvel employé » :
Acteurs AdminApp
Objectif Le module « Gérer les employés » permet l’administrateur de l’application
d’ajouter un nouvel employé.
Pré- condition Authentification de l’administrateur de l’application est réussite.
Post-condition Un message de réussite d’ajout s’affiche et l’employé sera ajouté dans la base.
Scénario nominal 1. L’administrateur de l’application s’authentifie au système.
2. L’administrateur de l’application clique sur « Gestion
Utilisateurs ».
3. L’administrateur de l’application clique sur le bouton « nouveau
utilisateur ».
4. L’administrateur de l’application remplit le formulaire d’ajout.
5. L’administrateur de l’application confirme d’ajout.
Scénario alternatif 1. Un message d’erreur s’affiche lors de l’authentification. Un
message s’affiche « login ou mot de passe incorrect ».
5. Un message d’erreur s’affiche quand l’administrateur de
l’application a tenté d’ajouter un employé existant. Un message
s’affiche
Tableau 3:Description du cas d'utilisation « Ajouter un employé »
 Cas d’utilisation : « Supprimer un employé »

Acteurs AdminApp
Objectif Le module « Gérer les employés » permet l’administrateur de l’application de
supprimer un employé.
Post-condition Un message de réussite de suppression s’affiche et l’employé sera supprimé
dans la base.
Utilisateurs ».
3. L’administrateur de l’application choisi l’employé qui va
supprimer.
4. L’administrateur de l’application clique sur le bouton
«supprimer ».

Tableau 4:Description du cas d'utilisation « Supprimer un employé »
 Le cas d’utilisation : « Consulter un employé »
Acteurs AdminApp, AminRh

Objectif Le module « Gérer les employés » permet l’administrateur de l’application et
l’administrateur Rh de consulter un employé.
Pré- condition Authentification de l’administrateur de l’application ou l’administrateur Rh est
réussite.
Post-condition La liste des employés sera affichée.
Scénario nominal 1. L’administrateur de l’application ou l’administrateur Rh
s’authentifie au système.
2. L’administrateur de l’application ou l’administrateur Rh clique
sur « Gestion Utilisateurs ».
3. L’administrateur de l’application ou l’administrateur Rh la liste
des employés.
Tableau 5:Description du cas d'utilisation « Consulter un employé »
 Cas d’utilisation : « Modifier les informations d’un employé »
Acteurs AdminApp
Objectif Le module « Gérer les employés » permet l’administrateur de l’application de
modifier les informations d’un employé.
Post-condition L’information sera modifiée dans la base.
Utilisateurs ».
3. L’administrateur de l’application cherche l’employé.
4. L’administrateur de l’application choisi l’employé.
5. L’administrateur de l’application clique sur le bouton
« modifier ».
6. L’administrateur de l’application sélectionne l’information à
modifier.
Tableau 6: Description du cas d'utilisation « Modifier les informations d'un employé »
 Cas d’utilisation : « Activer un employé » et « Désactiver un employé »
Acteurs AdminRh
Objectif Le module « Gérer les employés » permet l’administrateur Rh :
 Activer un employé
 Désactiver un employé
Pré- condition Authentification de l’administrateur Rh est réussite.
Post-condition Un message de réussite d’activation ou de désactivation s’affiche et l’employé
sera activer ou désactive dans la base.
Scénario nominal 1. L’administrateur Rh s’authentifie au système.
2. L’administrateur Rh clique sur « Gestion Utilisateurs ».
3. L’administrateur Rh choisi l’employé qui va activer ou
désactiver.
4. L’administrateur Rh clique sur le bouton « Activer »ou
« Désactiver ».
Tableau 7:Description du cas d'utilisation « Activer un employé » et le cas d'utilisation « Désactiver un employé »
2.3.3. Cas d’utilisation «Demander un congé » :

Dans la figure ci-dessous, on présente le diagramme des cas d’utilisations
« Demander un congé » :
Figure 5:Diagramme de cas d'utilisation « Demander un congé »

identifiés au niveau du cas d’utilisation « Demander un congé » :
 Cas d’utilisation : « Ajouter un congé »
Acteurs AdminApp, Employé

Objectif Le module « Demander un congé » permet l’administrateur de l’application et
l’employé d’ajouter un congé.
Pré- condition Authentification de l’administrateur de l’application et de l’employé est
réussite.
Post-condition La demande de congé sera ajoutée dans la base.
Scénario nominal 1. L’administrateur de l’application ou l’employé s’authentifie au
système.
2. L’administrateur de l’application ou l’employé clique sur
« Demandes de congé ».
3. L’administrateur de l’application ou l’employé clique sur le
bouton « ajouter demande ».
4. L’administrateur de l’application ou l’employé remplit le
formulaire de congé.
5. L’administrateur de l’application ou l’employé confirme l’ajout.
l’application ou l’employé a tenté d’ajouter des donnés non
valides. Un message s’affiche « les données ne sont pas invalide »
Tableau 8: Description du cas d'utilisation « Ajouter un congé »
 Cas d’utilisation : « Consulter les congé »

Acteurs AdminApp, AminRh, Employé
l’administrateur Rh et l’employé de consulter les congés.
Pré- condition Authentification de l’administrateur de l’application ou l’administrateur Rh ou
l’employé est réussite.
Post-condition La liste des demandes de congé sera affichée.
Scénario nominal 1. L’administrateur de l’application ou l’administrateur Rh ou
l’employé s’authentifie au système.
2. L’administrateur de l’application ou l’administrateur Rh ou
l’employé clique sur « demande congé ».
3. L’administrateur de l’application ou l’administrateur Rh ou
l’employé affiche la liste des demandes de congé.
Tableau 9: Description du cas d'utilisation « Consulter les congés »
 Cas d’utilisation : « modifier un congé »

l’employé de modifier un congé.
réussite.
Post-condition La demande de congé sera modifiée dans la base.
système.
« Demandes Congés ».
3. L’administrateur de l’application ou l’employé choisi la demande
qui n’est pas encore validé.
bouton « modifier ».

l’application ou l’employé a tenté de modifier une demande
validé. Un message s’affiche « la demande est validé»
Tableau 10:Description du cas d'utilisation « Modifier un congé »
Cas d’utilisation : « Supprimer un congé »

l’employé de supprimer un congé.
réussite.
Post-condition Un message de réussite de suppression s’affiche et la demande sera supprimée
dans la base.
système.
« Demandes Congés ».
3. L’administrateur de l’application ou l’employé choisi la demande
qui n’est pas encore validé.
bouton « supprimer ».

l’application ou l’employé a tenté de supprimer une demande
validé. Un message s’affiche « la demande est validé»
Tableau 11:Description du cas d'utilisation « Supprimer un congé »
 Cas d’utilisation : « valider un congé »
Acteurs AdminRh
Objectif Le module « Gérer les employés » permet l’administrateur Rh de validé un
congé.
Post-condition Un message de réussite de validation (Accepté ou Refusé) s’affiche et la
demande sera validée dans la base.
2. L’administrateur Rh clique sur « Demandes Congés ».
3. L’administrateur Rh choisi la demande à valider.
4. L’administrateur Rh clique sur le bouton « accepté »ou
« refusé ».
Tableau 12: Description du cas d'utilisation « Valider un congé »

2.3.4. Cas d’utilisation «Demander avance salaire » :
Dans la figure ci-dessous, on présente le diagramme des cas d’utilisations « Demander

avance salaire » :
Figure 6: Diagramme de cas d'utilisation « Demander une avance Salaire »
2.3.5. Cas d’utilisation «Demander frais personnel » :

2.3.5.1. Diagramme de cas d’utilisation

un frais personnel » :
Figure 7: Diagramme de cas d'utilisation « Demander un frais personnel »
2.3.6. Cas d’utilisation «Demander modification infos personnelle » :


modification infos personnelle » :
Figure 8: Diagramme de cas d'utilisation « Demander modification des informations personnelles »
2.3.7. Cas d’utilisation «Consulter des documents administratifs» :

Dans la figure ci-dessous, on présente le diagramme des cas d’utilisations « Consulter

des documents administratifs » :
Figure 9: Diagramme de cas d'utilisation « Consulter des documents administratifs »
identifiés au niveau du cas d’utilisation « Consulter des documents administratifs » :
Objectif Le module « Consulter des documents administratifs » permet l’administrateur
de l’application et l’employé de consulter :
 Bulletin de paie
 Attestation de salaire
 Solde de congé
Pré- condition Authentification de l’administrateur de l’application ou l’employé est réussite.
Post-condition Le document sera affiché.
système.
« Documents Administratifs ».
3. L’administrateur de l’application ou l’employé affiche le
document à consulter.
Tableau 13:Description du cas d'utilisation «Consulter des documents administratifs »
2.3.8. Cas d’utilisation «Gérer les notifications » :

Dans la figure ci-dessous, on présente le diagramme des cas d’utilisations « Gérer les
notifications» :
Figure 10: Diagramme de cas d'utilisation «Gérer les notifications»
identifiés au niveau du cas d’utilisation « Gérer les notifications » :
 Cas d’utilisation : « supprimer une notification »
Acteurs AdminRh
Objectif Le module « Gérer les notification » permet l’administrateur Rh de supprimer
une notification.
Post-condition Un message de réussite de suppression s’affiche et la notification sera
supprimée dans la base.
Scénario nominal 1. L’administrateur de Rh s’authentifie au système.
2. L’administrateur de Rh clique sur « Notifications ».
3. L’administrateur de Rh choisi la notification qui va supprimer.
4. L’administrateur de Rh clique sur le bouton «supprimer ».

Tableau 14: Description du cas d'utilisation « Supprimer une notification »
 Cas d’utilisation : « Consulter les notifications »
Acteurs AminRh
Objectif Le module « Gérer les notification » permet l’administrateur Rh de consulter les
notifications.
Post-condition La liste des notifications sera affichée.
2. L’administrateur Rh clique sur « Notifications ».
3. l’administrateur Rh affiche la liste des demandes de congé.
Tableau 15: Description du cas d'utilisation «Consulter les notifications »
Cas d’utilisation : « Créer une notification »

Acteurs AminRh
Objectif Le module « Gérer les notification » permet l’administrateur Rh de créer une
notification.
Post-condition Un message de réussite de création s’affiche et la notification sera envoyée
2. L’administrateur Rh clique sur « Notifications ».
3. L’administrateur Rh clique sur « Ajouter notification ».
4. L’administrateur Rh remplit le formulaire de notification en
identifiant l‘employé concerné et la description.
5. L’administrateur confirme la creation.
Tableau 16: Description du cas d'utilisation «Créer une notification»
Conclusion :
Ce chapitre nous a permis de préciser les besoins fonctionnels et techniques des acteurs
de ce système. On a exposé une analyse plus détaillé de ses besoins avec les diagrammes de
cas d’utilisation et la description détaillé de chaque cas.
Dans le chapitre suivant, on doit aborder les choix de technologie et la partie conception.
Chapitre 3 : Conception et choix technologiques :
Introduction :
La conception est une phase décisive dans le cycle de développent de tous les logiciels,
son objectif est d’exprimer l’architecture de ce système qui répond aux besoins formulés. Pour
garantir ses objectifs, on pourra utilisés les diagrammes de classe et de séquence pour mieux
expliquer les besoins déjà identifiés.
3.1. Conception architecturale:
3.1.1. Architecture logique :
L’architecture logique ou bien dite architecture logicielle se passionne au découpage
logique de l’application. Dans cette architecture, les applications au niveau serveur sont
délocalisées: chaque serveur est spécialisé dans une tâche et que l’architecture peut être des
différentes machines.
L’architecture de cette application est n-tiers, cette architecture permet à diviser
l’application sous forme de n couches qui sont indépendantes. La liaison logique de ces couches
sera à travers le même système.
En appliquant cette architecture, ce système sera décomposé sur trois couches : la
première couche est la couche présentation ou couche affichage (elle expose l’affichage et les
traitements locaux), la deuxième couche est la couche traitement ou la logique applicative (prise
par le serveur d’application « web »), la troisième couche est la couche de données (liées aux
serveurs de base de données).
L’architecture 3-tiers est une architecture suffisante pour comprendre la division logique
et physique de ce système. Cette architecture est présentée par le modèle suivant :
L’architecture 3-tiers est basé sur le modèle technique MVC (Model Vue Controller)
qu’on l’exprime dans la figure ci-dessous :
Figure 11: Modèle MVC (2)
Le fonctionnement de ce modèle est exprimé dans le scénario suivant :

1. La vue expose l’interface au client.
2. La validation va lancer le contrôleur.
3. Le contrôleur va traiter les informations saisie ou demandés par l’utilisateur et
transférer cette action au modèle.
4. Le modèle va recevoir la commande arrivé du contrôleur et lance la requête
convenable.
5. Le modèle va recevoir la repense de la requête envoyé et la transférer au
contrôleur.
6. Le contrôleur va traiter la repense.
7. Le contrôleur va transférer les données traitées à la vue.
8. La vue va recevoir les données envoyées par le contrôleur et elle va les afficher
à l’utilisateur.
3.1.2. Architecture physique:

La figure ci-dessous illustre l’architecture physique de notre application qui est composé
par trois parties telles que la partie Front-End, la partie Back-End et la partie base de donnés.
Figure 12: architecture physique
 Description de la partie Back-End :

Cette partie est basée sur l’architecture micro-service qui est implémenté par les
applications logicielles (complexes et volumineuses). Chaque micro-service peut être composé
d’un ou plusieurs services qui sont déployés indépendamment, aussi peut être développé
indépendamment avec des différentes technologies, ainsi peut être avoir une base de donné et
tester indépendamment.
L’architecture micro-service de notre application est composée par des packages:
 Dao : permet de regrouper les différentes explications des classes qui sont
relatives pour l’accès à la base de données. Entre autres, on trouve les packages
repositry, entity.
 Service : permet de regrouper les définitions des classe service du micro-service
ainsi leur classe service permet les règles d’affaires du micro-service, il permet
les interactions avec la base de données.
 Repository : permet de regrouper les définitions des classes telles qu’ il permet
d'interagir avec la base de données via le contexte JPA.
 Entity : permet de regrouper les définitions des classes qui permettent de
présenter une instance de donnés au sein de la base de donné.
 Controller : permet de regrouper les différentes classes Controller du service qui
sont responsables pour gérer les interactions définit entre le client web et le
micro-service tel que les requêtes web.
 Config : permet de regrouper les configurations nécessaires du micro-service.
Entre autres, on trouve la configuration du micro-service, la configuration de
Swagger.
3.2. Conception détaillé:

3.2.1. Modélisation statique:
Pour présenter une modélisation de la vue statique de ce projet, on s’intéresse à la
structure statique du système par l’intermédiaire des objets, des opérations, des attributs, des
relation et des classes, on doit décrire cette vue par le biais d’un diagramme de classe.
3.2.1.1. Diagramme de classe :
Le diagramme de classe est considéré comme le plus important de la modélisation
orienté objet. Il nous permit de décrire le système à travers des classes et des relations entre elles
La figure ci-dessous présente le diagramme de classe :
Figure 13: Diagramme de classe
 Dictionnaire de données :
Classe « User »
Champ type description

id_user String Identifiant de l’utilisateur
Nom String Nom de l’utilisateur
Prénom String Prénom de l’utilisateur
Matricule Int Matricule de l’utilisateur
Email String Email de l’utilisateur
Statut String Statut de l’utilisateur (activé
ou bloqué)
Pwd String Mot de passe de l’utilisateur
Photo Pixel La photo de l’employé
Tableau 17: Classe User
Classe « Rôle »

id_Role Int Identifiant du rôle
Libelle String Rôle de chaque utilisateur
(AdminRh, employé,
AdminApp)
Tableau 18: Classe Rôle
Classe « Notifications »

id_notification Int Identifiant de la notification
Corps String Corps et description de la
notification
Statut String Statut de la notification (envoyé
ou en attente)
id_user Int Identifiant de l’utilisateur
concerné
Date Date Date de la notification
Direct String La notification directe
Tableau 19: Classe Notifications
Classe « Document Administratif »

Id Int Identifiant de document
Tableau 20:Classe Document Administratif
Classe « solde congé »

date_piece Date La date de la pièce de solde de
congé
date_deb_abs Date La date début des absences
date_fin_abs Date La date fin des absences
heure_debut_abs Date Les heures début des absences
heure_fin_abs Date Les heures fines des absences
date_rubrique Date La date de la rubrique
nbre_abscence Float Le nombre des absences
Observation String L’observation
Tableau 21: Solde Congé
Classe « BulletinPaie »

Matricule Int La matricule de l’employé
Mois Date Le mois concerné du bulletin de
paie
Année Date L’année concernée du bulletin de
paie
Nom String Le nom de l’employé
Prenom String Le prénom de l’employé
Rubrique String La rubrique du bulletin de paie
Tableau 22:BulletinPaie
Classe « AttestationSalaire »

Description String La description de l’attestation du
salaire
Tableau 23: AttestationSalaire
Classe « Demandes »

id_demande Int Identifiant de la demande
date_demande Date Date de la demande
statut_demande String Statut de la demande (acceptée,
refusée, en attente)
Tableau 24: Demandes

Classe « ModificationinfoPersonnelle »

Description String La description de la demande
Tableau 25: ModificationinfoPersonnelle
Classe « TypeModification »

Id Int Identifiant de type de
modification
Libelle String Le libelle de l’information à
modifier (adresse, nom...)
Tableau 26: Classe TypeModification
Classe « congé »
date_debut Date La date début de congé
date_fin Date La date fin de congé
nbre_jour Int Le nombre de jour de congé
id_remplacant Int L’identifiant du remplaçant
pendant le congé
tache_delg String La tache déléguée pour le
remplaçant pendant le stage
Tableau 27: Classe Congé
Classe « TypeCongé »

Id int Identifiant de type de congé
Libelle String Le libelle de type de congé
(congé annuelle, maladie...)
Tableau 28: Classe TypeCongé
Classe « AvanceSalaire »
Montant float Le montant de l’avance du
salaire
Tableau 29: Classe AvanceSalaire
Classe « FraisPersonnelle »

Montant float Le montant pour le frais
personnel
date_mission Date La date de la mission
Tableau 30: Classe FraisPersonnelle
3.2.2. Modélisation dynamique:

Dans cette partie de la phase de conception, on doit entamer une description en
profondeur de la dynamique du système. On doit modéliser, tout d’abord, le diagramme de
séquence a fin de présenter les interactions entre les objets lors de l’exécution du programme.
On va ici attarder sur les cas d’utilisation suivants :
 S’authentifier
 Gérer les employés
 Demander un congé
 Consulter des documents administratifs
3.2.2.1. Diagramme de séquence de scénario « S’authentifier » :

Cette application doit être munie par une partie d’authentification. Cette partie est la
partie clé de tous les autres cas d’utilisation par ce qu’elle est le point d’entré de cette application.
La figure ci-dessous décrit le scénario de l’authentification.
Scénario : l’utilisateur doit introduire son identifiant et son mot de passe. Tout d’abord, le
système doit valider les champs, puis il doit vérifier la cohérence de l’identifiant et du mot de
passe saisie. S’il est validé, l’utilisateur accède à l’espace personnel avec succès.
Sinon, l’utilisateur doit entrer de nouveau l’identifiant et mot de passe et le processus de
vérification se répète.
Authenti fication
Control eSaisie Athentifi cation SGBD:Tabl eUser
User
loop [Succé du contrôl e sai sie]
Saisie logi n/password
ControlerSaisie()
Excepti on
succè du controle
Veri fier(login,password)
Reponse
alt [Verifier= false]
Al erte(Véri fi er votre login et password)
Page authentificati on
[Verifi er=true]
Al erte(Connexi on résussie)
Redi recti on vers page d'accueil
Figure 14: Diagramme de séquence relatif à« S’authentifier »
3.2.2.2. Diagramme de séquence de scénario « Gérer les employés » :

L’administrateur de l’application peut ajouter un nouvel employé. La figure ci-dessous
illustre le scénario relatif à l’ajout :
Ajouter Employé
EspaceUtilisateur ControleSaisie SGBD:Table employé
AdminApp
ref
Authentification()
Demander formulaire Ajout employé
Formulaire Ajout Emp
loop [Succé du contrôle saisie]
Envoyer le formulaire rempli
ControleSaisie()
Exception
AjouterEmploye()
succè du controle <<Invocation du service
AjouterEmploye>>
Reponse
alt [AjouterEmploye()= false]
Alerte(Ajout echoué)
Formulaire Ajout rempli
[AjouterEmploye()=true]
Alerte(Ajout effectué avec succè)
Formulaire Ajout vierge
Figure 15:Diagramme de séquence relatif à « Ajouter un employé »
L’administrateur de l’application peut supprimer un employé. La figure ci-dessous

illustre le scénario relatif à la suppression :
SupprimerEmployé
EspaceUtilisateur Employe SGBD:Table employé
AdminApp
ref
Authentificati on()
Demander Liste Employés ChercherEmploye()

ListerEmploye()
<<Invocation du service :
ListerEmpl oyés>>
Liste des employés
Choisir l'employé à supprimer

SupprimerEmploye()
<<Invocation du service
SupprimerEmploye>>
Réponse
alt [SupprimerEmploye()= false]
Al erte(Supression echoué)
Liste des employés
[SupprimerEmploye()=true]
Alerte(Suppression effectué avec succè)
Liste des employés
Figure 16: Diagramme de séquence relatif à Supprimer un employé
L’administrateur de l’application peut Consulter un employé. La figure ci-dessous

illustre le scénario relatif à la consultation :
Consulter Fiche Employé
AdminApp/Employé/
AdminRH
ref
Authentification()
Demander Liste Employés ChercherEmploye()

ListerEmploye()
ListerEmployés>>
Liste des employés
Choisir employé
FicheEmploye()
InfosEmploye>>
Réponse
Infos Employé
Affichage de la fiche employé
Figure 17: Diagramme de séquence relatif à « Consulter un employé »
3.2.2.3. Diagramme de séquence de scénario « Demander un congé » :

L’employé peut ajouter une demande de congé. La figure ci-dessous illustre le scénario
relatif à l’ajout :
Demander un congé
EspaceUtilisateur ControleSaisie SGBD:T able demandeConge
Employé
ref
Authentification()
Demander formulaire Demande Congé
Formulaire demande congé
loop [Succé du contrôle saisie]
Envoyer le formulaire de demande congé

rempli
ControleSaisie()
Exception
DemandeConge()
succè du controle <<Invocation du service
DemandeConge>>
Reponse
alt [DemandeConge()= false]
Alerte(Demande non enregistrée)
Formulaire Ajout rempli
[DemandeConge=true]
Alerte(Demande enregistrée avec succè)
Page d'accueil espace utilisateur
Figure 18: Diagramme de séquence Ajouter un congé
3.2.2.4. Diagramme de séquence de scénario « Consulter des documents

administratifs » :
L’employé peut consulter leur fiche de paie (bulletin de paie). La figure ci-dessous illustre le
scénario relatif à l’ajout :
Consulter fiche de paie
Employé
ref
Authentification()
Demander Fiche de paie

ListerFichePaie()
Formulaire de recherche de fiche de paie
ListerFichePaie>>
Envoyé formulaire rempli
ChercherFichePaie()
Liste des fiche de paie résultat de

recherche
Choisir Fiche de Paie

FichePaie()
FichePaie>>
Réponse
Fiche paie
Affichage de la fiche de paie
Figure 19: Diagramme de séquence Consulter documents administratifs
3.3. Choix technologiques :

3.3.1. Coté serveur :
Dans le coté du serveur, on a choisit pour développer cette application micro services
« Spring Boot ». Ce Framework est utilisé pour la simplification du démarrage ainsi que le
développement des applications Spring. Il a comme objectif d’influencer la plate-forme telle
que la favorisation l’utilisation de la technologie existante. En effet, Spring Boot est considéré
parmi les choix idéaux utilisé pour développer avec l’écosystème Spring. Le Framework
Spring Boot utilise un ensemble de modules ou bien « starter », qui exposent un ensemble des
collections de dépendances qui sont ajoutés au système.
Les modules utilisés dans cette application sont :
 Spring Security : Spring Security est un cadre d'authentification et de contrôle d'accès
puissant et hautement personnalisable. C'est la norme de facto pour sécuriser les
applications Spring. Spring Security est un Framework qui se concentre sur la fourniture à
la fois d'authentification et d'autorisation aux applications Java. Comme tous les projets
Spring, la vraie puissance de Spring Security réside dans la facilité avec laquelle il peut
être étendu pour répondre aux exigences personnalisées.(3)
 Spring Data JPA : est l’un des Framework de Spring reposant sur Spring data .Spring
Data JPA vise à améliorer la mise en œuvre de la couche d’accès aux donnés en réduisant
considérablement l’effort d’écriture du code d’implémentation en particulier pour les
méthodes CRUD et pour le recherche. La notion centrale dans Spring Data JPA est la
notation « Repository ». Le repository est une interface à écrire par le développeur. Il
déclare, dans cette interface, les méthodes utiles d’accès aux données et fournit les
implémentations nécessaires.(3)
 Java Mail Sender : JavaMail est une API qui permet d'utiliser le courrier électronique (e-
mail) dans une application écrite en Java (application cliente, applet, servlet, EJB, ...). Son
but est d'être facile à utiliser, de fournir une souplesse qui permette de la faire évoluer et
de rester le plus indépendant possible des protocoles utilisés.(4)
3.3.2. Coté client :

Dans le coté du serveur, on a choisit pour développer cette application Angular et
Bootstrap . Angular est un framework libre pour les interfaces Web , il utilise le TypeScript,
soit du JavaScript. Ce framework suit une architecture basée sur les composantes où chaque
composante est basée sur le patron de conception MV.
Bootstrap est une boîte à outils open source pour le développement avec
HTML, CSS et JS. Protégez rapidement vos idées ou construisez votre application entière
avec nos variables et combinaisons Sass, notre système de grille réactif, de nombreux
composants prédéfinis et de puissants plug-ins basés sur jQuery.(5)
CSS Les Feuilles de Style CSS (Cascade Style Sheets) : est un langage
informatique utilisé pour décrire l’affichage des documents HTML et XML. . Les normes
spécifiant les CSS sont publiés par le World Wide Web Consortium (W3C). CSS a été
introduit au milieu des années 1990. Il est largement utilisé dans la conception de sites web et
est bien pris en charge par les navigateurs web au cours du nouveau millénaire.
HTML5 : L'HTML est un langage informatique utilisé sur l'internet. Ce

langage est utilisé pour créer des pages web. L'acronyme signifie ‘’HyperText Markup
Language’’, qui signifie en français ‘’langage de balisage d'hypertexte’’. Cette signification
est nommée de manière appropriée car ce langage permet de créer un hypertexte basé sur la
structure de balisage.
TypeScript : typeScript est un langage open source qui s’appuient sur

JavaScript, l'un des outils les plus utilisés au monde, en ajoutant des définitions de type statiques.
Les types fournissent un moyen de décrire la forme d'un objet, fournissant une meilleure
documentation et permettant à TypeScript de valider que votre code fonctionne correctement.
L'écriture de types peut être facultative dans TypeScript, car l'inférence de type vous permet
d'obtenir beaucoup de puissance sans écrire de code supplémentaire.(6)
3.3.3. Liaison entre la partie cliente et la partie serveur :

Spring Data REST : il s’appui sur les référentiels Spring Data, il analyse aussi le modèle
et expose les entités automatiquement que ressource REST via http.
REST utilise les méthodes, ce qui serait plus facile et plus facile à gérer :
 Il utilise la méthode GET lorsque nous demande de web service une réponse à
afficher pour le client.
 Il utilise la méthode POST pour envoyer une demande au web service pour
enregistrer des données.
 Il utilise la méthode PUT et DELETE pour mettre à jour ou supprimer des
ressources.
Méthode Action
GET Afficher
POST Enregistrer
PUT Mise à jour
DELETE Supprimer
Tableau 31: Les méthodes de REST
Conclusion :
Durant ce chapitre, On a définit le processus de conception ainsi on a explicité le
diagramme de classe et les diagrammes de séquences. Enfin, on a justifié le choix technologique
pour la réalisation de cette application. Dans le chapitre suivant, on va présenter l’environnement
de développent (matérielle et logiciel).
Chapitre 4 : Réalisation
Introduction :
La réalisation expose l’aboutissement d’un travail de conception et aussi d’analyse. La
question dans ce chapitre est de présenter cette application spécifique dans le chapitre
précédent. Tout d’abord, on doit spécifier l’environnement : matériel et logiciel qu’on a utilisé
pendant la phase de développement. On clôture ce chapitre par l’exposant de la phase
d’implémentation.
4.1. Environnement de travail :
On va présenter dans cette partie l’environnement matériel et logiciels utilisées pour le
développent de notre application architecture micro-services pour le développement d’une
application portail Rh.
4.1.1. Environnement matériels :

Le composant matériel de l’environnement de travail est un Ordinateur portable
personnel dont les caractéristiques sont les suivants :
Processeur: Intel (R) Core™ i7-8550U CPU @ 1.80GHz 1.99 GHZ
Mémoire installé (RAM) : 8Go
Système d’exploitation : Windows 10 professionnel 64 bit
4.1.2. Environnement logiciels :

4.1.2.1. Environnement de conception :
 PowerAMC : est un logiciel de conception créé par la société SDP, leur
principale fonctionnalités est la modélisation des processus métiers ainsi que la modélisation
des données en Merise, MCD, MLD, MPD et UML.
4.1.2.2. Environnement de développement :
 Spring Tools Suite (STS) : est l’outil officiel pour développer un projet Spring
Boot. Cet outil consiste en un Integrated Development Environment (IDE) Eclipse avec une
extension développé spécifiquement pour intégrer les opérations nécessaires au
développement d’un projet Spring.
 Angular Command Line : Angular Command Line (CLI) est une librairie open
source qui facilite la création de projets Web utilisant la technologie Angular. Il permet de
générer différents fichiers contenant un minimum de code pour le fonctionnement dans
l’environnement Angular.(7)
 Node Package Manager (NPM) : un outil de gestion de librairie open source
pour la langue de programmation JavaScript. Apparu avec NodeJS en 2009 l’utilisation de
NPM dépasse aujourd’hui l’environnement serveur. Il est aussi le gestionnaire par défaut dans
l’environnement d’exécution NodeJS. Il est de plus en plus utilisé dans le développement des
interfaces utilisateurs. Il est simple à utiliser et permet d’accéder au plus gros dépôt de paquets
tous langages confondus. (7)
 Visual Studio Code : Visual Studio Code est présenté comme un éditeur de code
multiplateforme, logiciel libre et gratuit. C’est un éditeur de code source léger, mais puissant
qui s'exécute sur le bureau et est disponible pour Windows, macOS et Linux. Il est livré avec
un support intégré pour JavaScript, TypeScript et Node.js et possède un écosystème riche en
extensions pour d'autres langages (tels que C++, C#, Java, Python, PHP, Go) et
environnements d'exécution (tels que .NET et Unity). (7)
 Swagger 2.0 : Swagger est un logiciel libre offrant un large écosystème d’outils
aidant la conception, le développement, la documentation ainsi que la production de tests d’un
API Web RESTful. Swagger offre un éventail de fonctionnalités tel que la génération de
documentation, la génération de code ainsi que la génération de tests. En outre, il définit un
standard qui permet aux développeurs d’application de découvrir et comprendre les méthodes
disponibles dans une application ou un service sans avoir besoin d’accéder à son code ou
consulter une documentation supplémentaire. Lorsqu’une API a été correctement définie avec
Swagger, les développeurs peuvent comprendre et interagir avec le service avec beaucoup
moins d’effort d’implémentation. (7)
4.1.2.3. Environnement de base de données :
 PostgreSQL (version 12) : est un système de gestion de base de données
relationnelle et objet. L’une des principales qualités de postgreSQL est d’être un logiciel
gratuit et open Source .PostgreSQL possède de nombreuses caractéristiques faisant de lui un
SGDB robuste. Il dispose d’interface graphique, des bibliothèques facilement l’accès aux
données a partir des programmes écrit en (JAVA, C, C++..) et d’une API ODBC permettant a
n’importe quelle application supportant. Ce type d’interface d’accéder a des bases de données
de types PostgreSQL.(7)
4.2. Phase d’implémentation :

Tout au long de cette partie, nous présentons les principales fonctionnalités de notre
application à travers un enchainement de quels que captures d’écrans.
4.2.1. Interface d’authentification :
Pour profiter des fonctionnalités de l’application, l’utilisateur doit s’authentifier et remplir les
champs pour y accéder comme le montre la figure ci-dessous :
Figure 20: Interface « Authentification »
L’interface d’authentification est constituée de deux champs qui servent à la saisie de login
et du mot de passe. Après avoir remplir ces champs avec des données valides, l’utilisateur clique sur le
bouton « Connecter » afin d’accéder à l’application.
Si les données sont invalides un message d’erreur sera affiché comme indique la figure ci-
dessous :
Figure 21:Interface erreur d'Authentification
4.2.2. Interface demande avance salaire coté administrateur Rh :

Après l’authentification de l’administrateur Rh (Responsable Rh) une interface sera
affichée.
 Si l’administrateur Rh clique sur Demandes des avances Salaires, une
interface sera affiché contient tout la liste des demandes comme indique la
figure ci-dessous :
Figure 22:Interface «liste demande d'avance salaire »
4.2.3. Interface demande de congé (coté administrateur Rh ) :

affiché.
 Si l’administrateur Rh clique sur Demandes de congé, une interface sera
affiché contient tout la liste des demandes comme indique la figure ci-
dessous :
Figure 23:Interface « liste de demande de congé »
4.2.4. Interface de gérer les employés (coté administrateur Rh) :

affiché.
 Si l’administrateur Rh clique sur Gestion des utilisateur, une interface sera
affiché contient tout la liste des employés comme indique la figure ci-
dessous :
Figure 24:Interface « liste des employés »
4.2.5. Interface d’avance salaire (coté employé) :

Après l’authentification de l’employé une interface sera affichée.
 Si l’administrateur Rh clique sur Demandes des Avances Salaires, une
interface sera affiché contient tout la liste des demande comme indique la
figure ci-dessous :
Figure 25: Interface « demande avance salaire »
4.2.6. Interface de demande de congé (coté employé) :
Après l’authentification de l’employé une interface sera affiché.
 Si l’administrateur Rh clique sur Demandes de congés, une interface sera
affiché contient tout la liste des demandes comme indique la figure ci-
dessous :
Figure 26: Interface demande de congé
4.2.7. Interface de la liste des employés (coté administrateur de l’application) :

Après l’authentification de l’administrateur de l’application une interface sera
affiché.
 Si l’administrateur Rh clique sur Gestion des utilisateurs, une interface sera
affiché contient tout la liste des employés comme indique la figure ci-
dessous :
Figure 27:Interface liste des employés
Le reste de toutes les interfaces je les exprimerai dans la présentation.

Conclusion :
Dans ce chapitre, on a définit l’environnement de travail puis présenté le choix
technique lors de l’implémentation et on a exposé le fonctionnement de notre système avec
quelque interfaces.
Conclusion générale :
Au terme de ce rapport, on a présenté le démarche suivie pour à la réalisation complète
de notre projet intitulé « Architecture micro-services pour le développent d’une application
portail Rh ». Dans le cadre de réalisation du projet de fin d’étude pour l’obtention de diplôme
national d’ingénieur en Téléinformatique pour l’année universitaire 2019/2020.
Pour arriver à terminer ce rapport, on a commencé tout d’abord, par la mise du ce projet
dans leur cadre général : on a exposé et définies la problématique qui est à l’origine l’existant
du besoin de ce projet. Dans un deuxième lieu, on a essayé l’extraction les besoins
fonctionnels et les besoins non fonctionnels qui son un repère de notre travail. Puis on a arrivé
à représenter les différents cas d’utilisation avec leur acteur. La troisième partie, était occupé
pour la conception tels qu’on donné une présentation conceptuelle précise avec l’architecture
du système. Dans une dernière étape on a arrivé à la réalisation du projet.
Pour le niveau professionnel ce projet a donné une expérience très intéressante pour la
stratégie de modernisation et l’évolution des services de l’administration Rh de « Smart Up ».
La mise en place de ce processus Rh doit subir des évolution très inévitables tel que
cette application nécessitera des améliorations au niveau des modules réalisés a fin de la
rendre plus fiable, ou le développent d’autre module tels que module de générateur de
rapport , module de messagerie pour la communication entre les employés….
Webographie
1/https://iwra.org/member/congress/resource/abs580_article.pdf
2/ https://tahe.developpez.com/web/php/mvc/?page=page_1
3/ https://spring.io/projects/spring-security
4/ https://spring.io/projects/spring-data-jpa
5/ https://www.jmdoudoux.fr/java/dej/chap-javamail.htm
6/ https://fr.wikipedia.org/wiki/TypeScript
(7) : http://publicationslist.org/data/a.april/ref-639/PFE%20-%20Rapport%20Final.pdf
Résumé
Ce projet de fin d’étude a été réalisé au sein de « SmartUp » pour l’obtention l’obtention
de diplôme national d’ingénieur en Téléinformatique. Dans ce travail, des efforts on été portés
pour concevoir et développer une application web pour le direction de ressource Humaine qui
facilite la communication entre l’employé et la direction.
Mots clés :
2TUP, SpringBoot, microservice , Angular , PostgeSQL ,CSS, Html , TypeScript, Swagger
Abstract :
This end-of-study project was carried out within "SmartUp" to obtain a the National
Diploma of Engineering in Computer Science. In this work, efforts have been made to design
and develop a web application for human resource management that facilitates communication
between employee and management.
Keywords :
2TUP, SpringBoot, microservice , Angular , PostgeSQL ,CSS, Html , TypeScript, Swagger

Langue

Rapport

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport

Transféré par

Droits d'auteur :

Formats disponibles

Introduction générale

Grace à la diversité des moyens de l’administration des entreprises, le développent de

Dans ce cadre, la société « SmartUp » adopte la création et l’implémentation d’un système

Le premier chapitre « Contexte général », consiste à présenter le cadre général du projet,

Dans le deuxième chapitre « Analyse et spécification des besoins », on se concentre sur la

Dans le troisième chapitre « Conception et choix technologiques », consiste à exposer la

Par suite, on va extraire les problématiques qui sont à l’origine de la demande de la

1.1. Cadre générale :

Le présent projet « Architecture micro-services pour le développent d’une application

1.2. Organisme d’accueil :

Adresse : 53, Rue des minéraux La Charguia 1, 2035 Tunis –Tunisie

Téléphone : +216 70 132 152

Figure 1:logo de société "Smart Up"

Les axes d’expertise de SmartUp sont :

 Conseil en systèmes d’informations intégrés

1.3. Etude de l’existant :

La gestion Rh comprend des fonctions administratives et opérationnelles. Dans ce projet,

Cette étude présente un certain nombre de difficultés et d’insuffisances qui peuvent

1.5. Solution proposée :

1.6. Choix de méthodologies :

Méthodologies Description Points forts Points faibles

- Méthode - Donne la - La mise en

Tableau 1:Tableau comparatif des différentes méthodologies de conception

1.6.2. Le processus 2TUP :

La branche gauche est la branche fonctionnelle, qui contient deux phases :

Chapitre 2 : Analyse et Spécification des besoins

2.1. Spécification des besoins :

2.1.1. Besoins fonctionnels :

A ce niveau, on va étudier les différentes fonctionnalités attendues du futur système et

Selon ces options :

 Demander une avance sur salaire :

 Demander un frais personnel :

 Consulter des documents administratifs :

2.1.2. Besoins non fonctionnels :

Après la spécification des besoins fonctionnels, on doit passer maintenant à exprimer et

2.2. Identifications des acteurs :

2 Demander un AdminApp AdminApp AdminApp AdminApp

3 Demander AdminApp AdminApp AdminApp AdminApp

4 Demander un AdminApp AdminApp AdminApp AdminApp

5 Demander AdminApp AdminApp AdminApp AdminApp

Tableau 2: L'utilisation des opérations de système par les acteurs

2.3. Diagrammes des cas d’utilisation et identifications des scénarios :

2.3.2. Cas d’utilisation «Gérer les employés » :

2.3.2.2. Identification du scénario :

Tableau 3:Description du cas d'utilisation « Ajouter un employé »

 Cas d’utilisation : « Supprimer un employé »

Scénario alternatif 1. Un message d’erreur s’affiche lors de l’authentification. Un

Tableau 4:Description du cas d'utilisation « Supprimer un employé »

 Le cas d’utilisation : « Consulter un employé »

Acteurs AdminApp, AminRh

Tableau 5:Description du cas d'utilisation « Consulter un employé »

 Cas d’utilisation : « Modifier les informations d’un employé »

Tableau 6: Description du cas d'utilisation « Modifier les informations d'un employé »

 Cas d’utilisation : « Activer un employé » et « Désactiver un employé »

2.3.3. Cas d’utilisation «Demander un congé » :

2.3.3.2. Identification du scénario :

Acteurs AdminApp, Employé

Tableau 8: Description du cas d'utilisation « Ajouter un congé »

 Cas d’utilisation : « Consulter les congé »

Tableau 9: Description du cas d'utilisation « Consulter les congés »

 Cas d’utilisation : « modifier un congé »

Acteurs AdminApp, Employé

Scénario alternatif 1. Un message d’erreur s’affiche lors de l’authentification. Un