École Supérieure Privée des Sciences Appliquées et de

Management
Université SESAME

Rapport du projet personnel encadré

Réalisation de système d’information GFI

(RH)
Réalisé par

KETATA Marwen
SGHIR Amine
MERSNI Wael
TAAMALLAH Houssem

Année Universitaire 2019 - 2020

 Remerciement
Au terme de ce travail, nous adressons nos vifs remerciements à Monsieur Houssem JMAL,
notre encadrant, pour son suivi, sa disponibilité, son aide précieuse et ses conseils qui nous ont
été d’une utilité indéniable.
Nous exprimons également toutes nos gratitudes à tous nos enseignants de SESAME pour la
formation qu’ils nous ont donnés.
Nous tenons à remercier Madame Amal BOUAZIZ qui a accepté d’évaluer ce travail.
Enfin, nous remercions ceux et celles qui ont participé de près ou de loin à l’élaboration du
présent travail et principalement pour leur service et pour leur soutien moral tout au long de la
préparation de cette projet.

1
Remerciement .......................................................................................................................................... 1
Introduction Générale .............................................................................................................................. 5
Chapitre 1 ................................................................................................................................................ 6
Cadre général de projet ............................................................................................................................ 6
1. Introduction.................................................................................................................................. 7
2. Présentation de projet ................................................................................................................... 7
2.1. Présentation .......................................................................................................................... 7
2.2. Valeurs ................................................................................................................................. 8
2.3. Qualité.................................................................................................................................. 8
2.4. Service ................................................................................................................................. 9
3. Analyse du contexte ..................................................................................................................... 9
4. Problématique ............................................................................................................................ 10
5. Solution proposée ....................................................................................................................... 10
6. Méthodologie adoptée ................................................................................................................ 11
6.1. Comparaison entre l’approche Agile et l’approche classique .................................................... 11
6.2. Présentation de SCRUM ..................................................................................................... 12
6.3. Les rôles SCRUM............................................................................................................... 13
7. Conclusion ................................................................................................................................. 13
Chapitre 2 .............................................................................................................................................. 14
Planification : Sprint 0 ........................................................................................................................... 14
2.1. Introduction ............................................................................................................................ 15
2.2. Backlog du produit ............................................................................................................. 15
2.3. Identification des besoins .................................................................................................... 18
2.3.1. Identification des acteurs et de fonctionnalités ............................................................. 18
2.3.2. Les besoins fonctionnels ............................................................................................. 19
2.3.3. Les besoins non fonctionnels ....................................................................................... 19
2.4. Diagramme de cas d’utilisation global................................................................................. 19
2.5. Diagramme des classes global ............................................................................................. 20
2.6. Planification des sprints ...................................................................................................... 21
2.6.1. DevOps ....................................................................................................................... 22
2.7. Environnement de travail .................................................................................................... 24
2.7.1. Environnement matériel .............................................................................................. 24

2
 2.7.2. Environnement de développement ............................................................................... 24
2.7.3. Environnement logiciel ............................................................................................... 25
2.8. Architecture générale de l’application ................................................................................. 27
3. Conclusion ................................................................................................................................. 28
Chapitre 3 .............................................................................................................................................. 29
Mise en œuvre du projet ......................................................................................................................... 29
1. Introduction................................................................................................................................ 30
2. Mise en œuvre du Release 1 ....................................................................................................... 30
2.1. Sprint 1............................................................................................................................... 30
2.1.1. Backlog du Sprint ....................................................................................................... 30
2.1.2. Diagramme de cas d’utilisation ................................................................................... 32
2.1.3. Conception.................................................................................................................. 33
2.1.3.1. Diagramme de classe ............................................................................................... 33
2.1.4. Réalisation .................................................................................................................. 34
3. Mise en œuvre du Release 2 ....................................................................................................... 36
3.1. Sprint 2............................................................................................................................... 37
3.1.1. Backlog du Sprint ....................................................................................................... 37
3.1.2. Diagramme de cas d’utilisation ................................................................................... 38
3.1.3. Conception.................................................................................................................. 38
3.1.3.1. Diagramme d’activité .............................................................................................. 38
3.1.3.2. Diagramme des classes de sprint 2 ........................................................................... 39
3.1.4. Réalisation .................................................................................................................. 40
4. Conclusion ................................................................................................................................. 42
Conclusion générale ............................................................................................................................... 43
Références ............................................................................................................................................. 44
Netographie ........................................................................................................................................... 45

3
Liste des figures
Figure 1 : Logo GFI ................................................................................................................................. 7
Figure 2: Interface MYCYN .................................................................................................................. 10
Figure 3: Méthodologie agile vs. Classique ............................................................................................ 11
Figure 4: Méthode Scrum....................................................................................................................... 12
Figure 5 : Rôles dans SCRUM ............................................................................................................... 13
Figure 6 : Diagramme de cas d'utilisation global .................................................................................... 20
Figure 7: Diagramme de Classe Global .................................................................................................. 21
Figure 8: Planification des sprints .......................................................................................................... 22
Figure 9 : Planification du Sprint 1 avec DevOps ................................................................................... 23
Figure 10 : Planification du Sprint 2 avec DevOps ................................................................................. 24
Figure 11 : Data Base First Approche ..................................................................................................... 27
Figure 12: Architecture de l’application ................................................................................................. 28
Figure 13: Diagramme de cas d'utilisation du sprint 1 ............................................................................. 33
Figure 14 : Diagramme de classe du sprint 1 .......................................................................................... 34
Figure 15 : Interface de consultation ...................................................................................................... 35
Figure 16 : Interface d’ajout ................................................................................................................... 35
Figure 17 : Interface de modification...................................................................................................... 36
Figure 18 : Interface de suppression ....................................................................................................... 36
Figure 19 : Diagramme de cas d'utilisation de sprint 2 ............................................................................ 38
Figure 20: Diagramme d'activité de gérer demande congé ...................................................................... 39
Figure 21: Diagramme de classe du sprint 2 ........................................................................................... 40
Figure 22 : Interface de tableau de bord.................................................................................................. 41
Figure 23 : Interface de validation congé ................................................................................................ 41

Liste des Tableaux

Table 1: Backlog du produit ................................................................................................................... 15
Table 2 : Les différents acteurs interagissant avec notre système ............................................................ 18
Table 3: Backlog du Sprint 1 .................................................................................................................. 30
Table 4: Backlog du Sprint 2 .................................................................................................................. 37

4
 Introduction Générale

Actuellement, le monde connaît une avance technologique considérable dans tous les secteurs et
cela à l’aide de l’informatique, qui joue un rôle important dans le développement de nombreuses
entreprises et organisations.
Avant, nous enregistrons toutes les informations manuellement sur des supports en papier. Ce qui
engendrait beaucoup de problèmes tel que la perte de temps considérable dans la recherche de ces
informations ou la dégradation de ces dernières [1].
Notre projet de spécialité consiste à la création d’un application web de Gestion des ressources
humaines pour la société GFI. L’apport le plus important de notre projet sera à la fois pour tous
les employés de la société qui peut gérer les données facilement. Ainsi, qu’à l’administrateur qui
peut gérer aussi bien tous les fonctionnalités du systéme.
Le présent rapport est structuré en trois chapitres comme suit :

• Le premier chapitre intitulé Cadre général du projet sera consacré à la présentation du

projet, avec une étude des problématiques avec les solutions proposées, ensuite nous
présenterons une comparaison entre quelques méthodologies.

• Le deuxième chapitre, intitulé Planification « Sprint 0 », nous nous intéressons à définir le

backlog produit, et à présenter une vue architecturale et conceptuelle globale de notre
application. C’est également à ce niveau que nous présenterons les outils et technologies
utilisés pour le développement.

• Le dernier chapitre, intitulé Mise en œuvre du projet se concentrera sur l’étude et la

réalisation des sprints de notre projet. Dans chaque sprint, nous commencerons, par le «
Backlog du Sprint » qui décrit les tâches à faire et ensuite nous présenterons le diagramme
de classe, les des cas d’utilisation et le diagramme d’activité. Enfin, nous illustrerons
l’exécution de notre application par des captures écrans
Finalement, nous clôturerons ce rapport par une conclusion générale.

5
 Chapitre 1

Cadre général de projet

6
1. Introduction

Dans ce chapitre, nous allons tout d’abord mettre le projet dans son cadre, nous présenterons
l’établissement dans lequel nous avons réalisé le projet. Ensuite, nous allons aussi exposer l’étude
sur les avantages et les inconvénients des applications similaires existantes.

2. Présentation de projet
2.1. Présentation

Cynapsys GFI, l’ESN (entreprise de service numérique) tunisienne fondée en 2004 et déjà
présente dans plusieurs pays à travers ses filiales en Europe et en Afrique, est un acteur
majeur dans le secteur de l’ingénierie de l’informatique avec plus de 150 collaborateurs, 7
millions d’euros de chiffre d’affaire et plus de 100 références dans 16 pays. Cynapsys
intervient principalement par de l’assistance technique IT, de la TMA, du développement
logiciel et mène des activités de RDI. Le groupe GFI confirme son intérêt pour la Tunisie et
ses compétences techniques et humaines et juge que Cynapsys peut participer activement
dans la stratégie du développement à l’international du groupe du monde de l’IT en
développant plusieurs centres de services en Tunisie.

Figure 1 : Logo GFI

7
 2.2. Valeurs
Le Groupe Cynapsys GFI, ESN Entreprise de Service du Numérique, marque un point
d’honneur à mener l’intégralité de ses missions dans le strict respect de certaines valeurs qui
représentent les piliers de son activité :

• Performance
Lorsque la passion, l’investissement et la bonne qualification de chacun sont catalysés
et mis en

Valeur par une organisation et des moyens adaptés, la performance devient un résultat
naturel.

• Orientation client
Nous nous efforçons de saisir les besoins réels de nos clients et d’y répondre au
mieux, par des recommandations et des réalisations porteuses de progrès, élaborées
sans céder aux facilités de nos habitudes. ²

• Rigueur
Notre recherche de l’excellence et notre goût pour l’évolution nous poussent chaque
jour à améliorer la qualité de nos services informatiques avec le souci du détail et le
sens des responsabilités.

2.3. Qualité

La totale implication 120 collaborateurs basés aussi bien à Tunis, qu’à Paris ou
Frankfurt, donnent toute l’ampleur des directives prioritaires de la Politique Qualité de
Cynapsys qui visent l’amélioration continue de :

• La satisfaction de nos clients.

• La réactivité face aux besoins, exigences et attentes.
• La gestion des projets.
• Les compétences techniques de nos collaborateurs.
• La performance de notre entreprise.
• Le niveau de la qualité globale.
Cynapsys est engagée depuis 2011 dans la démarche de Responsabilité Sociétale de
l’Entreprise (RSE) qui lie :

• L’optimisation des coûts en rapport avec les impacts environnementaux.

• Les bonnes pratiques de la gestion des carrières et la gestion de la
connaissance.

8
L’adéquation entre les priorités financières et les bonnes pratiques de partenariat d’affaires

2.4. Service

Coté service GFI offre six service :

• Ingénierie informatique.
• TMA : La Tierce Maintenance Applicative est la maintenance appliquée à un
logiciel et assurée par un prestataire externe dans le domaine des technologies
de l’information et de la communication.
• Assistance technique.
• Test et validation.
• Formation
• RDI : Recherche, Développement et Innovation.

3. Analyse du contexte

MyCyn est une application web qui décrit le système d’information de l’entreprise GFI, elle permet de
gérer les ressources humaines, matérielles et logicielles, de données et de réseaux de communication et
diffuse l’information au sein de l’entreprise. Dans ce contexte, un utilisateur quel que soit son rôle (admin
ou simple employé), peut se connecter à cette application avec un nom d’utilisateur et mot de passe afin de
gérer des ressources bien précise. Par exemple, pour un simple employé, il peut faire la gestion des taches,
réserver des ressources et formuler les ordres de missions et les demande de congés. Par contre, un admin
a beaucoup d’autre privilège, tel que le panneau de paramétrage pour les gestions des employés, des
clients, des pôles et des profils

9
 Figure 2: Interface MYCYN

4. Problématique

Depuis sa création en 2004, GFI ne fait que grandir. Elle gagne de plus en plus de projet et par
conséquent, elle recrute de plus en plus de personnel. Cet accroissement génère un volume de données très
important en constante évolution, devenant ingérable pour une gestion sans assistance informatique
performante.

Initialement, la société utilisait un système d’information basique développé avec JAVA JEE. Au fur et à
mesure des années et de l’augmentation de la quantité de données stockées dans sa base de données [1], ce
système d’information est devenu progressivement un facteur de ralentissement tant au niveau de
l’efficacité de son interface web que sa rapidité d’exécution.

5. Solution proposée

Afin de résoudre les problématiques précédentes notre application doit répondre au

condition suivante :

• Centraliser l’information et les données

• Migration vers des technologie plus performante
• Amélioré les vues des interfaces et des Dashboard

10
6. Méthodologie adoptée

Pour pouvoir choisir la bonne méthodologie, il faut avoir une idée sur les avantages et les
inconvénients de quelques-unes et savoir ainsi laquelle répond aux contraintes et aux exigences
de notre projet. Ci-dessous nous présentons un aperçu sur les différentes méthodologies.

6.1. Comparaison entre l’approche Agile et l’approche classique

Depuis toujours, les projets sont gérés avec des méthodologies classiques qui se caractérisent
par recueillir les besoins, définir le produit, le développer et le tester avant de le livrer. Ces
méthodologies sont appelées aussi –les approches prédicatives. En effet, comme son nom
l’indique, il s’agit ici de prévoir des phases séquentielles où il faut valider l’étape précédente pour
passer à la suivante. On doit alors s’engager sur un planning précis de réalisation du projet en
prévoyant des jalons de débuts et fins de phases ainsi que les tâches à effectuer.
De plus, elles sont axées principalement sur le périmètre du projet, son coût et sa planification.
Les méthodes Agiles quant à elles font des méthodes "classiques" une contrainte. Ainsi on voit le
coût, le périmètre et la planification comme des contraintes sur lesquelles on va se focaliser tout
en étudiant en parallèle la valeur ajoutée cliente et la qualité du produit livre. On ne choisit pas
directement de livrer un projet, on s’assure d’apporter la valeur cliente nécessaire avec un produit
de qualité en optimisant nos coûts, notre temps et surtout les risques liés au projet. Le client
obtient donc une place importante au sein d’une organisation Agile. Son avis est compté et
respecté. Les protagonistes (internes et externes) doivent accepter l’apprentissage et doivent être
préparés au changement) [3]. La figure 1 présente une Comparaison entre la méthode classique
et la méthode Agile.

Figure 3: Méthodologie agile vs. Classique

11
Brièvement, les méthodologies agiles sont basées sur 4 valeurs clé qui les différencient des
approches classiques [4] :

• L’interaction avec les personnes plutôt que les processus et les outils,
• Un produit opérationnel plutôt qu’une documentation pléthorique,
• La collaboration avec le client plutôt que la négociation de contrat,
• La réactivité face au changement plutôt que le suivi d’un plan.
Par conséquent, on a choisi d’adopter une méthodologie agile car elle définit un cadre moins
rigide que les méthodes traditionnelles et elle est plus pragmatique que ces derniers de sorte
qu’elle assure la satisfaction du client en facilitant la gestion du projet, améliorant la qualité de
développement et s’adaptant mieux aux imprévus du projet.

6.2. Présentation de SCRUM

Scrum [5] est une méthode agile qui vise à satisfaire au mieux les besoins du client tout en
maximisant les probabilités de réussite du projet. Elle suppose que le développement d’un
logiciel n’est pas prévisible et ne peut donc pas suivre de processus défini. Ainsi, le résultat du
projet n’est pas connu au départ, il dépend des réorientations que lui donne le client en cours de
route.
Comme le client classe lui-même les fonctionnalités par ordre d’importance, il est certain
d’obtenir un logiciel à forte valeur ajoutée en fin de projet. La figure 2 montre de quoi se
compose SCRUM.

Figure 4: Méthode Scrum

Le principe de base de Scrum est de se focaliser de façon régulière sur un ensemble de
fonctionnalités à réaliser appelées Sprints. Chaque Sprint possède des buts à atteindre à partir
desquels sont choisies les fonctionnalités à implémenter. Ces fonctionnalités sont définies sous
forme d’User Story. Un sprint aboutit toujours sur la livraison d’un produit partiellement
fonctionnel [5–].

Justification du choix :
Le choix de la méthodologie Scrum fournit plusieurs avantages pour les clients :

12
 • La méthodologie scrum fournit au client de tester l’application des que le développeur
finit la premier partie de chaque sprint. Ainsi garantie le travail concret avec le client.
Nous minimisons les problèmes de compréhension de la conception. En plus le client peut
ajouter ou modifier des fonctionnalités au début ou à la fin de chaque sprint,
• Scrum assure une qualité de produit grâce à la transparence du processus nous pouvons
visualiser des lacunes d’un livrable et l’amélioration se fera dès le prochain livrable.

6.3. Les rôles SCRUM

SCRUM définit trois rôles principaux :

• Le « Product Owner » qui porte la vision du produit à réaliser (représentant

généralement le client) ;
• Le « Scrum Master » garant de l’application de la méthodologie Scrum ;
• Le « Scrum Team » L’équipe de développement qui réalise le produit.
La figure 3présente les rôles dans SCRUM.

Figure 5 : Rôles dans SCRUM

7. Conclusion

Tout au long de ce chapitre, nous avons présenté une brève description du projet à réaliser, en
déterminant la problématique et en proposant la solution envisagée pour faire face à la situation
actuelle. Par la suite nous avons présenté une étude de quelques méthodologies de
développements existants pour effectuer le choix de la méthodologie qui sera adoptée pour le
développement de notre système.
Le chapitre suivant sera consacré à l’étude des besoins fonctionnels et non fonctionnels, la
spécification du Backlog de produit et la préparation du planning de travail.

13
 Chapitre 2

Planification : Sprint 0

14
2.1. Introduction

Dans ce chapitre, nous allons tout d’abord, présenter le backlog du produit qui regroupe toutes les
exigences à réaliser par notre système. Ensuite, nous allons passer à la phase d’analyse de la
solution et la détermination des besoins fonctionnels et non fonctionnels. Après, nous décrivons
la spécification du diagramme de cas d’utilisation général. Enfin, nous présentons la planification
des sprints ainsi que l’environnement de développement.

2.2. Backlog du produit

Le backlog de produit est la liste des fonctionnalités attendues par notre application. Il contient
toutes les tâches qui seront développées par l’équipe. Elles y sont classées par priorité ce qui
permet de définir l’ordre de réalisation. Les tâches ainsi que ces priorités sont dégagées suite à
des réunions avec le client et le chef de projet.

Le backlog de produit permet de produire le plan de chaque sprint qui contient les différentes
fonctionnalités qu’on estime finir à la date précisée pour le sprint.
La complexité de la réalisation de chaque user story est ceci selon la suite de Fibonacci. Cette
dernière est une suite d’entiers, dont chaque terme est la somme de deux précédents, en
considérants les deux termes initiaux 0 et 1. Le début de cette suite est : 0, 1, 2, 3, 5, 8, 13 et
l’infini [6].
La priorité de l’user story selon la valeur métier et l’ordre de réalisation.

Table 1: Backlog du produit

Titre User Story Complexité

1 Gérer les Projets En tant qu’administrateur, je peux 2
consulter les projets.
En tant qu’administrateur, je peux 5
ajouter les projets.
En tant qu’administrateur, je peux 5
modifier les projets.
En tant qu’administrateur, je peux 2
supprimer les projets.
2 Gérer les clients En tant qu’administrateur, je peux 2
consulter les clients.
En tant qu’administrateur, je peux 2
ajouter les client.
En tant qu’administrateur, je peux 2
modifier les clients.
En tant qu’administrateur, je peux 2
supprimer les clients.
3 Gérer les employés En tant qu’administrateur, je peux 5
consulter les employés.
En tant qu’administrateur, je peux 5

15
 ajouter les employés.
En tant qu’administrateur, je peux 5
modifier les employés.
En tant qu’administrateur, je peux 5
supprimer les employés.
4 Gérer les groupes d’activité En tant qu’administrateur, je peux 2
consulter les groupes d’activité.
En tant qu’administrateur, je peux 2
ajouter les groupes d’activité.
En tant qu’administrateur, je peux 2
modifier les groupes d’activité.
En tant qu’administrateur, je peux 2
supprimer les groupes d’activité.
5 Gérer les domaines En tant que administrateur, je peux 3
ajouter les domaines.
En tant que administrateur, je peux 3
modifier les domaines.
En tant que administrateur, je peux 3
consulter les domaines.
En tant que administrateur, je peux 3
supprimer les domaines.
6 Gérer les types budget En tant que administrateur, je peux 2
ajouter les types budget.
En tant que administrateur, je peux 2
modifier les types budget.
En tant que administrateur, je peux 2
consulter les types budget.
En tant que administrateur, je peux 2
supprimer les types budget.
7 Gérer les demandes Congé En tant qu’employé, je peux ajouter 2
une demande congé.
En tant qu’employé, je peux 2
modifier les demandes congé.
En tant qu’employé, je peux 2
consulter les demandes congé.
En tant qu’employé, je peux 2
supprimer les demandes congé.
En tant qu’administrateur je peux 3
valider ou refuser les demandes
congé.
8 Gérer les pôles En tant que administrateur, je peux 2
ajouter les pôles.
En tant que administrateur, je peux 2
modifier les pôles.
En tant que administrateur, je peux 2
consulter les pôles.
En tant que administrateur, je peux 2
supprimer les pôles.
9 Gérer les fonctionnalités En tant que administrateur, je peux 2
ajouter les fonctionnalités.
En tant que administrateur, je peux 2
modifier les fonctionnalités.
En tant que administrateur, je peux 2
consulter les fonctionnalités.

16
 En tant que administrateur, je peux 2
supprimer les fonctionnalités.
10 Gérer les activités En tant que administrateur, je peux 2
ajouter les activités.
En tant que administrateur, je peux 2
modifier les activités.
En tant que administrateur, je peux 2
consulter les activités.
En tant que administrateur, je peux 2
supprimer les activités.
11 Gérer les types projet En tant que administrateur, je peux 2
ajouter les types projet.
En tant que administrateur, je peux 2
modifier les types projet.
En tant que administrateur, je peux 2
consulter les types projet.
En tant que administrateur, je peux 2
supprimer les types projet.
12 Gérer les équipes projet En tant que administrateur, je peux 2
ajouter les équipes projet.
En tant que administrateur, je peux 2
modifier les équipes projet.
En tant que administrateur, je peux 2
consulter les équipes projet.
En tant que administrateur, je peux 2
supprimer les équipes projet.
13 Gérer les secteurs En tant que administrateur, je peux 2
ajouter les secteurs.
En tant que administrateur, je peux 2
modifier les secteurs.
En tant que administrateur, je peux 2
consulter les secteurs.
En tant que administrateur, je peux 2
supprimer les secteurs.
14 Gérer homme jours En tant que administrateur, je peux 2
turnover ajouter homme jours turnover.
En tant que administrateur, je peux 2
modifier homme jours turnover.
En tant que administrateur, je peux 2
consulter homme jours turnover.
15 Gérer pourcentage charge En tant que administrateur, je peux 2
AO ajouter pourcentage charge AO.
En tant que administrateur, je peux 2
modifier pourcentage charge AO.
En tant que administrateur, je peux 2
consulter pourcentage charge AO.
16 Gérer les jours fériés En tant que administrateur, je peux 2
ajouter les jours fériés.
En tant que administrateur, je peux 2
modifier les jours fériés.
En tant que administrateur, je peux 2
consulter les jours fériés.

17
 En tant que administrateur, je peux 2
supprimer les jours fériés.
17 Gérer les horaires En tant que administrateur, je peux 2
ajouter les horaires.
En tant que administrateur, je peux 2
modifier les horaires.
En tant que administrateur, je peux 2
consulter les horaires.
En tant que administrateur, je peux 2
supprimer les horaires.
18 Gérer les tâches En tant que administrateur, je peux 2
ajouter les tâches.
En tant que administrateur, je peux 2
modifier les tâches.
En tant que administrateur, je peux 2
consulter les tâches.
En tant que administrateur, je peux 2
supprimer les tâches.

2.3. Identification des besoins

L’identification des besoins comprend l’identification des acteurs et la détermination des besoins
fonctionnels et les besoins non fonctionnels.

2.3.1. Identification des acteurs et de fonctionnalités

Dans ce qui suit, nous allons présenter les différents acteurs interagissant avec notre système. En
effet, un acteur peut consulter et ou modifier directement l’état du système, en émettant ou en
recevant des messages éventuellement porteurs de données.
Les principaux acteurs du notre système projeté ainsi que ses rôles sont présentés dans la table 2
suivant :

Table 2 : Les différents acteurs interagissant avec notre système

Administrateur l’administrateur c’est celui qui peut gérer tout le

système
Employé l’employé peut consulter ses données personnelles,
demander des congés, consulter et ajouter des tâches

18
2.3.2. Les besoins fonctionnels

L’application doit fournir les fonctionnalités suivantes :

• Administrateur
 Gérer les projets
 Valider les demandes congés.
 Consultation des statistiques.
 Paramétrage de l’application.
 Suivie des tâches.
• Employé
 Gérer les demandes congés.
 Gérer les tâches.
 Consultation et modification des données personnelles.

2.3.3. Les besoins non fonctionnels

En plus des besoins fonctionnels explicités, le produit livré à la fin de chaque sprint doit pouvoir
assurer les exigences non fonctionnelles suivantes :

• Intégrité : une partie essentielle de n’importe quelle application est de s’assurer que
toutes les opérations effectuées sont exécutées correctement,
• Ergonomie et simplicité : il faut prendre en considération tous les types des utilisateurs
pour cette raison notre application doit être simple à manipuler contenant les données
nécessaires pour effectuer une opération,
• Sécurité : Elle est assurée par un système d’authentification et d’autorisation pour
protéger les données personnelles,
• Performance et efficacité : Contenir un minimum d’erreurs, satisfaire les spécifications
et remplir ses missions, permette d’effectuer les opérations rapidement et de manière
efficace pour gagner du temps,
• Testabilité : Faciliter les procédures de test permettant de s’assurer de l’adéquation des
fonctionnalités.

2.4. Diagramme de cas d’utilisation global

Le diagramme de cas d’utilisation, présenté par la figure 6, permet de synthétiser les

spécifications générales de notre application ainsi que les fonctionnalités de chaque utilisateur de
système.

19
 Figure 6 : Diagramme de cas d'utilisation global

2.5. Diagramme des classes global

20
 Figure 7: Diagramme de Classe Global

2.6. Planification des sprints

Une fois nous avons terminé le backlog du produit, nous avons établi la réunion de planification.
Le but de cette réunion est de construire le backlog de sprint en se basant sur le backlog de
produit réalisé par le Product owner.
A la fin, nous avons identifié, les durées prévisionnelles du travail à effectuer durant chaque
sprint. Pour notre projet nous avons devisé le travail en deux sprints. Pour le premier contient les
tâches de développement de paramétrages d’une durée d’un mois alors que le deuxième sprint

21
contient la gestion des tâches, congé et tableau de bord par une durée d’un mois. La figure 8
montre la répartition des sprints relative à notre système.
Nous avons utilisé DevOps pour la planification de notre projet.

Plan du release Plan du release

Estimation: De 15/11/19 au 15/12/19 Estimation: De 15/04 au 27/04

Sprint 1 Sprint 2

1. Gérer les clients

2. Gérer les employés
3. Gérer les domaines
4. Gérer les types budget
5. Gérer les groupes d’activité
6. Gérer les pôles 1. Gérer les tâches
7. Gérer les fonctionnalités 2. Gérer les demandes
8. Gérer les activités congé
9. Gérer les secteurs 3. Gérer les projets
10. Gérer les types de frais
4. Consulter tableau de
11. Gérer les hommes jours
turnover bord
12. Gérer les pourcentages AO
13. Gérer les jours fériés
14. Gérer les horaires

444

Figure 8: Planification des sprints

2.6.1. DevOps

DevOps regroupe des personnes, des processus et des technologies qui permettent une livraison
continue de valeur aux clients. DevOps, nom composé du terme dev (pour développement) et du
terme ops (pour opérations), est une pratique de développement logiciel qui unifie les opérations
de développement et les opérations informatiques. Cette pratique permet la coordination et la
collaboration entre des disciplines autrefois cloisonnées. Les équipes d’ingénierie qualité et de
sécurité font également partie de l’équipe élargie du modèle DevOps.
DevOps inclut des activités principales, notamment la planification et le suivi, le développement,
les builds et les tests, la livraison, le monitoring et les opérations. Ces activités, ainsi que les
outils et technologies DevOps, aident à automatiser le cycle de vie des applications. Les
22
processus auparavant manuels et lents pour vos équipes, tels que la mise à jour du code ou la
mise en service d’un nouvel environnement, peuvent être réalisés rapidement et en continu
lorsque vous utilisez les outils et pratiques DevOps. Par ailleurs, il est plus facile de respecter les
standards de sécurité et de fiabilité qui sont intégrés au processus.
Avec DevOps, votre organisation est équipée pour fournir de meilleurs produits, plus rapidement.
En associant des personnes, des processus et des technologies à des pratiques et outils partagés,
vous bénéficiez de temps de développement réduits, d’un Time-to-Market plus rapide et d’une
qualité produit accrue [7].
Les figures 9 et 10 présentent, respectivement, la planification des Sprints 1 et 2.

Figure 9 : Planification du Sprint 1 avec DevOps

23
 Figure 10 : Planification du Sprint 2 avec DevOps

2.7. Environnement de travail

L’analyse des besoins techniques couvre la spécification des technologies à utiliser ainsi que la
structure applicative pour donner une vision globale sur l’architecture de notre projet Avant de se
lancer dans la conception et l’implémentation de notre projet nous allons décrire l’environnement
et les outils du travail. On va commencer par définir l’environnement matériel, ensuite
l’environnement de développement puis on passe à celui logiciel qui est bien riche.

2.7.1. Environnement matériel

Tout au long de notre projet, nous avons eu à notre disposition 3 ordinateurs portables qui
disposent de la configuration suivante :

• LENOVO: Intel Core i7 @ 1TO, Ram: 8, 00 Go,

• ASUS: Intel Core i7 @ 1TO, Ram: 8, 00 Go,
• LENOVO: Intel Core i5 @ 2TO, Ram: 8, 00 Go,
• Système d’exploitation : Windows 10.

2.7.2. Environnement de développement

24
Visual Studio 2017 : Visual Studio est un ensemble complet d’outil de développement
permettant de générer plusieurs types des applications Windows [8].

SQL SERVER 2017 : SQL Server est un système de gestion de base de données et
commercialisé par la société Microsoft.

SQL Server Management Studio 2017 : est un environnement intégré qui permet d’avoir accès,
de configurer, de gérer, d’administrer et de développer tous les composants de SQL Server [9].
Visual Studio Code : est un éditeur de code extensible développé par Microsoft pour Windows,
Linux et macOS2.

2.7.3. Environnement logiciel

• ASP.NET Core 2.0 :

ASP.NET Core est une jeune plateforme de développement, dont la première version stable à vue
le jour en juin 2016. Elle a été créée pour répondre aux besoins des développeurs dans la mise en
place d'applications Web modernes multiplateformes pouvant cibler le cloud et le mobile.

ASP.NET Core a donc été développé avec à l'esprit l'ouverture, les performances et la légèreté :

• le Framework est développé en open source avec la participation de la communauté. Son

code source est disponible sur GitHub;
• il est multiplateforme et peut fonctionner sur Windows, Linux et Mac ;

25
• il est indépendant de tout environnement de développement. Pas besoin de Visual Studio
pour créer une application ASP.NET Core ;
• il est développé autour de la modularité. De ce fait, une application ASP.NET Core est
publiée uniquement avec le nécessaire pour son fonctionnement. Ce qui rend la
plateforme un candidat de choix pour le cloud, où l'espace de stockage utilisé est facturé.

• Angular :
Angular est un Framework JavaScript côté client qui permet de réaliser des applications de
type « Single Page Application ». Il est basé sur le concept de l’architecture MVC (Model
View Controller) qui permet de séparer les données, les vues et les différentes actions que
l’on peut effectuer.

• HTML5 : définit deux syntaxes de DOM : HTML5 et XHTML5. Cette version apporte
de nouvelles possibilités en termes de création d’ « applications Web riches » bénéficiant
de l’intégration d’éléments multimédias et d’interactivité.

• Bootstrap: est un Framework CSS3, HTML5 et JavaScript, créé par les développeurs de
Twitter .Il comporte un système de grille de 12 colonnes efficace, permettant de mettre
en ordre l’aspect visuel d’une page web. Il apporte du style pour les boutons, les
formulaires, la navigation et permet ainsi de concevoir un site Web rapidement et avec
peu de lignes de code ajoutées.

• CSS3: est un langage de style permettant d’améliore le contenu des pages Web.

26
 • Entity Framework : est un outil permettant de créer une couche d’accès aux données
DAL pour Data Access Layer) liée à une base de données relationnelle.

Le but de cette solution de mapping est d’offrir une couche d’interfaçage qui sera
l’intermédiaire entre la base de données et le développeur [10].

Dans notre application, nous avons utilisé l’approche Data Base First, présenté par la
figure 9.

Figure 11 : Data Base First Approche

2.8. Architecture générale de l’application

Avant de se lancer dans la conception et le développement, nous allons préparer notre

architecture. La figure 10 présente l’architecture de notre projet.
Notre application est divisée en deux parties :

• La partie Front, développé avec Angular, des maquettes web permet aux utilisateurs de
gérer les différentes entités.

• La partie Back, développé avec ASP.Net Core, qui adopte le modèle MVC avec une
séparation entre le modèle de données, la vue et les traitements, alors on peut appliquer
cette sémantique de Model-View-Controller avec :

o Modèle : les modèles sont les entités de notre application. Ils sont également des
tables SQLServer,
o Vue : les vues sont définies en fichiers HTML dans Angular,
o Contrôleur : le contrôleur est web API.

27
 Figure 12: Architecture de l’application

3. Conclusion

À la fin de cette phase, nous avons effectué une présentation en clair de nos besoins et de la
solution proposée. En premier lieu nous avons identifié le backlog du produit. Ensuite, nous
avons présenté la spécification des besoins ainsi que la conception générale. Enfin, nous avons
exposé l’environnement matériel et logiciel de notre projet. Dans le chapitre suivant nous allons
passer à la mise en œuvre des releases de notre projet.

28
 Chapitre 3

Mise en œuvre du projet

29
1. Introduction

Dans ce chapitre nous avons choisi d’entamer la mise en œuvre de notre projet. Dans la première
partie nous présentons la première release, le Sprint 1, et dans la seconde la deuxième release,
Sprints 2, en organisant le travail sur trois phases principales qui sont l’analyse, la conception, et
la réalisation.

2. Mise en œuvre du Release 1

Dans cette partie, nous présentons la réalisation du premier sprint.

2.1. Sprint 1

Le sprint est le cœur de Scrum. Il s’agit d’un bloc de temps durant lequel un incrément du produit
sera réalisé. Tous les sprints d’une release ont une durée constante et ne se chevauchent jamais,
c’est-à-dire qu’un sprint ne peut pas démarrer tant que le précédent n’est pas encore terminé.
Avant de se lancer dans un sprint, l’équipe Scrum doit obligatoirement définir le but de ce dernier
qui doit être un tableau descriptif qui précise la charge du travail pour chaque tâche en nombre de
jours.

2.1.1. Backlog du Sprint

La table 3 décrit les Stories de notre backlog du sprint.

Table 3: Backlog du Sprint 1

Id Titre Story
1 Gérer les clients En tant qu’administrateur, je peux
consulter les clients.
En tant qu’administrateur, je peux
ajouter les client.
En tant qu’administrateur, je peux
modifier les clients.
En tant qu’administrateur, je peux
supprimer les clients.
2 Gérer les employés En tant qu’administrateur, je peux
consulter les employés.
En tant qu’administrateur, je peux
ajouter les employés.
En tant qu’administrateur, je peux
modifier les employés.
En tant qu’administrateur, je peux
supprimer les employés.
3 Gérer les groupes d’activité En tant qu’administrateur, je peux
consulter les groupes d’activité.
En tant qu’administrateur, je peux

30
 4ajouter les groupes d’activité.
En tant qu’administrateur, je peux
modifier les groupes d’activité.
En tant qu’administrateur, je peux
supprimer les groupes d’activité.
4 Gérer les domaines En tant que administrateur, je peux
ajouter les domaines.
En tant que administrateur, je peux
modifier les domaines.
En tant que administrateur, je peux
consulter les domaines.
En tant que administrateur, je peux
supprimer les domaines.
5 Gérer les types budget En tant que administrateur, je peux
ajouter les types budget.
En tant que administrateur, je peux
modifier les types budget.
En tant que administrateur, je peux
consulter les types budget.
En tant que administrateur, je peux
supprimer les types budget.
6 Gérer les pôles En tant que administrateur, je peux
ajouter les pôles.
En tant que administrateur, je peux
modifier les pôles.
En tant que administrateur, je peux
consulter les pôles.
En tant que administrateur, je peux
supprimer les pôles.
7 Gérer les fonctionnalités En tant que administrateur, je peux
ajouter les fonctionnalités.
En tant que administrateur, je peux
modifier les fonctionnalités.
En tant que administrateur, je peux
consulter les fonctionnalités.
En tant que administrateur, je peux
supprimer les fonctionnalités.
8 Gérer les activités En tant que administrateur, je peux
ajouter les activités.
En tant que administrateur, je peux
modifier les activités.
En tant que administrateur, je peux
consulter les activités.
En tant que administrateur, je peux
supprimer les activités.
9 Gérer les secteurs En tant que administrateur, je peux
ajouter les secteurs.
En tant que administrateur, je peux
modifier les secteurs.
En tant que administrateur, je peux
consulter les secteurs.
En tant que administrateur, je peux
supprimer les secteurs.
10 Gérer homme jours En tant que administrateur, je peux

31
 turnover ajouter homme jours turnover.
En tant que administrateur, je peux
modifier homme jours turnover.
En tant que administrateur, je peux
consulter homme jours turnover.
11 Gérer pourcentage charge En tant que administrateur, je peux
AO ajouter pourcentage charge AO.
En tant que administrateur, je peux
modifier pourcentage charge AO.
En tant que administrateur, je peux
consulter pourcentage charge AO.
En tant que administrateur, je peux
12 Gérer les jours fériés ajouter les jours fériés.
En tant que administrateur, je peux
modifier les jours fériés.
En tant que administrateur, je peux
consulter les jours fériés.
En tant que administrateur, je peux
supprimer les jours fériés.
En tant que administrateur, je peux
13 Gérer les horaires ajouter les horaires.
En tant que administrateur, je peux
modifier les horaires.
En tant que administrateur, je peux
consulter les horaires.
En tant que administrateur, je peux
supprimer les horaires.

2.1.2. Diagramme de cas d’utilisation

Dans cette partie nous présentons la phase d’analyse qui répond à la question « que fait
l’utilisateur d’application ». La réponse de cette question se traduit par la présentation du
diagramme des cas d’utilisation.
La figure 13 présente le diagramme de cas d’utilisation du sprint 1.

32
 Figure 13: Diagramme de cas d'utilisation du sprint 1

2.1.3. Conception

La conception est la deuxième activité dans un Sprint. Elle est présentée par le diagramme
des cl.

2.1.3.1. Diagramme de classe

La figure 14 traduit le diagramme de classe utilisé pour le développement du premier sprint.

33
 Figure 14 : Diagramme de classe du sprint 1

2.1.4. Réalisation

Cette partie est consacrée à l’exposition du travail achevé à travers des captures d’écrans de
différentes interfaces développées pendant ce sprint. La figure 15 présente l’interface de
consultation et la figure 16 montre l’interface d’ajout.

34
 Figure 15 : Interface de consultation

Figure 16 : Interface d’ajout

La figure 17 présente l’interface de modification et 18 l’interface de suppression.

35
 Figure 17 : Interface de modification

Figure 18 : Interface de suppression

3. Mise en œuvre du Release 2

36
Après avoir terminé le premier release de notre projet, nous pouvons maintenant passer au
deuxième release.

3.1. Sprint 2

Le but principal de Sprint 2 est de mettre en œuvre les stories qui sont présentées par le
tableau de Backlog.

3.1.1. Backlog du Sprint

La table 4 décrit les Stories de notre backlog du sprint.

Table 4: Backlog du Sprint 2

Id Titre User Story
1 Gérer les Projets En tant qu’administrateur, je peux
consulter les projets.
En tant qu’administrateur, je peux
ajouter les projets.
En tant qu’administrateur, je peux
modifier les projets.
En tant qu’administrateur, je peux
supprimer les projets.
2 Gérer les demandes Congé En tant qu’employé, je peux ajouter
une demande congé.
En tant qu’employé, je peux
modifier les demandes congé.
En tant qu’employé, je peux
consulter les demandes congé.
En tant qu’employé, je peux
supprimer les demandes congé.
En tant qu’administrateur je peux
valider ou refuser les demandes
congé.
3 Gérer les types projet En tant que administrateur, je peux
ajouter les types projet.
En tant que administrateur, je peux
modifier les types projet.
En tant que administrateur, je peux
consulter les types projet.
En tant que administrateur, je peux
supprimer les types projet.
4 Gérer les équipes projet En tant que administrateur, je peux
ajouter les équipes projet.
En tant que administrateur, je peux
modifier les équipes projet.
En tant que administrateur, je peux
consulter les équipes projet.
En tant que administrateur, je peux
supprimer les équipes projet.
5 Gérer les tâches En tant que administrateur, je peux

37
 ajouter les tâches.
En tant que administrateur, je peux
modifier les tâches.
En tant que administrateur, je peux
consulter les tâches.
En tant que administrateur, je peux
supprimer les tâches.

3.1.2. Diagramme de cas d’utilisation

La figure 19 représente le diagramme de cas d’utilisation du sprint 2.

Figure 19 : Diagramme de cas d'utilisation de sprint 2

3.1.3. Conception

Après avoir terminé le diagramme de cas d’utilisation du deuxième sprint. Nous passons à
présenter le diagramme d’activité de cette partie.
3.1.3.1. Diagramme d’activité

La figure 20 présente le diagramme d’activité de Gérer demande congé.

38
 Figure 20: Diagramme d'activité de gérer demande congé
3.1.3.2. Diagramme des classes de sprint 2

La figure 21 présente le diagramme de classe du sprint 2.

39
 Figure 21: Diagramme de classe du sprint 2

3.1.4. Réalisation

Dans cette partie nous présentons l’interface de tableau de bord, figure 22, et l’interface de
validation congé, figure 23.

40
Figure 22 : Interface de tableau de bord

Figure 23 : Interface de validation congé

41
4. Conclusion

Durant ce chapitre, nous avons présenté les deux releases de notre projet. Tout d’abord, nous
avons commencé par le premier release qui a été consacré pour la partie paramétrage. Nous avons
défini notre ligne de travail grâce au Backlog du sprint. Ensuite, nous avons fait l’analyse
détaillée de ce dernier pour aboutir enfin à l’étude conceptuelle et la réalisation de cette itération.
Le même travail a été effectué durant le deuxième release.

42
 Conclusion générale
Notre projet de spécialité encadré consiste à créer une application web de gestion des ressources
humaines pour la société GFI.
Pour réaliser ce travail, nous avons commencé par une analyse qui consiste à définir le contexte
général ainsi que la méthodologie du travail adopté. Ensuite, nous avons analysé et spécifié les
besoins fonctionnels et non fonctionnels, après avoir étudié l’existant, aux quels devra répondre
notre solution. Dans une étape suivante, nous avons présenté l’environnement de travail, les
outils et les technologies utilisés tout au long de notre projet. Puis, nous avons détaillé notre
conception à travers les diagrammes de cas d’utilisation, le diagramme de classe et les
diagrammes d’activité. Finalement, nous avons décrit notre application à travers des captures
d’écran.
Ce projet nous a permis d’approfondir nos connaissances théoriques, acquises tout le long de
notre formation, par la pratique des nouvelles technologies. Ce projet nous a permis de maîtriser
le langage de modélisation UML, le Framework Asp.Net Core et Angular ainsi que la
manipulation d’une base de données SQLServer.

43
 Références
[1] https://www.memoireonline.com/04/14/8816/Mise-en-place-d-un-nouveau-ERP--Enterprise-
Resource-Planning--Cas-de-la-societe-Bouchamaoui-ind.html

[2] https://www.gfi.world/fr-fr/

[3] J. Tabaka., La gestion de projet : methodes classiques vs methodes agiles. ACCESS-DEV. Fev.2013.
Adresse : http://www.access-dev.com/access-dev/lagestion-de-projet-methodesclassiques-vs-methodes-
agiles/.

[4] E.deCASI.(Novembre.2016).Lesméthodesagilessont-ellesunearnaque?
https://manurenaux.wp.imt.fr/2013/09/30/les-methodes-agiles-sontelles-une-arnaque/.

[5] igm.univ. (Mars 2015). Scrum : qu’est ce que c’est? http://www-igm.univ-

mlv.fr/~dr/XPOSE2008/SCRUM/presentation.php.

[6] F. Lothon, Guide de démarrage scrum. L’Agiliste. Jan. 2010. http://www.agiliste.fr/guide-de-

demarrage-scrum/.

[7] J.-P. Davalan., Suite de fibonacci mise en évidence. jm.davalan. Jan. 2002.
http://jm.davalan.org/divers/fibonacci/f03.html.

[8] https://azure.microsoft.com/en-us/solutions/

[9] Télécharger SQL Server Management Studio (SSMS). Jan. 2017. https://msdn.microsoft.com/fr-
fr/library/mt238290.aspx.

[10] J.-P..,Un nouvel environnement de programmation pour android. Cellenza.2-janvier-2014.

http://blog.cellenza.com/evenements/asp-net-mvc-fromzero-to-hero/.

44
 Netographie
https://dev.azure.com/

https://www.gfi.world/fr-fr/

https://angular.io/

https://material.angular.io/components/categories

https://primefaces.org/primeng/#/

https://stackoverflow.com/

https://github.com/

45