Moetaz

DEDICACES
À mes très chers parents, Nabil et Souhir

Vous avez tout sacrifié pour vos enfants n’épargnant ni santé ni efforts. Vous m’avez donné un
magnifique modèle de labeur et de persévérance. Les espoirs et les rêves m’appartiennent

maintenant et tout cela est grâce à vous chers parents. Merci de m’aimer comme vous le faites
si merveilleusement. Merci d’être tout simplement mes parents.
À ma chère soeur, Mawadda.

Tu m’as soutenu durant toute ma vie et mes années d’études, Tu m’as portée conseil, aide,
soutien et encouragement. Que Dieu te préserve santé et longue vie.
REMERCIEMENTS
Je réserve ces lignes en signe de gratitude et de reconnaissance à tous ceux qui ont contribué
de près ou de loin à la réalisaton de ce projet de fin d’études dans les meilleures conditions.
Un remerciement particulier à Monsieur Mohamed Karim Abdmouleh au sein de l’ENIG,

pour m’avoir encadré durant ce projet de fin d’études. Sa compétence, sa clair voyance, m’ont
beaucoup appris. J’aimerais témoigner du plaisir qu’était pour moi de travailler sous ses directives.
Merci de m’avoir appris à penser autrement.
Mes profondes reconnaissances s’adressent également à mes encadrants de société Monsieur

Fahmi Zouari et Safouene Dammak, pour ses directives inestimables, ses remarques pertinentes,
ses patiences et le temps qu’ils m’ont consacré. Je suis marqué par son savoir scientifique et par
ses qualités humaines.
Mes vifs remerciements s’adressent également à mes enseignants de l’ENIG qui ont contribué
à ma formation durant mon parcours .
Je tiens aussi à remercier les membres de l’honorable jury qui m’ont fait l’honneur de juger
ce travail en espérant qu’ils trouvent les qualités de motivation qu’ils attendent.
TABLE DES MATIÈRES
INTRODUCTION GÉNÉRALE 1
1 Étude Préalable 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Présentation générale de l’entreprise . . . . . . . . . . . . . . . . . . 4
1.2.2 Domaines d’activité et Organigramme hiérarchique de la société . . . 5
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Problématique et contexte du projet . . . . . . . . . . . . . . . . . . . 6
1.3.2 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Présentation de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1.1 Applications existantes portant sur la gestion des taches des
employés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1.2 Applications existantes portant sur la gestion du temps de
travail des employés . . . . . . . . . . . . . . . . . . . . . . 8
1.4.1.3 Applications existantes portant sur le partage des événements 8
1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.3 Solution Proposée ......................................................................................... 10
1.5 Contexte méthodologique du projet .......................................................................... 11
1.5.1 Le choix de la Méthode Scrum ..................................................................... 11
1.5.2 Rôles et notions ............................................................................................ 12
1.6 Conclusion................................................................................................................. 13
2 Analyse et spécification des besoins 14

2.1 INTRODUCTION..................................................................................................... 15
2.2 Spécification des besoins........................................................................................... 15
2.2.1 Identification des acteurs .............................................................................. 15
2.2.2 Besoins fonctionnels ..................................................................................... 16
2.2.3 Besoins non fonctionnels .............................................................................. 17
2.3 Pilotage du projet avec SCRUM ............................................................................... 18
2.3.1 Backlog Produit ............................................................................................ 18
2.3.2 Découpage et planification des sprints ......................................................... 21
2.4 Conclusion................................................................................................................. 22
3 Release 1 : Gestion des données de base 23

3.1 Introduction ............................................................................................................... 24
3.2 Planification .............................................................................................................. 24
3.3 Sprint 1 : S’authentifier ............................................................................................. 24
3.3.1 Backlog sprint ............................................................................................... 24
3.3.2 Analyse des besoins ...................................................................................... 25
3.3.2.1 Diagramme de cas d’utilisation .................................................... 25
3.3.2.2 Description textuelle .................................................................... 25
3.3.3 Conception.................................................................................................... 26
3.3.3.1 Diagramme de séquence .............................................................. 26
3.3.3.2 Diagramme de classe.................................................................... 27
3.4 Sprint 2 :Intégration du module Employé ................................................................. 28
3.4.1 Backlog sprint ............................................................................................... 28
3.4.3 Conception.................................................................................................... 29
3.5 Sprint 3 :Intégration du module Entreprise ............................................................... 31
3.5.1 Backlog sprint ............................................................................................... 31
3.5.3 Conception.................................................................................................... 33
3.6 Conclusion................................................................................................................. 35
4 Release 2 : Mise en place des procédures de travail 36

4.1 Introduction ............................................................................................................... 37
4.2 Planification .............................................................................................................. 37
4.3 Sprint 4 :Intégration du module projet ...................................................................... 37
4.3.1 Backlog sprint ............................................................................................... 37
4.3.3 Conception.................................................................................................... 39
4.4 Sprint 5 : Intégration du module tâches .................................................................... 40
4.4.1 Backlog sprint ............................................................................................... 40
4.4.2.1 Diagramme des cas d’utilisation .................................................. 40
4.4.2.2 Description Textuelle ................................................................... 41
4.4.3 Conception.................................................................................................... 42
4.5 Sprint 6 : Intégration du module catégorie ................................................................ 44
4.5.1 Backlog sprint ............................................................................................... 44
4.5.2.2 Description Textuelle du cas d’utilisation.................................... 45
4.5.3 Conception.................................................................................................... 46
4.6 Conclusion................................................................................................................. 46
5 Release 3 :Implémentation des outils de supervision 47

5.1 Introduction ............................................................................................................... 48
5.2 Planification .............................................................................................................. 48
5.3 Sprint 7 :Intégration du module emploi du temps ..................................................... 48
5.3.1 Backlog sprint ............................................................................................... 48
5.3.3 Conception.................................................................................................... 51
5.4 Sprint 8 : Intégration du module calendrier .............................................................. 52
5.4.1 Backlog sprint ............................................................................................... 52
5.4.2.2 Description Textuelle ................................................................... 53
5.4.3 Conception.................................................................................................... 54
5.4.3.1 Diagramme d’activité ................................................................... 54
5.5 Sprint 9 : Intégration des modules rapport et statistique ........................................... 56
5.5.1 Backlog sprint ............................................................................................... 56
5.5.2.2 Description Textuelle du cas d’utilisation.................................... 57
5.5.3 Conception.................................................................................................... 58
5.6 Conclusion................................................................................................................. 58
6 Réalisation 59
6.1 Introduction ............................................................................................................... 60
6.2 Architecture et technologies utilisées ........................................................................ 60
6.2.1 Architecture de l’application ........................................................................ 60
6.2.1.1 Étude comparative des architectures ............................................ 60
6.2.1.2 Explication de l’architecture REST API ...................................... 61
6.2.2 Architecture physique ................................................................................... 63
6.2.3 Architecture logique ..................................................................................... 64
6.3 Aspet technique ......................................................................................................... 66
6.3.1 Technologie du frontend............................................................................... 66
6.3.1.1 Dart............................................................................................... 66
6.3.1.2 Flutter ........................................................................................... 66
6.3.2 Technologie du backend .............................................................................. 68
6.3.2.1 NodeJS ......................................................................................... 68
6.3.2.2 NestJS........................................................................................... 68
6.3.3 Base de données .......................................................................................... 70
6.3.3.1 MongoDB.................................................................................... 70
6.3.3.2 Avantages de MongoDB ............................................................. 70
6.4 Présentation de l’environnement ............................................................................... 70
6.4.1 Environnement matériel .............................................................................. 71
6.4.2 Environnement matériel .............................................................................. 71
6.4.2.1 Postman ....................................................................................... 71
6.4.2.2 Visual Studio Code ..................................................................... 71
6.4.2.3 Android Studio ............................................................................ 72
6.4.2.4 MongoDB Compass .................................................................... 72
6.4.2.5 NPM ............................................................................................. 73
6.4.2.6 Serveur de gestion de versions GitLab ......................................... 73
6.4.2.7 StarUML ..................................................................................... 73
6.5 Diagramme de déploiement ...................................................................................... 74
6.5.1 Définition...................................................................................................... 74
6.5.2 Éléments d’un diagramme de déploiement .................................................. 74
6.5.3 Diagramme de déploiement système ............................................................ 74
6.6 Réalisation ................................................................................................................. 75
6.7 Conclusion................................................................................................................. 80
CONCLUSION GÉNÉRALE 81
BIBLIOGRAPHIE 82
LISTE DES FIGURES
1.1 Logo PixiMind [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Organigramme hiérarchique de la société . . . . . . . . . . . . . . . . . . . . 5
1.3 Représentation d’une interface du Redmine . . . . . . . . . . . . . . . . . . . 7
1.4 Représentation d’une interface du Toggl Track . . . . . . . . . . . . . . . . . . 8
1.5 Représentation d’une interface du Google agenda . . . . . . . . . . . . . . . . 9
1.6 La méthodologie Scrum ............................................................................................ 12
2.1 Planification du projet ............................................................................................... 22
3.1 Planification du release 1........................................................................................... 24

3.2 Diagramme de cas d’utilisation de sprint authentification ........................................ 25
3.3 Diagramme de séquence de cas d’utilisation "S’authentifier ".................................. 27
3.4 Diagramme de classe de sprint "S’authentifier" ........................................................ 27
3.5 Diagramme de cas d’utilisation du sprint "Intégration du module Employé" ........... 28
3.6 Diagramme de séquence de cas d’utilisation : "gérée employé" ............................... 30
3.7 Diagramme de classe de sprint "Intégration de module Employé" ........................... 31
3.8 Diagramme de cas d’utilisation du sprint 3 ............................................................... 32
3.9 Diagramme de séquence de cas d’utilisation : "Intégration entité Companie" ......... 34
3.10 Diagramme de classe de sprint 3 ............................................................................... 35
4.1 Planification du release 2........................................................................................... 37

4.2 Diagramme de cas d’utilisation du sprint "Intégration du module projet" ................ 38
4.3 Diagramme de séquence de cas d’utilisation : « Ajouter projet » et « Assigner
des membres au projet » ............................................................................................ 39
4.5 Diagramme des cas d’utilisation du sprint 5 ............................................................. 41
4.6 Diagramme d’état de transition de l’objet « tache ».................................................. 43
4.8 Diagramme cas d’utilisation du sprint 6.................................................................... 45
4.9 Diagramme de classe de cas d’utilisation "gérer catégorie"...................................... 46
5.1 Planification du release 3 .......................................................................................... 48
5.3 Diagramme de séquence d’ajout d’une ligne dans un "time sheet" .......................... 51
5.6 Diagramme d’activité pour le process « planification d’une réunion » .................... 55
6.1 Architecture API REST ............................................................................................. 63

6.2 Architecture physique de l’application ..................................................................... 64
6.3 Architecture logique de la solution ........................................................................... 65
6.4 Dart Logo .................................................................................................................. 66
6.5 Flutter Logo ............................................................................................................... 67
6.6 NodeJs Logo .............................................................................................................. 68
6.7 NestJS Logo .............................................................................................................. 69
6.8 MongoDB Logo ........................................................................................................ 70
6.9 Postman Logo ............................................................................................................ 71
6.10 Visual Studio Code Logo .......................................................................................... 72
6.11 Android Studio Logo ................................................................................................. 72
6.12 MongoDB Compas Logo .......................................................................................... 72
6.13 NPM Logo ................................................................................................................. 73
6.14 GitLab Logo .............................................................................................................. 73
6.15 StarUML Logo .......................................................................................................... 74
6.16 Diagramme de déploiement de l’application ............................................................ 75
6.17 Interface d’authentification ....................................................................................... 75
6.18 Interface des utilisateurs ............................................................................................ 76
6.19 Interface de modification d’un utilisateur ................................................................. 76
6.20 Pop-up de détail d’un employé.................................................................................. 77
6.21 Interface de construction d’une tache........................................................................ 77
6.22 Interface de la liste des taches ................................................................................... 78
6.23 Interface calendrier d’un employé............................................................................. 78
6.24 Pop-up de partage de temps libre .............................................................................. 79
6.25 Interface "Time Sheet" .............................................................................................. 79
LISTE DES TABLEAUX
1.1 les avantages et les inconvénients des applications évoquées ................................... 10
2.1 Backlog produit ......................................................................................................... 21

2.2 Découpage des sprints ............................................................................................... 21
3.1 Backlog sprint "S’authentifier" ................................................................................. 25

3.2 Description Textuelle : "S’authentifier" .................................................................... 26
3.3 Backlog sprint "Intégration de du module Employé" ................................................ 28
3.4 Description textuelle du cas d’utilisation :"Gérer les employés " ............................. 29
3.5 Backlog sprint "Intégration du module Entreprise" .................................................. 31
3.6 Description textuelle du cas d’utilisation « Gérer les entreprises »........................... 32
3.7 Description textuelle du cas d’utilisation « Visualiser ses détails » .......................... 33
4.1 Backlog sprint "Intégration du module projet" ......................................................... 37

4.2 Description textuelle du cas d’utilisation :"Intégration du module projet" ............... 38
4.3 Backlog sprint " Intégration du module tâches " ....................................................... 40
4.4 Description textuelle du cas d’utilisation « Gérer les tâches » .................................. 41
4.5 Description textuelle du cas d’utilisation « Consulter ses tâches » ........................... 42
4.6 Backlog sprint :Gestion des état des utilisateurs ....................................................... 44
4.7 Description textuelle du cas d’utilisation « Gérer les catégories »............................ 45
5.1 Backlog sprint " Intégration du module emploi du temps " ...................................... 49
5.2 Description textuelle du cas d’utilisation « Remplir son emploi du temps » ............ 50
5.3 Description textuelle du cas d’utilisation « Visualiser emploi du temps » ................ 50
5.4 Backlog sprint " Intégration du module calendrier " ................................................. 52
5.5 Description textuelle du cas d’utilisation « Partager son temps libre » ..................... 53
5.6 Description textuelle du cas d’utilisation « Planifier des événements ».................... 54
5.7 Backlog sprint " Intégration du module rapport et statistique" ................................. 56
5.8 Description textuelle du cas d’utilisation « Gérer les catégories »............................ 57
6.1 Comparaison entre SOAP, REST et GraphQL .......................................................... 61

INTRODUCTION GÉNÉRALE
Durant ces dernières années, les grandes structures multinationales ont réalisé une révolution
informatique par la mise en place de nouveaux outils techniques. Ces outils sont utilisés par la
majorité des entreprises informatiques qui ont développé se savoir-faire. La réalisation de ces
nouvelles applications a changé notre vie personnelle et professionnelle.
Dans le monde professionnel, toute entreprise vise à informatiser et sécuriser leurs données
et aussi à optimiser leur processus de travail. L’utilisation des solutions informatiques notamment
dans la gestion des employés s’avère indispensable.
La gestion de temps des employés et la planification des tâches sont des problèmes majeurs
que l’employé vit toujours. C’est vrai que travailler chaque jour et donner au maximum est
l’objectif principal de l’employeur mais ce dernier peut tomber dans le piège de dispersion
ou blocage ou une mauvaise planification de temps. La planification est aussi importante pour
l’employeur pour suivre la répartition du temps alloué à chaque projet et l’avancement de ceci,
aussi elle leur permet de détecter rapidement les problèmes et les tâches bloquantes pour les
résoudre. La numérisation permet l’analyse des données, les interpréter et assure une meilleure
interactivité entre les collaborateurs et leurs supérieurs ce qui aide à la prise de décision dans
des futurs dossiers et mesurer les performances des agents.
C’est dans ce cadre que s’inscrit notre projet de fin d’études qui consiste à mettre en
place une solution de gestion des employés appelée « My Scheduler » au sein de la société
PIXIMIND. Cette solution doit respecter le cahier de charge fournis et répondre aux besoins
définis afin d’optimiser le bon déroulement de la gestion des ressources humaines, le présent
rapport s’articule autour de six chapitres :
ENIG Page 1
INTRODUCTION GÉNÉRALE
— Le premier chapitre présente l’entreprise, l’étude de l’existant, on conclue avec la solution

proposé et la méthodologie adaptée.
— Le deuxième chapitre est dédié à l’analyse des besoins de notre application, l’identification
de nos acteurs et la planification de notre projet.
— Le troisième chapitre est réservé à la conception et au développement des trois sprints

"authentification", "Intégration de module employé" et "Intégration de module entreprise".
— Le quatrième chapitre examine la conception et au développement des trois sprints "Intégration

de l’entité projet" et "Intégration de l’entité tache" et " Intégration de l’entité catégorie".
— Le cinquième chapitre examine la conception et le développement des trois sprints "Intégration
de l’entité emploi de temps" et "Intégration de l’entité calendrier" et " Intégration des

modules rapport et statistique".
— Le dernier chapitre traite les outils technologiques qu’on a utilisés afin de réaliser ce
projet. D’autre ce chapitre précisera le diagramme de déploiement dans lequel doit répondre
notre application puis les structures et les interfaces développées tout le long de ce stage.
Enfin, nous clôturons ce rapport par une conclusion générale ainsi que les perspectives de notre
travail.
ENIG Page 2
Chapitre
1
Étude Préalable
Sommaire
1.1 Introduction.................................................................................................... 4
1.2 Présentation de l’organisme d’accueil ................................................ 4
1.2.1 Présentation générale de l’entreprise . . . . . . . . . . . . . . . 4
1.2.2 Domaines d’activité et Organigramme hiérarchique de la société 5
1.3 Présentation du projet ............................................................................... 6
1.3.1 Problématique et contexte du projet . . . . . . . . . . . . . . . 6
1.3.2 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Etude de l’existant ........................................................................................7
1.4.1 Présentation de l’existant . . . . . . . . . . . . . . . . . . . . . 7
1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.3 Solution Proposée ................................................................................ 10
1.5 Contexte méthodologique du projet ................................................... 11
1.5.1 Le choix de la Méthode Scrum ........................................................... 11
1.5.2 Rôles et notions ................................................................................... 12
1.6 Conclusion ..................................................................................................... 13
ENIG Page 3
ÉTUDE PRÉALABLE
1.1 Introduction
L’étude préalable constitue une étape préliminaire pour la réalisation d’une application.
En effet, elle permet d’analyser, d’évaluer et de critiquer le fonctionnement habituel, tout en
élaborant la liste des solutions possibles.
Ce chapitre sera réservé pour l’étude préalable de notre projet. Nous commencerons d’abord
par présenter l’organisme d’accueil. Ensuite, nous enchaînerons avec une description générale
de notre projet tout en détaillons la problématique, le contexte du projet et les objectifs à
atteindre. après, nous analyserons quelques solutions existantes sur le marché en discutant leurs
avantages et leurs inconvénients. L’analyse et le critique de l’existant nous ont permis de cerner
nos objectifs afin de développer un système de qualité dans le futur. Ce chapitre sera clôturé par
une présentation de la méthodologie adoptée tout au long de ce projet.
1.2 Présentation de l’organisme d’accueil
Dans cette partie, nous allons présenter l’entreprise PixiMind qui représente l’organisme
d’accueil durant notre projet de fin d’études, tout en détaillant ses activités
1.2.1 Présentation générale de l’entreprise
PIXIMIND est un éditeur d’applications mobiles et web (essentiellement B to B), fondé en

Tunisie et dédié à l’offshore depuis 2013. Une équipe de Geeks, de plus de 30 collaborateurs
maitrisant les technologies de pointe les plus sollicitées sur le marché, engagée à vous apporter
un accompagnement sur mesure, de bout en bout, pour réussir vos projets digitaux via des
solutions personnalisées fluides et riches en fonctionnalités au meilleur coût. a travers les années,
PIXIMIND a su développer une collaboration avec des partenaires en Europe, Belgique et
Moyen-Orient, et a su fidéliser ses partenaires, grâce à des process d’amélioration contenue,
intégrant une approche complète d’orchestration : une démarche qualité reconnue, une méthode
agile Scrum, et une pratique DevOps. [1].
ENIG Page 4
ÉTUDE PRÉALABLE
FIGURE 1.1 – Logo PixiMind [1]
1.2.2 Domaines d’activité et Organigramme hiérarchique de la société
PixiMind se concentre sur la fourniture de :

• L’expertise en développement des solutions web et mobile pour diverses industries afin de
créer des logiciels adaptés pour le contrôle, le test et la maintenance.
• Les services professionnels, prototypage et design pour la fabrication des maquettes qui
répondent ‘à tous les cas d’utilisation possibles.
• Test et validation, ou ils mettent l’accent sur la charte du code source et l’intégration des tests
unitaires dans toute chaine de production.
FIGURE 1.2 – Organigramme hiérarchique de la société
ENIG Page 5
ÉTUDE PRÉALABLE
1.3 Présentation du projet
Nous présentons la problématique et le contexte de notre projet ainsi que les objectifs à
atteindre.
1.3.1 Problématique et contexte du projet
Actuellement, la gestion des employés et de leurs plannings dans la société PixiMind se fait
manuellement avec le logiciel Excel. Celui-ci présente beaucoup de limites. En effet, l’utilisation
d’un programme comme Excel risque également d’augmenter les chances de perdre des fichiers
en les supprimant accidentellement ou suite à une panne système. Un autre problème des feuilles
de calcul qu’elles sont isolées du reste d’organisation, ce qui rend difficile la collaboration. En
fait, le tableur ne permet ni de collaborer, ni de communiquer efficacement entre les membres
d’une équipe car il ne facilite pas les échanges spontanés et les réponses directes et ne favorise
pas les discussions ou le partage d’idées. avec Excel, il est impossible de travailler simultanément.
Chacun doit donc travailler sur son propre tableur, puis les informations doivent être mises en
commun, ce qui engendre une véritable perte de temps et un risque de perdre des données.
Afin de remédier aux différents problèmes cités, la société PixiMind a besoin de réaliser une
application Web qui va automatiser la gestion des employés et de leurs plannings.
1.3.2 Objectifs du projet
Notre projet vise à :

• améliorer la gestion des employés.
• Faciliter aux employés de gérer leurs plannings au sein de l’entreprise.

• Planifier les tâches des salariés.
• Comptabiliser la durée du temps de travail de chaque employé.
• Planifier et partager des événements avec une ou plusieurs personnes

• Mieux suivre l’avancement des employés.
ENIG Page 6
ÉTUDE PRÉALABLE
1.4 Etude de l’existant
L’étude de l’existant constitue une étape fondamentale dans tout projet. Elle consiste à
étudier les solutions existantes dans le marché afin de dégager leurs avantages et leurs inconvénients.
À travers cette étude, nous allons proposer notre solution
1.4.1 Présentation de l’existant
1.4.1.1 Applications existantes portant sur la gestion des taches des employés
Redmine :
Redmine est une application de management de projet en ligne et de partage de ressources. Elle
a été développée par Jean-Philippe Lang et mise sur le marché en 2006. Redmine apporte une
véritable méthodologie au travail collaboratif car il permet de l’organiser et de gérer son suivi.
Les membres du projet peuvent voir un aperçu de qui travaille sur le projet ainsi que son rôle.
Chaque tâche possède un fil de discussion permettant d’enrichir les échanges.
FIGURE 1.3 – Représentation d’une interface du Redmine
ENIG Page 7
ÉTUDE PRÉALABLE
1.4.1.2 Applications existantes portant sur la gestion du temps de travail des employés
Toggl Track :
Toggl Track est un logiciel de suivi de temps développé par la société Toggl basée à Tallinn
en Estonie. Il offre des services de suivi et de rapport de temps en ligne via un site web, des
applications mobiles ou de bureau. Toggl Track permet un suivi de temps en fonction des tâches
et des projets, soit par une minuterie interactive soit par une entrée manuelle de la donnée.
FIGURE 1.4 – Représentation d’une interface du Toggl Track
1.4.1.3 Applications existantes portant sur le partage des événements
Google agenda :
Google agenda est un outil Google permettant d’avoir un agenda en ligne (disponible sur un
ordinateur ou un smartphone) qui peut être partagé ou publié sur un site web. Cet outil permet
de partager un agenda des événements et réunions d’une association, de connaître le planning
des collaborateurs et de mettre en place un planning de réservation de ressources (une salle par
exemple).
ENIG Page 8
ÉTUDE PRÉALABLE
FIGURE 1.5 – Représentation d’une interface du Google agenda
1.4.2 Critique de l’existant
Le tableau récapitule avantages et inconvénients de toutes les applications évoquées.
Avantages Inconvénients
• Open source .
• Compatible avec de nombreux
modules gratuits. • Parfois complexe à

• Possibilité d’ajouter autant de prendre en main.
processus configurables • Un temps de configuration
Redmine
que nécessaire important
• Possibilité de partager certaines • Interface qui pourrait gagnerait en
informations avec des intervenants ergonomie.
externes à l’organisation
(clients, partenaires)
ENIG Page 9
ÉTUDE PRÉALABLE
• La version gratuite de
la solution ne s’appuie pas sur

la gestion des rôles d’utilisateurs.
• Optimisation du temps.
• Un plan de niveau supérieur sur
• facile à utiliser.
Toggl coûte beaucoup plus cher
• Suivi des présences.
que d’autres outils
Toggl Track • Rapport détaillé du temps passé
de suivi du temps en raison de ses
avec export possible.
fonctionnalités supplémentaires.
• aide à la planification des emplois
• absence d’un module
du temps.
d’approbation des feuilles de temps
des employés par le responsable
de la société.
• Le partage de calendrier
• Partager des réunions avec une ou
n’est pas évident à paramétrer,
plusieurs personnes très facilement.
surtout lorsque l’un des participants
• Faire des rappels des rendez-vous
n’a pas d’adresse mail Google.
Google Calendar par mail et ou notification.
• L’agenda est en ligne
• Renouveler un événement de
donc son utilisation est plus
manière hebdomadaire, mensuelle,
contraignante qu’un agenda papier,
annuelle.
sauf si on a un smartphone.
TABLE 1.1 – les avantages et les inconvénients des applications évoquées
1.4.3 Solution Proposée
A la lumière de cette étude, PIXIMIND a pris la décision de mettre en place une solution qui
pallie aux limites des solutions existantes. La solution proposée rassemble diverses fonctionnalités
comme la gestion des taches, de temps de travail des employées ainsi que la planification
et le partage des événements ce qui conduit à un gain de temps considérable ainsi qu’une
ENIG Page 10
ÉTUDE PRÉALABLE
réduction des coûts de l’entreprise. Elle va faciliter aux employés de gérer leurs plannings au
sein de l’entreprise, au chef de projet de contrôler son équipe et à l’administrateur de gérer les
employés.
1.5 Contexte méthodologique du projet
La grande évolution dans le domaine du développement est accompagnée par une évolution
des moyens assurant le bon fonctionnement de ce dernier. D’où l’apparition des méthodes agiles
permettant d’organiser le cycle de développement des projets informatiques. Les méthodes
agiles sont basées sur des principes communs définis dans l’agile Manifesto qui est rédigé
par des experts dans ce domaine. Ils se reposent essentiellement sur une approche itérative
incrémentale et adaptative évoluant en parallèle avec les besoins du client, afin de livrer un
produit de qualité. Il existe plusieurs méthodes agiles, à savoir, la méthode RUP , la méthode
XP et la méthode SCRUM .
1.5.1 Le choix de la Méthode Scrum
Dans la majorité des projets, il est difficile d’anticiper les attentes du client. Ceci nous
oriente vers une approche itérative permettant de s’adapter aux exigences du client au fur et à
mesure de l’avancement du projet. Pour ce faire, nous avons choisi d’adopter la méthode Scrum.
aujourd’hui, Scrum est la méthode agile la plus utilisée. Elle permet de produire une solution
de la plus haute qualité dans des bref délais. Cette méthode est munie des atouts suivants :
. • Meilleur vue d’ensemble du projet : nous avons une vue globale sur l’avancement du projet
par tous les membres des différentes équipes avec un traitement régulier des problémes rencontrés
durant chaque phase.
• Mise à jour des priorités : le client, qui n’est pas nécessairement un informaticien, n’a pas
toujours une vision complète sur le produit final. Pour cela, et grâce à la composition séquentielle
du contenu des sprints, il bénéfice d’une flexibilité au niveau de la définition, de l’évolution des
priorités et des séquences d’activités.
ENIG Page 11
ÉTUDE PRÉALABLE
• Qualité du produit mise en avant : Cette méthode repose sur une évaluation régulière du travail,
ce qui permet un meilleur traitement des problèmes, une meilleure productivité et un produit
satisfaisant.
1.5.2 Rôles et notions
Le cadre méthodologique de Scrum est constitué comme le montre la figure d’une définition
des rôles, un rythme itératif, des artefacts et des réunions précises et limités dans le temps .
FIGURE 1.6 – La méthodologie Scrum
Les rôles :
• Le Product Owner : Il s’agit généralement d’un expert du domaine métier du projet, il travaille
en interaction avec l’équipe de développement en spécifiant les fonctionnalités à développer et
leur priorité.
• L’équipe de développement : Il s’agit généralement d’une équipe de 6 à 10 personnes chargées

de transformer les besoins exprimés par le Product Owner en fonctionnalités utilisables. Les
membres de l’équipe collaborent en apportant chacun son savoir-faire, afin d’accomplir les
tâches.
• Le Scrum Master : Il s’agit généralement d’un chef de projet. Il assure l’application correcte
des principes et des valeurs de Scrum, cherche à faciliter la communication au sein de l’équipe
et auprès du Product Owner et à améliorer la productivité et le savoir-faire de son équipe.
ENIG Page 12
ÉTUDE PRÉALABLE
Le rythme itératif :
• Le Sprint : Le cycle de vie Scrum est rythmé par des itérations ayant une durée de 2 à 4
semaines. C’est la période durant laquelle un incrément du projet est réalisé.
Les artefacts :
• Product Backlog : C’est un référentiel des exigences dressées avec le client que l’équipe doit
réaliser. Cet ensemble de ”User Stories” listé dans le backlog scrum sont classés par priorité
indiquant l’ordre de leur réalisation.
• Sprint Backlog : C’est une sélection des ”User Stories” du backlog produit que l’équipe doit
livrer à la fin du sprint.
Les réunions :
• Planification du Sprint : au cours de cette réunion, l’équipe de d´développement évalue avec le
« Product Owner », les éléments du « Product Backlog » selon leur priorité et choisi les tâches
à effectuer au cours du sprint.
• Mêlée quotidienne : Il s’agit d’une réunion quotidienne de 15 minutes au maximum, au cours
de laquelle l’équipe de développement discute leur avancement dans le projet.
• Revue de Sprint : au cours de cette réunion qui a lieu à la fin du sprint, l’équipe valide le
travail livré en se basant sur les feedbacks du Product Owner, elle anticipe aussi le périmètre
des prochains sprints.
1.6 Conclusion
Au cours de ce chapitre, on a présenté l’organisme d’accueil et on a mis le projet dans

son cadre générale. Le suivi d’une étude comparative des solutions existantes sur le marché, a
permis de déterminer les limites de ces applications. Nous avons également détaillé la méthodologie
agile et le formalisme présentant le processus utilisé pour la mise en place de notre application.
Le chapitre suivant aura pour objet de dégager les acteurs de la solution envisagée, les besoins
fonctionnels et non fonctionnels ainsi nous allons présenter les notions primordiales de la phase
de développement de ce travail.
ENIG Page 13
Chapitre
2
Analyse et spécification des besoins
Sommaire
2.1 INTRODUCTION ....................................................................................... 15
2.2 Spécification des besoins .........................................................................15
2.2.1 Identification des acteurs .................................................................... 15
2.2.2 Besoins fonctionnels ................................................................................. 16
2.2.3 Besoins non fonctionnels .................................................................... 17
2.3 Pilotage du projet avec SCRUM ........................................................... 18
2.3.1 Backlog Produit ................................................................................... 18
2.3.2 Découpage et planification des sprints ............................................... 21
2.4 Conclusion ..................................................................................................... 22
ENIG Page 14
ANALYSE ET SPÉCIFICATION DES BESOINS
2.1 INTRODUCTION
La réussite de tout projet dépend de la qualité de son départ. De ce fait, ce chapitre sera
consacré à l’analyse et la spécification des besoins de notre projet. Nous commencerons par
l’identification des acteurs, ensuite, nous présenterons les besoins fonctionnels et les besoins
non fonctionnels du projet et nous finirons par présenter le backlog product.
2.2 Spécification des besoins
2.2.1 Identification des acteurs
Dans cette section, nous définissons en détails l’ensemble des fonctionnalités offertes par
notre application. Tout d’abord, Nous commençons par l’identification des acteurs. Puis, nous
allons énumérer les différents besoins fonctionnels et non fonctionnels auxquels notre application
doit répondre :
• Administrateur : c’est le responsable de l’administration de notre application. Il a pour

tâche de :
* Gérer les employés
* Gérer les entreprises internes
* Gérer les projets
* Gérer les catégories
* Consulter les statistiques
• Chef de projet :
* Affecter les taches aux membres de projet
* Contrôler l’avancement des membres
ENIG Page 15
* Visualiser les emplois du temps
* Planifier des réunions
• Membre de projet :
* Remplir son emploi du temps
* Diriger son rapport
* Consulter ses tâches et ses réunions
* Partager son temps libre
2.2.2 Besoins fonctionnels
Les besoins fonctionnels sont les fonctionnalités que le système doit fournir à ses utilisateurs.
L’outil n’est considéré opérationnel que s’il garantit la disponibilité de ses fonctionnalités. Dans
ce qui suit, nous repérons les besoins fonctionnels que notre application doit satisfaire :
• Accès sécurisé à l’application avec authentification de l’utilisateur selon son droit d’accès.
• Gestion des Employées.
• Gestion des entreprises internes.
• Gestion des Projets.
• Affectation des Taches aux employés.

• Gestion des catégories.
• Gestion des rapports.
• Gestion des emplois du temps des salariés.
• Partage de temps libre

• Partage et planification des événements.
• Consultation des statistiques
ENIG Page 16
2.2.3 Besoins non fonctionnels
Capacité fonctionnelle
• Exactitude : présenter des résultats précis et juste
• Sécurité : Concerne l’accès non autorisé aux fonctions du logiciel.
La facilité d’utilisation
• Facilité de compréhension : Détermine la facilité avec laquelle les fonctions des systèmes peut
être comprissent et interprétés par l’utilisateur.
• Facilité d’apprentissage : Représente l’effort pour différents utilisateurs (novices, occasionne
ou expert) à apprendre le logiciel.
• Facilité d’exploitation : Représente la capacité du logiciel à être facile à utiliser au quotidien
par un utilisateur donné dans un environnement donné.
Fiabilité
• Facilité d’analyse : Caractérise la capacité d’identifier la cause première d’un échec dans le
logiciel
• Tolérance aux pannes : Capacité du logiciel de fonctionner dans un environnement dégradé
après une erreur.
• Facilité de récupération : Possibilité de ramener à la normal le logiciel (y compris les données

et les connexions réseau) qui a succombé à une erreur.
La performance
• Comportement temporel :Temps de réponse des transactions.
• Utilisation des ressources : Ressources utilisées, à savoir la mémoire, processeur, disque et
l’utilisation du réseau.
Maintenabilité
• Facilité d’analyse : Caractérise la capacité d’identifier la cause première d’un échec dans le
logiciel.
• Facilité de modification : Effort pour effectuer un changement pour adapter le logiciel aux
nouveaux besoins (un plus grand nombre d’utilisation, une utilisation plus intensive)
ENIG Page 17
• Stabilité : Sensibilité aux changements qui pourrait causer des nouvelles défaillances.
• Testabilité : Caractérise l’effort nécessaire pour vérifier un changement.
Portabilité
• Facilité d’adaptation : Capacité à migrer le logiciel (ex : d’un environnement de test vers de
production)
2.3 Pilotage du projet avec SCRUM
Dans cette section, nous présentons les fonctionnalités du backlog product qui seront par la
suite planifiées dans des sprints.
2.3.1 Backlog Produit
Le Backlog product est un recueil des besoins qui peut évoluer au fur et à mesure que le
produit ou le service est développé. Il est composé par des user stories plus ou moins abouties.
Ce n’est pas un document exhaustif, Au contraire, nous pouvons toujours ajouter des détails
descriptifs ou des critères d’acceptation supplémentaires. Avec le Backlog Produit, les intentions
du projet se transforment en commandes explicites. Cette approche fonctionnelle réunit sur des
fiches tout ce que doit savoir l’équipe agile :
• Les besoins.
• Les améliorations.
• Les correctifs à apporter.
La rédaction d’une user story rend le besoin utilisateur simple et compréhensible. Cette phrase
doit seulement contenir trois éléments descriptifs : Qui ? Quoi ? Pourquoi ?

• Le contexte → En tant que « rôle »
• La fonction → je veux « fonctionnalité »
• Le bénéfice → afin de (pour) « raison / objectif »
Et en tant que qualité de coach agile, on inspecte les user stories et les tâches grâce aux
grilles de critères INVEST et SMART. La grille des critères INVEST permet de motiver les
ENIG Page 18
membres de l’équipe à modifier ou à mieux reformuler l’énoncé d’une user story. Une bonne
user story est :
• Independent → pas de dépendance entre les user stories.

• Négociable → la user story peut être arbitrée par le client et l’équipe.
• Valuable → un besoin est toujours associé à la user story.

• Estimable → l’équipe doit être en capacité d’estimer l’user story.
• Small → la user story est décrite précisément.
• Testable → les critères d’acceptation de user story sont atteignables.
Nous pouvons ainsi évaluer la pertinence des tâches avec la grille de critères SMART :
• Specific → toute votre équipe comprend ce qu’il y a à faire.
• Mesurable → votre équipe sait comment s’assurer que la tâche est réalisée.
• Achievable → votre équipe dispose de tous les moyens pour réaliser la tâche.
• Relevant → la tâche participe bien à la concrétisation de la user story.
• Time Bound → la tâche a une durée connue et limitée de travail.

Pour bien gérer notre projet et atteindre les objectifs associés, il est impératif de prioriser les
points à traiter, les tâches à mener, les solutions à appliquer dans un espace temps déterminé...
Prises dans les approches logiques, la méthode MoSCoW est un outil pratique et très simple à
mettre en oeuvre pour fixer les priorités. Cette méthode est utilisé pour classer les exigences
d’un projet en fonction de leur degré de criticité. L’idée est d’aller au-delà d’une classifi-
cation plus ou moins binaire reposant sur l’importance, afin de mieux comprendre pourquoi
choisir tel ou tel élément plutôt qu’un autre. Utilisée par les projets Agile, originellement avec
la méthodologie DSDM (Dynamique Systems Developpement Method ), MoSCoW facilite la
prise de décision . Les lettres majuscules de l’acronyme MoSCoW signifient (en anglais) :
M- Must have this : Il s’agit véritablement des points critiques, pas de question à se poser, ils
doivent être traités en priorité. Dans le cas contraire, le succès du projet en souffrira et mènera
à son échec. Ces exigences sont non négociables.
S- Should have this if at all possible : : ces points apportent une vraie valeur ajoutée et/ou leur
importance contribue à l’atteinte des objectifs. La différence avec les Must Have réside souvent
dans le fait que leur traitement peut être différé dans le temps après celui des points prioritaires.
ENIG Page 19
Dans ce cas, leur classement est assimilable à la case "Important mais non urgent " de la matrice
importance-urgence. Et doivent ainsi être traités dans la mesure du possible.
C- Could have this if it does not affect anything else : c’est bien de les avoir, peuvent être
retirés des priorités si des choix doivent être faits. Généralement, ils font partie des "petits plus"
qui contribuent à la satisfaction client pour un coût très modéré. Des exigences additionnelles
de confort.
W- Won’t have this time but would like in the future : Ils sont exclus du projet, mais font
partie des points qui restent dans les cartons pour un traitement ou une intégration ultérieure.
ID En tant que ... je veux ... Afin de ... Priorité

avoir mes privilèges
m’authentifier sur
1 utilisateur en fonction de mon M
mon compte
rôle dans l’application.
Ajouter, modifier, supprimer

2 administrateur gérer les employés M
et consulter la liste des employés.

3 administrateur gérer les entreprises M
et consulter la liste des entreprises.

4 administrateur gérer les projets M
et consulter la liste des projets.

5 administrateur gérer les catégories M
et consulter la liste des catégories.
Avoir une idée de l’avancement

6 administrateur Visualiser les rapports et des problèmes vécus par S
les collaborateurs.
Visualiser les emplois Surveiller les heures

7 administrateur S
du temps. de travail des employés.
Modifier, supprimer
8 Chef de projet Gérer les tâches M
et affecter des tâches aux employés.
ENIG Page 20
Planifier des Discuter avec les

9 Chef de projet M
événements membres du projet
Donner au superviseur
Remplir emploi du une idée claire de ce

10 Membre de projet M
temps qui se passera au cours
de la journée.
Partager temps Mon superviseur puisse

11 Membre de projet C
libre fixer des événements.
Informer le superviseur
12 Membre de projet Rédiger son rapport de l’avancement et S
des difficultés rencontrées.
TABLE 2.1 – Backlog produit
2.3.2 Découpage et planification des sprints
Après la détermination du backlog product, nous le découpons en neuf sprints. Chaque

sprint s’intéresse à réaliser certaines user stories tout en précisant sa durée prévisionnelle. Le
tableau montre la planification des sprints du projet.
Sprint 1 2 3 4 5 6 7 8 9
User Strory 1 2 3 4 8 5 7,10 9,11 6,12
Période en semaine 2 2 2 2 2 2 2 2 2
TABLE 2.2 – Découpage des sprints
Une fois que nous avons identifié le backlog product, nous avons mis en place une réunion de
planification. Le but de cette réunion est de créer des backlogs de sprint basés sur le backlog
product tout en tenant compte de la priorité, de la complexité et des valeurs ajoutées des user
stories dans l’application. A l’issue de la réunion, nous avons déterminé la durée estimée des
travaux à effectuer lors de chaque sprint. Pour ce fait nous avons développé notre projet en trois
releases. Chaque release est constituée par trois sprints
ENIG Page 21
FIGURE 2.1 – Planification du projet
2.4 Conclusion
Durant ce chapitre, nous avons définit les acteurs et leurs rôles, les besoins fonctionnels et
non fonctionnels de notre application. Nous avons planifié notre projet selon la méthodologie
adoptée ainsi que la présentation de backlog product et les sprints réalisés. Dans le chapitre
suivant nous passons au développement de la première release
ENIG Page 22
Chapitre
3
Release 1 : Gestion des données de base
Sommaire
3.1 Introduction.................................................................................................. 24
3.2 Planification.................................................................................................. 24
3.3 Sprint 1 : S’authentifier ........................................................................... 24
3.3.1 Backlog sprint...................................................................................... 24
3.3.2 Analyse des besoins .................................................................................. 25
3.3.3 Conception ................................................................................................ 26
3.4 Sprint 2 :Intégration du module Employé ...................................... 28
3.4.1 Backlog sprint...................................................................................... 28
3.4.3 Conception ................................................................................................ 29
3.5 Sprint 3 :Intégration du module Entreprise .................................. 31
3.5.1 Backlog sprint...................................................................................... 31
3.5.3 Conception ................................................................................................ 33
3.6 Conclusion ..................................................................................................... 35
ENIG Page 23
RELEASE 1 : GESTION DES DONNÉES DE BASE
3.1 Introduction
Une release présente une période pendant laquelle un produit sera livré. Elle est composée
par une suite de sprints successifs. Ce chapitre vise le traitement de notre premier release qui
est composé de trois sprints, chacun ayant une période bien déterminée.
3.2 Planification
Le premier release est constituée par trois sprints exprimés dans la figure 3.1
FIGURE 3.1 – Planification du release 1
3.3 Sprint 1 : S’authentifier
Le but de ce sprint est d’implémenter la partie authentification. Nous spécifions les tâches
utilisateurs incluses dans ce sprint à partir du backlog de sprint. Ensuite, nous continuons à
analyser, concevoir et traiter ce sprint.
3.3.1 Backlog sprint
Le backlog de sprint est un ensemble des scénarios identifiés par l’équipe Scrum à exécuter
pendant le sprint.
ENIG Page 24
User story Tâche
Préparer les parties front et back de l’authentification

S’authentifier
de tous les utilisateurs de l’application
TABLE 3.1 – Backlog sprint "S’authentifier"
3.3.2 Analyse des besoins
La partie analyse des besoins d’un sprint se décrit par le diagramme de cas d’utilisation de
ce sprint ainsi leur description textuelle.
3.3.2.1 Diagramme de cas d’utilisation
Le diagramme de cas d’utilisation représente un ensemble des actions qu’un acteur peut
réaliser ou accomplir en interaction avec les différents acteurs du système. Le diagramme de
cas d’utilisation du premier sprint est exprimé dans la figure 3.2 :
FIGURE 3.2 – Diagramme de cas d’utilisation de sprint authentification
3.3.2.2 Description textuelle
Pour mieux lire notre diagramme des cas d’utilisation, les concepteurs d’UML proposent
une technique qui sert à décrire le comportement du système informatique appelé la description
textuelle. De ce fait, nous allons présenter les descriptions textuelles de nos cas d’utilisation via
le tableau ci-dessous.
ENIG Page 25
Cas d’utilisation S’authentifier
Objectif Ce cas d’utilisation permet à l’utilisateur de se connecter à l’application.
acteur Tout les utilisateurs
Pré-condition l’utilisateur est enregistré dans la base de donnée
1. L’utilisateur ouvre la page d’authentification.
2. Le système lui affiche le formulaire d’authentification.

Scénario nominal 3. L’utilisateur remplit le formulaire puis il confirme.
4. Le système vérifie les données saisit et affiche l’interface réservée
à l’utilisateur.
Scénario alternatif Si un des données n’est pas correctes, on se reprend à l’étape 3.
Post-condition Utilisateur authentifié
TABLE 3.2 – Description Textuelle : "S’authentifier"
3.3.3 Conception
3.3.3.1 Diagramme de séquence
Le diagramme de séquence est une représentation dynamique des différents scénarios qui
s’exécutent entre les objets de l’application selon un point de vue temporel. On présente dans
la figure 3.3 le diagramme de séquence pour le cas d’utilisation "S’authentifier".
Diagramme de séquence de cas d’utilisation "s’authentifier" :
ENIG Page 26
FIGURE 3.3 – Diagramme de séquence de cas d’utilisation "S’authentifier "
3.3.3.2 Diagramme de classe
Un diagramme de classe produit une version logique du système à travers une représentation
statistique des différentes classes nécessaires pour l’application avec les relations entre ces
dernières (association, généralisation, agrégation...). Le diagramme est composé de deux classes
(Employé, Compte).
La figure 3.4 présente le diagramme de classe dans ce sprint.
FIGURE 3.4 – Diagramme de classe de sprint "S’authentifier"
ENIG Page 27
3.4 Sprint 2 :Intégration du module Employé
Le tableau 3.3 présente le backlog du sprint "Intégration du module Employé"
User story Tâche
Intégration du module Préparer les API et les interfaces nécessaires
Employé pour que l’administrateur puisse gérer les employés.
TABLE 3.3 – Backlog sprint "Intégration de du module Employé"
La figure 3.5 présente le diagramme des cas d’utilisations détaillé du sprint 2 :
FIGURE 3.5 – Diagramme de cas d’utilisation du sprint "Intégration du module Employé"
La description textuelle de cas d’utilisation"Gérer les utilisateurs " est présentée dans le
tableau suivant :
ENIG Page 28
Cas d’utilisation Gérer les employés
Objectif Ce cas d’utilisation permet à l’administrateur de gérer les employés.
acteur administrateur
Pré-condition L’administrateur est authentifié et connecté à l’application
1. L’administrateur accède au tableau du bord des employés
pour avoir la liste des employés.
2. L’administrateur peut ajouter un employé en lui attribuant l’un des
Scénario nominal rôles suivants : « admin », « team lead » ou « developer ».

3. L’administrateur peut supprimer et modifier les employés.
Il peut aussi visualiser les détails de chacun d’eux.
4. La mise à jour est effectué par le back-end de l’application
Erreur lorsque l’administrateur oublie de saisir l’un des champs

Scénario alternatif
obligatoires.
Post-condition Employé ajouté / modifié / supprimé.
TABLE 3.4 – Description textuelle du cas d’utilisation :"Gérer les employés "
3.4.3 Conception
L’administrateur pourrait ajouter un à plusieurs scénarios dans notre application. La figure 3.6
présente le diagramme de séquence pour les cas d’utilisation « ajouter Employé », « supprimer
Employé » et « visualiser les détails de l’employé ».
ENIG Page 29
FIGURE 3.6 – Diagramme de séquence de cas d’utilisation : "gérée employé"
Le diagramme de classe du cas d’utilisation "ajouter un nouveau employé" est exprimés dans la
figure 3.7 .
ENIG Page 30
FIGURE 3.7 – Diagramme de classe de sprint "Intégration de module Employé"
3.5 Sprint 3 :Intégration du module Entreprise
Le tableau 3.5 présente le backlog du sprint "Intégration de l’entité équipe"
User story Tâche
Préparer les API et les interfaces nécessaires pour que l’administrateur

Intégration de l’entité Entreprise
puisse gérer les entreprises.
TABLE 3.5 – Backlog sprint "Intégration du module Entreprise"
ENIG Page 31
FIGURE 3.8 – Diagramme de cas d’utilisation du sprint 3
Le tableau suivant présente la description textuelle de cas d’utilisation « Gérer les entreprises ».
Cas d’utilisation Gérer les entreprises
Objectif Ce cas d’utilisation permet à l’administrateur de gérer les entreprises.
Pré-condition L’utilisateur est authentifié et connecté à l’application
1. L’administrateur accède au tableau du bord des entreprises
pour avoir la liste des entreprises.

2. L’administrateur peut ajouter, supprimer et modifier les entreprises.
Scénario nominal
Il peut aussi ajouter des employés à l’entreprise.
3. L’administrateur choisit l’action à faire et la valide.
4. La mise à jour est effectuée par le back-end de l’application.
Scénario alternatif Erreur lorsque l’administrateur oublie de saisir l’un des champs .
Post-condition Entreprise ajoutée / modifiée / supprimée.
TABLE 3.6 – Description textuelle du cas d’utilisation « Gérer les entreprises »
ENIG Page 32
Le tableau présente la description textuelle de cas d’utilisation « Visualiser ses détails ».

Cas d’utilisation Gérer les entreprises
Objectif Ce cas d’utilisation permet à l’administrateur de gérer les entreprises.
1. L’administrateur accède au tableau du bord des entreprises
pour avoir la liste des entreprises.
2. L’administrateur peut ajouter, supprimer et modifier les entreprises.

Scénario ominal
Il peut aussi ajouter des employés à l’entreprise.
Post-condition Entreprise ajoutée / modifiée / supprimée.
TABLE 3.7 – Description textuelle du cas d’utilisation « Visualiser ses détails »
3.5.3 Conception
La figure 3.9 présente le diagramme de séquence pour les cas d’utilisation « Supprimer
Entreprise », « ajouter les membres à l’entreprise » et « Modifier entreprise ».
ENIG Page 33
FIGURE 3.9 – Diagramme de séquence de cas d’utilisation : "Intégration entité Companie"
La figure 3.10 présente le diagramme de classes de sprint 3 qui se compose de deux classes
(Entreprise et Employé) et d’une classe d’association (Détail). Une classe d’association est
une classe à la jonction de deux autres classes. Elle porte des informations, que l’on appelle
« attributs », qui sont en dépendance directe des deux autres classes et qui ne pourraient se
mettre ni dans l’une, ni dans l’autre.
ENIG Page 34
FIGURE 3.10 – Diagramme de classe de sprint 3
3.6 Conclusion
Dans ce chapitre, nous avons délivré le premier release de notre projet avec lequel nous avons
intégré les 3 sprints : « L’authentification des différents utilisateurs », « La gestion des employés
» et « La gestion des entreprises ». Il nous manque les phases de mise en place des procédures
de travail et l’implémentation des outils de supervision qui seront étudiés dans les chapitres
suivants.
ENIG Page 35
Chapitre
4
Release 2 : Mise en place des
procédures de travail
Sommaire
4.1 Introduction.................................................................................................. 37
4.2 Planification.................................................................................................. 37
4.3 Sprint 4 :Intégration du module projet ........................................... 37
4.3.1 Backlog sprint...................................................................................... 37
4.3.3 Conception ................................................................................................ 39
4.4 Sprint 5 : Intégration du module tâches ......................................... 40
4.4.1 Backlog sprint...................................................................................... 40
4.4.3 Conception ................................................................................................ 42
4.5 Sprint 6 : Intégration du module catégorie .................................... 44
4.5.1 Backlog sprint...................................................................................... 44
4.5.3 Conception ................................................................................................ 46
4.6 Conclusion ..................................................................................................... 46
ENIG Page 36
RELEASE 2 : MISE EN PLACE DES PROCÉDURES DE TRAVAIL
4.1 Introduction
Après avoir terminé le premier release de notre application, nous pouvons commencer le
traitement nécessaire pour réaliser le deuxième release. Dans ce chapitre, nous présenterons les
trois sprints « Intégration du module projet », « Intégration du module tache » et « Intégration
du module catégorie » tout en détaillant le backlog de chaque sprint et la partie conception. .
4.2 Planification
Le second release est composé de trois sprints, définit dans la figure suivante :
4.3 Sprint 4 :Intégration du module projet
Le tableau 4.1 présente le backlog du sprint "Intégration du module projet"
User story Tâche
Intégration du module Préparer les API et les interfaces nécessaires pour que
projet l’administrateur puisse gérer les projets.
TABLE 4.1 – Backlog sprint "Intégration du module projet"
ENIG Page 37
FIGURE 4.2 – Diagramme de cas d’utilisation du sprint "Intégration du module projet"
La description textuelle de cas d’utilisation "Intégration du module projet" est présentée

dans le tableau suivant :
Cas d’utilisation Intégration du module projet
Objectif Ce cas d’utilisation permet à l’administrateur de gérer les projets.
Acteur Administrateur
1. L’administrateur accède au tableau du bord des projets
pour avoir la liste des projets.
2. L’administrateur peut ajouter, supprimer et modifier les projets.

Scénario nomianl
Il peut aussi affecter les employés au projet.
4. La mise à jour est effectuée par le back-end de l’application
Post-condition Scénario ajouté / modifié / supprimé.
TABLE 4.2 – Description textuelle du cas d’utilisation :"Intégration du module projet"
ENIG Page 38
4.3.3 Conception
La figure 4.3 présente le diagramme de séquence pour les cas d’utilisation « Ajouter projet » et
« Assigner des membres au projet ».
FIGURE 4.3 – Diagramme de séquence de cas d’utilisation : « Ajouter projet » et « Assigner des
membres au projet »
La figure 4.4 présente le diagramme de classe de sprint 4 qui se compose de trois classes
(Entreprise, Employé et Projet) , d’une classe d’association (Poste) et de quatre classes qui
ENIG Page 39
héritent de cette classe associative. Pour chaque projet, on assigne le product owner, le scrum
master, le team lead et le dev team parmi les employés de l’entreprise à laquelle le projet
appartient.
4.4 Sprint 5 : Intégration du module tâches
Le tableau 4.3 présente le backlog du sprint "Intégration du module tâches "
User story Tâche
Préparer les API et les interfaces nécessaires pour que

Gérer les tâches
le chef de projet puisse gérer les tâches.
Préparer les API et les interfaces nécessaires afin que

Consultation des tâches l’employé puisse consulter la liste des tâches qui
lui sont attribuées..
TABLE 4.3 – Backlog sprint " Intégration du module tâches "
4.4.2.1 Diagramme des cas d’utilisation
La figure présente le diagramme des cas d’utilisation détaillé du sprint 5 :
ENIG Page 40
FIGURE 4.5 – Diagramme des cas d’utilisation du sprint 5
4.4.2.2 Description Textuelle
Le tableau présente la description textuelle de cas d’utilisation « Gérer les tâches ».
Cas d’utilisation Gérer les tâches
Objectif Ce cas d’utilisation permet au chef de projet de gérer les tâches.
Acteur chef de projet
1.L’utilisateur accède à l’interface des tâches pour avoir la liste des tâches
assignées et crées.
Scénario nominal 2 L’utilisateur peut affecter des tâches à des employés, les supprimer et les modifier
3.L’utilisateur choisit l’action à faire et la valide.
4.La mise à jour est effectuée par le back-end de l’application
Scénario alternatif Un message d’erreur est sorti lorsqu’il y a un manque des options sur les flux
Post-condition Tâche crée /assignée / modifiée / supprimée.
TABLE 4.4 – Description textuelle du cas d’utilisation « Gérer les tâches »
ENIG Page 41
Le tableau présente la description textuelle de cas d’utilisation « Consulter ses tâches ».

Cas d’utilisation Consulter ses tâches
Objectif Ce cas d’utilisation permet aux employés de visualiser ses tâches
Acteur membre de projet
1.L’employé accède à l’interface des tâches pour obtenir une liste de ses tâches.
Scénario nominal 2 L’employé peut modifier seulement les champs de « work hour » et « progress »
3.La mise à jour est effectué par le back-end de l’application
Scénario alternatif L’employé n’est assigné à aucune tâche.
Post-condition Tâches visualisées/ modifiées.
TABLE 4.5 – Description textuelle du cas d’utilisation « Consulter ses tâches »
4.4.3 Conception
La figure 4.6 présente le diagramme d’état de transition pour les cas d’utilisation « suivie
tâches»
ENIG Page 42
FIGURE 4.6 – Diagramme d’état de transition de l’objet « tache »
La figure 4.7 présente le diagramme de classes de sprint 5 qui se compose de trois classes
(Projet, Employé et Tache).
ENIG Page 43
4.5 Sprint 6 : Intégration du module catégorie
User story Tâche
Préparer les API et les interfaces nécessaires

Intégration du module catégorie
pour que l’administrateur puisse gérer les catégories.
TABLE 4.6 – Backlog sprint :Gestion des état des utilisateurs
ENIG Page 44
FIGURE 4.8 – Diagramme cas d’utilisation du sprint 6
4.5.2.2 Description Textuelle du cas d’utilisation
Le tableau présente la description textuelle du cas d’utilisation « Gérer les catégories ».

Cas d’utilisation Gérer les catégories
Objectif Ce cas d’utilisation permet à l’administrateur de gérer les catégories.
Acteur Administrateur
1. L’administrateur accède au tableau du bord des catégories
pour avoir la liste des catégories. .
2. L’administrateur peut ajouter une catégorie en lui attribuant l’un des types
suivants : « sous-catégorie », « tâche » ou « saisie libre ».

Scénario nominal
3. L’administrateur peut supprimer et modifier les catégories.
Il peut aussi visualiser les sous catégories.

Post-condition Catégorie ajoutée / modifiée / supprimée.
TABLE 4.7 – Description textuelle du cas d’utilisation « Gérer les catégories »
ENIG Page 45
4.5.3 Conception
La figure 4.9 présente le diagramme de classes de sprint 6 qui se compose de deux classes
(Catégorie et Tache).
FIGURE 4.9 – Diagramme de classe de cas d’utilisation "gérer catégorie"
4.6 Conclusion
Dans ce chapitre, nous avons délivré le deuxième release de notre projet avec lequel nous avons
intégré les trois sprints : « intégration du module projet », « intégration du module tache »
et « La gestion des catégories ». Il nous manque la phase de l’implémentation des outils de
supervision qui sera étudié dans le chapitre suivant qui sera réserver pour la troisième release.
ENIG Page 46
Chapitre
5
Release 3 :Implémentation des outils
de supervision
Sommaire
5.1 Introduction..................................................................................................48
5.2 Planification..................................................................................................48
5.3 Sprint 7 :Intégration du module emploi du temps ......................48
5.3.1 Backlog sprint...................................................................................... 48
5.3.3 Conception ................................................................................................ 51
5.4 Sprint 8 : Intégration du module calendrier ................................. 52
5.4.1 Backlog sprint...................................................................................... 52
5.4.3 Conception ................................................................................................ 54
5.5 Sprint 9 : Intégration des modules rapport et statistique ......... 56
5.5.1 Backlog sprint...................................................................................... 56
5.5.3 Conception ................................................................................................ 58
5.6 Conclusion ..................................................................................................... 58
ENIG Page 47
RELEASE 3 :IMPLÉMENTATION DES OUTILS DE SUPERVISION
5.1 Introduction
Après avoir terminé le premier et le deuxième release de notre application, nous pouvons
commencer le traitement nécessaire pour réaliser le troisième release. Dans ce chapitre, nous
présenterons les trois sprints « Intégration du module emploi du temps », « Intégration du
module calendrier » et « Intégration des modules rapport et statistique » tout en détaillant le
backlog de chaque sprint et la partie conception.
5.2 Planification
La troisième release est constituée de trois sprints exprimés dans la figure 5.1
5.3 Sprint 7 :Intégration du module emploi du temps
Le tableau 5.1 présente le backlog du sprint "Intégration du module emploi du temps"
ENIG Page 48
User story Tâche
Remplir l’emploi Préparer les API et les interfaces nécessaires pour
du temps que l’employé puisse remplir son emploi du temps.
Visualiser les emplois du temps Préparer les interfaces nécessaires pour que l’administrateur
des employés puisse consulter les horaires des employés.
TABLE 5.1 – Backlog sprint " Intégration du module emploi du temps "
La figure 5.2 présente le diagramme des cas d’utilisation détaillé du sprint 7 :
Le tableau suivant présente la description textuelle de cas d’utilisation « Remplir son emploi
du temps».
ENIG Page 49
Cas d’utilisation Remplir son emploi du temps
Objectif Ce cas d’utilisation permet à l’employé de s’occuper de son emploi du temps.
acteur Employé
Pré-condition L’employé est authentifié et connecté à l’application
1. L’employé accède à son emploi du temps.
2. L’employé peut ajouter une ligne tout en sélectionnant la catégorie
correspondant à celle-ci.
Scénario nominal 3. L’employé choisit l’action à faire et la valide.
4. La mise à jour est effectué par le back-end de l’application.
5.le système calcule automatiquement les « Logged Hours »,
« Work Hours » et « Total Break » depuis les lignes entrées par l’employé.
Scénario alternatif Erreur lorsque l’employé oublie de saisir l’un des champs
Post-condition Ligne ajoutée / supprimée.
TABLE 5.2 – Description textuelle du cas d’utilisation « Remplir son emploi du temps »
Le tableau suivant présente la description textuelle de cas d’utilisation « Visualiser emplois du

temps ».
Cas d’utilisation Visualiser emplois du temps
Objectif permet à l’administrateur de consulter les emplois du temps des employés.
1. L’administrateur accède à l’interface des employés pour voir leurs plannings.
2. clique sur l’icône « Détail » puis sur le bouton « Last Time Sheet ».
Scénario nominal
3. Le système lui dirige vers le dernier emploi du temps de chaque employé.
4. clique sur le bouton « Time Sheet » affiche tous les plannings de chaque employé
Scénario alternatif L’employé n’a pas rempli son emploi du temps.
Post-condition Plannings visualisés.
TABLE 5.3 – Description textuelle du cas d’utilisation « Visualiser emploi du temps »
ENIG Page 50
5.3.3 Conception
La figure 4.3 présente le diagramme de séquence pour les cas d’utilisation « ajouter projet » et
« assigner des membres au projet ».
FIGURE 5.3 – Diagramme de séquence d’ajout d’une ligne dans un "time sheet"
La figure 5.4 présente le diagramme de classes de sprint 7 qui se compose de quatre classes
(Emploi du jour, Employé, catégorie et ligne). :
ENIG Page 51
5.4 Sprint 8 : Intégration du module calendrier
Le tableau 5.4 présente le backlog du sprint "Intégration du module calendrier "
User story Tâche
Préparer les API et les interfaces nécessaires pour

Planifier des événements que l’administrateur et le chef de projet puissent
organiser des événements avec les employés.
Préparer les API pour permettre au membre du projet

Partager le temps libre
de partager son temps libre..
TABLE 5.4 – Backlog sprint " Intégration du module calendrier "
ENIG Page 52
5.4.2.2 Description Textuelle
Le tableau présente la description textuelle de cas d’utilisation « Partager son temps libre ».
Cas d’utilisation Partager son temps libre
Objectif Ce cas d’utilisation permet au membre du projet de partager son temps libre.
acteurs Membre du projet
Pré-condition Le membre du projet est authentifié et connecté à l’application
1Le membre du projet accède à son calendrier.

2. Le membre du projet clique sur l’icône de partage pour partager son temps
Scénario nominal
libre avec les membres concernés.
3.La mise à jour est effectué par le back-end de l’application.
Scénario alternatif Erreur lorsque le membre du projet oublie de saisir l’un des champs.
Post-condition Temps libre partagé.
TABLE 5.5 – Description textuelle du cas d’utilisation « Partager son temps libre »
ENIG Page 53
Le tableau présente la description textuelle de cas d’utilisation « Planifier des événements ».

Cas d’utilisation Planifier des événements
Objectif Ce cas d’utilisation permet à l’utilisateur de programmer des événements
acteur administrateur / chef de projet
1. L’utilisateur accède à son calendrier.
2. L’utilisateur consulte l’icône « Détail » pour voir le temps libre des employés.
3.L’utilisateur appuie sur l’icône d’ajout pour planifier un événement

Scénario nominal
qui le partage avec les membres concernés.
4.La mise à jour est effectuée par le back-end de l’application.
5.Le système affiche l’événement à tous les participants.
Scénario alternatif Erreur lorsque l’utilisateur oublie de saisir l’un des champs
Post-condition Evénement planifié.
TABLE 5.6 – Description textuelle du cas d’utilisation « Planifier des événements »
5.4.3 Conception
5.4.3.1 Diagramme d’activité
La figure 5.6 présente le diagramme d’activité pour les cas d’utilisation « planification d’une
réunion ».
ENIG Page 54
FIGURE 5.6 – Diagramme d’activité pour le process « planification d’une réunion »
La figure 5.7 présente le diagramme de classes de sprint 8.
ENIG Page 55
5.5 Sprint 9 : Intégration des modules rapport et statistique
Le tableau 5.7 présente le backlog du sprint "Intégration du module rapport et statistique "
User story Tâche
Préparer les API et les interfaces nécessaires pour

Rédiger son rapport
que le membre du projet puisse écrire son rapport.
Préparer les API pour permettre à l’administrateur

Visualiser les rapports
de voir la liste des rapports.
Préparer l’interface pour permettre à l’administrateur

Consulter les statistiques
de consulter les statistiques.
TABLE 5.7 – Backlog sprint " Intégration du module rapport et statistique"
ENIG Page 56
5.5.2.2 Description Textuelle du cas d’utilisation
Le tableau présente la description textuelle de cas d’utilisation « Rédiger son rapport ».

Cas d’utilisation Rédiger rapport
Objectif Ce cas d’utilisation permet au membre du projet de rédiger son rapport.
acteur Membre du projet
Pré-condition Le membre du projet est authentifié et connecté à l’application
1. Le membre du projet accède à l’interface des rapports. .
2. Le membre de projet peut ajouter un rapport tout en choisissant
la société et le projet correspondant.

Scénario nominal 3. L’employé peut supprimer ses rapports. Il peut aussi visualiser
la liste de ses rapports.

4. L’employé choisit l’action à faire et la valide..
Post-condition Catégorie ajoutée / modifiée / supprimée.
TABLE 5.8 – Description textuelle du cas d’utilisation « Gérer les catégories »
ENIG Page 57
5.5.3 Conception
La figure 5.9 présente le diagramme de classe de sprint 9 :
5.6 Conclusion
Dans ce chapitre, nous avons délivré le troisième release de notre projet avec lequel nous avons
intégré les trois sprints : « intégration du module emploi du temps», « intégration du module
calendrier » et « La gestion des rapports ». Il nous manque la phase de réalisation qui sera
étudiée dans le chapitre suivant.
ENIG Page 58
Chapitre
6
Réalisation
Sommaire
6.1 Introduction................................................................................................. 60
6.2 Architecture et technologies utilisées .............................................. 60
6.2.1 Architecture de l’application ............................................................... 60
6.2.2 Architecture physique.......................................................................... 63
6.2.3 Architecture logique ............................................................................ 64
6.3 Aspet technique........................................................................................... 66
6.3.1 Technologie du frontend ..................................................................... 66
6.3.2 Technologie du backend .................................................................... 68
6.3.3 Base de données ................................................................................. 70
6.4 Présentation de l’environnement ........................................................ 70
6.4.1 Environnement matériel ..................................................................... 71
6.4.2 Environnement matériel ..................................................................... 71
6.5 Diagramme de déploiement .................................................................. 74
6.5.1 Définition .................................................................................................. 74
6.5.2 Éléments d’un diagramme de déploiement ........................................ 74
6.5.3 Diagramme de déploiement système .................................................. 74
6.6 Réalisation ..................................................................................................... 75
6.7 Conclusion .................................................................................................... 80
ENIG Page 59
RÉALISATION
6.1 Introduction
Le chapitre réalisation expose la derniere étape de notre projet. Dans ce chapitre, nous
décrivons l’architecture de notre application ainsi que l’environnement et les outils necessaire
qui facilite la réalisation de notre projet. Ensuite, nous définissons le diagramme de déploiement
et nous terminerons par la présentation des différents interfaces de notre application.
6.2 Architecture et technologies utilisées
6.2.1 Architecture de l’application
6.2.1.1 Étude comparative des architectures
Afin de choisir l’architecture la plus compatible pour notre projet, nous avons réalisé une
étude comparative, illustrée par le tableau 6.1, entre les trois architectures les plus connues.
SOAP REST GraphQL
XML, JSON, HTML,

Formats XML JSON
YaML, autres
URL de point de Données représentées Le client définit les
Principe de terminaison unique sous forme de données de réponse
fonctionnement pour récupérer/modifier ressources dans les dont il a besoin via un
des données. réponses HTTP langage de requête.
Formatage flexible
Données de requête
avantages Bien établi et bien des données basé
flexibles
connu sur des entités
Point de terminaison de
requête de données Poids léger Poids léger
unique
ENIG Page 60
RÉALISATION
Différents types de Récupération de

Typage de données fort
formats données efficace
Transfert sur de
nombreux Typage de données
Sans état
protocoles (HTTP, fort
SMTP, FTP)
Sur / sous extraction Sur / sous extraction

Mise en cache
de données de données
Plusieurs requêtes
Inconvénients Inefficient Manque de versioning
HTTP
Schéma de données
Verbose : afficher
compatible avec
explicitement toutes Validation de type
la structure de
les opérations effectuées
données graphique
Fait plusieurs
HaTEOaS n’est pas
demandes/réponses
pleinement utilisé
Mise en cache distinctes pour chaque
-implémentation
appel de point de
complexe
terminaison.
TABLE 6.1 – Comparaison entre SOAP, REST et GraphQL
Comme le montre le tableau de comparaison, chaque architecture a ses forces et ses

faiblesses. Mais nous avons préféré travailler avec l’architecture API REST en raison de sa
flexibilité par rapport au protocole SOAP, sa simplicité et sa facilité de gestion des erreurs par
rapport à l’architecture GraphQL.
6.2.1.2 Explication de l’architecture REST API
Nous avons proposé de suivre l’architecture api REST. Mais avant d’expliquer cette
architecture on doit tout d’abord définir le terme API.
ENIG Page 61
RÉALISATION
API (Interface de Programmation d’application) : est un ensemble normalisé de classes, de

méthodes, de fonctions et de constantes qui sert de façade par laquelle un logiciel offre des
services à d’autres logiciels. Elle est offerte par une bibliothèque logicielle ou un service
web, le plus souvent accompagnée d’une description qui spécifie comment des programmes
consommateurs peuvent se servir des fonctionnalités du programme fournisseur [5]. La mise en
place d’une aPI permet d’opérer une séparation des responsabilités entre le client et le serveur.
Cette séparation permet donc une probabilité et une évolutivité grandement améliorées. Chaque
composant peut évoluer séparément car il n’y a aucune logique du côté du serveur. ainsi on peut
imaginer une refonte totale de la charte graphique du site web sans devoir modifier le code côté
serveur ou sur les autres clients (mobiles par exemple).
REST (Representational State Transfer) ou RESTful est un style d’architecture permettant

de construire des applications (Web, Intranet, Web Service). Il s’agit d’un ensemble de
conventions et de bonnes pratiques à respecter et non d’une technologie à part entière.
L’architecture REST utilise les spécifications originelles du protocole HTTP, plutôt que de
réinventer une surcouche (comme le font SOaP ou XML-RPC par exemple).
La figure 6.1 présente l’architecture du REST aPI, dans laquelle, les client ou les
consommateurs de service envoient des requêtes HTTP au serveur qui utilise l’architecture
REST, tout en spécifiant le type d’opération en utilisant les verbes HTTP correspondants :
• Créer (create) => POST

• afficher (read) => GET
• Mettre à jour (update) => PUT ou PaTCH
• Supprimer (delete) => DELETE
Le serveur effectue l’opération demandé en accédant à la base de données puis il retourne une
réponse sous forme d’une représentation de ressource dans des formats divers ( en générale
JSON ou XML)
ENIG Page 62
RÉALISATION
FIGURE 6.1 – Architecture API REST
6.2.2 Architecture physique
Pour garantir la flexibilité et la maintenabilité de notre système d’information, nous avons

veillé à bien choisir l’architecture physique de l’application. En effet ce choix à une grande
influence sur les mesures de performances d’un logiciel. Il a également d’impact sur le coût de
développement et le coût de maintenance. Pour ce fait, nous avons choisi d’adopté l’architecture
3-tiers qui devise la logique métier en 3 niveaux qui sont les suivant :
1. Client : c’est la couche présentation qui s’occupe par le simple affichage et quelques
traitements locaux exécutés coté client par le navigateur.
2. Serveur d’application : c’est la couche contenant la logique métier de l’application et les

traitements applicatifs, son rôle principal est d’exécuter les requêtes et de fournir les ressources
demandées par la couche présentation.
3. Serveur de base de données : c’est la couche responsable de garantir l’intégrité des données.
Il se charge principalement de servir les besoins du serveur d’application.
La figure 6.2 montre l’architecture 3-tiers .
ENIG Page 63
RÉALISATION
FIGURE 6.2 – Architecture physique de l’application
Parmi les avantages majeurs de cette architecture nous pouvons citer :

• avoir un client léger.
• La centralisation de données.
• L’accès à l’information se fait à travers une couche intermédiaire ce qui fortifie la sécurité de
donnée.
• La séparation en plusieurs couche augmente la performance par le partage des tâches sur les
différents niveaux.
6.2.3 Architecture logique
Il est primordial avant de commencer le développement de notre projet de comprendre

l’architecture d’un module ainsi que les différents contraintes et règles à respecter. Flutter
utilise Modèle-Vue-Contrôleur (MVC) comme modèle d’architecture logicielle, qui est
principalement chargé d’organiser la structure de processus du système entier au niveau du
codage et d’établir les moyens pour que le système soit flexible et extensible. MVC distingue
trois couches d’activités logicielles, visant une forte cohésion et couplant de manière lâche les
modules responsables du fonctionnement des systèmes Flutter.
ENIG Page 64
RÉALISATION
FIGURE 6.3 – Architecture logique de la solution
Modèle : couche de modélisation du système. Son objectif principal est de gérer les règles
métier du système et les données persistantes. Il est responsable de la communication avec la
base. Le Modèle est chargé de manipuler les données entre les différents éléments du module.
Vue : il est responsable de la couche d’affichage des informations utilisateur, comme la page
du produit et le formulaire de contact. Contrôlé par des fichiers de disposition (Layout) qui
assemblent des blocs, des conteneurs et des composants d’interface utilisateur dans une page
à afficher par un navigateur Web. Les blocs (Block) sont soutenus par du code PHP pour
générer du contenu de page dynamique. Ils sont généralement associés à des fichiers de modèle
PHTML (Template) facilement personnalisables pour générer des fragments de HTML qui
sont assemblés dans la page.
Contrôleur : Contrôleur : il s’agit de la couche qui définit les principales actions, demandes
et réponses des clients susceptibles de modifier l’état du modèle et de générer des vues de
données de la couche de modèle. Les contrôleurs contrôlent les flux de pages et l’orchestration
de la soumission des formulaires.
Cette architecture nous offre beaucoup d’avantages à savoir :

• Diminuer la complexité lors de la conception.
• Favoriser la réutilisation en implémentant des blocs et des méthodes réutilisables depuis
n’importe quel module.
• Faciliter la séparation des tâches et la répartition suivant les développeurs.

• assurer la maintenabilité et ceci grâce à la modularité et au faible couplage .
ENIG Page 65
RÉALISATION
6.3 Aspet technique
6.3.1 Technologie du frontend
En ce qui concerne la partie frontend j’ai travaillé avec Flutter version 2.8.2 basé sur le
langage Dart.
6.3.1.1 Dart
Dart est un langage de programmation orienté objet à usage général avec une syntaxe de
style C. Il est open-source et développé par Google en 2011. Le but de la programmation Dart
est de créer une interface utilisateur frontale pour les applications Web et mobiles. C’est un
langage important pour créer des applications Flutter. Le langage Dart peut être compilé à la
fois aOT (ahead-of-Time) et JIT (Just-in-Time).
FIGURE 6.4 – Dart Logo
6.3.1.2 Flutter
Flutter est un framework de développement d’applications multiplateforme, conçu par

Google, dont la première version a été publiée sous forme de projet open source à la fin de
l’année 2018. Flutter met à disposition une grande variété de bibliothèques d’éléments d’IU
standard pour android et iOS. Les applications Flutter utilisent le langage de programmation
Dart pour créer une application. Flutter est principalement utilisé pour le développement
d’applications android et iOS, sans nécessiter la création d’une base de code propre à chacun
de ces deux systèmes si différents l’un de l’autre.
ENIG Page 66
RÉALISATION
FIGURE 6.5 – Flutter Logo
Avantages de Flutter :
Les avantages populaires du framework Flutter sont les suivants :
• Développement multiplateforme : cette fonctionnalité permet à Flutter d’écrire le code une
seule fois, de le maintenir et de l’exécuter sur différentes plateformes. Cela permet d’économiser
du temps, des efforts et de l’argent aux développeurs.
• Développement plus rapide : Les performances de l’application Flutter sont rapides. Flutter
compile l’application en utilisant la bibliothèque arm C/C++ qui la rapproche du code machine
et donne à l’application une meilleure performance native.
• Bonne communauté : Flutter a un bon support communautaire où les développeurs peuvent

poser les problèmes et obtenir le résultat rapidement.
• Rechargement en direct et à chaud : cela rend le processus de développement d’applications

extrêmement rapide. Cette fonctionnalité nous permet de modifier ou de mettre à jour le code
sont reflétés dès que les modifications sont apportées.
• Code minimal : l’application Flutter est développée par le langage de programmation

Dart, qui utilise la compilation JIT et aOT pour améliorer le temps de démarrage global,
le fonctionnement et accélérer les performances. JIT améliore le système de développement
et actualise l’interface utilisateur sans déployer d’efforts supplémentaires pour en créer un
nouveau.
• UI Focused : Il possède une excellente interface utilisateur car il utilise un widget centré sur
la conception, des outils de développement élevé, des aPI avancées.
• Documentation : Flutter a un très bon support de documentation. Il est organisé et plus
informatif. Nous pouvons obtenir tout ce que nous voulons écrire en un seul endroit.
ENIG Page 67
RÉALISATION
6.3.2 Technologie du backend
En ce qui concerne la partie backend j’ai travaillé sur la version 6 du framework NestJS basé
sur NodeJS.
6.3.2.1 NodeJS
Node.js est une plateforme logicielle libre en JavaScript orientée vers les applications réseau
événementielles hautement concurrentes qui doivent pouvoir monter en charge. Elle utilise
la machine virtuelle V8, la librairie libuv pour sa boucle d’évènements, et implémente sous
licence MIT les spécifications CommonJS. Parmi les modules natifs de Node.js, on retrouve
http qui permet le développement de serveur HTTP. Il est donc possible de se passer de
serveurs web tels que Nginx ou apache lors du déploiement de sites et d’applications web
développés avec Node.js. Concrètement, Node.js est un environnement bas niveau permettant
l’exécution de JavaScript côté serveur.avec cet environnement on peut créer rapidement une
application nécessitant peu de calculs et pouvant accueillir un nombre de requêtes à la seconde
très conséquent.
FIGURE 6.6 – NodeJs Logo
6.3.2.2 NestJS
NestJS est un framework Node.js progressif pour créer des applications côté serveur
efficaces, fiables et évolutives. Le framework va offrir les avantages de JavaScript avec sa
flexibilité et ses nombreuses librairies tout en incluant les concepts d’architectures modulaires
et de nombreux design-patterns. Pour réussir à ajouter ce concept d’architecture mature et
modulable à Node.js, NestJS va s’appuyer sur TypeScript aussi. NestJS applique les principes
de la programmation orientée objet, de la programmation fonctionnelle et la programmation
ENIG Page 68
RÉALISATION
fonctionnelle asynchrone. NestJS utilise par défaut le framework de serveur HTTP Express
mais il est possible d’utiliser d’autre framework comme Fastify. Express met en place
une infrastructure permettant de gé- nérer des serveurs web HTTP très facilement à l’aide
de méthodes HTTP utilitaires. Utiliser Express permet donc de continuer à utiliser les
fonctionnalités de Node.js. .
FIGURE 6.7 – NestJS Logo
Architecture de NestJS et ses avantages :

NestJS est composé par :
• Les controllers : Ces classes représentent le point d’entrée de l’application. Ils sont
responsables à définir les routes, accepter les requêtes et appeler les différents providers ou
services.
• Les providers : sont appelés par les controllers ou par d’autres providers. C’est dans ces classes
que le code le plus complexe d’une fonctionnalité va être développé.
• Les modules : permettent d’organiser la structure de l’application et la répartition du code.
En règle générale, un module va regrouper le controller et les providers spécifiques à une
fonctionnalité.
• En plus de ces principes permettant de favoriser l’architecture d’une application, NestJS

apporte de nombreuses autres fonctionnalités très utiles aux développeurs comme les Guards
pour l’authentification et les ExceptionsFilters pour gérer les réponses en erreurs.
• Grâce à tous ces concepts, NestJS permet de favoriser le développement d’une application
avec une architecture structurée palliant au passage le plus gros problème de Node.js, cela en
gardant tous les avantages de JavaScript avec sa performance et sa flexibilité.
• NestJS qui offre une surcouche TypeScript à Node.js, devient donc une alternative solide à
Java et PHP.
ENIG Page 69
RÉALISATION
6.3.3 Base de données
6.3.3.1 MongoDB
MongoDB est un système de gestion de base de données orienté document qui peut être
distribué sur n’importe quel nombre d’ordinateurs et n’a pas besoin d’un schéma de données
prédéfini. Il est écrit en C++. Le serveur et les outils sont distribués sous licence SSPL, les
pilotes sous licence apache et la documentation sous licence Creative Commons4 . Il fait partie
de la mouvance NoSQL.
FIGURE 6.8 – MongoDB Logo
6.3.3.2 Avantages de MongoDB
•Plate-forme de données d’application entièrement basée sur le cloud.

• Schémas de documents flexibles.
• accès aux données largement pris en charge et code natif. adaptée au changement.
• Requêtes et analyses puissantes.
• Installation simplifiée.
• Rentable.
• Support technique complet et documentation.
6.4 Présentation de l’environnement
Afin d’accomplir notre projet, nous avons eu recours à un environnement matériel et logiciel.
ENIG Page 70
RÉALISATION
6.4.1 Environnement matériel
Pour réaliser ce projet, nous avons utilisé l’ordinateur suivant :
• Un PC LENOVO possédant une RAM de capacité 16 GO.

• Un processeur Intel® CoreTM i7 9 éme génération de fréquence d’horloge 4,20 GHz.
• Disque dur : 2 To.
• Système d’exploitation Windows 10.
6.4.2 Environnement matériel
L’environnement logiciel que nous avons utilisé est constitué de :
6.4.2.1 Postman
PostMan est un logiciel permettant de tester vos aPI mais aussi de les enregistrer. C’est-à-
dire qu’au lieu de tester vos aPI sur votre navigateur et de découvrir vos informations non
formalisées, vous allez utiliser postman pour tester les requêtes, les voir sous le bon format et
aussi enregistrer la requête.
FIGURE 6.9 – Postman Logo
6.4.2.2 Visual Studio Code
Visual Studio Code est un éditeur de code extensible développé par Microsoft pour
Windows, Linux et macOS. Les fonctionnalités incluent la prise en charge du débogage, la mise
en évi- dence de la syntaxe, la complétion intelligente du code, les snippets, la refactorisation
du code et Git intégré.
ENIG Page 71
RÉALISATION
FIGURE 6.10 – Visual Studio Code Logo
6.4.2.3 Android Studio
Android Studio est un environnement de développement pour développer des applications

mobiles android. Il est basé sur IntelliJ IDEa et utilise le moteur de production Gradle. Il peut
être téléchargé sous les systèmes d’exploitation Windows, macOS, Chrome OS et Linux.
FIGURE 6.11 – Android Studio Logo
6.4.2.4 MongoDB Compass
Propose une interface graphique pour MongoDB, vous permettant d’envisager de nouvelles
perspectives de gestion de vos bases de données NoSQL orientées documents. MongoDB Com-
pass vous permet de garder la main sur vos données confidentielles ainsi que de vous connecter
à un serveur MongoDB local.
FIGURE 6.12 – MongoDB Compas Logo
ENIG Page 72
RÉALISATION
6.4.2.5 NPM
Npm est le package manager de NodeJS mais c’est aussi la plus grande bibliothèque de
projets open sources au monde. NPM est l’abréviation de Node Package Manager, qui est un
outil gérant les bibliothèques de programmation Javascript pour Node.js.
FIGURE 6.13 – NPM Logo
6.4.2.6 Serveur de gestion de versions GitLab
GitLab est un serveur Git plus moderne et complet, il est une forge fonctionnant sur
GNU/Linux. Il permet de gérer des dépôts Git ainsi que les utilisateurs et leurs droits d’accès
aux dépôts.
FIGURE 6.14 – GitLab Logo
6.4.2.7 StarUML
StarUML est un logiciel de modélisation UML, qui a été « cédé comme open source »
par son éditeur, à la fin de son exploitation commerciale (qui visiblement continue ...), sous
une licence modifiée de GNU GPL. StarUML gère la plupart des diagrammes spécifiés dans la
norme UML 2.0. StarUML est écrit en Delphi1, et dépend de composants Delphi propriétaires
(non open-source). .
ENIG Page 73
RÉALISATION
FIGURE 6.15 – StarUML Logo
6.5 Diagramme de déploiement
6.5.1 Définition
Le diagramme de déploiement est présentation stable qui modélise le déploiement physique

des informations produise par les logiciels sur les composants matériels.
6.5.2 Éléments d’un diagramme de déploiement
Les éléments qui forment un diagramme de déploiement sont particulièrement :
— Les noeuds : sont les éléments logiciels ou matériels du système (tels que les machines,
les membres d’équipes ou les serveurs ...), décrit généralement par un cube ou une boite.
— Les composants : présentés par desp arallélépipède qui montrent les éléments logiciels.
— artefacts : un artefact présente la désignation d’une partie d’information physique crée

au cour de développement. On définit un programme, un fichier, une base de données
ou une bibliothèque génerée ou changée dans tout projets à développer. Il est symbolisé
généralement par un rectangle avec le stéréotype "artifact"
— Les associations : sont des traits qui définient et joignent les liens d’échange des donnés
entre les différents parties de système.
6.5.3 Diagramme de déploiement système
Pour présenter le déploiement de notre projet, nous avons réalisé le diagramme de

déploiement, comme l’indique la figure 6.16, qui marque l’organisation physique des différents
matériels et la distribution des composants au sein des noeuds :
ENIG Page 74
RÉALISATION
FIGURE 6.16 – Diagramme de déploiement de l’application
6.6 Réalisation
Dans cette partie, nous allons exposer les interfaces les plus importantes de notre projet.
— Interface d’authentification
FIGURE 6.17 – Interface d’authentification
Un formulaire se compose de deux champs "Email" et "Password" pour saisir les données
nécessaires, avec un bouton "Log In" pour les valider.
ENIG Page 75
RÉALISATION
Gestion des utilisateurs et des entreprises

L’administrateur peut ajouter, modifier et supprimer un utilisateur ou une entreprise .
La figure ci-dessous montre la consultation des utilisateurs dans notre application.
FIGURE 6.18 – Interface des utilisateurs
La figure ci-dessous montre l’ajout d’un nouveau utilisateur
FIGURE 6.19 – Interface de modification d’un utilisateur
ENIG Page 76
RÉALISATION
FIGURE 6.20 – Pop-up de détail d’un employé
Les interfaces sont les mêmes pour la gestion des entreprises.
Construire une tache

Le Chef de projet peut construire une tache pour chaque membre de projet.
La figure ci-dessous montre la construction d’une nouvelle tache.
FIGURE 6.21 – Interface de construction d’une tache
ENIG Page 77
RÉALISATION
La figure ci-dessous montre la liste des taches à réaliser ainsi que les taches assignées aux
autre membres .
FIGURE 6.22 – Interface de la liste des taches
L’utilisateur peut partagé son temps libre chaque jour afin de planifier les réunions et éviter
toute sorte de chevauchement . La figure ci-dessous montre le calendrier d’un employé.
FIGURE 6.23 – Interface calendrier d’un employé
ENIG Page 78
RÉALISATION
FIGURE 6.24 – Pop-up de partage de temps libre
Emploi du temps
Chaque employé doit remplir son emploi du temps chaque jour. La figure ci-dessous montre
l’interface du "time sheet".
FIGURE 6.25 – Interface "Time Sheet"
ENIG Page 79
RÉALISATION
6.7 Conclusion
Au niveau de ce chapitre, nous avons définis les technologies et les outils utilisés dans
notre projet. Dans la seconde partie nous avons exposé le diagramme de déploiement de notre
application. on conclu avec une présentation de notre travail avec des captures d’écran où on
décrit les fonctionnalités de chaque interface de notre projet.
ENIG Page 80
CONCLUSION GÉNÉRALE
En guise de conclusion, ce projet était une véritable opportunité pour apprécier et enrichir
notre formation à L’école nationale d’ingenieurs de Gabes (ENIG) en apprenant des nouvelles
technologies. Il était aussi, un véritable clé d’accès vers les meilleures perspectives de la future
vie active et professionnelle.
Les différentes étapes d’élaboration de notre solution ont été exposées à travers le présent
rapport. Nous avons commencé par présenter notre projet dans son cadre général, puis nous
avons présenté les spécifications des besoins fonctionnels et non fonctionnels, auxquels devra
répondre notre application. Une fois la conception élaborée, nous avons exposé le travail
effectué à travers quelques captures d’écran.
Dans notre projet, nous avons pu développer plusieurs fonctionnalités répondant aux
besoins de « PIXIMIND ». Comme perspective, nous visons à améliorer notre projet par
l’intégration d’une version mobile. L’objectif de cette intégration est de faciliter l’accés pour
les employés.
Pour conclure, ce projet était vraiment une importante station dans notre vie sociale et aussi
professionnelle. Chose sentis et approuvé durant la période du projet et à travers l’esprit collectif
stimulant le travail par groupe.
ENIG Page 81
BIBLIOGRAPHIE
[1] www.cnil.fr/fr/definition/interface-de-programmation-dapplication-api, Interface de pro-

grammation, Cnil, Consulté le 20/03/2022.
[2] www.blog.nicolashachet.com/developpement-php/larchitecture-rest-expliquee-en-5-
regles/, L’architecture REST expliquée en 5 règles, Nicolas Hachet, Consulté le
20/03/2022.
[3] www.zestedesavoir.com/tutoriels/1280/creez-une-api-rest-avec-symfony-3/un-tour-
dhorizon-des-concepts-rest/, Un tour d’horizon des concepts REST, BestCoder, Consulté
le 20/03/2022.
[4] www.nutcache.com/fr/blog/methodologie-scrum/ Consulté le 03/05/2022
[5] www.scrum.org/resources/what-is-scrum. Consulté le 05/05/2022
[6] https ://www.tuleap.org/fr/comprendre-methode-agile-scrum-10-minutes Consulté le

10/04/2022
[7] en.wikipedia.org/wiki/Data Consulté le 20/05/2021
[8] visualstudio.com/ Consulté le 20/03/2022
[9] fr.wikipedia.org/wiki/JavaScript Consulté le 23/05/2022
[10] practicalprogramming.fr/nodejs Consulté le 05/04/2022
[11] nestjs.com Consulté le 23/04/2021
[12] flutter.dev Consulté le 23/02/2022
ENIG Page 82

Langue

Moetaz

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Moetaz

Transféré par

Droits d'auteur :

DEDICACES

À mes très chers parents, Nabil et Souhir

magnifique modèle de labeur et de persévérance. Les espoirs et les rêves m’appartiennent

À ma chère soeur, Mawadda.

Un remerciement particulier à Monsieur Mohamed Karim Abdmouleh au sein de l’ENIG,

Mes profondes reconnaissances s’adressent également à mes encadrants de société Monsieur

2 Analyse et spécification des besoins 14

3 Release 1 : Gestion des données de base 23

4 Release 2 : Mise en place des procédures de travail 36

5 Release 3 :Implémentation des outils de supervision 47

1.1 Logo PixiMind [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Planification du projet ............................................................................................... 22

3.1 Planification du release 1........................................................................................... 24

4.1 Planification du release 2........................................................................................... 37

6.1 Architecture API REST ............................................................................................. 63

1.1 les avantages et les inconvénients des applications évoquées ................................... 10

2.1 Backlog produit ......................................................................................................... 21

3.1 Backlog sprint "S’authentifier" ................................................................................. 25

4.1 Backlog sprint "Intégration du module projet" ......................................................... 37

6.1 Comparaison entre SOAP, REST et GraphQL .......................................................... 61

— Le premier chapitre présente l’entreprise, l’étude de l’existant, on conclue avec la solution

— Le troisième chapitre est réservé à la conception et au développement des trois sprints

— Le quatrième chapitre examine la conception et au développement des trois sprints "Intégration

— Le cinquième chapitre examine la conception et le développement des trois sprints "Intégration

de l’entité emploi de temps" et "Intégration de l’entité calendrier" et " Intégration des

1.2 Présentation de l’organisme d’accueil

1.2.1 Présentation générale de l’entreprise

PIXIMIND est un éditeur d’applications mobiles et web (essentiellement B to B), fondé en

FIGURE 1.1 – Logo PixiMind [1]

1.2.2 Domaines d’activité et Organigramme hiérarchique de la société

PixiMind se concentre sur la fourniture de :

FIGURE 1.2 – Organigramme hiérarchique de la société

1.3 Présentation du projet

1.3.1 Problématique et contexte du projet

1.3.2 Objectifs du projet

Notre projet vise à :

• Faciliter aux employés de gérer leurs plannings au sein de l’entreprise.

• Planifier et partager des événements avec une ou plusieurs personnes

1.4 Etude de l’existant

1.4.1 Présentation de l’existant

FIGURE 1.3 – Représentation d’une interface du Redmine

FIGURE 1.4 – Représentation d’une interface du Toggl Track

1.4.1.3 Applications existantes portant sur le partage des événements

FIGURE 1.5 – Représentation d’une interface du Google agenda

1.4.2 Critique de l’existant

Le tableau récapitule avantages et inconvénients de toutes les applications évoquées.

modules gratuits. • Parfois complexe à

la solution ne s’appuie pas sur

TABLE 1.1 – les avantages et les inconvénients des applications évoquées

1.4.3 Solution Proposée

1.5 Contexte méthodologique du projet

1.5.1 Le choix de la Méthode Scrum

1.5.2 Rôles et notions

FIGURE 1.6 – La méthodologie Scrum

• L’équipe de développement : Il s’agit généralement d’une équipe de 6 à 10 personnes chargées

Au cours de ce chapitre, on a présenté l’organisme d’accueil et on a mis le projet dans

2.2 Spécification des besoins

2.2.1 Identification des acteurs

• Administrateur : c’est le responsable de l’administration de notre application. Il a pour

* Gérer les employés

* Gérer les entreprises internes

* Gérer les projets

* Gérer les catégories

* Consulter les statistiques

* Affecter les taches aux membres de projet