Mémoire CGBI

Remerciement
Avant de commencer, nous tenons à exprimer notre gratitude et nos

remerciements sincères pour toutes les personnes ayant contribué à la
réalisation et l’accomplissement de ce projet.
Nous tenons tout d’abord à remercier Monsieur Mohamed Jarboui

encadrant académique et professionnel pour son aide, ses conseils et sa
disponibilité tout au long du projet.
Nous remercions également tous nos enseignants de l’ESEN et ISCAE pour

leur patience, leur soutien et les connaissances qu’ils nous ont transmis tout
au long de nos 2 ans de Master.
1
Dédicaces
A ma grand-mère
Source de tendresse par excellence, la personne la plus chère à mon cœur, à
qui je souhaite un bon rétablissement.
A ma mère
Pour un enfant, perdre l’être qui lui est le plus cher est la plus grande des
douleurs qui soit sur terre.
Ton âme si belle s’est envolée au paradis des sages.Heureusement, j’ai pu
garder dans ma mémoire la douceur de tes sourires et l’éclat de ton visage.
Mes souvenirs de toi sont une source de bonheur.
Je t’aime tellement et tu me manques en toute heure.
A mon père
A mon cher papa, aucun mot ne peut exprimer ma reconnaissance envers
tout ce que tu fais pour mon confort et mon éducation. Ton suivi, ton
contrôle et tes conseils qui sont en or ont fait de moi la personne que je suis
aujourd’hui.
A tous mes amis

Merci à tous mes amis avec qui je partage des moments de ma vie au fil du
temps.
GHASSEN
Table des matières
1 Etude de projet 3
1.1 Présentation de l’organisme d’acceuil . . . . . . . . . . 3
1.1.1 Présentation de Tunisie Telecom [1] . . . . . . . . . . . 3
1.1.2 Organigramme de "Tunisie Telecom" . . . . . . . . . . 7
1.2 Présenation du projet . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Description du projet . . . . . . . . . . . . . . . . . . 7
1.2.2 Objectifs du projet . . . . . . . . . . . . . . . . . . . . 8
1.3 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . 8
1.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 L’informatique décisionnelle . . . . . . . . . . . . . . . . . 9
1.5.1 Défintion et objectifs . . . . . . . . . . . . . . . . . . . 9
1.5.2 Architecture générale . . . . . . . . . . . . . . . . . . 11
1.5.3 Modélisation d’une base donnée multidimensionnelle . 13
1.6 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . 16
1.6.1 Méthodologie choisie agile . . . . . . . . . . . . . . . . 16
1.6.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 Planification et architecture 20
2.1 Spécification des besoins . . . . . . . . . . . . . . . . . . . 20
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . 21
2.1.2 Diagramme de contexte statique . . . . . . . . . . . . 21
2.1.3 Les besoins fonctionnels . . . . . . . . . . . . . . . . . 22
2.1.4 Les besoins non fonctionnels . . . . . . . . . . . . . . 23
2.2 Structure et découpage du projet . . . . . . . . . . . . . 23
2.2.1 Pilotage du projet par Scrum . . . . . . . . . . . . . . 23
2.2.2 Le backlog du produit . . . . . . . . . . . . . . . . . . 24
2.2.3 Planification des sprints . . . . . . . . . . . . . . . . . 27
2.3 Diagramme de cas d’utilisation global . . . . . . . . . . . 28
2.4 Prototypage des interfaces . . . . . . . . . . . . . . . . . . 28
0
TABLE DES MATIÈRES
2.5 Architecture de travail . . . . . . . . . . . . . . . . . . . . 30

2.6 Choix technologique . . . . . . . . . . . . . . . . . . . . . . 31
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3 SPRINT1 : GESTION DES DONNÉES 32

3.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . 33
3.2.1 Classification des cas d’utilisation par acteur . . . . . 33
3.2.2 Diagramme de cas d’utilisation . . . . . . . . . . . . . 33
3.3 Extraction et Trasformation des données . . . . . . . . 34
3.3.1 Extraction des données . . . . . . . . . . . . . . . . . 34
3.3.2 Tranformation des données . . . . . . . . . . . . . . . 36
3.4 Modélisation des données . . . . . . . . . . . . . . . . . . 37
3.4.1 Les relations entre les tables . . . . . . . . . . . . . . 40
3.4.2 Schéma en étoile . . . . . . . . . . . . . . . . . . . . . 41
3.5 Analyse des données . . . . . . . . . . . . . . . . . . . . . . 41
3.6 Sprint terminé . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4 SPRINT2 : VISUALISATIONS DES DONNÉES 45

4.1 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.1 Classification de cas d’utilisation par acteur . . . . . . 46
4.2.3 Raffinement des cas d’utilisation . . . . . . . . . . . . 47
4.2.4 Description textuelle des cas d’utilisation . . . . . . . 49
4.3 Implémentation des Dashboard . . . . . . . . . . . . . . 50
4.4 Sprint terminer . . . . . . . . . . . . . . . . . . . . . . . . 58
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5 Sprint 3 : ANALYSE PRÉDICTIVE 59

5.1 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2.1 Classification des cas d’utilisation par acteur . . . . . 60
5.3 Gérer les autorisations . . . . . . . . . . . . . . . . . . . . 61
5.4 Gérer les alertes . . . . . . . . . . . . . . . . . . . . . . . . 62
5.5 Jeu de données . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.5.1 Actualisation du jeu de données . . . . . . . . . . . . 63
5.6 Analyse prédictive (Machine Learning) . . . . . . . . . 64
5.6.1 Régression Linéaire Multiple . . . . . . . . . . . . . . 64
1
TABLE DES MATIÈRES
5.6.2 Régression Linéaire . . . . . . . . . . . . . . . . . . . 66

5.6.3 Régression Logistique . . . . . . . . . . . . . . . . . . 69
5.6.4 ARMA/SARIMA . . . . . . . . . . . . . . . . . . . . 71
5.7 Sprint terminé . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6 PHASE DE CLÔTURE 74
6.1 Environnement de travail . . . . . . . . . . . . . . . . . . 74
6.1.1 Environnement matériel . . . . . . . . . . . . . . . . . 74
6.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . 75
6.1.3 Technologies et langages utilisés . . . . . . . . . . . . . 79
Conclusion générale 80
2
Table des figures
1.1 Logo "Tunsie Telecom" . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Organigramme de "Tunsie Telecom" . . . . . . . . . . . . . . . 7
1.3 Architecture Décisionnelle . . . . . . . . . . . . . . . . . . . . 11
1.4 Schéma de Modéle en etoile . . . . . . . . . . . . . . . . . . . 14
1.5 Schéma de Modèle en flocon de neige . . . . . . . . . . . . . . 15
1.6 Schéma de Modèle en constellation . . . . . . . . . . . . . . . 16
1.7 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 Diagramme de contexte statique . . . . . . . . . . . . . . . . . 21

2.2 Backlog du produit sur Jira . . . . . . . . . . . . . . . . . . . 26
2.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . 27
2.4 Diagramme des cas d’utilisation global . . . . . . . . . . . . . 28
2.5 Maquette-Client . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6 Maquette-Trafic . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.7 Maquette-Offre . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.8 Architecture de travail . . . . . . . . . . . . . . . . . . . . . . 31
3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Diagramme de cas d’utilisation - Sprint1 . . . . . . . . . . . . 33
3.3 échantillons des données . . . . . . . . . . . . . . . . . . . . . 34
3.4 Importation les données dans Power BI . . . . . . . . . . . . . 35
3.5 Etape appliquées . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6 les Relations entre les dimensions . . . . . . . . . . . . . . . . 40
3.7 Schéma en étoile de Power Bi . . . . . . . . . . . . . . . . . . 41
3.8 Requête DAX . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.9 Requête DAX . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.10 Requête DAX . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.11 Requête DAX . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.12 Requête DAX . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.13 Requête DAX . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.14 Requête DAX . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3
TABLE DES FIGURES
3.15 Requête DAX . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.16 Requête DAX . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.17 Sprint Terminer sur Jira . . . . . . . . . . . . . . . . . . . . . 44
4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . 45

4.2 Diagramme de cas d’utilisation -Sprint2 . . . . . . . . . . . . . 46
4.3 Raffinement du cas d’utilisation "gérer client" . . . . . . . . . 47
4.4 Raffinement du cas d’utilisation "gérer Trafic" . . . . . . . . . 48
4.5 Raffinement du cas d’utilisation "gérer Offre" . . . . . . . . . . 48
4.6 Dashboard Client . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7 Dashboard Client page 2 . . . . . . . . . . . . . . . . . . . . 52
4.8 Dashboard Trafic . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.9 Dashboard Trafic page 2 . . . . . . . . . . . . . . . . . . . . . 54
4.12 Dashboard Offre . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.13 Sprint 2 Terminer sur Jira . . . . . . . . . . . . . . . . . . . . 58
5.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . 59

5.2 “Diagramme de cas d’utilisation -Sprint 3“ . . . . . . . . . . . 60
5.3 “Gérer les autorisations “ . . . . . . . . . . . . . . . . . . . . . 61
5.4 “Gérer les Alertes “ . . . . . . . . . . . . . . . . . . . . . . . . 62
5.5 “Traçabilité du jeu de données “ . . . . . . . . . . . . . . . . . 63
5.6 “Actualisation du jeu de données “ . . . . . . . . . . . . . . . 63
5.7 “Formule de Régression Linéaire Multiple “ . . . . . . . . . . . 64
5.8 “ Code source de Régression Linéaire Multiple “ . . . . . . . . 65
5.9 “Résultat de Régression Linéaire Multiple “ . . . . . . . . . . 66
5.10 “ Régression Linéaire “ . . . . . . . . . . . . . . . . . . . . . . 67
5.11 “Démarche et test de régression linéaire “ . . . . . . . . . . . . 68
5.12 “Résulta de Régression Linéaire “ . . . . . . . . . . . . . . . . 68
5.13 “ Régression Linéaire “ . . . . . . . . . . . . . . . . . . . . . . 69
5.14 “ Code source de Régression Logistique “ . . . . . . . . . . . . 70
5.15 “ Régression Logistique “ . . . . . . . . . . . . . . . . . . . . . 71
5.16 “ Formule ARMA “ . . . . . . . . . . . . . . . . . . . . . . . . 71
5.17 “ Formule SARIMA “ . . . . . . . . . . . . . . . . . . . . . . . 72
5.18 “ Code source des Modèles ARMA et SARIMA “ . . . . . . . 72
5.19 “ Résultat des Modèles ARMA et SARIMA “ . . . . . . . . . 73
5.20 “ Sprint 3 Terminé sur Jira “ . . . . . . . . . . . . . . . . . . . 73
6.1 logo POWER BI . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.2 logo POWER Autaomate . . . . . . . . . . . . . . . . . . . . . 76
4
6.3 logo GooGLE Colab . . . . . . . . . . . . . . . . . . . . . . . 76
6.4 logo Azure Machine Learning Studio . . . . . . . . . . . . . . 77
6.5 logo DrawIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.6 logo JustInMind . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.7 logo Sharelatex OverLeaf . . . . . . . . . . . . . . . . . . . . . 78
6.8 logo PYTHON . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.9 logo LaTex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Liste des tableaux
2.1 Identification des acteurs de systéme . . . . . . . . . . . . . . 21

2.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 Classification des cas d’utilisation- sprint1 . . . . . . . . . . . 33

3.2 Table de fait «FCT» . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Table Offre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4 Table Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5 Table Région . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6 Table Anc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7 Table Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1 Classification des cas d’utilisation sprint 2 . . . . . . . . . . . 46

4.2 Description textuelle du cas "Gérer client" . . . . . . . . . . . 49
4.3 Description textuelle du cas "Gérer Trafic" . . . . . . . . . . . 49
4.4 Description textuelle du cas "Gérer Offre" . . . . . . . . . . . . 49
5.1 Classification des cas d’utilisation- sprint 3 . . . . . . . . . . . 60
6.1 Matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Introduction générale
« L’informatique décisionnelle (ou BI pour Business Intelligence) dé-

signe les moyens, les outils et les méthodes qui offre de collecter, consolider,
modéliser et restituer les données, matérielles ou immatérielles, d’une entre-
prise en vue d’offrir une aide à la décision et de permettre aux responsables
de la stratégie d’entreprise d’avoir une vue d’ensemble de l’activité traitée. »
Une entreprise est habituellement composée de plusieurs services tels

que les ressources humaines, les services comptabilité, marketing, commercial,
technique etc. Tous sauvegarder des informations propres à leurs fonctions :
listes des clients,des employés, chiffres, emplois du temps...
L’accumulation de ces données nécessite donc leur sauvegarde dans le but
d’une future exploitation. On constate ainsi régulièrement que chaque service
possède son tableau de bord, ce qui lui permet de mesurer ses principaux indi-
cateurs de performance stratégiques, de productivité,de qualité, rendement,
compétitivité ou encore liés au marketing tels que le taux de conversion, l’in-
dice d’engagement etc .
Chaque département d’une entreprise a généralement sa propre manière

de sauvegarder les informations (dans des fichiers Excel, des bases de données
relationnelles, etc.) et sa manière de déterminer les indicateurs, avec sa vérité
et ses critères. Ainsi, si l’on veut observer les données de l’entreprise dans son
ensemble, la tâche s’avère difficile et de temps en temps impossible. Pourtant,
cela constituerait une utilité évidente et un réel apport à la société. En effet,
une mise en relation et une analyse de toutes les données permettraient de
réaliser des études et des prévisions sur le comportement et la « santé » de
l’entreprise.
Notre projet est réparti sur 6 chapitres selon la méthodologie de concep-
tion SCRUM.
1
LISTE DES TABLEAUX
Le premier chapitre présente d’une maniére générale le projet de l’en-

treprise Tunisie Telecom, l’étude de l’existant, la problématique et la solution
proposée en évoquant la méthodologie de travail de ce projet.
Le deuxième chapitre, intitulé "Planification et Architecture", contient

le Product Backlog construit dans le cadre de la première partie de la mé-
thodologie Agile Scrum. Il s’agit d’une liste de tâches priorisées définissant
les caractéristiques du produit.Il met en exergue les fonctionnalités de projet
en spécifiant les besoins fonctionnels et non fonctionnels.
les trois chapitres suivants, intitulés respecivement ’Gestion des don-

nées’,’Visualisations des données’,et ’Analyse prédictive’ présentent les 3 sprints
du projet.
Le dernier chapitre, intitulé "Phase de clôture", contient une introduc-

tion à l’environnement matériel et logiciel utilisé pour la conception et le
développement de notre projet.
Nous avons terminé notre projet par une conclusion générale qui résume
notre mission et les compétences acquises tout au long la période du stage.
2
Chapitre 1
Etude de projet
Introduction
Ce chapitre décrit les premières étapes de la mise en œuvre de notre
solution. Tout d’abord, nous allons soumettre compendieusement l’entreprise
au sein de laquelle nous avons passé notre période stage, ensuite nous allons
présenter le projet grâce à une étude de l’existant.Enfin la méthode de projet
utilisée.
1.1 Présentation de l’organisme d’acceuil

Dans cette partie, nous nous attarderons sur la présentation de Tunisie
Télécom, son histoire, son évolution et la nature de ses activités, en précisant
enfin ses services.
1.1.1 Présentation de Tunisie Telecom [1]

- L’office national des télécommunications est créé suite à la promulga-
tion de la loi N°36 du 17 avril 1995.
- L’office a ensuite changé de statut juridique, en vertu du décret N°30 du 5
avril 2004, pour devenir une société anonyme dénommée « Tunisie Telecom
».
- En juillet 2006, il a été procédé à l’ouverture du capital de Tunisie Telecom
à hauteur de 35en faveur du consortium émirati TeCom-DIG.
Cette opération vise à améliorer la rentabilité de Tunisie Telecom et à lui
permettre de se hisser parmi les grands opérateurs internationaux.
- Depuis sa création, Tunisie Telecom œuvre à consolider l’infrastructure des
3
Présentation de l’organisme d’acceuil
télécoms en Tunisie, à améliorer le taux de couverture et à renforcer sa com-

pétitivité.
Elle contribue également activement à la promotion de l’usage des TIC et au
développement des sociétés innovantes dans le domaine des télécoms.
- Pionnière du secteur des télécoms en Tunisie, Tunisie Telecom a établi un
ensemble de valeurs définitoires qui place le client au centre de ses priorités.
L’adoption de ces valeurs se traduit en particulier par une amélioration conti-
nue des standards de l’entreprise et de la qualité des services.
- Tunisie Telecom compte dans ses rangs plus de 6 millions abonnés dans la
téléphonie fixe et mobile.
- Tunisie Telecom se compose de 24 directions régionales, de 140 Espaces TT
et points de vente et de plus de 13 mille points de vente privés.
Elle emploie plus de 6000 agents.
NOTRE VISION
Simplifier le quotidien de tous les Tunisiens en accélérant l’adoption du
très haut débit et la transformation digitale de la société tunisienne.
NOTRE MISSION
Etre le premier choix de connectivité pour les ménages, les jeunes et
les entreprises. Nous nous engageons à offrir une meilleure vie connectée à
tous et partout en Tunisie en apportant une expérience utilisateur attrayante,
simple et instantanée.
NOS VALEURS
« FREE sont nos valeurs : Faire simple, Responsabilité, Esprit d’équipe,
Engagement »
FAIRE SIMPLE
• Réfléchir et agir de manière à simplifier les processus et agir plus
rapidement et efficacement.
• C’est le moyen de s’adapter à cet environnement complexe poussé par
l’accélération du digital et adopter une posture Agile.
• Faire simple veut dire aussi éliminer toute tâche inutile et sans valeur
ajoutée.
4
RESPONSABILITÉ
• La capacité à percevoir les frontières : Qu’est-ce qui m’appartient
vs qu’est ce qui appartient à l’autre. Ne pas faire supporter aux autres les
conséquences de ses décisions.
• La capacité à percevoir les relations de cause/effet : Assumer les consé-
quences de ses actes. Apprendre des ses erreurs.
ESPRIT D’ÉQUIPE
• La capacité à travailler efficacement au sein d’un groupe tout en gar-
dant un fort sentiment d’appartenance et de loyauté vis à vis de l’entreprise.
• Une personne qui a un fort esprit d’équipe, passe l’intérêt collectif avant
son intérêt personnel car elle est consciente que son évolution professionnelle
dépend du succès de l’entreprise. ENGAGEMENT
• La faculté d’une personne à donner le meilleur d’elle-même pour donner
satisfaction dans son travail.
• L’assiduité dans son travail et un haut niveau de fiabilité dans l’atteinte
des objectifs tant sur plan quantitatif que qualitatif.
• Les délais sont toujours respectés et on est capable de faire preuve d’ini-
tiative pour dépasser les imprévus et obstacles.
NOS ÉTAPES CLÉS

• 17 Avril 1995
Promulgation de la loi N°36 portant création de l’Office National des Télé-
communications, dénommé Tunisie Télécom.
• 1er Janvier 1996

Mise en place de l’Office National des Télécommunications.
• 20 Mars 1998
Inauguration de la première ligne GSM.
• Décembre 1999 Promulgation du décret N°2844 du 27 décembre 1999, re-
latif au statut de Tunisie Télécom.
• 17 Mai 2000
Attribution de la première licence de téléphonie mobile en Mauritanie au
5
consortium Mattel (détenue à 51

• Fin 2002
Restructuration de Tunisie Télécom en Société Anonyme.
• 07 Juillet 2004
Signature de la convention d’interconnexion entre Tunisie Télécom et Oras-
com Télécom Tunisie.
• 09 Juillet 2004
Premier Conseil d’Administration de la Société Nationale des Télécommuni-
cations suite à la transformation de Tunisie Télécom en Société Anonyme.
• 27 Avril 2006
Tecom Dubai partenaire stratégique de Tunisie Télécom Signature du contrat
de cession de 35% de son capital pour le montant de 3,05 milliards de dinars
soit un montant de 2,25 milliards de dollars.
Figure 1.1 – Logo "Tunsie Telecom"
6
Présenation du projet
1.1.2 Organigramme de "Tunisie Telecom"

L’organigramme ci-dessous décrit la structure organisationnelle de la
société "Tunisia Telecom". Nous sommes accueillis durant notre stage dans
la Direction centrale Commerciale et Marketing.
Figure 1.2 – Organigramme de "Tunsie Telecom"
1.2 Présenation du projet

1.2.1 Description du projet
Notre mémoire s’inscrit dans le contexte d’une solution BI au sein de
direction centrale commercial et marketing de l’entreprise « Tunisie Telecom
». Il consiste à mettre en place un tableau de bord de performance à partir
d’une source de données dynamique, en le boostant via une analyse prédic-
tive pour un meilleur processus décisionnel.
7
Critique de l’existant
1.2.2 Objectifs du projet

L’objectif du projet consiste à concevoir et mettre en place un tableau
de bord de performance qui permet à la société de mieux trouver des réponses
aux questions liées aux données. Elle leur permet de prendre des décisions
plus éclairées en présentant des données historiques, actuelles et prévisionnel
dans leur contexte commercial.
1. Intégration des données.
2. Centralisation des données.
3. Analyse des données.
4. Création des mesures.
5. Identification des kPI.
6. Analyse prédictive.
7. Comparaison entre la situation actuelle et de la situation prévisionnelle.
8. Visualisation des données.
9. Machine Learning
1.3 Critique de l’existant

Face aux imprévus et rythme accéléré dans lequel nous vivons aujour-
d’hui, les décideurs sont toujours à la recherche d’outils qui leur permettent
de bien gérer les activités de leurs entreprises. La problématique de notre
direction commerciale et marketing au sein de Tunisie Telecom se pose dans
la gestion et suivi des activités.En effet, on a calculé et remarqué un taux
d’attrition important. Par conséquent, si la société ne réagit pas d’une façon
efficace et efficiente, elle risque de perdre ses clients, ce qui risque de diminuer
son CA. Toutefois, la direction commerciale et marketing utilise Excel pour
la gestion et suivi de ses activité, une solution qui n’assure pas la collabora-
tion et présente plusieurs autres inconvénients :
1. Ce n’est pas un outil assez dynamique.
2. Ce n’est l’outil qui assure un bon suivi.
3. Ce n’est pas un outil assez interactif.
4. Ce n’est pas le mieux sécurisé.
5. La durée de collecte de données pose souvent problème avec un tableur
Excel etc.
Tous ces problèmes causent une baisse de rentabilité pour la société.
8
Solution proposée
1.4 Solution proposée

Le but de la solution BI est d’apporter une vision globale des données
de l’entreprise, afin de répondre aux problématiques de celle-ci ou, tout sim-
plement, afin de l’évaluer. Pour y arriver, POWER BI permet d’analyse et
de visualisation des données.
Objectif : Faciliter la prise de décision à travers la visualisation d’insights à
partir des données.
Il permet :
- Intégration et transformation de données
- Permet une modélisation de données
- Création de rapports visuels et interactifs
- Partage des tableaux de bord
- Gagner du temps.
- Avec utilisation de machine Learning qui permet de développer, de tester et
d’appliquer des algorithmes d’analyse prédictive sur différents types de don-
nées afin de prédire le futur. En automatisant le développement du modèle
analytique, il permet d’accélérer l’analyse de données et de la rendre plus
précise.
En plus des informations détaillées ci-dessus la solution doit offrir une

analyse et une interprétation sélective, contrairement à un tableur, lors de la
diffusion ou restitution des données analysées, elle doit collecter les données
dans un meilleur délai et sans risque de perte de données.
1.5 L’informatique décisionnelle

1.5.1 Défintion et objectifs
Le terme Business Intelligence (BI) désigne les technologies, applica-
tions et pratiques de collecte, d’intégration, d’analyse et de présentation
de l’information. L’objectif de la Business Intelligence est de soutenir une
meilleure prise de décision des verticales métiers, commerciale, marketing,
finance. Essentiellement, les systèmes de Business Intelligence sont des sys-
tèmes d’aide à la décision axés sur les données.
Quelle est la place de la Business Intelligence dans une entreprise ?

[5]
La Business Intelligence (BI) est un processus technologique d’analyse
des données et de présentation d’informations pour aider les dirigeants, ma-
9
L’informatique décisionnelle
nagers et autres utilisateurs finaux de l’entreprise à prendre des décisions

business éclairées.
La Business Intelligence englobe une grande variété d’outils, d’applications et
de méthodologies qui permettent aux organisations de collecter des données
à partir de systèmes internes et de sources externes. Ces données sont ensuite
préparées pour l’analyse afin de créer des rapports, tableaux de bord et et
autres outils de de Data Viz pour rendre les résultats analytiques disponibles
aux décideurs et aux opérations.
Aujourd’hui, les entreprises s’appuient sur les logiciels de Business In-

telligence pour identifier et extraire des informations précieuses des grands
volumes de données qu’elles stockent.
Ces outils permettent d’en tirer des informations tels que des veilles concur-
rentielles et les tendances du marché, ainsi que des informations internes tel
que trouver les raisons des opportunités perdues.
Au cours des dernières années, la Business
L’influence de la BI sur les métiers du contrôle de gestion [7]

Les outils de BI apportent un gain de temps d’extraction, de collecte,
de gestion ou de consolidation des données. Les tâches les plus chronophages
du contrôle de gestion sont alors allégées.
Aussi, l’émergence des nouveaux outils de BI soulève des questionnements
quant aux évolutions des professions de la finance, et en particulier du mé-
tier de contrôleur de gestion.
- La digitalisation (ou transformation digitale).
- Fiabilité des données.
- Un gain de temps considérable.
10
1.5.2 Architecture générale
Figure 1.3 – Architecture Décisionnelle
Data Warehouse
Un Data Warehouse est une base de données relationnelle hébergée sur
un serveur dans un Data Center ou dans le Cloud. Il recueille des données
de sources variées et hétérogènes dans le but principal de soutenir l’analyse
et faciliter le processus de prise de décision.
En matière d’intégration dans le système de données existant, le fonctionne-
ment du Data Warehouse est basé sur le processus ETL (Extract, Tranform,
Load) permettant de charger les données issues des différentes applications.
[3]
Data Mart
Un Data Mart est une forme simple de Data Warehouse centré sur un
seul sujet ou fonction, comme les ventes, le marketing ou la finance. Ils per-
mettent d’améliorer le temps de réponse des utilisateurs grâce au catalogage
des données spécifiques.
Un datamart est un sous-ensemble d’un entrepôt de données destiné à fournir
des données aux utilisateurs, et souvent spécialisé vers un groupe ou un type
d’affaire.[24]
11
ETL
ETL signifie Extract, Transform Load en anglais. Cet outil permet d’ex-
traire des informations issues de différentes sources, les transformer, pour
ensuite les charger dans un entrepôt de donnés cible.
- L’extraction consiste à collecter des données brutes des différentes database
via des connecteurs.
- La transformation consiste ensuite à convertir les données extraites dans un
format standard. Cette étape permet de nettoyer, vérifier, enrichir et conso-
lider les données.
- Après formatage, elles sont transférées vers un emplacement défini comme
un data warehouse ou une application de business intelligence. C’est la phase
de chargement des données.
OLAP
Le OLAP, ou Online Analytical Processing, est une technologie de trai-
tement informatique (computer processing). Elle permet à un utilisateur de
consulter et d’extraire facilement les données pour les comparer de différentes
façons.
C’est un outil inscrit dans analysis services d’aide à la décision bien pratique
pour une entreprise. Les données OLAP sont stockées sur une base multidi-
mensionnelle, aussi appelées Cubes OLAP, pour faciliter ce type d’analyses.
Un serveur OLAP est nécessaire.[9]
Restitution
Cette dernière étape, également appelée reporting, se charge de présen-
ter les informations à valeur ajoutée de telle sorte qu’elles apparaissent de la
façon la plus lisible possible dans le cadre de l’aide à la décision.
KPI
Un KPI est un indicateur de performance pour votre entreprise. Cet
indicateur est donc chiffré et permet de suivre l’efficacité d’une action par
rapport à des objectifs définis.
12
Machine Learning
Le machine learning est une technique de programmation informatique
qui utilise des probabilités statistiques pour donner aux ordinateurs la ca-
pacité d’apprendre par eux-mêmes sans programmation explicite. L’ objectif
de base du machine learning est "d’apprendre à apprendre" aux ordinateurs
– et par la suite, à agir et réagir – comme le font les humains, en améliorant
leur mode d’apprentissage et leurs connaissances de façon autonome sur la
durée. L’objectif ultime serait que les ordinateurs agissent et réagissent sans
être explicitement programmés pour ces actions et réactions. [20]
1.5.3 Modélisation d’une base donnée multidimension-

nelle
Table de fait
Une table de fait n’est rien d’autre qu’un collectivement de données
structurées, constitué de champs de type dimension (le contexte) et champs
de type mesure (les faits). Un processus des sociétés peut être indiqué grace
d’une ou plusieurs tables de fait.
Table de Dimension
Une table de dimensions comporter les axes de l’analyse (les dimen-
sions) ; à travers lesquels nous permettions d’étudier les données observables
(les faits) docile à des analyses multidimensionnelles, qui produisaient aux
utilisateurs les informations requises au processus de prise de décision.
Il existe 3 modèles dans la conception multidimensionnelle :
Modèle en étoile
- Une (ou plusieurs) table(s) de faits comprenant une ou plusieurs me-
sures
- Plusieurs tables de dimension dé-normalisées : descripteurs des dimensions.
- Les tables de dimension n’ont pas de lien entre elles.
* Avantages
- Facilité de navigation.
- Performances : nombre de jointures limité ; gestion des données creuses.
13
-Gestion des agrégats

* Inconvénients
- Redondances dans les dimensions.
- Alimentation complexe..
Figure 1.4 – Schéma de Modéle en etoile
Modèle en flocon de neige

- Modèle en étoile + normalisation des dimensions
- Utilisé lorsque les tables sont très volumineuses
* Avantages
- Réduction du volume
- Permettre des analyses par pallier (drill down) sur la dimension hiérarchisée
* Inconvénients
- Navigation difficile
- Nombreuses jointures
14
Figure 1.5 – Schéma de Modèle en flocon de neige
Modèle en constellation
Fusionner plusieurs modèles en étoile qui utilisent des dimensions com-
munes
* Un modèle en constellation comprend donc :
- Plusieurs tables de faits
- Des tables de dimensions communes ou non à ces tables de faits.
15
Méthodologie de travail
Figure 1.6 – Schéma de Modèle en constellation
1.6 Méthodologie de travail

Dans cette étape, nous allons définir et justifier le choix de la méthodo-
logie de conception et le Framework que nous allons utiliser pour la gestion,
planification ainsi que le découpage de ce projet.
1.6.1 Méthodologie choisie agile

Après avoir effectué des études et des recherches sur les méthodologies
de conception, nous avons choisi la méthodologie de conception AGILE.
Explication du choix
Nous nous sommes mis d’accord avec team de travail sur la méthode
AGILE de gestion de projets car ces modes sont loin de prédire et de tolérer
strictement les modifications. Elles n’obligez pas de documentation détaillée
et éprouvée. , Ils s’adaptent aux transformations et adoptent des processus
itératifs et incrémentaux.
1.6.2 Scrum
Après une bonne étude, nous avons décidé d’associer Scrum comme fra-
mework à AGILE.
Nous allons dans cette partie justifier le choix de SCRUM tout en expliquant
son cycle de vie et ses intervenants.
16
Définition
SSCRUM, c’est un terme anglais qui informé mêlé. C’est un Framework
de gestion de projets liés aux méthodes agiles, il est utilisé en développement
logiciel. Il autorise de créer des logiciels dans une petite durée. Une partie
du logiciel fonctionnel est produite à chaque sprint. Les sprints sont des
itérations d’une durée de 2 à 4. Durant les sprints, nous allons élaborer,
coder et vérifier la partie envisagée du logiciel qu’on peut remettre si elle est
bien fonctionnelle.
La figure 1.7 ci-dessous illustre le processus Scrum.
Figure 1.7 – Scrum
Répartition des rôles dans le framework Scrum

Comme pour toute méthode Agile, team Scrum est auto-organisé et
pluridisciplinaire. Elle sélectionne la meilleure façon d’accomplir son travail
et possède toutes les compétences requises à l’accomplissement du projet. La
flexibilité, l’inventivité et le rendement de l’équipe sont ainsi optimisés.
L’équipe Scrum se constituer en outre de :
• un Scrum Master, qui traité le rôle de coach pour les équipes de dévelop-
pement .
• un Product Owner, ou “propriétaire du produit” en français, assimilable
au chef de projet .
• une équipe de développement.
17
Le Sprint
Un sprint est une itération. Il s’agit d’une période de 1 à 4 semaines
plus grand au cours de laquelle une version terminée et utilisable du produit
est réalisée. Un nouveau Sprint débuté dès la fin du précédé. Chaque Sprint
participé un but et une liste de fonctionnalités à exécuter.
Planification d’un Sprint

Les tâches à accomplir pendant le sprint sont déterminées par collecti-
vement de l’équipe Scrum lors du meeting de planification du sprint. Celle-ci
se limite à 8 heures pour les sprints d’un mois. Elle offrir à l’équipe d’établir
les difficultés qu’elle va traiter au cours de ce sprint.
Revue du Sprint
Il s’agit du bilan du sprint effectué. Une fois le sprint achevé, l’équipe
Scrum et les parties prenantes se rassembler pour valider ce qui a été accom-
pli. Cette réunion dure 4 heures maximum.
L’équipe se sert de la rétrospective pour passer en revue le sprint ter-

miné et déterminer ce qui a bien fonctionné et ce qu’il faut progresser.
Mêlée quotidienne
Ce meeting journalier de 15 minutes est très primordial. Elle se fait de-
bout, afin d’éviter de s’éterniser. C’est ce qui précisé que l’on parle de “stand
Up meeting”. Ce meeting a pour but de faire un point sur la progression
quotidienne du sprint. Ce rendez-vous permet à team de synchroniser ses
activités et de faire un plan pour les suivants 24 heures.
À mêlée a lieu à la même heure et au même endroit chaque jour. Chaque
membre de team de développement doit répondre à ces trois questions :
• qu’est-ce qu’il a réalisé la veille ?
• Qu’est-ce qu’il va réaliser aujourd’hui ?
• Quelles sont les difficultés qui le retardent ?
18
Conclusion
1.7 Conclusion
Le premier chapitre concentré à placer le projet dans son contexte gé-
néral et comprendre le cadre dans lequel il circule. Cela nous permet de bien
englober les besoins et adopter la méthode de conception pour finir par déve-
lopper une solution BI qui répond complètement aux nécessités et exigences
de l’entreprise. Après cela, nous passerons au chapitre 2, qui est consacré à
la planification, à l’architecture et à la spécification des besoins .
19
Chapitre 2
Planification et architecture
Introduction
Après avoir choisi Scrum comme étant un contexte de projet dans le
chapitre passé, nous allons soumettre la phase de planification de ce chapitre :
appelée " Sprint Zéro".
Le sprint zéro est un parti essentiel pour démarrer un projet agile, il est
essentiellement utilisé pour permettre au sprint suivant de démarrer dans
des conditions optimales. Dans le chapitre II, nous déterminer les besoins,
les participants de notre solution BI, définiront le backlog du produit et
l’architecture de travail avec le choix de technologie .
2.1 Spécification des besoins

Cette phase est essentielle pour éduquer le contexte de notre projet.elle
sert à identifier les acteurs et les fonctionnalités du système et assurer d’iden-
tifier les premiers cas d’utilisation .
20
Spécification des besoins
2.1.1 Identification des acteurs

Nous avons principalement 2 acteurs dans notre projet :
— Administrateur.
— Décideur.
Table 2.1 – Identification des acteurs de systéme

Acteur Roles
L’administrateur est le responsable de l’application.
Il a une visibilité totale sur la solution.
Parmi les principales tâches qu’il peut effectuer, nous mentionnons :
- Extraction et transformation des données.
- Modélisation des données.
Administrateur - Analyse des données.
- Visualisation des données.
- Gestion des autorisations.
- Gestion des alertes.
- Création du jeu de données.
- Analyse prédictive (Machine Learning)
Il peut s’authentifier sur notre application.
Le Décideur utilise les résultats finaux du système :
Décideur
- Consultation et modification des rapports et tableau de bord
sur Power BI afin qu’il aide à la prise de décision.
2.1.2 Diagramme de contexte statique

Le diagramme de contexte statique délimite le domaine d’étude en pré-
cisant ce qui est à la charge du système et en identifiant l’environnement
extérieur au système étudié avec lequel ce dernier communique. On repré-
sente les interactions des acteurs avec le système étudié.
Figure 2.1 – Diagramme de contexte statique
21
Spécification des besoins
2.1.3 Les besoins fonctionnels

Les besoins fonctionnels sont spécifiés par les représentants des utili-
sateurs du produit. Ils exprimer les obligations fonctionnelles que le projet
devrait faire ou plus livrer aux utilisateurs.
Notre solution BI permet de réaliser les tâches suivantes :
• Gestion des données :
- Extraction et Transformation des données.
- Modélisation des données.
- Analyse des données et création des mesures.
• Visualisation des données.
Les tableaux de bord doivent couvrir les besoins suivants :
* Suivi « Client »
- Nombre de clients.
- Nombre des client actifs.
- NB clients/région.
- Revenu total .
- NB client/mois.
- NB de jours inactifs/client.
- Prévision du revenu/mois.
* Suivi « Trafic »
- Montant total de recharge.
. - -Prévision de recharge/Mois.
-. -Nombre total de recharge.
- Montant total de ussd Data/Mois/Région/Client.
- Durée offnet total/Mois/Région/Client.
- Durée onnet total /Mois/Région/Client.
- Durée international total/Mois/Région/Client.
- Nombre sms total/Mois.
- Volume total.
- Revenu voix total.
* Suivi « Offre »
- Nombre des offres.
- Nombre des clients pour chaque offre.
- Top 10 offres/Revenus/Montants de recharge.
- Nombre des offres pour chaque type/mois.
22
Structure et découpage du projet
• Gestion des droits d’accés.

• Céation des jeux de données.
• Analyse prédictive (Machine learning).
2.1.4 Les besoins non fonctionnels

Les besoins non fonctionnels sont les exigences techniques que doit as-
surer l’application. Les besoins non fonctionnels exigés sont :
- Simplicité : Même les non-spécialistes doivent être capables de comprendre
la solution pour minimiser toute assistance technique.
- Performance : La plateforme doit être rapide, fiable et systématiquement
exécutables.
- Évolutivité : Possibilité d’ajout de nouveaux modules ou de nouveaux axes
d’analyse aux modules existants.
- Sécurité : Il est nécessaire de garantir un accès complet et sûr à chaque
espace à partir des emplacements suivants : par nom d’utilisateur et mot de
passe.
- Disponibilité : Le système doit toujours être disponible pour les utilisateurs.
Les besoins fonctionnels et non fonctionnels du système seront fournis par les
outils techniques que nous utilisons pour développer notre solution BI que
nous expliquerons à la fin de l’étape, ce dont chaque personne a besoin et
quels outils sont nécessaires.
2.2 Structure et découpage du projet

2.2.1 Pilotage du projet par Scrum
On a mentionné dans le chapitre antécédent que nous allons gérer le
projet par le Framework Scrum. L’équipe scrum est composée de :
— Mr.Mohamed Jarbaoui, le scrum Master
— Tunisie Telecom est le product owner.
— Ghassen Salhi , Team Member.
23
2.2.2 Le backlog du produit

Le backlog du produit est créé avant le début du sprint suite, précisé-
ment à l’étape du sprint zéro. c’est un maillon de la gestion des exigences,
parce que recueille les fonctions que l’application doit exécuter. Pour chaque
user story, nous devons imputer une priorité et une complexité d’implémen-
tation.
Table 2.2 – Backlog du produit

id Co-
Thème User Description Priorité mpl-
Story exité
En tant qu’administrateur, je peux
Extraction et 1.1 Elevée 1/2 jour
extraire les données.
Transformation
En tant qu’ administrateur,
des données
1.2 je peux modifier,transformer Elevée 9 jours
et nettoyer les données.
choisir le modèle multidimensionnel
2.1 des données et établir des relations Elevée 8 jours
Modélisation des entre les dimensions.
données. .
analyser les données avec
3.1 la langage DAX. Elevée 10 jour
Analyse des
données
créer,ajouter,modifier et supprimer
4.1 Elevée 9 jours
l’interface client.
Suivi Client
.
En tant que décideur je peux
4.2 modifier et suivre l’interface client. Elevée

créer,ajouter,modifier
5.1 Elevée 9 jours
et supprimer l’interface trafic.
Suivi Trafic
5.2 modifier et suivre l’interface trafic. Elevée
24

créer,ajouter,modifier
6.1 Moyenne 5 jours
et supprimer l’interface offre.
Suivi Offre
En tant qu’administrateur
ou décideur je peux modifier
6.2 Moyenne
et suivre l’interface offre.

gérer les autorisations pour
7.1 Moyenne 6 jours
Gérer les interfaces.
les autorisations
8.1 créer les alertes . Elevée 7 jours
Gérer les alertes
8.2 consulter les alertes. Elevée
En tant qu’administrateur,
je peux créer le jeu de données
9.1 Moyenne 8 jours
Créer le jeu avec POWER BI SERVICE.
des données
Analyse prédictive faire des analyses prédective avec
10.1 Moyenne 14 jours
(Machine Learning)_ la langage python.
En tant que décideur

10.2 je peux consulter les analyses Moyenne
25
Jira
Jira est un système de contrôle de bugs, de gestion des incidents et de
conduite de projets développés par Atlassian et publiée pour la première fois
en 2002.
Il offrit des solutions à la fois à chemin des développeurs et des intervenants
non développeurs. Dans Jira Software, les projets Scrum et Kanban conte-
naient différentes fonctionnalités pour faciliter les équipes utilisant l’un ou
l’autre.Pour les équipes Scrum :
sélectionnez Backlog dans le menu de projet sur la gauche, puis appuyez sur
+ Créer un ticket pour commencer à ajouter du travail au backlog de votre
équipe.
La figure 2.2 illustre le backlog du produit sur le systéme des gestions

des projets « Jira » .
Figure 2.2 – Backlog du produit sur Jira
26
2.2.3 Planification des sprints

Après avoir terminé le Backlog produit nous avons organisé une réunion
avec toute l’équipe pour planifier les sprints. Cette réunion nous permet
d’identifier les exigences jugées nécessaires dans la liste du travail. Cela nous
permet également de valider nos estimations de paramètres de priorité.
Figure 2.3 – Planification des sprints
27
Diagramme de cas d’utilisation global
2.3 Diagramme de cas d’utilisation global

La figure 2.4 illustre le diagramme de cas d’utilisation global du projet.
Figure 2.4 – Diagramme des cas d’utilisation global
2.4 Prototypage des interfaces

Avant de réaliser le projet, il est bien d’avoir des idées sur les interfaces
de l’application et de leur compostions, pour modéliser les interfaces, nous
avons utilisé l’application « JustInMind ».
28
Prototypage des interfaces
La figure 2.6 illustre la maquette de l’interface CLIENT.
Figure 2.5 – Maquette-Client
La figure 2.7 illustre la maquette de l’interface TRAFIC .
Figure 2.6 – Maquette-Trafic
29
Architecture de travail
La figure 2.8 illustre la maquette de l’interface OFFRE.
Figure 2.7 – Maquette-Offre
2.5 Architecture de travail

• La conception des données débutées par une implantation sur site de
Power BI Desktop (rédacteur de requêtes intégré, vues relationnelles, don-
nées et rapports), qui faculté intégrait divers sources de données (local ou
dans le cloud) et éditait des données et des connexions sur le cloud indiqué
le service Power BI.
• Mise à jour des données est réalisable, soit en local (avec Power BI Desk-
top), ou bien en cloud (avec Power BI Service).
• La visualisation des données : les consommateurs finaux permettre de vi-
sualiser les rapports et tableaux de bord sur divers supports (mobiles, lien
web, etc.).
Avant de commencer les ouvrages de conception, une prise en compte de
construction de Power BI est essentielle. Celle-ci possède deux interfaces :
• Celle de l’éditeur de requête qui offre d’importer et de formater les don-
nées, suivant le processus de l’ETL (Extract, Transform, Load) aide à son
langage M.
• Celle de la vue des données puis chargement dans le modèle, qui elle-même
assuraient d’accéder à trois zones de travail ou vues :
. Une vue relationnelle illustrant toutes les tables, colonnes et relations du
modèle.
. La vue Donnée qui admettre d’examiner les données et d’ajouter des champs
calculés complémentaires aide au langage DAX.
. La vue Rapports qui permet d’établir un nombre considérable de pages de
30
Choix technologique
rapport avec des visualisations.
Figure 2.8 – Architecture de travail
2.6 Choix technologique

- La solution BI sera créée avec Power bi desktop ,Power BI service,
Power Query,Power automate, et la language dax .
- L’Analyse prédictive sera créée avec la language python et google colab.
- La solution BI doit être compatible avec tous les navigateurs et les supports
mobiles.
2.7 Conclusion
Ce chapitre est consacré à l’élaboration d’un plan de travail pour le
projet. Premièrement, nous énumérons les besoins fonctionnels et non fonc-
tionnels, les acteurs du système de la solution. Nous avons aussi élaboré
l’environnement de travail afin d’arriver à développer la table backlog de
produit. Dans le prochain chapitre, nous démarrer le premier sprint de notre
travail.
31
Chapitre 3
SPRINT1 : GESTION DES

DONNÉES
Introduction
Nous utiliserons ce chapitre pour matérialiser certaines des fonctionna-
lités d’un sprint, suivi de l’analyse, de la conception et enfin de la mise en
œuvre de la première partie du produit susceptible d’être livrée dans un délai
précis.
3.1 Backlog du sprint

Le sprint backlog, c’est la liste de l’ensemble des tickets à réaliser tout
au long du sprint afin d’être en mesure de livrer l’incrément à la fin de celui-
ci. Ces éléments en sujet proviennent du product backlog qui a été fabriqué
en amont, à sur le plan du projet Scrum.
Figure 3.1 – Backlog du sprint 1
32
Spécification fonctionnelle
3.2 Spécification fonctionnelle

Dans cette section, nous définirons les cas d’utilisation correspondant à
chaque acteur. Ensuite, nous construirons le diagramme de cas d’utilisation
pour le premier sprint.
3.2.1 Classification des cas d’utilisation par acteur
Le tableau 3.1 présente la classification des cas d’utilisation par acteur.
Table 3.1 – Classification des cas d’utilisation- sprint1

Acteur Cas d’utilisation
Extraire et Transformer les données.
Administrateur Modélisation des données.
Analyse des données
3.2.2 Diagramme de cas d’utilisation

Il est important de créer des diagrammes de cas d’utilisation à ce niveau
afin que le système puisse avoir une vue externe et identifier les possibilités
d’interactions entre le système et les acteurs.
La figure 3.2 illustre le diagramme de cas d’utilisation du sprint1.
Figure 3.2 – Diagramme de cas d’utilisation - Sprint1
33
Extraction et Trasformation des données
3.3 Extraction et Trasformation des données

3.3.1 Extraction des données
Accès à la majorité des systèmes de stockage de données (SGBD, ERP,
fichiers plats, etc.) pour rétablir les données identifiées et sélectionnées. Te-
nez compte de la synchronisation et de la périodicité de rafraîchissement.
Nous allons dans cette partie Extraire les données de notre solution BI.
Il s’agit de collecter des données brutes des différentes source des données
puis importer dans notre outil de travail Power BI .
Nous allons utiliser un fichier texte présentant un échantillon de données

qui décrit les trafics,les clients et les offres sur 6 mois.
La figure 3.3 illustre le fichier de source des données.
Figure 3.3 – échantillons des données
34
Nous avons obtenu les données de type texte puis on a chargé et trans-
formé dans Power query où on a fait les transformations des données.
La figure 3.4 illustre l’importation de données sur Power BI desktop et

le chargement dans Power query pour les transformer
Figure 3.4 – Importation les données dans Power BI
35
3.3.2 Tranformation des données

La transformation comportée ensuite à changer les données extraites
dans un format standard. Cette étape autorisait de nettoyer, vérifier, enrichir
et consolider les données.
Donc le nettoyage des données se fait sur power query où on a procédé à la
transformation avec le langage M et de ses fonctionnalités
La figure 3.5 illustre les étapes appliquées pour le nettoyage et le tran-
formations des données pour chaque table. Nous avons :
- Changer tous les types des colonnes.
- Supprimer les valeurs nulles,les espaces et les erreurs non nécessaires à l’ana-
lyse.
- Remplacer des valeurs.
- Utiliser la permière ligne pour les entêtes.
- Dupliquer la table fct et créer les autres tables.
- Fractionner les colonnes.
- Ajouter des colonnes personnalisées.
Figure 3.5 – Etape appliquées
36
Modélisation des données
3.4 Modélisation des données

La modélisation multidimensionnelle focalisée donc à considérer les don-
nées à analyser. On parle de thèmes analysés comme un point dans un espace
à multiples dimensions.
Les données sont ainsi organisées de telle sorte que le sujet étudié et les axes
d’analyse soient mis en évidence.
le tableau 3.2 illustre notre structure de table de fait
37
Table 3.2 – Table de fait «FCT»

Champs Types Contraintes Description
désigne la clé étrangère
id_client Texte Clé de subtitution
de table client
offre Texte Clé de subtitution
de table Offre
Mois Date Clé de subtitution
de table Date
Région Texte Clé de subtitution
de table Région
anc Nombre entier Clé de subtitution
de table an
actife_trafic Texte Clé de subtitution
de table Trafic
désigne le volume
Volume_tot Nombre décimal Mesure
de capacité Data total
Revenu_tot Nombre décimal Mesure désigne le revenu total
désigne le revenu total
Ussd_data Nombre décimal Mesure
des forfaits DATA
désigne le revenu
Ussd_tot Nombre décimal Mesure
total des forfaits
désigne le revenu voix
rev_voix Nombre décimal Mesure
total
désigne le nombre de
Nbr_jt_inac Nombre entier Mesure
jours inactifs des clients
désigne le nombre
nb_SMS Nombre entier Mesure
des SMS
désigne le nombre
nbr_appel Nombre entier Mesure
des appels
désigne la durée des
Dureé_onnet Nombre décimal Mesure
appels à Tunisie telecom
désigne la durée des
Duree_offnet Nombre décimal Mesure
appels hors de Tunsie telecom
désigne la durée
Duree_inter Nombre décimal Mesure
des appels internationnal
désigne la durée totale
Durée_tot Nombre décimal Mesure
des appels
désigne le montant
Mnt_rech Nombre décimal Mesure
de recharge
désigne le nombre
Nbr_rech Nombre décimal Mesure
de recharge
désigne la classification
Split_nbr_jt_inac Nombre entier 38 Mesure
des clients
le tableau 3.3 illustre notre structure de table Offre
Table 3.3 – Table Offre

offre Texte Clé de subtitution désigne le nom des offres
Type_offre Texte Attribut désigne le type des offres
le tableau 3.4 illustre notre structure de table Client
Table 3.4 – Table Client

id_CLIENT Texte Clé de subtitution désigne ID de client
le tableau 3.5 illustre notre structure de table Région
Table 3.5 – Table Région

région Texte Clé de subtitution désigne les noms des régions
le tableau 3.6 illustre notre structure de table Anc
Table 3.6 – Table Anc

anc Texte Clé de subtitution désigne l’ancienneté des clients
le tableau 3.7 illustre notre structure de table Date
Table 3.7 – Table Date

Mois Texte Clé de subtitution désigne le numéro de mois
39
3.4.1 Les relations entre les tables

Power BI Desktop cherchait à obtenir des liens entre les tables afin
d’établir des relations.
Lors de ce type de création du lieu les cardinalités, la direction et le fait que
la relation soit active ou non est gérée automatiquement.
Les relations créées de cette manière peuvent être modifiées manuellement.
Au sein de notre projet, nous avons 8 relations :
-Relation un à plusieurs entre CLient et FCT
-Relation un à plusieurs entre Offre et FCT
-Relation un à plusieurs entre Trafic et FCT
-Relation un à plusieurs entre Handset et FCT
-Relation un à plusieurs entre Date et FCT
-Relation un à plusieurs entre Anc et FCT
-Relation un à plusieurs entre Région et Client
-Relation un à plusieurs entre Anc et Client
Figure 3.6 – les Relations entre les dimensions
40
3.4.2 Schéma en étoile

Lors de la phase de modélisation, notre but est d’élaborer un modèle
de données adaptées aux besoins de notre solution BI et d’avoir un schéma
en étoile basé sur les avantages précédemment cités.
La figure 3.6 illustre le Schéma en étoile sur Power BI Desktop
Figure 3.7 – Schéma en étoile de Power Bi
3.5 Analyse des données

L’analyse est le processus qui concentrait à décomposer un sujet ou un
contenu difficile en éléments plus petits afin de davantage le comprendre. test
des données demande généralement des compétences statistiques avancées.
Pourtant certaines solutions arrêtaient ces fonctionnalités pré-paramétrées à
des cas de figure bien définie, afin d’offrir leurs prix ajoutés à des personnes
opérationnelles.
Dans cette partie on analyse notre donnée avec la création et l’identification
des mesures et KPIs en utilisant la langage DAX pour avoir une vision glo-
bale et claire sur notre donnée et aider le décideur à prendre une meilleure
décision.
Ci-dessous on a pu énumérer quelques mesures de notre solution éditer sur
41
Power Bi :
Durée internationale totale
Figure 3.8 – Requête DAX
Durée offnet totale
Montant total de USSD data
Nombre des client par région
Nombre des client pour chaque offre
42
Top 10 client
Top 3 offre
Ancienneté pour chaque client
Nombre des client
43
Sprint terminé
3.6 Sprint terminé

La figure 3.13 montre la fin du sprint1, tous les tickets de sprint sont
complétés.
Figure 3.17 – Sprint Terminer sur Jira
3.7 Conclusion
Nous avons à la clôture de ce chapitre, une première partie exploitable
du projet. Le chapitre suivant décrire la réalisation du sprint 2 intitulés :
Visualisations des données.
44
Chapitre 4
SPRINT2 : VISUALISATIONS
DES DONNÉES
Introduction
Dans le chapitre précédé, nous avons fini la partie la plus importante
du projet, celle qui nous autoriser de démarrer les sprints suivants. Tout au
long de ce chapitre nous allons travailler sur la troisième partie du projet. Il
s’agit de la partie chargée de la visualisation des données.
4.1 Sprint Backlog

Le figure 4.1 ci-dessous représente le backlog de notre deuxième sprint.
45

Dans notre projet, la spécification fonctionnelle s’illustre par le dia-
gramme de cas d’utilisation raffiné et la description textuelle de ces fonction-
nalités.
4.2.1 Classification de cas d’utilisation par acteur

Table 4.1 – Classification des cas d’utilisation sprint 2
Administrateur Gérer le tableau de bord
Décideur Consulter le tableau de bord

Gérer le tableau de bord ,client, trafic et l’offre effectués par l’adminis-
trateur quant au décideur, il va hériter les mêmes fonctionnalités. Les détails
sont illustrés par la figure 4.2 ci-dessous.
Figure 4.2 – Diagramme de cas d’utilisation -Sprint2
46
4.2.3 Raffinement des cas d’utilisation

Nous allons dans ce segment établir le raffinement des cas d’utilisation
du deuxième sprint.
Cas d’utilisation "Gérer client"
La consultation des clients et de leurs données personnelles n’autorisées
être réalisée que par l’administrateur et le décideur. Nous avons donc assigné
l’administrateur système et le décideur en tant qu’acteur dans les tableaux
incluant les descriptions textuelles et les diagrammes de cas d’utilisation
Gérer client.
Figure 4.3 – Raffinement du cas d’utilisation "gérer client"
Cas d’utilisation "Gérer Trafic"

La Consultation des trafics et de leurs données personnelles n’autorisées
être réalisée que par l’Administrateur et le décideur. Nous avons donc assigné
Gérer Trafic.
47
Figure 4.4 – Raffinement du cas d’utilisation "gérer Trafic"
Cas d’utilisation "Gérer Offre"

La Consultation des Offres et de leurs données personnelles n’autorisées
être réalisée que par l’Administrateur et le décideur. Nous avons donc assigné
Gérer Offre.
Figure 4.5 – Raffinement du cas d’utilisation "gérer Offre"
48
4.2.4 Description textuelle des cas d’utilisation

Nous allons dans cette section présenter les descriptions textuelles des
cas du sprint.
Description textuelle du cas "Gérer client"
Table 4.2 – Description textuelle du cas "Gérer client"

Cas d’utulisation Gérer client
Acteur Administrateur
Pré-condition Administrateur authentifié
Post-Condition Dashboard client affiché.
1/L’Administrateur appuie sur le bouton client
Scénario principal dans le Dashboard.
2/Le système affiche l’onglet client.
Description textuelle du cas "Gérer Trafic"
Table 4.3 – Description textuelle du cas "Gérer Trafic"

Cas d’utulisation Gérer Trafic
Post-Condition Dashboard Trafic affiché.
1/L’Administrateur appuie sur le bouton Trafic
2/Le système affiche l’onglet Trafic.
Description textuelle du cas "Gérer Offre"
Table 4.4 – Description textuelle du cas "Gérer Offre"

Cas d’utulisation gérer Offre
Post-Condition Dashboard Offre affiché.
1/L’Administrateur appuie sur l bouton Offre
2/Le système affiche l’onglet Offre.
49
Implémentation des Dashboard
4.3 Implémentation des Dashboard

Le tableau de bord est un outil de pilotage d’une entreprise constitué de
plusieurs indicateurs de performance et qui a pour essentiel objet d’anticiper
les changements probables et d’inciter le chef d’entreprise à approuver des
décisions.
Dans notre tableau de bord, nous avons tenté de répondre aux besoins fonc-
tionnels au moyen de graphiques pour qu’ils soient compréhensibles et at-
trayants.
Pour ce dernier, nous allons présenter les tableaux de bord réalisés :
50
Dashboard Client
La figure 4.6 de dashboard « Client » présente une analyse en terme :
- Un filtre sur le Mois ( Visualisation : segment).

- Un filtre sur la région ( Visualisation : segment).
- Nombre des client ( Visualisation : Carte dynamique).
- Nombre des client par région ( Visualisation : Carte et MAP dynamique).
- Nombre des jour inactife par client. Visualisation : Entonnoir).
- Prévisions du revenu pour les six prochains mois ( Visualisation : Graphique
en courbes).
- Nombre de jours inactifs par mois (Visualisation : Histogramme empilé).
Figure 4.6 – Dashboard Client
51
Dashboard Client page 2

La figure 4.7 de dashboard « Client 1 » présente une analyse en terme :

- Top 20 client/ nombre de recharge et mois ( Visualisation : Matrice).
- Nombre des clients actif ( Visualisation : Graphique en secteurs).
- Revenu/client ( Visualisation : Graphique de zone empilé).
Figure 4.7 – Dashboard Client page 2
52
Dashboard Trafic
La figure 4.8 de dashboard « Trafic » présente une analyse en terme :

- Montant total de recharge ( Visualisation : Carte dynamique).
- Nombre total de recharge ( Visualisation : Carte dynamique).
- Montant total USSD ( Visualisation : Carte dynamique).
- Monatant total de ussd data ( Visualisation : Carte dynamique).
- Prévisions de recharge pour les six prochains mois ( Visualisation : Gra-
phique en courbes).
- Montant de recharge/client (Visualisation : Histogramme empilé).
- Top 5 région/Montant ussd (Visualisation : Table).
- Montant total de recharge/région( Visualisation : MAP dynamique).
Figure 4.8 – Dashboard Trafic
53
Dashboard Trafic page 2

La figure 4.9 de dashboard « Trafic 2 » présente une analyse en terme :

- Durée Internationale totale ( Visualisation : Carte dynamique).
- Durée offnet totale ( Visualisation : Carte dynamique).
- Durée onnet totale ( Visualisation : Carte dynamique).
- Revenu voix total ( Visualisation : Carte dynamique).
- Nombre SMS total ( Visualisation : Carte dynamique).
- Durée Internationale/région ( Visualisation : Graphique en secteurs).
- Revenu data total VS Revenu voix totale/mois( Visualisation : Histo-
gramme groupé ).
- Durée offnet / mois( Visualisation : Graphique en cascade).
- Nombre sms/client( Visualisation : Graphique à barres groupées).
Figure 4.9 – Dashboard Trafic page 2
54


- Durée internationale prévue au cours des 6 prochains mois ( Visualisation :
Graphique en courbes).
- Durée offnet prévue au cours des 6 prochains mois ( Visualisation : Gra-
phique en courbes).
- Durée onnet prévue au cours des 6 prochains mois ( Visualisation : Gra-
phique en courbes).
55


- Volume total ( Visualisation : Carte dynamique).
- Durée totale ( Visualisation : Carte dynamique).
- Durée totale/région (Visualisation : Histogramme empilé).
- Nombre d’appel/ région / mois ( Visualisation : Graphique de ruban).
- Durée total prévue au cours des 6 prochains mois ( Visualisation : Gra-
phique en courbes).
- Volume total / mois ( Visualisation : Graphique en aires).
56
Dashboard Offre
La figure 4.12 de dashboard « Offre » présente une analyse en terme :

- Un filtre sur les Offres ( Visualisation : segment).
- Nombre des offres ( Visualisation : Carte dynamique et Histogramme em-
pilé).
- Nombre des client pour chaque offre ( Visualisation : Carte dynamique).
- Nombre des offres / type ( Visualisation : Graphique en anneau).
- Top 10 offre par rapport Revenu total/Montant ussd total/Montant ussda
total data/Montant total de recharge ( Visualisation : Matrice).
Figure 4.12 – Dashboard Offre
57
Sprint terminer
4.4 Sprint terminer

La figure 3.13 montre la fin du sprint 2, tous les tickets de sprint et
complétés.
Figure 4.13 – Sprint 2 Terminer sur Jira
4.5 Conclusion
A ce niveau, nous avons terminé le deuxième Sprint de la visualisation
des données. Nous passons au chapitre suivant qui décrit la troisième étape :
Analyse prédictive.
58
Chapitre 5
Sprint 3 : ANALYSE
PRÉDICTIVE
Introduction
Comme mentionné au niveau du chapitre 2, notre projet comporte 3
sprints. Le dernier chapitre décrit notre 3 ème sprint, y compris de Power BI
Service et la réalisation d’analyses prédictives.
5.1 Sprint Backlog

Le figure 5.1 illustre le backlog de notre sprint, il contient les fonction-
nalités que nous allons traiter tout au long de ce chapitre.
59

5.2.1 Classification des cas d’utilisation par acteur
Table 5.1 – Classification des cas d’utilisation- sprint 3
Gérer les autorisations .
Gérer les alertes.
Administrateur
Création les jeux de données.
Analyse prédictive.
Consulter les alertes.
Décideur
Consulter les analyses prédictives.

La figure 5.2 représente le diagramme de cas d’utilisations du sprint 3 .
Figure 5.2 – “Diagramme de cas d’utilisation -Sprint 3“
60
Gérer les autorisations
5.3 Gérer les autorisations

Tout d’abord nous avons publié le tableau de bord sur Power BI service.
Dans Power BI Service, le tableau de bord nous affiche des mosaïques, que
nous permettre choisir pour ouvrir des rapports pour une exploration plus
précise. Le tableau de bord et les rapports se lier à des ensembles de don-
nées qui rassemblait toutes les données utiles en un seul endroit.Aussi avec
la Power BI service on peut partager le tableau de bord sur le web,gérer les
autorisations, créer des jeux de données, créer des workflows, créer et gérer
des alertes...
La figure 5.3 représente la gestion des autorisations effectuées par l’ad-

ministrateur de Power BI Service .
Figure 5.3 – “Gérer les autorisations “
61
Gérer les alertes
5.4 Gérer les alertes

Lorsque les données suivies atteignent un seuil défini Power BI vérifie
s’il y a eu un dépassement d’une heure ou encore de 24 heures (selon l’option
sélectionnée) dans ce cas là une alerte est envoyée par email. Chaque alerte
contient un lien direct vers nos données.
La figure 5.4 représente la gestion des alertes qui fait par l’adminstra-
teur de Power BI service
Figure 5.4 – “Gérer les Alertes “
5.5 Jeu de données

Les jeux de données Power BI décrivait une source de données prêtes
pour la mise en place de rapports et la visualisation après la transformation
des données. Il existe cinq types de jeux de données différents, dans notre cas
chargement d’un fichier txt (valeurs séparées par des virgules).
62
Jeu de données
La figure 5.5 représente la traçabilité du jeu de données .
Figure 5.5 – “Traçabilité du jeu de données “
5.5.1 Actualisation du jeu de données

Power BI vous autoriser de changer rapidement les données en infor-
mations et en actions, mais vous devez vous assurer que les données de notre
tableau de bord et rapports Power BI sont à jour afin d’obtenir des résultats
clairs, il est souvent besoin de comprendre la procédure d’actualisation des
données.
La figure 5.5 représente l’actualisation du jeu de données par la méthode

de Power automate qui crée des flux des données entre (la source des données,
jeu de données, Power BI service, Power BI desktop).
Figure 5.6 – “Actualisation du jeu de données “
63
Analyse prédictive (Machine Learning)
5.6 Analyse prédictive (Machine Learning)

L’analyse prédictive est application des données, d’algorithmes statis-
tiques et de techniques machine learning pour prédire les résultats futurs
probables en fonction des données mémorables. But est d’extrapoler à partir
des événements survenus pour mieux anticiper les événements futurs.
Donc dans notre projet on a utilisé quelques modèles prédictifs per-

mettent de générer les informations dont nous avons besoin pour prendre des
décisions opérationnelles, de maintenance, de réparation ou de remplacement
de composantes avisées.
5.6.1 Régression Linéaire Multiple

En statistique , la régression linéaire multiple est une méthode de ré-
gression mathématique qui étend la régression linéaire simple pour décrire
les changements de variables endogènes par rapport aux changements de plu-
sieurs variables exogènes. [15]
Figure 5.7 – “Formule de Régression Linéaire Multiple “
64
La figure 5.7 représente le code source de modéle régression linéaire

multiple
Figure 5.8 – “ Code source de Régression Linéaire Multiple “
La figure 5.8 Décrit le résultat de régression linéaire multiple qui repré-

sente les relations entre toutes les variables de notre échantillon. Deux types
de corrélations sont générés :
- Corrélation négative faible (Exemple : handset par rapport anc -0.13).
- Corrélation positive faible et forte (Exemple : Faible(entre nbr sms et durée
0.18) et Forte (entre volume et ussd data 0.78) ).
65
Figure 5.9 – “Résultat de Régression Linéaire Multiple “
5.6.2 Régression Linéaire

la régression linéaire est un modèle statistique spécifiquement conçu
pour mettre en œuvre une fonction prédictive avec un minimum d’erreur.
L’algorithme utilise des valeurs numériques pour identifier des tendances ou
des évolutions prévisibles dans le temps.
Méthode 1
Comme les plusieurs modèles de régression, le modèle de régression li-

néaire sont aussi bien utilisés pour tenter de prédire un phénomène que pour
essayer à l’expliquer. Après avoir estimé un modèle de régression linéaire ,
on peut prévoir quel serait le niveau d’y pour des valeurs spécifiques de x.
66
Dans notre première méthode, nous avons prédit le revenu et testé s’il
existe une corrélation entre le réel et le prédictif.il donne 0.795 scores de
précision de prédiction.
Figure 5.10 – “ Régression Linéaire “
Méthode 2
Dans la 2ème approche, nous utilisons l’outil Azure Machine Learning

Studio pour construire notre modèle et tester s’il existe une corrélation entre
le volume et les revenus.
67
Figure 5.11 – “Démarche et test de régression linéaire “
La figure 5.11 illustre le résultat de régression linéaire qui montre une

corrélation entre le volume et les revenues ( quand le volume augmente le
revenu augmente et vice versa).
Figure 5.12 – “Résulta de Régression Linéaire “
68
Méthode 3
Pour la troisième méthode, la régression linéaire est appliquée aux types
d’offres liés à leurs revenus, Ussd, durée totale et volume.
Figure 5.13 – “ Régression Linéaire “
5.6.3 Régression Logistique

La régression logistique est un modèle mathématique qui combine un
ensemble de variables prédictives (X) avec une variable aléatoire binomiale
(Y). Elle est couramment utilisée dans le domaine de l’intelligence artificielle
(IA) et du machine learning.
SCORE CHURN
Ainsi, Churn Prediction prévisible principalement quels clients sont les

plus possibles d’annuler un abonnement, c’est-à-dire de «quitter une entre-
prise» en fonction de leur utilisation du service. Du point de vue de l’en-
treprise, il est essentiel d’obtenir ces informations car obtenir de nouveaux
69
clients est souvent ardu et plus coûteux que de garder les anciens.
Nous avons donc testé le nombre de jours d’inactivité de nos clients et

nous avons prédit quels clients resteraient et lesquels nous quitteraient en
fonction du nombre de jours. ( [0.30] = reste , [0<30]= quitte ).
Figure 5.14 – “ Code source de Régression Logistique “
La figure 5.11 illustre le résultat de régression logistique
70
Figure 5.15 – “ Régression Logistique “
5.6.4 ARMA/SARIMA
ARMA
En statistique, les modèles ARMA (modèles autorégressifs et moyenne mo-
bile), ou aussi modèle de Box-Jenkins, sont les principaux modèles de séries
temporelles. Étant donné une série temporelle Xt, le modèle ARMA est un
outil pour comprendre et prédire, éventuellement, les valeurs futures de cette
série.[22]
Figure 5.16 – “ Formule ARMA “
71
SARIMA
les SARIMA (pour Seasonal ARIMA ) présentent des variations périodiques
qui ont elles-mêmes un caractère aléatoire, les SARIMA sont stationnaires
quand ils ne sont pas intégrés (SARMA ), et non stationnaires lorsqu’ils sont
intégrés (au même titre que les ARIMA ) .[18]
Figure 5.17 – “ Formule SARIMA “
la figure 5.18 illustre le code source des Modèles ARMA,SARIMA et

test aléatoire sur le revenu par rapport date
Figure 5.18 – “ Code source des Modèles ARMA et SARIMA “
72
Sprint terminé
La figure 5.18 illustre les Résultat des Modèles ARMA , SARIMA et le

test.
Figure 5.19 – “ Résultat des Modèles ARMA et SARIMA “
5.7 Sprint terminé

La figure 5.15 montre la fin du sprint 3, tous les tickets de sprint sont
complétés.
Figure 5.20 – “ Sprint 3 Terminé sur Jira “
5.8 Conclusion
Dans ce chapitre, nous avons terminé le dernier sprint qui représenter
l’analyse prédictive. Le chapitre suite est le chapitre avec lequel nous allons
achever notre rapport, il contint les informations et les ressources ayant aidé
à réalisation du projet.
73
Chapitre 6
PHASE DE CLÔTURE
INTRODUCTION
Cette étape est considérée comme la dernière partie du cycle de dévelop-

pement du projet avec SCRUM. Ce chapitre sera consacré à la présentation
de l’environnement du projet : matériel et logiciel. Nous allons montrer les
logiciels utilisés pendant le cycle d’élaboration du projet.
6.1 Environnement de travail

6.1.1 Environnement matériel
Table 6.1 – Matériel

Propriétaire Ghassen Salhi
Processeur Core i7 8th Gen
Ram 8 Go
Disque dur 1 To
Systéme d’expoitation Windows 10 Professionnel(X64)
74
Environnement de travail
6.1.2 Environnement logiciel

— POWER BI Desktop
Microsoft Power BI est une solution d’analyse de données de Micro-

soft. Il permet de créer des visualisations de données personnalisées
et interactives avec une interface suffisamment simple pour que les
utilisateurs finaux créent leurs propres rapports et tableaux de bord.
Power BI est un ensemble de services logiciels, d’applications et de
connecteurs qui fonctionnent ensemble pour transformer différentes
sources de données en informations visuelles, immersives et interac-
tives.
Figure 6.1 – logo POWER BI
— POWER BI SERVICE
Le service Microsoft Power BI (app.powerbi.com), parfois appelé Po-

wer BI en ligne, est la partie SaaS (Software as a Service) de Power BI.
Dans le service Power BI, les tableaux de bord vous aident à garder
le pouls de votre entreprise. Les tableaux de bord affichent des mo-
saïques, que vous pouvez sélectionner pour ouvrir des rapports pour
une exploration plus approfondie.
— POWER Query
Power Query est la technologie de connectivité et de préparation des

données qui permet aux utilisateurs finaux d’importer et de remode-
ler en toute transparence des données à partir d’une large gamme de
produits Microsoft, notamment Excel, Power BI, Analysis Services,
Dataverse, etc..|23]
75
— POWER Autaomate
Microsoft Power Automate, anciennement connu sous le nom de Mi-

crosoft Flow jusqu’en novembre 2019, est un logiciel de Microsoft pour
l’automatisation des tâches récurrentes. Il fait partie de la gamme de
produits Microsoft Power Platform avec des produits tels que Power
Apps et Power BI.[27]
Figure 6.2 – logo POWER Autaomate
— Google Colab
Colaboratory, souvent raccourci en "Colab", est un produit de Google

Research. Colab permet à n’importe qui d’écrire et d’exécuter le code
Python de son choix par le biais du navigateur. C’est un environ-
nement particulièrement adapté au machine learning, à l’analyse de
données et à l’éducation.[26]
Figure 6.3 – logo GooGLE Colab
76
— Azure Machine Learning Studio
Azure ML Studio est un espace de travail dans lequel vous créez,

construisez et formez les modèles d’apprentissage automatique. Il s’agit
d’un outil de glisser-déposer (Azure Machine Learning Designer) dans
lequel vous pouvez faire glisser les ensembles de données et poursuivre
le traitement de l’analyse sur ces données. Il offre à la fois des options
sans code et à faible code pour les projets.[10]
Figure 6.4 – logo Azure Machine Learning Studio
— DrawIO
C’est un logiciel de modélisation d’organigrammes, des diagrammes

de processus, des diagrammes UML et les diagrammes de réseau.
Figure 6.5 – logo DrawIO
77
— JustInMind
L’outil de prototypage Justinmind est un outil de création de proto-

types d’applications Web et mobiles et de structures filaires de sites
Web haute fidélité.
Figure 6.6 – logo JustInMind
— Sharelatex OverLeaf
Un éditeur LaTex en ligne. C’est un outil collaboratif de rédaction,

d’édition de docuements text et compileur PDF qui permet de vision-
ner de manière continue l’état de progression du docuement.[13]
Figure 6.7 – logo Sharelatex OverLeaf
78
6.1.3 Technologies et langages utilisés

— DAX
DAX est un ensemble de fonctions, d’opérateurs et de constantes qui

peuvent être utilisés dans une formule, ou expression, afin de calculer
et retourner une ou plusieurs valeurs. Plus clairement, DAX vous aide
à créer de nouvelles informations à partir de données figurant déjà
dans votre modèle.[25]
— PYTHON
Python est le langage de programmation open source le plus employé

par les informaticiens. Ce langage s’est propulsé en tête de la gestion
d’infrastructure, d’analyse de données ou dans le domaine du déve-
loppement de logiciels. [19]
Figure 6.8 – logo PYTHON
— LaTex
c’est un langage de composition de documents. Il est utilisé dans le

domaine technique et scientifique pour la rédaction des documents de
taille importante tel que les thèses. C’est l’outil que nous avons utilisé
pour la rédaction de notre rapport de projet.[14]
Figure 6.9 – logo LaTex
79
Conclusion Générale
Ce rapport est le résultat de plus de 4 mois de travail avec "Tunsise

Telecom" dans le cadre de notre mémoire pour pouvoir obtenir notre diplôme
de Master contrôle de gestion et business intelligence de l’école supérieure
d’économie numérique de manouba,Institut Supérieur de Comptabilité et
d’Administration des Entreprises de Tunis et en partenariat avec l’institut
de finance, audit et comptabilité (IFAC) de université de reims champagne
ardenne (URCA).
L’objectif principal de cette solution Bi est la mise en place d’un tableau
de bord dynamique de performance avec une analyse prédictive des données
( Machine Learning) .En effet,Cette solution permet à l’entreprise de mieux
trouver des réponses aux questions liées aux données et aide les décideurs à
prendre les bonnes décisions.
Nous avons mis en œuvre ce projet de bout en bout en suivant la
méthodologie SCRUM, qui se base sur les sprints. Nous avons conçu le projet
dans un seul release, avec les deux premiers sprints pour réaliser le Power BI
et un sprint pour l’analyse prédictive ( Machine Learning) .
Ce projet est l’œuvre d’un grand travail et de longues nuits de travail
intense et c’est suite à ce stage on s’est familiarisé avec SCRUM et le maî-
triser complètement suite à plusieurs recherches. On a rencontré quelques
complexités avec manipulation de nouveaux outils technologiques mais en
fin de compte on a su les surmonter, en même temps nous avons acquis de
nouvelles connaissances et accompli une solution selon les besoins de l’entre-
prise.
80
Bibliographie
[1] [En ligne] https ://www.tunisietelecom.tn/Fr. [Consulter le 1/03/22]

[2] [EN ligne] Cours Scrum et BI de Mr.Mohamed Jarboui. [Consulter le
20/03/22]
[3] [En ligne] https ://www.oracle.com/fr/database/data-warehouse-
definition.html. [Consulter le 10/04/22]
[4] [En ligne] https ://fr.wikipedia.org/wiki/Microsoft_Power_BI. [Consul-
ter le 17/03/22]
[5] [En ligne] https ://www.oracle.com/fr/database/business-intelligence-
definition.html. [Consulter le 26/04/22]
[6] [En ligne] https ://en.wikipedia.org/wiki/Justinmind_(prototyper).
[7] [En ligne] https ://controle2gestion.net/business-intelligence-controle-
de-gestion.
[8] [En ligne] https ://support.microsoft.com/fr. [Consulter le 2/04/22]
[9] https ://www.lebigdata.fr/olap-online-analytical-processing
[10] [En ligne] https ://k21academy.com/microsoft-azure/ai-900/ai900-
azure-machine-learning-studio/.
[11] [En ligne] https ://www.journaldunet.fr.
[12] [En ligne] https ://business-intelligence.developpez.com
[13] [https ://fr.wikipedia.org/wiki/ShareLaTeX/. [Consulter le 7/05/22]
[14] [En ligne] https ://www.latexproject.org/. [Consulter le 29/03/22]
[15] [En ligne] https ://fr.wikipedia.org/wiki/R%C3%A9gression_lin%C3%A9aire_multiple.
[16] [En ligne] https ://web-new.univ-pau.fr/RECHERCHE/SET/LAFFLY/docs‘_laffly/Laffly
_regression%20multiple.pdf.
[17] [En ligne] https ://www.statsoft.fr/concepts-statistiques/regression-
multiple/regression-multiple.php.
[18] [En ligne] https ://www.techniques-ingenieur.fr/.[Consulter le 16/04/22]
81
BIBLIOGRAPHIE
[19] [En ligne]https ://www.journaldunet.fr/web-tech/dictionnaire-du-

webmastering/1445304-python-definition-et-utilisation-de-ce-langage-
informatique/.
[20] [Enligne] www.talend.com/fr/resources/what-is-machine-learning/.
[21] [Enligne] https ://fr.wikipedia.org/wiki/Operational_data_store
[22] [Enligne] https ://fr.wikipedia.org/wiki/ARMA. [Consulter le 26/05/22]
[23] [Enligne] https ://docs.microsoft.com/en-us/power-query/. [Consulter
le 20/04/22]
[24] [Enligne] https ://www.oracle.com/fr/database/data-mart-
definition.html.[Consulter le 5/05/22]
[25] [Enligne]https ://support.microsoft.com/fr-
fr/office/d%C3%A9marragerapide-d%C3%A9couvrir-les-
fondamentaux-de-dax-en-30-minutes-51744643-c2a5-436a-bdf6-
c895762bec1a. [Consulter le 10/05/22]
[26] [Enligne] https ://research.google.com/colaboratory/faq.html ?hl=fr : :
text=Colaboratory%2C%20souvent%20raccourci%20en%20%22Colab,
donn%C3%A9es%20et%20%C3%A0%20l’%C3%A9ducation.[Consulter
le 15/05/22]
[27] [Enligne]https ://en.wikipedia.org/wiki/Microsoft_Power_Automate
.[Consulter le 20/05/22]
82

Mémoire CGBI

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mémoire CGBI

Transféré par

Droits d'auteur :

Formats disponibles

Remerciement

Avant de commencer, nous tenons à exprimer notre gratitude et nos

Nous tenons tout d’abord à remercier Monsieur Mohamed Jarboui

Nous remercions également tous nos enseignants de l’ESEN et ISCAE pour

A tous mes amis

2.5 Architecture de travail . . . . . . . . . . . . . . . . . . . . 30

3 SPRINT1 : GESTION DES DONNÉES 32

4 SPRINT2 : VISUALISATIONS DES DONNÉES 45

5 Sprint 3 : ANALYSE PRÉDICTIVE 59

5.6.2 Régression Linéaire . . . . . . . . . . . . . . . . . . . 66

1.1 Logo "Tunsie Telecom" . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Diagramme de contexte statique . . . . . . . . . . . . . . . . . 21

3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . 32

3.15 Requête DAX . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . 45

5.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . 59

6.1 logo POWER BI . . . . . . . . . . . . . . . . . . . . . . . . . 75

2.1 Identification des acteurs de systéme . . . . . . . . . . . . . . 21

3.1 Classification des cas d’utilisation- sprint1 . . . . . . . . . . . 33

4.1 Classification des cas d’utilisation sprint 2 . . . . . . . . . . . 46

5.1 Classification des cas d’utilisation- sprint 3 . . . . . . . . . . . 60

« L’informatique décisionnelle (ou BI pour Business Intelligence) dé-

Une entreprise est habituellement composée de plusieurs services tels

Chaque département d’une entreprise a généralement sa propre manière

Le premier chapitre présente d’une maniére générale le projet de l’en-

Le deuxième chapitre, intitulé "Planification et Architecture", contient

les trois chapitres suivants, intitulés respecivement ’Gestion des don-

Le dernier chapitre, intitulé "Phase de clôture", contient une introduc-

1.1 Présentation de l’organisme d’acceuil

1.1.1 Présentation de Tunisie Telecom [1]

télécoms en Tunisie, à améliorer le taux de couverture et à renforcer sa com-

NOS ÉTAPES CLÉS

• 1er Janvier 1996

consortium Mattel (détenue à 51

Figure 1.1 – Logo "Tunsie Telecom"

1.1.2 Organigramme de "Tunisie Telecom"

Figure 1.2 – Organigramme de "Tunsie Telecom"

1.2 Présenation du projet

1.2.2 Objectifs du projet

1.3 Critique de l’existant

1.4 Solution proposée

En plus des informations détaillées ci-dessus la solution doit offrir une

1.5 L’informatique décisionnelle

Quelle est la place de la Business Intelligence dans une entreprise ?

nagers et autres utilisateurs finaux de l’entreprise à prendre des décisions

Aujourd’hui, les entreprises s’appuient sur les logiciels de Business In-

Au cours des dernières années, la Business

L’influence de la BI sur les métiers du contrôle de gestion [7]

1.5.2 Architecture générale

Figure 1.3 – Architecture Décisionnelle

1.5.3 Modélisation d’une base donnée multidimension-

Il existe 3 modèles dans la conception multidimensionnelle :

-Gestion des agrégats

Figure 1.4 – Schéma de Modéle en etoile

Modèle en flocon de neige

Figure 1.5 – Schéma de Modèle en flocon de neige

Figure 1.6 – Schéma de Modèle en constellation

1.6 Méthodologie de travail

1.6.1 Méthodologie choisie agile

Figure 1.7 – Scrum

Répartition des rôles dans le framework Scrum

Planification d’un Sprint

L’équipe se sert de la rétrospective pour passer en revue le sprint ter-

2.1 Spécification des besoins