R publique Tunisienne Minist re de lEnseignement Sup rieur et de la Recherche

Scientique

Universit de Carthage

Facult des Sciences Economiques et de Gestion de Nabeul

M moire de master

Pr par en vue de lobtention du dipl me

Mast re Professionel Ing nierie des Syst mes dInformation et des Connaissances

Conception et d veloppement dun CRM Vicidial

d di e aux centres dappels et mise en place dune

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

sacrices que vous avez consenti pour mon instruction et mon bien tre. Je vous remercie pour tout

le soutien et lamour que vous me portez depuis mon enfance et jesp re que votre b n diction

maccompagne toujours. Que ce modeste travail soit lexaucement de vos vSux tant formul s, le

fruit de vos innombrables sacrices, bien que je ne vous en acquitterai jamais assez.

mon cher fr re Mohamed et ma ch re sSur Naima

Ceux que jaime la folie, ceux qui nont jamais h sit me soutenir et mencourager. 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 aection incomparable, le monde a t Jaloux de toi ma soeur, tu as sem ce que tu ne

devait pas r colter alors que tu mencourager que jaille plus loin que possible dans mes tudes mais

de qui le sort ma s par pr matur ment avant m me mon premier couronnement universitaire et

en n tu as disparue de ce monde ingrat damour.

mon meilleur ami Yassine Fajraoui

Pour toute lambiance dont tu mas entour , pour toute la spontan it et ton lan chaleureux, Je te

d die ce travail . Puisse Dieu le tout puissant exhausser tous tes vSux.

Rouissi Hamza

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. Quils trouvent

ici collectivement et individuellement lexpression de toute notre gratitude.

Nous adressons nos vifs remerciements dans un premier temps, toute l quipe

p dagogique de lFSEG 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

lexp rience enrichissante et pleine dint r t quils nous ont fait vivre durant ces sept mois

au sein de lentreprise XPERIT, et sp cialement notre encadrant Monsieur Taieb Felfel

pour nous avoir int gr rapidement au sein de lentreprise et accord toute sa conance, son

encouragement, ses remarques et pour le temps quil 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.

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 lorganisme daccueil . . . . . . . . . . . . . . . . . . . . . . .

1.1.2 Pr sentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 Etude de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3 Solution propos e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.1 Analyse des applications similaires . . . . . . . . . . . . . . . . . . . . . . . .

2 Analyse et Sp cication des Besoins

2.1 M thodologie de mod lisation adopt . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Analyse des besoins fonctionnels

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1

Identication des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.2 Besoins fonctionnels

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.3 Diagrammes de cas dutilisation . . . . . . . . . . . . . . . . . . . . . . . . . .

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 Planication 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 lapplication . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iii

3.2.2 Diagramme de classe global

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Release 1 : Gestion des utilisateurs, gestion des centres appels,Gestion des groupes

,Gestion des campagnes et des statuts

4.1 Planication 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 cication 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 cication 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 cication fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.5

Interfaces r alis es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

5.1 Planication 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 cication fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2.4

Interfaces r alis es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3 Sprint 5 : Gestion des Statistiques et des des t l phones

. . . . . . . . . . . . . . . .

5.3.1 Objectifs du sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.2 Backlog du sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.3

Sp cication 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 dutilisation . . . . . . . . . . . . . . . . . . . . .

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 ches . . . . . . . . . . . . . . . . . . . . . . .

7.0.6

Sprint 5 : Gestion des t l phones et statistiques . . . . . . . . . . . . . . . . .

Table des gures

1.1 Logo XPERIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Interface daccueil de lapplication Bitrix24

. . . . . . . . . . . . . . . . . . . .

2.1 Diagramme de cas dutilisation global

. . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 M thodologie SCRUM

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3 Plan des releases

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 Logo CRM Vicidial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Achage responsive de lapplication . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3 Structure de lapplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4 Architecture physique

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5 Diagramme de classe global

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1 Diagramme de cas dutilisation du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . .

4.2 Diagrammes de s quence syst me Sauthentier . . . . . . . . . . . . . . . . . . .

4.3

Interface authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4

Interface "Message derreur dauthentication" . . . . . . . . . . . . . . . . . . . . .

4.5

Interface liste des utilisateurs

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.6

Interface Ajouter utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.7

Interface modication utilisateur

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.8 Diagramme de cas dutilisation du Sprint 2 (Gestion centre dappel ) . . . . . . . . .

4.9 Diagramme de cas dutilisation du Sprint 2 (Gestion des groupes) . . . . . . . . . . .

4.10 Interface Liste centre dappel

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.11 Interface Ajout dun centre dappel . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.12 Interface Liste groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.13 Interface Ajout dun groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.14 Diagramme de cas dutilisation du Sprint 3 (Gestion des statuts)

. . . . . . . . . . .

4.15 Diagramme de cas dutilisation du Sprint 3 (Gestion des statuts)

. . . . . . . . . . .

4.16 Interface Menu campagnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.17 Interface ajouter nouvelle campagne

. . . . . . . . . . . . . . . . . . . . . . . . . . .

4.18 Interface ajouter nouvelle statut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.19 Interface Menu statuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1 Diagramme de cas dutilisation du Sprint 4 (Gestion des listes)

. . . . . . . . . . . .

5.2 Diagramme de cas dutilisation du Sprint 4 (Gestion des ches) . . . . . . . . . . . .

5.3

Interface les listes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.4

Interface Ajouter une liste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.5

Interface Liste des ches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.6

Importer che CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.7 Exemple che CSV export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.8 Diagramme de cas dutilisation du Sprint 5(Gestion statistiques)

. . . . . . . . . . .

5.9 Diagramme de cas dutilisation 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 ches pour chaque statut . . . . . . . . . . . . . . . . . . . . . .

5.15 Interface Nombre de ches appel es pour chaque statut . . . . . . . . . . . . . . . . .

5.16 Interface Nombre de ches non appel es pour chaque statut . . . . . . . . . . . . . .

6.1 Architecture de Symfony

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 ches . . . . . . . . . . . . . . . . . . . . . .

2.7 Besoins fonctionnels de Gestion des utilisateurs . . . . . . . . . . . . . . . . . . .

2.8 Besoins fonctionnels de Gestion des statistiques . . . . . . . . . . . . . . . . . . .

2.9 R les SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.10 Backlog du produit g neral

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 Description des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1 Planication des sprints de la premi re release . . . . . . . . . . . . . . . . . . . . . .

4.2 Backlog du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 Backlog du deuxi me sprint (Gestion des centres dappels) . . . . . . . . . . . . . . .

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 Planication 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 lordinateur 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 dutilisation Sauthentier . . . . . . . . . . . . . . .

viii

7.3 Description textuelle du cas dutilisation Ajouter groupe . . . . . . . . . . . . . .

7.4 Description textuelle du cas dutilisation Ajouter nouvelle campagne . . . . . . .

7.5 Description textuelle du cas dutilisation Ajouter une statut . . . . . . . . . . . .

7.6 Description textuelle du cas dutilisation Ajouter une nouvelle liste . . . . . . . .

7.7 Description textuelle du cas dutilisation Ajouter une che . . . . . . . . . . . . .

7.8 Description textuelle du cas dutilisation Ajouter num ro de t l phone . . . . . .

7.9 Description textuelle du cas dutilisation Consulter les statistiques des campagnes 82

Liste des abr viations

CRM = Customer Relationship Management (Gestion de la Relation Client)

ERP

= Enterprise Resource Planning

MVC = Model View Control

Introduction g n rale

En ces temps de num risation, les entreprises ont besoin dun moyen pour visualiser et g rer

les donn es de ses clients an de faire une interpr tation de la fa on dont ils se comportent. Pour le

rendre facile, ces donn es doivent tre ach es dans une certaine fa on qui nous permet de mettre

laccent l o il y a des informations pertinentes.

De la n cessit de visualiser ces donn es est venue lid e de mettre en Suvre des applications

web qui permettent de repr senter facilement toutes ces informations et de les g rer dune mani re

personnalis e.

Pour cela, la demande dinterfaces 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 lint rieur dun

navigateur Web.

Dans ce contexte sintroduit notre projet de n d tudes intitul Conception et d veloppement

dun CRM Vicidial d di e aux centres dappels et mise en place dune solution de reporting sous

Symfony 4 , en Master professionnel en ing nierie des Syst mes dInformation 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 dappel.

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, lorganisme daccueil, l tude de lexistant, la probl matique et la solution propos e.

Le deuxi me chapitre, intitul Analyse et sp cication des besoins d crit les acteurs du

syst me, les besoins fonctionnels et les diagrammes de cas dutilisation. Le troisi me chapitre, intitul

Conception g n rale d crit la conception graphique et la conception technique globales, ainsi

que larchitecture 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 lenvironnement mat riel et

logiciel.

Chapitre 1

Etude Pr alable

Plan

Cadre g n ral du projet

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Etude de lexistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Solution propos e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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 lorganisme daccueil, ensuite la pr sentation du projet, la probl matique et

lanalyse de lexistant an de proposer une solution ad quate.

1.1 Cadre g n ral du projet

Ce projet sinscrit dans le cadre de la pr paration dun rapport de n d tudes FSEG

Nabeul , pr sent en vue dobtenir le dipl me de Master Professionnel en Ing nierie des Syst mes

dInformation et des Connaissances. Le stage de n d tudes est eectu au sein de lentreprise

XPERIT.

1.1.1 Pr sentation de lorganisme daccueil

La soci t XPERIT est un cabinet de conseil sp cialis dans larchitecture et lurbanisation

des syst mes dinformations. Nous apportons aux organisations une r elle expertise technique et un

ventail de solutions pour unier leur SI. Nous intervenons essentiellement en conseil, int gration

et maitrise dSuvre. 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 lindustrie.

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 dappel 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 dappel. A pr sent, XPERIT dispose dun site d velopp avec le Framework

Symfony 2 pour pr senter le CRM Vicidial ainsi que ses services.

Les fonctionnalit s attendues de lapplication sont les suivantes :

La gestion des campagnes ;

Chapitre 1. Etude Pr alable

La gestion des listes ;

La gestion des utilisateurs ;

La gestion des ches ;

La gestion des groupes dutilisateurs ;

La gestion des statuts ;

La gestion des statistiques.

1.2 Etude de lexistant

Dans cette section, nous pr sentons une analyse de lapplication existante .

Critique de lexistant

Au cours de la phase de recherche et de collecte des informations que nous avons eectu e XPERIT,

nous avons trouv que le CRM Vicidial, pr sente les limites suivantes :

Lapplication est trop charg e et mal organis e. Il y a beaucoup de menus ce qui d range

lutilisateur ;

Espace non ergonomique : La conception graphique de lapplication tait tr s classique et

basique. Il y avait un manque dinnovation et de cr ativit du cot design ;

Application lourde : lenteur de lapplication lors de lacc s un service ;

le site a t d velopp avec lancienne version de Symfony 2 alors pour lam liorer on a essay

de le mettre jour avec la derni re version (version 4).

Les donn es de lapplication non s curis es.

1.3 Solution propos e

ce niveau, il est devenu clair que lapplication existante nest 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 lapplication ;

Chapitre 1. Etude Pr alable

Utiliser une architecture MVC, cette architecture sert simplier la t che du d veloppeur qui

tenterait deectuer 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 lanalyse de lexistant des applications suivantes :

Lapplication Bitrix24

1.3.1.1 Etude de lapplication Bitrix24

" Adresse (URL) : https ://www.bitrix24.com/uses/free-cloud-erp.php .

Description de lapplication

Bitrix24 sarticule 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 signie que la plateforme propose di 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 dune large palette de fonctionnalit s ax es sur le travail collaboratif.

Chapitre 1. Etude Pr alable

Interface de lapplication

Figure 1.2: Interface daccueil de lapplication Bitrix24

Analyse de lapplication

A) Etude fonctionnelle Dans cette application il y a un seul acteur. Cest ladministrateur qui

g re toutes les fonctionnalit s de lapplication.

Lapplication ore ladministrateur 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 lactivit

des agents..

Points forts

Bitrix24 ore des appels t l phoniques virtuels ;

Vous pouvez stocker, rechercher, discuter et partager des documents et autres chiers ;

Vous pouvez g rer les communications externes via lextranet et le CRM et avec un minimum

de navigation. ;

Chapitre 1. Etude Pr alable

Les outils de gestion du temps comprennent une fonction denregistrement et de d part, des

rapports de travail r guliers et un planicateur quotidien.

Points faibles

Il y a tellement de fonctionnalit s parcourir quil faudra un certain temps pour que tout le

monde se retrouve sur la m me page ;

Trop doptions et de fonctionnalit s dint 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 davoir une id e sur les am liorations que nous allons ajouter la

solution existant an de r pondre aux besoins de XPERIT.

Analyse et Sp cification des Besoins

Chapitre 2

Plan

1 M thodologie de mod lisation adopt . . . . . . . . . . . . . . . . . . . .

Analyse des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . .

Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 M thodologie de gestion de projet adopt e . . . . . . . . . . . . . . . . .

Gestion du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 2. Analyse et Sp cication des Besoins

Introduction

La phase danalyse et sp cications des besoins consiste tudier les principales fonctionnalit s

du syst me en identiant ses acteurs et ses cas dutilisation initiaux an de comprendre son contexte.

En eet, 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 dune r alit de

mani re faire ressortir les points auxquels nous nous int ressons. Par ailleurs, elle nous ore 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 (Unied Modeling Language ou langage de mod lisation

uni ) car elle pr sente divers diagrammes qui vont permettre deectuer 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 simpli et normalis et fournir une repr sentation informatique dun ensemble

dobjets et de probl mes standards du monde r el.

2.2 Analyse des besoins fonctionnels

Lanalyse fonctionnelle est une d marche qui consiste caract riser les fonctions oertes par

un produit pour satisfaire les besoins dun utilisateur. En eet, chacun de ces besoins re te les

attentes des di rents utilisateurs envers le syst me con u. Pour cela, nous avons sp ci les acteurs

du syst me et les besoins fonctionnels.

2.2.1

Identication 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 oerts par une interface dacc s.

Il y a trois acteurs dans notre application :

Super administrateur : Cest lacteur 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 deux.

Ladministrateur :cest le responsable de tous les modules de lapplication ..

Chapitre 2. Analyse et Sp cication des Besoins

Agent : Cest lacteur qui a comme t che de consulter ces ches des rendez-vous sur une ou

plusieurs campagnes, dacc der lhistorique de son activit , r cup rer le temps dappel, 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 di rents modules de notre application.

Authentication : Chaque utilisateur (administrateur et agent ), est d j inscrit sur lapplication

et a un compte. Il poss de un espace sp cique qui lui permet de sauthentier avec un login

et un mot de passe.

Gestion des comptes et des r les

Super

G rer tout le syst me ;

administrateur

Aecter des r les (droits dacc s) aux utilisateurs ;

Administrateur

G rer les agents ;

g rer les groupes dagents ;

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 ches des rendez-vous sur une ou plusieurs campagnes ;

Acc der lhistorique de son activit ;

R cup rer le temps dappel, 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

Chapitre 2. Analyse et Sp cication des Besoins

Administrateur

Consulter toutes les campagnes ;

La cr ation dune nouvelle campagne ;

Le modication de campagne ;

La suppression de campagne.

Tableau 2.2: Besoins fonctionnels de Gestion des campagnes

Chapitre 2. Analyse et Sp cication des Besoins

Gestion des statuts

Administrateur

Consulter toutes les statuts

La cr ation dune nouvelle statut ;

Le modication 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 dune ou de plusieurs listes ;

visualiser le nombre de ches trait es, non trait es dans chaque liste.

Tableau 2.4: Besoins fonctionnels de Gestion des listes

Gestion des groupes

Administrateur

Acher toutes les groupes ;

Ajouter ou supprimer dune ou de plusieurs groupes.

Tableau 2.5: Besoins fonctionnels de Gestion des groupes

Gestion des ches

Administrateur

Acher toutes les ches ;

Ajouter ou supprimer dune ou de plusieurs ches ;

-Importer une nouvelle che en format CSV ;

-Exporter une che en format PDF.

Tableau 2.6: Besoins fonctionnels de Gestion des ches

Chapitre 2. Analyse et Sp cication des Besoins

Gestion des utilisateurs

Administrateur

cr er , modier , supprimer des agents ;

Aecter des agents di 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 ches.

Tableau 2.8: Besoins fonctionnels de Gestion des statistiques

2.2.3 Diagrammes de cas dutilisation

Le diagramme de cas dutilisation sert d nir le syst me, les acteurs, les cas dutilisations

et les liens entre acteurs et cas dutilisation. Un cas dutilisation est un moyen de repr senter les

di rents possibilit s dutiliser un syst me, il exprime toujours une suite dinteractions entre un

acteur et lapplication et d nit une fonctionnalit utilisable par un acteur.

La gure 2.1 repr sente le diagramme de cas dutilisation global de notre syst me.

Chapitre 2. Analyse et Sp cication des Besoins

Figure 2.1: Diagramme de cas dutilisation global

Chapitre 2. Analyse et Sp cication 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 sagit des besoins qui caract risent le syst me savoir :

Rapidit : Il est clairement tabli que la vitesse dachage inuence fortement lecacit

de lapplication. Cest pour cette raison quil faut d velopper une application fournissant des

r sultats ecaces et coh rents et dans un temps n gligeable suite aux requ tes issues des

utilisateurs ;

User-Exp rience (UX) : Lapplication devra tre plus utilisable, d sirable et navigables

permettant successivement la facilit demploi avec des interfaces consistantes ;

S curit : Laspect s curit est important dans notre syst me. En eet, nous devons restreindre

lacc s aux di rents espaces utilisateurs toute personne non autoris e, qui pourrait acc der

des informations condentielles ;

Fiabilit : Les r sultats apport s par lapplication doivent tre ables et re tent eectivement

l tat de la base au moment de son interrogation, cest- -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 lutilisateur sy trouve facilement et ceci

en respectant la charte graphique de Xarix.

2.4 M thodo...

Conception et développement d’un CRM Vicidial

Conception et développement d’un CRM Vicidial