Ben Hrak 3éme BI

Table des mati‘eres
Introduction générale 1
1 Contexte, enjeux et problématique 3

1.1 Cadre générale du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de lŠorganisme dŠaccueil . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Historique de lŠorganisme : . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Les références de lŠorganisme : . . . . . . . . . . . . . . . . . . . 4
1.2.3 Les produits de lŠorganisme : . . . . . . . . . . . . . . . . . . . . 4
1.2.4 Fiche de présentation globale : . . . . . . . . . . . . . . . . . . . 5
1.2.5 Organigramme actuel : . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Etude de lŠexistant : . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Problématiques : . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.3 La solution proposée : . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Méthode de conception et outils décisionnels 9

2.1 Contexte décisionnel : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Informatique décisionnelle : . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Base de donnée intermédiaire ODS (Un Operational Data Store) : 9
2.1.3 LŠentrepôt des données : . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4 Data Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.5 Comparaison entre un Data Warehouse et un Datamart . . . . . 11
2.1.6 Conception dŠun entrepôt de données . . . . . . . . . . . . . . . . 12
2.1.7 Chaı̂ne décisionnelle dŠun projet BI . . . . . . . . . . . . . . . . . 14
2.2 Méthodologie de réalisation dŠun projet . . . . . . . . . . . . . . . . . . 15
2.2.1 Méthode classique . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Méthodes Agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.3 Comparaison Méthodes Classiques VS Méthodes Agiles . . . . . 16
2.2.4 Le choix de méthode convenable de travail . . . . . . . . . . . . . 17
2.2.5 Présentation du méthode SCRUM . . . . . . . . . . . . . . . . . 17
i
CONTENTS ii
2.2.6 LŠapproche SCRUM appliquée ‘a un projet BI : (Les méthodologie

de conception du Data warehouse ) . . . . . . . . . . . . . . . . . 21
2.3 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Sprint 0 : Etude fonctionnelle : 26

3.1 Analyse des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1 SpéciĄcation des besoins fonctionnelles . . . . . . . . . . . . . . 26
3.1.2 SpéciĄcation des besoins non fonctionnelles : . . . . . . . . . . . 27
3.2 Backlog produit : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 PlaniĄcation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.1 Pilotage du projet avec la méthodologie SCRUM . . . . . . . . . 28
3.3.2 Découpage de la solution en Sprint . . . . . . . . . . . . . . . . . 29
3.4 Conception général de lŠentrepôt de données . . . . . . . . . . . . . . . . 29
3.4.1 Conception général de lŠentrepôt de données . . . . . . . . . . . . 29
3.4.2 Approches pour la création de lŠentrepôt de données . . . . . . . 33
3.4.3 3. Le diagramme général de la conception de lŠentrepôt de données 34
4 Sprint 1 : Préparation des données 37

4.1 Backlog du sprint : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Etude des données source : . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Préparation et alimentation de la base de donnée (ETL) : . . . . . . . . 38
4.3.1 Développement du Syst‘eme ETL : . . . . . . . . . . . . . . . . . 38
5 Création du datawarehouse 62
5.1 Backlog du sprint du datawarehouse . . . . . . . . . . . . . . . . . . . . 62
5.2 Les indicateurs de performance du datawarehouse . . . . . . . . . . . . 63
5.2.1 Principe dŠun indicateur de performance (KPI) . . . . . . . . . . 63
5.2.2 Objectifs des indicateur de performance du datawarehouse . . . . 63
5.3 Intégration des données ETL (Extraction, Transformation, Chargement) 64
5.3.1 Extraction des données . . . . . . . . . . . . . . . . . . . . . . . 64
5.3.2 Transformation de données . . . . . . . . . . . . . . . . . . . . . 71
5.3.3 Chargement des données . . . . . . . . . . . . . . . . . . . . . . 74
5.4 réation dŠun projet SSAS . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.4.1 Source de données . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.4.2 Vue source de données . . . . . . . . . . . . . . . . . . . . . . . 77
6 Sprint 3 : Création des tableaux de bords 80

6.1 Backlog du sprint Dashboard . . . . . . . . . . . . . . . . . . . . . . . 80
6.2 Phase de Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.2.1 LŠintégration des données du datawarehouse dans lŠoutil Power BI 81
6.2.2 Choix du graphique . . . . . . . . . . . . . . . . . . . . . . . . . 83
CONTENTS iii
6.3 Composant DAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.3.1 DéĄnition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.3.2 Calcul des mesures . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.4 Visualisation globale du tableau de bord . . . . . . . . . . . . . . . . . . 86
6.4.1 Suivi coût de revient . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.4.2 Suivi Production . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.4.3 Suivi Vente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Conclusion générale 95
Liste des tableaux
2.1 Méthodes agiles Vs méthodes classiques . . . . . . . . . . . . . . . . . . 16

2.2 Rôles des intervenants dans SCRUM . . . . . . . . . . . . . . . . . . . . 18
2.3 Description des artéfacts du SCRUM . . . . . . . . . . . . . . . . . . . . 19
2.4 Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 : de la modélisation multidimensionnelle . . . . . . . . . . . . . . . . . 32
3.3 Les faits du data-warehouse . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 : Backlog du sprint N°1 . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1 Backlog du sprint N°2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2 Objectifs et indicateurs du datawarehouse . . . . . . . . . . . . . . . . . 63
6.1 Backlog du sprint N°3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
iv
Table des Ągures
1.1 Références de lŠorganisme . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Produits de lŠorganisme . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Fiche technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Organigramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Schéma explicatif du processus de production . . . . . . . . . . . . . . . 7
2.1 Tableau dŠun entrepôt de données VS un Datamart . . . . . . . . . . . . 12

2.2 Data Warehouse VS Data Mart . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Exemple dŠune table de fait . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Exemple dŠune table de dimension . . . . . . . . . . . . . . . . . . . . . 13
2.5 Les étapes dŠun projet BI . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Mod‘ele classique de réalisation dŠun projet en V . . . . . . . . . . . . . 15
2.7 Comparaison entre les différent méthode . . . . . . . . . . . . . . . . . . 17
2.8 Processus SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9 SQL server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.10 Visuel studio 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.11 Power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.12 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1 Equipe scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Répartition des Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Exemple dŠun schéma en étoile . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Exemple dŠun schéma en Ćocon de neige . . . . . . . . . . . . . . . . . 30
3.5 Exemple illustratif dŠun schéma en constellation . . . . . . . . . . . . . 31
3.6 Mod‘ele ROLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 Mod‘ele MOLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8 Mod‘ele HOLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.9 Conception globale de lŠentrepôt de données . . . . . . . . . . . . . . . . 34
3.10 Aperçu sur les tables de faits «Fact Couts de revient» , «Fact Produc-
tion» et «Fact Ventet» . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.11 Aperçu sur la dimension «Date» . . . . . . . . . . . . . . . . . . . . . . 35
v
TABLE DES FIGURES vi
3.12 Aperçu sur la dimension «Lot» . . . . . . . . . . . . . . . . . . . . . . . 36

3.13 : Aperçu sur la dimension «Fournisseurd Aliment >> . . . . . . . . . . 36
3.14 Aperçu sur la dimension «Aliment» . . . . . . . . . . . . . . . . . . . . . 36
4.1 Gestionnaire de connexion ‘a la base de données SQL Server . . . . . . . 39

4.2 Aperçu sur la création base de donnée Ods . . . . . . . . . . . . . . . . 39
4.3 Aperçu sur la création base de donnée DWH . . . . . . . . . . . . . . . 40
4.4 Création dŠun nouveau projet SSIS . . . . . . . . . . . . . . . . . . . . 40
4.5 Le type de gestionnaire de connexion du VMIND . . . . . . . . . . . . 41
4.6 Aperçu sur la conĄguration le gestionnaire de connexion OLEDB VMIND
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.7 Aperçu sur la conĄguration le gestionnaire de connexion OLEDB ODS 42
4.8 Aperçu sur la conĄguration le gestionnaire de connexion OLEDB DWH 42
4.9 Paquet Integration Services . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.10 Composition dŠun Package SSIS simple . . . . . . . . . . . . . . . . . . . 43
4.11 Aperçu sur la liste des packages de chargement de la base de données . 44
4.12 Tâche dŠexécution de la requête SQL ≪ Vider ≫ . . . . . . . . . . . . . . 44
4.13 Résultat Control Ćow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.14 Gestionnaire de connexion de la source . . . . . . . . . . . . . . . . . . . 45
4.15 Sélection des attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.16 Output Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.17 Editeur de transformation de ŞSortŤ . . . . . . . . . . . . . . . . . . . . 47
4.18 Choix de Destination de Chargement de données . . . . . . . . . . . . . 47
4.19 Création de la table Aliment . . . . . . . . . . . . . . . . . . . . . . . . 48
4.20 «Mapping» de la table Aliment . . . . . . . . . . . . . . . . . . . . . . . 48
4.21 Chargement de la table OdsA liment . . . . . . . . . . . . . . . . . . . . 49
4.22 Table OdsA liment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.23 Vue LOTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.25 Gestionnaire de connexion de la source . . . . . . . . . . . . . . . . . . . 50
4.26 Chargement de la table OdsL ot . . . . . . . . . . . . . . . . . . . . . . . 51
4.27 Table Ods Lot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.28 Gestionnaire de connexion de la table OdsF ournisseurd Alimentation . 51
4.29 Résultat Control Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.30 Chargement de la table Ods Fournisseur dAlimentation . . . . . . . . . 52
4.31 Table Ods Fournisseur dŠAlimentation . . . . . . . . . . . . . . . . . . . 52
4.32 Création Data Set Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.33 Gestionnaire de connexion de la table Ods Date . . . . . . . . . . . . . . 54
4.35 Chargement de la table Ods Date . . . . . . . . . . . . . . . . . . . . . . 55
TABLE DES FIGURES vii
4.36 Table Ods Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.37 La vue Prodt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.38 Les jointures réalisé dans la table Ods Production . . . . . . . . . . . . 56
4.40 Chargement de la table Ods Production . . . . . . . . . . . . . . . . . . 57
4.41 Table Ods Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.42 Création de la colonne isDirectCharges . . . . . . . . . . . . . . . . . . . 58
4.43 Création de la table Ş Historique Purchasing AllPurchasingBIŤ et lŠexécution
du procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.44 Résultat Control Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.45 Exécution de la condition Conditional Split . . . . . . . . . . . . . . . . 59
4.46 Chargement de la table Ods Cout de revient . . . . . . . . . . . . . . . 59
4.47 La table Ods Cout de revient . . . . . . . . . . . . . . . . . . . . . . . . 59
4.48 Les jointures réalisés dans la table Ods Vente . . . . . . . . . . . . . . . 60
4.50 Chargement de la table Ods Vente . . . . . . . . . . . . . . . . . . . . . 61
4.51 Table Oda Vente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1 Aperçu sur la liste des packages de chargement de la base de données . 64

5.2 ConĄguration de la tâche dŠexécution de requête SQL «Vider» . . . . . 65
5.3 Résultat Control Ćow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4 Récupération des tables de la connexion . . . . . . . . . . . . . . . . . . 66
5.5 Création de la table Dim-date . . . . . . . . . . . . . . . . . . . . . . . 66
5.6 «Mapping» DimD ate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.7 Chargement de la dimension Dim-Date . . . . . . . . . . . . . . . . . . 67
5.8 Dimension Dim-Date dans DWH . . . . . . . . . . . . . . . . . . . . . . 67
5.9 Création du clé artiĄcielle Id-chargement de la dimension Dim-LotDimLot 68
5.10 Chargement de la dimension Dim-Lot . . . . . . . . . . . . . . . . . . . 68
5.11 Dimension Dim-Lot dans DWH . . . . . . . . . . . . . . . . . . . . . . . 68
5.12 Création du clé artiĄcielle Id-DimFournisseurAliment . . . . . . . . . . . 69
5.13 Chargement de la dimension Dim-FournisseurdAliment . . . . . . . . . . 69
5.14 Dimension Dim-FournisseurdAliment dans DWH . . . . . . . . . . . . . 69
5.15 Création du clé artiĄcielle id-dimAliment . . . . . . . . . . . . . . . . . 70
5.16 Chargement de la dimension Dim-Aliment . . . . . . . . . . . . . . . . . 70
5.17 Dimension Dim-Aliment dans DWH . . . . . . . . . . . . . . . . . . . . 70
5.18 Récupération des tables de la connexion . . . . . . . . . . . . . . . . . . 71
5.19 Conversion du type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.20 SpéciĄcation du connextion . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.21 Connexion de table Dim-Date . . . . . . . . . . . . . . . . . . . . . . . 73
5.22 Mappage ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
TABLE DES FIGURES viii
5.23 Chargement Fact-Cout-de-reveint . . . . . . . . . . . . . . . . . . . . . 74

5.24 Fact-Cout-de-revient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.25 Chargement Fact-Production . . . . . . . . . . . . . . . . . . . . . . . . 74
5.26 Fact-Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.27 Chargement Fact-Vente . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.28 Fact-Vente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.29 Création source de donnée DWH dans SSAS . . . . . . . . . . . . . . . 76
5.30 Connexion aux service SSAS . . . . . . . . . . . . . . . . . . . . . . . . 76
5.31 Importer source de donnée DWH . . . . . . . . . . . . . . . . . . . . . . 77
5.32 Sélectionner la source ‘
a exploiter . . . . . . . . . . . . . . . . . . . . . . 77
5.33 IdentiĄer les liens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.34 Ajouter les tables de lŠentrepôt de données . . . . . . . . . . . . . . . . 78
5.35 Importer les tables faits et ses dimensions de lŠentrepôt de données . . . 78
5.36 Mod‘ele en constellation du datawarehouse . . . . . . . . . . . . . . . . . 79
6.1 Démarrer lŠoutil « Power BI » . . . . . . . . . . . . . . . . . . . . . . . . 81

6.2 Importer les données ‘a partir SQL Server . . . . . . . . . . . . . . . . . 81
6.3 Connexion directe avec base de donnée «DWH» . . . . . . . . . . . . . 82
6.4 Sélection des tables nécessaires . . . . . . . . . . . . . . . . . . . . . . . 82
6.5 Chargement des tables sélectionner dans « Power BI » . . . . . . . . . . 82
6.6 Coût revient par esp‘eces . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.7 Mesure de charge total . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.8 Mesure du KPI Coût de revient KG . . . . . . . . . . . . . . . . . . . . 85
6.9 Mesure du Prix moyen . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.10 Rapport pour le suivi de lŠévolution des charges en fonction de la quantité
produite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.11 Rapport sur les facteurs contributifs ‘a lŠévolution du coût de revient . . 87
6.12 Rapport pour le suivi du coût par lot . . . . . . . . . . . . . . . . . . . 88
6.13 Rapport pour le Suivi des Production par Aliment . . . . . . . . . . . . 88
6.14 Rapport pour suivi de Production par Pêche . . . . . . . . . . . . . . . 89
6.15 Rapport pour le suivi de Production (clôturé) par pêche / poisson . . . 89
6.16 Rapport pour le suivi de Production (clôturé) par Biomasse . . . . . . 90
6.17 Rapport pour le suivi de Production (clôturé) par Mortalité / Fuite . . 90
6.18 Rapport pour le suivi de Production (clôturé) par Nbrjrs Alimentation 91
6.19 Rapport pour le suivi de Production (clôturé) par Coûts . . . . . . . . 91
6.20 Suivi Vente par date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.21 Suivi Vente par Espece . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.22 Suivi Vente par Cage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.23 Suivi Vente par Lot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.24 Suivi Vente en fonction de lŠévolution du prix moyen . . . . . . . . . . . 94
Liste des abréviations
[ESN] Entreprise de Système Numérique

[TMS] Training Management System
[LMS] Lraining Management System
[CMS] Craining Management System
[CRM] Customer Relationship Management
[ERP] Enterprise Resource Planning
[ODS] Operational Data Store
[DAX] Data Analysis Expressions
5
Introduction Générale
Le développement spectaculaire de lŠinformatique est un trait marquant des sociétés

contemporaines . Cette technologie nouvelle qui pouvait , il y a vingt ans , être considérée
comme marginale , ésotérique et réservée ‘a lŠusage de quelques experts , est maintenant
entrée dans la pratique les plus quotidiennes .
Les grandes entreprises font partie des principaux bénéĄciaires des avantages prodi-
gieux de lŠinformatique . En sŠétendant ‘a tous les domaines de la gestion , lŠinformatique
a su réduire considérablement les coûts et les délais de tout business .
Cependant , leur était considéré comme avantage , est aujourdŠhui un besoin essen-
tiel et acquis . LŠinformatique de gestion des temps modernes doit donc se surpasser .
En plus dŠassurer un sout‘enement aux opérations logistique des entreprises , lŠinforma-
tique doit représenter un véritable atout compétitif pour eux et leur permettre de faire
évoluer leurs performances .
En réponse ‘a de telles sollicitations , cŠest lŠinformatique décisionnelle , dont nous

témoignons lŠémergence aujourd39 ;hui , qui est en train de se développer . En effet ,
cŠest un domaine passionnant qui applique le pouvoir de lŠinformatique ‘a assister les
managers dans leurs prises de décisions stratégiques et inĆuer ainsi les performances de
lŠentreprise .
Ces entreprises , qui de nos jours sont confrontées ‘a une multitude de données sou-
vent éparses hétérog‘ene , cherchent une solution pour collecter , consolider et extraire
de lŠinformatique ‘ a partir de ces données considérées comme leurs plus grande richesse
. Cependant , pour extraire une telle valeur ajoutée , il faut passer par une énorme
quantité de données pas toujours cohérente ( Base de données relationnelles , Source
externe , Excel , etc ) . Sans une solution structurée et efficace , ces données si précieuses
perdent alors beaucoup de leur valeur . Les indicateurs deviennent difficilement lisibles
et nécessitent beaucoup plus dŠénergie et de temps pour les rendre utilisables , justes
et pertinents .
1
CŠest ‘a ce que le processus de lŠinformatique décisionnelle ou encore Business Intel-
ligence (BI) est destiné . Il sŠagit de collecte , lŠentreposage , et la diffusion des données
qui permettent aux
utilisateurs dŠacquérir de nouvelles connaissances dans le but dŠintégrer une ap-
proche plus stratégique pour une meilleure prise de décision . CŠest dans cette perspec-
tive que nous avons décidé de réaliser mon stage dans une entreprise qui me permettrait
de répondre ‘ a un tel enjeu . JŠai choisi la société Virtual Dev comme une entreprise
dŠaccueil . Le projet qui mŠa été conĄé consiste ‘a créer un tableau de bord décisionnel
sur le prix de revient dŠun KG pour un ferme d39 ;élevage des poissons .
CŠest un projet qui mŠa permis dŠappliquer mes connaissances des syst‘emes de ges-
tion , acquises dans le cadre de notre licence en informatique de gestion , et surtout
acquérir de nouvelles connaissances . Le présent rapport expose les différentes étapes
de lŠélaboration de ma solution selon le framework SCRUM BI . Le manuscrit de ce
projet de Ąn dŠétude se compose de la présente Introduction , de Quatre chapitres ,
dŠune conclusion générale et dŠune liste de références bibliographiques .
Le premier chapitre intitulé Ş Présentation du cadre du stage Ť consiste en la mise en

contexte de mon projet . Nous commencerons par la présentation de lŠorganisme dŠac-
cueil suivie par une étude de lŠexistant en vue de dégager ses limites et pouvoir ainsi
Ąxer les objectifs de notre solution . Le deuxi‘eme chapitre intitulé ŞMéthode de concep-
tion et outils décisionnels Ť présente le résultat de mon recherche autour du domaine de
lŠinformatique décisionnelle et ses concepts fondamentaux puis on récapitule les études
comparatives que nous avons mené pour pouvoir choisir la méthode de conception la
mieux adaptée ‘ a notre projet , ainsi que lŠensemble des outils BI adopté . Finalement
, on ach‘evera ce rapport par une conclusion générale qui récapitule tout le travail que
nous avons réalisé tout au long de ce stage et énoncera ces futures perspectives .
1 Contexte, enjeux et problématique
Introduction
Ce premier chapitre consiste en une présentation générale de lŠorganisme dŠaccueil,
son proĄl, ses caractéristiques et ses composantes, ainsi que les enjeux et lŠobjectif de
ce projet.
1.1 Cadre générale du projet

La gestion et lŠanalyse des données sont des étapes essentielles dans la réalisation
de tout projet, car elles permettent dŠanalyser et de visualiser lŠétat de lŠentreprise.
Cela entraı̂ne la prise de bonnes décisions qui contribuent ‘a améliorer sa performance.
Pour cela, VirtualDev utilise lŠinformatique décisionnelle aĄn de fournir des analyses
et des indicateurs sur lesquels ses clients peuvent sŠappuyer pour accélérer et améliorer
la prise de décisions. Ce projet est réalisé dans le cadre de la préparation dŠun projet
de Ąn dŠétudes pour lŠobtention du Diplôme de Licence Appliquée en Informatique
Décisionnelle ‘
a la Faculté des sciences juridiques , Economiques et gestion de Jendouba
(FSJEGJ). Il est exécuté par la société VirtualDev sur une durée de trois mois et a
pour objectif principal la réalisation dŠun tableau de bord décisionnel sur le coût de
revient dŠun kilogramme pour une ferme dŠélevage de poissons.
1.2 Présentation de lŠorganisme dŠaccueil

La digitalisation est devenue primordiale, le covid-19 nous a montré la nécessité de
cette évolution dans tous les domaines professionnels, non seulement pour la gestion
intégrée, mais également pour la communication, la collaboration entre les divers ac-
teurs du processus métier de lŠentreprise. VIRTUALDEV est une ESN, spécialisée dans
la digitalisation des processus métiers des entreprises (CRM, ERP, TMS, GCD, SIRH).
3
1.2. Présentation de lŠorganisme dŠaccueil 4
1.2.1 Historique de lŠorganisme :

Fondée en 2013, VIRTUALDEV a accumulé des années dŠexpérience dans les solu-
tions de processus dŠaffaires aĄn de créer des applications plus efficaces pour aider les
entreprises ‘
a gérer leurs charges de travail numériquement.
Leurs solutions et applications sont éligibles pour de nombreuses industries telles

que le transport logistique, lŠagriculture, les Ąnances et les PME de toutes les activités.
VIRTUALDEV propose ‘ a ses clients une solution clé en main : un progiciel intelligent
conçu avec les derni‘eres technologies digitales qui permet dŠautomatiser tous les pro-
cessus métiers de leur entreprise.De plus elle propose une accompagnement ‘a ses clients
pour la mise en İuvre et lŠexploitation de leurs syst‘emes dŠinformations . VIRTUAL-
DEV intervient également sur la totalité du cycle de vie des syst‘emes informatique y
compris lŠétude, la réalisation, lŠexploitation, et la maintenance .
1.2.2 Les références de lŠorganisme :
Figure 1.1 Ű Références de lŠorganisme
1.2.3 Les produits de lŠorganisme :

VMIND ERP : combine lŠintégralité des fonctions de gestion intégrée (Ąnanci‘ere,
commerciale,comptable), les outils de communication et de collaboration avec son in-
terface 100 web compatible sur les divers appareils, des fonctions automatisées, une
dimension collaborative et un paramétrage personnalisé.
1.2. Présentation de lŠorganisme dŠaccueil 5
Figure 1.2 Ű Produits de lŠorganisme
1.2.4 Fiche de présentation globale :
Figure 1.3 Ű Fiche technique

1.3. Contexte du projet 6
1.2.5 Organigramme actuel :
Figure 1.4 Ű Organigramme
1.3 Contexte du projet

Dans cette section, nous allons déĄnir la problématique, lŠobjectif et les solutions
proposées en se basant sur lŠanalyse de lŠexistant au sein de lŠentreprise .
1.3.1 Etude de lŠexistant :

Nous avons commencé par comprendre les fonctionnalités du syst‘eme vis-‘a vis du
client VMIND chez VIRTUALDEV .
Apr‘es une étude approfondie sur le domaine aquaculture et la participation ‘a une
formation avec un consultant métier fonctionnel nous a expliqué le processus dŠun
façon générale le processus de production dans sŠillustre dans la Ągure suivante :
Figure 1.5 Ű Schéma explicatif du processus de production
1.3.2 Problématiques :
A‘ lŠépoque actuelle, les clients du secteur des fermes aquacole des société dŠélevage
des poissons chez Virtual Dev qui utilise déj‘a la solution VMIND ERP conĆuent certains
probl‘emes au niveau de la couche décisionnelle qui résident dans :
- Il est difficile de suivre lŠévolution du coût de revient dŠun kilogramme de poisson
en raison de la Ćuctuation rapide des charges directes et indirectes au Ąl du temps, de
même que pour la quantité produite.
- Les visualisations actuelles ne permettent pas de fournir des informations pertinentes,

car assez plus au moins générique mais le client ‘a besoin dŠun détail plus profond et
pertinent sur le terme des charges en temps réel selon le KG de poissons, ce qui rend
difficile la prise de décisions éclairées.
1.3.3 La solution proposée :

Apr‘es lŠétude du métier et de divers données dans la base de données de VMIND
on nous propose une solution qui pourra se traduire par la mise en place dŠune solution
de Business Intelligence pour le client VMIND chez VirtualDev. Cette solution sera
composée de trois parties : un processus dŠETL (Extraction, Transformation, Load)
pour extraire et transformer les données, la création dŠun data warehouse pour stocker
lŠhistorique des données (charges, dates, quantités produites, etc.), et la mise en place
dŠun tableau de bord qui permettra aux utilisateurs de prendre des décisions éclairées
grâce ‘a des KPI pertinents.
Cette solution ‘ a pour objectif :
- Élaboration dŠun outil de mesure des coûts de revient dŠun kilo de poisson aĄn dŠop-
timiser la production dans une ferme aquacole.
- Il est nécessaire dŠélaborer un syst‘eme spéciĄque pour contrôler la variation des charges
relatives ‘ a la quantité produite et ‘a lŠévolution temporelle.
- Création dŠun tableau de bord décisionnel pour évaluer le coût de revient dŠun kilo-
gramme de poisson dans une ferme dŠaquaculture.
Conclusion :
Finalement , nous avons pu acquérir une connaissance assez large concernant lŠacti-
vité au sein de VirtualDev. En sŠentretenant avec ses différents acteurs qui interagissent
avec le département informatique et le département des études, On a su formuler une
idée claire des besoins de ces derniers en termes dŠaide ‘a la décision par la suite nous
avons pu concevoir la solution qui répond aux besoins de la société
.
2 Méthode de conception et outils décisionnels
Introduction
Avant dŠentamer la réalisation de mon projet , jŠessaierai ‘a travers ce chapitre de

décrire le principe de lŠinformatique décisionnelle . Je présenterai les étapes de pro-
cessus décisionnel ainsi que les principaux termes du lexique de la Business Intelligence
, ainsi que je déĄnirai les outils de lŠinformatique décisionnelle que jŠai choisi pour
lŠélaboration de projet .
2.1 Contexte décisionnel :
2.1.1 Informatique décisionnelle :

La Business Intelligence (BI) est un processus technologique qui consiste ‘a analyser
les données pour présenter des informations exploitables, aĄn dŠaider les dirigeants, les
managers et les utilisateurs Ąnaux ‘a prendre des décisions éclairées. Cette approche
utilise une variété dŠoutils, dŠapplications et de méthodes pour collecter des données ‘a
partir de sources internes et externes, les préparer pour lŠanalyse, exécuter des requêtes
et créer des rapports, des tableaux de bord et des visualisations des données. Ces
éléments sont ensuite mis ‘ a disposition du personnel opérationnel et des décideurs pour
une meilleure compréhension des données et une prise de décision plus éclairée [1]
2.1.2 Base de donnée intermédiaire ODS (Un Operational Data Store) :

- DéĄnition :
Un Operational Data Store (ODS) est une structure intermédiaire de gestion des
données,utilisée pour stocker et intégrer des données provenant de différentes sources
opérationnelles au sein dŠune organisation. LŠODS joue un rôle central dans les syst‘emes
dŠinformation en permettant lŠacc‘es aux données en temps réel ou quasi-réel, ce qui le
9
2.1. Contexte décisionnel : 10
différencie des entrepôts de données traditionnels. LŠutilité de lŠODS réside dans sa

capacité ‘a fournir une vue consolidée et cohérente des données opérationnelles.
- Les caractéristique dŠun Operational Data Store (ODS) :
- LŠODS permet dŠintégrer les données provenant de multiples sources opérationnelles,
offrant ainsi une vision uniĄée des données et facilite les analyses et les rapports.
- LŠODS est souvent utilisé comme une étape intermédiaire dans le processus dŠalimen-
tation des entrepôts de données. Les données sont dŠabord intégrées et nettoyées dans
lŠODS, puis transférées vers lŠentrepôt de données pour des analyses plus approfondies
et des rapports stratégiques.
- En résumé, un Operational Data Store est une base de données qui permet lŠintégration
des données opérationnelles provenant de différentes sources. LŠODS joue un rôle cru-
cial dans les syst‘emes dŠinformation en fournissant des données précises et ‘a jour pour
la prise de décisions opérationnelles [2].
2.1.3 LŠentrepôt des données :

- DéĄnition : LŠentrepôt de données, aussi connu sous le nom de Data Warehouse,
est une base de données relationnelle qui rassemble un volume important de données
provenant de multiples sources au sein dŠune entreprise. Son principal objectif est de
faciliter les requêtes, lŠanalyse de données et la prise de décisions plutôt que de gérer
les transactions ou autres fonctions traditionnelles des bases de données. En dŠautres
termes, il sŠagit dŠun outil privilégié pour lŠanalyse et la compréhension des données de
lŠentreprise, plutôt que pour leur gestion au quotidien.
- Les caractéristiques de LŠentrepôt des données :
LŠentrepôt de données doit suivre une orientation par sujet, ce qui implique que les infor-
mations doivent être organisées en fonction des sujets tels que les ventes, le marketing,
etc. En outre, il doit être capable dŠintégrer des données provenant de différentes sources
en un format cohérent, ce qui est essentiel pour la création dŠun référentiel unique de
données Ąables. Une autre caractéristique importante de lŠentrepôt de données est quŠil
doit être statique (non volatiles).Ce qui signiĄe que les données quŠil contient ne doivent
pas être modiĄées.
EnĄn, il doit également être capable de stocker des données historiques, ce qui permet
de suivre les changements et les évolutions sur une période déĄnie.
- Les avantages de lŠentrepôt des données :
LŠentrepôt de données présente plusieurs avantages, notamment :
- Pour les entreprises :
• Possibilité dŠaméliorer les opérations et lŠefficacité.
• Potentiel dŠaugmentation des revenus et des bénéĄces.
-Pour les responsables informatiques :
• Capacité ‘ a séparer le processus dŠanalyse du processus opérationnel pour améliorer
les performances.
• En dŠautres termes, lŠentrepôt de données permet aux entreprises dŠoptimiser leurs
activités et de générer des bénéĄces supplémentaires, tandis que pour les responsables
informatiques, il facilite la séparation des processus dŠanalyse et dŠopérations pour
améliorer les performances globales [3].
2.1.4 Data Mart

Un data mart est une composante dŠun entrepôt de données, qui est structuré
pour répondre aux besoins spéciĄques dŠun seul département ou dŠune seule fonction
au sein dŠune entreprise. Il sŠagit dŠun sous-ensemble de données qui est conçu pour
permettre une analyse plus approfondie et plus ciblée de lŠinformation pour une unité
organisationnelle particuli‘ere, plutôt que pour lŠensemble de lŠentreprise. En résumé, un
data mart est une version spécialisée et adaptée dŠun entrepôt de données pour répondre
aux besoins particuliers dŠun département ou dŠune fonction . - Les avantages de
Datamart :
Les data marts présentent plusieurs avantages, tels que :
• Un acc‘es simple et rapide aux données requises
• La disponibilité de données de base
• LŠoptimisation du temps de réponse pour les utilisateurs Ąnaux
• Une mise en place facile
• Un coût de création inférieur ‘a celui dŠun entrepôt de données
• Un meilleur contrôle des données.
- En somme, les data marts offrent des avantages signiĄcatifs en termes dŠacc‘es et de
contrôle des données, de rapidité et de coûts par rapport ‘a la création dŠun entrepôt de
données complet [4].
2.1.5 Comparaison entre un Data Warehouse et un Datamart

Le tableau suivant représente la différence entre un entrepôt de données et un Da-
tamart :[5]
Figure 2.1 Ű Tableau dŠun entrepôt de données VS un Datamart
La Ągure suivante sigiĄe que datamart représente un sous-ensemble dans dataware-

house :
Figure 2.2 Ű Data Warehouse VS Data Mart
2.1.6 Conception dŠun entrepôt de données

- La table des Faits :
Dans un entrepôt de données, la table des faits est considérée comme la table prin-
cipale car elle représente le sujet dŠanalyse. Cette table est composée de deux types
de colonnes : les clés étrang‘eres qui font référence aux clés primaires des tables de
dimension, et les mesures des processus métiers qui sont des valeurs numériques. [6]
Figure 2.3 Ű Exemple dŠune table de fait
- Les mesures :
Une mesure est une propriété qui permet de réaliser des calculs pour évaluer un
indicateur de performance, tels que la quantité vendue, le chiffre dŠaffaires, etc.
- Les dimensions :
Une dimension est une table qui représente un axe dŠanalyse dans un entrepôt de
données. Elle est composée dŠune clé primaire et dŠun ou plusieurs attributs regroupés
en fonction des éléments clés de lŠentreprise.
Figure 2.4 Ű Exemple dŠune table de dimension

2.1.7 Chaı̂ne décisionnelle dŠun projet BI

- La phase dŠalimentation : dans le processus de gestion des données consiste ‘a collec-
ter, nettoyer et consolider les données ‘a lŠaide dŠoutils ETL (Extract Transform Load).
Cette phase nécessite la mise en place de processus ETL pour extraire les données ‘a
partir de différentes sources de stockage, les convertir en un format standardisé, les
nettoyer et les consolider. Cependant, malgré lŠamélioration de la standardisation des
échanges entre les différents syst‘emes informatiques, les syst‘emes dŠinformation dŠen-
treprise restent souvent hétérog‘enes et les formats des données sont encore tr‘es variés.
Cette disparité représente lŠobstacle technologique majeur aux échanges étendus dŠin-
formation.
- Phase de modélisation et de stockage : permet de stocker les données sous une

forme adaptée . Parce que les requêtes décisionnelles sont tr‘es consommatrices en res-
sources machines, les données doivent être stockées dans une base spécialisée , lŠentrepôt
de données ou datawarehouse . Le datawarehouse se charge de stocker et centraliser les
données en vue de la constitution du syst‘eme dŠinformation décisionnel .
- La phase de restitution ou de distribution de lŠinformation : est un processus clé

dans la Business Intelligence. Elle permet dŠutiliser les outils de restitution des données
pour distribuer les informations de mani‘ere accessible aux différents utilisateurs en
fonction de leurs besoins. Pour cela, le portail décisionnel EIP joue un rôle central en
facilitant la distribution de lŠinformation ‘a tous les partenaires internes de lŠentreprise.
Avec lŠémergence de la BI 2.0, basée sur les capacités du web 2.0, lŠaccessibilité ‘a lŠin-
formation décisionnelle est considérablement démocratisée pour les entreprises.
- La phase dŠanalyse et dŠexploitation est la derni‘ere étape du processus de Busi-

ness Intelligence, dans laquelle les utilisateurs Ąnaux jouent un rôle essentiel. Ils ont
pour mission dŠexploiter et dŠanalyser les données qui leur sont fournies en fonction
de leurs besoins. Différents types dŠoutils sont disponibles pour faciliter cette tâche,
tels que les outils OLAP, qui permettent des analyses multidimensionnelles, les outils
de data mining pour détecter des corrélations peu évidentes, les tableaux de bord qui
présentent des indicateurs clés pour suivre la performance, et les outils de reporting
pour communiquer sur les résultats obtenus [7] .
2.2. Méthodologie de réalisation dŠun projet 15
Figure 2.5 Ű Les étapes dŠun projet BI
2.2 Méthodologie de réalisation dŠun projet

Pour réaliser et réussir, il est important de suivre une approche adaptable . Il existe
différentes méthodologies ‘ a suivre : entre la simplicité des unes et lŠefficacité des autres
, une étude comparative doit être faite pour garantir le choix adéquat .
2.2.1 Méthode classique

Les approches classiques de gestion de projet sont caractérisées par une séquence
rigide et standardisée dŠétapes prédéĄnies. Cette séquence commence par la collecte des
besoins, suivie de la déĄnition du produit, de son développement et de ses tests, pour
Ąnir par sa livraison.
Ces étapes sont généralement suivies selon un mod‘ele en cascade ou en V comme le
montre la Ągure ci-dessous :
Figure 2.6 Ű Mod‘ele classique de réalisation dŠun projet en V

Ce cycle consiste ‘a prévoir des phases séquentielles ou il faut valider lŠétape précédente
pour passer ‘ a la suivante . Du côté des risques du projet , ils seront identiĄés tardive-
ment car il faut attendre jusquŠ a‘ la Ąn du développement aĄn de passer ‘a la phase de
test . En Effet , plus le projet avance , plus lŠimpact des risques augmente : il sera plus
coûteux et difficile de revenir en arri‘ere lorsquŠon détecte une anomalie tardivement .Il
est si évident que les méthodes classiques ne conviennent pas aux nécessités évolutives
dŠun projet BI .
LŠimpact des risques détectés tardivement est ‘a éviter . En revanche , dŠautres
alternatives existantes sont proposées et par la suite , elles sont étudiées [8].
2.2.2 Méthodes Agiles

La méthode agile est une approche de gestion de projet et de développement itérative
tr‘es populaire dans les agences de marketing et les entreprises technologiques.
En dŠautres termes, la méthode agile se concentre sur lŠautonomie des individus, im-
plique fortement le client et permet une grande réactivité aux demandes du client, ce
qui facilite une prise de décision plus rapide. Cette approche de développement repose
sur un cycle itératif, incrémental et adaptable [9].
2.2.3 Comparaison Méthodes Classiques VS Méthodes Agiles

Le tableau explique la différence entre les deux méthodes [10] :
Axe de compa- Méthodes Agiles Méthodes Classiques

raison
Orientation Programmation,développement Programmation,développement web
web
PlaniĄcation Adaptive Prédictive
Cycle de vie Itératif et incrémental long et sans rétroaction possible
Equipe Une équipe responsabilisée ou Une équipe avec des ressources
lŠinitiative et la communica- spécialisées, dirigées par un chef de
tion sont privilégiées, soutenue projet
par le chef de projet
Flexibilité Accueil favorable au change- Résistance aux changements puisquŠils
ment sont généralement risqués et coûteux
Livraison de la Rapide, partielle et Généralement tardive
solution incrémentale
Table 2.1 Ű Méthodes agiles Vs méthodes classiques

Figure 2.7 Ű Comparaison entre les différent méthode
2.2.4 Le choix de méthode convenable de travail

Apr‘es avoir comparé différentes approches, nous avons décidé que la méthode agile
serait la plus appropriée pour notre projet. Cette méthode est cohérente avec le concept
dŠentrepôt de données proposé par Ralph Kimball. Grâce ‘a lŠapproche agile, nous pou-
vons facilement
De plus, nous avons constaté que lŠune des forces de notre équipe de développement
était sa capacité ‘
a collaborer et ‘a communiquer efficacement. Pour ces raisons, nous
avons opté pour la méthode agile Scrum, qui est particuli‘erement bien adaptée ‘a notre
projet.
2.2.5 Présentation du méthode SCRUM

La méthodologie Scrum signiĄe mêlée en français, est basée sur les valeurs et lŠesprit
du jeu de rugby. Elle est issue des travaux de Sutherland et Schwaben, les signataires
du Manifeste Agile, et fait partie des méthodes itératives et incrémentales.
Cette approche est conçue pour être utilisée dans des environnements de travail qui
permettent la réalisation de projets considérés comme complexes. Bien quŠelle soit prin-
cipalement adaptée ‘ a la gestion de projets logiciels, elle peut également être appliquée
a‘ dŠautres types de projets, quŠils soient simples ou innovants.

En Scrum, le client joue un rôle plus actif dans le suivi de lŠavancement du projet et
lŠapprobation des livrables. Cela lui permet de suivre réguli‘erement lŠévolution des tra-
vaux et de demander des modiĄcations ou exprimer des insatisfactions.
La méthodologie Scrum assure ainsi une meilleure prévisibilité du projet et permet de
contrôler les risques.
- Les intervenants dans SCRUM
LorsquŠon compare un projet séquentiel ‘a un projet agile, on observe des différences
au niveau des missions et des responsabilités des intervenants. Dans un projet agile, une
importance particuli‘ere est accordée ‘a lŠappropriation de tous les éléments du sprint
par les membres de lŠéquipe.
La méthodologie SCRUM déĄnit en trois rôles :
Acteurs Tâches
Le Product Owner Le porte-parole des clients a pour responsabilité de déĄnir soigneu-
(PO) sement le backlog. Cela implique de recueillir les besoins du client,
les spéciĄcations du produit ainsi que toutes les fonctionnalités du
projet ‘a réaliser. Le propriétaire du produit est également chargé de
classer les éléments du backlog par ordre de priorité et dŠindiquer
lŠordre dans lequel ils doivent être réalisés.
Le Scrum Master LŠanimateur dŠéquipe joue un rôle essentiel dans la coordination et la
facilitation du travail de lŠéquipe. Son rôle principal consiste ‘
a veiller
au bon déroulement du projet et ‘a résoudre les probl‘emes et les
obstacles qui entravent le progr‘es de lŠéquipe. LŠanimateur dŠéquipe
agit en tant que coordinateur et facilitateur, travaillant main dans
la main avec les membres de lŠéquipe pour assurer une collaboration
efficace et une réalisation harmonieuse des tâches.
Le Scrum Team LŠéquipe de développement est chargée de la livraison des éléments
(lŠéquipe de travail) de chaque sprint, en respectant leur ordre de priorité. Cette équipe
est composée dŠarchitectes, de développeurs et dŠadministrateurs de
bases de données.
Table 2.2 Ű Rôles des intervenants dans SCRUM
- Les artéfacts du SCRUM :
Le tableau ci-dessous descriptives des artéfacts du SCRUM :

Artéfacts Description
Product Backlog. Le carnet des produits, également appelé Product Backlog, est une
liste structurée qui regroupe les exigences, les besoins du client et
les spéciĄcations liées ‘a un produit donné. Le Le Product Owner est
chargé du Product Backlog ,en termes du contenu, de la disponibilité
et de lŠordonnancement du Product Backlog.
Sprint Backlog Le sprint Backlog est un élément essentiel pour suivre la progression
du travail de lŠéquipe de développement. Chaque sprint est conçu
pour répondre aux attentes du Product Owner et garantir lŠaccom-
plissement des objectifs préalablement déĄnis au début du sprint. Le
sprint Backlog constitue un plan détaillé des tâches ‘a réaliser
Sprint Burn-Down Le graphique dŠavancement est une représentation visuelle qui per-
Chart met dŠobserver lŠévolution de la quantité de travail restant par rap-
port au travail déj‘a accompli. LŠaxe vertical représente le travail res-
tant, tandis que lŠaxe horizontal représente le temps. Ce type de
graphique offre une vision anticipée de lŠavancement du travail sur
une période donnée, ce qui permet de suivre le déroulement de lŠac-
tivité.
Table 2.3 Ű Description des artéfacts du SCRUM
- Les événements de Scrum :

Scrum est une méthode agile qui comprend cinq événements importants pour soutenir
les équipes dans leur agilité. Ces événements perturbent la vie quotidienne de lŠéquipe
et favorisent la collaboration et la livraison itérative du produit .
• Sprint :
Un sprint est une itération de courte durée, généralement de 2 ‘a 4 semaines, au
cours de laquelle lŠéquipe sŠengage ‘a livrer un incrément de la solution Ąnale. Chaque
sprint a une durée Ąxe, un objectif clair et un périm‘etre déĄni dans le Sprint Backlog.
LŠéquipe et le Product Owner peuvent renégocier le périm‘etre du sprint au besoin.
• PlaniĄcation dŠun sprint :
La planiĄcation dŠun sprint est une réunion o‘ u le Product Owner et lŠéquipe se
réunissent pour planiĄer la nouvelle itération. Le Product Owner présente les différents
éléments du Product Backlog a‘ lŠéquipe, triés en fonction de leur valeur. LŠéquipe
sélectionne ensuite les éléments quŠelle estime pouvoir réaliser pendant le sprint et les
ajoute ‘ a son Sprint Backlog. LŠobjectif du sprint, appelé sprint Goal, est déĄni lors de
cette réunion pour guider lŠéquipe.
• Mêlée quotidienne (Daily Scrum) :
La mêlée quotidienne est une réunion quotidienne, dŠune durée maximale de 15
minutes, o‘ u toute lŠéquipe se synchronise. Chacun expose ce quŠil a accompli depuis
la derni‘ere mêlée, ce quŠil prévoit de faire dŠici la prochaine mêlée et sŠil rencontre des
obstacles. LŠéquipe utilise un tableau Scrum avec des notes adhésives pour visualiser
lŠavancement des tâches (‘a faire, en cours, terminées). La mêlée quotidienne favorise la
transparence et la collaboration au sein de lŠéquipe.
• Revue du sprint (Sprint Review) :
La revue du sprint est une réunion qui permet de boucler la boucle de rétroaction
et dŠadapter en continu le développement du produit. Toutes les personnes concernées
par le projet participent ‘ a cette réunion pour discuter de ce qui a été réalisé pendant le
sprint. Les résultats obtenus sont valorisés et priorisés, et le Product Backlog est ajusté
en conséquence pour la prochaine itération. La revue du sprint peut durer jusquŠ‘a 4
heures.
• Rétrospective du sprint (Sprint Retrospective) :
La rétrospective du sprint est un moment essentiel pour lŠéquipe aĄn dŠévaluer
ce qui sŠest passé pendant le sprint et favoriser lŠamélioration continue. LŠobjectif de
cette réunion est de recueillir les retours de chaque membre de lŠéquipe sur ce qui a
bien fonctionné, ce qui peut être amélioré et les actions ‘a entreprendre pour le prochain
sprint. La rétrospective du sprint permet ‘a lŠéquipe de sŠauto-organiser et de sŠaméliorer
constamment. Ces cinq événements constituent un cadre solide pour la gestion de projet
agile en utilisant la méthode Scrum. Ils favorisent la collaboration, la transparence et
lŠadaptation continue, ce qui permet aux équipes de développer des produits de mani‘ere
itérative et efficace [14]
Figure 2.8 Ű Processus SCRUM

2.2.6 LŠapproche SCRUM appliquée ‘

a un projet BI : (Les méthodologie
de conception du Data warehouse )
Le projet décisionnel est un projet complexe qui doit répondre aux besoins évolutifs
des utilisateurs qui prennent des décisions critiques dans un environnement instable
et en constante évolution. La Ąnalité de la Business Intelligence est de répondre ‘a
ces besoins. Toute décision comporte un risque, dŠautant plus dans un environnement
incertain, il est donc indispensable dŠimpliquer les utilisateurs dans le développement
de la solution. Pour cela, la méthode agile SCRUM est recommandée pour élaborer un
projet BI. Il existe plusieurs approches ‘a appliquer sur ce type de projet [15] :
• LŠapproche BOTTOM UP
• LŠapproche TOP DOWN
• LŠapproche MIDDLE OUT
- SCRUM est lŠapproche TOP DOWN (Inmon) :
LŠapproche Top Down pour un projet décisionnel implique de créer dŠabord un
entrepôt de données exhaustif o‘ u toutes les informations sont stockées de mani‘ere
détaillée, puis de créer des Data Marts ‘a partir de cet entrepôt. Bien que cette méthode
soit la plus compl‘ete, elle est également la plus lourde.
- SCRUM est lŠapproche BOTTOM UP (Kimball) :
LŠapproche Bottom-Up pour un projet décisionnel consiste ‘a créer des Data Marts
un par un, puis ‘ a les combiner pour former un Data Warehouse. Contrairement ‘a la
méthode dŠInmon, cette approche est plus simple.
LŠapproche Bottom-Up Kimball de conception dŠune maison Dataware a été introduite
par Ralph Kimball. Cette approche commence par la reconnaissance des processus
métier et des questions auxquelles Datawarehouse doit répondre. Ces ensembles dŠin-
formations sont analysés puis bien documentés. Le logiciel Extract Transform Load
(ETL) rassemble toutes les données de plusieurs sources de données appelées magasins
de données, puis est chargé dans une zone commune appelée staging. Ensuite, celui-ci
est transformé en cube OLAP .
- SCRUM est lŠapproche MIDDLE OUT (hybride) :
LŠapproche Middle-Out pour un projet décisionnel est considérée comme hybride et
est recommandée par les professionnels de la BI. Elle implique de concevoir enti‘erement
lŠentrepôt de données, cŠest-‘ a-dire de concevoir toutes les dimensions, tous les faits et
toutes les relations, puis de le diviser en parties plus petites et plus gérables pour
les implémenter. Cela revient ‘ a découper notre conception en éléments communs et ‘a
réaliser ces découpages un par un.
- Comparaison entre trois lŠapproche :
Approches Bottom Up Top Down Middle Out

LŠapproche
commence par une
Les données sont planiĄcation et une
collectées et conception
intégrées ‘
a partir de stratégiques pour LŠapproche utilise
sources créer un mod‘ele de un processus itératif
opérationnelles données global qui o‘u des entrepôts de
individuelles pour est ensuite données plus petits
créer des entrepôts décomposé en sont créés pour des
de données entrepôts de données unités spéciĄques de
départementaux, qui plus petits et plus lŠorganisation, puis
sont ensuite intégrés spéciĄques, pour les intégrés en un seul
en un seul entrepôt différentes unités entrepôt de données
Description de données. organisationnelles. global.
La capacité ‘a fournir
La Ćexibilité pour des résultats plus
répondre aux rapidement que la
besoins des La compatibilité méthode Top-Down
utilisateurs avec des grandes et ‘a permettre une
individuels, et la entreprises et la personnalisation
facilité de mise en facilité dŠobtenir des pour les besoins
place pour des informations spéciĄques de
Avantages projets plus petits. globales. chaque département.
Les projets peuvent
Coût initial élevé devenir trop
Risque de pour créer un complexes et
redondance de mod‘ele de données difficiles ‘a gérer si la
données, de manque global complet, et la planiĄcation initiale
dŠuniformité, et de difficulté de le nŠest pas
Inconvénients conĆits de données. maintenir. suffisamment solide.
Les entreprises qui
Les petites et Les grandes ont des besoins
moyennes entreprises ont spéciĄques pour des
entreprises avec des besoin de cohérence départements
Utilisation besoins spéciĄques dans leurs données. individuels.
Table 2.4 Ű Backlog Produit
- Choix de lŠapproche adaptée :

Dans notre projet, nous avons opté pour lŠapproche Bottom-Up pour plusieurs rai-
sons, dŠune part nous voulons limiter notre exposition aux risques liés ‘a la perte de
données et dŠautre part, parce que cette approche est caractérisée par sa simplicité et
son coût de déploiement le moins élevé.
2.3. Environnement de travail 23
2.3 Environnement de travail

Le but de cette section est dŠintroduire les outils utilisés pour mettre en place notre
syst‘eme décisionnel. Ces outils sont mentionnés dans le tableau selon les phases de
notre projet, en prenant en compte les avantages de ces choix.
• Modélisation du Data Warehouse : SQL server :
- Création et modiĄcation rapide des bases de données.
- Modélisation multidimensionnelle.
- Gestion des utilisateurs des serveurs des bases de données.
- Enregistrement et connexion des serveurs sur site et ‘a distance.
- Surveiller les performances de la base de données et du serveur SQL.
Figure 2.9 Ű SQL server
• Intégration des données (ETL) : SSIS et SSAS :

- SSIS est compl‘etement intégré dans Visual Studio .
- Intégration de gros volumes de données ‘a hautes performances.
- Notion de package qui facilite le processus de transformation des données pour
éviter la lourdeur et la complexité des développements.
- Outils graphiques et assistants incluent plusieurs fonctions de transformations
prédéĄnies (agrégation, fusion des données, tri,etc)
- SSAS prend en charge la modélisation multidimensionnelle (modélisation en cubes
OLAP)
Facilite la gestion des relations de jointure et des clés étranger dans le mod‘ele.
Figure 2.10 Ű Visuel studio 2010

• Power BI :
-Supporté par plusieurs applications telles quŠAndroid ou encore grâce ‘a un acc‘es
en ligne.
- Des tableaux de bord personnalisés ainsi que des rapports interactifs.
- Une large palette de visuels.
- Gagner en réactivité et productivité face aux concurrents.
- Outils dŠanalyse connecter ‘a des bases des données SQL Server , des mod‘eles
Analysis Services ainsi que de nombreuses autres sources des données.
Figure 2.11 Ű Power BI
• Python :
- Peut être utilisé dans Power BI pour effectuer des opérations de prétraitement des
données avancées .
- Créer des graphiques et des visualisations spéciĄques en utilisant des biblioth‘eques
Python telles que Matplotlib, Seaborn ou Plotly.
- Peut être utilisé dans Power BI pour effectuer des opérations de prétraitement des
données avancées.
Peut être utilisé pour extraire et transformer des données provenant de sources
multiples et complexes.
Figure 2.12 Ű Python
Conclusion
Dans ce chapitre, nous avons mis un projet BI dans son contexte. Nous avons
débuté avec la déĄnition et la comparaison des trois méthodologies et des trois mod‘eles
du travail aĄn de sélectionner la méthode la plus adéquate ‘a notre solution.
Par la suite, nous avons précisé les outils avec lesquels nous allons travailler. Quand
au chapitre suivant, on va passer au troisi‘eme chapitre qui va analyser et spéciĄer les
besoins.
3 Sprint 0 : Etude fonctionnelle :
Introduction
Ken Schwaber, le co-créateur de Scrum, reconnaı̂t que lŠutilisation du terme ŤSprint

0Ť sŠimposé pour décrire la phase de préparation avant le démarrage du projet est deve-
nue de plus en plus courante dans le contexte de Scrum. Cette expression, plus simple
que Ťphase de préparationŤ ou ŤinscriptionŤ, ne compromet en aucun cas la Ćexibilité
de notre projet, bien que, au contraire.En effet, il nous octroie la possibilité dŠanticiper
certains mesures et dŠacquérir une vision holistique, ce qui facilitera lŠadaptation aux
changement qui surgiront au Ąl des sprints subséquents .
Dans ce chapitre, on va étudier les besoins fonctionnels et non fonctionnels du

syst‘eme de décision , de même que présenter le backlog de produit et enĄn la conception
de notre entrepôt de données .
3.1 Analyse des données

La premi‘ere étape du sprint 0 consiste ‘a analyser la situation pour tenir compte
des exigences du client et répondre ainsi ‘a ces besoins . Cette section sera dédiée ‘a la
présentation du potentiel des utilisateurs de notre solution ainsi que la déĄnition de
leurs besoins fonctionnels et non fonctionnels .
3.1.1 SpéciĄcation des besoins fonctionnelles

La nécessité de déĄnir les besoins fonctionnels aide ‘a préciser les objectifs majeurs
pour les décideurs . Au cours de cette partie, on va exposer ses besoins ou exigences
fonctionnels : Améliorer la génération des rapports dŠune façon dynamique contenant
des Ąltres que lŠutilisateur en tant que décideurs peut les appliquer selon ses besoins et
26
3.2. Backlog produit : 27
regroupant les principaux indicateurs de performance pour une meilleure ‘a la prise de

décision . (automatiser le syst‘eme décisionnel )
3.1.2 SpéciĄcation des besoins non fonctionnelles :

Dans la précédente , nous avons noté les exigences fonctionnelles. Par la suite, nous
allons présenter les besoins non fonctionnels que tout syst‘eme dŠaide ‘a la décision doit
prendre en considération .
Ce sont des exigences qui ne concernent pas particuli‘erement le comportement du sys-
t‘eme, mais plutôt déterminent des contraintes internes et externes du syst‘eme. Les
principaux besoins non fonctionnels de notre application se résument dans les points
suivants :
• Fiabilité : Les données exploitées doivent être soumises ‘a des transformations et des
vériĄcations garantissant leur Ąabilité ce qui est fourni grâce ‘a lŠoutil lŠETL adapté
visuel studio (SSIS).
• Communicabilité : lŠapplication doit fournir des interfaces qui facilitent la communi-
cation entre lŠutilisateur et cette derni‘ere.
• Performance : le syst‘eme doit fournir un temps dŠattente et de réponse minimal.
•Convivialité : LŠapplication potentielle doit être facile ‘a utiliser. En effet, les interfaces
utilisateurs doivent être conviviaux, simples, ergonomiques et adaptés ‘a lŠutilisateur.
• Capacité : la capacité de serveur doit être suffisante pour pouvoir exécuter lŠappli-
cation et sauvegarder les données.
3.2 Backlog produit :

Dans cette partie, nous allons déĄnir le Backlog du produit, qui joue un rôle
prépondérant en guidant lŠéquipe de développement. Il sŠagit dŠun outil de travail es-
sentiel qui rassemble toutes les caractéristiques du produit. Il se présente sous la forme
dŠune liste de tâches prioritaires déĄnissant les différents aspects du produit. Il consti-
tue lŠun des piliers fondamentaux de la méthodologie SCRUMŤ.
Le détenteur du produit, également appelé ŤProduct OwnerŤ, assume la responsabilité
de déĄnir les exigences en fonction des priorités établies par ce dernier.
Notre Backlog est déĄnie comme suit :
3.3. PlaniĄcation du projet 28
Théme ID Tâches Préorités

Création dŠune Créer la base de données
base de intermédiaires ODS pour
données rassembler les données historiques
intermédiaire provenant de différentes sources et
ODS US 1 réaliser les jointures nécessaires Haute
Développement Concevoir et mettre en place une
dŠun syst‘eme datawarehouse contenant toutes les
ETL et données historiques détaillées pour
construction disposer dŠun mod‘ele entrepôt de
dŠun entrepôt données qui garde les traces des
de donnée US 2 données chargées Haute
Création dŠune
base de Développer des tableaux de bord
données pour une vision globale et une prise
intermédiaire de décision éclairé, ainsi que rester
ODS US 3 constamment informé Haute
Table 3.1 Ű Backlog Produit
3.3 PlaniĄcation du projet
3.3.1 Pilotage du projet avec la méthodologie SCRUM

LŠéquipe de notre projet est composée de trois membres représentés par la Ągure :
- Le Product Master est Mr Mohamed Ayadi Ghaith ‘a FSJEGJ .
- Le Product Owner est Mr Bassem Thebti , le directeur général de la société Virtual-
Dev.
- La team membre est Nouha Ben Hrak .
Figure 3.1 Ű Equipe scrum

3.4. Conception général de lŠentrepôt de données 29
3.3.2 Découpage de la solution en Sprint
Figure 3.2 Ű Répartition des Sprints
3.4 Conception général de lŠentrepôt de données
3.4.1 Conception général de lŠentrepôt de données

La modélisation dimensionnelle est une approche de conception logique de data-
warehouse qui consiste ‘ a organiser les données sous la forme dŠune structure divisée en
table de fait et dimension nŠadhérant pas aux normes recommandées dans les bases de
données relationnelles . Cette pratique facilite la compréhension des données par les
utilisateurs Ąnaux , améliore la performance des requêtes et permet lŠextensibilité et
lŠadaptation des mod‘eles aux changements . Il y a 3 mod‘ele de conception :
- Mod‘ele en Étoile
- Mod‘ele en Flocon de neige
- Mod‘ele en Constellation
* Schéma en étoile :
Le schéma en étoile est considéré comme le mod‘ele le plus élémentaire parmi les
schémas de modélisation multidimensionnelle. Il consiste en une table de faits centrale
qui représente le sujet dŠanalyse, entourée de tables de dimensions qui correspondent
aux différents axes dŠanalyse [16].
Figure 3.3 Ű Exemple dŠun schéma en étoile
* Schéma en Ćocon de neige :

Le schéma en Ćocon de neige, qui est basé sur le schéma en étoile, se distingue par
lŠutilisation de la normalisation aĄn de réduire la redondance des données. Contrai-
rement au schéma en étoile, le schéma en Ćocon de neige utilise des tables de sous-
dimensions pour créer une structure hiérarchique de tables de dimensions. En plus de
la table de faits centrale, ce mod‘ele comprend des tables de dimensions et des tables
de sous-dimensions pour organiser les donnéesde mani‘ere plus efficace [17].
Figure 3.4 Ű Exemple dŠun schéma en Ćocon de neige
* Schéma en constellation :
Le principe fondamental du mod‘ele en constellation est de fusionner plusieurs
schémas en étoile ou en Ćocon de neige dans un schéma unique comprenant plusieurs

tables de faits. Ces tables de faits partagent des dimensions communes qui leur per-
mettent dŠêtre intégrées de mani‘ere cohérente dans une même structure de données
[18].
Figure 3.5 Ű Exemple illustratif dŠun schéma en constellation
* comparaison entre les trois mod‘

eles multidimensionnelles
Mod‘ele Description Avantages Inconvénients

Peut y avoir
une
Facile ‘a duplication de
comprendre et données dans
‘a utiliser, les tables de
La table de performances dimensions, ce
faits est située de requêtes qui peut
au centre du rapides en entraı̂ner une
mod‘ele et est raison de la utilisation
entourée de simplicité de inefficace de
tables de la structure de lŠespace de
Étoile dimensions. données. stockage.
Peut être plus
complexe ‘a
comprendre et
Réduire la ‘a utiliser que
duplication le mod‘ele en
Basé sur le des données étoile en
mod‘ele en par rapport au raison de la
étoile, il utilise mod‘ele en structure plus
la étoile permet complexe. Les
normalisation une performances
pour réduire hiérarchisation de requête
la redondance des tables de peuvent
des données en dimensions également être
créant des pour une plus lentes en
tables de sous- meilleure raison de la
Flocon de dimensions compréhension complexité de
neige hiérarchiques. des données. la structure.
Peut être plus
difficile ‘a
comprendre et
Utilise ‘a modéliser en
plusieurs Permet une raison de la
tables de faits représentation complexité des
et de plus précise relations entre
dimensions in- des données les tables. Les
terconnectées complexes et performances
pour multidimen- de requête
représenter sionnelles, peuvent
des sujets offre une également être
dŠanalyse grande plus lentes en
complexes et Ćexibilité pour raison de la
multidimen- lŠanalyse de complexité de
Constellation sionnels. données. la structure.
Table 3.2 Ű : de la modélisation multidimensionnelle

Choix du mod‘ ele adapté Pour répondre aux besoins spéciĄques de lŠentreprise
VirtualDev dans le cadre de notre projet, nous avons choisi dŠadapter le mod‘ele de
données en constellation en tant quŠ un mod‘ele conceptuel, car notre datawarehouse
est constituée de plusieurs tables faits qui partagent les mêmes dimensions. Ce mod‘ele
a été sélectionné pour sa capacité ‘a gérer des relations complexes entre différentes
dimensions, telles que Lots, Fournisseur dŠaliment , Date , etc.
Le mod‘ele de données en constellation que nous avons adapté a permis ‘a lŠentreprise de
mieux comprendre ses performances de productions et commerciales et de prendre des
décisions plus éclairées en fonction des informations extraites de la base de données.
3.4.2 Approches pour la création de lŠentrepôt de données

Il existe trois mod‘eles de création de datawarehouse [19] :
. ROLAP : Les données sont stockées dans un SGBD relationnel . Un moteur OLAP
permet dŠanalyser la base multidimensionnelle .
Figure 3.6 Ű Mod‘ele ROLAP
.- MOLAP : Les données sont stockées dans des cubes ou nous pouvons accéder
directement aux données
Figure 3.7 Ű Mod‘ele MOLAP
.- HOLAP : Il sŠagit dŠun mixte hybride de ROLAP et MOLAP .

Figure 3.8 Ű Mod‘ele HOLAP
Il existe bien évidemment dŠautres approches telles que SOLAP (Spatial OLAP),
DOLAP (Desktop OLAP) , OOLAP (Object OLAP), . . .. mais qui restent tout de
même peu utilisées .
- Dans notre cas , nous avons choisi lŠapproche ROLAP pour notre solution
3.4.3 3. Le diagramme général de la conception de lŠentrepôt de données
Figure 3.9 Ű Conception globale de lŠentrepôt de données

Notre schéma comporte les 3 tables de faits suivants :
Faits Libellé
Fait qui collecte les données
détaillées sur charges directes et les
Fact Couts de revient charges indirectes des coûts .
détaillées sur lŠétat des poissons et
FactP roduction les ordres de production .
détaillées sur les chiffres dŠaffaires
Fact Vente de poissons vendus .
Table 3.3 Ű Les faits du data-warehouse
Figure 3.10 Ű Aperçu sur les tables de faits «Fact Couts de revient» , «Fact Produc-
tion» et «Fact Ventet»
Nous listons les dimensions de lŠentrepôt de donnée (data-warehouse) comme présentent

les Ągures suivantes :
Dim-Date : Cette dimension représente lŠaxe dŠanalyse date .
Figure 3.11 Ű Aperçu sur la dimension «Date»

Dim-Lot : Cette dimension représente lŠaxe dŠanalyse Lot
Figure 3.12 Ű Aperçu sur la dimension «Lot»
Dim-Fournisseur-dAliment : Cette dimension représente lŠaxe dŠanalyse Fournisseur-

dAliment
Figure 3.13 Ű : Aperçu sur la dimension «Fournisseurd Aliment >>
Dim-Aliment : Cette dimension représente lŠaxe dŠanalyse Aliment.
Figure 3.14 Ű Aperçu sur la dimension «Aliment»
Conclusion
LŠoutput essentiel de ce chapitre étant le backlog du produit, il nous sera indispensable

tout le long de la réalisation de notre projet puisquŠil permet de préciser les fonction-
nalités ‘
a assurer pour répondre aux exigences du client . Bien que nous adaptons tout
de même une démarche AGILES cela signiĄe que ce product Backlog demeure Ćexible
et apte aux changements .
4 Sprint 1 : Préparation des données
Introduction Au cours de ce chapitre et dŠapr‘es la méthodologie Agile utilisée

≪ SCRUM BI ≫ Ce sprint N°1 sera dédié pour lŠalimentation de la base de données
intermédiaire ODS .
4.1 Backlog du sprint :

Le sprint backlog est lŠun des artéfacts proclamés par le cadre méthodologique
SCRUM. En Effet, il sŠagit de lŠensemble des tâches qui doivent être accomplies au
cours du sprint aĄn dŠatteindre son objectif . Dans notre projet , le premier sprint est
de construire une base de données intermédiaire ODS en raison de la voluminosité des
données provenant de différentes sources . Le tableau suivant représente les éléments
du Backlog de SPRINT 1 :
User story
ID User story Tâches
En tant quŠ analyste, je veux
créer une base de données 1.1 DéĄnir les tables
ODS qui englobe toutes les sources pour
données historiques et lŠextraction.
détaillées concernant le grand 1.2 Transformation de
volume des données données.
existantes et développer le 1.3 Chargement de
US 1 syst‘eme ETL. données .
Table 4.1 Ű : Backlog du sprint N°1
37
4.2. Etude des données source : 38
4.2 Etude des données source :

Cette section est consacrée pour lŠétude des données sources extraites du syst‘eme
dŠinformation de lŠentreprise avec lesquelles nous allons alimenter notre base de préparation
ODS . Pour des raisons de sécurité et de conĄdentialité ,il nŠétait pas possible que nous
ayons acc‘es aux serveurs de la société dans lesquels sont stockés des données person-
nelles des clients. Les données sources nous ont été livrées sous format SQL Server dans
une base de données nommée VMIND .
4.3 Préparation et alimentation de la base de donnée (ETL) :

Extract, Transform, Load (ETL) ou Extraire, Transformer, Charger est le processus
consistant ‘a extraire les données a‘ leur sources et ‘a les intégrer dans la base de données
ODS . Les données sont extraites des syst‘emes sources , nettoyées, harmonisées et
transformées sous forme adaptée aux analyses, et chargées dans la solution analytique.
Le logiciel ETL automatise le processus de conversion, de reformatage et dŠintégration
des données provenant de plusieurs sources opérationnelles .
Le processus ETL est le plus délicat et le plus important dans un syst‘eme décisionnel.
Donc, nous allons présenter en détails ce processus dans la partie suivante de lŠalimen-
tation de la base de données ODS .
4.3.1 Développement du Syst‘

eme ETL :
- ConĄguration des connexion aux base de données : La phase dŠextraction
des données se fait par la connexion ‘a la base de données.
Ű La premi‘ere étape est de choisir le serveur de connection
Ű Deuxi‘eme étape choisir entre SQL Server ou Windows : si lŠauthentiĄcation se fait
par SQL Server. Il faut obligatoirement entrer le nom dŠutilisateur et le mot de passe
et si par Windows il suffit de le choisir.
Ű La derni‘ere étape cŠest de choisir la base de données.
4.3. Préparation et alimentation de la base de donnée (ETL) : 39
Figure 4.1 Ű Gestionnaire de connexion ‘a la base de données SQL Server
- Création deux nouvelles base de données nommée (Ods)et (DWH) dans SQL
Server.
Figure 4.2 Ű Aperçu sur la création base de donnée Ods

Figure 4.3 Ű Aperçu sur la création base de donnée DWH
- LŠétape qui suit la création de la base au niveau de SQL Server, Pour ce faire, nous
avons créé un nouveau projet dans lŠenvironnement Visual Studio 2010 et nous avons
choisi ≪ Integration Service ≫ sous la rubrique ≪ Business Intelligence ≫ qui constitue
un ensemble de packages assurant le chargement des données comme indiqué dans la
Ągure 4.4.
Figure 4.4 Ű Création dŠun nouveau projet SSIS

Nous allons établir une connexion pour accéder aux sources de type OLEDB .
- Sélectionner le type de gestionnaire de connexion pour ajouter le package .
Figure 4.5 Ű Le type de gestionnaire de connexion du VMIND
- ConĄgurer le gestionnaire de connexion OLEDB pour la base de données VMIND.
Figure 4.6 Ű Aperçu sur la conĄguration le gestionnaire de connexion OLEDB VMIND

Figure 4.7 Ű Aperçu sur la conĄguration le gestionnaire de connexion OLEDB ODS
Figure 4.8 Ű Aperçu sur la conĄguration le gestionnaire de connexion OLEDB DWH

La Ągure ci-dessous représente lŠenvironnement de travail ( Intégrations Services).
Figure 4.9 Ű Paquet Integration Services
Le projet Integration Services est composé de plusieurs Packages, qui ‘a leurs tours
sont composés des Flux de contrôle et des Flux de données : Dans SSIS, lŠonglet Flux de
contrôle permet de gérer les tâches nécessaires aux transformations et les éléments de
contrôle que le package va exécuter. Au niveau de lŠonglet Flux de données, sŠeffectue
la sélection des données sources, les transformations quŠelles vont subir, et la précision
de leurs destinations.
Le schéma dans la Ągure 4.10 clariĄe la composition dŠun package simple.
Figure 4.10 Ű Composition dŠun Package SSIS simple

- Nous avons créé des packages pour construire les tables dans la base de données
ODS .
Figure 4.11 Ű Aperçu sur la liste des packages de chargement de la base de données
- Préparation de métadonnées (Extraction) :
Chaque package comporte une tâche de Ćux de données qui assure lŠextraction des
données et chaque tâche de Ćux de contrôle assure la mise ‘a jour des Tables.
Dans notre cas, nous avons eu recours ‘a une tâche ≪ Execute SQL Task ≫ que nous
avons nommée ≪ Vider la table . . . ≫ en utilisant la fonction ŞTRUNCATEŤ qui permet
dŠeffectuer une requête SQL ‘ a chaque exécution du package pour éviter la duplication
des données et ‘ a une tâche ≪ Data Flow Tasks ≫ qui comporte des requêtes SQL pour
la création et le chargement des tables ODS dans le Ćux du contrôle
* Table dimension : Table Ods Aliment
Figure 4.12 Ű Tâche dŠexécution de la requête SQL ≪ Vider ≫

Figure 4.13 Ű Résultat Control Ćow
- On ‘
a appliquer la connexion du sources de la base de données VMIND .
Figure 4.14 Ű Gestionnaire de connexion de la source

- Lors du choix du mode dŠacc‘es aux données, il est possible de sélectionner soit une
table, soit une vue . Pour cette raison, on utilise la Şcommande SQLŤ pour générer les
jointures aĄn de faciliter la création des requêtes et sélectionner les attributs nécessaires
.
Figure 4.15 Ű Sélection des attributs
- VériĄer et modiĄer les noms des attributs sélectionnés .
Figure 4.16 Ű Output Column
- Transformation de données :
Dans cette phase, les attributs de la table≪ Ods Aliment≫ sont issus de différentes
tables sources de la base de données initiale. En combinant la fonction de tri ŞSortŤ et
la transformation des doublons dans SSIS, dont le but de supprimer les duplications
des enregistrement dŠun Ćux de données .Cette approche est bénéĄque car on a besoins
dŠobtenir les enregistrement des ID de la table ‘a partir du source de données VMIND .
- Nous avons commencé par trier et éliminer les redondances dans chaque table.
Figure 4.17 Ű Editeur de transformation de ŞSortŤ
Une fois les transformations nécessaires effectuées et que les tables obtenues répondent
aux besoins de notre solution, il est temps de les charger dans une structure, que nous
avons déj‘
a créé dans SQL Server nommé ≪ ODS ≫.
- Puisque les données seront stockées dans SQL Server, nous avons choisi comme Des-
tination ≪ OLE DB ≫ dans SSIS comme indiqué dans la Ągure 4.18.
Figure 4.18 Ű Choix de Destination de Chargement de données

Nous avons commencé par charger les tables ‘a partir des données sources en assurant
‘a chaque fois le tri.
- Effectuer une vériĄcation de la connexion ‘a la base de destination ODS pour la création
de la table ŤAlimentŤ.
Figure 4.19 Ű Création de la table Aliment
- Réaliser le mappage de la table Aliment
Figure 4.20 Ű «Mapping» de la table Aliment

- La table Aliment ‘
a été créer et charger dans la base de données ODS par succé.
Figure 4.21 Ű Chargement de la table OdsA liment
- Le résultat de lŠalimentation de la table Ods Aliment sur SQL Server.
Figure 4.22 Ű Table OdsA liment
- Table Ods Lot

Nous avons créé un vue qui englobe toutes les historiques de la table Ods Lot pour
effectuer les jointures nécessaire de la requête dans la base de données VMIND .
Figure 4.23 Ű Vue LOTS

Figure 4.25 Ű Gestionnaire de connexion de la source

Figure 4.26 Ű Chargement de la table OdsL ot
Figure 4.27 Ű Table Ods Lot
- Table Ods Fournisseur dAliment :
Figure 4.28 Ű Gestionnaire de connexion de la table OdsF ournisseurd Alimentation

Figure 4.29 Ű Résultat Control Flow
Figure 4.30 Ű Chargement de la table Ods Fournisseur dAlimentation
Figure 4.31 Ű Table Ods Fournisseur dŠAlimentation

- Table Ods Date

Nous avons créé une dataset qui regroupe toutes les dates dans la base de données
VMIND.
Figure 4.32 Ű Création Data Set Date

Figure 4.33 Ű Gestionnaire de connexion de la table Ods Date

Figure 4.35 Ű Chargement de la table Ods Date
Figure 4.36 Ű Table Ods Date
Les tables faits
- Table Ods Production
Nous avons créé une vue dans la base de données VMIND nommée Prodt qui représente
les détails de la table Ods Production .
Figure 4.37 Ű La vue Prodt

La Ągure ci-dessous représente les jointures effectuer pour créer la table Ods Production.
Figure 4.38 Ű Les jointures réalisé dans la table Ods Production

Figure 4.40 Ű Chargement de la table Ods Production
Figure 4.41 Ű Table Ods Production
- Table Ods Cout de revient
On ‘ a ajouter une nouvelle colonne ŞisDirectChargesŤ dans la base de données

source VMIND dans la table nommée Şdbo.Matérials MatérialsSpeciĄcationŤ prenant
en consédiration les conditions suivants :
- Si on ‘
a Aliment ou Aleviens = 1 alors charges direct
- Si null = 0 alors charge indirect

Figure 4.42 Ű Création de la colonne isDirectCharges
Nous avons créé une table nommée Ş Historique Purchasing AllPurchasingBIŤ dans
la base de données source VMIND , puis nous avons créé une procédure pour importer
les données nécessaires ‘
a chaque fois on ajoute des factures dont des dates différentes .
Figure 4.43 Ű Création de la table Ş Historique Purchasing AllPurchasingBIŤ et

lŠexécution du procédure
Figure 4.44 Ű Résultat Control Flow

Nous avons utilisé la fonction pour ajouter seulement les charges indirects dont la
condition = 0
Figure 4.45 Ű Exécution de la condition Conditional Split
Figure 4.46 Ű Chargement de la table Ods Cout de revient
Figure 4.47 Ű La table Ods Cout de revient

- Table Ods Vente

La Ągure ci-dessous représente les jointures effectuer pour créer la table Ods Vente.
Figure 4.48 Ű Les jointures réalisés dans la table Ods Vente

Figure 4.50 Ű Chargement de la table Ods Vente
Figure 4.51 Ű Table Oda Vente
Conclusion
Au cours de ce sprint, nous avons effectué le processus ETL pour lŠalimentation de

la base intermédiaire ODS. Nous classons ce chapitre comme préparation de données
avant de les transformer et de les charger dans la data-warehouse .
5 Création du datawarehouse
Introduction
Durant ce chapitre, conformément ‘a la méthodologie Agile «SCRUM BI» , ce sprint

est spéciĄquement alloué ‘
a la conception et lŠalimentation du data warehouse ‘a partir
de la base de données ODS .
Nous commençons par la partie ETL jusquŠ‘a la conception du mod‘ele en constella-
tion de notre datawarehouse .
5.1 Backlog du sprint du datawarehouse

Le but de notre projet lors du deuxi‘eme sprint est de construire la datawarehouse
relative aux exigences de lŠutilisateur et générer par la suite les rapports interactifs
concernés.
Le tableau suivant représente les éléments du Backlog de SPRINT 2 :
User story
En tant quŠ analyste, je veux
développer le syst‘eme ETL 1.1 DéĄnition des indicateurs
pour créer une de performance (KPI).
datawarehouse qui englobe 1.2 DéĄnir les tables sources
toutes des données pour lŠextraction.
historiques et détaillées sur 1.3 Transformation de
les ordre du coût de revient, données.
US 2 du production et du vente. 1.4 Chargement de données.
Table 5.1 Ű Backlog du sprint N°2
62
5.2. Les indicateurs de performance du datawarehouse 63
5.2 Les indicateurs de performance du datawarehouse
5.2.1 Principe dŠun indicateur de performance (KPI)

CŠest un indicateur métrique conçu pour mesurer les avancées réalisées pour at-
teindre un but stratégique. Ces indicateurs de performance sont utilisés dans la présentation
des tableaux de bord.
Un bon indicateur de performance doit être pertinent, éviter les effets pervers,
attribuable, bien déĄnie en temps utile, Ąable, comptable, et vériĄable [20] .
5.2.2 Objectifs des indicateur de performance du datawarehouse
Objectifs Indicateur Axe dŠanalyse

Charge Direct
Charges indirectes
ChargesTotal
Cout Alevins
cout Aliment
Suivi lŠévolution CoutTraitement Par Lot
du coût de PecheKg Par Date
revient CoutRevient KG Par Fournisseur dAliment
BIOMASSE
DureeCycle
EffectActuel
EffectifInitiale
fuite
Mortalite
TauxMortalite
NbJourAlimentation
NbPeche
NbPoisson Par Aliment
QtAlimt Par Lot
Suivi de lŠétat de PM Par Date
production PMactuel Par Fournisseur dAliment
ChiffredŠaffaire Par Lot
Total Quantite Par Date
Suivi des ventes Poid Moyen Par Fournisseur dAliment
Table 5.2 Ű Objectifs et indicateurs du datawarehouse

5.3. Intégration des données ETL (Extraction, Transformation, Chargement) 64
5.3 Intégration des données ETL (Extraction, Transfor-

mation, Chargement)
Nous avons créé des packages pour construire les tables dans la base de données
DWH .
Figure 5.1 Ű Aperçu sur la liste des packages de chargement de la base de données
5.3.1 Extraction des données

Nous nous sommes basés sur les tables sources déĄnies dans notre base de données
aĄn dŠextraire les mesures et les dimensions dans lŠentrepôt de données en tenant compte
des relations et des contraintes établies.
- Table de dimension :
Nous allons transformer les tables ODS en table dimension dans la base de données
DWH .
Nous commençons tout dŠabord par transformer les tables ods en dimension dans la
datawarehouse, par lŠajout dŠune tâche dŠexécution de requête SQL qui permet de vider
la table et éliminer la redondance des lignes en utilisant la fonction ŞTRUNCATEŤ et
dŠune tâche de Ćux de données qui comporte des requêtes SQL pour la création et le
chargement des tables ODS dans le Ćux du contrôle .
• Table Dim-Date
Figure 5.2 Ű ConĄguration de la tâche dŠexécution de requête SQL «Vider»

Pour la premi‘ere partie de la phase ETL, nous devons récupérer les tables ‘a partir
de la connexion du base ODS.
La Ągure suivante présente la création de la connexion et de récupération de la table
Dim-Date :
Figure 5.4 Ű Récupération des tables de la connexion
Effectuer une vériĄcation de la connexion ‘a la base de destination DWH pour la

création de la table ŤDimDateŤ .
Figure 5.5 Ű Création de la table Dim-date

- Réaliser le mappage de la table Dim-Date
Figure 5.6 Ű «Mapping» DimD ate
Figure 5.7 Ű Chargement de la dimension Dim-Date
Figure 5.8 Ű Dimension Dim-Date dans DWH

Une fois que nous avons créé les dimensions dans la base de données DWH,nous
avons ajouté un champ nommé Ťclé artiĄcielleŤ ‘a chacune dŠentre elles . Cette clé
artiĄcielle est utilisée dans les table des faits pour établir les liens entre les dimensions
et les faits.
• Table Dim-Lot
Figure 5.9 Ű Création du clé artiĄcielle Id-chargement de la dimension Dim-

LotDimLot
Figure 5.10 Ű Chargement de la dimension Dim-Lot
Figure 5.11 Ű Dimension Dim-Lot dans DWH

• Table DimFournisseurAliment
Figure 5.12 Ű Création du clé artiĄcielle Id-DimFournisseurAliment
Figure 5.13 Ű Chargement de la dimension Dim-FournisseurdAliment
Figure 5.14 Ű Dimension Dim-FournisseurdAliment dans DWH

Table Dim-Aliment
Figure 5.15 Ű Création du clé artiĄcielle id-dimAliment
Figure 5.16 Ű Chargement de la dimension Dim-Aliment
Figure 5.17 Ű Dimension Dim-Aliment dans DWH

NB :
Dans cette étape la base de données intermédiaire Ods est devenue la source de
données puisquŠelle est chargée par les données détaillées aĄn de charger les données
agrégées dans la datawarehouse .
• Les tables faits
Nous allons transformé les tables ODS en table fait dans la base de données DWH
Dans cette phase, nous devons récupérer les tables ‘a partir de la connexion du base
ODS.
• Table Fact-cout-de-revient
La Ągure suivante présente la création de la connexion et de récupération de la table
Ods-cout-de-revient :
Figure 5.18 Ű Récupération des tables de la connexion
5.3.2 Transformation de données

Pour garantir la réussite dŠun ETL, il faut accorder une grande importance aux
transformations des données, sujet que nous allons traiter dans cette section.
Pour que les données soient signiĄcatives et utilisables plus tard lors de la génération
des rapports et des Tableaux de bord de VIRTUALDEV, elles doivent être nettoyées,
triées et vériĄées en vue dŠéliminer toutes sortes de valeurs aberrantes et dupliquées. Il
faut aussi traiter les données manquantes ainsi que la standardisation des référentiels.
Ainsi que, la transformation consiste ‘a convertir , Ąltrer et valider les données .
Nous allons citer dans ce qui suite, les différentes transformations apportées
On a utilisé la fonction ŞData conversionŤ pour changer de type de la colonne Invoice-

Date.
Figure 5.19 Ű Conversion du type
En outre, la fonction Lookup est un outil puissant pour rechercher, récupérer, mettre
‘a jour et intégrer des données en fonction de correspondances. Elle facilite lŠenrichisse-
ment des données et la synchronisation entre différentes sources de données, contribuant
ainsi ‘a lŠintégration efficace des données dans le processus dŠintégration de données.
Dans notre cas, nous avons adapté la fonction Lookup pour générer les ID date corres-
pondants ‘ a partir de la table Dim-Date. Cette approche nous permet de créer des liens
entre les tables de faits et les dimensions.
Figure 5.20 Ű SpéciĄcation du connextion

Figure 5.21 Ű Connexion de table Dim-Date
Figure 5.22 Ű Mappage ID

5.3.3 Chargement des données
Figure 5.23 Ű Chargement Fact-Cout-de-reveint
Figure 5.24 Ű Fact-Cout-de-revient
- Même démarche pour les autres dimension

• Fact-Production
Figure 5.25 Ű Chargement Fact-Production

Figure 5.26 Ű Fact-Production
• Tabla Fact-Vente
Figure 5.27 Ű Chargement Fact-Vente
Figure 5.28 Ű Fact-Vente

5.4. réation dŠun projet SSAS 76
Nous avons clôturé la phase de lŠETL par le chargement des tables de faits pour
enĄn, obtenir notre Datawarehouse total stocké au niveau de SQL server.
5.4 réation dŠun projet SSAS

LŠétape qui suit le chargement de la base « DWH » au niveau de SQL Server, Pour ce
faire, nous avons créé un nouveau projet SSAS dans lŠenvironnement Visual Studio 2010
et nous avons choisi ≪ Analysis Services ≫ sous la rubrique ≪ Projet multidimentionnelle
≫.
5.4.1 Source de données

- Nous avons préparer la nouvelle source de données
Figure 5.29 Ű Création source de donnée DWH dans SSAS
Figure 5.30 Ű Connexion aux service SSAS

Figure 5.31 Ű Importer source de donnée DWH
5.4.2 Vue source de données
Figure 5.32 Ű Sélectionner la source ‘a exploiter
Figure 5.33 Ű IdentiĄer les liens

Figure 5.34 Ű Ajouter les tables de lŠentrepôt de données
Figure 5.35 Ű Importer les tables faits et ses dimensions de lŠentrepôt de données
Figure 5.36 Ű Mod‘ele en constellation du datawarehouse
Conclusion
Dans ce chapitre, nous avons effectué le processus ETL, ainsi que la création dŠun projet
SSAS pour le traitement du datawarehouse. De plus, nous avons conçu la conception
du mod‘ele en constellation pour organiser les données de mani‘ere efficace.
6 Sprint 3 : Création des tableaux de bords
Introduction
Durant ce chapitre et dŠapr‘es la méthodologie agile utilisée « SCRUM BI » et le
traitement du processus ETL, ce sprint N°3 sera dédié pour la phase de reporting, ainsi
que la création et la consultation du tableau de bord .
6.1 Backlog du sprint Dashboard

Le but de notre projet lors du troisi‘eme sprint est de développer des rapports
dynamiques relatifs aux exigences de lŠutilisateur et générées par la suite les rapports
interactifs concernés.
Le tableau suivant représente les éléments du Backlog de SPRINT 3 :
User story
En tant quŠ analyste, je 1.1 Importation des données
veux créer et générer dans Power BI.
des rapports 1.2 Choix du graphique qui
dynamiques pour une répond ‘a nos besoins .
vision globale sur le 1.3 Effectuer le calcul des
suivi du coût de mesures avec DAX .
revient, du production 1.4 Générer un rapport
et du vente et par la dynamique concernant le
suite une prise de suivi du coût de revient, de la
US 3 décision éclairée production et de la vente
Table 6.1 Ű Backlog du sprint N°3
80
6.2. Phase de Reporting 81
6.2 Phase de Reporting

La phase de Reporting est dédiée ‘a élaborer, publier et diffuser les rapports dŠacti-
vité de lŠentreprise selon un format prédéterminé. Le principe de lŠoutil de Reporting
cŠest quŠil assure une interrogation des bases de données en fonction des requêtes SQL
préalablement préparées lors de lŠélaboration du mod‘ele .
6.2.1 LŠintégration des données du datawarehouse dans lŠoutil Power

BI
Pour accéder aux données nécessaires pour effectuer la phase de reporting, nous
devons connecter notre outil « Power BI » a‘ notre datawarehouse nommé « DWH »
Figure 6.1 Ű Démarrer lŠoutil « Power BI »
Figure 6.2 Ű Importer les données ‘a partir SQL Server

Figure 6.3 Ű Connexion directe avec base de donnée «DWH»
Figure 6.4 Ű Sélection des tables nécessaires
Figure 6.5 Ű Chargement des tables sélectionner dans « Power BI »

6.2.2 Choix du graphique

Power BI est livré avec de multiples visuels prêts ‘a lŠemploi . Ces visuels sont dis-
ponibles dans le volet de visualisation de Power BI Desktop est peuvent être utilisés
pour créer et modiĄer le contenu Power BI . ą
Dans la phase de reporting , le choix des graphiques est tr‘es important et doit répondre
parfaitement ‘ a nos besoins pour bien traduire nos indicateurs de performance.
Rendre un tableau de bord facile ‘a lire est lŠun de nos objectifs ‘a Ąn de faciliter la prise
de décision et gagner du temps. Pour cela nous allons effectuer une justiĄcation pour
le choix des graphiques que nous avons utilisés .
- Carte : Nous lŠavons utilisé pour mettre en valeur certains mesures .
- Table : Nous lŠavons utilisé pour afficher des spéciĄcations pour les aliments.
- Graphique en courbe : Nous lŠavons utilisé pour visualiser et analyser les tendances
et les variations des données sur une période donnée.
- Graphique en anneau : Nous lŠavons utilisé pour représenter la répartition des
QteAlim par Calibre .
- Graphique en ruban : Nous lŠavons utilisé pour visualiser les variations des pêches
selon le NumLot.
- Graphique ‘ a barres regroupé : Nous lŠavons utilisé pour comparer les valeurs
entre différentes catégories et sous-catégories.
- Graphique ‘ a barres empilées : Nous lŠavons utilisé pour représenter la contribu-
tion de chaque catégorie ‘ a un total.
- Graphique au secteur : Nous lŠavons utilisé pour afficher la répartition des valeurs
dŠune seule variable.
- Histogramme empilé : Nous lŠavons utilisé pour présenter la distribution des
données en fonction de leurs plages ou de leurs intervalles.
Pour représenter lŠévolution du coût de revient par esp‘ece, nous avons utilisé la bi-
blioth‘eque matplotlib, une biblioth‘eque puissante en Python permettant de créer des
visualisations statiques, animées et interactives.
6.3. Composant DAX 84
Figure 6.6 Ű Coût revient par esp‘eces
6.3 Composant DAX
6.3.1 DéĄnition
DAX (Data Analysis Expressions) est un langage de formules utilisé dans Power BI,
un outil de visualisation de données. Il est utilisé pour créer des mesures et des colonnes
calculées, ainsi que pour effectuer des manipulations et des agrégations de données.
6.3.2 Calcul des mesures

Dans cette phase, nous avons commencé ‘a calculer les charges totales,qui englobent
‘a la fois les charges directes et indirectes en utilisant une nouvelle mesure et appliquer
une formule DAX appropriée y parvenir.
6.3. Composant DAX 85
Figure 6.7 Ű Mesure de charge total
Puis , nous avons réussi ‘

a calculer notre indicateur de performances Şcoût de revient
dŠun KG de poissonsŤ . Nous avons accompli cette tâche en utilisant une nouvelle mesure
et en appliquant une formule DAX adaptée qui incorpore la fonction COALESCE .
Cette fonction, en DAX, permet de gérer les valeurs nulles en renvoyant la premi‘ere
expression non nulle dans une liste donnée. Elle sŠav‘ere précieuse pour substituer les
valeurs nulles par des alternatives lors de calculs et de manipulations de données.
Figure 6.8 Ű Mesure du KPI Coût de revient KG

6.4. Visualisation globale du tableau de bord 86
- EnĄn , nous avons effectué le calcul du prix moyen qui signiĄe le prix de vente
dŠun KG de poissons .
Figure 6.9 Ű Mesure du Prix moyen
6.4 Visualisation globale du tableau de bord

Apr‘es avoir déĄni les graphiques choisis et effectué les mesures nécessaires dans la
partie précédente et présenter des apercu sur chaque graphique.
Dans les Ągures suivantes nous allons présenter les tableau de bords :
6.4.1 Suivi coût de revient

Plusieurs facteurs contribuent au suivi du coût de revient qui représente lŠensemble
des charges directes et des charges indirectes. Ainsi que les variations de ces charges
entraı̂nent des Ćuctuations du coût de revient .
Tenant compte notre indicateurs de performances nous avons créé un tableau de bord
dynamique pour montrer lŠévolution des charges en fonction de la quantité produite
par date et type dŠespece.
Figure 6.10 Ű Rapport pour le suivi de lŠévolution des charges en fonction de la

quantité produite
Nous avons observé que les charges et la quantité produite présentent des Ćuctua-
tions qui peuvent être ascendantes ou ou descendantes, et parfois atteindre une phase
de maturité .
La Ągure suivante représente lŠévolution du coût de revient dŠun KG de poissons en
fonction des facteurs de performances nécessaire durant un période donnée pour chaque
type dŠespece.
Figure 6.11 Ű Rapport sur les facteurs contributifs ‘a lŠévolution du coût de revient
Nous avons montré lŠévolution des trois coûts qui sont classés dans les charges
directes pour chaque Lot en adaptant des Ąltres sur les fournisseurs dŠaliment .
Figure 6.12 Ű Rapport pour le suivi du coût par lot
6.4.2 Suivi Production

Nous prévoyons de créer des tableaux de bord aĄn de suivre la production en fonc-
tion de lŠétat des aliments et du suivi de la pêche.
De plus, nous avons généré des rapports détaillant le suivi de production (clôturé)
qui englobe le suivi des activités de pêche/poissons, la biomasse, la mortalité/fuite,
ainsi que les coûts dŠalimentation pour chaque lot.
Figure 6.13 Ű Rapport pour le Suivi des Production par Aliment

Nous avons effectuer le suivi de Production par Aliment en considérant les indica-
teurs de performances nécessaire .
Figure 6.14 Ű Rapport pour suivi de Production par Pêche
Nous avons effectuer le suivi de pêche en considération les indicateurs de perfor-

mances nécessaire .
Figure 6.15 Ű Rapport pour le suivi de Production (clôturé) par pêche / poisson
Nous avons réalisé le suivi de la pêche et des poissons dans chaque lot, en tenant
compte des indicateurs de performances pertinents.
Figure 6.16 Ű Rapport pour le suivi de Production (clôturé) par Biomasse
Nous avons effectué le suivi de la production par biomasse dans chaque lot, en
prenant en compte les indicateurs de performances pertinents.
Figure 6.17 Ű Rapport pour le suivi de Production (clôturé) par Mortalité / Fuite
Nous avons réalisé le suivi de la production en tenant compte des indicateurs de

performance pertinents, notamment la mortalité/fuite, pour chaque lot.
Figure 6.18 Ű Rapport pour le suivi de Production (clôturé) par Nbrjrs Alimentation
Nous avons effectué le suivi de la production par Nbrjrs Alimentation dans chaque
lot .
Figure 6.19 Ű Rapport pour le suivi de Production (clôturé) par Coûts

6.4.3 Suivi Vente

Nous avons lŤintention de concevoir et générer des tableaux de bord détaillés qui
permettront de suivre les ventes par date, esp‘ece, cage et lot, et également la progression
du prix moyen.
Figure 6.20 Ű Suivi Vente par date
Nous avons représenté lŠévolution des chiffres dŠaffaires et de la quantité vendus ‘a

la fois sur une base annuelle et mensuelle.
Figure 6.21 Ű Suivi Vente par Espece

Nous avons affiché lŠévolution des Ventes pour chaque esp‘ece.
Figure 6.22 Ű Suivi Vente par Cage
Nous avons montré lŠévolution des ventes dans chaque cage .
Figure 6.23 Ű Suivi Vente par Lot

Ce rapport dynamique a pour objectif dŠafficher la progression du chiffres dŠaffaires

par Lot.
Figure 6.24 Ű Suivi Vente en fonction de lŠévolution du prix moyen
Le but de ce rapport interactif est de visualiser lŠévolution mensuelle du prix moyen.
Conclusion
Au cours de ce chapitre, nous avons réalisé la phase de reporting, o‘ u nous avons

généré des tableaux de bord correspondant ‘a notre entrepôt de données.
Cela a permis ‘ a lŠutilisateur VMIND de prendre des décisions éclairées en se basant sur
ces informations.
Conclusion générale
Tout au long de notre stage au sein de VIRTUALDEV, nous sommes engagés ‘a

mettre en place une solution dŠaide ‘a la décision destinée aux utilisateurs VMIND .
Étant novices dans le domaine de lŠinformatique décisionnel, le démarrage de ce projet
fut une rude épreuve pour nous. Pour le manque de connaissance, nous avons entamé
notre projet par une phase de recherche et de parcours de la littérature existante au
sujet de lŠinformatique décisionnelle et des projets des aides ‘a la décision.
Au terme de cette premi‘ere étape nous avons pu dégager la particularité dŠun tel
projet et avons réussi ‘ a choisir et ‘a adapter le cadre méthodologique qui nous a semblé
idéale pour sa réalisation.
Une autre étape critique sŠest aussi présentée, il sŠagissait de mener ‘a bien lŠétude
de lŠexistant et le cadrage des besoins. Pour pouvoir proposer une solution qui contri-
bue ‘a lŠoptimisation des décisions précise par les décideurs de VIRTUALDEV, il nous
a fallu en premier lieu assimiler leur mode de travail, détecter les probl‘emes ils font
face et pouvoir ainsi déterminer les objectifs ‘a atteindre par notre solution. Une fois
nos objectifs Ąxés, nous nous sommes lancés dans la réalisation de notre projet selon la
méthodologie SCRUM . Nous avons commencé par la construction de notre dataware-
house de façon incrémentielle,étalée sur trois sprints. Cette approche nous a permis de
livrer rapidement le résultat de notre travail VIRTUALDEV.
Le véritable déĄ rencontré lors de la production de ce premier livrable, était de ma-
nipuler les données sources avec précaution et exactitude aĄn de construire un entrepôt
de données Ąable. CŠest sur ce dernier que reposait lŠefficacité de notre solution dŠaide
‘a la décision. Pour y parvenir, comprendre la structure des différentes sources ainsi que
la signiĄcation des données est nécessaire. Cela nŠaurait pas été possible sans lŠaide et
la coopération du département informatique.
Ce stage fut pour nous une expérience tr‘es riche autant sur le plan personnel que
professionnel. Nous avons eu la chance de nous intégrer au sein dŠun cadre de travail
qui nous a inculqué le sens de responsabilité et de collaboration. Par ailleurs, nous
avons non seulement acquis une expérience intéressante dans un domaine qui nous
était totalement inconnu, mais nous avons aussi appris les bonnes pratiques concernant
lŠutilisation des outils BI .
Ce stage nous a permis de renforcer notre formation académique et de la rendre
95
Conclusion générale 9697
ainsi plus compl‘ete.

Pour conclure, nous pouvons affirmer que nous avons atteint tous les objectifs que
nous avons Ąxés par notre solution .
Bibliographie
[1] Informatique décisionnelle

https://www.lemagit.fr/definition/BI-informatique-decisionnelle
[2] ODS
https://www.journaldunet.fr/web-tech/dictionnaire-du-webmastering/1445324-ods-ou-operational-
data-store-definition-et-utilisation/
[3] Présentation d’une datawrehouse
.https://www.lebigdata.fr/data-warehouse-entrepot-donnees-definition
[4] Datamart
https://www.youtube.com/watch?v=ALLIk3cn-4U
[5] un entrepôt de données VS un Datamart
https://waytolearnx.com/2018/08/difference-entre-un-datawarehouse-et-un-datamart.html
[6] conception d’une datawarehouse
https://grim.developpez.com/cours/businessintelligence/concepts/conception-
datawarehouse/
[7] Les étapes d’un projet BI
https://alphalyr.fr/projet-bi-etapes-pour-reussir/
[8] Présentation de méthodes classiques.
https://www.manager-go.com/gestion-de-projet/cycle-en-v.htm
[9] Présentation des méthodes agiles.
https://www.piloter.org/projet/methode/methode-agile.htm
[10] Comparaison entre les différent méthode
http://www.marine-guyot.ovh/methode-agile-ou-classique/
[11] Présentation du méthode SCRUM

https://asana.com/fr/resources/what-is-scrum
[12] Rôles des intervenant sans SCRUM
https://blog-gestion-de-projet.com/roles-et-responsabilites-de-scrum/
[13] Les artéfacts du SCRUM
https://www.tuleap.org/fr/agile/comprendre-methode-agile-scrum-10-minutes
[14] Les évènements du SCRUM
https://wiki.sfeir.com/agilite/scrum/evenements-scrum/
[15] Approche scrum dans un projet BI
https://grim.developpez.com/cours/businessintelligence/concepts/conception-
datawarehouse/#:~:text=Elle%20consiste%20en%20la%20conception,les%20d%C3%A9coupages%2
0un%20par%20un.
[16] Présentation du schéma en étoile
https://fr.wikipedia.org/wiki/%C3%89toile_%28mod%C3%A8le_de_donn%C3%A9es%29
[17] Présentation du schéma en Flocon de neige
https://boowiki.info/art/theorie-des-bases-de-donnees/flocon-de-neige-schema
[18] Présentation du schéma en constellation
https://www.educba.com/fact-constellation-schema/
[19] modèles de création de datawarehouse

https://infodecisionnel.com/la-bi-en-generale/definitions/illustration-du-molap-rolap-holap/
[20] Principe d’un indicateur de performance (KPI)
https://www.powerslide.io/blog/kpi-definition-exemples

Ben Hrak 3éme BI

Transféré par

Informations du document

Titre original

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

Ben Hrak 3éme BI

Transféré par

Droits d'auteur :

Formats disponibles

Table des mati‘eres

1 Contexte, enjeux et problématique 3

2 Méthode de conception et outils décisionnels 9

2.2.6 LŠapproche SCRUM appliquée ‘a un projet BI : (Les méthodologie

3 Sprint 0 : Etude fonctionnelle : 26

4 Sprint 1 : Préparation des données 37

6 Sprint 3 : Création des tableaux de bords 80

6.3 Composant DAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

2.1 Méthodes agiles Vs méthodes classiques . . . . . . . . . . . . . . . . . . 16

3.1 Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 : Backlog du sprint N°1 . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 Backlog du sprint N°2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.1 Backlog du sprint N°3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

1.1 Références de lŠorganisme . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Tableau dŠun entrepôt de données VS un Datamart . . . . . . . . . . . . 12

3.1 Equipe scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.12 Aperçu sur la dimension «Lot» . . . . . . . . . . . . . . . . . . . . . . . 36

4.1 Gestionnaire de connexion ‘a la base de données SQL Server . . . . . . . 39

4.36 Table Ods Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1 Aperçu sur la liste des packages de chargement de la base de données . 64

5.23 Chargement Fact-Cout-de-reveint . . . . . . . . . . . . . . . . . . . . . 74

6.1 Démarrer lŠoutil « Power BI » . . . . . . . . . . . . . . . . . . . . . . . . 81

[ESN] Entreprise de Système Numérique

Le développement spectaculaire de lŠinformatique est un trait marquant des sociétés

En réponse ‘a de telles sollicitations , cŠest lŠinformatique décisionnelle , dont nous

Le premier chapitre intitulé Ş Présentation du cadre du stage Ť consiste en la mise en

1.1 Cadre générale du projet

1.2 Présentation de lŠorganisme dŠaccueil

1.2.1 Historique de lŠorganisme :

Leurs solutions et applications sont éligibles pour de nombreuses industries telles

1.2.2 Les références de lŠorganisme :

Figure 1.1 Ű Références de lŠorganisme

1.2.3 Les produits de lŠorganisme :

Figure 1.2 Ű Produits de lŠorganisme

1.2.4 Fiche de présentation globale :

Figure 1.3 Ű Fiche technique

1.2.5 Organigramme actuel :

Figure 1.4 Ű Organigramme

1.3 Contexte du projet

1.3.1 Etude de lŠexistant :

Figure 1.5 Ű Schéma explicatif du processus de production

- Les visualisations actuelles ne permettent pas de fournir des informations pertinentes,

1.3.3 La solution proposée :

Avant dŠentamer la réalisation de mon projet , jŠessaierai ‘a travers ce chapitre de

2.1 Contexte décisionnel :

2.1.1 Informatique décisionnelle :

2.1.2 Base de donnée intermédiaire ODS (Un Operational Data Store) :

différencie des entrepôts de données traditionnels. LŠutilité de lŠODS réside dans sa

2.1.3 LŠentrepôt des données :

2.1.4 Data Mart

2.1.5 Comparaison entre un Data Warehouse et un Datamart

Figure 2.1 Ű Tableau dŠun entrepôt de données VS un Datamart

La Ągure suivante sigiĄe que datamart représente un sous-ensemble dans dataware-

Figure 2.2 Ű Data Warehouse VS Data Mart

2.1.6 Conception dŠun entrepôt de données

Figure 2.3 Ű Exemple dŠune table de fait

Figure 2.4 Ű Exemple dŠune table de dimension

2.1.7 Chaı̂ne décisionnelle dŠun projet BI

- Phase de modélisation et de stockage : permet de stocker les données sous une

- La phase de restitution ou de distribution de lŠinformation : est un processus clé

- La phase dŠanalyse et dŠexploitation est la derni‘ere étape du processus de Busi-

Figure 2.5 Ű Les étapes dŠun projet BI

2.2 Méthodologie de réalisation dŠun projet