REPUBLIQUE TUNISIENNE

Ministère de l’Enseignement Supérieur et

de la Recherche Scientifique
Université de Gabès

Ecole Nationale d’Ingénieurs de Gabès ‫المدرسة الوطنية للمهندسين بقابس‬

Département de Génie des ‫قسم هندسة اإلتصاالت والشبكات‬
Communications & des Réseaux

MEMOIRE DE PROJET DE FIN D’ETUDES

Présenté en vue de l’obtention du

Diplôme National d’Ingénieur en

Génie des Communications & des Réseaux

Réalisé par :
Bekri Malek

Sujet :

Refonte du module administrateur de

l’application Contact Plus relation client

Soutenu le 11 /09 /2020 devant la commission de jury :

M.Ikbel Azaiez Président

M.Abdelhak Moussa Membre
M.Chaker Ben Mahmoud Encadrant

Année Universitaire : 2019/2020

 TABLE DES MATIÈRES

LISTE DES FIGURES viii

INTRODUCTION GÉNÉRALE x

1 Context générale de projet 2

1.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Context de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Domaines d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.3 Équipe contact plus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2.1 Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2.2 L’interface graphique . . . . . . . . . . . . . . . . . . . . . 7
1.4.3 Solution envisagée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Méthodologie de gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.1 Présentation de la méthode SCRUM . . . . . . . . . . . . . . . . . . . 9
1.5.2 Les rôles dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.3 Le sprint agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Analye et spécification des besoins 12

2.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Étude des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Besoin non fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . 14

ENIG Page iii

TABLE DES MATIÈRES

2.3 Planification de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1 Equipe de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Les sprints du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Release 1 17
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Sprint1 : Authentification et Gestion des clients . . . . . . . . . . . . . . . . . 18
3.3.1 Backlog sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . 19
3.3.2.2 Description textuelle . . . . . . . . . . . . . . . . . . . . . 20
3.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.3.1 Diagramme de séquence . . . . . . . . . . . . . . . . . . . 21
3.3.3.2 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . 23
3.4 Sprint2 :Création d’un nouveau scénario . . . . . . . . . . . . . . . . . . . . 24
3.4.1 Backlog sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.2.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . 24
3.4.2.2 Description textuelle . . . . . . . . . . . . . . . . . . . . . . 24
3.4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.3.1 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . 25
3.4.3.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . 25
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Release 2 27
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Gestion des téléphones des conseillers . . . . . . . . . . . . . . . . . . . . . . 28
4.3.1 Backlog sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.2.1 Diagramme des cas d’utilisation . . . . . . . . . . . . . . . 29
4.3.2.2 Description Textuelle . . . . . . . . . . . . . . . . . . . . . 30
4.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

ENIG Page iv
TABLE DES MATIÈRES

4.3.3.1 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . 30

4.3.3.2 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . 31
4.4 Sprint 2 : Gestion des calendriers+ Configuration d’un scénario . . . . . . . . . 31
4.4.1 Backlog sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.2.1 Diagramme des cas d’utilisation . . . . . . . . . . . . . . . 32
4.4.2.2 Description Textuelle du cas d’utilisation . . . . . . . . . . 33
4.4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.3.1 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . 34
4.4.3.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . 34
4.4.3.3 Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . 35
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5 Réalisation 36
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Architecture et environnement de travail . . . . . . . . . . . . . . . . . . . . . 37
5.2.1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.2 Environnement du travail . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . 38
5.2.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . 38
5.2.2.3 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . 39
5.3 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.2 Éléments d’un diagramme de déploiement . . . . . . . . . . . . . . . 40
5.3.3 Diagramme de déploiement système . . . . . . . . . . . . . . . . . . 41
5.4 Digramme de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4.2 Diagramme de composants du système . . . . . . . . . . . . . . . . . 41
5.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

CONCLUSION GÉNÉRALE 51

Authentification à base de JWT 53

A.1 Authentification à base de JWT . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.1.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.1.2 Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

ENIG Page v
TABLE DES MATIÈRES

BIBLIOGRAPHIE 54

ENIG Page vi
 LISTE DES FIGURES

1.1 Logo sofrecom [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Interface d’authentification de l’ancienne IHM de contact plus . . . . . . . . . 5
1.3 Interface d’accueil de l’ancienne IHM de contact plus . . . . . . . . . . . . . 6
1.4 Page de gestion de téléphone de l’ancienne IHM de contact plus . . . . . . . . 6
1.5 Page de paramétrage de scénario de l’ancienne IHM de contact plus . . . . . . 6
1.6 La méthodologie Scrum [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 Planification du release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Diagramme de cas d’utilisation de sprint Gestion des clients . . . . . . . . . . 19
3.3 Diagramme de séquence de cas d’utilisation "s’authentifier" . . . . . . . . . . 22
3.4 Diagramme de séquence de cas d’utilisation "gérer client" . . . . . . . . . . . 23
3.5 Diagramme de classe de sprint "authentification et Gestion des clients" . . . . 23
3.6 Diagramme de cas d’utilisation du sprint "Création d’un nouveau scénario" . . 24
3.7 Diagramme de séquence de cas d’utilisation : "créer un nouveau scénario" . . . 25
3.8 Diagramme de classe de sprint "Création d’un nouveau scénario" . . . . . . . 26

4.1 Planification du release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Diagramme de cas d’utilisation du sprint "Gestion des téléphones des conseillés"
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Digramme de séquence de cas d’utilisation "gérer téléphone des conseillers" . 31
4.4 Digramme classe du sprint "gestion des Téléphones des conseillé" . . . . . . . 31
4.5 Diagramme de cas d’utilisation :"gérer calendriers"+"Configuration d’un scénario
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.6 Diagramme de séquence de cas d’utilisation "gérer calendrier " . . . . . . . . 34
4.7 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.8 Diagramme d’activité de cas d’utilisation "Configurer un scénario" . . . . . . 35

5.1 Architecture globale de l’application . . . . . . . . . . . . . . . . . . . . . . . 38

5.2 Diagramme de déploiement de l’application . . . . . . . . . . . . . . . . . . . 41
5.3 Diagramme de composant du système . . . . . . . . . . . . . . . . . . . . . . 42

ENIG Page vii

LISTE DES FIGURES

5.4 Interface d’authentfcaton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.5 Interface de super-admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.6 Interface de gestion de téléphones . . . . . . . . . . . . . . . . . . . . . . . . 43
5.7 Pop-up d’ajout téléphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.8 Rechercher téléphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.9 Pop-up de suppression téléphone . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.10 Gestion calendrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.11 Affichage calendrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.12 Pop-up d’ajout d’un scénario récurrent ouvert . . . . . . . . . . . . . . . . . . 46
5.13 Affichage différents scénarios par semaine . . . . . . . . . . . . . . . . . . . . 46
5.14 Affichage différents scénarios par mois . . . . . . . . . . . . . . . . . . . . . . 47
5.15 Affichage différents scénarios par jour . . . . . . . . . . . . . . . . . . . . . . 47
5.16 Gestion des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.17 Configuration des caractéristiques d’un scénario . . . . . . . . . . . . . . . . . 48
5.18 Affectation un calendrier à un scénario . . . . . . . . . . . . . . . . . . . . . 48
5.19 Configuration de l’appel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.20 Configuration de la vignette . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.21 Fenêtre d’ouverture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

A.1 Principe du JWT [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

A.2 format du JWT [20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

ENIG Page viii

LISTE DES TABLEAUX

Liste des tableaux

2.1 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Backlog sprint "Gestion des clients" . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Description Textuelle :"s’authentifier " . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Description Textuelle :"gérer les clients " . . . . . . . . . . . . . . . . . . . . 21
3.4 Backlog sprint "Création d’un nouveau scénario" . . . . . . . . . . . . . . . . 24
3.5 Description textuelle du cas d’utilisation :"créer un nouveau scénario" . . . . . 25

4.1 Backlog sprint "Gestion des téléphones des conseillers" . . . . . . . . . . . . . 29

4.2 Description textuelle du cas d’utilisation "Gérer les téléphones des conseillers" 30
4.3 Backlog sprint :Gestion des calendriers+ Configuration d’un scénario . . . . . 32
4.4 Description textuelle de cas d’utilisation gérer calendrier . . . . . . . . . . . . 33

5.1 Caractéristiques du matériels utilisé . . . . . . . . . . . . . . . . . . . . . . . 38

ENIG Page ix
 INTRODUCTION GÉNÉRALE

Nous vivons aujourd’hui dans l’ère numérique où la relation client est d’une valeur exceptionnelle.
De ce fait, les grandes firmes, ayant conscience de l’importance de la fidélisation de la clientèle,
construisent des stratégies qu ont pour but de paramétrer des différents scénarios d’appel selon
la disponibilité du service pour faciliter la mise en contact entre le client et le conseiller.

D’autre part, l’évolution des outils et des moyens de développement des logiciels, appariée
du changement de technologie, ont poussé les sociétés de services à mettre à jour leurs systèmes
et ré-innover leurs approches pour tenir en face de la compétition. Dans ce contexte, le groupe
Orange a mis en place une application web qui permet aux entreprises de configurer leurs
propres scénarios d’appel téléphonique. Ce projet est sous la responsabilité de l’équipe « Contact
Plus » faisant partie de la filiale du groupe Orange SOFRECOM Tunisie, société d’accueil du
projet de fin d’études. Étant donné la taille importante du projet, il est décomposé en deux
modules. L’une des applications du projet est « Contact Plus » qui permet de gérer la disponibilité
des centres de contact dans un calendrier pour l’exploiter par la suite lors du paramétrage
d’un scénario d’appel téléphonique. Nous avons été amenés, durant ce stage de fin d’études,
à effectuer une refonte technologique de cette application, du fait qu’elle n’est plus maintenable
et qu’elle repose sur des vieilles technologies, ce qui rend son évolution complexe et coûteuse.
Pour illustrer la démarche de travail réalisé, nous allons présenter les diffèrent chapitres :

— Le premier chapitre comportera une présentation de l’organisme d’accueil, l’étude de

l’existant ainsi la solution envisagée et la méthodologie adaptée.

— Le deuxième chapitre est consacré à l’analyse des besoins de notre application ainsi
l’identification de nos acteurs et la planification de notre projet.

ENIG Page x
INTRODUCTION GÉNÉRALE

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

"Authentification et Gestion des clients" et "La création d’un nouveau scénario".

— Le quatrième chapitre se penche sur la conception et au développement de deux sprints

"Gestion des téléphones des conseillés" et "Gestion des calendriers et configuration des
scénarios".

— Le dernier chapitre illustre les outils technologiques et matériels utilisés ainsi les diagrammes
de composants et déploiement spécifique pour notre application puis les structures et les
interfaces développés durant ce stage.

Enfin, nous clôturons ce rapport par une conclusion générale ainsi que les perspectives de notre
travail.

ENIG Page 1
Chapitre

1
Context générale de projet

Sommaire
1.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Context de projet . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . 3
1.3.1 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Domaines d’activité . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.3 Équipe contact plus . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.3 Solution envisagée . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Méthodologie de gestion de projet . . . . . . . . . . . . . . . . 9
1.5.1 Présentation de la méthode SCRUM . . . . . . . . . . . . . . . 9
1.5.2 Les rôles dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.3 Le sprint agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

ENIG Page 2
CHAPITRE 1. CONTEXT GÉNÉRALE DE PROJET

1.1 INTRODUCTION

Ce premier chapitre aura pour objectif la présentation de l’entreprise dans laquelle nous
avons effectué ce stage.Ensuite, nous nous intéressons au contexte du projet , la problématique
à résoudre , les objectifs à atteindre et enchaînons par la proposition des grandes lignes de notre
solution envisagée. Enfin, nous parlerons de la méthodologie de développement adoptée dans
notre projet.

1.2 Context de projet

Notre travail a été élaboré au sein de l’entreprise SOFRECOM. Ce projet de fin d’études
vise principalement à faciliter la mise en contact d’un client avec un conseiller. Il s’agit de
mettre en place d’une plate-forme de configuration de scénario d’appel téléphonique selon la
disponibilité du centre de contact du client. Ce projet représente pour nous une opportunité pour
mettre en pratique les compétences acquises au sein del’ENIG.

1.3 Présentation de l’organisme d’accueil

Notre de stage de fin d’étude est réalisé au sein de l’unité d’affaire « OAB » de la société
SOFRECOM Tunisie en faisant partie de l’équipe «Contact plus».

1.3.1 Présentation générale

Inaugurée en Octobre 2011, SOFRECOM Tunisie est à présent un acteur majeur du conseil
et d’ingénierie en télécommunications sur le marché local. C’est la plus jeune et la plus importante
filiale du groupe SOFRECOM en zone de L’Afrique et Moyen Orient.

En 8 ans seulement, SOFRECOM Tunisie compte déjà plus de 650 ingénieurs et experts, elle
a acquis sa force et sa crédibilité au travers de centaines de projets diversifiés à l’international,
lui permettant d’avoir une longueur d’avance sur ses concurrents. Elle travaille pour trois clients

ENIG Page 3
CHAPITRE 1. CONTEXT GÉNÉRALE DE PROJET

majeurs du groupe Orange : OAB, DS France et OLS. Elle connaît une très forte croissance
depuis sa création avec plus de 600 collaborateurs en 2018 [1].

F IGURE 1.1: Logo sofrecom [1]

1.3.2 Domaines d’activité

SOFRECOM Tunisie possède une forte expertise qui couvre les domaines d’activité suivantes :
• Centres de Services Nearshore « Développement T » et « Plates-formes de Services » :
Architecture, Design de Services Logiciels, Ingénierie, Gestion de projets, Validation Intégration,
Gestion de Plates-formes, Opérations ...
• Conseil en TN (T Networks) : Customer Experience Management (CEM), Design de Réseaux
(Fixe, Mobile, Infrastructure), Optimisation Coûts Investissement Réseaux (Capex/Opex), Transformation
de Réseaux (LTE, FTTx), Solutions OSS- BSS, Sécurité, Stratégie T, Services PMO, Conseil
e-Gov/SmartGov, e-Health ...
• Conseil Business : Services Financiers Mobiles, B2B, Transformation Digitale, Capacity [3] .

1.3.3 Équipe contact plus

Nous avons intégré l’équipe Contact Plus durant la période de mon stage de fin d’études.
L’équipe Contact Plus fait partie de l’unité d’affaires OAB et mène les différents travaux de
développement, test, qualification de divers projets.

ENIG Page 4
CHAPITRE 1. CONTEXT GÉNÉRALE DE PROJET

1.4 Étude de l’existant

La création d’une solution informatique innovante et qui répond aux besoins des clients
nécessite des observations et une analyse des solutions existantes. Notre étude de l’existant
portera sur l’ancienne application Contact Plus. Nous détecterons les différentes anomalies
qu’elle présente et nous proposons nos améliorations.

1.4.1 Description de l’existant

L’interface graphique de l’application existante se caractérise par la simplicité. Il s’agit

de tableaux simples sur un fond blanc et rose avec insertion automatique dans ce dernier
et possibilité de suppression d’élément. Les rubriques de centre de contact (liste de filtrage,
paramétrage de scénario, . . . ) sont représentées de cette même façon. L’affichage des images de
la bibliothèque est très simple de sorte qu’elles ne sont pas trop claires. L’interface d’accueil est
trop classique, elle est représentée sous forme de ligne qui n’attire pas l’utilisateur.

Nous présentons par les figures ci-dessous des captures d’écran de l’ancienne application de
contact plus.

F IGURE 1.2: Interface d’authentification de l’ancienne IHM de contact plus

ENIG Page 5
CHAPITRE 1. CONTEXT GÉNÉRALE DE PROJET

F IGURE 1.3: Interface d’accueil de l’ancienne IHM de contact plus

F IGURE 1.4: Page de gestion de téléphone de l’ancienne IHM de contact plus

F IGURE 1.5: Page de paramétrage de scénario de l’ancienne IHM de contact plus

ENIG Page 6
CHAPITRE 1. CONTEXT GÉNÉRALE DE PROJET

1.4.2 Critique de l’existant

1.4.2.1 Technologie

Nous énumérons ci-dessous nos remarques concernant les technologies utilisés :

• Le Framework Flex se base sur le langage MXML pour la création des interfaces web et Action
Script qui est un langage de programmation procédurale orienté objet nécessaire pour gérer les
évènements déclenchés à partir des vues. Bien que cette architecture présente des avantages,
elle impose des problèmes de performances et de fluidité lors de la navigation dans de grosses
applications.
• Les composants graphiques que’offre le Framework Flex sont primitifs. De ce fait, nous
finissons par avoir une interface très simple et qui n’est pas conviviale. Nous expliquerons ce
point d’avantage dans la partie « Interface graphique ».
• L’application est encore sous la version 6 de Java et des versions relativement anciennes du
Framework Flex. Des travaux de migration de versions (pour passer par exemple à la version
8 de Java) seront très complexes, exigeront beaucoup de temps et n’auront pas un apport
significatif sur l’application (vu les limites du Framework Flex que nous avons déjà invoqué).

1.4.2.2 L’interface graphique

L’interface graphique de l’application actuelle présente beaucoup d’anomalies. A part la

primitivté des composants graphiques qu’offre le Framework Flex, nous remarquons auss :
• Aucun style n’est appliqué sur l’ensemble de l’application.
• Manque d’affichage de quelques composants tels que les pop-up qui ne s’affichent pas carrément
lors d’une modification.
• La non homogénéité de l’interface (mal alignement et positionnement des éléments graphiques,
taille des champs. . . ).
• Il n’y a pas la possibilité de recherche des éléments dans tous les tableaux ni avec un seul
champ ou plusieurs champs.
• Pour la page de l’affichage des scénarios, toutes les données sont empilées dans la même page.

ENIG Page 7
CHAPITRE 1. CONTEXT GÉNÉRALE DE PROJET

Un utilisateur doit continuer à défiler la page pour pouvoir visualiser ces données. Cette page
présente une surcharge considérable d’information.
• Aucune demande de confirmaton des changements n’est demandée lors d’une mise à jour des
données (qui est considérée comme action très sensible et dangereuse).

1.4.3 Solution envisagée

Suite à l’étude de l’existant, et en considérant les limites qu’impose l’environnement technique

de l’application actuelle, nous avons établi une approche de migration technologique. Le but est
de redévelopper l’application en s’assurant de reporter les fonctionnalités existantes tout en
tenant compte des évolutions qui peuvent être apportées plus tard. L’approche de migration est
comme suit :
• Une phase d’étude fonctionnelle qui est requise pour maîtriser le contexte du projet Contact
Plus.
• Une phase d’étude technique qui consiste à explorer la pile technologique existante et à
étudier le code source afin de pouvoir identifier les méthodes clefs de l’outil. Cette étude est
suivie du choix du nouvel environnement technologique (langages de programmation, outils,
architecture. . . ).
• Préparation d’un Template graphique pour la couche présentation de la nouvelle version de
l’application qui se base sur la pile technologique choisie. Cette étape est importante pour
valider la nouvelle disposition graphique avec les métiers avant de démarrer le développement.
• Mettre en place le socle de l’application qu définit l’architecture de l’application.
• Mener les travaux de conception et de développement de l’application à la base du socle mis
en place.
Ces différentes étapes constituent un plan d’exécution durant ce stage afin de bien mener les
tâches de migration de l’application et garantir la qualité du produit final livré.

ENIG Page 8
CHAPITRE 1. CONTEXT GÉNÉRALE DE PROJET

1.5 Méthodologie de gestion de projet

Le choix entre un modèle de processus de développement et un autre, dépend de la nature

du projet et de sa taille. Lorsqu’il s’agit d’un projet où les données ne sont pas réunies dès
le départ, où les besoins sont incomplets voire floues, il recommander de s’orienter vers une
méthode itérative ou orientée prototypes. Parmi les méthodes itératives, nous pouvons citer les
méthodes AGILE largement utilisées de nos jours à travers le monde. Une méthode AGILE est
menée dans un esprit collaboratif et s’adapte aux approches incrémentales. Elle engendre des
produits de haute qualité tout en tenant compte de l’évolution des besoins du client. Elle permet
aussi de gérer la qualité en continu et de détecter des problèmes le plus tôt au fur et à mesure,
permettant ainsi d’entreprendre des actions correctrices sans trop de pénalités dans les coûts et
les délais. Il y a plusieurs méthodes AGILE et il ne s’agit pas de choisir la meilleure méthode
parmi celles existantes. Pour notre projet, nous nous sommes orientés vers une méthode de type
AGILE et plus particulièrement SCRUM [4].

1.5.1 Présentation de la méthode SCRUM

Le principe de la méthodologie SCRUM est de développer un logiciel de manière incrément

ale en maintenant une liste totalement transparente des demandes d’évolutions ou de corrections
à implémenter. Avec des livraisons très fréquentes, le client reçoit un logiciel fonctionnel à
chaque itération. Plus le projet avance, plus le logiciel est complet et possède toujours de plus
en plus de fonctionnalités [5].

1.5.2 Les rôles dans SCRUM

La méthodologie SCRUM fait intervenir trois rôles principaux qui sont :

• Product owner : dans la majorité des projets, le responsable produit (Product owner) est le
responsable de l’équipe projet client. C’est lui qui va définir et prioriser la liste des fonctionnalités
du produit et choisir la date et le contenu de chaque sprint sur la base des valeurs (charges) qui
lui sont communiquées par l’équipe,

ENIG Page 9
CHAPITRE 1. CONTEXT GÉNÉRALE DE PROJET

• Scrum Master : véritable facilitateur sur le projet, il veille à ce que chacun puisse travailler au
maximum de ses capacités en éliminant les obstacles et en protégeant l’équipe des perturbations
extérieures
• Equipe de développement : l’équipe s’organise elle-même et elle reste inchangée pendant toute
la durée d’un sprint. Elle doit tout faire pour délivrer le produit [6].

F IGURE 1.6: La méthodologie Scrum [6]

1.5.3 Le sprint agile

Le sprint agile représente le cœur de la méthode scrum. Cette qualification lui correspond
plutôt bien, puisque tous les développements incrémentaux menant petit à petit au produit final
du projet sont réalisés au sein des sprints
Un périmètre de développement est défini au début d’un sprint et doit être entièrement réalisé
lorsqu’il se termine. Chaque sprint doit apporter des fonctionnalités supplémentaires à l’application
en cours de développement qui doivent être livrées lorsqu’il se termine.
Le product owner est le responsable de définir les sprints et d’organiser le «backlog product»
afin de faciliter la construction du produit [7].

1.6 Conclusion

Ce premier chapitre constitue une étape primordiale pour fixer les repères de notre projet.
Après avoir présenté l’organisme d’accueil et avoir reconnu les attentes du projet, nous avons
déterminé le cadre du travail ainsi que la méthodologie à emprunter lors de ce stage. Dans le

ENIG Page 10
CHAPITRE 1. CONTEXT GÉNÉRALE DE PROJET

prochain chapitre nous décrirons quelques notions indispensable à la phase de compréhension

de ce travail.

ENIG Page 11
Chapitre

2
Analye et spécification des besoins

Sommaire
2.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Étude des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Besoin non fonctionnel . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Planification de projet . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Equipe de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Les sprints du projet . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

ENIG Page 12
CHAPITRE 2. ANALYE ET SPÉCIFICATION DES BESOINS

2.1 INTRODUCTION

La spécification des besions est primordiale lors du développement de la première phase du

cycle logiciel. Une étude des besoins globaux de ces acteurs est alors nécessaire. Ensuite, nous
exposerons les besoins non fonctionnels ainsi que notre backlog de produit.

2.2 Étude des besoins

2.2.1 Identification des acteurs

L’accès aux différentes parties du système n’est pas autorisé pour tous les utilisateurs qui
se dfférencient par un droit qu leur permet de bénéficier de cette tâche ou non, les différents
acteurs qui interagissent dans notre système sont :
Super-Admin : C’est le représentant coté orange. C’est le superviseur qui contrôle l’application
web.Son rôle consiste à gérer les clients, consulter et modifier la liste des clients ainsi leurs
comptes.De plus il a le droit de créer de nouveau scénario
Gestionnaire : C’est le représentant du client, il a toutes les permissions à tous les modules
qu’offre l’outil contact Plus tel que : gestion utilisateur, gestion centre de contact, calendrier,
configuration scénario.

2.2.2 Besoins fonctionnels

Dans notre projet, la solution proposée doit répondre à un ensemble des besoins fonctionnels
qui vont représenter le backlog produit de notre solution.
Ce backlog produit est constitué des fonctionnalités suivantes :
• Gérer les clients
• Gérer les comptes clients
• Ajouter un nouveau scénario
• Gérer les téléphones des conseillers

ENIG Page 13
CHAPITRE 2. ANALYE ET SPÉCIFICATION DES BESOINS

• Configurer un scénario
• Modifier un calendrier

2.2.3 Besoin non fonctionnel

• Ergonomie : Comme évoqué dans le premier chapitre, l’un des buts les plus importants de
la refonte de l’IHM Contact Plus est d’améliorer l’interface graphique qu’il offre. Il est naturel
d’évoquer l’importance de l’ergonomie de la nouvelle version de cet outil. Notre application
doit donc offrir une interface conviviale et qu facilite l’exploitation des fonctionnalités offertes à
l’utilisateur.Cela est réalisé à l’aide d’Angular qui permet de créer des singles page applications
(SPA).En effet, angular est l’outil principal qui nous permet de garantir une gestion dynamique
du contenu et reste une excellente solution pour programmer notre application web hautement
interactive.

• Évolutivité : Le développement des applications informatiques doit se faire en considérant

toujours l’évolutivité du système ultérieurement. Modélisation efficace et correcte, respect des
bonnes pratiques de programmation.Pour cela, on a utilisé les framework de développement
(spring,angular) afin d’obtenir des architectures modulaires, extensibles et apte à évoluer dans
le futur.

• Sécurité : L’application doit garantir la sécurité des données qu’elle gère. Le mécanisme
d’authentification doit permettre de s’assurer de l’authenticité de l’utilisateur connecté et de la
validité des autorisations qu’il détient lors de sa manipulation de l’outil. De plus, les échanges
entre le back end et le front end doivent être protégés.C’est dans le but nous avons utilisé Spring
Security qui intervient dans la mise en place d’une authentification fiable, robuste et facile à
integrer à notre projet.

ENIG Page 14
CHAPITRE 2. ANALYE ET SPÉCIFICATION DES BESOINS

2.3 Planification de projet

2.3.1 Equipe de Scrum

Dans le contexte de notre projet, Monsieur Yengi Aymen, le directeur de l’unité OAB sera
le product owner ,Monsieur Ellouz Haitham le chef de projet sera Scrum Master et je fais partie
de l’équipe de développement

2.3.2 Backlog produit

Le tableau résume le backlog produit de l’application ou chaque user story est caractérisée
par un nom, une priorité et un acteur.

Scénario ou story Acteur Priorité

S’authentifier super-admin+gestionnaire Elevé

Gérer les clients super-admin moyenne

Ajouter un nouveau scénario pour un

super-admin moyenne
clients

Gérer les téléphones gestionnaire Elevé

Modifier un calendrier gestionnaire Elevé

Configurer les scénarios gestionnaire Elevé

TABLE 2.1: Backlog produit

2.4 Les sprints du projet

La réunion de planification des sprints est considérée comme un événement initial et très
important lors de l’application de la méthode Scrum.Pour ce faire, nous avons développé notre
projet en deux releases.

ENIG Page 15
CHAPITRE 2. ANALYE ET SPÉCIFICATION DES BESOINS

2.5 Conclusion

Durant ce chapitre, nous avons identifié tout d’abord les acteurs principaux de notre application
ainsi que les besoins fonctionnels et nom fonctionnels de notre système.Ensuite, nous avons
détaillé la planification de projet suivant la méthodologie adoptée ainsi que la présentation de
backlog du produit et les sprints réalisés. Dans le chapitre suivant nous entamons le développement
de la première release.

ENIG Page 16
Chapitre

3
Release 1

Sommaire
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Sprint1 : Authentification et Gestion des clients . . . . . . . 18
3.3.1 Backlog sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Sprint2 :Création d’un nouveau scénario . . . . . . . . . . . . 24
3.4.1 Backlog sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

ENIG Page 17
CHAPITRE 3. RELEASE 1

3.1 Introduction

Un release présente une période de temps pendant laquelle un produit sera livré, composé
par une suite d’itérations (sprint) successifs.Ce chapitre est consacré au traitement de notre
premier release qui est composé de deux sprints, chacun ayant une période bien déterminée.

3.2 Planification

Le premier release est constitué par deux sprints exprimés dans la figure 3.1

F IGURE 3.1: Planification du release 1

3.3 Sprint1 : Authentification et Gestion des clients

Le but de ce sprint est de réaliser la partie de l’authentification et gestion des clients dans une
durée de semaines.Une fois,le but et la durée sont fixés , nous précisons les tâches utilisateurs
inclus dans ce sprint à partir du backlog sprint. Ensuite nous passons à l’analyse, à la conception
et au traitement de ce sprint.

ENIG Page 18
CHAPITRE 3. RELEASE 1

3.3.1 Backlog sprint

Le backlog de sprint est un ensemble des scénarios identifiés par l’équipe Scrum à exécuter
pendant le sprint.

User story Tâche

Préparer la partie design de l’interface de

S’authentifier
l’authentification de super-admin + couche métier

Réaliser un outil pour ajouter , modifier

Gérer les clients
et supprimer des clients (aussi pour les comptes clients)

TABLE 3.1: Backlog sprint "Gestion des clients"

3.3.2 Analyse des besoins

La partie analyse des besoins d’un sprint se décrit par le diagramme de cas d’utilisation de
ce sprint ainsi leur description textuelle.

3.3.2.1 Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation représente un ensemble de séquences d’action ou tâche

qu’un acteur peut réaliser ou accomplir en interaction avec les différents acteurs du système.Le
diagramme de cas d’utilisation du premier sprint est exprimé dans la figure 3.2 :

F IGURE 3.2: Diagramme de cas d’utilisation de sprint Gestion des clients

ENIG Page 19
CHAPITRE 3. RELEASE 1

3.3.2.2 Description textuelle

Pour mieux lire notre diagramme des cas d’utilisation , les concepteurs d’UML proposent
une technique qui sert à décrire le comportement du système informatique appelée la description
textuelle.De ce fait,nous allons présenter les descriptions textuelles de nos cas d’utilisation via
les tableaux ci-dessous.

Titre S’authentifier

Rôle Super-admin,Gestionnaire

Pré-condition l’utilisateur est enregistré dans la base de donnée

1.L’utilisateur demande la page d’authentification..

2.Le système affiche le formulaire d’authentification .
Scénario nominal 3.l’utilisateur saisit ses identifiant puis il valide.
4.Le système vérifie les donnée saisit et affiche l’interface réservée
à l’utilisateur.

Si le pseudo d’utilisateur et/ou le mot de passe ne sont pas correctes

Scénario alternatif
l’enchaînement se reprend à l’étape 3.

Post-condton Utilisateur authentifié

TABLE 3.2: Description Textuelle :"s’authentifier "

ENIG Page 20
CHAPITRE 3. RELEASE 1

Cas d’utilisation Gérer les clients

Rôle Utilisateur a un rôle super-Admin

Pré-condition l’utilisateur est authentifié et connecté à l’application.

1.L’utilisateur clique sur le bouton "Modifier".

2.L’utilisateur modifie les différents critères du client.
Scénario nominal 3.l’utilisateur clique sur le bouton "valider".
4.L’ajout est effectué par le back-end de l’application.
5.L’utilisateur est redirigé vers la page qui affiche la liste des clients.

Un message d’erreur est surmonté à l’utilisateur lorsqu’il oublie

Scénario alternatif
de saisir les champs obligatoires.

Post-condton Client modifié

TABLE 3.3: Description Textuelle :"gérer les clients "

3.3.3 Conception

3.3.3.1 Diagramme de séquence

Le diagramme de séquence est une représentation dynamique des différents scénarios qui
s’exécutent entre les objets de l’application selon un point de vue temporel.Les figure ci-dessous
présentent les diagrammes de séquence de nos cas d’utilisation :

Diagramme de séquence de cas d’utilisation "s’authentifier" :

ENIG Page 21
CHAPITRE 3. RELEASE 1

F IGURE 3.3: Diagramme de séquence de cas d’utilisation "s’authentifier"

Afin d’améliorer la sécurité,on utilise l’authentification à la base de token (voir Annexe).Le

diagramme de séquence ci-dessous explique les étapes de l’authentification d’un utilisateur.Ce
dernier doit saisir son pseudo et son mot de passe dans les champs convenables. Les données
saisie seront envoyés dans une requête HTTP vers l’API de route /apli/login avec la méthode
POST.
Si les informations saisies sont valides, l’utilisateur sera envoyé vers son espace de travail sinon
un message d’erreur sera affiché.

Diagramme de séquence de cas d’utilisation "gérer les clients" :

ENIG Page 22
CHAPITRE 3. RELEASE 1

F IGURE 3.4: Diagramme de séquence de cas d’utilisation "gérer client"

3.3.3.2 Diagramme de classes

Un diagramme de classe fournit une version logique du système à travers une représentation
statistique des différentes classes nécessaires pour l’application ainsi que les relations entre
ces dernières (association,généralisation,agrégation...). En fait,la figure ci-dessous présente le
diagramme des classes participant dans ce sprint.

F IGURE 3.5: Diagramme de classe de sprint "authentification et Gestion des clients"

ENIG Page 23
CHAPITRE 3. RELEASE 1

3.4 Sprint2 :Création d’un nouveau scénario

3.4.1 Backlog sprint

La table 3.4 présente le backlog du sprint "Création d’un nouveau scénario"

User story Tâche

Ajout des scénarios Préparer un outil afin que l’utilisateur puisse ajouter un nouveau scénario

TABLE 3.4: Backlog sprint "Création d’un nouveau scénario"

3.4.2 Analyse des besoins

3.4.2.1 Diagramme de cas d’utilisation

La figure 3.5 présente le diagramme des cas d’utilisations détaillé du sprint 2 :

F IGURE 3.6: Diagramme de cas d’utilisation du sprint "Création d’un nouveau scénario"

3.4.2.2 Description textuelle

La description textuelle de cas d’utilisation "Ajouter un nouveau scénario " est présentée
dans la table suivante :

ENIG Page 24
CHAPITRE 3. RELEASE 1

Cas d’utilisation Créer un nouveau scénario

Rôle Utilisateur a un rôle super-Admin

Pré-condition L’utilisateur est authentifié et connecté à l’application

1.L’utilisateur clique sur le bouton "Ajouter".

2.L’utilisateur saisit les différents critères du scénario.
Scénario
3.l’utilisateur clique sur le bouton "valider".
4.L’ajout est effectué par le back-end de l’application

Un message d’erreur est surmonté à l’utilisateur lorsqu’il oublie

Scénario alternatif
de saisir les champs obligatoires.

Post-condition Scénario ajouté.

TABLE 3.5: Description textuelle du cas d’utilisation :"créer un nouveau scénario"

3.4.3 Conception

3.4.3.1 Diagramme de séquence

Après la procédure de l’authentification,le super-admin pourrait ajouter un nouveau scénario

dans l’application.Ce scénario est décrit dans le diagramme 3.6 suivant :

F IGURE 3.7: Diagramme de séquence de cas d’utilisation : "créer un nouveau scénario"

3.4.3.2 Diagramme de classe

Le diagramme de classe du cas d’utilisation "Créer un nouveau scénario" est exprimés dans la
figure 3.7 :

ENIG Page 25
CHAPITRE 3. RELEASE 1

F IGURE 3.8: Diagramme de classe de sprint "Création d’un nouveau scénario"

3.5 Conclusion

Dans cette partie, nous avons finalisé le premier release de notre projet avec lequel nous avons
réalisé l’authentification des différents utilisateurs de notre application , la gestion des clients
ainsi que la partie de la création d’un nouveau scénario.Il nous reste maintenant la phase de
gestion des téléphones des conseillers et la configuration des scénarios qui seront étudiés dans
le chapitre suivant.

ENIG Page 26
Chapitre

4
Release 2

Sommaire
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Gestion des téléphones des conseillers . . . . . . . . . . . . . . 28
4.3.1 Backlog sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 Sprint 2 : Gestion des calendriers+ Configuration d’un scénario 31
4.4.1 Backlog sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

ENIG Page 27
CHAPITRE 4. RELEASE 2

4.1 Introduction

Après avoir entamé le premier release de notre application, nous pouvons nous lancer dans
le traitement nécessaire pour réaliser le second release.Tout au long de ce chapitre, nous
présenterons les deux sprints "la gestion des téléphones des conseillers" , la configuration d’un
scénario et la gestion des calendriers en détaillant le backlog de chaque sprint et en abordant la
partie conception.

4.2 Planification

Le deuxième release est constitué par deux sprints, illustrés dans la figure suivante :

F IGURE 4.1: Planification du release 2

4.3 Gestion des téléphones des conseillers

Le sprint "Gestion des conseillés " qui s’est déroulé dans quatre semaines,a pour but l’ajout
des téléphones des conseillers , la modification et la suppression des téléphones affichés dans la
liste de centre de contact.

ENIG Page 28
CHAPITRE 4. RELEASE 2

4.3.1 Backlog sprint

User story Tâche

Préparer un outil pour que le gestionnaire

Consulter les téléphones des conseillers
peut consulter les téléphones des conseillers

Préparer une interface pour que le gestionnaire

Gérer les téléphones des conseillers peut modifier, ajouter
et supprimés les téléphones des conseillers.

TABLE 4.1: Backlog sprint "Gestion des téléphones des conseillers"

4.3.2 Analyse des besoins

4.3.2.1 Diagramme des cas d’utilisation

Le diagramme 4.2 décrit les cas d’utilisations spécifiques pour le sprint "Gestion des téléphones
des conseillers".

F IGURE 4.2: Diagramme de cas d’utilisation du sprint "Gestion des téléphones des conseillés"

ENIG Page 29
CHAPITRE 4. RELEASE 2

4.3.2.2 Description Textuelle

La description des cas d’utilisations "gérer les téléphones" est détaillée dans la table suivante :

Cas d’utilisation Gérer les téléphones des conseillers

Acteurs Utilisateur a un rôle gestionnaire

Pré-condition L’utilisateur est authentifié et connecté à l’application

1.L’utilisateur clique sur le bouton « Ajouter ».

2.L’utilisateur saisit les dfférents critères du numéro de téléphone.
Scénario nominal
3.L’utilisateur clique sur le bouton « Valider ».
4.L’ajout est effectuée par le back-end de l’application.

Un message d’erreur est surmonté à l’utilisateur

Scénario alternatif
lorsqu’il oublie de saisir les champs obligatoires

L’utilisateur est sur la page d’affichage des numéros

Post-condition de téléphone avec l’apparition d’une notification
indiquant le succès d’ajout du numéro.

TABLE 4.2: Description textuelle du cas d’utilisation "Gérer les téléphones des conseillers"

4.3.3 Conception

4.3.3.1 Diagramme de séquence

La figure 4.3 présente le diagramme de séquence de cas d’utilisation "gérer un téléphone"

ENIG Page 30
CHAPITRE 4. RELEASE 2

F IGURE 4.3: Digramme de séquence de cas d’utilisation "gérer téléphone des conseillers"

4.3.3.2 Diagramme de classes

La figure 4.4 décrit le diagramme de classe du sprint "Gestion des téléphones des conseillés".

F IGURE 4.4: Digramme classe du sprint "gestion des Téléphones des conseillé"

4.4 Sprint 2 : Gestion des calendriers+ Configuration d’un

scénario

Le sprint "Gestion des calendriers"+"Configuration d’un scénario" est de durée 10 semaines,

qui a pour objectif la configuration d’un scénario en plusieurs tâche présentées dans le backlog
suivant :

ENIG Page 31
CHAPITRE 4. RELEASE 2

4.4.1 Backlog sprint

User story Tâche

Préparer un outil pour que le gestionnaire

Gérer les calendriers
peut gérer les calendriers

Réaliser un outil pour que le gestionnaire

Configuration d’un scénario
peut configurer les scénarios

TABLE 4.3: Backlog sprint :Gestion des calendriers+ Configuration d’un scénario

4.4.2 Analyse des besoins

4.4.2.1 Diagramme des cas d’utilisation

La figure suivante est le diagramme de cas d’utilisations de sprint "Gestion des calendriers
"+"Configuration d’un scénario"

F IGURE 4.5: Diagramme de cas d’utilisation :"gérer calendriers"+"Configuration d’un scénario

ENIG Page 32
CHAPITRE 4. RELEASE 2

4.4.2.2 Description Textuelle du cas d’utilisation

Cas d’utilisation Modifier un calendrier

Acteur Utilisateur a un rôle gestionnaire

Pré-condition L’utilisateur est authentifié et connecté à l’application

1.L’utilisateur clique sur l’icône de modification du calendrier.

2.L’utilisateur est redirigé vers la page qui affiche le calendrier.
3.L’utilisateur clique sur l’icône de modification du nom calendrier.
4.L’utilisateur saisit un nom pour le calendrier.
5.L’utilisateur clique sur l’icône de validation de modification du nom.
Scénario nominal 6.L’utilisateur glisse la barre « Ouvert » soit du scénario récurent
soit du scénario exceptionnel vers un jour du calendrier.
7.Une fenêtre d’évènement est affichée.
8.L’utilisateur saisit le libellé du scénario, heure début fin,Minute début fin.
9.L’utilisateur clique sur le bouton « Valider ».
10.L’utilisateur clique sur le bouton «Enregistrer »

Scénario alternatif Aucun scénario ni récurent ni exceptionnel affiché sur le calendrier.

L’utilisateur est sur la page d’affichage du calendrier

Post-condition
en remarquant des couleurs des évènements affichés.

TABLE 4.4: Description textuelle de cas d’utilisation gérer calendrier

ENIG Page 33
CHAPITRE 4. RELEASE 2

4.4.3 Conception

4.4.3.1 Diagramme de séquence

F IGURE 4.6: Diagramme de séquence de cas d’utilisation "gérer calendrier "

4.4.3.2 Diagramme de classe

F IGURE 4.7: Diagramme de classe

ENIG Page 34
CHAPITRE 4. RELEASE 2

4.4.3.3 Diagramme d’activité

Un diagramme d’activité visualise l’état d’exécution d’un mécanisme,d’un cas d’utilisation ou

plus généralement d’un processus impliquant un ou plusieurs classificateurs sous graphe des
étapes (ou transitions) regroupées séquentiellement.
Le diagramme d’activité de cas d’utilisation "Configurer un scénario" est présenté dans la figure
4.7

F IGURE 4.8: Diagramme d’activité de cas d’utilisation "Configurer un scénario"

4.5 Conclusion

A la fin de ce release,nous pouvons livrer une version complète du produit à notre Product
Owner. Ceci est possible grâce au concept d’itération à chaque réalisation d’un produit partiel
de la solution globale. Dans le prochain chapitre nous allons présenter la partie réalisation de
notre application.

ENIG Page 35
Chapitre

5
Réalisation

Sommaire
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Architecture et environnement de travail . . . . . . . . . . . . 37
5.2.1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . 37
5.2.2 Environnement du travail . . . . . . . . . . . . . . . . . . . . . 38
5.3 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . 40
5.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.2 Éléments d’un diagramme de déploiement . . . . . . . . . . . . 40
5.3.3 Diagramme de déploiement système . . . . . . . . . . . . . . . 41
5.4 Digramme de composants . . . . . . . . . . . . . . . . . . . . . 41
5.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4.2 Diagramme de composants du système . . . . . . . . . . . . . . 41
5.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

ENIG Page 36
CHAPITRE 5. RÉALISATION

5.1 Introduction

Le chapitre réalisation représente l’étape finale de notre projet.Dans ce qui suit, nous décrirons
l’architecture de notre application ainsi que les environnements et les outils qui nous ont permis
de réaliser le projet .Ensuite, nous présenterons le diagramme de déploiement et des composants
de notre système et nous terminerons par l’exposition des différents interfaces de l’application.

5.2 Architecture et environnement de travail

5.2.1 Architecture de l’application

L’architecture logicielle est une étape primordiale pour le développement logiciel qui intervient
lors de la phase de conception.
Notre application se présente sous la forme d’une architecture à quatre niveaux qui sont :

— Couche présentation : correspond à la partie interactive et visible de l’application pour

l’utilisateur.

— Couche métier : présente la couche fonctionnelle de l’application qui contient les classes
de traitement des données.

— Couche service : présente la couche intermédiaire entre la couche métier et le serveur

externe.

— Couche accès aux données :correspond à la partie gérante l’accès aux données de
l’application, dont le rôle est la connexion à notre base de données,l’exécution des
requêtes et l’appel des procédures stockées [8].

ENIG Page 37
CHAPITRE 5. RÉALISATION

F IGURE 5.1: Architecture globale de l’application

5.2.2 Environnement du travail

5.2.2.1 Environnement matériel

Durant la phase de réalisation, nous avons choisi comme un standard pour notre projet un
ordinateur qui possède les caractéristiques suivantes :

Type DELL

Processeur Intel Core i5

Fréquence de processeur 3.6 Ghz

Mémoire installé(RAM) 12 Go

TABLE 5.1: Caractéristiques du matériels utilisé

5.2.2.2 Environnement logiciel

Dans le but de couvrir certains aspects de notre application à toutes les phases, de la spécification
et la conception ainsi que l’implémentation, il s’avère indispensable de bien choisir les outils
logiciels à utiliser pour la réalisation de ce travail.

— Draw.io : c’est un outil de conception et modélisation UML, il offre la possibilité de créer

et gérer les différents diagrammes UML.

— Eclipse IDE : est un moyen et environnement intégré destiné principalement au

développement informatique de technologie Java [9] .

ENIG Page 38
CHAPITRE 5. RÉALISATION

— Postman :est un client REST qui se présente sous forme d’une extension Chrome ou
bien d’une application stand-alone.C’est un outil qui permet de construire et de tester
directement les requêtes HTTP [10].

— Visual Studio Code :est un éditeur de code léger, multi-plateforme (Windows,Mac

et linux), développé par Microsoft.Il est livré avec un support intégré pour
JavaScript,TypeSript et Node.js et peut s’adapter à d’autre types de langages grâce à un
système d’extension bien fourni [11].

— Overleaf : un éditeur Latex en ligne pour la rédaction du rapport de stage.

5.2.2.3 Technologies utilisées

Dans cette partie, nous présenterons les principaux langages et technologies adaptés dans le
développement de notre plateforme.

— Java 1.8 : est un langage de programmation orienté objet moderne développé par
Sun Microsystems (rachetés par Oracle).il permet de développer des logiciels et des
applications qui peu fonctionner dans plusieurs machines [12].

— Spring MVC :Le framework Spring MVC de Spring a une architecture MVC
(Model-View-Controller) et ses composants sont utilisés pour développer des applications
Web flexibles et faiblement couplées. Le modèle MVC permet de séparer les différentes
parties de l’application web, c’est-à-dire de gérer la requête d’entrée envoyée par le client,
la logique métier et la logique UI (réponse à la requête d’affichage du résultat), tout en
assurant un couplage moins fort (paresse) dans différentes classes de l’application entre
[13].

— Spring Security :C’est une dépendance Spring qu offre des mécanismes de sécurisation
des applcatons JavaEE (en partculer les projets qu utilisent Spring Framework). Nous
l’utilisons dans notre contexte pour gérer l’authentification à l’IHM Contact Plus et la
vérification des rôles des utilisateurs de l’application [14].

— MySQL : présente un systéme de gestion de base de données relationnelle et objet

(SGBD).

ENIG Page 39
CHAPITRE 5. RÉALISATION

— TypeScript :est un langage de programmaton open source mplémenté par Mcrosoft

permettant d’amélorer les solutons basées sur javascrpt [15].

— Angular : : C’est un Framework front-end développé. par Google. l est basé sur le langage
TypeScrpt [16].

5.3 Diagramme de déploiement

5.3.1 Définition

Le diagramme de déploiement est visualisation statique qui modélise le déploiement physique

des informations générées par les logiciels sur les composants matériels.Il est applicable pour
le système client-serveur qui distinguent entre l’interface utilisateur et les données de système.

5.3.2 Éléments d’un diagramme de déploiement

Les éléments qui constituent un diagramme de déploiement sont principalement :

— Les noeuds : sont les éléments matériels ou logiciels du système (tels que les ordinateurs
personnels, les détecteurs , les périphériques d’impression ou les serveurs),représentés
généralement par un cube ou une boite.

— Les composants : représentés par des boites rectangulaires qui indiquent des éléments
logiciels.

— Artefacts :un artefact présente la spécification d’une partie d’information physique crée
durant le processus de développement. C’est une manière de définir un programme, un
fichier,une base de données ou une bibliothèque produite ou modifiée dans un projet à
développer.Il est symbolisé généralement par un rectangle avec le stéréotype "artifact"

— Les associations : sont des lignes simples qui indiquent les liens de communication entre
les différents composants de système.

ENIG Page 40
CHAPITRE 5. RÉALISATION

5.3.3 Diagramme de déploiement système

Pour illustrer le déploiement de notre application, nous avons réalisé le diagramme de

déploiement,comme le montre la figure 6.2, qui présente la disposition physique des différents
matériels (ou noeuds) et la répartition des composants au sein des noeuds :

F IGURE 5.2: Diagramme de déploiement de l’application

5.4 Digramme de composants

5.4.1 Définition

Un diagramme de composants est une partie statiques d’UML.C’est un moyen qui illustre la
partie logicielle et les contrôleurs intégrés d’un système comme les données( base de données
et fichiers) et les modules(fichiers sources, paquetage et bibliothèques) aussi bien les éléments
de configuration (telle que les fichiers de commandes et les scripts).

5.4.2 Diagramme de composants du système

La figure 6.3 est consacrée à la modélisation du diagramme des composants de notre application.

ENIG Page 41
CHAPITRE 5. RÉALISATION

F IGURE 5.3: Diagramme de composant du système

5.5 Réalisation

Dans cette partie, nous allons présenter quelques interfaces de notre application.

— Interface d’authentification

F IGURE 5.4: Interface d’authentfcaton

Nous avons utilisé un simple formulaire qui permet de saisir l’identifiant d’utilisateur et son
mot de passe, avec un bouton pour valider la saisie.
Espace du super-admin

ENIG Page 42
CHAPITRE 5. RÉALISATION

F IGURE 5.5: Interface de super-admin

Centre de contact
Le centre de contact regroupe les numéros de téléphone, les numéros mis en listes blanches et
listes noires.
Téléphone
La figure ci-dessous montre les numéros de téléphone sous la forme d’un tableau contenant trois
colonnes libellé, numéro appelé et numéro présenté.

F IGURE 5.6: Interface de gestion de téléphones

ENIG Page 43
CHAPITRE 5. RÉALISATION

F IGURE 5.7: Pop-up d’ajout téléphone

Ajout téléphone
Nous utilisons un simple formulaire qui permet de saisir le libellé, le numéro appelé et le numéro
présenté, avec deux boutons soit pour valider ou annuler l’insertion d’un numéro.
Filtrer téléphone
La figure ci-dessous présente la page contenant le résultat de filtrage des numéros de téléphone
suite à l’activation des barres de recherche sur chaque colonne en cliquant sur le bouton filtrer.

F IGURE 5.8: Rechercher téléphone

Supprimer téléphone
La figure ci-dessous présente un pop-up de suppression d’un numéro de téléphone.

ENIG Page 44
CHAPITRE 5. RÉALISATION

F IGURE 5.9: Pop-up de suppression téléphone

Nous utilisons des étiquettes qui permettent d’afficher le libellé, le numéro appelé et le numéro
présenté, avec deux boutons soit pour valider ou annuler la suppression d’un numéro.
Calendrier
La figure ci-dessous montre la liste des calendriers sous la forme d’un tableau contenant trois
colonnes nom, type et action.

F IGURE 5.10: Gestion calendrier

F IGURE 5.11: Affichage calendrier

ENIG Page 45
CHAPITRE 5. RÉALISATION

Affichage calendriers
Nous avons utilisé des couleurs différents qui représentent un scénario bien détermné et où on
peut les déplacer dans le calendrier pour fusionner un évènement.
Ajouter un scénario récurrent ouvert
La figure ci-dessous présente un pop-up d’ajout d’un scénario récurrent ouvert dans un
calendrier.

F IGURE 5.12: Pop-up d’ajout d’un scénario récurrent ouvert

Nous avons utilisé un simple formulaire qui permet de saisir le libellé du calendrier, début
scénario, fin scénario et un numéro d’entreprise associé au scénario avec deux boutons soit
pour valider ou annuler l’insertion d’évènement.
Affichage évènements par semaine :

F IGURE 5.13: Affichage différents scénarios par semaine

Affichage évènement par mois

ENIG Page 46
CHAPITRE 5. RÉALISATION

F IGURE 5.14: Affichage différents scénarios par mois

Affichage évènement par mois :

La figure ci-dessous montre l’affichage des différents scénarios par jour dans le calendrier.

F IGURE 5.15: Affichage différents scénarios par jour

Liste des scénaros

F IGURE 5.16: Gestion des scénarios

ENIG Page 47
CHAPITRE 5. RÉALISATION

Configuration caractéristique scénario :

La figure ci-dessous montre la page qui sert à saisir les caractéristiques d’un scénario tel que le
choix du canal de communication, le nom, le fuseau horaire de la cible, la langue . . .

F IGURE 5.17: Configuration des caractéristiques d’un scénario

Affectation un calendrier à un scénario :

La figure ci-dessous montre l’interface qui nous permet d’affecter un calendrier à notre scénario
en cours de paramétrage.

F IGURE 5.18: Affectation un calendrier à un scénario

Configuration des propriétés de l’appel téléphonique :

La figure ci-dessous présente l’interface qui nous permet de configurer notre scénario en
cours de paramétrage, cette étape consiste à saisir certaines propriétés tel que priorité d’appel,
affichage des numéros, confirmation avant mise en relation, musique d’attente . . .

ENIG Page 48
CHAPITRE 5. RÉALISATION

F IGURE 5.19: Configuration de l’appel

Editeur de fenêtre :
L’éditeur de fenêtre est la partie la plus importante dans notre projet car elle nous nous permet
de paramétrer en ligne les pages qui vont apparaître à l’appelant lors de sa mise en contact avec
un conseiller via le canal callback.
Vignette :
La fgure ci-dessous montre la configuration de la vignette qui va être injecté dans le site
bénéficiaire de notre solution.

F IGURE 5.20: Configuration de la vignette

Le paramétrage de la vignette consiste à choisir certaines caractéristiques en adéquation avec le

scénario demandé, parmi ces propriétés nous pouvons citer la période d’activation de la vignette,
choix de l’image de fond, position de la vignette . . .
Fenêtre d’ouverture
La figure ci-dessous décrit le paramétrage de la fenêtre d’ouverture qui est la première interface
qui va apparaître au client après son clique sur la vignette.

ENIG Page 49
CHAPITRE 5. RÉALISATION

F IGURE 5.21: Fenêtre d’ouverture

La configuration de la fenêtre d’ouverture consiste à choisir une image de fond pour l’interface
et le nombre de champs à ajouter avec la précision de leurs types.

5.6 Conclusion

Dans ce chapitre, nous avons décrit en premier lieu les technologies et les outils utilisées
dans notre projet.La deuxième partie a été consacré pour la présentation du diagramme de
déploiement et de composants de notre application et le dernière partie présente notre travail
moyennant des captures d’écran et une description des fonctionnalités offertes par les différentes
interfaces de l’application développé.

ENIG Page 50
 CONCLUSION GÉNÉRALE

Dans le cadre de ce stage de fin d’études, nous constatons les efforts considérables fournis
par l’équipe Contact Plus afin d’offrir un produit fiable pour configurer les scénarios d’appel
téléphoniques des clients du groupe Orange.
Cependant, l’ancienne HM Contact Plus n’est pas conviviale, elle manque d’interaction avec
le client comme l’absence des notificatons après l’exécution d’une tâche, nous pouvons
mentionner aussi que la configuration d’un scénario passe par plusieurs étapes qui prennent
beaucoup de temps à les paramétrer ,c’est pour cela il est très important d’automatiser le
processus et le simplifier le maximum pour ne pas ennuyer le client donc il était nécessaire
de simplifier l’affectation des jours normaux et jours spéciaux dans un même calendrier que
l’utilisateur peut juste déplacer des évènements sans renseigner beaucoup d’information.
Par la suite le paramétrage des fenêtres est simplifié par exemple pour les champs il faut ajouter
le nombre de champs, leurs types et ils seront ajouté automatiquement et leurs descriptions sont
modifiables dans l’interface donc nous avons évité la limitation du client. De ce fait, ce projet
de fin d’études s’est avéré d’une importance réelle pour simplifier le processus de configuration
d’un scénario et attirer le client par des interfaces conviviales et simple à manipuler pour ne pas
l’embêter.
Ce projet a été une opportunité pour utiliser des technologies modernes dans un projet
intéressant et monter en compétences sur les aspects fonctionnels du projet Contact Plus. C’était
aussi une occasion pour intégrer une équipe dynamique et compétente et de se familiariser avec
un environnement de travail professionnel énorme tel que la société SOFRECOM Tunisie. Ce
travail a été d’une valeur ajoutée considérable qui se reflétera dans nos projets futurs et vie
professionnelle.

ENIG Page 51
CONCLUSION GÉNÉRALE

Comme toutes les applications, notre solution ne peut pas être parfaite et reste toujours ouverte à
tout besoin d’amélioration.Pour ce qui est de perspectives, nous proposons dans le futur proche :

— Ajouter plus d’options concernant les scénarios d’appel téléphonique.

— Améliorer l’IHM du super-admin afin qu’il puisse contrôler l’espace du gestionnaire .

ENIG Page 52
 ANNEXES

A.1 Authentification à base de JWT

Un jeton Web JSON (JWT) est une norme ouverte (RFC 7519) qui définit un moyen compact
et autonome de transmettre en toute sécurité des informations entre des parties en tant qu’objet
JSON. Ces informations peuvent être vérifiées et fiables car elles sont signées numériquement.
Les JWT peuvent être signés en utilisant une clé secrète ou une paire de clés publiques/privées.

A.1.1 Principe

F IGURE A.1: Principe du JWT [19]

ENIG Page 53
ANNEXES

A.1.2 Composition

*Header :
L’en-tête se compose généralement de deux parties : le type de jeton, qui est JWT, et
l’algorithme de hachage utilisé, tel que HMAC SHA256 ou RSA.
*Payload :
La deuxième partie du jeton est la charge utile, qui contient les revendications. ils sont des
déclarations concernant une entité.
Il existe trois type de revendications :

— -Enregistrées

— -Publiques

— -Privées

*Signature :
La signature est utilisée pour vérifier que l’expéditeur du jeton JWT est bien celui qu’il prétend
être et de veiller à ce que le message n’a pas été modifié en cours de route. Un JWT signé est
conforme au standard JWS [17].

F IGURE A.2: format du JWT [20]

ENIG Page 54
 BIBLIOGRAPHIE

[1] https ://www.orange.tn consulté le 10/04/2020

[2] https ://www.sofrecom.com/fr/

[3] https ://www.sofrecom.com/fr/business-sectors consulté le 10/04/2020

[4] https ://www.nutcache.com/fr/blog/methodologie-scrum/ consulté le 10/05/2020

[5] https ://www.orange-business.com/fr/blogs/usages-dentreprise/management-de-projet/les-3-roles-de-scrum

consulté le 10/05/2020

[6] https ://www.scrum.org/resources/what-is-scrum. consulté le 10/05/2020

[7] ://www.tuleap.org/fr/comprendre-methode-agile-scrum-10-minutes consulté le 10/05/2020

[8] ://en.wikipedia.org/wiki/Data consulté le 20/07/2020

[9] https ://www.eclipse.org/ide/ consulté le 20/08/2020

[10] https ://blog.ippon.fr/2015/01/30/postman-le-client-pour-api-web-qui-vous-fera-oublier-les-autres/

consulté le 20/08/2020

[11] : https ://code.visualstudio.com/ consulté le 20/08/2020

[12] :https ://fr.wikipedia.org/wiki/Java consulté le 20/08/2020

[13] : https ://docs.spring.io/ consulté le 20/08/2020

[14] : https ://docs.spring.io/consulté le 20/08/2020

[15] : https ://spring.io/projects/spring-securityconsulté le 20/08/2020

[16] : https ://en.wikipedia.org/wiki/TypeScript consulté le 20/08/2020

[17] ://angular.io/ consulté le 20/08/2020

[18] :/https ://oa.dnc.global/web/-JSON-Web-Token-JWT-JWS-.html consulté le 20/08/2020

[19] :https ://www.vaadata.com/blog/fr/jetons-jwtet consulté le 25/08/2020

ENIG Page 55
BIBLIOGRAPHIE

[20] :https ://miro.medium.com/max/1148/1*0SEbHdFcVpaejejGA-1DDw.png consulté le

25/08/2020

ENIG Page 56