Ministère de l’Enseignement Supérieur

de la Recherche Scientifique
  
Université de Carthage
  
Faculté des Sciences Economiques et de Gestion de Nabeul

Rapport de Stage
En vue de l’obtention du diplôme de Licence en
« Informatique de Gestion »
Spécialité
« Business Intelligence »

Titre :

Conception et développement
d’une solution BI intégrant des outils IA
pour l’analyse et le suivi d’un CRM

Réalisé au sein de : DIESE

Elaboré par : HADDAD Siwar

Encadré par :
Encadrante universitaire Mme. BOUAFIF Fadoua
Encadrant professionnel M. HADDAD Cherif

Année universitaire : 2022/ 2023

 Dédicaces
Je dédie ce travail

À la plus belle personne, celle qui incarne la quintessence de la tendresse,

de la patience et de la générosité,

À toi, ma mère, qui, avec ta présence bienveillante, tu as été mon refuge

et avec ton amour infini tu as été ma douce étreinte qui a enveloppé chaque étape

de ma vie. Je t'exprime aujourd'hui ma gratitude éternelle.

À toi, mon père, dont la présence solide et rassurante a marqué chaque

instant de mon existence. Tu as été mon guide, mon mentor et mon protecteur. Ta détermination et

ton dévouement ont tracé la voie de ma persévérance. Je te suis profondément reconnaissante pour

tout ce que tu as fait pour moi.

À vous, ma chère petite sœur et mon cher petit frère, vous qui êtes mes

précieux compagnons dans la vie. Un grand merci.

Et à mes chers amis, à ceux qui ont été présents à mes côtés, partageant

mes hauts et mes bas. Vos encouragements et votre soutien m’ont été d’une vraie

bénédiction.

Je dédie mon travail, ainsi que mes mots, imprégnés d'émotion et de

reconnaissance, à vous tous. Que cette dédicace soit le reflet de l'amour profond que je vous porte,

et une expression sincère de ma gratitude pour votre présence

précieuse dans ma vie.

 Remerciements
Au seuil de ce travail, mes mots se parent de gratitude envers tous ceux qui

ont œuvré, avec bienveillance et dévouement, à sa réalisation.

Je souhaite, tout d’abord, exprimer ma reconnaissance sincère à l’égard de Madame BOUAFIF

Fadoua, mon encadrante académique, pour ses conseils avisés et son assistance qui m’ont insufflé

une direction juste à mon travail.

Je tiens également à exprimer ma gratitude envers l'organisme d'accueil pour

m'avoir accueillie et offert une expérience enrichissante. Leur confiance en mes compétences

et les opportunités d'apprentissage que j'ai eues au sein de leur structure ont grandement

contribué à ma formation et à mon développement professionnel.

Je ne manquerai pas cette occasion pour adresser mes remerciements

les plus sincères à tous mes enseignants qui ont veillé à cultiver mon esprit de curiosité

et d'apprentissage, guidant mes pas sur le chemin de la connaissance et de l'excellence,

ainsi qu’aux membres du jury qui, par leur regard avisé

et leur expertise, ont évalué mon travail.

Et enfin, en cet instant solennel, ma gratitude s'étend à toutes les âmes qui, de

Près ou de loin, ont contribué à la réalisation de ce travail. Vos soutiens indéfectibles, vos

encouragements sincères et vos précieux conseils ont donné vie à ce projet.

Table des matières

Introduction générale 1
1 Cadre Général Du Projet 3
1.1 Présentation de l'organisme d'accueil . . . . . . . . . . . . . . . . . 4

1.1.1 Informations générales . . . . . . . . . . . . . . . . . . . . . 4

1.1.2 Structure et organisation . . . . . . . . . . . . . . . . . . . . 4

1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.2 Etude de l'exitant et description de l'environnement actuel . 5

1.2.2.1 GSoft . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.2.2 GSoft CRM . . . . . . . . . . . . . . . . . . . . . . 6

1.2.3 Critique de l'existant . . . . . . . . . . . . . . . . . . . . . . 6

1.2.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Spécication des besoins . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . 7

1.3.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . 8

1.4 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.1 Présentation de la méthodologie . . . . . . . . . . . . . . . . 8

1.4.2 Planication agile du projet . . . . . . . . . . . . . . . . . . 10

1.4.2.1 Présentation des Sprints . . . . . . . . . . . . . . . 10

1.4.2.2 Product Backlog . . . . . . . . . . . . . . . . . . . 10

2 Concepts Théoriques Et État De L'art 12

2.1 Gestion de la Relation Client . . . . . . . . . . . . . . . . . . . . . 13

2.2 Informatique Décisionnelle . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Dénition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.2 Architecture d'un système décisionnel . . . . . . . . . . . . . 14

2.2.2.1 Sources de données . . . . . . . . . . . . . . . . . . 15

2.2.2.2 Processus ETL . . . . . . . . . . . . . . . . . . . . 15

i
Table des matières

2.2.2.3 L'entrepôt de données (data warehouse) . . . . . . 15

2.2.2.4 Les magasins de données (data marts) . . . . . . . 16

2.2.2.5 Outils de reporting . . . . . . . . . . . . . . . . . . 18

2.2.2.6 Outils OLAP . . . . . . . . . . . . . . . . . . . . . 18

2.2.2.7 Tableaux de bords . . . . . . . . . . . . . . . . . . 18

2.2.2.8 Outils d'exploration de données (Data mining) . . 18

2.3 Intelligence Articielle . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Apprentissage Automatique . . . . . . . . . . . . . . . . . . . . . . 19

3 Mise en Place de L'Infrastructure de Données 20

3.1 Sprint 1 : Conception de l'architecture de l'Entrepôt de données et

développement des processus ETL . . . . . . . . . . . . . . . . . . . 21

3.1.1 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.2 Outils Utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.2.1 Sql Server Management Studio 19 . . . . . . . . . . 22

3.1.2.2 Sql Server Integration Services 2022 . . . . . . . . 22

3.1.3 Conception de l'architecture de l'entrepôt de données . . . . 23

3.1.3.1 Spécication des objectifs de l'entrepôt de données 23

3.1.3.2 Choix de l'approche de modélisation . . . . . . . . 23

3.1.3.3 Identication des tables de dimensions . . . . . . . 23

3.1.3.4 Identication des tables de faits . . . . . . . . . . . 27

3.1.3.5 Conception du schéma en ocon de neige de l'en-

trepôt des données . . . . . . . . . . . . . . . . . . 29

3.1.4 Description des sources de données . . . . . . . . . . . . . . 31

3.1.5 Développement des processus ETL . . . . . . . . . . . . . . 32

3.1.5.1 Staging_Package . . . . . . . . . . . . . . . . . . . 32

3.1.5.2 DataWarehousing_Package . . . . . . . . . . . . . 34

3.1.5.3 Planication des processus ETL . . . . . . . . . . . 35

3.2 Sprint 2 : Analyse et Création du Modèle Tabulaire . . . . . . . . . 35

3.2.1 Sprint BackLog . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.2 Outils Utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.3 Conception du modèle tabulaire . . . . . . . . . . . . . . . . 36

3.2.3.1 Importation des données . . . . . . . . . . . . . . . 36

3.2.3.2 Dénition des relations . . . . . . . . . . . . . . . . 37

3.2.3.3 Dénition des hiérarchies . . . . . . . . . . . . . . 37

3.2.3.4 Dénition des perspectives . . . . . . . . . . . . . . 37

3.2.4 Développement des mesures . . . . . . . . . . . . . . . . . . 38

3.2.5 Déploiment et planication du modèle tabulaire . . . . . . . 39

ii
Table des matières

3.2.5.1 Déploiment du modèle tabulaire . . . . . . . . . . . 39

3.2.5.2 Planication de l'actualisation du modèle . . . . . 39

4 Exploitation des Données 40

4.1 Sprint 3 : Création de rapports et de tableaux de bord . . . . . . . 41

4.1.1 Sprint BackLog . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1.2 Outils Utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1.3 Obtention des données . . . . . . . . . . . . . . . . . . . . . 42

4.1.4 Création du tableau de bord `Ore' . . . . . . . . . . . . . . 42

4.1.4.1 Présentation des KPIs . . . . . . . . . . . . . . . . 42

4.1.4.2 Présentation du tableau de bord . . . . . . . . . . 43

4.1.5 Création du tableau de bord `Prospection' . . . . . . . . . . 43

4.1.5.1 Présentation des KPIs . . . . . . . . . . . . . . . . 43

4.1.5.2 Présentation du tableau de bord . . . . . . . . . . 44

4.1.6 Création du tableau de bord `Fidélisation Et Communication' 45

4.1.6.1 Présentation des KPIs . . . . . . . . . . . . . . . . 45

4.1.6.2 Présentation du tableau de bord . . . . . . . . . . 45

4.2 Sprint 4 : Analyse prédictive et machine learning . . . . . . . . . . 46

4.2.1 Sprint BackLog . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.2 Outils Utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2.3 Spécication des objectifs de l'utilisation de L'apprentissage

automatique . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2.4 Choix des algorithmes . . . . . . . . . . . . . . . . . . . . . 47

4.2.4.1 La régression linéaire . . . . . . . . . . . . . . . . . 48

4.2.4.2 L'arbre de décision . . . . . . . . . . . . . . . . . . 48

4.2.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.6 Visualisation des prédictions . . . . . . . . . . . . . . . . . . 49

4.3 Sprint 5 : Création de site web de consultation . . . . . . . . . . . . 49

4.3.1 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.2 Réalisation du diagramme de cas d'utilisation . . . . . . . . 50

4.3.3 Publication des rapports réalisés . . . . . . . . . . . . . . . . 50

4.3.4 Développement et présentation des interfaces des pages . . . 50

4.3.4.1 Page de connexion . . . . . . . . . . . . . . . . . . 51

4.3.4.2 Page de présentation des tableaux de bord . . . . . 51

4.3.4.3 Page de présentation du tableau de bord de pré-

diction . . . . . . . . . . . . . . . . . . . . . . . . . 52

Conclusion générale 53

iii
Table des matières

Bibliographie 54
Annexe 56

iv
Table des gures

1.1 logo de DIESE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 organigramme de la société DIESE . . . . . . . . . . . . . . . . . . 5

1.3 logo de GSoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 logo de GSoft CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5 Approche itérative et agile (Scrum) . . . . . . . . . . . . . . . . . . 9

2.1 Customer Relationship Management(CRM) . . . . . . . . . . . . . 13

2.2 Architecture d'un système décisionnel . . . . . . . . . . . . . . . . . 14

2.3 Schéma en étoile et Schéma en ocon de neige . . . . . . . . . . . . 16

2.4 Approche d'Inmon . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5 Approche de Kimball . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Logo de Sql Server Management Studio(SSMS) . . . . . . . . . . . 22

3.2 Logo de Sql Server Integration Services(SSIS) . . . . . . . . . . . . 22

3.3 Conception de l'entrepôt des données . . . . . . . . . . . . . . . . . 29

3.4 Conception du DataMart `Ore' . . . . . . . . . . . . . . . . . . . . 30

3.5 Conception du DataMart `Prospection' . . . . . . . . . . . . . . . . 30

3.6 Conception du DataMart `FidelisationEtCommunication' . . . . . . 31

3.7 Les processus ETL pour alimentation de l'entrepôt de données . . . 32

3.8 Staging_Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.9 Exemple d'une tâche de chargement vers la zone de staging . . . . . 33

3.10 DataWarehousing_Package . . . . . . . . . . . . . . . . . . . . . . 34

3.11 Exemple d'alimentation d'une table des faits . . . . . . . . . . . . . 35

3.12 Logo de Sql Server Analysis Services(SSAS) . . . . . . . . . . . . . 36

3.13 Liste des relations existantes entre les tables . . . . . . . . . . . . . 37

3.14 Calcul de la mesure nombre total des ores acceptées avec DAX . . 38

4.1 Logo de Power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Tableau de bord `Ore' . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3 Tableau de bord `Prospection' . . . . . . . . . . . . . . . . . . . . . 44

v
Table des gures

4.4 Tableau de bord `Fidélisation Et Communication' . . . . . . . . . . 46

4.5 Logo de Jupyter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.6 Tableau de bord de prédiction . . . . . . . . . . . . . . . . . . . . . 49

4.7 Diagramme de cas d'utilisation de la réalisation du site web . . . . 50

4.8 Page de connexion du site . . . . . . . . . . . . . . . . . . . . . . . 51

4.9 Page de consultation des tableaux de bord . . . . . . . . . . . . . . 51

4.10 Page de consultation du tableau de bord de prédiction . . . . . . . 52

11 Arbre de décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

vi
Liste des tableaux

1.1 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.1 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Comparaison des approches d'Inmon et de Kimball [13] . . . . . . . 18

3.1 Sprint Backlog du premier Sprint . . . . . . . . . . . . . . . . . . . 21

3.2 Attributs de la dimension `Dim_Date' . . . . . . . . . . . . . . . . 24

3.3 Attributs de la dimension `Dim_Client' . . . . . . . . . . . . . . . . 24

3.4 Attributs de la dimension `Dim_Contact' . . . . . . . . . . . . . . . 24

3.5 Attributs de la dimension `Dim_Fonction' . . . . . . . . . . . . . . 25

3.6 Attributs de la dimension `Dim_Secteur' . . . . . . . . . . . . . . . 25

3.7 Attributs de la dimension `Dim_Ville' . . . . . . . . . . . . . . . . 25

3.8 Attributs de la dimension `Dim_Utilisateur' . . . . . . . . . . . . . 26

3.9 Attributs de la dimension `Dim_ObjetOre' . . . . . . . . . . . . . 26

3.10 Attributs de la dimension `Dim_EtatOre' . . . . . . . . . . . . . . 26

3.11 Attributs de la dimension `Dim_ObjetAction' . . . . . . . . . . . . 27

3.12 Attributs de la dimension `Dim_ResultatAction' . . . . . . . . . . . 27

3.13 Attributs de la dimension `Dim_CanalCommunication' . . . . . . . 27

3.14 Attributs de l a table de faits `Fact_Ore' . . . . . . . . . . . . . . 28

3.15 Attributs de la table de faits `Fact_Prospection' . . . . . . . . . . . 28

3.16 Attributs de la table de faits `Fact_FidelisationEtCommunication' . 28

3.16 Attributs de la table de faits `Fact_FidelisationEtCommunication' . 29

3.17 Sprint Backlog du deuxième Sprint . . . . . . . . . . . . . . . . . . 36

4.1 Sprint Backlog du troisième Sprint . . . . . . . . . . . . . . . . . . 41

4.2 Liste des KPIs du tableau de bord `Ore' . . . . . . . . . . . . . . . 42

4.2 Liste des KPIs du tableau de bord `Ore' . . . . . . . . . . . . . . . 43

4.3 Liste des KPIs du tableau de bord `Prospection' . . . . . . . . . . . 44

4.4 Liste des KPIs du tableau de bord `Fidélisation Et Communication' 45

4.5 Sprint Backlog du quatrième Sprint . . . . . . . . . . . . . . . . . . 46

4.6 Sprint Backlog du cinquième Sprint . . . . . . . . . . . . . . . . . . 50

vii
Liste des sigles et acronymes

BI Business Intelligence

CRM Customer Relationship Management

DAX Data Analysis Expressions

DWH Data Warehouse

ETL Extraction Transformtion Load

IA Intelligence Articielle

KPI Key Performance Iindicator

ML Machine Learning

SGBD Système de Gestion des Bases de Données

viii
Introduction générale

Nous vivons dans une ère caractérisée par une concurrence acharnée et des attentes

grandissantes de la part des clients. Cette réalité s'inscrit dans un contexte où les avan-

cées technologiques ne cessent de se développer, orant ainsi de nouvelles opportunités

mais aussi de nouveaux dés aux entreprises. Dans ce paysage commercial en perpétuelle

évolution, la gestion ecace des relations avec les clients est devenue un élément essentiel

pour garantir la croissance et la pérennité des entreprises.

C'est là que les systèmes de gestion de la relation client (CRM) se sont imposés comme des

outils indispensables pour les entreprises souhaitant gérer ecacement leurs interactions

avec les clients. En eet, ces systèmes permettent de centraliser les informations clients,

de suivre de près les interactions et les transactions, ainsi que de mettre en place des

stratégies de prospection et de délisation.

Cependant, face à la croissance exponentielle des données disponibles, il est devenu impé-

ratif de tirer pleinement parti de ces informations an de prendre des décisions éclairées

et d'implémenter des actions ecaces.

C'est dans ce contexte que la Business Intelligence (BI) et l'intelligence articielle (IA)

entrent en jeu. La BI permet de collecter, d'organiser, d'analyser et de visualiser de ma-

nière ecace les données commerciales, orant ainsi une vue globale des activités commer-

ciales et des performances. De son côté, l'IA propose des capacités avancées d'apprentis-

sage automatique et de traitement, permettant l'automatisation des tâches, la prédiction

des comportements clients et une meilleure prise de décisions.

Conscient de l'importance de cette évolution, notre organisme d'accueil s'est engagé

dans un projet visant à améliorer son logiciel CRM en intégrant la Business Intelligence

et l'intelligence articielle.

Dans ce cadre, notre projet de n d'études consistera à conçevoir et développer une

solution BI qui fait recours aux outils IA pour suivre et analyser les données stockées du

CRM.

Le présent rapport est structuré en quatre chapitres an de fournir une vision complète

de notre projet :

1
Introduction générale

 Le premier chapitre  Cadre général du projet  : présente le cadre général du

projet, notamment la présentation de l'oganisme d'accueil ainsi que celle du projet

en exposant la problématique, la solution, les besoins et la méthodologie utilisée.

 Le deuxième chapitre  Concepts théoriques et état de l'art  : examine l'état

de l'art et les concepts théoriques liés à la Business Intelligence, à l'intelligence

articielle et aux systèmes CRM, en mettant l'accent sur les techniques, les mé-

thodologies et les outils utilisés.

Les chapitres suivants détaillent les sprints réalisés dans le cadre du projet.

 Le troisième chapitre  Mise en place de l'infrastructure de données  : se

concentre sur les sprints 1 et 2, qui portent sur la conception de l'entrepôt de

données, les processus ETL et la création d'un modèle tabulaire.

 Le quatrième chapitre  Exploitation des données  : aborde les sprints 3, 4 et

5, qui se concentrent sur la visualisation des tableaux de bord, l'analyse prédictive

et le développement du site web de consultation.

Nous clôturons ce rapport avec une conclusion générale.

2
Chapitre 1
Cadre Général Du Projet

3
Chapitre 1. Cadre Général Du Projet

Introduction
Dans ce chapitre, nous allons présenter en premier lieu l'organisme d'accueil `DIESE'
au sein duquel s'est eectué notre stage de n d'études pour entamer par la suite un aperçu

de notre projet tout en détaillant l'existant, la critique de l'existant et la solution proposée.

Nous clôturons ce chapitre par la méthodologie de travail choisie pour la réalisation de ce

projet.

1.1 Présentation de l'organisme d'accueil

1.1.1 Informations générales
DIESE est une société tunisienne qui propose des solutions digitales et logicielles sur

mesure et dédiées dans le domaine des technologies de l'information(IT) tout en regrou-

pant toutes les expertises : design, Tech et conseil.

Elle accompagne ses clients an de les aider à révéler de nouvelles opportunités qui

s'adaptent aux évolutions du marché.

En tant que plateforme de solutions digitales complètes, DIESE aide ses clients à

augmenter leur capacité à travers un large spectre d'ores et services de haut niveau qui

comprennent :

 l'ingénierie logicielle : DIESE propose la solution logicielle GSoft(sera détaillée

dans la section suivante) pour gérer l'ensemble des processus de l'entreprise cliente

intégrant l'ensemble de ses fonctions.

 le développement web : DIESE crée des sites web vitrine, e-commerce ainsi que
des applications web métier uniques, entièrement administrables et sur-mesure.

 le marketing digital : DIESE accompagne ses clients pour concevoir et mettre

en place une stratégie de communication digitale performante et sur-mesure an

de tirer le meilleur parti de cette nouvelle tendance.

 le support et maintenance : DIESE ore des services d'assistance, prise en

charge et dépannage.

Figure 1.1  logo de DIESE

1.1.2 Structure et organisation

La structure de la société est présentée dans la gure suivante (gure 1.2) :

4
Chapitre 1. Cadre Général Du Projet

Figure 1.2  organigramme de la société DIESE

Au sommet de l'organigramme on trouve la direction générale au long avec l'assistance

chargées de la supervision des diérents départements. Juste en dessous, nous trouvons

trois sous-directions :

 Direction technique : responsable de la gestion des projets, du développement de

produits soit le développement web et le développement GSoft ainsi que du support

et de la maintenance des produits ou services oerts.

 Direction Admistrative et comptable : responsable de la gestion nancière, admi-

nistrative et juridique de l'entreprise.

 Direction Commerciale : responsable de toutes les activités liées aux ventes, au

Marketing et la gestion des relations avec les clients.

La réalisation du projet se déroule dans le département de développement GSOFT.

1.2 Présentation du projet

1.2.1 Contexte du projet
Le présent projet s'inscrit dans le cadre d'un stage de n d'études d'une durée de

quatre mois au sein de l'entreprise DIESE en vue d'obtention du diplôme de licence

d'informatique de gestion spécialité Business Intelligence.

1.2.2 Etude de l'exitant et description de l'environnement actuel

Comme spécié précedemment, DIESE fournit des services de mise en place de son

propre logiciel GSoft.

5
Chapitre 1. Cadre Général Du Projet

1.2.2.1 GSoft
Créé en 2003, GSoft permet de gérer l'ensemble des processus et fonctions d'une en-

treprise, qu'elle soit petite, moyenne ou grande, notamment la gestion des ressources

humaines, la gestion nancière et comptable, l'approvisionnement, le stock, la vente, la

distribution, la production, l'aide à la décision ainsi que la gestion des relations clients.

GSoft est un logiciel ouvert développé autour du système de gestion des bases de don-

nées(SGBD) Microsoft SQL Server et de l'outil Crystal Reports.

Figure 1.3  logo de GSoft

GSoft ore plusieurs produits, dont GSoft CRM.

1.2.2.2 GSoft CRM

Cette solution CRM(Customer Relationship Management), développée en interne par

DIESE, permet à ses utilisateurs de gérer leurs relations clients en organisant et en au-

tomatisant les communications ainsi que toutes les activités en relation directe avec leurs

clients (prospections, visites, missions, ventes, relances, délisations).

Figure 1.4  logo de GSoft CRM

Seulement que GSoft CRM n'intègre pas un système automatique d'analyse des don-

nées stockées. Et par la suite, pour extraire les informations nécessaires à la prise des

décisions, ses utilisateurs doivent consulter des tables de la base de données centralisée

du logiciel.

Ainsi, le projet portera sur l'amélioration de ce logiciel.

1.2.3 Critique de l'existant

Vu que la societé DIESE souhaite fournir à ses clients un moyen d'analyse et de prise de

décision, on peut bien cerner les suivantes limitations au niveau de la solution existante :

6
Chapitre 1. Cadre Général Du Projet

 Absence de fonctionnalités avancées d'analyse et de suivi de l'activité des clients.

 L'analyse des données des clients est basée sur des tables de données transaction-

nelles ce qui rend l'interprétation dicile sans une connaissance approfondie des

bases de données.

 Processus de prise de décision longs et peu ecaces.

 Les rapports fournis par le logiciel sont statiques et ne prennent pas en compte le

facteur temps.

 Absence de moyen automatisé pour surveiller les indicateurs clés de performance

(KPI).

 Absence d'un système de visualisation des données.

1.2.4 Solution proposée

L'objectif est d'améliorer la version existante pour garantir une meilleure prise de

décision.

De ce fait, la solution proposée consiste à concevoir et à développer un module de Business

Intelligence (BI) qui intègre des outils d'Intelligence Articielle (IA) dans le but d'analyser

et mieux suivre les données du CRM selon des indicateurs clés de performance pertinents.

L'intégration des outils d'IA est illustrée par la réalisation des analyses prédictives ainsi

que des analyses de classication.

Ce module BI sera ajouté à GSoft CRM et sera accessible par l'ensemble des clients de la

société qui utilise le logiciel.

1.3 Spécication des besoins

Les besoins fonctionnels et non fonctionnels sont les suivants :

1.3.1 Besoins fonctionnels

Cette solution doit être en mesure de :

 Collecter les données de façon automatisée à partir du CRM existant et d'autres

sources externes (ex : Base de données, chiers Excel, ERP, etc.).

 Traiter les données (Nettoyage, préparation et transformation).

 Stocker les données : préparation de l'entrepôt des données pour y charger les

données traitées.

 Analyser les données en utilisant des techniques d'apprentissage automatique pour

la prédiction et la détection des tendances.

7
Chapitre 1. Cadre Général Du Projet

 Visualiser les données pour une analyse plus approfondie en fournissant des ta-

bleaux de bord et des rapports interactifs qui présentent les résultats de l'analyse

de manière claire et concise.

 Optimiser les processus de prise de décision.

 Tenir compte de l'aspect sécurité

1.3.2 Besoins non fonctionnels

Les besoins non fonctionnels de la solution sont :

 Performance : La solution doit être capable de traiter des volumes importants de

données de manière ecace pour une analyse en temps réel.

 Scalabilité : La solution doit être capable de gérer des volumes de données en

croissance continue.

 Facilité d'utilisation : La solution devra être conviviale et facile à utiliser par les

décideurs de l'entreprise.

 Maintenance : La solution devra être facile à maintenir et à mettre à jour, en

réduisant les coûts et les temps d'arrêt.

 Pertinence des KPI choisis.

1.4 Méthodologie adoptée

1.4.1 Présentation de la méthodologie
Lors de la conception et de la réalisation de notre projet, nous avons opté pour la

méthodologie agile Scrum.

Cette méthode est parmi les méthodes agiles les plus utilisées. Elle garantit un pilotage

rapide du travail et est le cadre de référence que la société utilise lors de la réalisation de

ses projets.

Scrum est `un cadre de travail permettant de répondre à des problèmes complexes

et changeants, tout en livrant de manière productive et créative des produits de la plus

grande valeur possible'[1].

Chaque Scrum se déroule en itérations qui dure généralement entre deux et quatre se-

maines appelées Sprints et peuvent être regroupés en Release pour fournir des versions
incorporants plus de fonctionnalités.

Cette méthodologie dénit plusieurs évènements (parfois appelés cérémonies) qui se pro-

duisent à l'intérieur de chaque sprint :

 Planication du sprint ( Sprint Planning) où l'équipe de développement décide

les objectifs à atteindre durant le sprint.

8
Chapitre 1. Cadre Général Du Projet

 Réunions quotidiennes rapides ( Daily Scrums) pour faire le point sur l'avance-
ment et ajuster la direction si nécessaire.

 Activités de développement.

 Revue du sprint ( Sprint Review) pour examiner les résultats obtenus et discuter
les ajustements à apporter pour améliorer les prochains sprints.

 Rétrospective du sprint ( Sprint Retrospective) où elle rééchit sur les points

forts et les points faibles du sprint passé et envisage des améliorations pour les

sprints futurs.

Ces évènements sont représentés dans la gure suivante :

Figure 1.5  Approche itérative et agile (Scrum)

[2]

Il existe trois rôles clés dans Scrum : le propriétaire du produit(Product Owner) , le maître

Scrum(Scrum Master) et l'équipe Scrum :

 Product Owner : le responsable de ce que l'équipe construit, de la mise à jour

et de l'ordre de priorité du travail.

Dans notre cas, c'est le directeur général.

 Scrum Master : s'assure que le processus Scrum est suivi par l'équipe et conti-
nuellement à la recherche de l'amélioration, tout en résolvant les obstacles et les

autres problèmes bloquants qui surviennent pendant le sprint.

Dans notre cas, c'est le responsable du département de développement.

 Équipe Scrum : Ceux qui construisent réellement le produit[2].

Dans notre cas , c'est nous.

Nous trouvons aussi les artefacts Scrum(comme montrés dans la gure 1.5) qui sont des

éléments de travail ou des documents créés au cours du processus. Les principaux artefacts

de Scrum incluent :

 Product Backlog : Une liste ordonnée et émergente de ce qui est nécessaire pour
améliorer le produit. C'est l'unique source du travail entrepris par la Scrum Team.

 Sprint Backlog : Composé de l'Objectif de Sprint (le  pourquoi ), de l'ensemble

des éléments du Product Backlog choisis pour le Sprint (le  quoi ), ainsi que d'un

plan d'action pour la réalisation de l'Increment (le  comment )[1].

9
Chapitre 1. Cadre Général Du Projet

 Increment : Une version du produit qui est potentiellement utilisable, intégrant

toutes les fonctionnalités ajoutées ou améliorées durant le sprint.

La méthodologie Scrum est bien adaptée avec des sprints de deux semaines dans ce projet

puisque les objectifs et la limitation temporelle sont parfaitement délimités et connus.

1.4.2 Planication agile du projet

1.4.2.1 Présentation des Sprints
Puisque nous avons opté pour Scrum agile comme méthodologie de travail, notre projet

serait, alors, divisé en Sprints qui ont été identiés comme suit :

 Sprint 1 : Conception de l'architecture de l'entrepôt de données et développement

des processus ETL.

 Sprint 2 : Analyse et création du modèle tabulaire.

 Sprint 3 : Création de rapports et de tableaux de bord.
 Sprint 4 : Analyse prédictive et machine learning.
 Sprint 5 : Création de site web de Consultation.

1.4.2.2 Product Backlog

Ci-dessous (table 1.1), le product backlog prévisionnel du projet, dans lequel nous

avons spécié les fonctionnalités et les tâches à réaliser, organisées par ordre de priorité

en fonction de leur importance pour les utilisateurs naux :

Table 1.1  Product Backlog

ID User Story Priorité Sprint

1 En tant qu'développeur, je sou- 1 Sprint 1

haite pouvoir importer des don-

nées de CRM pour les analyser

dans la solution BI.

2 En tant qu'développeur, je sou- 2 Sprint 2

haite pouvoir eectuer un modèle

tabulaire pour une analyse plus

approfondies de mes données.

10
Chapitre 1. Cadre Général Du Projet

Table 1.1  Product Backlog

ID User Story Priorité Sprint

3 En tant qu'utilisateur, je veux 3 Sprint 3

pouvoir accéder à des graphiques

et des tableaux de bord person-

nalisables pour suivre les données

de mon CRM.

4 En tant qu'utilisateur, je souhaite 4 Sprint 4

pouvoir utiliser des algorithmes

de machine learning et d'IA pour

prédire les tendances futures de

mes données CRM.

5 En tant que utilisateur, je sou- 5 Sprint 5

haite consulter les tableaux de

bord sur le web.

6 En tant qu'utilisateur, je veux 6 Sprint 2

pouvoir automatiser les processus

ETL pour une mise à jour régu-

lière des données.

Conclusion
Durant ce chapitre, nous avons présenté le cadre général du projet. Nous avons com-

mencé par présenter l'organisme d'accueil. Ensuite, nous avons étudié l'existant, la so-

lution proposée pour cerner par la suite les besoins et nir avec la présentation de la

méthode adoptée ainsi que le plan de travail suivi, pour l'aboutissement aux objectifs

désirés.

Dans le chapitre suivant, nous allons dénir les notions théoriques en rapport avec le

projet.

11
Chapitre 2
Concepts Théoriques Et État De L'art

12
Chapitre 2. Concepts Théoriques Et État De L'art

Introduction
Dans ce chapitre, nous allons exposer l'état de l'art et la dénition des diérentes no-

tions liées au projet allant de `la gestion de la relation client' pour passer à `l'informatique

décisionnelle' et nir par `l'intelligence articielle'.

2.1 Gestion de la Relation Client

Gestion de la Relation Client ou Customer Relationship Management (CRM), terme

introduit au milieu des années 1990, est une stratégie d'entreprise qui permet de gérer

toutes les relations et interactions avec ses clients et prospects. Il s'agit d'une approche

centrée sur le client qui vise l'amélioration de l'expérience client et la délisation de la

clientèle tout en fournissant un service personnalisé, une communication ecace et une

gestion ecace des données clients.

Le CRM vise à créer de la valeur pour l'entreprise en créant de la valeur pour le client.

Celà revient au fait qu'il permet aux entreprises de collecter les données clients et les

utiliser pour mieux comprendre leurs besoins, leurs préférences et leurs comportements, et

les segmenter en groupes ayant des besoins similaires an d'orir une meilleure pertinence

et personnalisation des produits et des services.

En eet, les systèmes CRM aident les entreprises à créer de relations à long terme avec

ses clients, basées sur la conance, la loyauté et la satisfaction impliquant par la suite la

rationalisation des processus et l'augmentation de leur rentabilité[3, 4, 5].

Figure 2.1  Customer Relationship Management(CRM)

[6]

13
Chapitre 2. Concepts Théoriques Et État De L'art

2.2 Informatique Décisionnelle

2.2.1 Dénition
Informatique Décisionnelle ou Business Intelligence, souvent appelée BI, peut être dé-

nie comme le processus de collecte, d'intégration, analyse et visualisation des données an

de garantir une meilleure prise de décision. Les techniques et outils de BI comprennent

l'entreposage de données, l'exploration de données, l'analyse en ligne traitement (OLAP)

et autres.

Le terme est apparu pour la première fois en 1989 par Howard Dressner du groupe Gartner

en tant que terme générique pour décrire des concepts et des méthodes visant à améliorer

la prise de décision en entreprise en utilisant un support basé sur des faits[7].

L'objectif principal de la BI est de fournir aux décideurs des informations opportunes,

exactes et pertinentes qui peuvent les aider à prendre de meilleures décisions.

BI est particulièrement utile dans les environnements commerciaux complexes et dyna-

miques, où les décideurs besoin de naviguer dans de grandes quantités de données et de

réagir rapidement aux circonstances changeantes.

En d'autres termes, les systèmes BI mettent l'accent sur l'analyse de grands volumes de

données structurées (et dans une certaine mesure semi-structurées) pour fournir des in-

formations et des connaissances exploitables au bon moment, au bon endroit et sous la

bonne forme.

2.2.2 Architecture d'un système décisionnel

Figure 2.2  Architecture d'un système décisionnel

14
Chapitre 2. Concepts Théoriques Et État De L'art

1
L'architecture détaillée d'un système décisionnel (BI) , comme indiquée dans la gure

ci-dessus (gure 2.2), est composée des éléments suivants :

2.2.2.1 Sources de données

Ce sont les données brutes, stockées de manière distribuées, variées et hétérogènes. Les

sources de données peuvent inclure des systèmes de gestion de bases de données (SGBD),

des chiers plats, des applications de gestion de la relation client (CRM) et d'autres

systèmes de l'entreprise.

2.2.2.2 Processus ETL

Le processus Extraction, Transformation et Chargement (ETL) consiste à extraire

les données de diérentes sources, à les transformer (nettoyage, normalisation, ltrage,

agrégation..) en un format cohérent et à les charger périodiquement au sein de l'entropôt

des données.

L'ETL est essentiel pour garantir que les données soient propres, organisées et prêtes à

l'emploi pour l'analyse et la prise de décision[8].

2.2.2.3 L'entrepôt de données (data warehouse)

Il s'agit d'une collection de données orientée sujet, intégrée, non volatile et historisée,

qui supporte les processus de prise de décision de l'entreprise.

Il est conçu pour stocker les données transformées et normalisées de manière à ce qu'elles

puissent être facilement accessibles et utilisées pour la génération de rapports, l'analyse

et la création des tableaux de bord[8, 9].

Les données sont généralement organisées en deux types de tables : dimensions et faits.

Tables de faits (Fact Tables) : contiennent les mesures numériques et quantitatives,

les indicateurs clés de performance (KPI) et les données transactionnelles agrégées. Ces

mesures sont souvent les résultats de calculs ou d'agrégations eectués sur des données

brutes[10].

Les tables de faits sont généralement de grande taille et sont liées aux tables de dimensions

par des clés étrangères.

Tables de dimensions (Dimension Tables) : contiennent des informations détaillées

qui décrivent les données de la table de faits. dans un contexte plus large et d'aider à

l'analyse des données en fournissant des points de référence[10].

Les tables de dimensions sont généralement plus petites que les tables de faits.

1. Un ensemble de composants logiciels et matériels qui permettent la collecte, la gestion, l'analyse et

la présentation des données an que les utilisateurs puissent prendre des décisions bien rééchies.

15
Chapitre 2. Concepts Théoriques Et État De L'art

Pour représenter ces tables dans les entrepôts de données, le plus courant est d'utiliser

les deux modèles de conception : schéma en étoile (Star schema) ou schéma en ocon de

neige (Snowake schema).

Dans un schéma en étoile, la table de faits est centrale et entourée de tables de dimensions.

Le schéma en ocon de neige est une variante du schéma en étoile, dans lequel les tables

de dimensions sont normalisées : les attributs redondants sont supprimés et placés dans

des tables séparées. [10]

Figure 2.3  Schéma en étoile et Schéma en ocon de neige

2.2.2.4 Les magasins de données (data marts)

Ce sont des extraits de l'entrepôt de données centrés sur un seul sujet ou fonction.

Les données sont organisées de manière adéquate pour permettre des analyses rapides à

des ns de prise de décision et améliorer le temps de réponse des utilisateurs grâce au

catalogage des données spéciques[11].

Il est à noter que pour concevoir et construire un entrepôt de données, les deux approches

les plus couramment utilisées sont l'approche de Kimball et l'approche d'Inmon.

L'approche d'Inmon :
L'approche d'Inmon met l'accent sur la construction d'un entrepôt de données cen-

tralisé et intégré qui sert de source unique de vérité pour l'ensemble de l'organisation.

Elle repose sur la modélisation en 3NF (troisième forme normale) et la normalisation des

données, permettant ainsi une meilleure intégrité et cohérence des informations.

L'approche d'Inmon vise à capturer les données opérationnelles de l'ensemble de l'en-

treprise, à les transformer en structures logiques et à les consolider dans l'entrepôt de

données. Cela facilite l'analyse et le reporting tout en garantissant la cohérence et la

qualité des données[12].

16
Chapitre 2. Concepts Théoriques Et État De L'art

Figure 2.4  Approche d'Inmon

[13]

L'approche de Kimball
L'approche de Kimball, également connue sous le nom de modélisation dimensionnelle,

est une méthodologie de conception d'entrepôts de données axée sur les besoins métier et

la simplicité. Elle se concentre sur la création de modèles de données dimensionnels qui

facilitent l'analyse et la compréhension des données.

L'approche de Kimball met l'accent sur l'identication des faits et des dimensions clés,

la structuration des données en schémas en étoile ou en ocons, et la création d'un en-

vironnement de reporting et d'analyse performant. Elle favorise également l'itération et

l'agilité dans le processus de conception, permettant aux organisations de construire pro-

gressivement leur datawarehouse en fonction des besoins évolutifs[10].

Figure 2.5  Approche de Kimball

[13]

Le tableau suivant (table 2.1) montre une comparative entre les deux approches de concep-

17
Chapitre 2. Concepts Théoriques Et État De L'art

tion d'entrepôt de données :

Table 2.1  Comparaison des approches d'Inmon et de Kimball [13]

Critère Approche d'Inmon Approche de Kimball

Type d'approche Approche descendante Approche ascendante

Intégration de se concentre sur les domaines à se concentre sur les domaines

données l'échelle de l'entreprise. d'activité individuels

Temps de complexe et prend plus de temps. ecace et prend moins de temps.

construction

Entretien l'entretien est facile. l'entretien est dicile.

Modèle de don- Les données sont dans un modèle Les données sont dans un modèle

nées normalisé dénormalisé.

2.2.2.5 Outils de reporting

Ces outils permettent aux utilisateurs de générer des rapports à partir des données

stockées dans l'entrepôt de données. Les rapports peuvent être générés sous diérents

formats tels que PDF, Excel, HTML, etc.

2.2.2.6 Outils OLAP

Les outils de traitement analytique en ligne (OLAP) sont des outils permettant aux

utilisateurs d'analyser facilement les données stockées dans l'entrepôt de données en créant

des cubes multidimensionnels.

2.2.2.7 Tableaux de bords

Ce sont des outils qui fournissent une vue synthétique des données à travers des gra-

phiques, des diagrammes et des indicateurs de performance clés (KPI). Ils permettent de

visualiser les tendances, les écarts et les points d'alerte pour faciliter la prise de décision.

2.2.2.8 Outils d'exploration de données (Data mining)

Ces outils permettent d'explorer les données pour découvrir des modèles et des ten-

dances qui ne sont pas évidents à première vue.

2.3 Intelligence Articielle

L'intelligence articielle est un domaine vaste et évolutif qui englobe de nombreuses

approches, techniques et applications diérentes.

Cette notion a vu le jour dans les années 1950 grâce au mathématicien Alan Turing dans

18
Chapitre 2. Concepts Théoriques Et État De L'art

son livre `Computing Machinery and Intelligence' où il a soulèvé la question d'apporter

aux machines une forme d'intelligence[14].

Globalement, l'IA peut être dénie comme la simulation ou l'imitation de l'intelligence

humaine dans des machines programmées. Son but est de permettre à des ordinateurs de

penser et d'agir comme des êtres humains[14].

La dénition précise de l'IA, cependant, peut changer selon le contexte et la perspective

de la personne ou de l'organisation qui utilise le terme. Certaines dénitions peuvent

mettre l'accent sur la capacité des systèmes d'IA à eectuer des tâches spéciques, tandis

que d'autres peuvent se concentrer sur leur capacité à apprendre et à s'adapter au l du

temps.

Parmi les branches de l'IA, on trouve l'apprentissage automatique ou Machine Learning

(ML).

2.4 Apprentissage Automatique

L'apprentissage automatique est le processus de trouver des modèles cachés dans les

données.

Considéré comme un sous-ensemble de l'IA, l'apprentissage automatique (Machine lear-

ning en anglais (ML)) expose l'apprentissage expérientiel associé à l'intelligence hu-

maine, tout en ayant la capacité d'apprendre et de s'améliorer grâce à l'utilisation d'algo-

rithmes de calcul(ou modèles). Ces algorithmes utilisent de grands ensembles d'entrées et

de sorties de données(données étiquetées) ou de données non étiquetées pour apprendre

ecacement à la machine et l'entraîner à faire des recommandations ou des décisions au-

tonomes.

Lorsque l'algorithme est susamment répété et modié, la machine devient capable de

prédire un résultat à partir d'une entrée. Les extrants sont ensuite comparés à un en-

semble de résultats connus an de juger de l'exactitude des algorithmes, qui seront par

la suite ajustés de manière itérative pour perfectionner la capacité à prédire d'autres

résultats[15, 16].

Conclusion
Durant ce chapitre, nous avons déni les notions majeures liées à notre projet soient

CRM, IA et ML.

Dans le chapitre qui suit, nous entamerons la première étape de réalisation où nous allons

commencer par la mise en place de l'infrastructure des données.

19
Chapitre 3
Mise en Place de L'Infrastructure de
Données

20
Chapitre 3. Mise en Place de L'Infrastructure de Données

Introduction
Dans ce chapitre, nous allons nous concentrer sur les deux premiers sprints du projet

qui porteront sur la mise en place de l'infrastructure de données nécessaire pour soutenir

l'analyse et la visualisation ultérieures. Nous commencerons par exposer la conception de

notre entrepôt de données, pour passer au dévelopement des processus d'ETL (Extract,

Transform, Load) et nir par présenter la création du modèle tabulaire des données.

3.1 Sprint 1 : Conception de l'architecture de l'En-

trepôt de données et développement des processus
ETL
3.1.1 Sprint Backlog
Nous spécions les tâches à réaliser dans ce premier sprint ainsi que la durée estimée

dans le sprint backlog suivant (table 3.1) :

Table 3.1  Sprint Backlog du premier Sprint

ID Eléments du backlog et Tâches Estimation

1 Conception de l'architecture de l'entrepôt de données : 5 jours

 Spécication des objectifs de l'entrepôt de données

 Choix de l'approche de modélisation.

 Identifaction des tables de faits et des tables des di-

mensions.

 Conception du schema en ocon de neige.

2 Identication des sources de données. 2 jours

3 Développement et test des processus ETL : 10 jours

 Développement du package 'Sources vers zone de sta-

ging'.

 Développement de package 'Zone de transit vers

DWH'.

 Planication des processus ETL.

21
Chapitre 3. Mise en Place de L'Infrastructure de Données

3.1.2 Outils Utilisés

3.1.2.1 Sql Server Management Studio 19
SQL Server Management Studio, abrégé SSMS, est un environnement intégré fourni

par Microsoft pour la gestion de toute infrastructure SQL, de SQL Server à Azure SQL

Database[17].

SSMS permet de :

 Congurer, surveiller et administrer des instances de SQL Server et des bases de

données.

 Déployer, surveiller et mettre à niveau les composants de la couche données.

 Créer des requêtes et des scripts.

 Interroger, concevoir et gérer des bases de données et des entrepôts de données.

Figure 3.1  Logo de Sql Server Management Studio(SSMS)

3.1.2.2 Sql Server Integration Services 2022

SQL Server Integration Services, abrégé SSIS, est une plateforme d'intégration de

données et un outil ETL développé par Microsoft[18].

Elle permet de :

 Extraire et transformer des données provenant d'une grande variété de sources.

 Générer des solutions d'intégration de données.

 Nettoyer et explorer des données.

 Charger les données dans une ou plusieurs destinations(tels les entrepôts de don-

nées).

Figure 3.2  Logo de Sql Server Integration Services(SSIS)

22
Chapitre 3. Mise en Place de L'Infrastructure de Données

3.1.3 Conception de l'architecture de l'entrepôt de données

3.1.3.1 Spécication des objectifs de l'entrepôt de données
Dans le cadre de notre projet, an d'analyser et de suivir le CRM, la conception de

l'entrepôt de données sera orientée vers les trois sujets suivants :

 Ore : Regroupe les éléments liés à l'ore de produits et services de l'entreprise,

tels que la vente de produits, la mise en place, la formation et l'assistance technique,

répondre aux besoins des clients existants et attirer de nouveaux clients.

 Prospection : Regroupe les éléments liés à la prospection de nouveaux clients, tels

que la recherche de nouveaux clients et la présentation des services. La prospection

est une étape importante pour attirer de nouveaux clients et assurer la croissance

de l'entreprise.

 Fidélisation et Communication : Regroupe les éléments liés à la délisation et à

la communication avec les clients existants, tels que, le suivi d'aaire, le lancement

de nouveaux produits, la délisation et la promotion. Le but est de renforcer les

relation et maximiser leur valeur à long terme pour l'entreprise.

3.1.3.2 Choix de l'approche de modélisation

Comme mentionné et déni dans le chapitre précédent (partie 2.2.2.4), il existe deux

approches couramment utilisées pour concevoir et construire un entrepôt de données, soit

l'approche de Kimball et l'approche d'Inmon.

Dans notre cas, nous avons opté pour l'approche de Bill Inmon puisqu'elle garantit la

cohérence des données ainsi qu'une grande exibilité et une evoluvité facile de l'entrepôt

De plus c'est une approche approfondie et centralisée orant une vue globale et uniée de

toutes les données clients et de leurs interactions.

3.1.3.3 Identication des tables de dimensions

Nous avons identié les tables de dimensions suivantes :

- La dimension `Dim_Date' : contient les informations relatives aux dates. Elle

peut être utilisée pour ltrer les données par période et pour eectuer des agrégations

temporelles.

Le tableau (table 3.2) montre les attributs de la dimension `Dim_Date' ainsi que leurs

types :

23
Chapitre 3. Mise en Place de L'Infrastructure de Données

Table 3.2  Attributs de la dimension `Dim_Date'

Attributs Types
Id_Date (clé primaire) varchar

Date date

Annee int

Mois int

Jour int

- La dimension `Dim_Client' : stocke les informations sur les clients. Elle peut être

utilisée pour analyser les performances par client, segmenter les clients, etc.

Le tableau (table 3.3) montre les attributs de la dimension `Dim_Client' ainsi que leurs

types :

Table 3.3  Attributs de la dimension `Dim_Client'

Attributs Types
Code_Client (clé primaire) varchar

Nom_Client varchar

Email varchar

Secteur_Activite varchar

Ville_Client varchar

Date_Ajout date

Concerné_Client varchar

- La dimension `Dim_Contact' : contient les détails des contacts clients. Elle peut

être utilisée pour suivre les interactions spéciques avec les contacts clients.

Le tableau (table 3.4) montre les attributs de la dimension `Dim_Contact' ainsi que leurs

types :

Table 3.4  Attributs de la dimension `Dim_Contact'

Attributs Types
Code_Client (clé primaire) varchar

Num_Contact (clé primaire) varchar

Fonction_Contact varchar

Nom_Contact varchar

Email varchar

Telephone varchar

Mobile varchar

24
Chapitre 3. Mise en Place de L'Infrastructure de Données

- La dimension `Dim_Fonction' : répertorie les diérentes fonctions ou rôles que

peuvent occuper les contacts clients, par exemple, ssistant(e), chef Département, Gérant,

etc. Elle permet de segmenter les contacts clients en fonction de leur rôle dans le processus

de vente.

Le tableau (table 3.5) montre les attributs de la dimension `Dim_Fonction' ainsi que leurs

types :

Table 3.5  Attributs de la dimension `Dim_Fonction'

Attributs Types
Code_Fonction (clé primaire) varchar

Designation_Fonction varchar

- La dimension `Dim_Secteur' : répertorie les diérents secteurs d'activité auxquels

appartiennent les clients. Elle permet de segmenter les clients en fonction de leur secteur

d'activité pour une analyse plus précise.

Le tableau (table 3.6) montre les attributs de la dimension `Dim_Secteur' ainsi que leurs

types :

Table 3.6  Attributs de la dimension `Dim_Secteur'

Attributs Types
Code_Secteur (clé primaire) varchar

Designation_Secteur varchar

- La dimension `Dim_Ville' : stocke les informations sur les villes. Elle peut être

utilisée pour analyser les performances des ventes par région géographique.

Le tableau (table 3.7) montre les attributs de la dimension `Dim_Ville' ainsi que leurs

types :

Table 3.7  Attributs de la dimension `Dim_Ville'

Attributs Types
Code_Ville (clé primaire) varchar

Designation_Ville varchar

Region_Ville varchar

- La dimension `Dim_Utilisateur' : contient les informations sur les utilisateurs

du système. Elle peut être utilisée pour attribuer les actions, les ores et les activités de

prospection à des utilisateurs spéciques.

Le tableau (table 3.8) montre les attributs de la dimension `Dim_Utilisateur' ainsi que

leurs types :

25
Chapitre 3. Mise en Place de L'Infrastructure de Données

Table 3.8  Attributs de la dimension `Dim_Utilisateur'

Attributs Types
Code_Utilisateur (clé primaire) varchar

Nom_Utilisateur varchar

Departement_Commercial varchar

- La dimension `Dim_ObjetOre' : contient les diérents types d'objets ou de

catégories auxquels les ores proposées peuvent appartenir, tels que "Vente Produits",

"Assistance Technique", "Mise En Place", "Formation", etc. Elle peut être utilisée pour

suivre les performances par type d'ore, analyser les préférences des clients ou identier

les catégories d'ores les plus rentable.

Le tableau (table 3.9) montre les attributs de la dimension `Dim_ObjetOre' ainsi que

leurs types :

Table 3.9  Attributs de la dimension `Dim_ObjetOre'

Attributs Types
Code_ObjetOre (clé primaire) varchar

Designation_Objet varchar

Description_Objet varchar

- La dimension `Dim_EtatOre' : répertorie les diérents états possibles d'une ore,

tels que en cours, accepté, refusé, etc. Elle permet de suivre l'état des ores et d'analyser

le taux de conversion des ores proposées.

Le tableau (table 3.10) montre les attributs de la dimension `Dim_EtatOre' ainsi que

leurs types :

Table 3.10  Attributs de la dimension `Dim_EtatOre'

Attributs Types
Code_EtatOre (clé primaire) varchar

Designation_Etat varchar

- La dimension `Dim_ObjetAction' : répertorie les diérents types d'actions réa-

lisées, tels que "Appel lancement nouveau produit", "Promotion", "Suivi aaire", "Fi-

délisation", etc. Elle permet de catégoriser les actions entreprises lors des activités de

délisation et de communication.

Le tableau (table 3.11) montre les attributs de la dimension `Dim_ObjetAction' ainsi que

leurs types :

26
Chapitre 3. Mise en Place de L'Infrastructure de Données

Table 3.11  Attributs de la dimension `Dim_ObjetAction'

Attributs Types
Code_ObjetAction (clé primaire) varchar

Designation_Objet varchar

Description_Objet varchar

- La dimension `Dim_ResultatAction' : liste les résultats possibles des actions de

prospection et de délisation et de communication , tels que "Favorable", "Intérresé",

"Non Intéressé", etc. Elle permet de suivre les résultats des actions entreprises et d'ana-

lyser leur ecacité.

Le tableau (table 3.12) montre les attributs de la dimension `Dim_ResultatAction' ainsi

que leurs types :

Table 3.12  Attributs de la dimension `Dim_ResultatAction'

Attributs Types
Code_Resultat (clé primaire) varchar

Designation_Resultat varchar

- La dimension `Dim_CanalCommunication' : contient les informations relatives

aux canaux utilisés pour la prospection ou les actions de délisation et communication.

Elle peut être utilisée pour ltrer les données par type de canal (par téléphone ou sur

place).

Le tableau (table 3.13) montre les attributs de la dimension `Dim_CanalCommunication'

ainsi que leurs types :

Table 3.13  Attributs de la dimension `Dim_CanalCommunication'

Attributs Types
Code_CanalCommunication (clé primaire) varchar

Designation_CanalCommunication varchar

3.1.3.4 Identication des tables de faits

Nous avons identié les tables de faits suivantes :

- La table de faits `Fact_Ore' :

Le tableau (table 3.14) montre les attributs de la table de faits `Fact_Ore' ainsi que

leurs types :

27
Chapitre 3. Mise en Place de L'Infrastructure de Données

Table 3.14  Attributs de l a table de faits `Fact_Ore'

Attributs Types
Reference (clé primaire) varchar

Id_Date (clé étrangère) varchar

Code_Client (clé étrangère) varchar

Code_Utilisateur (clé étrangère) varchar

Code_ObjetOre (clé étrangère) varchar

Code_EtatOre (clé étrangère) varchar

Montant_HT decimal

Montant_TTC decimal

- La table de faits `Fact_Prospection' :

Le tableau (table 3.15) montre les attributs de la table de faits `Fact_Prospection' ainsi

que leurs types :

Table 3.15  Attributs de la table de faits `Fact_Prospection'

Attributs Types
Reference (clé primaire) varchar

Id_Date (clé étrangère) varchar

Code_Client (clé étrangère) varchar

Code_Utilisateur (clé étrangère) varchar

Code_ResultatFinalProspection (clé étrangère) varchar

Code_Canal_Prospection (clé étrangère) varchar

Nbre_Tentatives_Realisees int

Duree_Process int

- La table de faits `Fact_FidelisationEtCommunication' :

Le tableau (table 3.16) montre les attributs de la table de faits

`Fact_FidelisationEtCommunication' ainsi que leurs types :

Table 3.16  Attributs de la table de faits `Fact_FidelisationEtCommunication'

Attributs Types
Reference (clé primaire) varchar

Id_Date (clé étrangère) varchar

Code_Client (clé étrangère) varchar

Code_Utilisateur (clé étrangère) varchar

Code_ObjetAction (clé étrangère) varchar

28
Chapitre 3. Mise en Place de L'Infrastructure de Données

Table 3.16  Attributs de la table de faits `Fact_FidelisationEtCommunication'

Attributs Types
Code_ResultatFinalAction (clé étrangère) varchar

Code_Canal_Action (clé étrangère) varchar

Nbre_Tentatives_Realisees int

Duree_Process int

3.1.3.5 Conception du schéma en ocon de neige de l'entrepôt des données

Dans la gure (gure 3.3), nous schématisons l'architechture de l'entrepôt de données

`GSoft_CRM_DW' :

Figure 3.3  Conception de l'entrepôt des données

Cet entrepôt de données peut éventuellement être partitionné en trois datamarts (Ma-

gasins de données) dont l'architecture de chacun est montrée dans les gures suivantes

(gure 3.4, 3.5 et 3.6) :

29
Chapitre 3. Mise en Place de L'Infrastructure de Données

Figure 3.4  Conception du DataMart `Ore'

Figure 3.5  Conception du DataMart `Prospection'

30
Chapitre 3. Mise en Place de L'Infrastructure de Données

Figure 3.6  Conception du DataMart `FidelisationEtCommunication'

3.1.4 Description des sources de données

Notre projet consiste à développer une solution qui sera opérationnelle dans GSoft

CRM et prête à l'utilisation par tous ses clients.

Dans notre cas, pour l'implémentation et le test, nous avons utilisé les données d'un des

client de DIESE qui sont fournies sous forme de :

 Tables transactionnelles d'une base de données SQL2000 :

 Table `Client'

 Table `Utilisateur'

 Table `Contact'

 Table `Ore'

 Table `Action'

 Table `CanalCommunication'

31
Chapitre 3. Mise en Place de L'Infrastructure de Données

 Fichiers Plats :
 Fichier `Archivage des ores de 2019'

 Fichier `Archivage des ores de 2020'

 Fichier `Archivage des actions de 2019'

 Fichier `Archivage des actions de 2020'

3.1.5 Développement des processus ETL

Le processus d'intégration des données dans notre entrepôt de données suit un chemi-

nement qui va des sources de données vers une zone de staging (ou de transit) ETL, puis

vers l'entrepôt de données lui-même.

Les données sont extraites des sources d'origine, puis elles passent par des étapes de trans-

formation et de consolidation dans la zone de staging ETL. Une fois préparées, les données

sont chargées dans l'entrepôt de données nal à l'aide d'un autre processus ETL.

Ce processus est illustré lors du développement des deux packages SSIS développés (dé-

taillés par la suite) :

 Staging_Package

 DataWarehousing_Package

Figure 3.7  Les processus ETL pour alimentation de l'entrepôt de données

3.1.5.1 Staging_Package
Dans le package SSIS 'Staging_Package' (gure 3.8 ci-dessous), les données sont ex-

traites à partir des sources précédemment citées, collectées et combinées.

Par la suite, elles subissent des opérations de nettoyage et de transformation telles que :

 la conversion de type des données

 la génération des nouvelles colonnes dérivées

 Le tri des données

 Le fractionnement des données selon le contexte

 L'union et la fusion des données

32
Chapitre 3. Mise en Place de L'Infrastructure de Données

 La gestion des valeurs NULL

 L'ajout de colonnes

Et pour nir, ces données sont chargées dans les tables de la zone de staging an d'être

exportées vers l'entrepôt.

Figure 3.8  Staging_Package

La gure 3.9 montre l'exemple de chargement des données de prospection et celles

de délisation vers les tables `Stg_Prospection' et `Stg_ FidelisationEtCommunication'

dans la zone de transit.

Figure 3.9  Exemple d'une tâche de chargement vers la zone de staging

33
Chapitre 3. Mise en Place de L'Infrastructure de Données

3.1.5.2 DataWarehousing_Package
Le package SSIS 'DataWarehousing_Package' est représenté dans la gure 3.10 ci-

dessous.

Une fois qu'elles ont été extraites et préparés dans la zone de staging, les données sont

mappées aux structures correspondantes dans l'entrepôt de données. et associés avec les

tables de dimensions et les tables des faits (grâce à la tâche SSIS 'lookup').

Après, elles subissent des tansformations supplémentaires qui impliquent :

 La gestion des doublons

 La génération de nouvelles colonnes dérivées (pour les mesures)

 La recherche avec ou sans correspondance

 La normalisation

Et par la n, ces données sont chargées (insérées ou mises à jour) dans les tables de

dimensions et de faits de l'entrepôt de données et sont prêtes à être utilisées pour les

futurs analyses.

Figure 3.10  DataWarehousing_Package

La gure ci-après (gure 3.11) montre l'exemple de l'alimentation de la table des faits

`prospection'.

34
Chapitre 3. Mise en Place de L'Infrastructure de Données

Figure 3.11  Exemple d'alimentation d'une table des faits

Les deux packages sont, par la suite, déployés dans SQL Server.

3.1.5.3 Planication des processus ETL

En raison de la nature dynamique des données et des transactions eectuées par les

sociétés clientes, nous avons pris la décision d'automatiser et de planier les processus

ETL à l'aide de l'Agent SQL Server qui est un composant clé de SSMS qui permet de

programmer l'exécution de diverses tâches et travaux administratives.

Cela nous permet d'assurer des mises à jour régulières de la zone de staging et de l'entrepôt

de données et de garantir, ainsi, la synchronisation constante et précise de nos données

avec l'évolution de notre activité et reéter les modications survenant dans les sources

de données.

3.2 Sprint 2 : Analyse et Création du Modèle Tabulaire

3.2.1 Sprint BackLog
Nous spécions les tâches à réaliser dans ce deuxième sprint ainsi que la durée estimée

dans le sprint backlog suivant (table 3.17) :

35
Chapitre 3. Mise en Place de L'Infrastructure de Données

Table 3.17  Sprint Backlog du deuxième Sprint

ID Eléments du backlog et Tâches Estimation

1 Conception du modèle tabulaire : 3 jours

 Importation des données.

 Dénition des relations.

 Dénition des hiérarchies.

 Dénition des perspectives.

2 Dévéloppement des mesures. 3 jours

3 Planication des actualisations. 2 jours

3.2.2 Outils Utilisés

Sql Server Analysis Services 2022
SQL Server Analysis Services, abrégé SSAS, est une plateforme de traitement analy-

tique en ligne et d'exploration de données développée par Microsoft qui fournit une vue

agrégée des données pour eectuer des analyses complexes[19].

Elle permet de créer, à partir de sources de données relationnelles de :

 des cubes multidimensionnels : basés sur une structure de données multidi-

mensionnelle traditionnelle, où les données sont organisées en dimensions et en

mesures.

 des modèles tabulaires : utilisent une approche de modélisation en colonnes

pour fournir des performances élevées et une compression des données.

Figure 3.12  Logo de Sql Server Analysis Services(SSAS)

Dans notre cas, nous avons opté pour la création d'un modèle tabulaire.

3.2.3 Conception du modèle tabulaire

3.2.3.1 Importation des données
Une fois que notre entrepôt de données est établi et que les processus ETL sont mis en

place, les données sont devenues prêtes à l'exploitation et à l'utilisation pour la création

du modèle tabulaire.

36
Chapitre 3. Mise en Place de L'Infrastructure de Données

Nous n'avons qu'à congurer l'entrepôt `GSoft_CRM_DWH' comme étant une source

de données du modèle.

3.2.3.2 Dénition des relations

Comme elles ont été précedemment dénies lors de la conception de l'entrepôt des

données, les relations entre les tables (faits et dimensions) sont automatiquement créées

lors de l'importation des données. Il ne nous reste qu'à vérier leurs validités.

Ces relations sont montrées dans la gure suivante (gure 3.14) :

Figure 3.13  Liste des relations existantes entre les tables

3.2.3.3 Dénition des hiérarchies

An de faciliter la navigation entre les colonnes et l'exploration des données et les

structurer de manière logique, nous avons créé les hiérarchies suivantes :

 Dim_Date :

Jour → M ois → Année

Jour → M ois → T rimestre → Année
 Dim_Ville :

V ille → Région

3.2.3.4 Dénition des perspectives

En tenant en compte de l'architecture de notre entrepôt de données, nous avons opté
1
pour la création de quatre perspectives :

1. Une perspective dénit un sous-ensemble visible d'un modèle qui fournit des points de vue ciblés,
spéciques à l'entreprise ou spéciques à l'application du modèle tabulaire[20].

37
Chapitre 3. Mise en Place de L'Infrastructure de Données

 La perspective 'Globale'

 La perspective 'Ore'

 La perspective 'Prospection'

 La perspective 'Fidélisation et Communication'

3.2.4 Développement des mesures

Nous avons déni des mesures ainsi que leurs formules à l'aide du langage Data Ana-
2
lysis Expressions (DAX) . Ces mesures sont placées dans la grille des mesures du modèle

et seront utiliser ultérieurement pour la visualisation des données et la génération des

rapports. Elles sont réparties comme telles :

 Fact_Ore :
 Nombre total des ores

 Nombre total des ores (acceptées(gure 3.15)/déclinées/en cours)

 Montant des ores (acceptées/déclinées/en cours)

 Fact_Prospection :
 Nombre total des prospections eectuées

 Nombre total des prospections (conrmé/favorable/non intéressé/injoignable)

 Moyenne de tentatives pour conclure une prospection

 Durée moyenne du cycle de prospection

 Fact_FidélisationEtCommunication :
 Nombre total des actions eectuées

 Nombre total des actions (conrmé/favorable/non intéressé/injoignable)

 Moyenne de tentatives pour conclure une action

 Durée moyenne du cycle d'action

Figure 3.14  Calcul de la mesure nombre total des ores acceptées avec DAX

2. DAX est un langage de formule utilisé pour créer des calculs avancés et personnalisés sur les données
des tables et des colonnes grâce à des fonctions, des opérateurs, etc[21].

38
Chapitre 3. Mise en Place de L'Infrastructure de Données

3.2.5 Déploiment et planication du modèle tabulaire

3.2.5.1 Déploiment du modèle tabulaire
Une fois que le modèle tabulaire est créé, il est déployé vers SSMS où il peut être

interrogé à l'aide de requêtes MDX (Multidimensional Expressions) et DAX, en fonction

des besoins d'analyse. Cela permet d'eectuer des analyses approfondies sur les données

du modèle et d'obtenir plus d'informations pour la prise de décision.

3.2.5.2 Planication de l'actualisation du modèle

En raison de l'évolution continue des ux de données des clients, nous avons aussi

opté pour l'automatisation et la planication du processus de l'actualisation du modèle

tabulaire créé.

Pour cela, nous avons utilisé l'outil de planication des travaux Agent SQL Server.

Conclusion
Dans ce chapitre, nous nous sommes appliqué à la mise en place de l'infrastructure de

données. Nous avons déni, au début, la structure de notre entrepôt de données, identié

les sources et développé les ux ETL nécessaires. Et par la n, nous avons conçu et crée

le modèle tabulaire corespondant.

Dans le chapitre suivant, nous allons procéder pour les actions d'analyse, visualisation et

Consultation des données.

39
Chapitre 4
Exploitation des Données

40
Chapitre 4. Exploitation des Données

Introduction
Dans ce chapitre, nous aborderons les trois derniers sprints qui traiteront l'exploita-

tion des données. Nous débuterons par la visualisation des tableaux de bord interactifs

créés pour passer ensuite à l'analyse prédictive des données. Enn, nous procéderons à la

création du site web dédié à la consultation pour les décideurs des entreprises.

4.1 Sprint 3 : Création de rapports et de tableaux de

bord
4.1.1 Sprint BackLog
Nous spécions les tâches à réaliser dans ce troisième sprint ainsi que la durée estimée

dans le sprint backlog suivant (table 4.1) :

Table 4.1  Sprint Backlog du troisième Sprint

ID Eléments du backlog et Tâches Estimation

1 Obtention des données 1 jour

2 Création du tableau de bord `Ore' : 2 jours

 Présentation des KPIs.

 Présentation du tableau de bord.

3 Création du tableau de bord `Prospection' : 2 jours

 Présentation des KPIs.

 Présentation du tableau de bord.

4 Création du tableau de bord `Fidélisation Et Communica- 2 jours

tion' :

 Présentation des KPIs.

 Présentation du tableau de bord.

4.1.2 Outils Utilisés

Power BI
Power BI est une plateforme d'analyse et de visualisation de données développée par

Microsoft[22].

Elle permet de :

 Se connecter à plusieurs sources de données diérentes.

41
Chapitre 4. Exploitation des Données

 Transformer et nettoyer ces données pour créer un modèle de données.

 Créer des visuels et des graphiques qui donnent des représentations des données.

 Créer des rapports correspondant à des collections de visuels.

 Partager des rapports avec d'autres personnes au sein de la même organisation à

l'aide du service Power BI

Figure 4.1  Logo de Power BI

4.1.3 Obtention des données

Avant de procéder à la création des rapports et des tableaux de bord, nous avons

établi une connexion en direct (live connection) entre les données de SSAS (issues du

sprint précédent) et Power BI.

Cette connexion en direct nous garantit l'accés, en temps réel et de manière dynamique,

aux données du modèle tabulaire créé, sans nécessité d'importation ou de duplication des

données à chaque fois. De plus, elle nous permet de tirer parti des capacités d'analyse

avancées et des fonctionnalités de modélisation de SSAS.

Notre rapport sera composé de trois tableaux de bord chacun orienté vers un objectif.

4.1.4 Création du tableau de bord `Ore'

4.1.4.1 Présentation des KPIs
Pour la création de ce tableau de bord, nous avons utilisé les KPIs suivants (montrés

dans la table 4.2) :

Table 4.2  Liste des KPIs du tableau de bord `Ore'

KPI Axe Visuel utilisé

Nombre total des ores ∅ Carte

Date(année et mois) Graphique en courbe

Date(année et trimstre) et Histogramme groupé

état d'ore

Catégorie d'ore Graphique en anneau

Etat d'ore Graphique en anneau

Total du montant des ores acceptée ∅ Carte

Client Entonnoir

42
Chapitre 4. Exploitation des Données

Table 4.2  Liste des KPIs du tableau de bord `Ore'

KPI Axe Visuel utilisé

Total du montant des ores déclinée ∅ Carte

Client Entonnoir

Total du montant des ores en cours ∅ Carte

Taux des montants des ores pour Catégorie d'ore Graphique à barres

chaque état empilées (%)

4.1.4.2 Présentation du tableau de bord

La gure suivante (gure 4.2) représente le tableau de bord de la perspective `Ore'

Figure 4.2  Tableau de bord `Ore'

Ce tableau de bord est une représentation visuelle complète des données des ores et

des métriques liées à cet aspect. Il ore une interface interactive permettant aux décideurs

de surveiller et d'analyser les diérents types d'ores ainsi que leurs revenus et résultats.

De plus, il inclut des ltres(par date, type d'ore et état) qui permettent de personnaliser

les données achées en fonction des besoins.

4.1.5 Création du tableau de bord `Prospection'

4.1.5.1 Présentation des KPIs
Pour la création de ce tableau de bord, nous avons utilisé les KPIs suivants (montrés

43
Chapitre 4. Exploitation des Données

dans la table 4.3) :

Table 4.3  Liste des KPIs du tableau de bord `Prospection'

KPI Axe Visuel utilisé

Nombre total de prospections ∅ Carte

Date(année et mois) Graphique en courbe

Date(année et trimstre) et Histogramme groupé

résultat

Résultat de prospection Graphique en anneau

Canal de prospection Graphique en anneau

Moyenne de tentatives pour ∅ Carte

conclure une prospection

Durée moyenne du cycle de pros- ∅ Carte

pection

Nombre de prospections eec- Utilisateur Graphique à barres

tuées avec résultat groupées

Taux de conversion des prospects ∅ Jauge

en clients

4.1.5.2 Présentation du tableau de bord

La gure suivante 4.3 représente le tableau de bord de la perspective `Prospection'

Figure 4.3  Tableau de bord `Prospection'

44
Chapitre 4. Exploitation des Données

Ce tableau de bord est une représentation visuelle complète des données des pros-

pections ainsi que les métriques liées à cette perspective. Il ore une interface interactive

permettant aux décideurs de surveiller et d'analyser les diérentes prospections des clients,

leurs résultats, les canals utilisés et les taux de conversion des prospects en clients.

De plus, il inclut des ltres(par date et résultat de prospection) qui permettent de per-

sonnaliser les données achées en fonction des besoins.

4.1.6 Création du tableau de bord `Fidélisation Et Communica-

tion'
4.1.6.1 Présentation des KPIs
Pour la création de ce tableau de bord, nous avons utilisé les KPIs suivants (montrés

dans la table 4.4) :

Table 4.4  Liste des KPIs du tableau de bord `Fidélisation Et Communication'

KPI Axe Visuel utilisé

Nombre total d'actions ∅ Carte

Date(année et mois) Graphique en courbe

Date(année et trimstre) et Histogramme groupé

résultat

Catégorie d'action Graphique en anneau

Résultat d'action Graphique en anneau

Canal de communication Graphique en anneau

Moyenne de tentatives pour ∅ Carte

conclure une action

Durée moyenne du cycle d'action ∅ Carte

Taux de résultat d'actions Catégorie d'action Graphique à barres

empilées (%)

4.1.6.2 Présentation du tableau de bord

La gure suivante (gure 4.4) représente le tableau de bord de la perspective `Fidéli-

sation Et Communication'

Ce tableau de bord est une représentation visuelle complète des données des actions de

délisation et et de communication ainsi que les métriques liées à cette perspective. Il

ore une interface interactive permettant aux décideurs de surveiller et d'analyser les dif-

férentes types d'actions, leurs résultats, les canals utilisés et les durées des actions.

De plus, il inclut des ltres(par date, catégorie d'action et résultat de l'action) qui per-

mettent de personnaliser les données achées en fonction des besoins.

45
Chapitre 4. Exploitation des Données

Figure 4.4  Tableau de bord `Fidélisation Et Communication'

4.2 Sprint 4 : Analyse prédictive et machine learning

4.2.1 Sprint BackLog
Nous spécions les tâches à réaliser dans ce quatrième sprint ainsi que la durée estimée

dans le sprint backlog suivant (table 4.5) :

Table 4.5  Sprint Backlog du quatrième Sprint

ID Eléments du backlog et Tâches Estimation

1 Spécication des objectifs de l'utilisation de L'apprentissage 5 jours

automatique :

 Prédiction du nombre des ores futures

 Prédiction du potentiel montant des ores acceptées.

 Prédiction des taux futurs de conversion des prospects

en clients

 Le classement et l'évaluation des résultats des actions

de délisation et communication

2 Choix des algorithmes. 2 jours

3 Réalisation. 7 jours

4 Visualisation des prédictions. 2 jours

46
Chapitre 4. Exploitation des Données

4.2.2 Outils Utilisés

Jupyter
Jupyter, une interface web interactive, est un environnement de développement connu

dans le domaine de l'analyse de données, de l'apprentissage automatique et de la science

des données [23].

Il permet de :

 Ecrire et d'exécuter du code en direct en prenant en charge plusieurs langages,

notamment, Python.

 Faciliter le processus d'exploration des données.

 Analyser les données.

 Générer des visualisations riches.

Figure 4.5  Logo de Jupyter

4.2.3 Spécication des objectifs de l'utilisation de L'apprentis-

sage automatique
Une fois les tableaux de bord construits, nous passons à l'inclusion des fonctionnalités

de prédiction et de classement dans le CRM.

Dans ce contexte, nous avons utilisé alors l'apprentissage automatique pour :

 La prédiction du nombre des ores futures.

 La prédiction du potentiel de montant des ores acceptées.

 La prédiction des taux futurs de conversion des prospects en clients.

 Le classement et l'évaluation des résultats des actions de délisation et communi-

cation.

L'objectif est de tirer parti des données collectées et des visualisations créées précedem-

ment pour anticiper les performances futures de l'entreprise, identier les opportunités

d'amélioration et prendre des décisions plus éclairées.

4.2.4 Choix des algorithmes

An d'atteindre nos objectifs, nous avons utilisé les algorithmes d'apprentissage sui-

vants :

47
Chapitre 4. Exploitation des Données

4.2.4.1 La régression linéaire

La régression linéaire est un type d'algorithme d'apprentissage automatique supervisé

qui calcule la relation linéaire entre une variable dépendante et une ou plusieurs carac-

téristiques indépendantes. Le but est de trouver la meilleure équation linéaire qui peut

prédire la valeur de la variable dépendante en fonction des variables indépendantes[24].

Nous avons utilisé cet algorithme pour :

 La prédiction du nombre des ores futures : Ce choix est justié par la nature
continue de nos variables cibles(le nombre d'ore) et la relation linéaire attendue

avec nos variables explicatives(dans notre cas, l'année et le mois).

 La prédiction du potentiel montant des futures ores acceptées : Cet

algorithme nous a permis de prendre en compte les variables telles que la catégorie

d'ore, l'historique des montants précédents pour générer des prédictions sur le

montant potentiel des ores à venir.

 La prédiction des taux futurs de conversion des prospects en clients :

Cet algorithme nous a permis de se focaliser sur les caractéristiques des prospects

ainsi que les taux de conversion précédents pour établir les prédictions futurs de

conversion des prospects.

4.2.4.2 L'arbre de décision

L'arbre de décision est un algorithme polyvalent d'apprentissage automatique super-

visé, utilisé à la fois pour les problèmes de classication et de régression. Il s'agit dune

structure arborescente de type organigramme où chaque n÷ud interne désigne la fonc-

tionnalité, les branches désignent les règles et les n÷uds feuilles désignent le résultat de

l'algorithme[25].

Nous avons utilisé cet algorithme pour :

 Le classement et l'évaluation des résultats des actions de délisation et

communication : En eet, cet algorithme nous a permis d'analyser les caractéris-
tiques de chaque action, comme le canal de communication et la catégorie d'action,

pour prédire la classe de résultat à laquelle appartiendraient les futurs actions.

4.2.5 Réalisation
Pour la réalisation de ces tâches de prédiction et de classication, nous avons utilisé

le langage Python.

Nous avons, tout à bord, commencé par la collecte des données nécessaires à nos modèles

d'apprentissage automatique. Nous les avons extrait à partir de notre entrepôt des données

et eectué un prétraitement pour les rendre adaptées à l'analyse.

48
Chapitre 4. Exploitation des Données

Par la suite, nous avons sélectionné les algorithmes appropriés choisis en fonction des

objectifs spéciques de notre projet (la régression linéaire et les arbres de décision).

Une fois les modèles d'apprentissage automatique construits, nous les avons entraînés

en utilisant l'ensemble de données d'entraînement et évalués en utilisant l'ensemble de

données de test.

Ceux-ci faits, les modèles sont désormais prêts et nous pouvons les utiliser pour prédire

le nombre des ores futures, estimer les montants potentiels et les taux de conversion des

prospects en clients ou encore classer et évaluer les résultat des actions de délisation et

communication.

4.2.6 Visualisation des prédictions

Après l'éxécution du code et l'obtention des tables de prédiction, nous les avons trans-

féré vers power BI comme source de données pour les visualiser comme montré dans la

gure 4.6.

Figure 4.6  Tableau de bord de prédiction

Voir annexe pour la représentation de l'arbre de décision.

4.3 Sprint 5 : Création de site web de consultation

4.3.1 Sprint Backlog
Nous spécions les tâches à réaliser dans ce dernier sprint ainsi que la durée estimée

dans le sprint backlog suivant (table 4.6) :

49
Chapitre 4. Exploitation des Données

Table 4.6  Sprint Backlog du cinquième Sprint

ID Eléments du backlog et Tâches Estimation

1 Réalisation du diagramme de cas d'utilisation. 1 jour

2 Publication des rapports réalisés. 1 jour

3 Développement et présentation des interfaces des pages : 2 jours

 Page de connexion.

 Page de présentation des tableaux d'ores.

 Page de présentation du tableau de bord de prédiction.

4.3.2 Réalisation du diagramme de cas d'utilisation

Le site web doit permettre aux décideurs de pouvoir se connecter, consulter et navi-

guer entre les diérents tableaux de bord précedemment réalisés dans les deux dernières

sections.

Ainsi le diagramme de cas d'utilisation sera illustré comme tel(gure 4.7)

Figure 4.7  Diagramme de cas d'utilisation de la réalisation du site web

4.3.3 Publication des rapports réalisés

Pour pouvoir utiliser les rapports précedemment créés et les insérer dans le site web,

nous avons besoin de les publier sur le service power BI.

Pour cela, nous avons créé une passerelle de données(On-premises data Gateway) qui nous

a permis de relier les données sur site avec le service, tout en assurant une actualisation

régulière des informations.

4.3.4 Développement et présentation des interfaces des pages

Le site web de consultation développé est constitué de trois pages :

50
Chapitre 4. Exploitation des Données

4.3.4.1 Page de connexion

Dans cette page, l'utilisateur est mené à entrer ses données d'authentication. Ces

dernières seront vérier : seuls les décideurs ont l'accés aux tableaux de bord. L'utilisateur

possède l'option de récupérer son mot de passe en cas d'oubli. (gure 4.8)

Figure 4.8  Page de connexion du site

4.3.4.2 Page de présentation des tableaux de bord

Dans cette page, le décideur peut consulter les rapports et naviguer entre les pages.

(gure 4.9)

Figure 4.9  Page de consultation des tableaux de bord

51
Chapitre 4. Exploitation des Données

4.3.4.3 Page de présentation du tableau de bord de prédiction

Dans cette page, le décideur peut consulter les rapports de prédiction. (gure 4.10)

Figure 4.10  Page de consultation du tableau de bord de prédiction

Conclusion
Dans ce chapitre, nous avons tout d'abord visualisé les données dans des tableaux

de bord signicatifs puis nous avons réalisé une analyse prédive pour cerner les futures

tendances et actions. Vers la n, nous avons développé un site web de consultation pour

les décideurs.

52
Conclusion générale

Au terme de ce projet de n d'études, nous avons créé une solution complète, amélio-

rée et intégrée du logiciel GSoft CRM. Cette solution permet à ses utilisateurs d'exploiter

pleinement les données des clients et leurs interactions, de prendre des décisions éclairées

et de suivre les performances de manière proactive.

De la conception de l'entrepôt de données à la création des tableaux de bord, en passant

par l'analyse prédictive et la consultation en ligne, chaque sprint a apporté des fonc-

tionnalités essentielles à notre solution, permettant ainsi à notre organisme d'accueil de

prospérer et de rester compétitive sur le marché.

Pour les perspectives futures, nous envisageons d'explorer davantage les possibilités

oertes par l'intelligence articielle et le traitement du langage naturel pour améliorer

encore plus la solution de CRM. Nous pourrions développer des chatbots pour une assis-

tance en ligne en temps réel, utiliser l'analyse sémantique pour extraire des informations

précieuses à partir des données non structurées, ou encore mettre en place des systèmes

de recommandation personnalisés pour les clients.

Dans l'ensemble, ce stage de n d'études a été une expérience très enrichissante, tant

sur le plan académique que professionnel. Il nous a permis d'appliquer les connaissances

théoriques acquises tout au long de notre cursus universitaire à un projet concret dans un

environnement professionnel.

Nous avons assimilé des compétences pratiques en matière de gestion de projet, d'analyse

de données et d'utilisation d'outils d'apprentissage automatique, tout en développant

notre capacité à travailler en équipe et à relever des dés concrets.

53
Bibliographie
[1] K. Schwaber and J. Sutherland, The scrum guide, 2020. [En ligne]. Disponible

sur : https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf

[2] Microsoft Corporation, Qu'est-ce que scrum ? Novembre 2022, Consulté le 02 Mars

2023. [En ligne]. Disponible sur : https://learn.microsoft.com/en-us/devops/plan/

what-is-scrum

[3] F. Buttle, Customer Relationship Management : Concepts and Technologies. Rout-

ledge, 2015.

[4] M. W. Johnson, C. M. Christensen, and H. Kagermann, Reinventing your business

model, Harvard Business Review, vol. 86, no. 12, pp. 5059, 2008.

[5] D. Lu and P. M. Swatman, Customer relationship management : An overview,

Informatik/Informatique, vol. 44, no. 6, pp. 713, 2003.

[6] L. Fabrique, Le guide sur les logiciels crm marketing : dénition et

fonctionnalités, Consulté le 10 Mars 2023. [En ligne]. Disponible sur :

https://www.lafabriquedunet.fr/crm/logiciels-crm-marketing/

[7] F. Burstein and C. Holsapple, Handbook on decision support systems 2. Springer,

2008.

[8] P. Ponniah, Data Warehousing Fundamentals : A Comprehensive Guide for IT Pro-

fessionals. John Wiley and Sons, 2010.

[9] Microsoft, Qu'est-ce qu'un entrepôt de données ? Consulté le 11 Mars

2023. [En ligne]. Disponible sur : https://azure.microsoft.com/fr-fr/resources/

cloud-computing-dictionary/what-is-a-data-warehouse/#data-warehouse-denition

[10] R. Kimball and M. Ross, The Data Warehouse Toolkit : The Denitive Guide to

Dimensional Modeling. John Wiley and Sons, 2013.

[11] Oracle, Tout ce que vous devez savoir sur un data mart, Consulté le 11

Mars 2023. [En ligne]. Disponible sur : https://www.oracle.com/fr/database/

data-mart-denition.html

[12] W. Inmon, Building the Data Warehouse, 4th ed. John Wiley and Sons, 2005.

[13] GeeksforGeeks, Diérence entre kimball et inmon - geeksforgeeks, Consulté

le 30 Mai 2023. [En ligne]. Disponible sur : https://www.geeksforgeeks.org/

dierence-between-kimball-and-inmon/

54
Bibliographie

[14] Intelligence articielle : qu'est-ce que c'est ? Consulté le 08 Mars 2023.

[En ligne]. Disponible sur : https://www.futura-sciences.com/tech/denitions/

informatique-intelligence-articielle-555/

[15] J. M. Helm1, A. M. Swiergosz1, H. S. Haeberle2, J. M. Karnuta1, J. L. Schaer1,

V. E. K. 1, A. I. Spitzer3, and P. N. Ramkumar, Machine learning and articial

intelligence : Denitions, applications, and future direction, en ligne, Janvier 2020.

[16] K. Murphy, Machine learning : A probabilistic perspective, MIT Press, 2012.

[17] Microsoft, Qu'est-ce que sql server management studio (ssms) ? Consulté le 03

Avril 2023. [En ligne]. Disponible sur : https://learn.microsoft.com/en-us/sql/ssms/

sql-server-management-studio-ssms?view=sql-server-ver16

[18] Microsoft, sql server integration services, Consulté le 03 Avril 2023. [En

ligne]. Disponible sur : https://learn.microsoft.com/fr-fr/sql/integration-services/

sql-server-integration-services?view=sql-server-ver16

[19] Microsoft, sql server analysis services, Consulté le 16 Avril 2023. [En ligne].

Disponible sur : https://learn.microsoft.com/en-us/analysis-services/ssas-overview?

view=asallproducts-allversions

[20] Microsoft, Perspectives dans les modèles tabulaires, Consulté le 17

Avril 2023. [En ligne]. Disponible sur : https://learn.microsoft.com/

en-us/analysis-services/ssas-overview?view=asallproducts-allversionshttps://learn.

microsoft.com/en-us/analysis-services/tabular-models/perspectives-ssas-tabular?

view=asallproducts-allversions

[21] Microsoft, Dax dans les modèles tabulaires, Consulté le 18 Avril 2023. [En

ligne]. Disponible sur : https://learn.microsoft.com/en-us/analysis-services/

tabular-models/understanding-dax-in-tabular-models-ssas-tabular?view=

asallproducts-allversions

[22] Microsoft, Qu'est-ce que power bi desktop ? Consulté le 27 Avril 2023. [En

ligne]. Disponible sur : https://learn.microsoft.com/fr-fr/power-bi/fundamentals/

desktop-what-is-desktop

[23] jupyter, Jupyter, Consulté le 12 Mai 2023. [En ligne]. Disponible sur :

https://jupyter.org/

[24] GeeksforGeeks, Régression linéaire dans l'apprentissage automatique, Consulté

le 12 Mai 2023. [En ligne]. Disponible sur : https://www.geeksforgeeks.org/

ml-linear-regression/

[25] geeksforgeeks, Arbre de décison, Consulté le 12 Mai 2023. [En ligne]. Disponible

sur : https://www.geeksforgeeks.org/decision-tree/

55
Annexe

56
 Annexe .

Annexe 11  Arbre de décision

57
 Résumé
Ce travail a été réalisé au sein de la société DIESE dans le cadre d'un projet de

n d'études pour l'obtention de diplôme de licence en informatique de gestion spécialité

Business Intelligence à la faculté des sciences économiques et de gestion à Nabeul.

Le projet vise à améliorer un logiciel CRM existant et à orir une solution complète en y

intégrant des fonctionnalités avancées de BI et d'IA.

À travers cinq sprints successifs, nous avons mis en place une infrastructure de données

solide, développé des modèles d'analyse prédictive, créé des tableaux de bord interactifs

et conçu un site web dédié à la consultation des données.

Ces améliorations permettent aux utilisateurs du logiciel d'accéder à des visualisations,

d'optimiser les actions de prospection et de délisation, et de prendre des décisions éclai-

rées.

Mots clés : Informatique décisionnelle(BI), Entrepôt de données, CRM, Intelligence Ar-

ticielle(IA), Apprentissage automatique(ML)

Abstract
This work was carried out within the company DIESE as a part of a project of end of

studies for obtaining a bachelor's degree in Business Computing, specializing in Business

Intelligence at the Faculty of Economics and Management in Nabeul.

The project aims to improve an existing CRM software and oer a complete solution by

integrating advanced BI and AI functionalities.

Through ve successive sprints, we have established a solid data infrastructure, develo-

ped predictive analytics models, created interactive dashboards and designed a website

dedicated to consulting data.

These enhancements allow software users to access visualizations, optimize prospecting

and loyalty actions, and make informed decisions

Mots clés : Business Intelligence(BI), Data warehouse, CRM, Articial Intelligence(IA),

Machine Learning(ML)