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é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 1 Etude Préalable 2 1.1 Cadre général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3.1 Analyse des applications similaires . . . . . . . . . . . . . . . . . . . . . . . . 5 2 Analyse et Spécification des Besoins 8 2.1 Méthodologie de modélisation adopté . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Analyse des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.3 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4 Méthodologie de gestion de projet adoptée . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.1 Pourquoi SCRUM ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.5 Gestion du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.5.1 Equipe et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.5.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5.3 Planification des releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3 Conception 20 3.1 Conception graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.1 Synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.2 Charte graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Conception technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 iii 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 28 4.1 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2 Sprint 1 : Gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2.1 Objectifs du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2.2 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.3 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2.4 Interfaces réalisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.3 Sprint 2 : Gestion des centres appels,Gestion des groupes . . . . . . . . . . . . . . . 36 4.3.1 Objectifs du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.2 Backlog du sprint 2 (Gestion des centres appels) . . . . . . . . . . . . . . . . 36 4.3.3 Backlog du sprint 2 (Gestion des groupes) . . . . . . . . . . . . . . . . . . . . 37 4.3.4 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3.5 Interfaces réalisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.4 Sprint 3 : Gestion des campagnes et des statuts . . . . . . . . . . . . . . . . . . . . . 42 4.4.1 Objectifs du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.4.2 Backlog du sprint 3 (Gestion des campagnes) . . . . . . . . . . . . . . . . . . 42 4.4.3 Backlog du sprint 3 (Gestion des statuts) . . . . . . . . . . . . . . . . . . . . 43 4.4.4 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.4.5 Interfaces réalisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.2 Sprint 4 :Gestion des Listes et des Fiches . . . . . . . . . . . . . . . . . . . . . . . . 51 5.2.1 Objectifs du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.2.2 Backlog du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.2.3 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.2.4 Interfaces réalisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.3 Sprint 5 : Gestion des Statistiques et des des téléphones . . . . . . . . . . . . . . . . 57 iv 5.3.1 Objectifs du sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.3.2 Backlog du sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.3.3 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.3.4 Interfaces réalisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6 Phase de clôture 65 6.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.1.2 Logiciels utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.1.3 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.1.4 Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.1.5 Pourquoi Symfony ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Conclusion générale 70 Bibliographie 71 Webographie 72 Annexes 73 Annexe A. Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Annexe B. Règles de gestion et Dictionnaire de données . . . . . . . . . . . . . . . . . . . 76 7.0.1 Règles de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Annexe C. Description textuelle des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 77 7.0.2 Sprint 1 : Gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.0.3 Sprint 3 : Gestion des groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.0.4 Sprint 3 : Gestion des campagnes . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.0.5 Sprint 4 : Gestion des listes et fiches . . . . . . . . . . . . . . . . . . . . . . . 80 7.0.6 Sprint 5 : Gestion des téléphones et statistiques . . . . . . . . . . . . . . . . . 82 v Table des figures 1.1 Logo XPERIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Interface d’accueil de l’application Bitrix24 . . . . . . . . . . . . . . . . . . . . 6 2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2 Méthodologie SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3 Plan des releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1 Logo CRM Vicidial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Affichage responsive de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3 Structure de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.5 Diagramme de classe global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.1 Diagramme de cas d’utilisation du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . 31 4.2 Diagrammes de séquence système « S’authentifier » . . . . . . . . . . . . . . . . . . . 32 4.3 Interface authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4 Interface "Message d’erreur d’authentification" . . . . . . . . . . . . . . . . . . . . . 33 4.5 Interface liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.6 Interface Ajouter utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.7 Interface modification utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.8 Diagramme de cas d’utilisation du Sprint 2 (Gestion centre d’appel ) . . . . . . . . . 38 4.9 Diagramme de cas d’utilisation du Sprint 2 (Gestion des groupes) . . . . . . . . . . . 39 4.10 Interface Liste centre d’appel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.11 Interface Ajout d’un centre d’appel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.12 Interface Liste groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.13 Interface Ajout d’un groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.14 Diagramme de cas d’utilisation du Sprint 3 (Gestion des statuts) . . . . . . . . . . . 44 4.15 Diagramme de cas d’utilisation du Sprint 3 (Gestion des statuts) . . . . . . . . . . . 45 4.16 Interface Menu campagnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.17 Interface ajouter nouvelle campagne . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 vi 4.18 Interface ajouter nouvelle statut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.19 Interface Menu statuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.1 Diagramme de cas d’utilisation du Sprint 4 (Gestion des listes) . . . . . . . . . . . . 53 5.2 Diagramme de cas d’utilisation du Sprint 4 (Gestion des fiches) . . . . . . . . . . . . 53 5.3 Interface les listes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.4 Interface Ajouter une liste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.5 Interface Liste des fiches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.6 Importer fiche CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.7 Exemple fiche CSV exporté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.8 Diagramme de cas d’utilisation du Sprint 5(Gestion statistiques) . . . . . . . . . . . 58 5.9 Diagramme de cas d’utilisation du Sprint 5(Gestion téléphones) . . . . . . . . . . . . 59 5.10 Diagramme de séquence système « Consulter les statistiques » . . . . . . . . . . . . . 60 5.11 Interface Ajouter téléphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.12 Interface Tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.13 Interface Statistiques des campagnes . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.14 Interface Nombre de fiches pour chaque statut . . . . . . . . . . . . . . . . . . . . . . 63 5.15 Interface Nombre de fiches appelées pour chaque statut . . . . . . . . . . . . . . . . . 63 5.16 Interface Nombre de fiches non appelées pour chaque statut . . . . . . . . . . . . . . 64 6.1 Architecture de Symfony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 vii Liste des tableaux 2.1 Besoins fonctionnels de « Gestion des comptes et des rôles» . . . . . . . . . . . . . . 10 2.2 Besoins fonctionnels de « Gestion des campagnes» . . . . . . . . . . . . . . . . . . . 11 2.3 Besoins fonctionnels de « Gestion des statuts» . . . . . . . . . . . . . . . . . . . . . . 12 2.4 Besoins fonctionnels de « Gestion des listes» . . . . . . . . . . . . . . . . . . . . . . . 12 2.5 Besoins fonctionnels de « Gestion des groupes» . . . . . . . . . . . . . . . . . . . . . 12 2.6 Besoins fonctionnels de « Gestion des fiches» . . . . . . . . . . . . . . . . . . . . . . 12 2.7 Besoins fonctionnels de « Gestion des utilisateurs» . . . . . . . . . . . . . . . . . . . 13 2.8 Besoins fonctionnels de « Gestion des statistiques» . . . . . . . . . . . . . . . . . . . 13 2.9 Rôles SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.10 Backlog du produit géneral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1 Description des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1 Planification des sprints de la première release . . . . . . . . . . . . . . . . . . . . . . 29 4.2 Backlog du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3 Backlog du deuxième sprint (Gestion des centres d’appels) . . . . . . . . . . . . . . . 36 4.4 Backlog du deuxième sprint (Gestion des groupes) . . . . . . . . . . . . . . . . . . . 37 4.5 Backlog du troisième sprint (Gestion des camapgnes) . . . . . . . . . . . . . . . . . . 42 4.6 Backlog du troisième sprint (Gestion des statuts) . . . . . . . . . . . . . . . . . . . . 43 5.1 Planification des sprints de la deuxième release . . . . . . . . . . . . . . . . . . . . . 51 5.2 Backlog du quatrième sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.3 Backlog du cinquième sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.1 Caractéristiques de l’ordinateur utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.2 Logiciels utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.3 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.4 Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.1 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.2 Description textuelle du cas d’utilisation « S’authentifier » . . . . . . . . . . . . . . . 77 viii 7.3 Description textuelle du cas d’utilisation « Ajouter groupe» . . . . . . . . . . . . . . 78 7.4 Description textuelle du cas d’utilisation « Ajouter nouvelle campagne» . . . . . . . 79 7.5 Description textuelle du cas d’utilisation « Ajouter une statut » . . . . . . . . . . . . 79 7.6 Description textuelle du cas d’utilisation « Ajouter une nouvelle liste » . . . . . . . . 80 7.7 Description textuelle du cas d’utilisation « Ajouter une fiche » . . . . . . . . . . . . . 81 7.8 Description textuelle du cas d’utilisation « Ajouter numéro de téléphone » . . . . . . 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 Plan Chapitre 1 Etude Préalable 1 Cadre général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 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. 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 Chapitre 2 Analyse et Spécification des Besoins Plan 1 Méthodologie de modélisation adopté . . . . . . . . . . . . . . . . . . . . 9 2 Analyse des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 9 3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4 Méthodologie de gestion de projet adoptée . . . . . . . . . . . . . . . . . 15 5 Gestion du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . 17 Chapitre 2. Analyse et Spécifcation 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. 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. 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écifcation 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ér...