Ce document présente un projet de fin d'étude pour obtenir un diplôme d'ingénieur en informatique, réalisé à l'école supérieure privée d'ingénierie et de technologies (esprit) durant un stage de six mois chez Dream Tek Consulting. L'objectif principal du projet était de concevoir et de mettre en place une application web pour le dashboarding et l'automatisation de la gestion des ressources humaines et des produits de l'entreprise. Le rapport détaille le projet à travers ses aspects techniques et fonctionnels.

1. INFORMATIQUE
Système de Dashboarding
et d’automatisation de la gestion des
ressources entre RH et production
pour les PME
Réalisé par: Lina Meddeb
Encadrant ESPRIT: Mme. Amal Rihani
Encadrant Entreprise: M. Anis Kossontini
2020 - 2021

2. Dédicace
“ À celle qui était mon école et mon soutien continuel,
Pour son éternelle mémoire,
À ma plus chère au monde, ma mère feu Samira BEN
SOUILAH.
À celui qui n’a cessé de me soutenir,
À celui qui a toujours cru en moi,
Pour l’éducation exemplaire qu’il m’a inculquée,
À mon cher père Rjeb MEDDEB.
À celui qui égaie mes jours,
À celui qui me submerge d’affection,
Pour l’amour sans failles qu’il a pour moi,
À mon cher frère Walid MEDDEB.
À toute la famille MEDDEB et BEN SOUILAH,
À toutes les personnes qui me sont chères,
Je vous dédie ce travail en témoignage de reconnaissance et
de gratitude.
”
- Lina

3. Remerciements
J’adresse mes sincères remerciements et ma grande gratitude à toute personne ayant
contribué à ce travail :
À Monsieur Anis KOSSONTINI et à toute l’équipe de DREAM TEK CONSUL-
TING, pour cette unique opportunité et cet excellent cadre professionnel.
À Madame Amal RIHANI, pour son encadrement pédagogique et ses conseils plus
qu’utiles.
À Madame Sawssan SELMI, qui m’a aidé durant les restitutions, m’a guidé constam-
ment et a précieusement enrichi ce projet.
À l’ensemble des enseignants d’ESPRIT, qui m’ont formé durant des années et
m’ont inculqué les bases de ma formation.
Aux membres du jury, qui ont accepté de lire et évaluer ce travail
Qu’ils trouvent, ici, le fruit de leur soutien inconditionnel et le témoignage d’un travail
à la hauteur de leurs attentes.

4. Résumé
Ce document englobe mon projet de fin d’étude réalisé dans le but d’obtenir le diplôme
national d’ingénieur en informatique de l’école supérieure privée d’ingénierie et de tech-
nologies (ESPRIT), suite à un stage qui a duré six mois effectués au sein de l’entreprise
« DREAM TEK Consulting ». Un stage qui avait principalement pour objectif d’élargir et
d’appliquer mes acquis et mes connaissances et de me préparer pour la vie professionnelle.
Ma mission était de concevoir et de réaliser une application web pour le Dashboarding
et l’automatisation de la gestion des ressources RH et des produits de l’entreprise.
Ce rapport vous donne une idée bien détaillée sur le projet dans son cadre technique
et fonctionnel.
Abstract
The present document contains the details of the work done as the end-of-study project
to get the national degree of IT engineering from the private higher school of enginee-
ring and technology (ESPRIT), after a six-month internship in the firm « DREAM TEK
Consulting ». An internship that aimed to expand and apply my skills and knowledge.
My mission was to design and implement a web application for dashboarding and
automating the management of HR resources and the company products.
This document offers a very detailed idea about the project in both technical and
functional scopes.

5. Table des matières
Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 Présentation générale du projet . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Cadre général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 3
1.4 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7.1 Présentation des méthodologies . . . . . . . . . . . . . . . . . . . . 7
1.7.2 Etude comparative des méthodes UP . . . . . . . . . . . . . . . . . 8
1.7.3 Choix de méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Analyses et spécification des besoins . . . . . . . . . . . . . . . . . . . . . 12
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Etude fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Identification des acteurs de système . . . . . . . . . . . . . . . . . 12
2.2.2 Identification des besoins fonctionnels . . . . . . . . . . . . . . . . 12
2.2.3 Identification des besoins non fonctionnels . . . . . . . . . . . . . . 14
2.2.4 Les diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . 15
2.2.5 Diagramme de séquence système . . . . . . . . . . . . . . . . . . . 18
2.3 Etude technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2 Coté client - Angular Framework . . . . . . . . . . . . . . . . . . . 19
2.3.3 Coté Serveur – Spring Boot . . . . . . . . . . . . . . . . . . . . . . 21
2.3.4 La Sécurité - Spring Security . . . . . . . . . . . . . . . . . . . . . 22
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Diagramme des paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Diagramme de classe global . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Diagrammes de séquence objet . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.1 Diagramme du séquence objet pour le cas d’utilisation modifier
photo de profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.2 Diagramme du séquence objet pour le cas d’utilisation ajouter projet 28

6. Table des matières
3.4.3 Diagramme du séquence objet pour le cas d’utilisation demander
un congé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5 Diagramme d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.1 Diagramme d’activité activer compte . . . . . . . . . . . . . . . . . 31
3.5.2 Diagramme d’activité récupérer un mot de passe . . . . . . . . . . 32
3.5.3 Diagramme d’activité passer un quiz . . . . . . . . . . . . . . . . . 33
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 Réalisation et Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.2 Environnement Logiciel . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.3 Autres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Interfaces graphiques d’application . . . . . . . . . . . . . . . . . . . . . . 38
4.3.1 Interface graphique de confirmation de compte . . . . . . . . . . . . 38
4.3.2 Interface graphique d’authentification . . . . . . . . . . . . . . . . . 39
4.3.3 Interface graphique de liste des utilisateurs . . . . . . . . . . . . . . 39
4.3.4 Interface graphique de gestion de profil . . . . . . . . . . . . . . . . 40
4.3.5 Interface graphique d’ajout d’un projet . . . . . . . . . . . . . . . . 40
4.3.6 Interface graphique de la liste des projets . . . . . . . . . . . . . . . 41
4.3.7 Interface graphique de détails de projet et ses tickets . . . . . . . . 41
4.3.8 Interface graphique de Kanban bord . . . . . . . . . . . . . . . . . 42
4.3.9 Interface graphique d’affichage de calendrier . . . . . . . . . . . . . 43
4.3.10 Interface graphique d’ajout d’une question au quiz . . . . . . . . . 44
4.3.11 Interface graphique de la liste de quiz à passer . . . . . . . . . . . 45
4.3.12 Interface graphique de résultat de quiz . . . . . . . . . . . . . . . . 45
4.3.13 Interface graphique de Dashboard . . . . . . . . . . . . . . . . . . . 46
4.4 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.1 Test unitaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.2 Test API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.3 Tests d’acceptations . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Conclusion et perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7. Table des figures
1.1 Interface graphique IDGOS . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Interface graphique Idylis.com . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 UP itératif et incrémental [1] . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Architecture de processus 2TUP [2] . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Diagramme du cas d’utilisation global . . . . . . . . . . . . . . . . . . . . 15
2.2 Diagramme raffiné du cas d’utilisation gérer les utilisateurs. . . . . . . . . 16
2.3 Diagramme raffiné du cas d’utilisation gérer les tickets . . . . . . . . . . . 17
2.4 diagramme de séquence système consulter la liste des projets . . . . . . . . 18
2.5 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Architecture de Framework Angular [4] . . . . . . . . . . . . . . . . . . . . 20
2.7 Architecture MVVM [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8 Les couches de Spring Boot [6] . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 Ecosystéme Spring Security [7] . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Diagramme de classe global . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Diagramme du séquence objet modifier photo de profil . . . . . . . . . . . 27
3.4 Diagramme du séquence objet ajouter un projet . . . . . . . . . . . . . . . 29
3.5 Diagramme du séquence objet demander un congé . . . . . . . . . . . . . . 30
3.6 Diagramme d’activité d’activer un compte . . . . . . . . . . . . . . . . . . 32
3.7 Diagramme d’activité de récupérer un mot de passe . . . . . . . . . . . . . 33
3.8 Diagramme d’activité passer un quiz . . . . . . . . . . . . . . . . . . . . . 34
4.1 Caractéristiques du PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Spring Tool Suite logo [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 MySQL Workbench logo [9] . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 NPM logo [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5 Angular logo [12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6 Web Storm logo [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.7 GitLab logo [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.8 Docker logo [15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.9 Tableau software logo [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.10 Postman logo [17] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.11 Interface de la confirmation de compte . . . . . . . . . . . . . . . . . . . . 39
4.12 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.13 Interface de la liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . . 40
4.14 Interface de gestion de profil . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.15 Interface d’ajout d’un projet . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8. Table des figures
4.16 Interface de la liste des projets . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.17 Interface de détails projets . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.18 Interface de kanban bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.19 Interface d’affichage de calendrier . . . . . . . . . . . . . . . . . . . . . . . 44
4.20 Interface d’ajout d’une question au quiz . . . . . . . . . . . . . . . . . . . 45
4.21 Interface de la liste des quiz à passer . . . . . . . . . . . . . . . . . . . . . 45
4.22 Interface de liste de résultat de quiz . . . . . . . . . . . . . . . . . . . . . . 46
4.23 Interface de Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.24 Test de filtre sur les projet en utilisant JUnit . . . . . . . . . . . . . . . . 47
4.25 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.26 Accès refusé à l’API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.27 Accès accepté à l’API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.28 formulaire d’ajout de ticket . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.29 email d’avancement du développeur . . . . . . . . . . . . . . . . . . . . . 50
4.30 rapport quotidien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.31 Interface d’ajout de ticket avec conflit . . . . . . . . . . . . . . . . . . . . 51
4.32 Interface de choix de solution . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.33 Interface de résolution de conflit . . . . . . . . . . . . . . . . . . . . . . . . 52
4.34 Interface de notification sur Slack . . . . . . . . . . . . . . . . . . . . . . . 53

9. Liste des tableaux
1.1 Etude Comparative des méthodes UP . . . . . . . . . . . . . . . . . . . . . 9
2.2 Documentation CU : Ajouter un utilisateur . . . . . . . . . . . . . . . . . 16
2.4 Documentation CU : Ajouter un Ticket . . . . . . . . . . . . . . . . . . . . 17

10. Introduction générale
Actuellement, les usages de la technologie de l’information ne cessent de s’étendre pour
engendrer pratiquement tous les secteurs, tel que l’agriculture, l’audiovisuel, la médecine et
la géolocalisation. Puisque la technologie de l’information améliore la qualité des services
dans n’importe quel domaine elle touche, offre plus de rapidité et de traçabilité, elle tend
à devenir un moteur majeur de progrès et du bon fonctionnement des sociétés.
En effet, notre monde devient de plus en plus connecté, par des ordinateurs de bureau
et portables, par des Smartphones et des tablettes. L’éclosion de ces dispositifs, acces-
sibles à tous, la simplicité de leur utilisation et la facilité de leur transport favorisent la
progression du développement des logiciels informatiques vers des applications orientées
Web.
D’ailleurs, l’implémentation de applications Web devient un atout de plus en plus
crucial dans le monde des entreprises, là où le besoin de développer, déployer et main-
tenir ces ressources accessibles pour un nombre important d’utilisateurs sur des diverses
plateformes.
Par conséquent, les entreprises se dirigent vers ces applications qui automatisent leurs
métiers, surtout leurs quotidiens en se basant sur une conception efficace et rapide d’outils
métiers.
Les logiciels d’automatisation ont aussi la possibilité de résoudre les problèmes d’orga-
nisation surtout dans les grandes entreprises ayant de nombreux employés qui possèdent
des tâches et des rôles différents. Car, pour être réaliste aucune entreprise ne possède une
organisation parfaite. Au fur et à mesure que les tâches et les employés se diversifient, de
plus en plus de complications organisationnelles peuvent se produire. Ces complications
peuvent concerner les employés, l’équipe ou l’entreprise en gros et qui peuvent faire de sa
maintenabilité une tâche de plus en plus irréalisable.
Ceci est le cadre général dans lequel s’inscrit notre projet de fin d’études effectué au
sein de DREAMTEK CONSULTING. Cette solution intitulée ”Système de dashboarding
et d’Automatisation de la gestion des ressources entre RH et Production pour les PME”
qui consiste à réaliser une plateforme pour l’automatisation et la gestion des processus
interne à l’entreprise.
Afin de mieux exposer ce projet, nous présentons les éléments de cette application
dans ce présent rapport qui est composé de quatre chapitres comme suit :
• Le premier chapitre est dédié à présenter le contexte général du projet
1

11. Introduction générale
• Le deuxième chapitre est consacré à détailler les spécification et l’analyse des be-
soins fonctionnels et non-fonctionnels, le choix de la méthodologie. Ainsi que l’étude
technique de ce projet.
• Le troisième chapitre consiste à détailler la conception de plateforme par le biais de
diagramme des paquetages, le diagramme séquence objet et les diagrammes d’acti-
vité de plusieurs fonctionnalités de l’application.
• Le dernier chapitre, présente l’environnement de travail matériel et logiciel et met
en valeur le travail réalisé sous forme des captures d’écran accompagnées d’une
description détaillée.
2

12. Chapitre 1
Présentation générale du projet
1.1 Introduction
Dans ce premier chapitre, nous décrivons la vue d’ensemble du projet à réaliser. Dans
un premier lieu, nous présentons la société d’accueil, qui a proposé et a hébergé ce sujet.
Dans un deuxième lieu, nous décrivons le projet en évoquant la problématique ainsi que
les différents objectifs à atteindre, nous critiquons les applications existantes et enfin nous
terminons par la description de la solution envisagées et la méthodologie adoptée.
1.2 Cadre général du projet
Ce stage s’inscrit dans le cadre d’un projet de fin d’études en vue de l’obtention
du diplôme national d’ingénieur en informatique, spécialité génie logiciels à ESPRIT.
Il est effectué au sein de la société DREAM TEK CONSULTING qui est spécialisée
dans le domaine de développement des solutions web. Ce projet consiste à concevoir et
à développer une plate-forme de gestion des ressources humaines et de projets dans les
PMEs.
1.3 Présentation de l’organisme d’accueil
DREAM TEK CONSULTING est une société spécialisée dans le domaine de dévelop-
pement web (sites et portails). Les technologies utilisées sont : Symfony, Zend, Rubedo,
PHP, Javascript, CSS, GIT, Hébergement ...
La plupart des clients de DREAM TEK CONSULTING sont des entreprises digitales
étrangères (France, Allemagne, ...), spécialisés aussi dans le domaine de développement
web et qui sont en manque d’effectif pour le développement de leurs projets.
3

13. Chapitre 1. Présentation générale du projet
1.4 Problématique
Faire partie d’une petite ou moyenne entreprise (PME) comme notre société d’accueil,
c’est souvent travailler en collaboration avec une équipe textile qui fait des miracles au
quotidien et qui met des produits compétitifs et de bonne qualité sur le marché.
En effet, lors du stage d’été fait chez DREAM TEK CONSULTING, en Juillet et Août
2020, j’est constaté que la société se trouve embarrassé devant plusieurs lacunes :
• La non cohérence et l’hétérogénéité des information par l’utilisation de plusieurs
outils (Drive, Trello, email...) pour la gestion des tickets de projets.
• La charge du travail lourde pour les tâches administratifs répétitifs.
• Les conflits dans les plannings de travail à cause de sa distribution d’une façon
manuelle.
• Le dépassement des deadlines.
• Le manque d’historique de production.
• Les données des tâches qui risquent d’être perdues à tout moment.
1.5 Etude de l’existant
L’utilisation des même outils que les grandes entreprise devient alors une nécessité
pour les PME pour avoir les même privilèges pour s’agrandir et se développer.
Ce qui nous a amené à proposer, au chef de l’entreprise , d’utiliser une application
ERP qui permet d’affronter les obstacles du société par l’automatisation et la gestion des
ressources humaines et des projets.
Un Entreprise Ressource Planning (ERP) est un système de gestion des ressources de
l’entreprise. Dans les petites et moyenne entreprises (PME), l’ERP améliore le processus
de planification des ressources , de réduction des coûts de la production et qui assure
l’augmentation de productivité
A travers cette partie, nous allons nous intéresser au ERP destinés aux PME existantes
dans le marché pour dégager leurs faiblesses et mettre en valeur ce que notre solution va
apporter.
IDGOS
La Solution de gestion IDGOS s’adresse aux petites et moyennes entreprises (TPE,
PME), avec des spécialisations pour la Logistique, l’Industrie, le Bâtiment… soucieuses
de structurer et d’optimiser leurs processus métier tout en gardant la maitrise de leur
système d’information.
Vous trouvez dans la figure 1.1 l’interface graphique de IDGIOS.
4

14. Chapitre 1. Présentation générale du projet
Fig. 1.1 : Interface graphique IDGOS
Les limites de cette application sont :
• Interface très modeste
• Interface non responsive
• Il s’agit d’une application desktop que nous devons télécharger et n’est pas dispo-
nible sur le web.
• Manque d’une partie dashboarding
• L’application contient des fonctionnalités dont nous n’avons pas besoins donc nous
payons des frais pour une solution non spécifique.
• Une solution couteuse pour une startup : 40 euros /mois pour 5 utilisateurs soit
1584dt/an
Idylis.com
idylis.com est un logiciel de gestion commerciale, de comptabilité et CRM en ligne qui
permet une gestion facile de comptabilité, des factures, des ventes, des achats.
Vous trouvez ci-dessous l’interface graphique de idilys.com
5

15. Chapitre 1. Présentation générale du projet
Fig. 1.2 : Interface graphique Idylis.com
Les limites de cette application sont :
• Manque de filtrages
• Ne répond pas à tous les besoins fonctionnels de la société accueillante (la partie
évaluation des compétences par exemple)
• Une solution couteuse pour une startup : 49 euros/mois/utilisateur soit 1940,4dt
par utilisateur.
1.6 Solution proposée
Bien que les applications proposées bénéficient de plusieurs années d’expérience, au-
cune d’entre elles ne satisfait pleinement les attentes de DREAM-TEK CONSULTING
en termes d’exigences. Elles présentent un grand défaut commun c’est la non satisfaction
des besoins de l’entreprise tel que le module responsable de rémunération et le coût très
élevé qui peut être un défi pour une PME.
La solution que nous avons proposé à l’entreprise pour faire face aux problèmes consta-
tés consiste à implémenter un système de dashboarding et d’automatisation de la gestion
des ressources humaines et de production. Cette solution doit être à la fois sécurisée et
fiable car elle s’intéresse au cœur de l’activité de la société, et elle est utilisée quotidien-
nement et intensivement par les collaborateurs.
L’application est composée par les principales parties suivantes :
• Le module de gestion des utilisateurs
C’est le module qui gère l’inscription et l’authentification de l’application ainsi que
les profils des utilisations.
6

16. Chapitre 1. Présentation générale du projet
• Le module TimeSheet
C’est le module qui s’intéresse à la partie production et à l’activité de l’entreprise,
il contient 4 sous modules :
– La gestion des projets
– Le suivi de travail
– La gestion de congés et des absences
– La planification des réunions.
• Le module d’évaluation et de la rémunération
C’est le module responsable des différents types d’évaluations tels que :
– L’évaluation des compétences
– L’évaluation de l’environnement de travail
Le module d’évaluation et de la rénumération cherche à fidéliser les collaborateurs
par une ré-compensation suivant leurs contribution au succès de l’entreprise.
• Le module de dashboarding
C’est le module responsable de générer des chartes graphiques et des statistiques
qui s’intéressent aux différents KPI de la société comme :
– L’avancement des projets
– L’augmentation de chiffre d’affaires
– La gestion des congés et des absences
– Le taux d’absentéisme
Notre solution doit également être simple à utiliser, ergonomique et bien sécurisé.
1.7 Méthodologie de travail
1.7.1 Présentation des méthodologies
Le développement d’un logiciel diffère d’un projet à un autre à cause de plusieurs
facteurs tels que sa complexité, la quantité de travail exigée et son degré de risque. Il
est donc nécessaire de choisir la solution de structuration, planification et de contrôle de
processus de développement la plus appropriée.
En effet, on peut citer parmi les méthodologies de travail existant :
• Les méthodes Agiles (Exp : SCRUM)
Un ensemble de pratiques qui peuvent être appliquées à plusieurs types de projets
mais limité au domaine des IT parce que les principes Agile se traduisent par des
livrables concrets plutôt que des services.
7

17. Chapitre 1. Présentation générale du projet
• Les processus unifiés (UP) (Exp : XUP, RUP, 2TUP) Les méthodes qui offrent un
cadre de développement logiciel générique, itératif et centré sur l’architecture et qui
supportent le cycle de vie d’un logiciel.
Nous avons la méthode UP comme elle est basée sur les composants et fournit un bon
cadre de développement logiciel des systèmes orientés objet.
Les processus unifiés se distinguent par les caractéristiques suivantes :
• La méthode UP est itératif et incrémental
Le projet est divisé en des itérations qui assure la maîtrise de partie de gestion
risques et de suivi d’avancement. A chaque fin d’itération une partie exécutable du
produit final est produite d’une façon incrémentale.
Le processus est bien détaillé dans la figure 1.5 .
Fig. 1.3 : UP itératif et incrémental [1]
• La méthode UP est guidée par des cas d’utilisation
La satisfaction des utilisateurs (les êtres humains et les autres systèmes) est l’objectif
principal de tout système logiciel, Le processus est piloté par les exigences de ces
utilisateurs présentés par les cas d’utilisation.
• La méthode UP est centré sur l’architecture
L’architecture est le lien entre les différents intervenants au projet. Elle est éta-
blie dès le début de projet car plus ce dernier avance plus que les risques liés à
l’architecture s’élèvent.
1.7.2 Etude comparative des méthodes UP
Il existe plusieurs types de méthodes UP, une étude comparative est illustrée dans le
tableau 1.1.
8

18. Chapitre 1. Présentation générale du projet
RUP XP 2TUP
Description r
• Il est non
seulement une
méthodologie
de travail mais
aussi un outil
prêt à l’emplois)
• Un collectif de
“Best Practices”
de développe-
ment (le travail
en équipe et l’in-
ter échange des
compétences)
• Basée sur l’ar-
chitecture
• Présentée par
un cycle de
développement
en V
Points forts
• Spécifie la
communication
entre les in-
tervenants de
projets grâce
au (livrables,
plannings,
prototypes)
• Facile à mettre
en place
• Offre une im-
portance aux as-
pects techniques
(les prototypes,
les règles de dé-
veloppement, les
tests etc.)
• Offre une im-
portance à la
technologie et à
la gestion des
risques
• Définit les
profils des in-
tervenants, les
livrables, les
plannings, les
prototypes [2]
Points faibles
• Coûteux au
terme de per-
sonnalisation
• Élimine la
Phase d’analyse
• Ne couvre pas
toute la pipeline
de développe-
ment ,les phases
en amont et en
aval, la capture
des besoins,
le support, la
maintenance
, les tests
d’intégration
• Plutôt superfi-
ciel au niveau
le pipeline de
développement,
les phases en
amont et en
aval, la capture
des besoins,
le support, la
maintenance,
les tests d’inté-
gration
Type de projets > 10 personnes < 10 personnes Tout Tailles
Itérative Oui Oui OUI
Tab. 1.1 : Etude Comparative des méthodes UP
9

19. Chapitre 1. Présentation générale du projet
1.7.3 Choix de méthodologie
D’après l’étude précédente, nous avons choisi le processus 2TUP qui garantit une
bonne gestion de risque et qui assure l’adaptation avec des projets de toute taille.
Le processus 2TUP ou cycle en Y est un processus unifié. Il propose un cycle de vie
qui assure une séparation entre les aspects techniques (l’étude de l’implémentation) et les
aspects fonctionnels (l’étude de l’application).
Ce processus est basé sur trois branches principales :
• La branche technique
• La branche fonctionnelle
• La branche de conception et de réalisation
La figure 1.4 détaille les étapes de développement des trois branches de ce processus :
Fig. 1.4 : Architecture de processus 2TUP [2]
La branche fonctionnelle
Ses principales étapes se présentent comme suit :
• L’étape de la capture des besoins fonctionnels
Cette phase permet de définir la borne fonctionnelle entre le système et son milieu
de travail, ainsi que les activités espérées de la part des différents acteurs.
• L’étape d’analyse
Cette phase est engagée pour spécifier les besoins fonctionnels pour le but d’obtenir
une vision claire sur la fonction à réaliser.
10

20. Chapitre 1. Présentation générale du projet
La branche technique
Elle regroupe les étapes suivantes :
• L’étape capture des besoins techniques
Elle inclut toutes les anomalies rencontrées sur les types de technologies pour la
conception du système. Elle met en jeu de plus les outils et le matériel sélectionnés.
• L’étape de la conception générique
Elle détermine les éléments fondamentaux à la construction de l’architecture tech-
nique, et indépendamment des aspects fonctionnels.
La phase conception - réalisation
Elle se résume en ces étapes :
• L’étape de la conception préliminaire
Elle produise un prototype de conception système, afin d’organiser les composants,
les services techniques et fonctionnels du système.
• L’étape de la conception détaillée
Elle permet d’obtenir un résultat en fournissant une image prête à fabriquer sur le
système complet.
• L’étape de codage
Elle permet d’exécuter la production des composants et de réaliser des tests unitaires
sur le code au fur et à mesure de leur réalisation.
• L’étape de recette
Elle consiste à valider les différentes tâches du système développé.
1.8 Conclusion
Durant ce premier chapitre, nous sommes intéressés au cadre de ce projet. En pre-
mier lieu, nous avons présenté l’entreprise d’accueil “DREAM TEK CONSULTING”. En
deuxième lieu, nous avons proposé la problématique du projet afin de donner une vue
générale. Ensuite, nous avons montré les solutions proposées par l’application qui per-
mettent d’éliminer les faiblesses identifiées précédemment. Le chapitre suivant va être
dédié à l’étude fonctionnelle et technique du projet.
11

21. Chapitre 2
Analyses et spécification des besoins
2.1 Introduction
Après avoir étudié les notions théoriques nécessaires pour mieux comprendre le projet,
nous commençons par la phase d’analyse des besoins et des spécifications techniques. Dans
ce deuxième chapitre, nous développons une étude fonctionnelle du projet basé sur les
diagrammes de cas d’utilisation et quelques diagrammes de séquences ainsi qu’une étude
technique des technologies utilisés.
2.2 Etude fonctionnelle
L’étude fonctionnelle est une phase nécessaire pour expliquer le sujet et les tâches
nécessaire à réaliser. Elle met en valeur la liste des acteurs, leurs tâches, et les interactions
entre eux sous la forme des diagrammes UML.
2.2.1 Identification des acteurs de système
• Le collaborateur : C’est le principal protagoniste de notre application. (il peut-être
un développeur/un manager ou un RH)
• L’administrateur/Manager : C’est le responsable de la gestion de toute l’application
• Le développeur : C’est un simple utilisateur.
• Le responsable RH : Il est responsable de la partie de gestion des utilisateurs et le
traitement des évaluations des collaborateurs.
2.2.2 Identification des besoins fonctionnels
En tant que collaborateur, je peux :
12

22. Chapitre 2. Analyses et spécification des besoins
• S’authentifier (simple ou via compte google) : elle est obligatoire pour accéder à
l’espace de collaborateur.
• Recevoir un email de confirmation de compte.
• Changer le mot de passe en cas d’oubli.
• Personnaliser mon propre espace.
• Consulter le planning (quotidien, mensuel, annuel )
• Demander un congé.
• Consulter le solde des congés.
• Commenter la demande de congé.
• Recevoir une réponse aux demandes de congé.
• Avoir des alertes de réunions.
En tant que Administrateur/Manager, je peux :
• Gérer les utilisateurs.
• Valider les inscriptions faites par comptes google.
• Archiver les profils d’utilisateurs.
• Archiver les projets terminés.
• Gérer les projets et les tickets.
• Consulter la liste des bonus calculés.
• Consulter la liste des employés les plus performants.
• Consulter les tableaux de bord des KPI.
En tant que développeur, je peux :
• Avoir une notification d’affectation au projet via Slack.
• Consulter la liste, les détails et l’avancement des projets qui l’ont été affectés.
• Visualiser les taches dans un KanbanBoard.
• Archiver les projets terminés.
• Gestion des projet et des tickets.
• Marquer l’état d’avancement d’un ticket par drag and drop des tickets dans le
kanban board.
13

23. Chapitre 2. Analyses et spécification des besoins
• Recevoir une liste des tâches quotidiennes
• Avoir un brouillon d’email d’avancement.
• Envoyer automatique d’email d’avancement par l’application.
• Recevoir des alertes en cas de retard.
• Passer des évaluations.
• Consulter les résultats d’évaluations.
• Consulter les solutions des évaluations passés.
En tant que RH, je peux :
• Gérer les contrats.
• Gérer les évaluations.
• Valider le planning après la gestion des conflits par le système.
• Gérer les réunions.
2.2.3 Identification des besoins non fonctionnels
Bien qu’ils ne soient pas en relation avec le métier, les besoins non fonctionnels sont
essentiels pour assurer une meilleure qualité de l’application.
Notre solution doit assurer :
• La maintenabilité
Le code de l’application doit être lisible, commenté et bien expliqué pour faciliter
la contribution aux autres développeurs et pour garantir la maintenance de l’appli-
cation si nécessaire.
• L’ergonomie
L’application doit être facile à utiliser par les utilisateurs avec des interfaces moderne
et interactives, et responsive avec tous types d’écrans (mobile, large...). Ceci est
garanti avec l’utilisation de Angular Material et Bootstrap.
• La performance
Le temps de réponse de la solution doit être tolérable et stable, l’utilisation de
Framework Angular nous donne la possibilité de créer des Single Pages Application
qui se caractérise par un temps de réponse rapide lors de chargement des pages.
• La sécurité
L’outil doit être sécurisé et contrôlé par les droits d’accès des utilisateurs. L’utilisa-
tion de Spring Security est un moyen d’assurer la sécurité via l’utilisation du Web
Token.
14

24. Chapitre 2. Analyses et spécification des besoins
2.2.4 Les diagrammes de cas d’utilisation
Le diagramme de cas d’utilisation décrit le comportement du système du point de vue
de l’utilisateur. Il divise ses fonctionnalités en cas d’utilisations qui permettent d’exprimer
les besoins de ses utilisateurs [3], il est présenté par la figure 2.1 ci-dessous.
Fig. 2.1 : Diagramme du cas d’utilisation global
15

25. Chapitre 2. Analyses et spécification des besoins
Diagramme raffiné du cas d’utilisation gérer les utilisateurs
Fig. 2.2 : Diagramme raffiné du cas d’utilisation gérer les utilisateurs.
Description textuelle cas d’utilisation (CU) : Ajouter un utilisateur
Acteur : Administrateur
Pré condition : L’administrateur est déjà connecté
Enchaînement principal :
Le cas d’utilisation démarre lorsque l’administrateur souhaite ajouter un nouvel utili-
sateur.
1. Le système affiche l’interface de l’ajout des utilisateurs.
2.L’administrateur saisit les informations du nouvel utilisateur.
3. Une fois que les données seront validées l’utilisateur sera créé.
4. Le système envoie un mail de confirmation de compte ainsi qu’un mot de passe
aléatoire au nouveau collaborateur ajouté.
Post condition : Affichage d’interface de consultation de la liste
d’utilisateurs.
Enchaînement alternatif : Si les données saisies sont erronées, ou le nom d’utilisateur
/ email existent déjà, l’administrateur vérifie les données inserées et valide de nouveau
le formulaire d’ajout.
Tab. 2.2 : Documentation CU : Ajouter un utilisateur
16

26. Chapitre 2. Analyses et spécification des besoins
Diagramme raffiné du cas d’utilisation gérer les tickets
Fig. 2.3 : Diagramme raffiné du cas d’utilisation gérer les tickets
Description textuelle cas d’utilisation (CU) : Ajouter un ticket
Acteur : Administrateur
Pré condition : L’administrateur est déjà connecté
Enchaînement principal :
Le cas d’utilisation démarre lorsque l’administrateur souhaite ajouter un nouveau ticket
à un projet existant.
1. Le système affiche l’interface d’affectation de ticket au développeur.
2. L’administrateur choisit l’estimation de ticket ainsi que le nom de développeur.
3. Le système vérifie la disponibilité de ce développeur en fonction des horaires de
travail et des tâches déjà affectées.
Post condition : Redirection vers l’interface détail de projet.
Enchaînement alternatif : Si le développeur n’est pas disponible, une alerte sera
afficher qui propose soit la liste des développeurs disponibles soit le changement de
date de ticket.
Tab. 2.4 : Documentation CU : Ajouter un Ticket
17

27. Chapitre 2. Analyses et spécification des besoins
2.2.5 Diagramme de séquence système
Les diagrammes de séquence, couramment utilisés par les développeurs, modélisent
les interactions entre les objets dans un seul cas d’utilisation. Ils illustrent comment les
différentes parties d’un système interagissent les unes avec les autres pour exécuter une
fonction, et l’ordre dans lequel les interactions se produisent lorsqu’un cas d’utilisation
particulier est exécuté.
Diagramme de séquence système consulter la liste des projets
La partie front envoie une requête HTTP GET pour demander la liste des projet le
système de la partie back ou api informe la coté front que l’utilisateur n’est pas autorisé à
accéder à cet API donc la partie Angular redirige l’utilisateur au formulaire de l’authen-
tification, après avoir être authentifié, une autre requête HTTP est envoyée. Le système
de la partie back valide les cordonnés et génère un JWT Token et le ré-envoie à la partie
front qu’elle l’enregistre en interne et ré-envoie la première demande de liste des projets
avec une entête qui contient le Token enregistré, la partie back vérifie le Token et envoie
un Json dans le quelle les projets sont listés.
Fig. 2.4 : diagramme de séquence système consulter la liste des projets
18

28. Chapitre 2. Analyses et spécification des besoins
2.3 Etude technique
2.3.1 Architecture physique
La figure 2.6 illustre l’architecture physique de notre solution qui est une L’architecture
N-tiers. C’est une architecture client-serveur dans laquelle notre application est exécutée
par plusieurs composants logiciels distincts.
Fig. 2.5 : Architecture physique
2.3.2 Coté client - Angular Framework
Le choix s’est porté sur Angular. Angular est un Framework pour la création d’ap-
plications clientes en HTML et JavaScript ou un langage comme Type Script qui sera
compilé en JavaScript.
Le Framework se compose de plusieurs bibliothèques, certaines principales et d’autres
facultatives.
Le Framework Angular est basé sur quatre concepts de base et ils sont les suivants :
• Les composants.
• Les Templates avec les métadonnées : Property Binding et l’Event Binding
• Les modules
• Les services et l’injection des dépendances.
La figure 2.6 montre l’architecture de Framework Angular.
19

29. Chapitre 2. Analyses et spécification des besoins
Fig. 2.6 : Architecture de Framework Angular [4]
Comme montré dans la figure 2.8 le Framework Angular supporte l’architecture Model-
View- ViewModel (MVVM), c’est un modèle de conception structurelle qui sépare les
objets en trois groupes distincts :
• Les modèles (M)
Ils contiennent des données d’application. Ce sont généralement des classes simples.
• Les vues (V)
Elles affichent des éléments visuels et des commandes à l’écran. Ce sont généralement
des sous-classes de UIView.
• Les modèles de vue (VM)
Ils transforment les informations du modèle en valeurs qui peuvent être affichées sur
une vue. Ce sont généralement des classes qui peuvent donc être transmises comme
références.
20

30. Chapitre 2. Analyses et spécification des besoins
Fig. 2.7 : Architecture MVVM [5]
2.3.3 Coté Serveur – Spring Boot
Spring est un Framework pour le développement d’applications d’entreprises. Il offre
plusieurs fonctionnalités ce qui laisse le choix au développeur d’utiliser la solution qui
répond aux besoins.
Spring Boot fait partie des projets Spring qui apportent des fonctionnalités de haut
niveau pour les développeurs. Il utilise touts les modules de spring comme Spring MVC,
Spring Data etc...
Il y a 4 couches principales dans Spring Boot, illustrées dans la figure 2.9:
• La couche de présentation
La couche de présentation gère les requêtes HTTP, traduit le paramètre JSON en
objet et authentifie la demande et le transfère à la couche métier.
• La couche métier
La couche métier gère toute la logique métier. Elle est constituée par des classes
et des services et utilise les services fournis par la couche d’accès aux données. Elle
effectue également l’autorisation et la validation.
• La couche de persistance
La couche de persistance contient toute la logique de stockage et convertit les objets
métier depuis et vers les lignes de la base de données.
• La couche de base de données
Dans la couche base de données, les opérations de gestion (création, récupération,
mise à jour et supprimer) sont effectuées.
21

31. Chapitre 2. Analyses et spécification des besoins
Fig. 2.8 : Les couches de Spring Boot [6]
2.3.4 La Sécurité - Spring Security
Notre application permet de visualiser des informations critiques qui s’intéressent à
l’activité principale de la société. Il est donc essentiel de les protéger contre les intrusions
et l’accès non autorisé. Dans cette optique, disposer d’un système de sécurité est devenu
un composant essentiel de l’infrastructure de l’entreprise afin de réduire les vulnérabilités
contre les menaces accidentelles ou intentionnelles.
Les exigences fondamentales en matière de sécurité informatique doivent être identi-
fiées. Elles caractérisent ce que les utilisateurs de systèmes informatiques attendent du
point de vue de la sécurité.
Pour notre projet, nous identifions les exigences suivantes :
• Authentification
Il s’agit de valider la légitimité de l’accès de l’utilisateur
• Autorisation
C’est un processus permettant de décider si un utilisateur déjà authentifié est au-
torisé à effectuer une action dans votre application.
• Confidentialité
Elle exige que les informations sur le système ne puissent être lues que par personnes
autorisées.
• Intégrité
Elle demande que les informations sur le système ne puissent être modifiées que par
personnes autorisées.
Spring Security fournit une solution de sécurité complète pour les entreprises logiciel
basé sur des applications JavaEE.
22

32. Chapitre 2. Analyses et spécification des besoins
1. Un processus d’authentification est lancé au début par ”Authentication Filter” qui
intercepte toute requête provenant du client. Les demandes sont transmises à l’objet
”Gestionnaire” qui effectue les opérations de vérification. Pour terminer, un jeton
d’authentification sera généré par l’objet ”Provider”.
2. Un processus de chiffrement/déchiffrement sera effectué au niveau ”Manager”. Le
mot de passe d’origine est remplacé par une valeur de hachage dérivée du texte en
clair à l’aide d’un nouveau mécanisme de hachage appelé BCryptPasswordEncoder.
3. L’access Authorization Manager vérifie l’autorité de l’utilisateur et accède à l’auto-
risation informations et lève une exception de refus d’accès lorsque le rôle n’est pas
attribué.
La figure 2.10 liste les différents composants qui composent le Spring Security écosys-
tème.
Fig. 2.9 : Ecosystéme Spring Security [7]
2.4 Conclusion
Dans ce chapitre, nous avons décrit les besoins fonctionnels et non fonctionnels de la
solution proposée à travers des diagrammes UML, ainsi que son architecture physique. Le
prochain chapitre sera dédié à l’étude de la partie conception de notre projet.
23

33. Chapitre 3
Conception
3.1 Introduction
Dans ce chapitre, nous allons faire la modélisation de notre application en se basant
sur les diagrammes UML dynamiques. C’est une phase primordiale dans le processus de
développement pour implémenter les besoins fonctionnels en faisant une description de
système.
3.2 Diagramme des paquetages
Le diagramme de paquetage est utilisé pour montrer comment les paquetages sont
organisés ainsi que leurs éléments.
La figure 3.1 illustre les différents paquetages de partie back et front ainsi que la
connexion entre eux.
24

34. Chapitre 3. Conception
Fig. 3.1 : Diagramme de paquetage
3.3 Diagramme de classe global
Le diagramme de classes d’analyse est généralement considéré comme le diagramme le
plus utilisé dans le développement orienté objet et dans les spécifications UML. Il décrit
les classes, les attributs, les opérations et leurs relations, que le système utilise.
Le diagramme de classe mentionné dans la figure 2.5 montre l’implémentations de
différentes classes dans le système ainsi que les relations et les cardinalités entre eux.
25

35. Chapitre 3. Conception
Fig. 3.2 : Diagramme de classe global
3.4 Diagrammes de séquence objet
Un diagramme de séquence représente simplement l’interaction entre les objets dans un
ordre séquentiel, c’est-à-dire l’ordre dans lequel ces interactions ont lieu. Les diagrammes
de séquence décrivent comment et dans quel ordre les objets d’un système fonctionnent.
3.4.1 Diagramme du séquence objet pour le cas d’utilisation mo-
difier photo de profil
26

36. Chapitre 3. Conception
Fig. 3.3 : Diagramme du séquence objet modifier photo de profil
La figure 3.2 expose le processus de modification de la photo de profil. Quand le
collaborateur importe une nouvelle photo, une requête HTTP sera envoyée par la partie
front vers la partie back pour enregistrer la nouvelle photo, le système vérifie alors le type
du fichier et sa taille s’il est n’est pas une image alors un logo d’échéance de l’opération
sera affiché au collaborateur sinon le système ajoute un nouveau dépôt d’image pour le
collaborateur si ce dernier ne dispose pas d’un, Puis l’image sera redimensionnée et le lien
27

37. Chapitre 3. Conception
vers la photo sera enregistrée dans la base de données. Enfin le collaborateur, reçoit un
message de succès de l’opération.
3.4.2 Diagramme du séquence objet pour le cas d’utilisation
ajouter projet
La figure 3.3 explique comment l’administrateur peut ajouter un projet. En fait, le
processus se fait sur 2 partie une partie coté client et une partie cote serveur. L’adminis-
trateur déjà authentifié demande la page d’ajout du projet, puis il remplit un formulaire
dans lequel il mentionne les informations à propos le nouveau projet et il clique sur le
bouton d’ajout si tous vas bien une requête HTTP et une entête d’authentification vont
être envoyés au côté serveur pour compléter le processus d’ajout si tout vas bien un mes-
sage de succès vas être affiché à l’administrateur et un message d’ajout du projet sera
envoyé au canal Slack de l’équipe sinon une alerte sera affichée.
28

38. Chapitre 3. Conception
Fig. 3.4 : Diagramme du séquence objet ajouter un projet
29

39. Chapitre 3. Conception
3.4.3 Diagramme du séquence objet pour le cas d’utilisation de-
mander un congé
Fig. 3.5 : Diagramme du séquence objet demander un congé
30

40. Chapitre 3. Conception
Dans la figure 3.4, nous avons détaillé le processus de demande de congés. Il se dé-
roule sur 2 partie une partie coté client et une partie coté serveur. Le collaborateur déjà
authentifié demande la page de la demande du congé. Après avoir rempli le formulaire
dédié au demande de congé, il clique sur le bouton de confirmation si le formulaire est
bien vérifié une requete HTTP et une entet d’authentification vont être envoyés au coté
serveur pour compléter le processus, le système va vérifier le solde de congé du collabo-
rateur connecté , si ce dernier a un solde suffisant le système va confirmer sa demande
immédiatement sinon il va vérifier l’agenda du collaborateur durant les jours du congé
demandés, et envoyer un email au responsable RH avec la demande et les tâches affectées
au collaborateurs durant les jours de congé. A la fin, un message de succés de l’opération
va être affiché au collaborateur.
3.5 Diagramme d’activités
Les diagrammes d’activité fournissent une vue dynamique d’un domaine et son tech-
nique pour décrire la logique procédurale, du processus métier et le flux de travail avec un
élément clé et qu’ils prennent en charge le comportement parallèle. Il peut être appliqué
à n’importe quelle perspective ou objectif, mais il est populaire pour visualiser les flux de
travail et les processus métier, et les cas d’utilisation.
3.5.1 Diagramme d’activité activer compte
L’administrateur ajoute un nouveau collaborateur, dans l’interface d’ajout des utilisa-
teurs, le collaborateur reçoit un email de notification d’ajout d’un nouveau compte dans
lequel il va avoir un mot de passe généré automatiquement par le système et un bouton
de confirmation du compte, lorsqu’il clique sur ce dernier bouton le compte est hormis
activé et il sera dirigé vers l’interface de connexion de l’application. Ceci est bien expliqué
dans la figure 3.5.
31

41. Chapitre 3. Conception
Fig. 3.6 : Diagramme d’activité d’activer un compte
3.5.2 Diagramme d’activité récupérer un mot de passe
La figure 3.6 donne une vision sur la régénération de mot de passe suit à une demande
du collaborateur, un email est lui envoyer avec un code généré par le système. Le colla-
borateur saisie ce code-là s’il est correct donc il vas être dirigé vers l’interface de saisie
de nouveau mot de passe, il saisit le nouveau mot de passe et la ressaisie si tous les deux
sont identiques alors la modification du mot de mot est faite avec succè.
32

42. Chapitre 3. Conception
Fig. 3.7 : Diagramme d’activité de récupérer un mot de passe
3.5.3 Diagramme d’activité passer un quiz
Le collaborateur demande de passer un quiz d’évaluation. Il choisit entre le passage
d’un quiz de compétences ou d’un quiz d’évaluation de l’environnement de travail.
Si le collaborateur choisit le quiz des compétences, alors il doit choisir la compétence
à évaluer ainsi que le niveau de difficulté. Après avoir terminer l’évaluation, le score et la
correction seront envoyés au collaborateur et un email sera envoyé à l’administrateur.
Sinon s’il a fait le quiz de l’évaluation de l’environnement un email sera envoyé seule-
ment à l’administrateur.
Nous avons détaillé ce processus dans la figure 3.7 ci-dessous.
33

43. Chapitre 3. Conception
Fig. 3.8 : Diagramme d’activité passer un quiz
3.6 Conclusion
Dans ce chapitre, nous avons présenté la conception de notre application, tout en
décrivant le diagramme de paquetage, de diagrammes séquence objet et les diagrammes
d’activité. Le chapitre suivant va être dédier à la phase de la réalisation et des tests de
notre travail.
34

44. Chapitre 4
Réalisation et Tests
4.1 Introduction
Ce chapitre représente la dernière partie du rapport. Son objectif est de présenter le
projet réalisé au sein de l’entreprise. Dans un premier lieu, nous allons présenter l’envi-
ronnement matériel et logiciel utilisé pour la réalisation de projet. Dans un deuxième lieu,
nous allons présenter les interfaces de l’application ainsi que les tests effectués.
4.2 Environnement de développement
4.2.1 Environnement matériel
Du point de vue matérielle, Le projet a été développer avec une poste de travail avec
les caractéristiques mentionnées dans la figure 4.1 ci-dessous.
Fig. 4.1 : Caractéristiques du PC
35

45. Chapitre 4. Réalisation et Tests
4.2.2 Environnement Logiciel
Partie Back-End
Spring Tool Suite (STS)
Basé sur Eclipse, STS est un environnement de développement dédié pour les appli-
cations Spring. Il offre un environnement prêt à l’utilisation pour tout le cycle de vie de
l’application spring (l’implémentation, le débogage, l’exécution et le déploiement).
Fig. 4.2 : Spring Tool Suite logo [8]
MySQL Workbench
MySQL Workbench est un logiciel de gestion de base de données MySQL. A travers
son interface graphique simple à utiliser, il assure plusieurs fonctionnalités tel que le déve-
loppement SQL, la modélisation des données, l’administration des comptes d’utilisateurs.
[9]
Fig. 4.3 : MySQL Workbench logo [9]
Partie Front-End
NPM
Node Package Manager (NPM) est un gestionnaire de paquets pour les applications
programmés en utilisant JavaScript pour Node.js. Il est utilisé principalement pour ins-
taller des bibliothèques déjà disponibles sur Internet. [10]
Fig. 4.4 : NPM logo [11]
Angular 8
36

46. Chapitre 4. Réalisation et Tests
Angular est une plate-forme de développement permettant de créer des applications
d’une seule page. Ces nombreux outils comme Angular CLI aident à créer les composants
plus facilement.
Fig. 4.5 : Angular logo [12]
WebStorm
Web Storm est un éditeur de code source qui permet de mieux structurer notre projet
avec un support de TypeScript, JavaScript et Node.js.
Fig. 4.6 : Web Storm logo [13]
4.2.3 Autres
GitLab
GitLab est un outil gratuit qui assure l’hébergement du code et met en faveur la
collaboration dans le travail.
Fig. 4.7 : GitLab logo [14]
Docker
Docker est une plateforme de conteneurisation. Il permet aux développeurs de condi-
tionner les applications dans des conteneurs.
37

47. Chapitre 4. Réalisation et Tests
Les conteneurs des composants exécutables standardisés combinant le code source de
l’application avec les bibliothèques du système d’exploitation (OS) et les dépendances
requises pour exécuter ce code dans n’importe quel environnement.
Fig. 4.8 : Docker logo [15]
Tableau Software
Tableau Software est un logiciel de visualisation des données, largement utilisé dans
l’informatique décisionnelle qui transforme une énorme quantité de données en représen-
tations visuelles interactives, telles que des graphiques et des tableaux.
Fig. 4.9 : Tableau software logo [16]
Postman
Postman est un outil qui permet de développer des API (Application Programming
Interface) qui permet de créer, tester et modifier des API.
Fig. 4.10 : Postman logo [17]
4.3 Interfaces graphiques d’application
4.3.1 Interface graphique de confirmation de compte
Un email est envoyé à l’utilisateur suite à l’inscription dans lequel il trouve un mot de
passe généré automatique et un bouton de confirmation de compte.
38

48. Chapitre 4. Réalisation et Tests
Fig. 4.11 : Interface de la confirmation de compte
4.3.2 Interface graphique d’authentification
L’utilisateur doit saisir son email et mot de passe sinon il se connecte avec son compte
google pour s’authentifier.
(a) interface
d’authentification
pour mobile
(b) interface d’authentification pour Desktop
Fig. 4.12 : Interface d’authentification
4.3.3 Interface graphique de liste des utilisateurs
Cette interface permet l’administrateur de bien gérer ses utilisateurs.
39

49. Chapitre 4. Réalisation et Tests
(a) interface
mobile
(b) interface Desktop
Fig. 4.13 : Interface de la liste des utilisateurs
4.3.4 Interface graphique de gestion de profil
Grâce à l’interface de gestion de profil, l’utilisateur peut changer son image de pro-
fil, modifier ses informations et son mot de passe. Elle permet de lister aussi les tâches
quotidiennes de chaque utilisateur.
(a) interface
mobile
(b) interface Desktop
Fig. 4.14 : Interface de gestion de profil
4.3.5 Interface graphique d’ajout d’un projet
A travers cette interface, l’administrateur peut ajouter un nouveau projet pour son
entreprise via un formulaire dans lequel il précise les informations nécessaire de projet(date
début, date fin, technologies ...)
40

50. Chapitre 4. Réalisation et Tests
(a) interface
mobile
(b) interface Desktop
Fig. 4.15 : Interface d’ajout d’un projet
4.3.6 Interface graphique de la liste des projets
La figure 4.16 présente l’interface de liste des projets, elle assure aussi le filtrage des
projets par statuts, l’avancement des projets ainsi que leurs états (critique ou pas).
(a) interface
mobile
(b) interface Desktop
Fig. 4.16 : Interface de la liste des projets
4.3.7 Interface graphique de détails de projet et ses tickets
41

51. Chapitre 4. Réalisation et Tests
(a) interface
mobile 1
(b) interface
mobile 2
(c) interface Desktop
Fig. 4.17 : Interface de détails projets
L’interface ci-dessus détaille les projet ainsi que leurs ticket, en cliquant sur le bouton
details une carte qui affiche les détails de ticket sélectionnées sera affiché.
4.3.8 Interface graphique de Kanban bord
Le kanban bord offre au développeur la visibilité de leurs taches par projet ainsi que
les états de ces taches-là, il permet aussi au développeur de marquer l’avancement des
tickets par un simple ”drag and drop”.
42

52. Chapitre 4. Réalisation et Tests
(a) interface
mobile
(b) interface Desktop
Fig. 4.18 : Interface de kanban bord
4.3.9 Interface graphique d’affichage de calendrier
La calendrier permet à tous les collaborateurs de l’application de visualisé leurs plan-
ning sous plusieurs format (par mois, jours, list..). Pour l’administrateur, elle lui offre une
simplicité de changement de plannings en glissants les différents taches tout en respectant
les deadlines des projets.
43

53. Chapitre 4. Réalisation et Tests
(a) interface mobile 1 (b) interface mobile 2
(c) interface Desktop
Fig. 4.19 : Interface d’affichage de calendrier
4.3.10 Interface graphique d’ajout d’une question au quiz
La figure 4.20 représente l’interface qui assure l’ajout des question au quiz , le RH
ajoute le thème et la difficulté puis il ajoute les questions et les réponse ainsi que la
réponse correcte pour construire le quiz.
44

54. Chapitre 4. Réalisation et Tests
(a) interface
mobile
(b) interface Desktop
Fig. 4.20 : Interface d’ajout d’une question au quiz
4.3.11 Interface graphique de la liste de quiz à passer
C’est l’interface qui permet au développeurs de choisir le quiz à passer.
(a) interface
mobile
(b) interface Desktop
Fig. 4.21 : Interface de la liste des quiz à passer
4.3.12 Interface graphique de résultat de quiz
C’est l’interface qui sera affiché au développeur après avoir terminé le quiz dans, le
pop-up contient le temps passé sur le quiz ainsi que le score final de développeur.
45

55. Chapitre 4. Réalisation et Tests
(a) interface
mobile
(b) interface Desktop
Fig. 4.22 : Interface de liste de résultat de quiz
4.3.13 Interface graphique de Dashboard
La figure 4.21 représente le Dashboard de l’application dans lequel l’administrateur
peut voir les KPI de son entreprise (l’état des projets, taux d’absentéisme, évaluation des
taches, les meilleurs performants ...)
(a) interface
mobile
(b) interface Desktop
Fig. 4.23 : Interface de Dashboard
4.4 Tests
L’activité de Test fait partie du cycle de développement logiciel. Ils visent à qualifier
et assurer la qualité des logiciels et/ou à réduire les risques liés aux problèmes produits
dans l’environnement opérationnel.
46

56. Chapitre 4. Réalisation et Tests
4.4.1 Test unitaire
Les tests unitaires évaluent le bon fonctionnement d’une méthode bien terminé et
assurent le bon fonctionnement d’une partie bien précise d’une application et sa réponse
aux besoins même après d’éventuelles modifications.
JUnit
JUnit est un Framework utilisé pour le développement des tests unitaires pour les
environnements JAVA qui se base sur les assertions qui testent les résultats attendus.
Ci-dessous, le figure montre le bon fonctionnement des filtres sur les projets en vérifiant
le résultat obtenu par l’exécution du test en utilisant JUnit. Le test avec JUNIt est achevé
avec succès et tous les cas de test ont été terminée sans déclanchement d’erreurs ou de
Failure.
Fig. 4.24 : Test de filtre sur les projet en utilisant JUnit
4.4.2 Test API
Le Test API via Postman permet de tester le fonctionnement d’API aussi bien en
interne qu’avec des API tierces. [18] Pour le cas du test suivant, nous allons tester la
sécurité dans notre application en appelant un web service sans et avec le passage de Jwt
Token dans l’entête.
Dans le premier cas, le système refuse d’afficher le résultat demandé avec une erreur
403 (figure 4.26 ). Dans le deuxième cas, en ajoutant le header dans la demande la requête
est traitée parfaitement (figure 4.27 ).
47

57. Chapitre 4. Réalisation et Tests
Fig. 4.25 : Authentification
Fig. 4.26 : Accès refusé à l’API
48

58. Chapitre 4. Réalisation et Tests
Fig. 4.27 : Accès accepté à l’API
4.4.3 Tests d’acceptations
Les tests d’acceptation sont des tests effectués par l’utilisateur finale de l’application.
Ils effectués avant la mise en production, dans le but de vérifier et accepter le fonctionne-
ment du système logiciel.
Ajout de ticket
Pour ajouter un ticket, l’administrateur doit remplir un formulaire, Si un champ requis
n’est pas renseigné alors le bouton d’ajout sera désactivé et l’administrateur doit vérifier
les champs manquants avant qu’elle soit réactiver de nouveau.
49

59. Chapitre 4. Réalisation et Tests
Fig. 4.28 : formulaire d’ajout de ticket
Réception des emails quotidien
A la fin de la journée de travail, un email d’avancement est envoyé du développeur
à l’équipe (figure 4.29) pour mentionner les taches qu’il a fait durant ce jour-là et un
rapport quotidien est envoyé à l’administrateur qui résume les tâches effectuées par toute
l’équipe (figure 4.30).
Fig. 4.29 : email d’avancement du développeur
50

60. Chapitre 4. Réalisation et Tests
Fig. 4.30 : rapport quotidien
Gestion de conflits de calendrier
Dans la figure 4.31, l’utilisateur ajoute un nouveau ticket, avec une estimation de 2h
et il l’affecte à un développeur ayant un planning saturé durant ces jours-là.
Fig. 4.31 : Interface d’ajout de ticket avec conflit
D’après la figure 4.32, Le système propose à l’utilisateur deux solution pour résoudre
les conflits de planning.
51

61. Chapitre 4. Réalisation et Tests
Fig. 4.32 : Interface de choix de solution
Si l’administrateur choisit l’option de réaffectation des tâches alors le système lui
propose un autre développeur disponible comme montré dans la figure 4.33. Sinon, si
l’administrateur choisit l’option de reprogrammer la tâche alors le système le redirige vers
le calendier où il peut glisser la tâche vers un autre jour vide comme montré dans la figure
4.33.
(a) interface réaffectation ticket (b) interface reprogrammation ticket
Fig. 4.33 : Interface de résolution de conflit
Lorsque le ticket est ajoutée avec succès un message sera envoyé dans la canal Slack
de l’équipe afin de notifier les membres de l’équipe comme montré dans la figure 4.34.
52

62. Chapitre 4. Réalisation et Tests
Fig. 4.34 : Interface de notification sur Slack
4.5 Conclusion
Dans ce chapitre, nous avons exposé la partie réalisation de notre projet. Nous avons
commencé par la présentation de l’environnement matériel et logiciel de travail. Après,
nous avons passé à la description de quelque interface graphique de l’application. Enfin,
nous avons terminé par les tests du travail réalisé.
53

63. Conclusion et perspectives
Ce rapport s’agit d’une présentation détaillée du travail réalisé en tant que stagiaire
PFE chez DREAM TEK CONSUTING afin d’obtenir le diplôme national d’ingénieur en
informatique de l’école Supérieur Privée d’ingénierie et de technologie ESPRIT.
Mon projet de fin d’étude consiste à concevoir et implémenter un système de dashboar-
ding et d’automatisation de la gestion des ressources humaines et de production. C’est un
ERP , ergonomique, performant, sécurisé et moins coûteux que les solutions disponibles
sur le marché, dédié aux petites et moyennes entreprise pour améliorer leurs organisa-
tion , qui regroupe plusieurs modules tels que : le module de dashboarding, le module
TimeSheet, le module évaluation et rémunération...
Pour conclure, ce stage m’a donné l’opportunité d’approfondir mes connaissances dans
le domaine de conception et de développement, de bien étudier les besoins clients afin de
réaliser des outils métiers qui répondent adéquatement aux exigences. Il m’a offert de
même l’opportunité de bien exploiter mes compétences que j’ai développées durant ma
formation d’ingénieur.
Quant aux perspectives, la prochaine étape serait de prévoir en avance l’estimation des
durées de réalisation de projets et de préparer le planning en se basant sur des données
similaires stockées sans revenir aux managers et aux ressources humaines vu que nous
aurions un flux massif de données que nous pourrions étudier à notre faveur.
A la fin, je souhaite renouveler ma sincère gratitude à toute personne qui a rendu la
réalisation de ce projet possible. De même, je tiens à exprimer ma joie d’avoir travaillé
dans une entreprise accueillante qui m’a offert des conditions de travail favorables et un
environnement motivant et je souhaite que ce travail serait à la hauteur des attentes des
membres de jury et l’équipe de DREAM TEK CONSULTING.
54

64. Bibliographie
[1] ALEXANDRE LEPRIEULT. Les Nouvelles Méthodologies de gestion de projet.
en-FR.
[2] FreeInformationSystemsForManagementApplication. UnifiedProcess. en-
FR.
[3] Audibert. UML 2 De l’apprentissage à la pratique. en-FR.
[4] Jignesh Trivedi. Basic Architecture Of Angular 2 Applications. en-EN.
[5] WayToLearnX. Différence entre MVC et MVVM. en-FR.
[6] javapoint. Spring Boot Architecture. en-EN.
[7] TERASOLUNA. TERASOLUNA Global Framework Development Guideline. en-
EN.
[8] Spring-Tool-Suite-Project-Logo. en-EN.
[9] MySQL. Product workbench. en-FR.
[10] DevStory. Qu’est-ce que NPM ? en-FR.
[11] Matt Eaton. Getting Started with NPM. en-FR.
[12] Angular. Official Angular Logo. en-EN.
[13] webstorm. WebStorm. en-EN.
[14] GitLab. GITLab Logos. en-EN.
[15] Docker. Docker Logos. en-EN.
[16] Tableau Software. LinkedIN. en-FR.
[17] Jenna Sargent. Postman opens up features from its paid plan. en-FR.
[18] Raed Ben Brahim. Test API : Comment tester son API avec les tests Postman.
en-FR.
55