République Tunisienne Ministère de l’Enseignement Supérieur et de la Recherche
Scientifique
Université de Carthage
Faculté des Sciences Economiques et de Gestion de Nabeul
Mémoire de master
Préparé en vue de l’obtention du diplôme
Mastère Professionel Ingénierie des Systèmes d’Information et des Connaissances
Conception et développement d’un CRM Vicidial
dédiée aux centres d’appels et mise en place d’une
solution de reporting sous Symfony 4
Réalisé Par
Rouissi Hamza
Encadré par
Encadrante académique : Taieb Felfel
Encadrant professionnel : Taieb Felfel
Année Universitaire 2018-2019
Dédicaces
À mes très chers parents Lazher et Hayet
Aucune dédicace ne saurait exprimer mon respect, mon amour éternel et ma considération pour les
sacrifices que vous avez consenti pour mon instruction et mon bien être. Je vous remercie pour tout
le soutien et l’amour que vous me portez depuis mon enfance et j’espère que votre bénédiction
m’accompagne toujours. Que ce modeste travail soit l’exaucement de vos vœux tant formulés, le
fruit de vos innombrables sacrifices, bien que je ne vous en acquitterai jamais assez.
À mon cher frère Mohamed et ma chère sœur Naima
Ceux que j’aime à la folie, ceux qui n’ont jamais hésité à me soutenir et à m’encourager. Que Dieu
vous réserve une longue vie pleine de bonheur, de santé et de succès dans votre vie professionnelle
et familiale.
À ma regrettée soeur khaoula
Malgré ton affection incomparable, le monde a été Jaloux de toi ma soeur, tu as semé ce que tu ne
devait pas récolter alors que tu m’encourager que j’aille plus loin que possible dans mes études mais
de qui le sort m’a séparé prématurément avant même mon premier couronnement universitaire et
en fin tu as disparue de ce monde ingrat d’amour.
À mon meilleur ami Yassine Fajraoui
Pour toute l’ambiance dont tu m’as entouré, pour toute la spontanéité et ton élan chaleureux, Je te
dédie ce travail . Puisse Dieu le tout puissant exhausser tous tes vœux.
Rouissi Hamza
i
Remerciements
Nous tenons, avant de présenter notre travail, à exprimer notre grande reconnaissance en
vers les personnes qui nous ont, de prés ou de loin, apporter leurs soutiens. Qu’ils trouvent
ici collectivement et individuellement l’expression de toute notre gratitude.
Nous adressons nos vifs remerciements dans un premier temps, à toute l’équipe
pédagogique de l’FSEG Nabeul, et spécialement notre encadrant Monsieur Taieb Felfel
qui a bien voulu assurer un encadrement continu et rigoureux à ce travail tout en mettant à
ma disponibilité tous les moyens possibles et nécessaires. De plus, ses compétences et ses
conseils étaient extrêmement judicieux et constructifs.
Nous exprimons nos sincères gratitudes à toute l’équipe SCRUM et le cadre de stage, pour
l’expérience enrichissante et pleine d’intérêt qu’ils nous ont fait vivre durant ces sept mois
au sein de l’entreprise XPERIT, et spécialement notre encadrant Monsieur Taieb Felfel
pour nous avoir intégré rapidement au sein de l’entreprise et accordé toute sa confiance, son
encouragement, ses remarques et pour le temps qu’il nous a consacré tout au long de cette
période à toutes nos interrogations malgré ses grandes occupations.
Nous adressons également nos remerciements aux membres du Jury pour avoir acceptéde
juger ce travail.
ii
Table des matières
Introduction générale
1 Etude Préalable
1.1 Cadre général du projet
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . .
1.1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Analyse des applications similaires . . . . . . . . . . . . . . . . . . . . . . . .
2 Analyse et Spécification des Besoins
2.1 Méthodologie de modélisation adopté . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Analyse des besoins fonctionnels
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1
Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Besoins fonctionnels
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Méthodologie de gestion de projet adoptée . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Pourquoi SCRUM ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Gestion du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1 Equipe et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.3 Planification des releases
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Conception
3.1 Conception graphique
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1
Synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Charte graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Conception technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii
1
2
3
3
3
4
4
5
8
9
9
9
10
13
15
15
16
17
17
18
19
20
21
21
21
24
24
3.2.2 Diagramme de classe global
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4 Release 1 : Gestion des utilisateurs, gestion des centres appels,Gestion des groupes
,Gestion des campagnes et des statuts
4.1 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Sprint 1 : Gestion des utilisateurs
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Objectifs du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3
Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4
Interfaces réalisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Sprint 2 : Gestion des centres appels ,Gestion des groupes . . . . . . . . . . . . . . .
4.3.1 Objectifs du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2 Backlog du sprint 2 (Gestion des centres appels)
. . . . . . . . . . . . . . . .
4.3.3 Backlog du sprint 2 (Gestion des groupes) . . . . . . . . . . . . . . . . . . . .
4.3.4
Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.5
Interfaces réalisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Sprint 3 : Gestion des campagnes et des statuts . . . . . . . . . . . . . . . . . . . . .
4.4.1 Objectifs du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 Backlog du sprint 3 (Gestion des campagnes) . . . . . . . . . . . . . . . . . .
4.4.3 Backlog du sprint 3 (Gestion des statuts)
. . . . . . . . . . . . . . . . . . . .
4.4.4
Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.5
Interfaces réalisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
29
29
29
30
31
32
36
36
36
37
37
39
42
42
42
43
43
46
5 Release 2 : Gestion des Listes et des Fiches, gestion des Statistiques et des
numeros des téléphones , gestion des rendez-vous et des appels téléphoniques
50
5.1 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Sprint 4 :Gestion des Listes et des Fiches
. . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Objectifs du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 Backlog du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3
Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.4
Interfaces réalisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Sprint 5 : Gestion des Statistiques et des des téléphones
. . . . . . . . . . . . . . . .
51
51
51
51
52
54
57
iv
Publicité
5.3.1 Objectifs du sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2 Backlog du sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3
Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.4
Interfaces réalisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Phase de clôture
6.1 Environnement de travail
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Environnement matériel
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2 Logiciels utilisés
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.3 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.4 Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.5 Pourquoi Symfony ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion générale
Bibliographie
Webographie
Annexes
Annexe A. Backlog du produit
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annexe B. Règles de gestion et Dictionnaire de données
. . . . . . . . . . . . . . . . . . .
7.0.1 Règles de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annexe C. Description textuelle des cas d’utilisation . . . . . . . . . . . . . . . . . . . . .
7.0.2
Sprint 1 : Gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . .
7.0.3
Sprint 3 : Gestion des groupes . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.0.4
Sprint 3 : Gestion des campagnes . . . . . . . . . . . . . . . . . . . . . . . . .
7.0.5
Sprint 4 : Gestion des listes et fiches . . . . . . . . . . . . . . . . . . . . . . .
7.0.6
Sprint 5 : Gestion des téléphones et statistiques . . . . . . . . . . . . . . . . .
57
57
58
60
65
66
66
66
67
68
68
70
71
72
73
73
76
76
77
77
78
78
80
82
v
Table des figures
1.1 Logo XPERIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Interface d’accueil de l’application Bitrix24 [W4]
. . . . . . . . . . . . . . . . . . . .
2.1 Diagramme de cas d’utilisation global
. . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Méthodologie SCRUM [B2]
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Plan des releases
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Logo CRM Vicidial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Affichage responsive de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Structure de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Architecture physique
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Diagramme de classe global
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 Diagramme de cas d’utilisation du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . .
4.2 Diagrammes de séquence système « S’authentifier » . . . . . . . . . . . . . . . . . . .
4.3
Interface authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4
Interface "Message d’erreur d’authentification" . . . . . . . . . . . . . . . . . . . . .
4.5
Interface liste des utilisateurs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6
Interface Ajouter utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7
Interface modification utilisateur
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8 Diagramme de cas d’utilisation du Sprint 2 (Gestion centre d’appel ) . . . . . . . . .
4.9 Diagramme de cas d’utilisation du Sprint 2 (Gestion des groupes) . . . . . . . . . . .
4.10 Interface Liste centre d’appel
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.11 Interface Ajout d’un centre d’appel . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.12 Interface Liste groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.13 Interface Ajout d’un groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.14 Diagramme de cas d’utilisation du Sprint 3 (Gestion des statuts)
. . . . . . . . . . .
4.15 Diagramme de cas d’utilisation du Sprint 3 (Gestion des statuts)
. . . . . . . . . . .
4.16 Interface Menu campagnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.17 Interface ajouter nouvelle campagne
. . . . . . . . . . . . . . . . . . . . . . . . . . .
3
6
14
16
19
21
22
23
25
26
31
32
33
33
34
35
35
38
39
40
40
41
41
44
45
46
47
vi
4.18 Interface ajouter nouvelle statut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.19 Interface Menu statuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 Diagramme de cas d’utilisation du Sprint 4 (Gestion des listes)
. . . . . . . . . . . .
5.2 Diagramme de cas d’utilisation du Sprint 4 (Gestion des fiches) . . . . . . . . . . . .
5.3
Interface les listes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4
Interface Ajouter une liste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5
Interface Liste des fiches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6
Importer fiche CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7 Exemple fiche CSV exporté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.8 Diagramme de cas d’utilisation du Sprint 5(Gestion statistiques)
. . . . . . . . . . .
5.9 Diagramme de cas d’utilisation du Sprint 5(Gestion téléphones) . . . . . . . . . . . .
5.10 Diagramme de séquence système « Consulter les statistiques » . . . . . . . . . . . . .
5.11 Interface Ajouter téléphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.12 Interface Tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.13 Interface Statistiques des campagnes . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.14 Interface Nombre de fiches pour chaque statut . . . . . . . . . . . . . . . . . . . . . .
5.15 Interface Nombre de fiches appelées pour chaque statut . . . . . . . . . . . . . . . . .
5.16 Interface Nombre de fiches non appelées pour chaque statut . . . . . . . . . . . . . .
48
48
53
53
54
55
55
56
56
58
59
60
61
61
62
63
63
64
6.1 Architecture de Symfony [W12]
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
vii
Liste des tableaux
2.1 Besoins fonctionnels de « Gestion des comptes et des rôles» . . . . . . . . . . . . . .
2.2 Besoins fonctionnels de « Gestion des campagnes» . . . . . . . . . . . . . . . . . . .
2.3 Besoins fonctionnels de « Gestion des statuts» . . . . . . . . . . . . . . . . . . . . . .
2.4 Besoins fonctionnels de « Gestion des listes» . . . . . . . . . . . . . . . . . . . . . . .
2.5 Besoins fonctionnels de « Gestion des groupes» . . . . . . . . . . . . . . . . . . . . .
2.6 Besoins fonctionnels de « Gestion des fiches» . . . . . . . . . . . . . . . . . . . . . .
2.7 Besoins fonctionnels de « Gestion des utilisateurs» . . . . . . . . . . . . . . . . . . .
2.8 Besoins fonctionnels de « Gestion des statistiques» . . . . . . . . . . . . . . . . . . .
2.9 Rôles SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Publicité
2.10 Backlog du produit géneral
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
11
12
12
12
12
13
13
17
18
3.1 Description des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.1 Planification des sprints de la première release . . . . . . . . . . . . . . . . . . . . . .
4.2 Backlog du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Backlog du deuxième sprint (Gestion des centres d’appels) . . . . . . . . . . . . . . .
4.4 Backlog du deuxième sprint (Gestion des groupes)
. . . . . . . . . . . . . . . . . . .
4.5 Backlog du troisième sprint (Gestion des camapgnes) . . . . . . . . . . . . . . . . . .
4.6 Backlog du troisième sprint (Gestion des statuts) . . . . . . . . . . . . . . . . . . . .
5.1 Planification des sprints de la deuxième release . . . . . . . . . . . . . . . . . . . . .
5.2 Backlog du quatrième sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Backlog du cinquième sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 Caractéristiques de l’ordinateur utilisé . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Logiciels utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Description textuelle du cas d’utilisation « S’authentifier » . . . . . . . . . . . . . . .
29
30
36
37
42
43
51
52
57
66
66
67
68
75
77
viii
7.3 Description textuelle du cas d’utilisation « Ajouter groupe» . . . . . . . . . . . . . .
7.4 Description textuelle du cas d’utilisation « Ajouter nouvelle campagne» . . . . . . .
7.5 Description textuelle du cas d’utilisation « Ajouter une statut » . . . . . . . . . . . .
7.6 Description textuelle du cas d’utilisation « Ajouter une nouvelle liste » . . . . . . . .
7.7 Description textuelle du cas d’utilisation « Ajouter une fiche » . . . . . . . . . . . . .
7.8 Description textuelle du cas d’utilisation « Ajouter numéro de téléphone » . . . . . .
78
79
79
80
81
82
7.9 Description textuelle du cas d’utilisation « Consulter les statistiques des campagnes » 82
ix
Liste des abréviations
— CRM = Customer Relationship Management (Gestion de la Relation Client)
— ERP
= Enterprise Resource Planning
— MVC = Model View Control
x
Introduction générale
En ces temps de numérisation, les entreprises ont besoin d’un moyen pour visualiser et gérer
les données de ses clients afin de faire une interprétation de la façon dont ils se comportent. Pour le
rendre facile, ces données doivent être affichées dans une certaine façon qui nous permet de mettre
l’accent là où il y a des informations pertinentes.
De la nécessité de visualiser ces données est venue l’idée de mettre en œuvre des applications
web qui permettent de représenter facilement toutes ces informations et de les gérer d’une manière
personnalisée.
Pour cela, la demande d’interfaces de tableau de bord et des applications de visualisation de
données a été de plus en plus une façon intéressante à voir ces applications surtout à l’intérieur d’un
navigateur Web.
Dans ce contexte s’introduit notre projet de fin d’études intitulé « Conception et développement
d’un CRM Vicidial dédiée aux centres d’appels et mise en place d’une solution de reporting sous
Symfony 4 », en Master professionnel en ingénierie des Systèmes d’Information et des Connaissances
à FSEG Nabeul. Il consiste à concevoir et développer une application web qui permet sur une seule
plateforme de gérer plusieurs campagnes en intégrant toutes les fonctionnalités pour une gestion
dynamique de centre d’appel.
Pour les méthodologies de travail utilisées dans notre projet, nous allons opter pour les
méthodes agiles, plus exactement le framework SCRUM.
Le présent rapport comporte six chapitres :
Le premier chapitre, intitulé « Etude préalable » est consacré à la présentation du cadre de
notre projet, l’organisme d’accueil, l’étude de l’existant, la problématique et la solution proposée.
Le deuxième chapitre, intitulé « Analyse et spécification des besoins » décrit les acteurs du
système, les besoins fonctionnels et les diagrammes de cas d’utilisation. Le troisième chapitre, intitulé
« Conception générale » décrit la conception graphique et la conception technique globales, ainsi
que l’architecture du système.
Les deux chapitres qui suivent, comportent la conception et la réalisation de chaque release
de notre projet.
Dans le dernier chapitre « Phase de clôture », nous décrirons l’environnement matériel et
logiciel.
1
Chapitre 1
Etude Préalable
Plan
1
2
3
Cadre général du projet
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
4
4
Chapitre 1. Etude Préalable
Introduction
Ce chapitre représente une présentation générale du projet commençant par le cadre du projet,
puis la présentation de l’organisme d’accueil, ensuite la présentation du projet, la problématique et
l’analyse de l’existant afin de proposer une solution adéquate.
1.1 Cadre général du projet
Ce projet s’inscrit dans le cadre de la préparation d’un rapport de fin d’études à FSEG
Nabeul , présenté en vue d’obtenir le diplôme de Master Professionnel en Ingénierie des Systèmes
d’Information et des Connaissances. Le stage de fin d’études est effectué au sein de l’entreprise
XPERIT.
1.1.1 Présentation de l’organisme d’accueil
La société XPERIT est un cabinet de conseil spécialisé dans l’architecture et l’urbanisation
des systèmes d’informations. Nous apportons aux organisations une réelle expertise technique et un
éventail de solutions pour unifier leur SI. Nous intervenons essentiellement en conseil, intégration
et maitrise d’œuvre. Nous avons une large expérience de conseil auprès de nombreux clients des
secteurs privé et public. Nous intervenons plus particulièrement dans les secteurs des Télécoms et
de l’industrie.
Figure 1.1: Logo XPERIT
1.1.2 Présentation du projet
Le CRM VICIDIAL est un CRM prédictif stable, performant ,sécurisé et évolutif.Il convient
aux centres d’appel de petite à grande taille dans diverses industries. Il permet sur une seule
plateforme de gérer plusieurs campagnes en intégrant toutes les fonctionnalités pour une gestion
dynamique de centre d’appel. A présent, XPERIT dispose d’un site développé avec le Framework
Symfony 2 pour présenter le CRM Vicidial ainsi que ses services.
Les fonctionnalités attendues de l’application sont les suivantes :
— La gestion des campagnes ;
3
Chapitre 1. Etude Préalable
— La gestion des listes ;
— La gestion des utilisateurs ;
— La gestion des fiches ;
— La gestion des groupes d’utilisateurs ;
— La gestion des statuts ;
— La gestion des statistiques.
1.2 Etude de l’existant
Dans cette section, nous présentons une analyse de l’application existante .
— Critique de l’existant
Au cours de la phase de recherche et de collecte des informations que nous avons effectuée XPERIT,
nous avons trouvé que le CRM Vicidial, présente les limites suivantes :
— L’application est trop chargée et mal organisée. Il y a beaucoup de menus ce qui dérange
l’utilisateur ;
— Espace non ergonomique : La conception graphique de l’application était très classique et
basique. Il y avait un manque d’innovation et de créativité du coté design ;
— Application lourde : lenteur de l’application lors de l’accès à un service ;
— le site a été développé avec l’ancienne version de Symfony 2 alors pour l’améliorer on a essayé
de le mettre à jour avec la dernière version (version 4).
— Les données de l’application non sécurisées.
1.3 Solution proposée
À ce niveau, il est devenu clair que l’application existante n’est plus satisfaisante et adéquate
pour la société XPERIT. Notre mission est de concevoir et développer une nouvelle application
permettant la gestion de la relation client(GRC), ou gestion des relations avec les clients, en anglais
Customer Relationship Management (CRM).
Notre solution permettre de :
— Visualiser des tableaux de bord ;
— Améliorer les fonctionnalités de l’application ;
4
Chapitre 1. Etude Préalable
— Utiliser une architecture MVC, cette architecture sert à simplifier la tâche du développeur qui
tenterait d’effectuer une maintenance ou une amélioration sur le projet ;
— De plus, elle doit être ergonomique et facile à utiliser.
1.3.1 Analyse des applications similaires
Cette analyse a pour but de dégager les points positifs et les points négatifs des applications
existantes ce qui nous aidera à la réalisation de notre application web.
Nous avons choisi de faire l’analyse de l’existant des applications suivantes :
— L’application « Bitrix24 »
1.3.1.1 Etude de l’application « Bitrix24 »
• Adresse (URL) : https ://www.bitrix24.com/uses/free-cloud-erp.php .
Description de l’application
Bitrix24 s’articule majoritairement autour de cinq éléments principaux, à savoir : la gestion
des tâches et des projets, le CRM, mais aussi les communications internes, le centre de contact
et le constructeur de sites. Plus concrètement, cela signifie que la plateforme propose différentes
interfaces personnalisables permettant de gérer ses projets tout en communiquant simplement avec
les personnes concernées. Entre réseau social interne, messagerie, espace de stockage, appels téléphoniques,
Bitrix24 dispose d’une large palette de fonctionnalités axées sur le travail collaboratif.
5
Chapitre 1. Etude Préalable
Interface de l’application
Figure 1.2: Interface d’accueil de l’application Bitrix24 [W4]
Analyse de l’application
A) Etude fonctionnelle Dans cette application il y a un seul acteur. C’est l’administrateur qui
gère toutes les fonctionnalités de l’application.
Publicité
L’application offre à l’administrateur la possibilité de :
— Établir des devis et des factures professionnels de manières récurrentes (mensuels, annuelles,
hebdomadaires, ...)
— générer des prospects (personnes susceptibles d’être intéressées par des produits ou services)
et de les convertir en clients payants ;
— Consulter les statistiques de Pipeline des ventes,Ventes prévues,Rapports sur l’activité
des agents..
Points forts
— Bitrix24 offre des appels téléphoniques virtuels ;
— Vous pouvez stocker, rechercher, discuter et partager des documents et autres fichiers ;
— Vous pouvez gérer les communications externes via l’extranet et le CRM et avec un minimum
de navigation. ;
6
Chapitre 1. Etude Préalable
— Les outils de gestion du temps comprennent une fonction d’enregistrement et de départ, des
rapports de travail réguliers et un planificateur quotidien.
Points faibles
— Il y a tellement de fonctionnalités à parcourir qu’il faudra un certain temps pour que tout le
monde se retrouve sur la même page ;
— Trop d’options et de fonctionnalités d’intégration dans Bitrix24 peuvent parfois être confondues. ;
Conclusion
Dans ce premier chapitre, nous avons présenté l’étude préalable et étudié ce qui existe sur
le marché. Ceci nous a permis d’avoir une idée sur les améliorations que nous allons ajouter à la
solution existant afin de répondre aux besoins de XPERIT.
7
Analyse et Spécification des Besoins
Chapitre 2
Plan
1 Méthodologie de modélisation adopté . . . . . . . . . . . . . . . . . . . .
2
3
Analyse des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . .
Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Méthodologie de gestion de projet adoptée . . . . . . . . . . . . . . . . .
5
Gestion du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . .
9
9
15
15
17
Chapitre 2. Analyse et Spécification des Besoins
Introduction
La phase d’analyse et spécifications des besoins consiste à étudier les principales fonctionnalités
du système en identifiant ses acteurs et ses cas d’utilisation initiaux afin de comprendre son contexte.
En effet, au cours de ce chapitre nous allons présenter la méthodologie, les besoins fonctionnels et
non fonctionnels.
2.1 Méthodologie de modélisation adopté
Une méthodologie de modélisation consiste à créer une présentation virtuelle d’une réalité de
maniére à faire ressortir les points auxquels nous nous intéressons. Par ailleurs, elle nous offre un
support de données évolutif nécessaire pour la réalisation de notre projet. Nous trouvons plusieurs
méthodes de modélisation telle que MERISE, UML.
Nous avons choisi la méthodologie UML (Unified Modeling Language ou langage de modélisation
unifié) car elle présente divers diagrammes qui vont permettre d’effectuer une analyse détaillée des
besoins. Aussi présente le meilleur outil pour schématiser des systèmes complexes sous un format
graphique et textuel simplifié et normalisé et fournir une représentation informatique d’un ensemble
d’objets et de problèmes standards du monde réel. [B1]
2.2 Analyse des besoins fonctionnels
L’analyse fonctionnelle est une démarche qui consiste à caractériser les fonctions offertes par
un produit pour satisfaire les besoins d’un utilisateur. En effet, chacun de ces besoins reflète les
attentes des différents utilisateurs envers le système conçu. Pour cela, nous avons spécifié les acteurs
du système et les besoins fonctionnels.[W6]
2.2.1
Identification des acteurs
Un acteur est une entité externe au système. Il représente une personne ou un autre système
informatique qui attend un ou plusieurs services offerts par une interface d’accès.
Il y a trois acteurs dans notre application :
— Super administrateur : C’est l’acteur qui a une visibilité totale sur la base de données. Il a
comme tâche de gérer tout le système. Il gère les utilisateurs et les droits pour chacun d’eux.
— L’administrateur :c’est le responsable de tous les modules de l’application ..
9
Chapitre 2. Analyse et Spécification des Besoins
— Agent : C’est l’acteur qui a comme tâche de consulter ces fiches des rendez-vous sur une ou
plusieurs campagnes, d’accéder à l’historique de son activité, récupérer le temps d’appel, les
appels sortants, les enregistrements pour tous les communications et de lancer les appels.
2.2.2 Besoins fonctionnels
Nous exposons ainsi tous les besoins fonctionnels qui devront être implémentés au sein de
notre projet pour les différents modules de notre application.
— Authentification : Chaque utilisateur (administrateur et agent ), est déjà inscrit sur l’application
et a un compte. Il possède un espace spécifique qui lui permet de s’authentifier avec un login
et un mot de passe.
— Gestion des comptes et des rôles
Super
- Gérer tout le système ;
administrateur
- Affecter des rôles (droits d’accès) aux utilisateurs ;
Administrateur
- Gérer les agents ;
- gérer les groupes d’agents ;
- Gérer les listes ;
- Gérer les campagnes ;
- Le suivi de la production en temps réel, ;
- Consulter les statistiques par campagnes, par liste ou par utilisateurs.
Agent
- Consulter ces fiches des rendez-vous sur une ou plusieurs campagnes ;
- Accéder à l’historique de son activité ;
- Récupérer le temps d’appel, les appels sortants, les enregistrements pour tous
les communications et de lancer les appels.
Tableau 2.1: Besoins fonctionnels de « Gestion des comptes et des rôles»
— Gestion des campagnes
10
Chapitre 2. Analyse et Spécification des Besoins
Administrateur
- Consulter toutes les campagnes ;
- La création d’une nouvelle campagne ;
- Le modification de campagne ;
- La suppression de campagne.
Tableau 2.2: Besoins fonctionnels de « Gestion des campagnes»
11
Chapitre 2. Analyse et Spécification des Besoins
— Gestion des statuts
Administrateur
- Consulter toutes les statuts
- La création d’une nouvelle statut ;
- Le modification de statut ;
- La suppression de statut.
Tableau 2.3: Besoins fonctionnels de « Gestion des statuts»
— Gestion des listes
Administrateur
- Consulter toutes les listes ;
- Ajouter ou supprimer d’une ou de plusieurs listes ;
- visualiser le nombre de fiches traitées, non traitées dans chaque liste.
Tableau 2.4: Besoins fonctionnels de « Gestion des listes»
— Gestion des groupes
Administrateur
- Afficher toutes les groupes ;
- Ajouter ou supprimer d’une ou de plusieurs groupes.
Tableau 2.5: Besoins fonctionnels de « Gestion des groupes»
— Gestion des fiches
Administrateur
- Afficher toutes les fiches ;
- Ajouter ou supprimer d’une ou de plusieurs fiches ;
-Importer une nouvelle fiche en format CSV ;
-Exporter une fiche en format PDF.
Tableau 2.6: Besoins fonctionnels de « Gestion des fiches»
12
Chapitre 2. Analyse et Spécification des Besoins
— Gestion des utilisateurs
Administrateur
- créer , modifier , supprimer des agents ;
- Affecter des agents à différentes campagnes ;
Tableau 2.7: Besoins fonctionnels de « Gestion des utilisateurs»
— Gestion des statistiques :
Administrateur
- Consulter les statistiques par campagne ou sur plusieurs campagnes ;
- Consulter les statistiques par liste ;
- Consulter les statistiques par fiches.
Tableau 2.8: Besoins fonctionnels de « Gestion des statistiques»
2.2.3 Diagrammes de cas d’utilisation
Le diagramme de cas d’utilisation sert à définir le système, les acteurs, les cas d’utilisations
et les liens entre acteurs et cas d’utilisation. Un cas d’utilisation est un moyen de représenter les
différents possibilités d’utiliser un système, il exprime toujours une suite d’interactions entre un
acteur et l’application et définit une fonctionnalité utilisable par un acteur.
La figure 2.1 représente le diagramme de cas d’utilisation global de notre système.
13
Chapitre 2. Analyse et Spécification des Besoins
Figure 2.1: Diagramme de cas d’utilisation global
14
Chapitre 2. Analyse et Spécification des Besoins
2.3 Besoins non fonctionnels
En plus des fonctionnalités capitales citées précédemment, notre solution doit prendre en
considération certaines contraintes additionnelles et répondre à un ensemble de besoins non fonctionnels.
Il s’agit des besoins qui caractérisent le système à savoir :
— Rapidité : Il est clairement établi que la vitesse d’affichage influence fortement l’efficacité
de l’application. C’est pour cette raison qu’il faut développer une application fournissant des
résultats efficaces et cohérents et dans un temps négligeable suite aux requêtes issues des
utilisateurs ;
— User-Expérience (UX) : L’application devra être plus utilisable, désirable et navigables
permettant successivement la facilité d’emploi avec des interfaces consistantes ;
— Sécurité : L’aspect sécurité est important dans notre système. En effet, nous devons restreindre
l’accès aux différents espaces utilisateurs à toute personne non autorisée, qui pourrait accéder
à des informations confidentielles ;
— Fiabilité : Les résultats apportés par l’application doivent être fiables et reflètent effectivement
l’état de la base au moment de son interrogation, c’est-à-dire lors de la mise à jour des données
avec le CRM ;
— Ergonomie : Etant donné que notre application va être utilisé par les consultants de Topnet
les interfaces doivent être réalisées de telle façon que l’utilisateur s’y trouve facilement et ceci
en respectant la charte graphique de Xarix.
2.4 Méthodologie de gestion de projet adoptée
Afin de bien comprendre le fonctionnement de notre système, nous avons choisi la méthode
de développement agile SCRUM pour apporter de la souplesse, de la réactivité dans l’organisation
et s’adapter parfaitement à la gestion du projet.
La figure 2.2 montre le processus SCRUM :
15
Chapitre 2. Analyse et Spécification des Besoins
Figure 2.2: Méthodologie SCRUM [B2]
— Un projet utilisant la méthodologie SCRUM se base sur des itérations appelées Sprints qui se
succèdent. La durée du sprint est de 4 à 6 semaines. Chaque Sprint commence par une réunion
de planification appelée « S