PROJET DE FIN D’ÉTUDES
Application web de gestion en ressources humaines :
Rudy TOURROU
José-Alexandre GIRY
Jimmy RAKOTOSON
Amine DARABID
1 sur 27
1. Introduction 3
2. Étude 4
2.1. Définition du besoin 4
2.2. Définition des attendus 5
3. Organisation 8
3.1. L’équipe 8
3.2. Définition des taches 9
3.3. Planification des tâches 10
4. Conception 13
4.1. Modélisation UML 13
4.2. Modélisation de l’application 17
4.3. Architecture physique de l’application 20
5. Réalisation 22
5.1. Développement des fonctionnalités 22
5.2. Écriture de la documentation technique 24
5.3. Tests 24
6. Livraison 25
6.1. Déploiement de l’application 25
7. Conclusion 27
2 sur 27
1. Introduction
Dans le cadre de notre projet de fin d’études en mastère informatique, il nous a été demandé
de concevoir et développer une application web dans les langages et technologies étudiées, en
équipe de quatre personnes et sur une durée de quatre jours.
Ce dossier a pour objectif de présenter et justifier de :
‣ L’étude préalable et le cadrage du projet → définition des attendus client.
‣ L’organisation → planification de l’utilisation des ressources.
‣ La conception → modélisation graphique et fonctionnelle de l’application.
‣ La réalisation → développement des fonctionnalités et rédaction des documentations.
‣ La livraison → mise à disposition de l’application.
3 sur 27
2. Étude
2.1. Définition du besoin
L’application dont il est sujet est un logiciel de gestion RH ou SIRH (système d'information de
gestion des ressources humaines) où il est demandé de venir développer, dans le respect de
certains attendus et contraintes techniques, un module de « formation » avec toutes les fonc-
tionnalités qui l’incombent.
Ce module doit permettre de :
A. Gagner du temps sur la gestion des formations, en :
‣ Automatisant le calcul des coûts de formations.
‣ Permettant aux salariés et employeurs de s’exprimer.
B. Construire efficacement un plan de formation en :
‣ Maitrisant le budget de formation.
‣ Suivant les dépenses selon leur type ou nature et dispositifs de financement.
‣ Évaluant les compétences acquises.
C. Faire participer les équipes dans le processus de formation en :
‣ Identifiant les besoins prioritaires de formation.
‣ Proposant des formations pertinentes.
‣ Évaluant les formations réalisées.
Il existe en outre trois rôles différents permettant des actions distinctes :
Employé
‣ S’authentifier.
‣ Consulter le catalogue de formations.
‣ Se voir proposer des formations selon son métier.
‣ Evaluer chacune de ses formations réalisées.
Manager
‣ Effectuer les mêmes actions que les employés.
‣ Gérer les demandes de formation de son équipe.
‣ Consulter l’historique de formation de son équipe.
‣ Gérer les compétences de son équipe.
4 sur 27
Gestionnaire RH
‣ S’authentifier.
‣ Gérer le catalogue de formation.
‣ Gérer les budgets de formation.
‣ Valider les compétences une fois la formation réalisée.
Le processus métier est le suivant :
1. Le gestionnaire RH crée une formation qui remonte ensuite dans le catalogue RH.
2. L’employé consulte le catalogue de formation et peut faire la demande d’une formation.
3. La demande est transférée à son manager :
‣ S’il la valide, l’employé en est informé et pourra réaliser cette formation.
‣ Si elle est refusée, le salarié en est informé et reçoit ou consulte le motif de refus.
4. Chacun des acteurs doit se connecter avant de pouvoir agir sur les formations.
2.2. Définition des attendus
En plus des fonctionnalités citées ci-dessus, des exigences clients sont à prendre en compte.
Exigences technologiques
Outils de développement
GitHub Service web d'hébergement et de gestion de
développement logiciel utilisant l’outil de
gestion de versions Git.
Angular 7 Framework front-office.
WebService REST Style d’architecture logicielle permettant l’in-
téropérabilité entre ordinateurs sur internet.
JPA Permet la persistance des données.
Spring Boot Micro-framework permettant de générer l’ar-
chitecture d’une application Java.
Spring Cloud Configuration des microservices.
Déploiement de l’application sur le cloud URL fournie à la fin du projet.
5 sur 27
Intégration et déploiement continu
L’intégration et le déploiement continu permettent une automatisation de tâches dès que le
code est modifié.
Exigences de qualité
‣ Ergonomie → l’ergonomie représente la disposition et l’accessibilité de chacune des fonc-
tionnalités listées ci-dessus. Afin de répondre du mieux possible aux besoins de notre client,
la navigation doit être la plus simple et intuitive possible. Nous allons donc présenter par la
suite des maquettes de l’interface générale de notre application, point de départ pour le dé-
veloppement global de l’application.
‣ Fiabilité → la fiabilité d’une application se caractérise par sa capacité à fonctionner comme
prévu, sans bug ou ralentissement altérant l’expérience utilisateur. C’est au travers d‘un déve-
loppement méthodologique et testé à chaque phase que nous évaluerons la fiabilité. Enfin,
lors de la mise en production nous analyserons et comblerons les dernières anomalies éven-
tuellement détectées.
6 sur 27
‣ Maintenabilité → il s’agit de toujours penser aux possibles améliorations qui pourraient
être implémentées par la suite, que ce soit des nouvelles fonctionnalités ou une modification
d’interface. Cela implique donc une culture de codage où chaque fonctionnalité peut fonc-
tionner indépendamment l’une de l’autre.
‣ Portabilité → l’application doit fonctionner sur les différents navigateurs web de nos clients.
Un axe de d’amélioration possible sera de proposer une application « responsive », c’est à
dire qui est compatible aux écrans de smartphones ou tablettes.
7 sur 27
3. Organisation
3.1. L’équipe
L’équipe est constituée de quatre personnes issues de cursus scolaires similaires mais de mé-
tiers différents. Cette mixité des profils admet non seulement un échange des connaissances
acquises dans les domaines de chacun, mais aussi un partage des points de vue et des expé-
riences personnelles sur les sujets appréhendés.
‣ José-Alexandre GIRY → en tant que consultant SIRH de métier, José-Alexandre contribue
de par ses qualités de conseil client à la retranscription des besoins et à la bonne détermina-
tion des attendus techniques. Sa vision à long terme et son savoir-faire informatique per-
mettent d’instaurer une parfaite corrélation entre les retours terrain commerciaux et la finalité
logicielle. Sa connaissance des métiers RH est un atout majeur dans ce projet et en fait un
élément essentiel de l’équipe.
‣ Rudy TOURROU → fort de ses expériences en développement informatique et en
conduite de projets dans des administrations publiques comme le ministère de la Défense ou
d’autres grandes entreprises avec SUEZ et ERA Immobilier, Rudy apporte une vision claire et
réaliste des chemins à prendre pour atteindre les objectifs techniques. Organisé et métho-
dique, il coordonne les équipes dans la réalisation des différentes tâches constitutives du li-
vrable commercial.
‣ Jimmy RAKOTOSON → reconnu pour ses qualités de conseil auprès de clients dans le
monde de l’assurance, Jimmy sera un maillon fort de notre projet. Ces connaissances en dé-
veloppement et son savoir purement métier seront des éléments indispensable à la bonne
réalisation et entre en totale adéquation avec les qualités des autres membres de l’équipe.
‣ Amine DARABID → ayant déjà assuré la réalisation d’une multitude de projets, Amine
viendra compléter les compétences déjà présentes dans l’équipe. Son expérience nous per-
mettra d’avancer avec des objectifs toujours bien déterminés et cohérents avec l’attendu.
8 sur 27
3.2. Définition des taches
Il nous a été accordé pour ce projet quatre jours, du lundi 16 heures au vendredi 13 heures.
D’un effectif de quatre personnes, nous avons une capacité de travail maximale de seize jours.
Les phases du projet ont été retranscrites dans ce tableau :
Phase Explication Nb jours / homme
Définition du projet Découverte et réflexion sur le projet. 1
Pilotage Action menées tout au long du projet
1
afin de le cadrer.
Modélisation Les interactions entre les acteurs et le
système seront modélisées via le lan- 4
gage UML.
Préparation des environnements Afin de maximiser la productivité de
chacun des membres de l’équipes les
0,5
environnements seront mis en place
très tôt dans le projet.
Réalisation Développement front et back. 12
Tests Réalisation des tests pour notre appli-
2
cation.
Documentation Réalisation de la documentation de
0,5
notre application.
Déploiement Déploiement de notre application sur
1
le cloud.
Total 22
Selon nos estimations, ce projet nécessite 22 jours homme. Possédant 16 jours au maximum,
nous pouvons penser que le projet ne sera pas entièrement finalisé lors de sa livraison. De ce
fait, nous allons approfondir le déroulement et le contenu de chacune de ses phases.
9 sur 27
3.3. Planification des tâches
Définition du projet (1 jour / homme)
Tâches Priorité Ressources
Prise de connaissance du projet / Equipe
Définition du paramètre / Equipe
Analyse métier / Equipe
Analyse fonctionnelle / Equipe
Pilotage (1 jour / homme)
Tâches Priorité Ressources
Définition des tâches / Amine / José
Estimation du temps par tâches / Amine / José
Répartition des tâches / Amine / José
Suivi / Equipe
Modélisation (4 jours / homme)
Tâches Priorité Ressources
Diagrammes cas d’utilisation / Amine / José
Diagramme de classes / Equipe
Diagramme d’activité / Amine / José
Diagramme de séquence / Amine / José
Diagramme de déploiement / Amine / José
Plan du site / Rudy
Maquettage du site / Rudy
10 sur 27
Préparation environnement (0,5 jour / homme)
Tâches Priorité Ressources
Préparation environnement / Equipe
Documentation (0,5 jour / homme)
Tâches Priorité Ressources
JavaDoc / Jimmy
ReadMe / Amine
Réalisation (12 jours / homme)
Tâches Priorité Ressources
Front
Page Login / Rudy
Page Formation / Rudy
Page Demande en cours / Rudy
Page Historique / Rudy
Page Compétences / Rudy
Page Gestion des formations / Rudy
Page Plan de formation / Rudy
Page validation des compétences / Rudy
Page Budget annuel / Rudy
Back
S’authentifier 1 Amine / José
Gérer formations 1 Jimmy / Rudy
Valider compétences 4 Jimmy
Gérer budget 4 Jimmy
Gérer plan de formation 4 Jimmy
Voir liste formation 1 Jimmy / Rudy
Demander formation 2 Jimmy / Rudy
11 sur 27
Tâches Priorité Ressources
Voir historique formation 3 Jimmy
Gérer demande employé 2 Jimmy
Gérer compétences employé 4 Jimmy
/ / Equipe
Test (2 jour / homme)
Tâches Priorité Ressources
Test unitaire / Jimmy
Test d’intégration / Equipe
Test de non régréssion / Jimmy
Test utilisateur / Equipe
Déploiement (1 jour / homme)
Tâches Priorité Ressources
Déploiement / Rudy
12 sur 27
4. Conception
4.1. Modélisation UML
Le langage UML (Unified Modeling Language) est un standard de modélisation graphique. Il
permet la visualisation de la conception d’un système. Nous avons utilisé ce langage afin modé-
liser notre application et produire les diagrammes suivants :
‣ Diagramme de cas d’utilisation
‣ Diagramme de classe
‣ Diagramme d’activité
‣ Diagramme de séquence
‣ Diagramme de déploiement
Diagramme de cas d’utilisation
Ce diagramme permet de modéliser les principales interactions entre les utilisateurs et le sys-
tème.
13 sur 27
Nous identifions trois acteurs : le gestionnaire RH, l’employé et le manager.
Le gestionnaire RH :
‣ Gère les formations
‣ Valide les compétences
‣ Gère le budget
‣ Gère le plan de formation
L’employé :
‣ Consulte la liste des formations
‣ Effectue des demandes de formation
‣ Consulte son historique de formation
Le manager :
‣ Gère les demandes de formations de son équipe
‣ Gère les compétences de son équipe
Diagramme de classe
Le diagramme de classes est un schéma utilisé pour présenter les classes et les interfaces des
systèmes ainsi que les différentes relations qu’elles entretiennent.
14 sur 27
Diagramme d’activité
Le diagramme d’activité permet de modéliser le déclenchement d’événements en fonction
de l’état du système. Il sert également à décrire un flux de travail.
Nous pouvons par exemple connaitre le statut d’une demande de formation en fonction des
évènement déclenchées dans le système.
Diagramme de séquence
Le diagramme de séquence est la modélisation des interactions entre les acteurs et le sys-
tème dans l’ordre chronologique.
15 sur 27
Par exemple, afin de pouvoir faire une action, un acteur doit préalablement se connecter.
Diagramme de déploiement
Le diagramme de déploiement permet de représenter de façon statique l’infrastructure phy-
sique du système.
16 sur 27
4.2. Modélisation de l’application
Il s’agit ici de décrire l’interface de notre application. Pour se faire, nous allons modéliser le
plan du site, puis nous réaliserons les maquettes.
Plan du site
Le plan est la « carte » de l’application : toutes les pages y sont répertoriées et hiérarchisées ;
leur accessibilité dans le déroulement logique du processus utilisateur est explicité.
La première page accessible est la page authentification. Une fois connecté, chaque acteur à
des fonctionnalités propres représentées par un code couleur.
17 sur 27
Maquette de l’application
Cette étape consiste à réaliser les écrans sur un logiciel adapté, tels que les verront les utilisa-
teurs finaux. Les maquettes serviront par la suite lors du développement de la partie front.
Afin de réaliser les maquettes graphiques, nous avons utilisé Adobe XD. Cet outil permet
également la création de scénarios : en cliquant sur un bouton de la maquette, l’écran suivant
correspondant s’affiche.
18 sur 27
19 sur 27
4.3. Architecture physique de l’application
L’architecture définie est connue sous le nom de « trois-tiers ». Elle est constituée de trois
couches communiquant entre elles : la couche client, la couche serveur d’application et la
couche serveur de base de données et est reconnue dans le monde professionnel de par sa
bonne fiabilité, sécurité, disponibilité et évolutivité.
20 sur 27
Pour l’hébergement de notre serveur d’application, notre choix s’est porté sur Amazon Web
Services. En déposant simplement le fichier .war généré dans un répertoire dédié, l’application
est déployée et accessible à l ‘URL suivante :
http://assistrh-env-1.wmteyrppjf.us-east-1.elasticbeanstalk.com/connexion.html
Pour l’hébergement de notre base de donnée, nous avons choisi la solution gratuite propo-
sée par le site remotemysql.com qui répond entièrement aux besoins de l’application.
!
Architecture 3 tiers.
De gauche à droite : postes client, serveur d’application et base de données.
L'application en elle-même n'est déployée que sur la partie serveur : le client n’a besoin que
d’un navigateur web compatible. Cette facilité de déploiement aura pour conséquence non
seulement de réduire le coût de déploiement mais aussi de permettre une évolution régulière
du système car elle nécessitera que la mise à jour de l'application sur le serveur applicatif.
21 sur 27
5. Réalisation
5.1. Développement des fonctionnalités
Architecture logicielle
Pour répondre aux besoins de l’architecture trois tiers, nous utiliserons le modèle MVC ; mo-
dèle – vue – contrôleur.
‣ Modèle : contient les données et la logique de traitement (validation, lecture et enregis-
trement) via les classes métier. Il vient suppléer le contrôleur et est complété par le DAO (ou
objet d’accès au données) qui est un patron de conception gérant l’accès aux donnés dans
notre project. Il correspond ici à la partie domaine.
‣ Vue : interface graphique qui sert à la présentation et la modification des données du mo-
dèle. Elle est matérialisée ici par les différents fichiers JSP du dossier webapp.
‣ Contrôleur : gère la partie logique de l’interaction homme machine.
Voici dans le détail leur composition :
22 sur 27
23 sur 27
5.2. Écriture de la documentation technique
JavaDoc
La JavaDoc, outil développé par Oracle donne la possibilité de créer une documentation
d’API au format HTML. Cette documentation se réalise à partir des commentaires présents dans
le code source de l’application, qui sont écrits tout au long du développement.
ReadMe
Le fichier ReadMe est un fichier dans lequel apparaît des informations relatives aux autres fi-
chiers constitutif du projet.
5.3. Tests
Tests réalisés
Tests unitaires. À l’apparition d’une nouvelle fonctionnalité,
celle-ci est testé afin de voir si l’action réali-
sée est conforme à l’attendu.
Tests de non-régression. Au fur et à mesure que notre site internet
prend de l’ampleur et possède de multiples
fonctionnalités, celles-ci sont à tester indé-
pendamment dans l’environnement. Cela
permet de vérifier qu’un nouvel ajout n’a pas
détérioré une fonctionnalité déjà présente.
Tests de bout-en-bout. Consiste à tester un process précis. Par
exemple la demande et la validation de la
demande de formation: faire la demande de
formation par l’employé, gestion de cette
demande par le manager, réponse visible
par l’employé.
24 sur 27
6. Livraison
6.1. Déploiement de l’application
L’un des pré-requis projet initiaux concernait la mise à disposition de l’application sur une
adresse internet accessible depuis l’extérieur. Il a donc fallu sélectionner un hébergeur pour la
base de données et l’application.
Application web
Nous avons utilisé l’offre « Elastic Beanstalk » d’Amazon Web Services, un des leaders du do-
maine du cloud computing à la demande, qui permet de déployer des applications et services
web développés avec différents langages populaires comme Java, .NET, Node.js…
Il s’agit de venir déposer un fichier .zip ou .war du projet, le déploiement et la mise en ligne
étant totalement automatique et optimisée.
25 sur 27
Base de données
L’hébergement de la base s’est fait sur un site gratuit, remotemysql.com. Les offres d’Amazon
ont été jugées trop complexes et coûteuses par rapport aux dimensions projet.
Le site permet la mise en ligne de deux bases de données au maximum. Il fournit ensuite les
identifiants pour l’accès à distance via des logiciels ou propose un accès direct via phpMyAd-
min.
26 sur 27
7. Conclusion
À travers ce dossier, nous avons décrit le processus de création de l’application Assist-RH.
Il a d’abord fallu prendre connaissance du sujet et évaluer un périmètre d’action. Nous nous
sommes ensuite organisés et répartis les tâches en fonction de la charge, des délais accordés et
des points forts de chacun. Nous avons conceptualisé l’application avec des outils et langages
de modélisation (Adobe XD, UML) ce qui nous a conféré une vision claire de l’application finale.
La phase de développement a concrétisé notre travail. Des livraisons sur le service cloud
d’Amazon ont été régulièrement effectuées, ainsi qu’une batterie de tests.
Pendant toute la durée du projet, nous avons réfléchi aux axes possible d’amélioration et en
avons détecté un certain nombre, comme par exemple l’amélioration des contrôles de saisie
utilisateur sur certaines parties de l’application. C’est dans cet objectif que notre architecture lo-
giciel a été définit : elle est évolutive et facilement maintenable.
Nous avons su partager lors de ce projet en groupe nos idées et agir malgré des avis parfois
divergents. De nombreuses compétences informatiques acquises ces deux dernières années
ont pu être mises en oeuvre. Nous avons également été sensibilisés aux processus métiers rela-
tifs à la gestion des formations.
27 sur 27
