République Tunisienne

Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National d’ingénieur

Spécialité : Génie Logiciel

Par

MANNAI Hamdi

Le développement d’une application HelpDesk de

suivi de projets

Encadrante
Mme. SMAOUI Amira
professionnelle :
M. ZOGHLAMI Mohamed Ali
Encadrant académique :

Réalisé au sein de Sopra HR Software

A.U : 2021-2022
J’autorise l’étudiant à faire le dépôt de son rapport de PFE en vue d’une soutenance.

Encadrante professionnelle, Mme. SMAOUI Amira

Signature et cachet

J’autorise l’étudiant à faire le dépôt de son rapport de PFE en vue d’une soutenance.

Encadrant académique, M. ZOGHLAMI Mohamed Ali

Signature

i
Dédicaces

Avec grand plaisir que je dédiais ce travail, en premier lieu, à mon

père Ezzedine qui m’a soutenu au cours de tout le projet ainsi ma

mère Safia qui m’a encouragé et m’a donné la force tout le temps de

tribulations, tous mes professeurs pour leur soutien moral durant

l’élaboration du travail de fin d’études, Mes très chers amis et

collègues que je considère comme une deuxième famille, je leur

souhaite une longue vie pleine de joie, de bonheur et de réussite.

Puisse ALLAH, le tout-puissant leur garder et leur procurer la

santé et le bonheur.

Mannai Hamdi

ii
Remerciements

Tout d’abord, j’adresse les remerciements à mes encadrants Mme.

SMAOUI Amira et M. Mohamed Ali ZOGHLAMI pour leurs

persévérances dans le suivi du stage, leurs encouragements et

surtout pour le soutien psychologique qui m’a permis de mener à

bien ce projet.

Je suis reconnaissant à mon parrain de stage M. Hbib SMEI, pour

le suivi de ce projet, pour ses conseils, orientations et instructions

durant la période du stage.

Je remercie aussi très sincèrement, les membres du jury d’avoir

intéressé à ce travail et d’avoir bien voulu accepter de faire partie de

la commission d’examinateurs pour juger la qualité de mon projet.

J’adresse également une gratitude au corps professoral de

l’université SESAME, qui m’ont donné les bases de la science de

l’informatique, durant mon parcours d’études.

À toutes ces personnes : merci

iii
Table des matières

Introduction générale 1

1 Présentation du cadre du projet 2

1.1 Présentation du cadre de stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Présentation du groupe Sopra Steria . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Présentation de la société SopraHR Software . . . . . . . . . . . . . . . . . . . 4
1.1.4 Domaines d’activités de la société Sopra HR . . . . . . . . . . . . . . . . . . . . 4
1.2 Cadre du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Planning du travail et choix de la méthodolgie de travail . . . . . . . . . . . . . . . . . 8
1.3.1 Les méthodologies du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.2 Langage de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.3 Pourquoi SCRUM ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Analyse et spécification des besoins 12

2.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Critique des solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.2 Description de la solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.3 Identification des acteurs du système . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Conception générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Diagrammes de cas d’utilisation initial . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Diagrammes de cas d’utilisation détaillé . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

iv
3 Conception détaillée et méthodologie de la planification des tâches 22
3.1 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Planification des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1 Planification des releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.3 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Phase de réalisation 34
4.1 Les environnements matériel et logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Création de prototypes des interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.1 Création d’un logo pour notre application . . . . . . . . . . . . . . . . . . . . . 36
4.2.2 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.3 Interface création d’un compte . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.4 Interface vue administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.5 Interface création d’un ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.6 Interface dashboard pour le client . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 La réalisation de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.1 L’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.2 Espace Administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.3 Espace du chef de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.4 Espace du collaborateur de maintenance . . . . . . . . . . . . . . . . . . . . . . 44
4.3.5 Espace du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.6 La création d’un ticket par le client . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Tests fonctionnels de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Conclusion générale 52

v
Table des figures

1.1 Le modéle de cycle en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Diagramme du cas d’utilisation détaillé relatif à la gestion des utilisateurs . . . . . . . 19
2.3 Diagramme du cas d’utilisation détaillé relatif à la gestion des catégories . . . . . . . . 19
2.4 Diagramme du cas d’utilisation détaillé relatif à la gestion des projets . . . . . . . . . 20
2.5 Diagramme du cas d’utilisation détaillé relatif à la gestion des modules . . . . . . . . . 21

3.1 Diagramme des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Diagramme de séquence relatif à l’authentification . . . . . . . . . . . . . . . . . . . . 25
3.3 Diagramme de séquences relatif à l’ajout d’un utilisateur . . . . . . . . . . . . . . . . . 26
3.4 Diagramme de séquences relatif au consultation d’un utilisateur . . . . . . . . . . . . . 26
3.5 Diagramme de séquences relatif à la création d’un projet . . . . . . . . . . . . . . . . . 27
3.6 Diagramme de séquences relatif à la modification d’un projet . . . . . . . . . . . . . . 28
3.7 Diagramme de séquences relatif à la suppression d’un projet . . . . . . . . . . . . . . . 29
3.8 Diagramme de séquences relatif à la création d’un ticket . . . . . . . . . . . . . . . . . 30
3.9 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Logo Sopra Tracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Design de page d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Design de page d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Interface vue administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 Interface création d’un ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.6 Interface dashboard pour le client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.7 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.8 Interface principale de l’administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.9 Interface de consultation de la liste des projets . . . . . . . . . . . . . . . . . . . . . . 41
4.10 Interface du formulaire de saisie d’un projet . . . . . . . . . . . . . . . . . . . . . . . . 42
4.11 Interface des statistiques des projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.12 Interface principale du chef de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.13 Interface de consultation de la liste des tickets . . . . . . . . . . . . . . . . . . . . . . . 43
4.14 Interface principale du collaborateur de maintenance . . . . . . . . . . . . . . . . . . . 44

vi
4.15 Interface de consultation de la liste des tickets . . . . . . . . . . . . . . . . . . . . . . . 45
4.16 Interface de consultation et mise à jour d’un ticket . . . . . . . . . . . . . . . . . . . . 46
4.17 Interface principale du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.18 Création d’un ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.19 Interface de consultation et mise à jour d’un ticket . . . . . . . . . . . . . . . . . . . . 49
4.20 Interface d’ouverture d’un live chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

vii
Liste des tableaux

1.1 Sopra Steria en quelques chiffres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 SopraHR Software en quelques chiffres . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Étude comparative entre les différentes solutions . . . . . . . . . . . . . . . . . . . . . 8

3.1 Backlog produit Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Backlog produit Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Backlog produit Release 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Backlog produit Release 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 Tests effectués . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

viii
Liste des abréviations

— HR = Human resources/Ressources humaines

— NULL

— SGBD = Système de Gestion de Base de Données

— SQL = Structured Query Language

— UML = Langage de Modélisation Unifié

ix
Introduction générale

Dans un monde de plus en plus connecté et globalisé, la planification de voyages en groupe

est devenue une activité courante mais souvent complexe. Que ce soit pour des vacances entre amis,
des voyages d’affaires, ou des sorties scolaires, la coordination des diverses préférences, budgets, et
calendriers peut s’avérer un véritable défi. C’est dans ce contexte que s’inscrit notre projet de fin
d’annés (PFE), visant à développer une application innovante de planification de voyages en groupe.
Le but principal de ce projet est de créer une plateforme intuitive et efficace qui facilite
l’organisation et la gestion des voyages en groupe. Notre application se propose de centraliser toutes
les informations nécessaires, de la sélection des destinations à la réservation des hébergements et des
activités, en passant par la gestion des budgets et la coordination des agendas des participants.
Le rapport qui suit détaillera les différentes phases de ce projet, de la conception initiale à
la mise en œuvre technique, en passant par les tests utilisateurs et l’évaluation des performances
de l’application. Nous aborderons également les défis rencontrés et les solutions apportées pour les
surmonter. Enfin, nous discuterons des perspectives d’évolution de l’application et des potentielles
améliorations à envisager pour répondre encore mieux aux besoins des utilisateurs.
Ce présent rapport est composé de quatre chapitres. Le premier chapitre, nous a servi à mettre
le projet dans son cadre, nous allons tout d’abord présenter l’entreprise d’accueil, ensuite on décrit la
problématique, l’étude de l’existant et la solution proposée en finissant par le choix d’une méthodologie
de travail. Le deuxième chapitre, nous allons présenter les besoins fondamentales de cette application,
la critique des solutions existantes, l’identification des acteurs et leurs rôles puis les besoins fonctionnels
et non fonctionnels de notre solution et les diagrammes des cas d’utilisations. Le troisième chapitre
est consacré à la conception et la méthodologie de la planification des tâches, nous allons présenter
en premier lieu, les diagrammes des classes et de séquences, ensuite nous allons étudier le backlog de
notre travail dans le cadre de la planification des tâches du projet. Finalement dans le dernier chapitre,
on s’intéresse à la mise en place de notre solution, la liste de tous les outils que nous avons utilisés,
l’environnement de travail, le matériel utilisé, les prototypes des interfaces et on terminera par les
résultats obtenus.

1
 Chapitre 1

Présentation du cadre du projet

Plan
1 Présentation du cadre de stage . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Cadre du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Planning du travail et choix de la méthodolgie de travail . . . . . . . . . . 8

Chapitre 1. Présentation du cadre du projet

Introduction

Ce chapitre a pour but de mettre l’accent sur notre projet de fin d’année et de le situer dans
son contexte général. Dans un premier lieu, nous allons commencer par la présentation de l’organisme
d’accueil, qui est la société SopraHR Software.
Ensuite, nous introduirons les différentes parties de notre projet, tout en incluant une étude de
l’existant. Enfin, nous proposerons une solution et choisirons une méthodologie de travail afin de gérer
la planification et la gestion de notre projet.

1.1 Présentation du cadre de stage

1.1.1 Présentation de l’organisme d’accueil

Nous allons procéder à une présentation générale de la société SopraHR Software qui fait partie
du groupe Sopra Steria afin de mieux comprendre l’organisation des tâches. Ainsi, mon stage s’est
déroulé au sein de l’équipe TMA qui est en relation directe avec les clients.

1.1.2 Présentation du groupe Sopra Steria

Sopra Steria est une entreprise de services du numérique (ESN) française et une société de
conseil en transformation numérique des entreprises et des organisations.
Sopra Steria est le fruit de la fusion en janvier 2015 des deux entreprises françaises de services
numériques Sopra et Steria, créées respectivement en 1968 et 1969. En 2020, le groupe compte 46 000
salariés répartis dans plus de 30 pays dont 20 000 en France, et réalise un chiffre d’affaires de 4,3
milliards d’euros.
Sopra Steria, l’un des leaders européens de la Tech reconnu pour ses activités de conseil, de
services numériques et d’édition de logiciels, aide ses clients à mener leur transformation digitale et
à obtenir des bénéfices concrets et durables. Il apporte une réponse globale aux enjeux de compétitivité
des grandes entreprises et organisations, combinant une connaissance approfondie des secteurs d’activité
et des technologies innovantes à une approche résolument collaborative. Sopra Steria place l’humain au
centre de son action et s’engage auprès de ses clients à tirer le meilleur parti du digital pour construire
un avenir positif.
Fort de ses 47 000 collaborateurs dans près de 30 pays, le Groupe a réalisé un chiffre d’affaires
de 4,7 milliards d’euros en 2021 (Voir tableau 1.1).

3
Chapitre 1. Présentation du cadre du projet

Tableau 1.1 : Sopra Steria en quelques chiffres

Chiffre
Nombre de
Classement d’affaires en Présence dans le monde
collaborateurs
2021
TOP 5 des acteurs européens
4,7 MRD € 47 000 Présent dans près de 30 PAYS
du secteur des ESN

1.1.3 Présentation de la société SopraHR Software

Sopra HR Software, un leader en solutions et services pour la paie et les ressources humaines,
répond aux enjeux des Directions des Ressources Humaines des organisations de moyennes et grandes
tailles, des secteurs d’activités public et privé. Spécialiste de la Paie, du Talent Management et du
pilotage des RH, dans un contexte local et international, Sopra HR, privilégie la co-innovation et
favorise les enjeux de performance de la fonction RH autour d’une expérience collaborateur optimale.
Partenaire de la réussite d’une transformation digitale positive, Sopra HR s’engage auprès de ses clients
à tirer le meilleur parti du digital pour construire une RH 3.0 responsable. Sopra HR, filiale du groupe
Sopra Steria, accompagne plus de 900 clients, dans plus de 54 pays, en mode « on-premise » ou services
cloud. Sopra Steria, l’un des leaders européens du conseil, des services numériques et de l’édition de
logiciels, aide ses clients à mener leur transformation digitale. Fort de ses 46 000 collaborateurs dans
25 pays, le Groupe a réalisé un chiffre d’affaires de 4,3 milliards d’euros en 2020 (Voir tableau 1.2).

Tableau 1.2 : SopraHR Software en quelques chiffres

Effectif : tranche INSEE à
Capital social Chiffre d’affaires en 2021
18 mois
500 à 999 salariés 13 109 820,00 € 172 938 000.00 €

1.1.4 Domaines d’activités de la société Sopra HR

Les différents domaines d’activités de la société Sopra HR Software mondialement pour la

gestion des ressources humaines sont présentés ci-dessous :

1.1.4.1 Administration du personnel

Permet de libérer les experts RH des tâches administratives et adoptez des solutions RH
intelligentes et performantes, automatiser les processus RH qui accompagnent l’évolution du collaborateur
dans votre organisation tout au long de son parcours dans l’entreprise ainsi que sécuriser l’administration
du personnel en assurant le respect de la conformité légale.

4
Chapitre 1. Présentation du cadre du projet

1.1.4.2 Paie et déclaratifs

Permet d’adoptez une paie sûre, automatisée et rapide pour l’organisation et exploiter un moteur
de paie robuste et de puissantes fonctionnalités de calcul, pour une maîtrise sans faille de la paie quelle
que soit sa complexité.

1.1.4.3 Temps et activités

Proposer aux équipes des plannings partagés afin de planifier les meilleures organisations performantes
du temps de travail, tout en prenant en compte les préférences.

1.1.4.4 Talents

Les solutions HR accompagnent dans la recherche des meilleurs talents, dans le développement
des collaborateurs et dans l’adéquation idéale de la stratégie de l’organisation avec son capital humain.

1.1.4.5 Analytics

Le Big Data RH permet d’extraire l’intelligence de ces données et de la mettre au service

de l’action. Doter aux équipes une solution analytique RH avancée, pour accompagner les décisions
stratégiques, piloter les politiques RH, prévenir les risques et anticiper les actions.

1.2 Cadre du sujet

Notre travail s’inscrit dans le cadre du projet de fin in d’année ayant pour but l’enrichissement
de notre formation en génie logiciel et la mise en pratique des connaissances théoriques acquises à
l’université SESAME.

5
Chapitre 1. Présentation du cadre du projet

1.2.1 Objectifs du projet

Les solutions de gestion des tickets sont devenus essentiels car ils aident à résoudre les problèmes
d’une façon rapide et pratique, en gérant les incidents depuis leur déclenchement jusqu’à leur résolution
simplifiant le contact entre les différents acteurs. Parmi les solutions qui existent aujourd’hui nous
citons :

• Zendesk

• JIRA

L’objectif de notre travail est de mettre en place une solution de suivi des projets et gestion de
leurs tickets répondant exactement à ses besoins, ses avantages :

— Identité propre de SopraHR qu’elle peut fournir à ses clients

— Moins cher

— Application dynamique (Plus réactive et intervention rapide via chat) afin d’avoir un temps de
réponse faible

— Design plus simple

— Accélérer le temps de traitements des events/Ticket pour augmenter la productivité

1.2.2 Etude de l’existant

L’étude des systèmes existants constitue une étape utile et importante pour achever notre
travail. Elle a pour but de porter un jugement objectif, afin de déceler les insuffsances éventuelles
rencontrées au cours de l’étude de l’existant en vue de proposer un système plus fiable et fonctionnel.
En effet, cette partie importante nous a permis de dégager un certain nombre de lacunes, on cite par
exemple :

— Une perte de temps : Certaines interventions peuvent être faites très rapidement sans avoir
besoin de faire plusieurs échanges.

— Pas de notifications pour certaines solutions

— Une difficulté dans le suivi si un dashboard est compliqué : il est difficile au directeur
de bien suivre le déroulement du travail et de contrôler la réalisation des tâches puisqu’il n’existe
pas des traces de travail claires.

— Manque d’évaluation des tâches : comme le déroulement du travail est non évalué, il est aussi
très difficile au directeur, de déduire les causes d’une défaillance ou d’améliorer un tel service.

6
Chapitre 1. Présentation du cadre du projet

— Difficulté d’amélioration : comme l’évaluation est difficile, l’amélioration demeurre risquée.

Sans savoir les lacunes du travail, il est difficile d’améliorer la qualité de produit, la rapidité de
la réalisation.

1.2.3 Problématique

Les solutions de suivi des projets sont devenus primordiales à l’organisation et à la mise en
œuvre des activités de l’entreprise. Ils permettent de planifier et d’optimiser la gestion d’un projet à
travers le suivi et la coordination des travaux de ses membres, le contrôle des flux d’informations ainsi
que le respect des deadlines et la maîtrise des coûts. Parmi les solutions qui existent aujourd’hui nous
citons :

• Zendesk

• JIRA

• Trello

1.2.3.1 Étude préalable des solutions similaires

Afin d’approfondir notre compréhension du projet et avoir une idée plus claire sur les objectifs
de notre travail et les fonctionnalités attendues, nous avons mené une étude sur les applications les
plus populaires et similaires à celle à développer.

1.2.3.2 Étude comparative entre les différentes solutions

Afin d’étudier les divers solutions présentées précédemment, nous les comparons dans le tableau
ces derniers (Voir le tableau 1.3)

7
Chapitre 1. Présentation du cadre du projet

Tableau 1.3 : Étude comparative entre les différentes solutions

Solution Avantages Inconvénients
— Coût élevé
— Existe en version mobile — Solution complexe,
Zendesk — Enquêtes de satisfaction client — Besoin d’apprentissage
— Trop de navigations

— Difficile à utiliser
— Recherche puissante — Coût élevé
JIRA — Importation facile des données — Difficile à configurer
— Besoin d’apprentissage

— Créer un board en utilisable en

moins de 5 minutes — Pas de gestion de droits avancés
Trello — Facile à utiliser — On ne peut pas faire de board
kanban complexes
— Visuellement très agréable

1.2.4 Solution proposée

On doit tout d’abord mentionner que les attentes des différentes parties prenantes par rapport
à cette application sont sensiblement différentes. En effet, l’administrateur cherche principalement à
avoir son propre solution de gestion des tickets et à superviser le travail de tous les acteurs de la
manière la plus aisée qui soit partant d’une vue globale jusqu’à parvenir au moindre détail concernant
le projet. La sécurité et la stabilité de l’application est également au cœur de ses préoccupations. En
ce qui concerne le chef de projet (appelé aussi le responsable maintenance) l’idéal pour lui serait de
disposer d’un système capable de travailler en temps réel afin de pouvoir contrôler l’avancement des
tâches de la manière la plus efficace possible et bien gérer les tickets des problèmes de son équipe. Pour
les membres de projet (appelés aussi les collaborateurs de maintenance) l’interface doit leur afficher
les tickets qui leur sont attribuées et doit être simple et facile à manipuler. Et pour le client ou le
collaborateur, le système l’aidera à résoudre ses problèmes par l’utilisation des tickets.

1.3 Planning du travail et choix de la méthodolgie de travail

L’analyse et la conception d’un plan ou d’une démarche à suivre est une étape indispensable
pour rendre nos besoins plus clairs à fin d’avoir un travail plus fidèle aux besoins de la société. A cette
phase de planification, nous devisons le projet en tâches, nous décrivons leur enchaînement dans le
temps et nous affectons à chacune une durée. Pour mieux l’organiser, nous faisons un planning qui
présente les différentes tâches, leurs durées planifiées et les status d’avancement de chacune.

8
Chapitre 1. Présentation du cadre du projet

1.3.1 Les méthodologies du projet

Il existe une variation des méthodologies de conception, chacune avec ses propres caractéristiques,
nous pouvons citer :

1.3.1.1 Le processus unifié et les méthodologies agiles (Scrum)

Scrum est une méthode agile dédiée à la « gestion de projet ». Cette méthode de gestion, ou
plutôt ce Framework de management de projet, a pour objectif d’améliorer la productivité de son
équipe. La méthodologie Srcum est basée sur la répartition des rôles, répartition du projet en sous
projets.

1.3.1.2 Le modèle en cascade

Alternative de la méthodologie Agile, considéré comme l’approche classique du développement,

ce modèle décrit un cycle linéaire et séquentiel. Ce modèle comporte 7 phases :

• Analyse des besoins

• Spécifications

• Conception de l’architecture

• Conception détaillée

• Implémentation

• Tests (validation)

• Installation

9
Chapitre 1. Présentation du cadre du projet

1.3.1.3 Le modèle de cycle en V

Ce modèle est une amélioration du modèle en cascade qui permet en cas d’anomalie, de limiter
un retour aux étapes précédentes. Le cycle en V est décrit par la figure 1.1 :

Figure 1.1 : Le modéle de cycle en V

1.3.2 Langage de conception

Pour la partie conception, nous avons choisi d’utiliser le langage de modélisation unifié (Unified
Modeling Language en anglais) UML comme un langage de modélisation pour notre projet. Le choix
s’est porté sur les points forts de l’UML[1] face aux autres langages généralement sur sa standardisation
et la multiplicité des diagrammes proposés. Son objectif principal est de créer un langage visuel commun
dans le monde complexe de la réalisation des applications, un langage qui serait également compris
par les utilisateurs professionnels et tous ceux qui veulent comprendre un système spécifique.

1.3.3 Pourquoi SCRUM ?

Il s’agit d’une méthode complète de management projet qui ne présente que des qualités, elle
se recentre sur la qualité, les objectifs, l’efficacité, la réduction de bugs et le plus important c’est la
communication entre les membres du groupe chargés de réaliser le projet. La méthode agile SCRUM
divise le travail en plusieurs petits cycles appelés « Sprints », chaque « sprint » est une itération de
développement de la méthode Scrum. La durée de chaque sprint est limitée de 2 à 4 semaines.[2]

Conclusion

Tout au long de ce chapitre, nous avons présenté l’organisme d’acceuil SopraHR Software et ses
activités. Par ailleurs, nous avons pu dégager le contexte général du projet et présenter le choix de la
méthodologie de développement. Dans le chapitre suivant, nous allons présenter la phase préparatoire

10
Chapitre 1. Présentation du cadre du projet

qui consiste à spécifier les besoins, le backlog du produit et enfin l’architecture et l’environnement du
travail.

11
 Chapitre 2

Analyse et spécification des besoins

Plan
1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Conception générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Chapitre 2. Analyse et spécification des besoins

Introduction

L’analyse et la spécification des besoins est une étape indispensable pour rendre nos besoins
plus clairs à fin d’avoir un travail plus fidèle aux besoins du client. Pour bien réussir notre travail, il
faut commencer par une étude et une analyse détaillées des besoins de notre projet puis passer à la
phase de développement de l’interface de supervision.

2.1 Analyse des besoins

L’analyse des besoins représente l’une des plus importantes phases du cycle de vie d’un logiciel.
La réussite d’un projet dépend d’une spécification concise et compréhensible. En effet, C’est dans cette
partie qu’on extrait les fonctionnalités du système par la description de ses besoins. Pour assurer les
objectifs de notre projet, il est nécessaire que nous parvenions à une vue claire des différents besoins
escomptés.

2.1.1 Critique des solutions existantes

— Une perte de temps : Certaines interventions peuvent être faites très rapidement sans avoir
besoin de faire plusieurs échanges.

— Pas de notifications pour certaines solutions

— Une difficulté dans le suivi si un dashboard est compliqué : il est difficile au directeur
de bien suivre le déroulement du travail et de contrôler la réalisation des tâches puisqu’il n’existe
pas des traces de travail claires.

— Manque d’évaluation des tâches : comme le déroulement du travail est non évalué, il est aussi
très difficile au directeur, de déduire les causes d’une défaillance ou d’améliorer un tel service.

— Difficulté d’amélioration : comme l’évaluation est difficile, l’amélioration demeurre risquée.

Sans savoir les lacunes du travail il est difficile d’améliorer la qualité de produit, la rapidité de
la réalisation.

2.1.2 Description de la solution proposée

Notre projet a pour objectif de développer notre propre produit signé SopraHR Software
qui permet la gestion des tickets et des tâches divisés selon des projets et catégories gérés par un
administrateur pour les droits, des chefs de projets pour l’affectation des tickets à leurs équipes, des
collaborateurs de maintenance qui vont travailler sur les tickets et des clients qui vont ouvrir de
nouveaux tickets. Notre nouvelle solution doit répondre au critères ci-dessous :

13
Chapitre 2. Analyse et spécification des besoins

— Adaptation plus rapide au besoin métier.

— Meilleure gestion du code grâce à l’utilisation des designs pattern.

— Stabilité et un meilleur Audit Trace de l’application.

— Portabilité et mobilité.

— Architecture évolutive.

— Meilleure ergonomie et expérience utilisateur.

2.1.3 Identification des acteurs du système

Un acteur peut être décrit comme une entité externe qui communique avec le système.
Dans notre cas, nous avons défini les cinq acteurs suivants :

2.1.3.1 L’administrateur :

son rôle est :

— Création des utilisateurs

— Affectation des responsables

— Création des catégories

2.1.3.2 Responsable maintenance :

ayant les tâches suivantes :

— Affectation des tickets

— Consultation des tickets

— Consultation des états d’avancement

2.1.3.3 Collaborateur :

qui peut faire :

— Lancement du live chat

— Ouverture ticket

— Modification ticket

— Clôture d’un ticket

2.1.3.4 Collaborateur maintenance :

qui pourra :

14
Chapitre 2. Analyse et spécification des besoins

— Lancement du live chat

— Ouverture ticket

— Modification ticket

— Clôture d’un ticket

2.1.3.5 User

son rôle est :

— Création d’un compte

2.2 Identification des besoins

L’identification des besoins consiste à traduire les objectifs de l’application en un ensemble de

fonctionnalités ciblées et bien définies par l’outil à réaliser. Ceci procurera une compréhension plus
claire des tâches à mettre en œuvre.

2.2.1 Besoins fonctionnels

Les besoins fonctionnels sont ceux qui doivent répondre aux exigences du futur système en
termes de fonctionnalités. Ils permettent de générer les cas d’utilisation. Les besoins recensés sont
comme suit :

2.2.1.1 Gestion des utilisateurs

La gestion des utilisateurs sera pilotée par l’administrateur du système. Cette tâche consistera
essentiellement en :

— Insérer des informations relatives à chaque utilisateur,

— Editer ces informations,

— Supprimer un utilisateur,

— Consulter un utilisateur.

2.2.1.2 Gestion des projets/catégories

La gestion des projets ou de catégories est effectuée par deux types d’utilisateurs qui sont :
• Administrateur : Il doit être en mesure de :

— Créer un nouveau projet/catégorie,

— Consulter les informations du projet,

15
Chapitre 2. Analyse et spécification des besoins

— Supprimer un projet,

— Modifier ces informations,

— Affecter les chefs de projet,

— Déposer un document de projet,

— Consulter le planning général de tous les projets,

— Consulter le tableau de bord.

• Chef de projet : Il doit être en mesure de :

— Consulter le planning des projets qui lui sont attribués,

— Consulter les informations du projet,

— Fermer le projet,

— Consulter un document de projet.

• Membre de projet : Il doit être en mesure de :

— Consulter les informations d’une tâche,

— Marquer l’état d’avancement d’une tâche.

2.2.1.3 Gestion des tickets

La gestion des tickets est effectuée par trois types d’utilisateurs :

• Client : Il doit être en mesure de :

— Envoyer un ticket,

— Editer les informations d’un ticket,

— Supprimer un ticket,

— Consulter un ticket.

• Chef de projet : Il doit être en mesure de :

— Valider un ticket,

— Assigner un ticket.

• Membre de projet : Il doit être en mesure de :

— Consulter les tickets,

— Marquer l’état d’avancement de ticket.

16
Chapitre 2. Analyse et spécification des besoins

2.2.1.4 Gestion des catégories des problèmes

La gestion des catégories des problèmes sera pilotée par l’administrateur. Cette tâche consistera
essentiellement en :

— Ajouter une catégorie de problème.

— Editer les informations d’une catégorie,

— Supprimer une catégorie,

— Consulter les informations d’une catégorie.

2.2.1.5 Création d’un espace de discussion

2.2.2 Besoins non fonctionnels

Ce sont des exigences qui ne concernent pas spécifiquement le comportement du système mais
plutôt qui identifient des contraintes internes et externes du système. En général, un système doit
fournir :

— L’ergonomie : L’application doit être adaptée à l’utilisateur sans qu’il ne fournisse beaucoup
d’effort à comprendre (utilisation claire et facile) de point de vue navigation entre les différentes
pages, couleurs et mise en textes utilisés, symboles et boutons. et ceci en utilisant un texte lisible
pour la lecture, des termes simples et classique.

— La performance : il s’agit d’optimiser le maximum du temps de chargement des donnés

depuis deux environnements différents c’est à dire la rapidité de chargement des pages web de
l’application.

— L’évolutivité : l’application peut avoir des extensions et des amélioration dans le temps, toute
en intégrant des nouveaux modules pour répondre aux nouveaux besoins fonctionnels et ceci
sans modifier les modules déjà existants. Cette fonction sera assurée en adoptant des patrons du
développement MVC et DAO.

— La sécurité : L’accès à l’application et aux données en géneral doit être sécurisé vu la sensibilité
des données tels que : la liste des clients et leurs informations personnelles, la liste des etudiants
et surtout des paiements qui doivent être bien protégés.

17
Chapitre 2. Analyse et spécification des besoins

2.3 Conception générale

2.3.1 Diagrammes de cas d’utilisation initial

Le modèle de Cas d’utilisation capture les exigences d’un système. Le Cas d’Utilisation est un
moyen de communiquer avec les utilisateurs et d’autres parties prenantes ce que le système est destiné
à faire. La figure 2.1 représente le diagramme de cas d’utilisation général de l’application :

Figure 2.1 : Diagramme de cas d’utilisation

2.3.2 Diagrammes de cas d’utilisation détaillé

Dans cette partie, nous présentons les diagrammes des cas d’utilisation détaillés ainsi que leur
descriptions textuelles.

18
Chapitre 2. Analyse et spécification des besoins

2.3.2.1 Cas d’utilisation « Gestion des utilisateurs »

La figure 2.2 illustre le diagramme du cas d’utilisation relatif à la gestion des utilisateurs.

Figure 2.2 : Diagramme du cas d’utilisation détaillé relatif à la gestion des utilisateurs

2.3.2.2 Cas d’utilisation «Gestion des catégories»

La figure 2.3 illustre le diagramme du cas d’utilisation relatif à la gestion des modules.

Figure 2.3 : Diagramme du cas d’utilisation détaillé relatif à la gestion des catégories

2.3.2.3 Cas d’utilisation «Gestion des projets»

La figure 2.4 illustre le diagramme du cas d’utilisation relatif à la gestion des projets.

19
Chapitre 2. Analyse et spécification des besoins

Figure 2.4 : Diagramme du cas d’utilisation détaillé relatif à la gestion des projets

2.3.2.4 Cas d’utilisation «Gestion des tickets»

La figure 2.5 illustre le diagramme du cas d’utilisation relatif à la gestion des tickets.

20
Chapitre 2. Analyse et spécification des besoins

Figure 2.5 : Diagramme du cas d’utilisation détaillé relatif à la gestion des modules

2.4 Conclusion

Dans ce chapitre, nous avons détaillé les besoins fonctionnels et non fonctionnels ainsi que les
diagrammes des cas d’utilisation. Lors de chapitre suivant nous allons exposer la partie conception
détaillée.

21
 Chapitre 3

Conception détaillée et méthodologie

de la planification des tâches

Plan
1 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Planification des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Chapitre 3. Conception détaillée et méthodologie de la planification des tâches

Introduction

Après avoir analysé les besoins, nous entamons dans ce chapitre la phase de conception. Ainsi,
nous nous focalisons sur la conception d’une structuration adéquate pour l’application. Cette étape est
primordiale au bon déroulement du projet, et a pour but de détailler les tâches à entreprendre et de
préparer le terrain pour l’étape de la réalisation. Dans une première partie, nous commençons par la
conception globale de notre projet. Ensuite, dans une deuxième partie, nous détaillons la conception en
utilisant les diagrammes UML appropriés, avant de finir par une présentation de la conception logique
de données.

3.1 Architecture globale

Notre projet consiste à développer une application intranet qui offre un ensemble de services
accessibles uniquement à partir des postes du réseau local. C’est une application à 3 niveaux, donc
l’architecture est partagée entre :

• Un client, c’est-à-dire que l’ordinateur est demandeur de ressources, équipé d’une interface
utilisateur (généralement un navigateur web)

• Un service, chargé de fournir les ressources mais faisant appel à un autre serveur

• Des données (sous forme de liste) qui sont fournis à l’application.

3.2 Conception détaillée

A ce niveau, nous allons entamer la partie conception détaillée au cours de laquelle nous
illustrons notre conception par la présentation de diagramme de classes et des diagrammes de séquences.

23
Chapitre 3. Conception détaillée et méthodologie de la planification des tâches

3.2.1 Diagramme de classes

Le diagramme de classes fournit une vue globale d’un système en présentant ses classes, ses
interfaces, ses collaborations, et les relations entre elles. La figure 3.1 représente le diagramme des
classes de notre travail :

Figure 3.1 : Diagramme des classes

3.2.2 Diagrammes de séquences

La description textuelle des cas d’utilisation permet de communiquer facilement et précisément

avec les utilisateurs. En revanche, le texte présente certaines limites puisqu’il est difficile de montrer
la succession des enchainements. Il est donc recommandé de compléter la description textuelle par
un diagramme de séquences. Dans cette section, nous présentons quelques diagrammes de séquences
pour des scénarios susceptibles d’avoir lieu dans notre système, afin de mettre en évidence l’aspect
dynamique de l’application.

24
Chapitre 3. Conception détaillée et méthodologie de la planification des tâches

3.2.2.1 Diagramme de séquences relatif à l’authentification

La figure 3.2 décrit le scénario de l’authentification :

Figure 3.2 : Diagramme de séquence relatif à l’authentification

3.2.2.2 Diagrammes de séquences relatifs à la gestion des utilisateurs

Dans cette partie nous présentons quelques diagrammes de séquences pour des scénarios relatifs
à la gestion des utilisateurs.
Ajouter un nouvel utilisateur La figure 3.3 décrit le scénario de l’ajout d’un utilisateur :

25
Chapitre 3. Conception détaillée et méthodologie de la planification des tâches

Figure 3.3 : Diagramme de séquences relatif à l’ajout d’un utilisateur

Consulter un utilisateur La figure 3.4 décrit le scénario de consultation d’un utilisateur :

Figure 3.4 : Diagramme de séquences relatif au consultation d’un utilisateur

26
Chapitre 3. Conception détaillée et méthodologie de la planification des tâches

3.2.2.3 Diagrammes de séquences relatifs à la gestion des projets/modules

Dans cette partie nous présentons quelques diagrammes de séquences pour des scénarios relatif
à la gestion des projets.
Créer un projet/catégorie
La figure 3.5 décrit le scénario de création d’un projet/catégorie :

Figure 3.5 : Diagramme de séquences relatif à la création d’un projet

27
Chapitre 3. Conception détaillée et méthodologie de la planification des tâches

Modifier un projet La figure 3.6 décrit le scénario de modification d’un projet :

Figure 3.6 : Diagramme de séquences relatif à la modification d’un projet

28
Chapitre 3. Conception détaillée et méthodologie de la planification des tâches

Supprimer un projet La figure 3.7 décrit le scénario de supression d’un projet/module :

Figure 3.7 : Diagramme de séquences relatif à la suppression d’un projet

29
Chapitre 3. Conception détaillée et méthodologie de la planification des tâches

3.2.2.4 Diagramme de séquence relatif à la gestion des tickets

Dans cette partie nous présentons le diagramme de séquences pour le scénario relatif à la gestion
des tickets.
Créer un ticket La figure 3.8 décrit le scénario de création d’un ticket :

Figure 3.8 : Diagramme de séquences relatif à la création d’un ticket

30
Chapitre 3. Conception détaillée et méthodologie de la planification des tâches

3.3 Planification des tâches

3.3.1 Planification des releases

Dans la représentation suivante, nous illustrons la planification des différentes release du projet.
Chacune de ces versions dispose d’un ensemble de fonctions distribuées pour effectuer des sprints.

3.3.2 Diagramme de Gantt

Le diagramme de Gantt couramment utilisé dans la gestion de projets est l’un des outils les
plus populaires pour montrer visuellement la progression des différentes activités plus efficacement.
Les tâches qui composent le projet. Il vous permet de visualiser l’horaire qui change au fil du temps
La tâche à accomplir. Au cours de ce projet, nous avons fixé un temps approximatif, non Ne doit pas
dépasser.

Figure 3.9 : Diagramme de Gantt

3.3.3 Backlog produit

Dans la méthode Agile, un backlog de produit est une liste ordonnée de livrables qui nécessitent
être implémentées dans le cadre d’un développement de produit. C’est un artefact de prise de décision
qui nous aide à estimer, affiner et hiérarchiser tout ce que nous voulons atteindre.

3.3.3.1 Backlog release 1

Les tâches effectuées lors du premier release sont dans le tableau 3.1 :

31
Chapitre 3. Conception détaillée et méthodologie de la planification des tâches

Tableau 3.1 : Backlog produit Release 1

ID
ID Use case user User Story Priorité
story
— La partie
d’authentification
— Le système affiche
à l’administrateur
un formulaire à
remplir contenant
les informations d’un
utilisateur afin de créer
Gestion des un nouveau user.
1 1.1 Forte
utilisateurs
— l’affichage de la liste des
utilisateurs
— L’administrateur
modifie les informations
d’un utilisateur
— L’administrateur
supprime un utilisateur
,

3.3.3.2 Backlog release 2

Les tâches effectuées lors du deuxième release sont dans le tableau 3.2 :

Tableau 3.2 : Backlog produit Release 2

ID
ID Use case user User Story Priorité
story
— La création d’un
projet/catégorie
— L’affichage de la liste des
catégories
— L’administrateur
modifie les informations
d’une catégorie
Gestion des
2 2.1 — L’administrateur Elevée
projets/catégories
supprime un catégorie
— Le système affiche les
gauges de performances
pour chaque catégorie
(présentée par une
équipe)

3.3.3.3 Backlog release 3

Les tâches effectuées lors du troisième release sont dans le tableau 3.3 :

32
Chapitre 3. Conception détaillée et méthodologie de la planification des tâches

Tableau 3.3 : Backlog produit Release 3

ID
ID Use case user User Story Priorité
story
— La création des
différents types de
user avec leurs droits
— La création de la gestion
des tickets
— La gestion de
l’affectation des tickets
Gestion des
3 3.1 — l’affichage de la liste des Forte
tickets
utilisateurs
— L’administrateur
modifie les informations
d’un utilisateur
— L’administrateur
supprime un utilisateur

3.3.3.4 Backlog release 4

Les tâches effectuées lors du troisième release sont dans le tableau 3.4 :

Tableau 3.4 : Backlog produit Release 4

ID
ID Use case user User Story Priorité
story
— L’intégration d’un outil
Gestion des partage d’écran
4 4.1 Moyenne
interventions — L’ajout du live chat

3.4 Conclusion

Dans ce chapitre, nous nous sommes concentrés sur les aspects analytiques et conceptuels de
notre application ainsi que sur la base de données. Pour la phase d’analyse, nous avons défini les
différents cas d’utilisation puis nous les avons traduits en diagrammes UML. Tels que le diagramme
de classes, le diagramme de cas d’utilisation et le diagramme de séquences, ainsi que les outils de
développement et nous avons détaillé le fonctionnement global de notre application.

33
 Chapitre 4

Phase de réalisation

Plan
1 Les environnements matériel et logiciel . . . . . . . . . . . . . . . . . . . . . 35

2 Création de prototypes des interfaces . . . . . . . . . . . . . . . . . . . . . . 36

3 La réalisation de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Tests fonctionnels de l’application . . . . . . . . . . . . . . . . . . . . . . . . 51

5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Chapitre 4. Phase de réalisation

Introduction

La réalisation est l’aboutissement de la phase d’analyse et de la conception. Il s’agit dans

ce chapitre de présenter notre application spécifiée dans le chapitre précédent. La première chose à
faire est de spécifier l’environnement matériel et logiciel que nous avons utilisés lors de la phase de
développement. Ensuite, nous exposons les interfaces et les fonctionnalités de cet outil.

4.1 Les environnements matériel et logiciel

4.1.1 Environnement matériel

Nous présentons dans cette section l’environnement matériel et logiciels utilisés pour le développement
de notre application. Ce projet a été réalisé sur un ordinateur portable personnel. Cet environnement
est constitué principalement de :

— Processeur : Intel I5-8300H 3.9 GHZ

— Disque Dur : 2,5 To

— Mémoire vive : 16 Go

— Système d’exploitation : Windows 10-64bits

4.1.2 Environnement logiciel

4.1.2.1 Création du logo avec Adobe Illustrator

Adobe Illustrator est un logiciel de création graphique vectorielle. Il fait partie de la gamme
Adobe, peut être utilisé indépendamment ou en complément de Photoshop, et offre des outils de dessin
vectoriel puissants.

4.1.2.2 Création design les interfaces avec Photoshop

Photoshop est un logiciel de retouche, de traitement et de dessin assisté par ordinateur, lancé
en 1990 sur MacOS puis en 1992 sur Windows. Édité par Adobe, il est principalement utilisé pour le
traitement des photographies numériques, mais sert également à la création d’images.

4.1.2.3 React

React (aussi appelé React.js ou ReactJS) est une bibliothèque JavaScript libre développée par
Facebook depuis 2013. Le but principal de cette bibliothèque est de faciliter la création d’application
web monopage, via la création de composants dépendant d’un état et générant une page (ou portion)
HTML à chaque changement d’état.

35
Chapitre 4. Phase de réalisation

4.1.2.4 NodeJS

NodeJS est une plateforme logicielle libre en JavaScript, orientée vers les applications réseau
évènementielles hautement concurrentes qui doivent pouvoir monter en charge. Concrètement, Node.js
est un environnement bas niveau permettant l’exécution de JavaScript côté serveur.

4.1.2.5 Postgre

PostgreSQL est un système de gestion de base de données relationnelles et objet (SGBDRO).

C’est un outil libre disponible selon les termes d’une licence de type BSD. Ce système est comparable
à d’autres systèmes de gestion de base de données, qu’ils soient libres (comme MariaDB et Firebird),
ou propriétaires (comme Oracle, MySQL, Sybase, DB2, Informix et Microsoft SQL Server). Comme
les projets libres Apache et Linux, PostgreSQL n’est pas contrôlé par une seule entreprise, mais est
fondé sur une communauté mondiale de développeurs et d’entreprises.

4.2 Création de prototypes des interfaces

Afin d’avoir une image claire de nos interfaces, nous avons opté à la solution de créer des
prototypes avec un outil de design des interfaces (dans notre cas nous avons choisit Adobe Photoshop)
afin de garantir que l’usabilité et les fonctionnalités de notre application seront bien présentes selon
l’interface ouverte :

4.2.1 Création d’un logo pour notre application

Afin d’avoir une identité Sopra, nous avons créé un logo avec le logiciel Adobe Illustrator et
nommé notre application Sopra Tracker comme présente la figure 4.1 :

Figure 4.1 : Logo Sopra Tracker

36
Chapitre 4. Phase de réalisation

4.2.2 Interface d’authentification

Nous avons fait le design d’imagination de notre page d’authentification pour qu’elle soit claire
et contient les différents nécessités dans la figure 4.2 :

Figure 4.2 : Design de page d’authentification

4.2.3 Interface création d’un compte

L’interface suivante sera pour la création d’un compte, selon notre prescriptions, ça devra
contenir les champs nécessaire qu’un profil d’un acteur de notre application devrait avoir comme
leur nom, prénom, addresse mail et ces identifiants de connexion (identifiant et mot de passe) comme
montre la figure 4.3 :

Figure 4.3 : Design de page d’authentification

37
Chapitre 4. Phase de réalisation

4.2.4 Interface vue administrateur

La vue administrateur devra avoir la liste de tous les projets et avoir accès au liste des utilisateurs
de l’application ainsi que les statistiques des projets présentées par des gauges comme montre la figure
4.4 :

Figure 4.4 : Interface vue administrateur

4.2.5 Interface création d’un ticket

Cette interface est pour la création d’un ticket, donc il faut avoir un champ pour le type du
ticket (tâche, anomalie, demande d’information,...), un titre, une description et la priorité du ticket
comme dans la figure 4.5 :

38
Chapitre 4. Phase de réalisation

Figure 4.5 : Interface création d’un ticket

4.2.6 Interface dashboard pour le client

Cette dashboard (figure 4.6) est dédiée au client, donc il faut qu’elle présente les tickets qu’il a
ouvert avec leurs status :

Figure 4.6 : Interface dashboard pour le client

39
Chapitre 4. Phase de réalisation

4.3 La réalisation de l’application

Cette partie détaillera la solution finale obtenue. Ainsi, nous présentons notre application à
travers des imprimés écrans correspondants au travail réalisé.

4.3.1 L’authentification

La figure 4.7 ci-dessous illustre l’interface d’accès à l’application. Elle implémente la fonction
qui consiste à vérifier l’identité de l’utilisateur par un login et un mot de passe, afin de lui autoriser
l’accès à cette application et lui offrir les services dédiés à son profil.

Figure 4.7 : Interface d’authentification

40
Chapitre 4. Phase de réalisation

4.3.2 Espace Administrateur

Dans cette partie nous présentons les interfaces de l’administrateur :

4.3.2.1 Interface principale de l’administrateur

La figure 5.4 ci-dessous montre le menu principal de l’administrateur, avec les différentes
fonctionnalités accessibles :

Figure 4.8 : Interface principale de l’administrateur

4.3.2.2 Interface de consultation de la liste des projets

La figure ci-dessous 4.8 présente l’interface des projets, où l’administrateur est en mesure de
consulter les détails de tous les projets, comme il à la main aussi et de les gérer soit par ajout, en
cliquant sur le bouton «Nouvel élément », soit par modification ou par suppression, en cliquant sur le
lien «Modifier ». Cette interface offre aussi la possibilité de consulter les détails du projet, ainsi que la
liste de ses documents.

Figure 4.9 : Interface de consultation de la liste des projets

41
Chapitre 4. Phase de réalisation

4.3.2.3 Interface de l’ajout d’un nouveau projet

La figure ci-dessous 4.9 illustre le formulaire de demande de la saisie des différentes informations
concernant un projet :

Figure 4.10 : Interface du formulaire de saisie d’un projet

4.3.2.4 Interface des statistiques des projets

La figure 4.11 ci-dessous présente la planification de l’ensemble des projets. En cliquant sur un
projet particulier, les détails du planning du projet sélectionné sont affichés.

Figure 4.11 : Interface des statistiques des projets

4.3.3 Espace du chef de projet

Dans cette partie nous présentons les interfaces relatifs au chef de projet.

42
Chapitre 4. Phase de réalisation

4.3.3.1 Interface principale du chef de projet

La figure 4.12 ci-dessous montre le menu principal du chef de projet avec les différentes fonctionnalités
accessibles.

Figure 4.12 : Interface principale du chef de projet

4.3.3.2 Interface de consultation de la liste des tickets

La figure 4.13 ci-dessous illustre l’interface des tâches où le chef de projet est en mesure de
consulter la liste de toutes les tâches, et de les gérer soit par ajout, en cliquant sur le bouton «créer un
ticket » soit par modification ou par suppression. Cette interface offre aussi la possibilité de consulter
les détails d’une tâche.

Figure 4.13 : Interface de consultation de la liste des tickets

43
Chapitre 4. Phase de réalisation

4.3.4 Espace du collaborateur de maintenance

Dans cette partie nous présentons les interfaces relatifs au collaborateur de maintenance.

4.3.4.1 Interface principale du collaborateur de maintenance

La figure 4.13 ci-dessous montre le menu principal du chef de projet avec les différentes fonctionnalités
accessibles.

Figure 4.14 : Interface principale du collaborateur de maintenance

44
Chapitre 4. Phase de réalisation

4.3.4.2 Interface de consultation de la liste des tickets

La figure 4.14 ci-dessous illustre l’interface des tâches où le chef de projet est en mesure de
consulter la liste de toutes les tâches, et de les gérer soit par ajout, en cliquant sur le bouton «nouvelle
tâche » soit par modification ou par suppression. Cette interface offre aussi la possibilité de consulter
les détails d’une tâche.

Figure 4.15 : Interface de consultation de la liste des tickets

45
Chapitre 4. Phase de réalisation

4.3.4.3 Interface de consultation et mise à jour d’un ticket

La figure 4.15 ci-dessous illustre l’interface des tâches où le chef de projet est en mesure de
consulter la liste de toutes les tâches, et de les gérer soit par ajout, en cliquant sur le bouton «nouvelle
tâche » soit par modification ou par suppression. Cette interface offre aussi la possibilité de consulter
les détails d’une tâche.

Figure 4.16 : Interface de consultation et mise à jour d’un ticket

46
Chapitre 4. Phase de réalisation

4.3.5 Espace du client

Dans cette partie nous présentons les interfaces relatifs au client.

4.3.5.1 Interface principale du client

La figure 4.16 ci-dessous montre le menu principal du client, avec les différentes fonctionnalités
accessibles.

Figure 4.17 : Interface principale du client

47
Chapitre 4. Phase de réalisation

4.3.6 La création d’un ticket par le client

La figure 4.17 ci-dessous illustre le formulaire permettant de créer un ticket :

Figure 4.18 : Création d’un ticket

48
Chapitre 4. Phase de réalisation

4.3.6.1 Interface de consultation et mise à jour d’un ticket

La figure 4.18 ci-dessous illustre l’interface des tâches où le chef de projet est en mesure de
consulter la liste de toutes les tâches, et de les gérer soit par ajout, en cliquant sur le bouton «nouvelle
tâche » soit par modification ou par suppression. Cette interface offre aussi la possibilité de consulter
les détails d’une tâche.

Figure 4.19 : Interface de consultation et mise à jour d’un ticket

49
Chapitre 4. Phase de réalisation

4.3.6.2 Interface d’ouverture d’un live chat

La figure 4.19 ci-dessous illustre le popup ou le client peut communiquer avec le collaborateur
de maintenance via des messages instantantés.

Figure 4.20 : Interface d’ouverture d’un live chat

50
Chapitre 4. Phase de réalisation

4.4 Tests fonctionnels de l’application

Le tests fonctionnels de notre application sont illustrés dans le tableau 4.1 ci dessous.

Tableau 4.1 : Tests effectués

Cas de Test Démarche Comportement attendu Résultat
Le client crée un ticket envoyé
Créer un ticket Le ticket est créé. Conforme
par la suite à l’équipe adéquat
Le chef de projet valide le
ticket envoyé par le client, et
Fermer ticket l’utilisateur change l’état du Le ticket est marqué terminé. Conforme
ticket quand il termine son
traitement.
Marquer
Le membre accède à la tâche La tâche est marquée
l’avancement Conforme
terminé et modifie son état. terminée.
de tâche
L’utilisateur accède à la liste
Consulter les Une page contenant les détails
des éléments et clique le titre Conforme
détails d’un ticket du ticket sélectionné s’affiche
du ticket à consulter.
L’utilisateur accède à la liste
Supprimer un L’élément est supprimé de la
et sélectionne un ticket à Conforme
ticket de la liste liste.
supprimer.

4.5 Conclusion

Dans ce dernier chapitre, nous avons décrit l’environnement du travail et les principales interfaces
du projet et nous avons clôturé le chapitre par les tests fonctionnels de l’application.

51
Conclusion et Perspective

Au cours de ce projet, nous avons contribué à la mise en place d’une solution de suivi des projets
et de gestion de leurs tickets. Pour réaliser ce travail, nous avons présenté dans un premier temps le
cadre général du projet où nous avons présenté l’entreprise d’accueil ainsi que l’étude de l’existant.
Ensuite, nous avons effectué un état de l’art des notions traitées dans notre sujet de PFE, avant de
procéder à l’analyse et la spécification des besoins de notre application. Enfin, cette analyse a servi
dans la conception et l’implémentation de la nouvelle application. Ce projet nous a été bénéfique, dans
la mesure où il nous a permis de mettre en œuvre nos connaissances théoriques par la pratique des
nouvelles technologies. Pour pouvoir réaliser ce projet, nous avons intégré le milieu professionnel dans
lequel SopraHR nous a appris à évoluer en répondant aux exigences et aux contraintes techniques ; et
en nous inculquant des notions et des habitudes du professionnalisme.
Ce travail répond aux besoins préalablement fixés mais il pourra évidemment être amélioré et
optimisé par l’ajout de nouvelles fonctionnalités comme la gestion de mailing, la synchronisations des
projets selon les catégories, la gestion des réunions, l’enquête de satisfaction clients et la génération
des rapports au format PDF.

52
Bibliographie

[1] S. STS. [Consulté le 11-Avril-2019]. (), adresse : https : / / fr . wikipedia . org / wiki / M % C3 %
A9thode_agile.

[2] Sopra-Steria. [Accès le 5-Mars-2019]. (), adresse : http://www.soprasteria.com/carrieres/

consultation-offre?ref=SE/AIX/IED/1001448.

53
 Résumé
Ce travail a été réalisé pour l’obtention du Diplôme National d’Ingénieur en Génie Logiciel au
sein de l’École Supérieure privée des Sciences Appliquées et de Management (SESAME). Il a
pour objectif de mettre en place une solution de suivi des projets et gestion de leurs tickets au
sein de la société SopraHR Software.

Mots clés : React, NodeJS, Postgres, UML,Solution,Projet,Ticket

Abstract
This work was carried out to obtain the National Engineering Degree in software engineering in
Private School of Applied Sciences and Management (SESAME). It aims to develop a solution
of monitoring project and management of their tickets for the company SopraHR Software.

Keywords : React, NodeJS, Postgres, UML,Solution,Projet,Ticket

@tek-up.de : ¨ž¤rtk˜¯ d§rb˜ 71 709 899 : H•Af˜ 71 709 944 :  Ah˜ TžA§C
2080 T˜ zŒ˜ ¨w˜wnt˜ Wq˜ Tž rWJ P. 2
Z.I Chotrana 2 Pôle Technologique Elgazala Tél : 71 709 944 Fax : 71 709 899 Email : @tek-up.de