Réf : 2020/ II3 / ......

Soutenu à la session de septembre 2020

Université de la Manouba
École Nationale des Sciences de l’Informatique
Rapport de Mémoire de Fin d’Etudes

Présenté en vue de l’obtention du titre

D’INGENIEUR EN INFORMATIQUE

Par]

Amairi Saifeddine

Sujet : Conception et Développement d’une plateforme

d’e-ticketing et help-desk PrimaSup 360

Organisme d’accueil :PrimaFrance System

Nom du Responsable :Mme Morgado Anne-Marie

Encadré par :Mr Ghanem Alexandre

Supervisé par :Mr Elleuch Ahmed

Adresse :4 Avenue Laurent Cely 92600, Asniéres sur Seine, Tour d’Asniéres
HALL D

Tél :+33156838742
Appréciations, signature et cachet de
l’encadrant
Dédicaces

Avec toute gratitude et amour je dédie ce modeste travail ..

À mes chers parents, pour vos conseils et vos prières qui m’ont toujours accompagné,pour
les sacrifices que vous avez consenti pour mon instruction et mon bien être.
À mes chèrs frères et ma chère sœur, pour l’amour, la tendresse et la gentillesse dont vous
m’avez toujours entouré,
À mon oncle Mohamed pour le soutien que tu m’a accordé,
À mes grand-mères et mon grand-père que Dieu le tout puissant vous comble de santé, de
bonheur et vous prouve une longue vie pleine de joie parmi nous,
À tous mes amis, en souvenir des plus beaux instants qu’on a passé ensemble,
Aussi bien à tous ceux qui m’ont aidé,
Merci.

AMAIRI Saifeddine

ii
Remerciements

Mes remerciements les plus intenses et les plus sincères s’adressent à tous ceux qui, de
près ou de loin, ont contribué au succès de ce projet.
J’exprime ma sincère gratitude à Monsieur Ahmed Elleuch qui, malgré ses responsa-
bilités et ses devoirs, a fait de moi l’une de ses priorités et a toujours été là pour m’aider
et me guider.
Je tiens à remercier mon encadrant professionnel : Monsieur Alexandre Ghanem
pour la confiance qu’il m’a accordée, son assistance et son suivi permanent. Que ce travail
soit un modeste témoignage de ma haute considération et de mon profond respect.
Je suis infiniment reconnaissante à toutes les équipes de PrimaFrance d’avoir créé un
environnement de travail confortable et encourageant et pour leur esprit d’accueil. Je suis
honorée d’être parmi vous.
Je souhaite également remercier les membres du jury pour leur volonté de m’accorder
leur attention et d’évaluer mon travail.
Enfin, je ne laisserai pas passer cette occasion sans adresser mes remerciements à tous
nos professeurs pour la qualité de l’enseignement qu’ils nous ont prodigué durant nos
études.

iii
Table des matières

Introduction générale 1

1 Présentation générale 2
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Présentation de l’entreprise d’accueil . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 PrimaFrance Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 Les service de PrimaFrance . . . . . . . . . . . . . . . . . . . . . . 2
1.2.3 Domaine d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Le contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.2 Objectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.3 Travail demandé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.1 Les méthodes agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.2 Méthode de travail adoptée . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Étude préalable 8
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Étude Théorique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Évolution des procédures d’assistance avec le temps . . . . . . . . 8
2.2.2 Help desk et les systèmes des tickets des support . . . . . . . . . . . 9
2.3 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Étude des produits externes . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Étude des produits internes . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3 Les limites des systèmes existantes et la solution proposée . . . . . 14
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Analyse et spécification des besoins 16

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

iv
Table des matières v

3.2 Analyse des besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 Identification des Acteurs . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Spécification des besoins fonctionnels . . . . . . . . . . . . . . . . . 17
3.2.3 Spécification des besoins non fonctionnels . . . . . . . . . . . . . . . 18
3.3 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Diagrammes d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Conception 28
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Conception globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.1 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.2 Architecture fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.3 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Diagramme de paquetages . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.1 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.2 Schéma relationnel de la base de données . . . . . . . . . . . . . . 36
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Realisation 38
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.3 Frameworks et technologies . . . . . . . . . . . . . . . . . . . . . . 39
5.3 Travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.1 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.2 Interfaces de configurateur . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.3 Interface environnement . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.4 Interface incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.5 Interface de gestion d’accès de documents . . . . . . . . . . . . . . 43
5.4 sécurité applicative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Conclusion et perspectives 45

Annexe 46

Netographie 49
Table des figures

1.1 Processus de développement SCRUM . . . . . . . . . . . . . . . . . . . . 6

1.2 Visual Management board de Primafrance . . . . . . . . . . . . . . . . . . 7

2.1 Mantis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Support Oracle Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Support Hexagon ecosys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 Diagramme de cas d’utilisation pour le superAdmin . . . . . . . . . . . . . 19

3.2 Diagramme de cas d’utilisation partie cliente . . . . . . . . . . . . . . . . . 20
3.3 Diagramme de cas d’utilisation partie entreprise . . . . . . . . . . . . . . . 21
3.4 Diagramme de séquence : demander un support . . . . . . . . . . . . . . . 22
3.5 Diagramme de séquence : gestion des licences . . . . . . . . . . . . . . . . 23
3.6 Diagramme d’activité : demander un support . . . . . . . . . . . . . . . . . 24
3.7 Diagramme d’activité : développement . . . . . . . . . . . . . . . . . . . . 25
3.8 Diagramme d’activité : gestion des licences . . . . . . . . . . . . . . . . . . 26

4.1 Diagramme de déploiements . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Architecture fonctionnelle du système . . . . . . . . . . . . . . . . . . . . . 30
4.3 Architecture logique partie Backend . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Architecture logique partie Frontend . . . . . . . . . . . . . . . . . . . . . 32
4.5 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6 Première partie du diagramme de classe . . . . . . . . . . . . . . . . . . . 34
4.7 Deuxième partie du diagramme de classe . . . . . . . . . . . . . . . . . . . 36

5.1 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2 Interface d’ajout d’utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3 Interface d’ajout des rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4 Interface environnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5 Interface incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.6 Interface d’ajout d’un bug . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.7 Interface d’ajout d’un ticket . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.8 Interface accès document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

vi
Table des figures vii

5.9 OWASP Dependency Check . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.10 Matrices des risques PAQSSI . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.11 Interface entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.12 Interface client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Liste des tableaux

1.1 Tableau comparatif des méthodes agiles. . . . . . . . . . . . . . . . . . . . 5

2.1 Tableau comparatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

viii
Liste des sigles et acronymes

PMF PrimaFrance
PM Project Management
FAQ Frequently Asked Questions
EDF Electricité De France
IBM International Business Machines Corporation
REX Registered Exporter system
SCCM System Center Configuration Manager
REST Representational State Transfer
HTTP Hypertext Transfer Protocol
HTML Hyper Text Markup Language
JPA Java Persistence API
OWSAP Open Web Application Security Project

ix
Introduction générale

es entreprises et le monde professionnel cherchent toujours à donner à leurs clients le

L meilleur service possible en leur accompagnant dans leurs projets pour les rendre sa-
tisfaits, à mesure que les entreprises se développent et les besoins en service à la clientèle
augmentent. Bien que le traitement de chaque cas individuellement puisse fonctionner au
début, cela deviendra rapidement difficile à gérer.

Une des manières la plus rentable pour suivre tous les clients et apporter des solutions
efficaces c’est d’avoir une plate-forme pour le support. Une telle application va automati-
ser, centraliser et faciliter cette procédure. En offrant à ses utilisateurs la possibilité d’ouvrir
des tickets de support, un système d’assistance ou help-desk représente une ressource des-
tinée à fournir au client ou à l’utilisateur final l’adaptation aux problématiques concrètes.

Un service d’assistance fournit un daschbord central qui affiche facilement toutes les
informations et un système de e-ticketing en ligne qui met en file d’attente les demandes
entrantes provenant de plusieurs sources. Cela permet évidement de s’assurer de bien gé-
rer les demandes d’assistance et d’organiser, de classer et de hiérarchiser efficacement les
tâches pour que les équipes du support les traitent efficacement.

Dans ce contexte, le projet PrimaSup consiste en la conception et la mise en œuvre d’une

application web d’e-ticketing et de gestion des incendies en ligne tout en offrant d’autres
fonctionnalité dans ce même cadre. Cette plate-forme est hébergée sous le nom de sup-
port.domainePrimafrance.com.

Ainsi, PrimaSup présente un outil informatique sécurisé de partage des informations et

des actions effectuées inter-entreprises. C’est à la fois une manière ergonomique mais aussi
intuitive de coordonner et d’informer rapidement et efficacement les différentes personnes
concernées, de professions différentes, aidant à la prise en charge des systèmes de support.
Chapitre 1

Présentation générale

1.1 Introduction
Ce premier chapitre présente l’organisme d’accueil où nous avons effectué notre stage
de fin d’étude, le contexte général du projet ainsi que la présentation du sujet particulière-
ment les objectifs de travail. Ensuite, nous discutons les méthodologies de travail tout en
précisant la méthode de gestion le plus adoptée pour notre projet.

1.2 Présentation de l’entreprise d’accueil

Dans cette première section de ce chapitre, nous faisons une description de l’entreprise
d’accueil et son domaine d’activité.

1.2.1 PrimaFrance Systems

PrimaFrance est une société qui a été créée depuis 1997 par une équipe pluridisciplinaire
de consultants métiers et consultants informatiques expérimentés. Elle offre à la fois une
expertise et des solutions de gestion de portefeuilles et gestion de projets conçues en fonction
des besoins, des processus, des métiers et de la maturité de ses clients.
Parmi les consultants PrimaFrance, nous distinguons d’une part des consultants PM
(Project Management), consultants fonctionnels et métiers de la gestion de projet, et
d’autre part des consultants IT (Information Technology), consultants informatiques et
système d’information.

1.2.2 Les service de PrimaFrance

Les services de Primafrance peuvent être regroupés en quatre grands axes. Tout d’abord,
PrimaFrance offre une expertise des systèmes d’information projets où les consultants IT
allient l’expertise fonctionnelle à celle des systèmes d’information. Ainsi, ils sont capables

2
1.3. Le contexte du projet 3

de concevoir et de réaliser des interfaces entre les différentes applications de Project Mana-
gement. Puis, une expertise en gestion de projet en préconisant des solutions fonctionnelles
et en effectuant des missions d’expertise métier et d’organisation projet. Ainsi qu’une ex-
pertise des solutions PrimaVera, le logiciel le plus connu et le plus utilisé dans le domaine
de PM, cependant les consultants fonctionnels sont donc impliqués dès la phase initiale
d’analyse et de définition des besoins et restent l’interlocuteur privilégié du chef de pro-
jet, jusqu’à la fin de l’implémentation. Finalement, PrimaFrance offre aussi une assistance
technique efficace à ses clients voire même une suivie continue permettant de gérer tout
incident qui peut arriver, ainsi que toute sollicitation du support à tout moment.

1.2.3 Domaine d’activité

L’expertise de PrimaFrance couvre le conseil en Management de projets, l’implémen-
tation de la suite logicielle et son intégration aux autres applications stratégiques des
entreprises. Ainsi, les activités s’organisent autour de six axes :
— organisation des projets ;
— accompagnement au changement tout au long de la réalisation des projets ;
— implementation des solutions ;
— intégration du système d’information projet ;
— support technique ;
— transfert des connaissances et une collaboration étroite.

1.3 Le contexte du projet

Ce projet a été effectué dans le cadre du stage de fin d’études présenté en vue de
l’obtention du titre d’ingénieur en informatique de l’Ecole National des Sciences de l’In-
formatique ENSI. Le travail a été réalisé pendant 6 mois à partir de mars 2020 pour la
société PrimaFrance qui suit ses clients tout au long de la durée de vie de leurs projets,
en les accompagnant dans l’organisation et la mise en œuvre de systèmes de pilotage et de
gestion de projet. Ainsi, Le projet est intitulé PrimaSup 360, il s’agit d’une plateforme du
support client s’inscrivant dans ce cadre. Le système va aider les clients à créer un ticket de
support concernant un problème rencontré sur les outils de Project Management de Pri-
maFrance. Notre mission est d’élaborer un système qui soit le plus ergonomique possible
et qui puissent répondre au maximum aux attentes des utilisateurs futurs.

1.4 Présentation du projet

Ce paragraphe présente deux principales parties qui sont la problématique du sujet
ainsi que les principaux objectifs du travail.
1.5. Méthodologie de travail 4

1.4.1 Problématique
L’absence d’un système centralisé qui regroupe tous les clients ainsi que toutes les de-
mandes d’interventions chez eux, va causer des pertes de temps et d’argent pour l’ensemble
des intervenants : l’entreprise et évidement leur collaborateurs. Ainsi, les agents du service
client auront besoin de dépenser plus d’énergie et de temps pour donner aux clients le
meilleur service. Donc, afin de réduire au maximum le coût de la prise en charge des tickets
dans le cadre du maintien, de l’assistance et du support. Notre but, est de développer un
système qui fournit des accès adaptés aux différents utilisateurs potentiels, tout en gardant
une architecture de travail simple et une interconnexion permanente.

1.4.2 Objectif du projet

Au-delà de l’adaptation nécessaire à la compréhension du domaine de gestion de projet,
et plus spécifiquement de la prise en charge de système d’assistance technique et client, il est
nécessaire de bien cerner les besoins et les attentes de chaque intervenant pour construire un
produit final à l’écoute des besoins de chacun, capable de présenter de nombreux avantages
sans pour autant être difficile d’utilisation. D’où, Le présent projet a comme objectif de :
— concevoir et Développer un système d’e-ticketing ;
— faciliter le support et l’assistance client ;
— alimenter une Base des données des interventions (historique) et un REX (alimentant
une FAQ).

1.4.3 Travail demandé

Nous avons eu pour missions au sein de PrimaFrance durant le stage de concevoir et
développer un système de help desk et de support en ligne, de réaliser l’étude de faisabilité
et du marché, de rédiger les spécification générales et détaillée, de mettre en place de
l’infrastructure cible, de concevoir la base des données et l’échange des données, de travailler
avec les méthodes agiles et d’intégrer les méthodes DevOps, d’implémenter la solution, de
sécuriser et de tester l’application. Aussi dans ce même laps de temps, il faudra également
s’imprégner de scénarii d’utilisations susceptibles de représenter un usage type du produit et
donc de mettre en avant les avantages et les inconvénients qu’il présente pour se confronter
au plus vite aux réalités d’utilisation et de conception.

1.5 Méthodologie de travail

Dans cette section, nous abordons la méthode de management que nous avons utilisé
durant notre stage et qui reflète assez bien notre façon de procéder.
1.5. Méthodologie de travail 5

1.5.1 Les méthodes agiles

La notion de méthode agile a été officialisée depuis environ vingt ans. Par conséquent,
Il existe plusieurs méthodes qui sont définit comme des méthodes agiles. Les plus connues
sont XP et Scrum. Les méthodes Agiles sont des groupes de pratiques qui s’appliquent ac-
tuellement aux projets de développement en domaine informatique et en d’autres domaines
éventuellement. Elles se veulent plus pragmatiques que les anciennes méthodes. Elles im-
pliquent au maximum le client et permettent une grande réactivité à ses demandes. En
outre, elles visent la satisfaction du besoin du client. Cependant, pour mieux clarifier les
principes et les fondements de cette méthode, nous allons détailler quelques avantages des
méthodes agiles. Ces méthodes permettent d’offrir des fonctionnalités utiles et pratiques
tels que l’interaction continu avec les différents intervenants dans un projet, la construction
d’un produit opérationnel et la collaboration avec le client. Elles sont avérées plus efficaces
dans le traitement de l’évolution des besoins au cours de la phase de développement[URL1].

1.5.2 Méthode de travail adoptée

Pour mieux choisir la méthode de travail adoptée, nous allons présenté un tableau
comparatif des méthodologies agiles les plus répandues.

SCRUM
Diviser le projet en des ité-
rations nommées SPRINTS
allant de deux à quatre se-
maines.
Après la planification du
SPRINT et de ses fonction-
nalités à développer, il y
aura plus de modification
dans les spécifications.
Au début de chaque
SPRINT, l’équipe attribut
une priorité à chaque fonc-
tionnalité et commence le
développement de celle ci.
XP
Les itérations durent d’une
à deux semaines.
Le développement est plus
ouvert aux changements,
le client peut remplacer
une fonctionnalité avec une
autre de même complexité.
Le client décide de la prio-
rité de chaque fonctionna-
lité, l’équipe est alors ame-
née à les développer en pre-
mier.

Table 1.1 – Tableau comparatif des méthodes agiles.

[URL2]

À partir de ce tableau comparatif Table 1.1, nous pouvons conclure que la méthode
SCRUM s’avère la plus adéquate pour notre cas. En effet, pour notre projet, le client ne
décide pas les priorités de chaque fonctionnalité mais c’est plutôt à nous de gérer toutes
1.5. Méthodologie de travail 6

les étapes de réalisation. Aussi, la durée d’un sprint ça prend de trois à quatre semaines
au maximum et c’est bien le cas pour la méthode Scrum. De plus, lors de développement
de PrimaSup, nous nous somme concentrés sur l’aspect du travail d’équipe, d’où cette
méthode semble bien la plus efficace pour la réalisation de notre projet. Donc, la méthode
agile SCRUM a été choisi comme méthodologie du travail tous le long de la réalisation de
ce projet et plus précisément la méthode de gestion visuelle (visual Management). Cette
méthode va être détaillée ultérieurement dans ce même chapitre.

Figure 1.1 – Processus de développement SCRUM

[URL3]

La figure 1.2 illustre le processus de travail en utilisant la méthodologie SCRUM. Cette

méthode de gestion définit particulièrement un jeu minimal d’acteurs qui se concrétise en
trois acteurs : le Product Owner est celui qui possède l’expertise fonctionnelle, le Scrum
Master c’est un membre de l’équipe du projet et dont la tâche principale est d’optimiser la
capacité de production et l’équipe qui prend en charge le développement du produit sans
spécialisation des rôles. Elle se base également sur des sprints pour assurer la régularité
des réunions quotidiennes (Daily SCRUM) et faire la synchronisation entre les différents
membres de l’équipe.

Visual Management
Parfois, sont mis en place aux seins des méthodes agiles des outils de Management très
particuliers basés sur une visualisation du travail pour mieux le gérer.
1.6. Conclusion 7

Le Visual Management est une façon simple et efficace d’organiser et de présenter son
travail. Il a un aspect dynamique qui lui est donnée par l’utilisation des feutres avec des
différentes couleurs, capable de donner vie au travail dans n’importe quelle structure (peu
importe la taille). C’est aussi un moyen efficace de renforcer la confiance au sein des équipes
de travail. Le tableau de bord est entièrement personnalisable en fonction de l’entreprise
c’est pourquoi nous présentons dès à présent le tableau que nous avons utilisé au sein de
PrimaFrance. Chaque membre a sa couleur. Il se décompose en plusieurs sous-parties :

Figure 1.2 – Visual Management board de Primafrance

Un numéro représente une tâche à réaliser. Il peut être placé sur le planning à la date
ou la tâche sera effectuée et migrer vers les tâches en attente ou les problèmes en cours
s’ils doivent être reportés. Chaque matin un point d’un peu plus de 5min est réalisé pour
tous les projets, afin que chacun se rende compte et connaisse les avancements. C’est
aussi le moment de mettre à jour le tableau. Cette représentation est très pratique pour
la gestion de projets. Elle permet de structurer la pensée, de nous assurer que rien n’est
oublié, d’organiser nos tâches et d’identifier nos problèmes. C’est une bonne façon aussi de
communiquer avec les autres personnes dans une entreprise. Les employés peuvent alors
interagir avec vos projets en identifiant vos problèmes ou en vous proposant de l’aide dans
des tâches qu’ils maîtrisent mieux.

1.6 Conclusion
Dans ce chapitre nous avons définit le contexte et la problématique du sujet tout en
précisant la méthodologie de travail qui va être suivie durant la réalisation du projet.
Dans le chapitre suivant, nous faisons une étude concernant les produits existants et nous
expliquons certains termes et concepts liés à notre sujet.
Chapitre 2

Étude préalable

2.1 Introduction
Dans ce chapitre nous allons présenter l’étude préalable de notre projet tout en abordons
les notions théoriques et les systèmes existants.

2.2 Étude Théorique

2.2.1 Évolution des procédures d’assistance avec le temps
Les centres de service modernes tel que nous le connaissons sont ancré dans l’histoire
du service client qui remonte à partir des plusieurs années. Les centres d’appels sont nés
dans les années 1970 avec la capacité de prendre les appels entrants et de fournir des
informations. Ce n’est que plus tard, les services d’assistances sont officiellement né. Le
terme help desk a été inventé par IBM, et il est né par nécessité. L’ordinateur personnel, ou
PC, était utilisé par des personnes travaillant dans des entreprises et par des utilisateurs
à domicile, et ils avaient besoin d’assistance. En tant que client pour être soutenu, il
devait soit appeler le fabricant de l’ordinateur, soit un fournisseur, ou tout simplement le
découvrir par lui-même. Les organisations internes ont réalisé que le meilleur pari était
d’avoir leurs propres employés pour aider les clients, plutôt que d’appeler un fournisseur
tiers pour obtenir de l’aide. Le défi est que les employés les plus qualifiés pour assister
les clients étaient généralement des développeurs ou des ingénieurs, et ils n’avaient pas les
compétences en service client nécessaires pour aider les clients très peu qualifiés. Certaines
entreprises ont lancé un processus de capture et d’expédition, afin qu’un client appelle
quelqu’un, qui prendrait les informations, les noterait, puis les transmettrait à quelqu’un
de plus technique. Au final, ces deux méthodes se sont révélées coûteuses et inefficaces.
Cependant, à un moment donné les entreprises ont réalisé la nécessité d’officialiser un
service d’assistance, un groupe de personnes qui aideraient les clients ayant des besoins de
support technique. Dans de nombreuses organisations, ces personnes ne s’assoyaient pas

8
2.3. Étude de l’existant 9

ou ne travaillaient même pas vraiment ensemble.

C’est là que les clients avaient un point de contact unique pour obtenir de l’aide, par
opposition à essayer de savoir qui ou où appeler spécifiquement pour obtenir de l’assistance.
Ce modèle centralisé obligeait de nombreuses entreprises à réorganiser leurs processus et à
embaucher les bonnes personnes avec les bonnes compétences pour soutenir correctement
leurs clients. Après, les processus et la technologie ont commencé à évoluer rapidement et
plus que jamais, l’accent est mis sur la gestion efficace et effective du service desk. Cela doit
être une partie rentable de l’entreprise, tout en offrant la récompense ultime à ses clients :
la valeur. Cette brève histoire nous a présenté la création de services d’assistance et la façon
dont ils ont évolué pour devenir des bureaux de service pleinement opérationnels.[URL4]

2.2.2 Help desk et les systèmes des tickets des support

Un help-desk est un outil organisationnel que les entreprises utilisent pour classer, gérer
et surveiller les demandes d’assistance pour les clients. Un logiciel comprenant un tableau
de bord, un service d’assistance fournit un point de contact unique et permet aux opé-
rateurs du service d’assistance de suivre, hiérarchiser et traiter les requêtes et les tâches.
Il dispose de plusieurs portails pouvant être intégrés dans un seul emplacement principal.
Par conséquent, les équipes de service d’assistance seront en mesure de gérer efficacement
plusieurs produits, services et marques à partir d’un emplacement complet. Les agents
pourront acheminer avec succès chaque ticket d’assistance vers le bon portail d’assistance
client.La gestion des tickets de support garantira que les tickets et les e-mails sont envoyés
au bon endroit et que les utilisateurs reçoivent les liens vers les bons articles de la base de
connaissances et les portails de la communauté du support client.
Un tel logiciel permet de servir efficacement les clients et de créer des opportunités pour
que les agents soient aussi productifs que possible.Aussi, Les services d’assistance mettent
en œuvre des processus pour aider à fonctionner plus efficacement, en examinant des me-
sures telles que la satisfaction du client pour déterminer l’efficacité de l’organisation et en
utilisant des technologies telles que des outils à distance, le Web, le support automatique et,
éventuellement, les médias sociaux pour étendre les canaux de support aux clients[URL5]

2.3 Étude de l’existant

Dans cette partie nous abordons les applications help-desk existantes pour une meilleure
compréhension de notre solution. Commençons, dans un premier temps, par étudier des
systèmes présents sur le marché et qui offrent des solutions pour le support et le traitement
des tickets d’incidents, ensuite nous allons spécifier quelques outils internes utilisés par
PrimaFrance pour le support client pour définir finalement le cadre du projet.
2.3. Étude de l’existant 10

2.3.1 Étude des produits externes

Il existe de nombreux systèmes de help-disk et support client, mais tous ne sont pas créés
égaux, chacun a ses propres fonctionnalités, ses avantages mais également ses inconvénients.
Dans cette section, nous examinons deux solutions existantes qui sont MantisBT et Zendesk
en faisant notamment, un processus comparatif entre ces deux systèmes.

Mantis Bug Tracker

Mantis Bug Tracker est un système Open Source de suivi des bug en ligne. L’utilisation
la plus courante de MantisBT est de suivre les défauts logiciels. Cependant, MantisBT
est souvent configuré par les utilisateurs pour servir de système de suivi des problèmes
plus génériques et d’outil de gestion de projet. C’est un système de gestion des tickets
d’incidents et d’assistance technique et fonctionnelle généralement utilisé dans des envi-
ronnements collaboratifs, en particulier dans les collaborations importantes ou distribuées,
mais peut également être utilisé par des individus dans le cadre d’un régime de gestion du
temps ou de productivité personnelle [URL6]. MantisBT englobe souvent l’allocation des
ressources, la comptabilisation du temps, la gestion des priorités et le flux de travail de
supervision, en plus c’est un outil centralisé pour traiter principalement la procédure de
support et d’assistance. C’est un logiciel, éventuellement, qui gère et tient à jour des listes
des problèmes.

Figure 2.1 – Mantis Interface

La figure 3.1 présente une capture d’écran de l’application Mantis, c’est un tableau
de bord qui englobe toutes les activités d’un utilisateur donnée y compris tous les tickets
qui sont attribués pour ce dernier, les tickets qui sont déjà résolus, les tickets qui sont
récemment modifiés, les tickets qui sont surveillés par ce utilisateur ainsi que la chronologie
de toutes les activités sur cette plate-forme.
2.3. Étude de l’existant 11

Fonctionnement de Mantis Bug Tracker

Afin de de mieux appréhender le fonctionnement de Mantis et le déroulement de scé-
nario de suivi de bug. Nous allons illustrer le fonctionnement à travers un simple scénario,
afin de détailler les principales étapes du suivi d’un bug :

— le client de l’application rencontre un bug ;

— il le reporte dans Mantis Bug Tracker ;
— le développeur consulte Mantis Bug Tracker pour assurer le suivi de la version de
l’application qu’il a livré à son client ;
— il assigne alors les bugs signalés aux membres de son équipe de debugging ;
— le bug est alors traité par la personne en charge, avec la possibilité de dialoguer avec
le client sur le bug en question ;
— une fois le bug fixé, il publie les modifications sur l’application et il marque alors le
bug comme résolu en spécifiant la version de l’application ou le bug est corrigé.

C’est ensuite le client qui clôture le suivi de bug à partir du moment où il constate que
le bug n’est plus présent dans la version de l’application en production.

Zendesk Help-Disk
Zendesk est un excellent logiciel de suivi des problèmes utilisé par de nombreuses
équipes. Lorsque le service support avec Zengesk est utilisé, il est possible de créer des
incidents à partir de n’importe quel ticket en un seul clic. Les problèmes contiendront tous
les détails du ticket et un lien vers le reporteur sera intégré lors de la création du ticket. Il
dispose notamment d’un outil de génération des rapports qui permet de suivre les demandes
de support client, d’identifier les tendances et d’aider à tirer des enseignements significatifs
des données. Ceci va améliorer les fonctionnalités en libre-service, donner aux utilisateurs
une réponse plus rapide et libère les agents pour des problèmes plus complexes.
Zendesk dispose également de fonctionnalités améliorées qui peuvent être utilisées pour
améliorer l’expérience des clients et des spécialistes du support client. Les chatbots de
réponse peuvent fournir des réponses automatisées basées sur des requêtes courantes, des
messages ciblés et basés sur le comportement peuvent être envoyés aux clients en fonction
de déclencheurs lors de leur utilisation, et des tâches rudimentaires répétitives peuvent être
automatisées pour libérer la charge de travail. Pour les opérateurs du service d’assistance,
Zendesk fournit un espace de travail unifié sous la forme d’un tableau de bord permet un
routage basé sur les compétences afin que les tâches soient envoyées à la personne qui peut
le mieux répondre ou répondre à la demande, et prend en charge les règles métiers afin
que les déclencheurs automatisés puissent canaliser les tickets spécifiquement dans le flux
de travail souhaité.[URL7]
2.3. Étude de l’existant 12

Tableau comparatif

Fonctionnalité Mantis Zendesk

Support Multi-
Non Oui
canal
Centre d’appel Non Oui
Chat en ligne Non oui
Intercom, Asana, Salesforce
Google Drive, Slack, HubS-
Intégration et 200+ autres apps et ser-
pot, Jira
vices
Automatisation des ré-
Automatisez les réponses de
Automatisation ponses aux demandes
chat avec Answer Bot.
courantes
Professionnel : 89 Dollar
Plans tarifaires gratuit /agent/mois, Entreprise :
149 Dollar /agent/mois .

Table 2.1 – Tableau comparatif .

[URL8]

A travers la Table 3.1, nous avons fait un processus de comparaison basé sur différentes
critères afin de savoir les fonctionnalités offertes par chacun de ces deux logiciels. Nous
pouvons donc conclure que ces deux logiciels sont performant non seulement en termes
de suivi des bugs mais également en termes de support. Cependant, ces deux solutions ne
sont pas adéquates pour les fonctionnalités assez particulières que nous voulons ajouter,
comme la gestion et le traitement des licences des quelques produits. En outre, pour traiter
des bugs complexes rencontrés sur des logiciels de PM, nous avons besoin de suivre des
processus particuliers qui vont être détailler notamment dans le chapitre suivant. Bien
étendu, MantisBT et Zendesk sont des solutions standards dans le marché qui ne peuvent
pas être utilisées dans un contexte particulier et pour servir un client donné qui exige des
fonctionnalités spécifiques. Aussi, avoir un bon help-desk coûte cher pour l’entreprise donc
avoir son propre logiciel du support sera une bonne idée sur le long terme. Sans oublier que
PrimaSup peut être utilisé par d’autres entreprises dans le même domaine. Ce qui semble
être une nouvelle opportunité financière pour PrimaFrance. C’est un projet susceptible
d’être économiquement très rentables dans les années à venir.

2.3.2 Étude des produits internes

PrimaFrance dispose de ses propres systèmes de support client. Les consultants utilisent,
afin de maintenir le support chez les clients, principalement trois outils qui sont dédiées
pour répondre aux sollicitations de support. Ces trois outils logiciels sont respectivement,
2.3. Étude de l’existant 13

le support Oracle qui est un support pour l’application Primavera, le support Hexagon qui
est le support pour l’application Ecosys, le support Bentley pour l’application Synchro 4D.

Support Oracle Primavera

Primavera est une application développée par oracle, c’est un logiciel de gestion de
projets d’entreprise. Il comprend la gestion de projets, la planification, l’analyse des risques,
la gestion des opportunités, la gestion des ressources, la collaboration et les capacités de
contrôle, et s’intègre à d’autres logiciels d’entreprise tels qu’Oracle et les systèmes ERP de
SAP[URL9]. Ainsi, les clients doivent être formées pour utiliser le logiciel et durant toutes
les phases des projets ils doivent être accompagné par des consultants fonctionnelles et
techniques. Cependant, les clients passent par le support oracle pour avoir un support et
afin que les consultants puissent intervenir chez eux.

Figure 2.2 – Support Oracle Interface

[URL10]

La figure 3.2 présente une capture d’écran du système de support d’Oracle pour l’appli-
cation Primavera P6. Elle illustre un portail qui contient toutes les demandes de support,
elles sont divisées en trois types différentes des tickets de support les demandes non tech-
niques, les demandes techniques et les brouillons.

Support Hexagon Ecosys

La plateforme Ecosys, qui est également un logiciel de Management fournissant la

solution ultime pour des niveaux élevés de prévisibilité de projet, dispose notamment de
son système d’assistance qui est le support Hexagon. C’est un logiciel (une application
web) qui traite des tickets d’incidents déclarés sur l’application Ecosys et qui permet de
les résoudre en passant par des consultants qui vont essayer de trouver des solutions aux
2.3. Étude de l’existant 14

problèmes déclarés. PrimaFrance utilise support Hexagon pour maintenir l’assistance de

ses clients sur l’application Ecosys.

Figure 2.3 – Support Hexagon ecosys

[URL11]

La figure 3.3 illustre le système d’assistance pour Ecosys, elle présente une interface
où les demandes d’un utilisateur donnée sont listés avec tous les détails de tickets ouverts
récemment sur cette plate-forme.

Support Bentley
Le logiciel SYNCHRO 4D est dédié pour la planification de la construction et la gestion
de projet, il est introduit par la société Bentley en 2007. Synchro offre la planification 4D en
améliorant la sécurité, la fiabilité, la prévisibilité et la qualité des projets de construction
complexes[URL12]. Cela permet évidement d’économiser en évitant les retouches et en
identifiant les problèmes d’ordonnancement à l’avance. Pour cette application PrimaFrance
utilise le support Bentley, afin d’accompagner les clients sur cette application.

2.3.3 Les limites des systèmes existantes et la solution proposée

Nous avons étudié dans les paragraphes précédentes deux systèmes présentes sur le mar-
ché et il y’en a encore plein mais ils restent toujours des systèmes standardisés. Nous avons
montré également les lacunes de ces systèmes et pourquoi nous ne pouvons pas l’utiliser
dans notre cas. Par la même occasion, nous avons énuméré les solutions internes comme le
support Oracle, le support Hexagon et le support Bentley. Sachant que, nous devons avoir
notre propre système FAQ et Rex personnalisé pour les logiciels de PM, aussi nous voulons
centraliser tous ces systèmes de support dans un seul endroit. Les clients de PrimaFrance
ont des exigences strictes en termes de sécurité des données de leurs collaborateurs surtout
2.4. Conclusion 15

lorsqu’il s’agit des projets appartenant à des domaines sensibles comme le domaine nu-
cléaire, la défense ou bien l’aéronautique. Par conséquent, la sécurité des données comme
les emails et coordonnées des clients deviendra une exigence strictement nécessaire. Pour
cela, elles doivent être traitées avec une forte confidentialité. A titre d’exemple, il n’est pas
possible d’héberger leurs données dans des entreprises en dehors de l’union européenne.
Toutefois, les systèmes existants abordés ne dispose pas d’un système de Reporting qui
permettra de générer une base des connaissances personnalisée pour les clients de Prima-
France. Seulement, nous cherchons un logiciel de support technique qui dispose d’un outil
de génération de rapports permettant de suivre les demandes de support client, d’identi-
fier les tendances et de nous aider à tirer des enseignements significatifs des données. Il
s’agit d’un élément essentiel du processus, car il nous aidera à identifier les domaines à
développer dans notre base de connaissances afin d’améliorer notre support automatique.
Sans oublier que toute amélioration des fonctionnalités de support automatique donne à
nos utilisateurs une réponse plus rapide et libère les consultants pour les problèmes plus
complexes. Pour conclure, nous cherchons une solution permettant d’offrir la gestion des
priorités, la gestion du flux de travail de supervision et la mise en œuvre d’un traitement
centralisé tout en respectant les normes des sécurités exigées. Toutes ces fonctionnalités
vont rendre le processus de support intuitif et plus efficace.

2.4 Conclusion
Une étude théorique ainsi qu’une étude de l’existant ont été détaillées dans ce chapitre,
cette approche nous a permis de mieux comprendre les objectifs et les motivations de notre
travail. Cependant, dans le chapitre suivant, nous présentons le spécification et l’analyse
des besoins de notre projet.
Chapitre 3

Analyse et spécification des besoins

3.1 Introduction
Tous le long de ce troisième chapitre nous allons détailler la spécification des besoins
des différents utilisateurs du système. Commençons par définir tous les acteurs ainsi que
les principaux intervenants dans ce projet qui sont amené à utiliser cette plate-forme de
support, ensuite nous intéressons à l’énumération des besoins fonctionnels et non fonction-
nels de chaque acteur et les différents scénarii offerts par ce système tous en basant sur des
diagrammes de modélisation UML.

3.2 Analyse des besoins Fonctionnels

Avant d’aborder les exigences et les besoins, nous allons entreprendre d’abord une iden-
tification des intervenants potentiels de notre système.

3.2.1 Identification des Acteurs

L’environnement de notre plate-forme contient essentiellement cinq acteurs. Le super-
admin, c’est un membre de l’équipe d’informatique il peut être le développeur ou bien
l’administrateur de système d’information au sein de PrimaFrance, il est responsable de la
configuration de l’application. L’administrateur entreprise, c’est un membre d’une entre-
prise, cette entreprise peut être PrimaFrance où n’importe quelle entreprise qui offre des
services d’assistances en générale, l’administrateur entreprise est donc un chef de projet
où un référant. L’utilisateur entreprise, c’est un consultant d’entreprise amené à réaliser le
support client. L’administrateur client, c’est un membre de l’entreprise cliente, c’est l’en-
treprise qui profite du support, il peut être de même un chef de projet ou un référent.
L’utilisateur client, c’est un membre de l’entreprise cliente, c’est celui qui travaille sur des
projets et des produits logiciels inscrits dans le système d’assistance.

16
3.2. Analyse des besoins Fonctionnels 17

3.2.2 Spécification des besoins fonctionnels

Tous les utilisateurs de l’application doivent s’authentifier obligatoirement pour y ac-
céder aux différentes fonctionnalités du système.

Spécification des besoins fonctionnels du SuperAdmin

L’administrateur de cette plateforme est responsable principalement de la configuration

de l’application :

• ajouter, mettre à jour et supprimer les clients ;

• ajouter, mettre à jour et supprimer les utilisateurs entreprise ;
• attribuer les rôles et les métiers selon les profils ;
• attribuer, selon la zone géographique, un consultant à un client.

Spécification des besoins fonctionnels de l’Utilisateur Entreprise

L’administrateur entreprise exige de la part de l’application les fonctionnalités sui-

vantes :
• répondre aux demandes des utilisateurs clients ;
• résoudre les problèmes déclarés sur l’application ;
• en cas de problème technique nécessitant un patch ou une intervention spéciale,
proposer une solution de contournement.

Spécification des besoins fonctionnels de l’Administrateur Entreprise

L’administrateur entreprise peut avoir toutes les fonctionnalités offertes aux utilisateurs
clients et en plus de ça il est capable de :

• comprendre, catégoriser et orienter le problème vers l’agent qui est concerné ;

• gérer les contrats, ces sont principalement des contract de support sur la plate-forme,
avec les clients ;
• gérer les licences des produits du project management (Synchro 4D, Ecosys . . . ). ;
• créer des nouveaux projets et produits ;
• créer, consulter et envoyer un rapport aux clients ;
• geler les fonctionnalités du système pour un client donné, une fois leur contrat n’est
plus valable.
3.2. Analyse des besoins Fonctionnels 18

Spécification des besoins fonctionnels de l’Utilisateur Client

L’application développée offre à l’utilisateur Client les fonctionnalités suivantes :
• déclarer un bug et ouvrir des tickets du support là-dessus ;
• avoir des supports sur plusieurs outils le concernent de PrimaFrance et également de
management en générale ;
• consulter à la demande ou lors de l’ouverture d’un ticket le FAQ ;
• définir le projet, l’outil et le produit de sa demande ;
• définir la catégorie de sa demande. ;
• afficher l’état de sa demande (ouverte, en attente ou bien fermé).

Spécification des besoins fonctionnels de l’Administrateur Client

L’administrateur client peut avoir toutes les fonctionnalités offertes aux utilisateurs
clients et en plus de ça il est capable de :
• créer des nouveaux projets et produits ;
• créer, consulter et sortir un rapport de ses demandes et les demandes de ses utilisa-
teurs.

3.2.3 Spécification des besoins non fonctionnels

Les besoins non fonctionnels représentent les contraintes auxquelles le système doit
répondre afin de garantir son bon fonctionnement et éventuellement sa validation auprès
de client. Parmi ces besoins nous pouvons énumérer :
— disponibilité : la plate-forme réalisées doit être disponible et fonctionne correctement
lors de la demande de l’utilisateur à tout moment ;
— confidentialité : la plate-forme doit être sécurisé par système d’authentification, ga-
rantir les bonnes autorisations pour accès aux données et respecter les normes de
sécurité de PrimaFrance décrite dans le Plan d’assurance de Qualité et de Sécurité
de Système d’Information de PrimaFrance PAQSSI ;
— intégrité : la plate-forme doit garantir l’intégrité des données ;
— traçabilité : la plateforme doit rendre les actions tracées en vue de produire des
preuves à la demande.
La classe de conséquence de la plateforme PrimaSup 360 est considéré au niveau
très important dans la matrice de risque défini par le PAQSSI avec un niveau de
vraisemblance estimé à plausible. Elle doit donc bien s’inscrire dans les exigences de
qualité et de sécurité de PAQSSI de PrimaFrance. La matrice de risque PAQSSI sera
présentée dans l’annexe.
3.3. Diagrammes de cas d’utilisation 19

3.3 Diagrammes de cas d’utilisation

La figure 3.1 illustre le diagramme de cas d’utilisation pour le super Administrateur de
l’application.

Figure 3.1 – Diagramme de cas d’utilisation pour le superAdmin

La figure 3.1 montre que le Superadmin de l’application est capable de gérer les parti-
cipants et attribuer les rôles et les métiers.
3.3. Diagrammes de cas d’utilisation 20

Figure 3.2 – Diagramme de cas d’utilisation partie cliente

Le figure 3.2 illustre le diagramme de cas d’utilisation pour la partie cliente. Ce dia-
gramme montre que les acteurs côté client sont capable de déclarer un bug et ouvrir des
tickets là-dessus, Consulter à tout moment l’avancement sur ces tickets et Consulter les
documents présentés sur la plate-forme. L’administrateur client est capable aussi de définir
les projets et les produits et de consulter et sortir des rapports.
3.3. Diagrammes de cas d’utilisation 21

Figure 3.3 – Diagramme de cas d’utilisation partie entreprise

La figure 3.3 illustre le diagramme de cas d’utilisation pour la partie entreprise, cela
veut dire tous les acteurs liés à l’entreprise. En outre, la figure 3.3 montre que les acteurs
coté entreprise sont capable de créer des nouveaux projets et produits, gérer les licences
des produits, créer des documents et attribuer des accès, comprendre, catégoriser, orienter
le problème vers l’agent qui est concerné et proposer des solutions de contournement.

Description textuelle de cas d’utilisation « créer des documents et attribuer

des accès pour les clients »
Tout d’abord, le client doit être inscrit sur l’application PrimaSup. Il a besoin de parta-
ger avec ses utilisateurs des documents ainsi que d’autres ressources d’une manière générale.
Donc, il doit contacter l’administrateur entreprise pour ajouter ces ressources. Une fois ça
ce fait, la ressource devient accessible sur la plate-forme, tous en définissant les droits d’ac-
cès sur cette ressource (qui pourra modifier et qui pourra juste consulter sans modifier),
pour tous les utilisateurs du client.
3.4. Diagrammes de séquences 22

3.4 Diagrammes de séquences

Dans cette section, nous allons présenter deux diagrammes de séquences pour les deux
scénarios suivants : demander un support et gérer les licences Synchro.

Figure 3.4 – Diagramme de séquence : demander un support

La figure 3.4 présente un diagramme de séquence pour le cas d’utilisation : demander

un support. En effet, l’utilisateur client s’authentifie sur l’application, il consulte le FAQ.
S’il ne trouve pas des solution, il va déclarer un bug ensuite selon la complexité de ce bug,
il va ouvrir un ou plusieurs tickets. Cependant, l’utilisateur client est capable de visualiser
à tout moment l’avancement du travail sur son ticket. L’administrateur d’entreprise va
clôturer les tickets une fois le bug est résolu.
3.4. Diagrammes de séquences 23

Figure 3.5 – Diagramme de séquence : gestion des licences

La figure 3.5 illustre le diagramme de séquence pour le cas d’utilisation : gestion des
licences. Ce diagramme montre les messages envoyés lors de la demande d’une nouvelle
licence Synchro entre l’utilisateur Synchro qui présente l’utilisateur client dans notre cas
et l’admin synchro, c’est l’administrateur entreprise, d’une part et entre la plate-forme de
support et la plate-forme de Licensing (Bentley.com) d’autre part. Une description avec
plus de détails sera présentée dans la section 3.5.
3.5. Diagrammes d’activité 24

3.5 Diagrammes d’activité

Afin de détailler les sénarii de fonctionnement possible de PrimaSup, nous allons en-
treprendre dans cette section les diagrammes d’activité de notre système. Cela permet
de décrire le déclenchement d’événements dans notre application y compris les états du
système.
.

Figure 3.6 – Diagramme d’activité : demander un support

La Figure 3.6 illustre le diagramme d’activité du système d’assistance. Dans cette figure,
PMF support fait référence à PrimaFrance support. Pour demander un support, il est
nécessaire tout d’abord de vérifier si le client concerné possède un contrat de support chez
3.5. Diagrammes d’activité 25

PMF, s’il y avait un contrat et s’il est encore valable, l’utilisateur client est invité dans
ce cas à détailler son problème sur PrimaSup, plate-forme PMF support, et d’échanger
avec l’équipe de support afin de résoudre le problème. Une fois le problème est résolu,
l’administrateur PMF entreprise met à jour la liste des problèmes sur PrimaSup et clôture
les tickets et les bugs.

Figure 3.7 – Diagramme d’activité : développement

La figure 3.7 illustre le diagramme d’activité pour la phase développement. Dans cer-
tains cas, en traitant des bugs complexe, la résolution du problème nécessite une étape
de développement où nous devons contacter les développeurs du logiciel si ce n’est pas un
logiciel interne.
3.5. Diagrammes d’activité 26

Figure 3.8 – Diagramme d’activité : gestion des licences

La figure 3.8 illustre le diagramme d’activité pour la gestion des licences.

Le process de Licensing s’effectue en 4 niveaux :
• niveau Entreprise Cliente ( ici c’est EDF = Electricité De France) ;
• niveau Primasup360 coté Client ;
• niveau Primasup360 coté Primafrance ;
• niveau Plateforme de Licensing ( connect.Bentley.com).
Le process Commence au niveau de l’entreprise cliente. Pour demander une licence Synchro
4D , les utilisateurs doivent passer par un administrateur entreprise ayant le droit de créer
un ticket Admin. Ce dernier crée un ticket au niveau de l’interface Client de Primasup360,
en joignant une liste des nouveaux utilisateurs, changements de postes . . . . Un Adminis-
trateur de Chez Primafrance reçoit le ticket sur Primasup360 et demande au configurateur
de créer les utilisateurs s’ils n’existent pas et de faire la mise à jour du tableau utilisateurs
au niveau de Primasup360.
L’Administrateur Licences ( Admin Plateforme Bentley) retourne les anciennes Licences
en cas de modifications de poste ou d’utilisateur, créer les utilisateurs s’ils n’existent pas
en utilisant le NNI ( Aucune information sur les salariés d’EDF ne sera saisit sur la plate-
forme de Bentley à part le nom de pc. Pour cela nous génerons un code NNI, ce code
correspond à un utilisateur client. Il sera envoyer au plateforme de Licensing Bentley ).
3.6. Conclusion 27

L’appropriation de licences en masse important un fichier csv contient le NNI et le nom

du pc. Un fichier .belic sera généré et envoyé à un Administrateur SCCM chez EDF ( c’est
celui censé realiser l’instlation logiciels dans les machines clientes) pour être déployé sur
les postes clients concernés.

3.6 Conclusion
A partir de ce chapitre, nous avons mis le point sur la spécification des besoins des
acteurs présent dans ce système y compris les différentes fonctionnalités de l’application
tout en appuyant sur des diagrammes de modélisation. Cette partie concrétise les modules
à implémenter, ces derniers vont être étudier en plus de détails dans le prochain chapitre.
Chapitre 4

Conception

4.1 Introduction
Dans ce chapitre, nous allons décortiquer la phase de conception. C’est une étape impor-
tante pour enchainer ensuite efficacement sur la phase de développement et pour satisfaire
notamment les besoins dégagés dans le chapitre précèdent. Durant ce chapitre, nous ex-
poserons la conception générale et également les composants du système conformément à
la modélisation UML, tout en présentant leurs diagrammes de classes et voire même leurs
scénarii de fonctionnement possible.

4.2 Conception globale

L’architecture globale du système présente trois aspects : une architecture physique
qui détaille le déploiement de l’application sur un environnement informatique physique,
une architecture fonctionnelle et une architecture logique qui décrit les relations existantes
entre les composants logiciels de la solution. Enfin, pour clarifier l’architecture globale
du système nous allons présenter un diagramme de paquetages ainsi qu’un diagramme de
déploiements.

4.2.1 Architecture physique

L’architecture physique présente globalement l’infrastructure logicielle et matérielle qui
héberge l’implémentation des composants. Pour le projet PrimaSup360, l’architecture phy-
sique la plus adéquate est l’architecture 4-tiers. Elle permet un découpage des aspects
métiers et techniques et des services entre eux pour rassurer une meilleure modularité, ce
type de conception permet également de faciliter l’évolution, le passage à l’échelle et la ges-
tion de la sécurité. Les composants matériels permettant de mettre en place l’architecture
4-tiers sont les suivants :

28
4.2. Conception globale 29

• un serveur de base de données ;

• un serveur d’application ;
• un serveur Frontal et les services de sécurité ;
• des machines pour les applications clientes.
D’où, chaque élément se charge de réaliser ses propres tâches afin d’optimiser et accélérer
le temps d’exécution. La figure 4.1 illustre l’architecture de déploiements utilisées pour la
mise en œuvre du projet et les différents liens entre des niveaux distincts.

Figure 4.1 – Diagramme de déploiements

L’interaction entre les différents compartiments est décrite comme suit : le client envoie
une requête au serveur applicatif, cette requête est passée par un serveur proxy ensuite par
un serveur de redirection Apache afin d’être récupérée finalement par le serveur applicatif
qui va la traiter à l’aide des services métiers du projet. Par la suite, il envoie cette requête
au serveur de base des données, ce serveur PrimaData traite le résultat et l’envoie vers le
serveur applicatif, qui va finalement l’envoyé vers le client.

4.2.2 Architecture fonctionnelle

Elle s’agit essentiellement de l’organisation hiérarchique des caractéristiques et du com-
portement du système tels que perçus par les utilisateurs ou par tout système externe à
ce système d’information. La couche fonctionnelle est une interface entre l’applicatif et le
métier qui a pour objectif d’optimiser les flux d’information en s’assurant que les logiciels
utilisés respectent les besoins exprimés, et plus largement les objectifs de l’organisation.
Les niveaux de cette hiérarchie sont classiquement : Zone, Quartier, Îlot, Bloc.
4.2. Conception globale 30

Figure 4.2 – Architecture fonctionnelle du système

La figure 4.2 illustre l’architecture fonctionnelle du système. En effet, nous avons princi-
palement 4 zones qui sont comme suit : zone Data ou se présente tous ce qui est interaction
avec la base des données, zone services, zone application et finalement une Front zone où
nous trouvons les utilisateurs finaux.

4.2.3 Architecture logique

Dans cette section, nous allons détailler l’architecture logique de notre application.
Cette architecture indique la répartition des composants logiques sur les niveaux appropriés
de l’architecture et les relations entre ces composants.
4.2. Conception globale 31

Architecture logique de la partie Backend

Pour la partie Backend de notre application nous avons choisi comme architecture
logique l’architecture MVC (Modèle-Vue-Contrôleur).

Figure 4.3 – Architecture logique partie Backend

[URL13]

La figure 4.3 illustre l’architecture logique de la partie Backend de notre application.

L’architecture MVC présente trois couches. La couche modèle contient les données mani-
pulées par le système et offre des méthodes pour l’interaction avec la base des données.
La couche vue, elle fait l’interface avec la partie Frontend. La couche contrôler reçoit tous
les événements de l’utilisateur et enclenche les actions à effectuer, elle est responsable à la
synchronisation entre le modèle et la vue.

Architecture logique de la partie Frontend

Pour la partie Frontend de notre application nous avons choisi comme architecture
logique l’architecture MVVM (Modèle-vue-vue Modèle). MVVM est une dérivation de
modèle MVC.
4.3. Diagramme de paquetages 32

Figure 4.4 – Architecture logique partie Frontend

[URL14]

La figure 4.4 illustre l’architecture logique de la partie Frontend de notre application.

L’architecture MVVM présente trois couches. La couche modèle c’est la couche responsable
à l’interaction avec la partie Backend, la couche vue c’est la partie présentation et la couche
vue modèle c’est l’équivalent de contrôleur, c’est la partie responsable au déclenchement
des évènements sur les interfaces utilisateur.
Nous avons choisi cette approche pour des nombreux raisons. Dans un premier temps,
MVVM sépare clairement l’interface utilisateur de la logique d’application, donc elle permet
une adaptation au changement, à l’amélioration et à la maintenance. Ensuite, avec cette
architecture, seulement les données requises sont échangées avec les serveurs pour permettre
un chargement plus rapide des interfaces. Pour cela, nous avons décidé de s’appuyer sur
cette architecture pour la partie frontend.

4.3 Diagramme de paquetages

Après avoir spécifie l’architecture globale de notre projet, la prochaine étape est de
présenter le diagramme de paquetage. En gros, un diagramme de paquetage permet de
clarifier visuellement la structure hiérarchique des différents éléments au sein d’un système
donné.
4.3. Diagramme de paquetages 33

Figure 4.5 – Diagramme de paquetage

La figure 4.3 illustre les principaux paquetages du projet, il est composé par : com.primasup.entity
c’est le paquetage censé à définir les classes entités du système c’est-à-dire créer la table
de base des données, com.primasup.enum c’est paquetage qui contient les classes des types
énumérés définis dans le projet, com.primasup.dao c’est le paquetage qui contient toutes
les classes qui sont responsable au traitement et l’interaction avec la base des données, ils
importent les paquetage suivants : com.primasup.dao.ex c’est le paquetage responsable à la
gestion d’exception pour la partie DAO, com.primasup.dao.util c’est paquetage qui englobe
toutes les fonctionnalité utile pour le développement de la couche DAO, com.primasup.web
c’est un paquetage qui, com.primasup.web.bean, com.primasup.web.controller c’est le pa-
quetage responsable à la reception et l’envoi des données et com.primasup.web.validator
c’est le paquetage qui englobe toutes les classes responsable à la validation des données,
com.primasup.service c’est le paquetage qui contient les classes qui représentent le service
métier de l’application, com.primasup.service.rest c’est le paquetage qui englobe toutes les
classes permettant de générer et développer les web services rest, com.primasup.service.ex
c’est le paquetage responsable à la gestion des exceptions pour la couche métier et
com.primasup.service.util c’est le paquetage qui englobe toutes les fonctionnalités utiles
pour le développement de la couche logique métier.
4.4. Conception détaillée 34

4.4 Conception détaillée

Une étape impérieuse pour le développement de toute application est d’accomplir la
conception détaillée. Pour cela, cette section est consacrée à définir la manière de procéder
afin de concevoir la bonne solution pour notre projet.

4.4.1 Diagramme de classe

Les figures 4.6 et 4.7 illustrent le diagramme de classe de Primasup.
A partir des figures 4.6 et 4.7 nous allons instaurer le diagramme de classe de notre
système PrimaSup 360. Cela nous permet donc d’avoir une représentation interne et ex-
haustive de la solution.

Première partie de diagramme de classe

Figure 4.6 – Première partie du diagramme de classe

4.4. Conception détaillée 35

Description
Pour bien comprendre le diagramme de classe présent dans la figure 4.4, il faut dé-
tailler les différentes classes. La classe « User » : cette classe présente essentiellement les
informations nécessaires pour un utilisateur tels son nom, son adresse mail, son numéro
de téléphone etc. . . elle est en association avec les classes suivantes : La classe « UserRole
» : cette association est de type OneToOne, elle représente les rôles des utilisateurs, elle
contient principalement le champ suivant : roleFlag qui peut prendre les valeurs suivantes
RoleSysAdmin, RoleAdmin, RoleUser et RoleNotAssigned. Ensuite, il y a la classe « User-
Profile » qui présente aussi une association de type OneToOne et elle permet de spécifier
principalement les différents profils des utilisateurs. Puis, nous avons la classe « client »,
chaque utilisateur appartient à un client donné qui est inscrit sur la plateforme, un client
peut évidement avoir plusieurs utilisateurs d’où l’association OneToMany entre la classe
« client » et la classe « utilisateur ». De plus, un client peut être dans une seule ou plu-
sieurs zones ainsi qu’un utilisateur doit être présent dans une zone. La classe « Business »
cette classe modélise le métier de l’utilisateur. Bien entendu, chaque utilisateur possède un
métier donné. Un client est attaché à un ou plusieurs projets et ensuite à un ou plusieurs
produits d’où la relation OneToMany entre la classe « client » et la classe « projet » d’une
part et la relation OneToMany entre la classe « projet » et la classe « produit » d’autre
part. De même, pour un produit, il est trivial de définir sa version, la plateforme ou il est
installé tandis que des informations générales sur ce produit. Pour cela, nous disposons de
associations entre la classe « produit » et les classes suivantes : « version », « plateforme
» et « Product Info ». Ensuite, pour un produit donné nous pouvons déclarer un bug et
à partir de ce dernier nous pouvons ouvrir un ou plusieurs tickets chaque bug ou bien un
ticket possède un statut qui peut avoir les valeurs suivantes : ouvert, en cours ou bien
terminé.
4.4. Conception détaillée 36

Deuxième partie de diagramme de classe

Figure 4.7 – Deuxième partie du diagramme de classe

Description

Cette deuxième partie de diagramme de classe manipule les classes suivantes : La classe
« Document » elle présente les documents partagés entre le client et ses utilisateurs, cette
relation est modélisée avec une association OneToMany. Ensuite, nous trouvons la classe
Access qui présente l’accès à un document ainsi que les ressources fournies par le client à
ces utilisateurs. Afin de spécifier quel ressource ou document procède tels accès, nous avons
défini la classe « AccessShare ». Finalement, la classe « Access rules » qui va définie les
accès selon les profils des utilisateurs.

4.4.2 Schéma relationnel de la base de données

Dans cette section, nous intéressons à définir le schéma relationnel de la base de données.
— userEntity (id, create-date, create-user, update-date, update-user authentifiacation-
mode, config-data, email-address, first-name, last-connection, last-name, office-phone,
psswd-last-update-date, user-flag, user-password, user-salt, user-type, user-name, business-
id, client-id, entreprise-id, parent-id, profile-id, role-id, zone-id) ;
— userRoleEntity (id, role-code, role-desc, role-disabled, role-flag, role-locked, role-name) ;
— userProfileEntity (id, profile-code, profile-desc, profile-disabled, profile-flag, profile-
locked, profile-name, superUserFlag) ;
— clientEntity (id, client-flag, client-code, client-name, client-desc, parent-id, zone-id) ;
4.5. Conclusion 37

— entrepriseEntity (id, entreprise-flag, entreprise-code, entreprise-name, entreprise-desc,

parent-id, zone-id) ;
— businessEntity (id, business-flag, business-code, business -name, business -desc, entreprise-
id, client-id) ;
— zoneEntity (zone-code,zone-name) ;
— projectEntity (id,project-flag, project-code, project-name, project-desc,client-id) ;
— productEntity (id, project-name, project-desc, plateforme-id, project-id, productinfo-
id) ;
— plateformeEntity (id, osName, osVersion) ;
— version (id, product-version, product-id) ;
— productInfoEntity () ;
— bugEntity (id, bug-name, bug-desc, attachmentFile, status-id, client-id, user-id) ;
— ticketEntity (id, ticket-title, ticket-desc, ticket-theme, ticket-type, attachement-file,
bug-id, status-id, user-id, severity-id) ;
— statusEntity (id, status-code, complete-pct, FK-id, FK-code) ;
— severityEntity (id,severity-code) ;
— disscussionEntity (id, message, send-date, user-id, ticket-id) ;
— accessEntity (id, create-flag, read-flag, update-flag, delete-flag, filter-flag, sync-flag,
export-flag, import-flag) ;
— accessShareEntity(id, fk-id, fk-code, access-id, userprofile-id) ;
— accessRuleEntity(id, module, rule, access-id, userprofile-id) ;
— documentEntity (id, document -flag, document -code, document -name, document
-desc, document-type, attachement-file,client-id) ;
— ressourceEntity (id, ressource-flag, ressource-code, ressource -name, ressource -desc,
ressource -type, attachement-file,client-id) ;
— licenceEntity (id, type-id, pseudo, user-id, client-id, project-id, product-id, licence,
statut).

4.5 Conclusion
A partir de ce chapitre nous avons réussi à concevoir la solution ainsi que l’architecture
de base du travail. Dans le prochain chapitre nous abordons la partie développement et
réalisation de la solution.
Chapitre 5

Realisation

5.1 Introduction
Ce dernier chapitre est consacré à la présentation de l’étape de développement de la
solution, y compris une démonstration du résultat prévu de l’implémentation, ainsi que
l’environnement de travail utilisée tous le long de la réalisation de ce projet. Sans oublier,
notamment, de détailler les techniques utilisé pour améliorer la performance et la sécurité
de la plate-forme. Dans ce chapitre, nous allons détailler d’avantage les démarches faites
pour la phase du test avant de passer finalement à la phase de la production.

5.2 Environnement de travail

5.2.1 Environnement matériel
Dans ce projet nous prévoyons réaliser notre plate-forme PrimaSup 360 en utilisant une
machine dont les caractéristiques matérielles sont les suivantes :
• modèle : ALIENWARE ;
• système d’exploitation : Windows 10 Professionnel ;
• processeur : Intel Core i7 ;
• RAM : 32.0 Go.

5.2.2 Environnement logiciel

Dans ce projet nous prévoyons utiliser l’environnement logiciel suivant :
Eclipse est un environnement logiciel fournissant des briques logicielles pour développer,
en s’appuyant principalement sur Java.
Apache Tomcat Server est le serveur d’applications Java. Il permet d’exécuter des ap-
plications Web développées avec les technologies Java.

38
5.3. Travail réalisé 39

PostgreSQL est un système de gestion de base de données relationnelle et objet (SGB-

DRO). Il est reconnu pour son comportement stable, robuste et fiable.
Postman est un logiciel utilisé pour tester les web services REST.
Frontal Apache est un serveur HTTP conçu pour prendre en charge la sécurité de notre
application.
SVN est un logiciel de subversion et de gestion de versions de codes.
Maven est un outil d’automatisation et de gestion de production des projets logiciels Java
EE et Java en général.

5.2.3 Frameworks et technologies

Pour développer Primasup, nous prévoyons utiliser les Frameworks et les langages de
programmation suivants :
Java JEE est la version entreprise de la plate-forme Java. c’est une norme qui va englo-
ber à la fois l’infrastructure de gestion des systèmes et les API des services utilisées pour
développer ces systèmes.
Spring est un framework pour construire l’infrastructure des applications Java. Il permet
de faciliter la phase du développement et les tests.
Hibernate est un framework permet de réaliser le Mapping objet et objet relationnelle.
En outre, c’est une implémentation de JPA qui garantit la persistance des données.
Webix est un framework JavaScript / HTML5 / CSS3 pour le développement d’applica-
tions Web complexes et dynamiques.
JQuery est une bibliothèque JavaScript utilisée pour faciliter le développement côté client
dans le code HTML des pages web.
Jenkins est un outil logiciel open source d’intégration continue développé en Java.

5.3 Travail réalisé

Dans cette section, nous allons présenter les interfaces graphique de notre système à
travers une série de captures.

5.3.1 Interface d’authentification

La figure 5.1 illustre l’interface d’authentification des utilisateurs de Primasup. Les
deux champs nom d’utilisateur et mot de passe sont demandés afin de se connecter à la
plate-forme.
5.3. Travail réalisé 40

Figure 5.1 – Interface d’authentification

5.3.2 Interfaces de configurateur

La figure 5.2 illustre l’interface qui permet d’ajouter des nouveaux utilisateurs sur
Primasup. Le super admin accède à ce portail pour ajouter les futurs utilisateurs.

Figure 5.2 – Interface d’ajout d’utilisateurs

La figure 5.3 illustre l’interface qui permet d’ajouter des nouveaux rôles. Le super admin
accède à ce portail pour ajouter les rôles.
5.3. Travail réalisé 41

Figure 5.3 – Interface d’ajout des rôles

De même le configurateur où le super admin est capable d’ajouter des nouvelles en-
treprise, des nouveaux clients, des nouveaux métiers, des nouvelles zones. Ces interfaces
seront présentées dans l’annexe.

5.3.3 Interface environnement

La figure 5.4 illustre l’interface environnement. A partir de cette interface, l’administra-
teur entreprise peut créer des nouveaux projets et produits. Par conséquent, l’utilisateur
client et l’administrateur client sont capable de sélectionner le produit lors de déclaration
d’un bug. Une étape indispensable afin de solliciter un support.

Figure 5.4 – Interface environnement

5.3. Travail réalisé 42

5.3.4 Interface incident

La figure 5.5 illustre l’interface incident. Ce portail englobe la gestion des bugs et des
tickets.

Figure 5.5 – Interface incident

Ajout d’un bug

La figure 5.5 illustre la déclaration d’un Bug. Il est indispensable d’ajouter un Bug
avant d’ouvrir un ticket. En effet, à partir d’un Bug nous pouvons ouvrir un ou plusieurs
tickets.

Figure 5.6 – Interface d’ajout d’un bug

5.3. Travail réalisé 43

Ajout d’un ticket

La figure 5.6 illustre l’étape d’ajout d’un ticket. L’utilisateur est amené à communiquer
les détails de sa demande tout en joignant des fichiers. A partir de cette interface l’admi-
nistrateur client est capable de créer un ticket admin pour demander où renouveler une
licence.

Figure 5.7 – Interface d’ajout d’un ticket

5.3.5 Interface de gestion d’accès de documents

La figure 5.7 illustre la gestion d’accès pour un document à créer.

Figure 5.8 – Interface accès document

5.4. sécurité applicative 44

5.4 sécurité applicative

La sécurité applicative est un processus utilisé pour effectuer des mesures et des contrôles
aux applications web dans le but de gérer le risque de leur utilisation. Ces mesures peuvent
être appliquées à l’application elle-même, à ses données, et à toutes les technologies, les
processus et acteurs impliqués dans le cycle de vie de l’application. Par conséquent, pour
réaliser le test de sécurité nécessaires et pour rassurer la sécurité de notre application
contre les attaques qui criblent la couche applicative et notamment les vulnérabilités qui
se retrouvent dans cette même couche nous avons basé sur OWASP, c’est projet a comme
but de présenter une liste des dix failles de sécurité applicatifs Web les plus critiques. Ce
classement fait référence actuellement dans la sécurité d’applications.[URL15]
Cependant, pour ce faire nous avons utilisé OWASP Dependency Check c’est un ou-
til permettant d’analyser les applications et les librairies externes et de vérifier si elles
contiennent des vulnérabilités connues dans la base de données du NIST (National Insti-
tute of Standards and Technology)

Figure 5.9 – OWASP Dependency Check

La figure 5.9 présente une capture d’écran prise après le test de Primasup sur OWASP
Dependency Check. Ces résultats nous a permis d’améliorer la qualité de notre code afin
d’éviter les failles signalés ainsi que les vulnérabilités présentées.

5.5 Conclusion
A partir de ce dernier chapitre nous avons présenté tous les résultats du travail réalisé
durant notre stage y compris notre environnements du développement.
Conclusion et perspectives

En s’attaquant à un problème fréquent, les services clients, nous avons propoé une
solution permettant le suivi des incendies à travers des tickets du support.
C’est dans ce contexte, la plate-forme PrimaSup360 s’inscrit, relevant le défi de dévelop-
per un système de e-ticketing et help-desk à disposition les fonctionnalités cité antérieure-
ment et en répondant éventuellement aux distinctes exigences de la sécurité. Pour entamer
ce projet du stage, nous avons définit avant tout le cadre, les objectifs et les motivations
de notre travail à savoir la réalisation du système de e-ticketing avec toutes les contraintes
posées par ce sujet. Puis, nous avons préciser quelle méthode de travail était la plus fruc-
tueuse pour notre cas, afin de savoir la manière de procéder tous le long de la réalisation de
ce travail. Cependant, le planning prévisionnel a été accéléré et la gestion des tâches à l’aide
du Visual Management a été un enrichissement important. Ensuite, une étude de solutions
existantes pour examiner quelques systèmes existants et savoir s’il été faisable d’en exploi-
ter un. Nous avons aboutit décidément à la nécessitée de développer notre propre modèle
pour des exigences que ce soit fonctionnelle où financière. Après, nous avons identifié les
intervenants majeurs, la spécification des besoins fonctionnels pour chaque intervenant, les
besoins non fonctionnels, et une corrélation entre les trois pour clarifier le travail que nous
aurons à accomplir. La conception nous a servi de préciser l’architecture fonctionnelle,
physique et logique du projet, de visionner les différents services métiers à implémenter
ainsi que leurs interactions de manière dynamique avec les diagrammes de séquences et
de manière immuable avec les diagrammes de classes. A cet effet, nous avons présentés la
phase de réalisation de PrimaSup à savoir l’achèvement pour tous nos efforts d’analyse, de
conception et de développement.
Ce stage restera une expérience professionnelle qui nous a énormément apportée, tant sur
le plan de la compréhension et de la vision de notre métier que sur celui de l’acquisi-
tion de connaissances en gestion de projet, Management, développement et en relations
partenariales.
Les travaux futurs qui pourront améliorer le fonctionnement de PrimaSup seront essen-
sialement l’integration des outils des collaborations, l’ajout d’un chatbot et l’amélioration
de la fonctionnalité de repoting. Ce qui semble être un bon début pour évoluer l’outil afin
de voir jusqu’au où peut-on arriver avec un tel système surtout que nous commencerons le
développement de la deuxième version prochainement.

45
Annexe

Figure 5.10 – Matrices des risques PAQSSI

46
Annexe 47

Figure 5.11 – Interface entreprise

Figure 5.12 – Interface client

Netographie

[URL1] https://fr.wikipedia.org/wiki/M%C3%A9thode_agile, consulté le

20/03/2020.
[URL2] https://blog.engineering.publicissapient.fr/2008/01/10/
scrum-ou-xp-scrum-et-xp/#:~:text=La%20compl%C3%A9mentarit%C3%
A9%20de%20Scrum%20et,niveau%20des%20activit%C3%A9s%20de%20d%C3%
A9veloppement.&text=non%2C%20allez%2C%20c’est,s’articule%20avec%
20eXtreme%20Programming%E2%80%A6, consulté le 02/05/2020.
[URL3] https://www.planview.com/se/resources/guide/
agile-methodologies-a-beginners-guide/basics-benefits-agile-method/,
consulté le 20/03/2020.
[URL4] https://www.littlefish.co.uk/evolution-service-desk/, consulté le
02/05/2020.
[URL5] https://www.zendesk.fr/support/features/#features, consulté le
03/04/2020.
[URL6] https://www.logiciel-libre.org/s/mantisbt/, consulté le 28/03/2020.
[URL7] https://www.zendesk.fr/support/features/#features, consulté le
03/04/2020.
[URL8] https://techboomers.com/best-helpdesk-ticketing-system, consulté le
03/04/2020.
[URL9] https://fr.wikipedia.org/wiki/Primavera_(logiciel), consulté le
01/04/2020.
[URL10] https://login.oracle.com/mysso/signon.jsp, consulté le 06/04/2020.
[URL11] http://support.ecosys.net/login.asp?stay=1&goUrl=/Default.asp,
consulté le 07/04/2020.
[URL12] https://www.businesswire.com/news/home/20180620005867/en/
Bentley-Systems-Acquires-Synchro-Software-Extend-Digital, consulté
le 10/04/2020.
[URL13] https://tahe.developpez.com/web/php/mvc/?page=page_1, consulté le
08/05/2020.

48
Netographie 49

[URL14] https://naveenpete.wordpress.com/2016/09/07/mvc-mvvm-and-angular/,
consulté le 10/05/2020.
[URL15] https://owasp.org/www-project-web-security-testing-guide//, consulté
le 04/08/2020.
 ‘J
jÊ K

éJ
J£ñË@
 Ï @ áÓ  JêË@
ék  PX úΫ Èñ’mÌ '@ Ég @ áÓ 
éƒPYÖ éƒY . . h. Qm' ¨ðQå„Ò» ÉÒªË@ @ Yë 
ƒ AK Õç'
 g éJ ÊÔ« ÉJîD„ áÓ
  ñë AJ«ðQå „Ó áÓ . éJ ÓC«B @ ÐñʪË
¬YêË@
éÓY

áºÖ ß
ú
æ…Aƒ @ ÐA ¢  YJ
®J Kð Õæ

Ғ

.©K
PA‚ÖÏ @ èP@X@ ÈAm.× ú
¯ ZCÒªË@
 
,H @ñË@ HA
... A¯Ag  ®J
J.¢ ,ZCÒªË@ éÓY g : IjJ  . Ë@ HAÒÊ¿

. .

Résumé
Ce travail a été établi comme un projet de fin d’études dans le but d’obtenir le diplôme
d’ingénieur de l’École nationale des sciences de l’informatique . L’objectif de notre projet
consiste en la conception et la mise en œuvre d’une plate-forme de gestion des tickets de
support. Elle permet de faciliter la procédure du support client dans le domaine de la ges-
tion de projet.
Mots clés : Support client, dévelopement web, Java ...

Abstract

This work was established as a graduation project in order to obtain the engineering de-
gree from the National School of Computer Science. The goal of our project is to design
and implement a help-desk and a e-ticketing system. It’s a platform that facilitates the
customer support process for project management field.
Keywords : Customer support, web development, Java ...