UnivERSITÉ DE CARTHAcE

FACULTÉ DES SciEncES EconoMIQUES ET DE GESTIOn dE NABEUL

MÉMOIRE DE MASTERE

MASTÉRE PROfESSIOnnEL
IngÉnIERIE DES SySTÈMES D’InfoRMATIOn ET DES
ConnAISSAncES

Réalisation d’une solution décisionnelle

pour Biatnet
RÉALISÉ pAR : JIHEnE SELLAMI

SOUS LA DIRECTIOn dE :
M. RIADH KHAncHEL M. HEITHEM DRIDI
FSEG NABEUL BIAT TUnISIE

Année Universitaire : 2019/2020

Remerciements

Je souhaite adresser mes remerciements les plus sincères aux personnes qui m’ont ap-
porté leur aide et ont contribué à l’élaboration de ce travail.

Ces remerciements vont tout d’abord au corps professoral et administratif de la Fa-

culté des Sciences Économiques et de Gestion de Nabeul, pour la richesse et la qualité
de leur enseignement qui déploient de grands efforts pour assurer à leurs étudiants une
formation actualisée.

Je tiens aussi à remercier : le responsable de mastère ingénierie des systèmes d’in-

formation et des connaissances M. Taieb Felfel, pour tout ce qu’il a pu nous apprendre,
qu’il trouve ici l’expression de ma profonde et sincère reconnaissance.

Ma gratitude s’adresse à M. Riadh Khanchel pour son encadrement, son orientation,

ses conseils, et la disponibilité qu’il m’a témoigné pour me permettre de mener à bien
ce travail.

Je remercie mon encadrant professionnel M. Heithem Dridi, pour sa confiance et les

connaissances qu’il a su partager avec moi. Je le remercie aussi pour sa disponibilité et
la qualité de son encadrement.

Je remercie également la direction "Digital Factory et données" de la BIAT, pour

l’ex- cellent accueil qui m’a été réservé, que la qualité de l’accompagnement dont j’ai
béné- ficier, que la bienveillance et la disponibilité dont m’avez fait preuve à mon
égard.

Je saisis cette occasion pour remercier les membres du jury en espérant qu’ils
trouvent dans ce mémoire les qualités de clarté et de motivation qu’il attendent.

Enfin, je remercie tous ceux qui m’ont aidé de près ou de loin dans l’élaboration de
ce travail.

2
Dédicaces

Avec tout respect et amour je dédie ce travail à :

Mon père Jalel,

Pour m’avoir insuffié l’abnégation.

Ma mère Fatma,
Pour sa précieuse attention à mon égard.

Ma chére soeur Hadil,

Pour son encouragement, son soutien et son amour.

Mon frère Mohamed,

Ma chére grand-mère Asia,

Qui m’a accompagné par ses prières, puisse Dieu lui preter longue vie et beaucoup de
santé et de bonheur.

Ma chére tante Sonia,

Pour le soutien qu’elle m’a apporté.

Mes amis : Naoures, Nour, Oumaima, Islem...

Qui ont toujours su être présents.

A tous ceux qui croient aux vertus du sacrifice, de l’effort et du travail.

3
Table des matières
1 L’informatique décisionnelle 13
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Concepts généraux du BI . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.1 La Business Intelligence . . . . . . . . . . . . . . . . . . . . . . 13
1.2.2 Les domaines d’application de la Business Intelligence . . . . . 13
1.2.3 Les enjeux des applications de Business Intelligence . . . . . . 14
1.3 Démarche de construction d’un entrepôt de données . . . . . . . . . . 14
1.3.1 Modélisation et Conception de l’entrepôt . . . . . . . . . . . . . 14
1.3.1.1 Approche ascendante . . . . . . . . . . . . . . . . . . 15
1.3.1.2 Approche descendante . . . . . . . . . . . . . . . . . 15
1.3.2 Alimentation de l’entrepôt . . . . . . . . . . . . . . . . . . . . . 15
1.3.2.1 Extraction des données . . . . . . . . . . . . . . . . . 15
1.3.2.2 Transformation des données . . . . . . . . . . . . . . 15
1.3.2.3 Chargement des données . . . . . . . . . . . . . . . . 16
1.3.3 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.4 Restitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 Modélisation dimensionnelle . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.1 Concept de fait . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.2 Concept de dimension . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.3 Différents modèles de la modélisation dimensionnelle . . . . . 18
1.5 Le Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5.2 Les bases des données NoSQL . . . . . . . . . . . . . . . . . . . 19
1.5.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5.2.2 La différence entre SQL et NoSQL . . . . . . . . . . . 19
1.5.2.3 Schémas de données dans les bases NoSQL . . . . . . 19
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 Cadre du projet 21
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Présentation de l’organisme d’accuei : BIAT . . . . . . . . . . . . . . . 21
2.2.1 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 Organigrammme global . . . . . . . . . . . . . . . . . . . . . . 22
2.2.3 Les missions du département système d’information . . . . . . 22
2.3 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1 contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4
 Table des

2.4 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . 24
2.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.3 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.4 Analyse et spécification des besoins . . . . . . . . . . . . . . . 25
2.4.4.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . 25
2.4.4.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . 25
2.5 Méthode adoptée pour la conduite du projet . . . . . . . . . . . . . . . 26
2.5.1 La méthodologie Scrum . . . . . . . . . . . . . . . . . . . . . . 26
2.5.2 Equipe Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.3 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3 Modélisation de la Solution Proposée 31

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 La collecte d’information . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.1 Table Affectation . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.2 Table ProtocolTC . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.3 Table Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.4 Table Longitude_Latitude . . . . . . . . . . . . . . . . . . . . . 32
3.3 Choix des indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Liste des dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1 Dimension AGENCE . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.2 Dimension Agence de Rattachement Client . . . . . . . . . . . 34
3.4.3 Dimension DATE . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.4 Dimension RÉGION . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.5 Dimension TRANSACTION . . . . . . . . . . . . . . . . . . . . 36
3.4.6 Dimension USER . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.7 Dimension ZONE . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5 Table de Fait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6 Schéma de DataMart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Réalisation 40
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 Environnement de réalisation . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . 40
4.2.2 Environnement logiciels . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Description des processus ETL . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.1 Les outils ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2 Étapes ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.2.1 Extraction des données . . . . . . . . . . . . . . . . . 44
4.3.2.2 Transformation des données . . . . . . . . . . . . . . 45
4.3.2.3 Chargement des données . . . . . . . . . . . . . . . . 48
4.3.2.4 Création et chargement du Data mart . . . . . . . . . 50

5
 Table des

4.4 Développement de l’application BI................................................................54

4.4.1 L’ingestion de données avec "Logstash/Elasticsearch".....................54
4.4.2 Visualisation des données avec kibana..............................................57
4.5 Conclusion......................................................................................................62

6
Table des figures
1.1 "Démarche de construction d’un entrepôt de données".................................14
1.2 "Le cycle de vie d’un projet en BI".................................................................17
1.3 "types de bases de données NoSQL"..............................................................20

2.1 "Logo de la BIAT"...............................................................................................21

2.2 "organigramme de la BIAT"...........................................................................22
2.3 "Tableau Trello"..............................................................................................26
2.4 "Processus Scrum"..........................................................................................27
2.5 "Planification du projet : Diagramme de Gantt".............................................29

3.1 "Schéma en étoile du Data Mart"....................................................................38

4.1 "Logo de Oracle Database".............................................................................41

4.2 "Logo de Talend"............................................................................................41
4.3 "Logo de DBeaver"..............................................................................................41
4.4 "Logo de Elasticsearch"..................................................................................42
4.5 "Logo de Kibana"................................................................................................42
4.6 "Logo de Logstash".........................................................................................42
4.7 "Connexion à la base de données SQL"..........................................................44
4.8 "Extraction des données".................................................................................45
4.9 "Transformation de la table ProtocolTC"........................................................46
4.10 "Transformation de la table Affectation"........................................................47
4.11 "Transformation de la table Protocol".............................................................48
4.12 "Chargement de la dimension AGENCE".......................................................49
4.13 "Chargement de la table dimension AGR"......................................................49
4.14 "Chargement de la table dimension AGR"......................................................50
4.15 "Création du job de schéma multidimensionnel"...........................................51
4.16 "Main row ".....................................................................................................52
4.17 "Les jointures".................................................................................................52
4.18 "Aperçu de FACT_BIATNET"............................................................................53
4.19 "Input du fichier Log".....................................................................................54
4.20 "Input du fichier Log".....................................................................................55
4.21 "Filtre du fichier Log".....................................................................................55
4.22 "Output du fichier Log"...................................................................................56
4.23 "Index_biatnet"................................................................................................56
4.24 "Interface Login kibana".................................................................................57
4.25 "Interface Discover Kibana"............................................................................58
4.26 "Interface de tableau de bord Agence 1.1"......................................................59

7
 Table des figures

4.27 "Interface de tableau de bord Agence 1.2"......................................................59

4.28 "Interface de tableau de bord Agence 1.3"......................................................60
4.29 "Interface tableau de bord BIATNET 1.1 "....................................................60
4.30 "Interface tableau de bord BIATNET 1.1".....................................................61
4.31 "Interface tableau de bord Agence de rattachement"......................................62
4.32 "Interface tableau de bord Agence de rattachement"......................................62

8
Liste des tableaux
2.1 Backlog du produit..........................................................................................28

3.1 Attribut de la table Affectation.......................................................................31

3.2 Attribut de la table ProtocolTC.......................................................................32
3.3 Attribut de la table Protocol............................................................................32
3.4 Attribut de la table Longitude_Latitude.........................................................32
3.5 Liste des indicateurs et leurs modes de calcul................................................33
3.6 Dimension agence : Dim_AGENCE..............................................................34
3.7 Dimension agence de rattachement : Dim_AGENCER................................35
3.8 Dimension date : Dim_DATE........................................................................35
3.9 Dimension region : Dim_REGION................................................................35
3.10 Dimension transaction : Dim_TRANSACTION...........................................36
3.11 Dimension user : Dim_USER........................................................................36
3.12 Dimension zone : Dim_ZONE.......................................................................36
3.13 Attribut de la table Fait...................................................................................37

4.1 Etude comparative entre TOS et PDI..............................................................43

9
Abréviations

BIAT : Banque Internationnal Arab de Tunisie

BI : Business Intelligence
ETL : Extract, Transform,
Load DW : Data Wharehouse
NoSQL : Not Only SQL
PDI : Penthao Data Integration
TOS : Talend Data Integration
SGBD : Sytème de Gestion de Base de
Données JDBC : Java Data Base Connectivity
TB : Tableau de Bord
SIAD : Système d’Information et d’Aide à la
Décision ERP : Entreprise Resource Planning

1
Introduction générale
De nos jours, l’information est omniprésente, la difficulté n’est plus de la recueilli,
mais de la rendre disponible sous la bonne forme, au bon moment, pour l’exploiter et
en tirer la valeur ajoutée.

Dans cette optique, la plupart des entreprises se dirigent vers l’informatique décision-
nelle afin de faire face aux énormes masses de données, extraire des informations si-
gnificatives, enrichir les analyses tactiques et opérationnelles et de mieux éclairer les
prises de décision.

Le domaine de la banque quant a lui tend au développement des nouvelles approches

méthodologiques qui favorisent la découverte des données et des techniques analy-
tiques avancées. Ainsi, au développement de nouveaux paradigmes de la Business In-
telligence ou l’informatique décisionnelle qui met la data science en position de Leader
et valorise les Big Data.
Le secteur bancaire est l’un des secteurs les plus développés en Tunisie. Le développe-
ment digital est aujourd’hui au cœur de la stratégie de la BIAT. Elle a mis à la
disposition de ses clients BIATNET pour suivre leurs comptes en temps réel, initier
certaines opé- rations bancaires et télécharger les fichiers ou les documents y
afférents, 24h sur 24 et 7 jours sur 7, en toute rapidité et en toute sécurité.
Les prérequis à cette transformation digitale ont été entamés notamment à travers la
mise en place d’une analyse stratégique et d’une gouvernance d’information. Ainsi, la
mise en place d’un système d’intégration des données complexes et volumineuses. Un
système qui a pour but d’améliorer d’une façon significative le processus de prise de
décision et de bien exploiter ses données qui représentent une source précieuse d’infor-
mations.

J’ai eu l’honneur d’être appelé par la direction "digital factory et données" de la

BIAT, pour concevoir et mettre en place une solution décisionnelle qui tend à
construire une vision globale sur les activités financières des clients et dans le but de
distinguer les potentiels clients qui sont éligibles à l’offre digitale .

1
 Liste des tableaux

Les principaux objectifs assignés au projet sont :

. Réaliser un outils dynamique et interactif d’aide à la décision.

. Mettre en place une solution décisionnelle qui offre une vision globale sur les
activités clients et permettre de distinguer la famille des clients éligibles à l’offre
digitale.
. Élaborer des tableaux de bord d’une façon dynamiques et sous différents formats.
. Suivre l’évolution des activités des clients : Par région, par zone, par temps et par
type de transactions.
Notre solution décisionnelle fournira les informations nécessaires sur lesquelles
peuvent se baser les responsables dans leurs prises de décision.

Au fil des pages suivantes nous présentons l’illustration du travail effectué qui est
articulé autour de quatre chapitres :

Chapitre 1 (L’informatique décisionnlle) : Le premier chapitre décrira les concepts

généraux de l’informatique décisionnelle.

Chapitre 2 ( Cadre du projet ) : Le deuxième chapitre présentera dans un premier

lieu le cadre général du projet. Ensuite, une étude approfondie de l’existant sera élabo-
rée et achevée par les critiques et la spécification des besoins. Il présentera dans une
dernier lieu la méthodologie adopté pour la conduite du projet.

Chapitre 3 (Modélisation de la solution proposée) : Le troisième chapitre pré-

sentera la conception, la collecte d’informations, la précision du choix des indicateurs,
les listes des dimensions, la table de fait et sera terminer par la présentation du schéma
du Data Mart.

Chapitre 4 (Réalisation) : Ce chapitre final décrira les différentes étapes suivies

pour mettre en oeuvre la solution réalisée.

Finalement, la clôture du projet sera avec une conclusion générale et quelques pers-
pectives pour la continuité de ce travail.

1
 1
CHAPITR

L’informatique
décisionnelle

1.1 Introduction
Ce chapitre, présente l’informatique décisionnelle en détallaient ses termes, ses
concepts clés, la notion d’ETL et d’entrepôt de données. Puis il décrit les notions de
Big Data et de bases de données NoSQL.

1.2 Concepts généraux du BI

1.2.1 La Business Intelligence

Business Intelligence ou informatique décisionnelle, désigne des outils et des
méthodes offrant l’accès aux informations, ainsi découvrant celles qui sont pertinentes
pour les transmettre aux managers d’entreprise.
Le but c’est d’analyser l’information pour améliorer et optimiser les décisions et les
performances d’une entreprise au travers des rapports et tableaux de bord qu’ils soient
analytiques ou prospectifs.
L’aide à la décision permet aux acteurs concernés de spécifier leurs besoins par des
processus de collecte, d’analyse et d’échange d’informations.

1.2.2 Les domaines d’application de la Business Intelligence

— Finance - Contrôle de gestion : Analyse des coûts, des risques, suivi du chiffre
d’affaires, élaboration budgétaire, les indicateurs de performance.
— CRM/CLM : Analyse clients, comportement de l’achat, suivi de l’activité com-
merciale.
— Marketing : Étude des consommateurs, impact sur les ventes, ciblage, pilotage
de gamme.

1
 CHAPITRE 1. L’INFORMATIQUE

— Ressources humaines : Suivi des effectifs, masse salariale, la gestion des car-
rières.
— Commercial - Force de vente : Suivi des objectifs, analyse des actions, générer
des prévisions des ventes, détection de nouvelles opportunités.
— Logistique : Suivi des volumes, optimisation des transport et approvisionne-
ments .

1.2.3 Les enjeux des applications de Business Intelligence

Les capacités technologiques ont vécus une évolution importante qui permettent de
placer le service à l’utilisateur en position centrale dans les applications de business
intelligence. On distingue parmis les évolutions et les attentes :
Le temps réel : Une vision instantanée des résultats en fonction des manipulations
effectuées.
La finesse et la précision des analyses : Niveaux de détails plus nombreux, segmen-
tations plus fines.
La simplicité d’utilisation : Une utilisation claire et simple pour l’utilisateur.
La mobilité : Possibilité de manipuler et visualiser les indicateurs à distance : Télétra-
vail, Téléphone mobile, tablette . . .

1.3 Démarche de construction d’un entrepôt de

données

FIgUre 1.1 – "Démarche de construction d’un entrepôt de données"

1.3.1 Modélisation et Conception de l’entrepôt

L’entrepôt de données autorise deux approches verticales : ascendante et
descendante.

1
 CHAPITRE 1. L’INFORMATIQUE

1.3.1.1 Approche ascendante

Ventile les magasins de données constitutifs de l’entrepôt auprès de groupes d’utili-

sateurs spécifiques, et ce une fois l’entrepôt de données a été créé dans son intégralité.

1.3.1.2 Approche descendante

Commence par construire les magasins de données, puis les combines au sein d’un
unique entrepôt de données.

1.3.2 Alimentation de l’entrepôt

ETL, ce terme signifie Extract, Transform and Load. Ce processus d’intégration revient
à extraire les données brutes d’un système, les transformer et les envoyer vers un
entrepôt de référence.
La préparation des données consiste à collecter des données de différentes provenances
puis les exploiter.
Par la suite, une séquence d’opérations qui se produit :

1.3.2.1 Extraction des données

Cette phase revient à extraire de gros volumes de données brutes depuis différentes
sources, comme des fichiers, des feuilles de calcul, des systèmes de base de données et
des applications.
La taille des données extraites varie de quelques centaines de kilo-octets à plusieurs
Giga-octets, selon le système source et la situation commerciale.

1.3.2.2 Transformation des données

Une fois les données extraites, elles doivent être physiquement transportées vers la
destination cible et converties dans le format approprié. Cette transformation passe par
plusieurs étapes tel que :
— Résolution des informations manquantes.
— Validation des données.
— Conversion en format standard.
— Nettoyage des données.
— Assemblages des données.
— Construction d’agrégats pour optimiser les performances des requêtes les plus
courantes.
— Application des filtres.

1
 CHAPITRE 1. L’INFORMATIQUE

1.3.2.3 Chargement des données

Cette phase vise à transférer les données qualifiées vers un emplacement cible qui peut
être une base de données ou un Data Warehouse. Il existe deux méthodes de
chargement de données :
— Chargement complet : Implique un chargement complet de données qui a
lieu la première fois que la source est chargée dans l’entrepôt.
— Chargement incrémental : qui a lieu à intervalles réguliers. Ces intervalles
peuvent être des incréments de flux (meilleurs pour de plus petits volumes de
données) ou des incréments de lots (meilleurs pour de plus grands volumes
de données).

1.3.3 Administration
L’étape de l’administration est constitué de plusieurs taches pour assurer :
— La qualité des données.
— La maintenance et le suivi.
— La gestion de la configuration.
— L’organisation et l’optimisation du système d’information.

1.3.4 Restitution
Cette dernière étape, également appelée reporting. Il s’agit de présenter les
informa- tions à valeur ajoutée pour qu’elles apparaissent de la façon la plus lisible
possible dans le cadre de l’aide à la décision.
Les données sont principalement modélisées par des représentations à base des
requêtes pour constituer des tableaux de bord ou des rapports avec des outils d’analyse
décision- nelle.
Le reporting permet aux décideurs de :
— Sélectionner, tirer, regrouper ou répartir les données selon des critères de choix.
— Réaliser des calculs.
— Présenter les données d’une manière synthétique ou détaillée, généralement sous
forme de graphes.

1
 CHAPITRE 1. L’INFORMATIQUE

1.4 Modélisation dimensionnelle

FIgUre 1.2 – "Le cycle de vie d’un projet en BI"

La représentation des données dans des schémas logiques et compréhensibles permet

d’aider à la prise de décisions (informatique décisionnelle). Ces schémas
dimensionnels peuvent être mis à jour grâce à un rafraîchissement périodique des
données.
Ces schémas comprennent des faits et des dimensions.

1.4.1 Concept de fait

Une table de faits est la table centrale d’un modèle dimensionnel. Elle contient les me-
sures sur ce qu’on veut analyser.
Une ligne d’une table de faits correspond à une mesure qui est généralement de valeur
numérique.
Une table de faits assure les liens plusieurs à plusieurs entre les dimensions. Elles com-
portent des clés étrangères, qui ne sont autres que les clés primaires des tables de di-
mension.

1.4.2 Concept de dimension

Une table de dimension représente un axe d’analyse, qui raccompagne la table de fait
et contient une description textuelle de l’activité.
La table de dimension permet à l’entrepôt de donnée d’être compréhensible et
utilisable, la table permet aussi d’avoir des analyses en tranches et en dés.

1
 CHAPITRE 1. L’INFORMATIQUE

1.4.3 Différents modèles de la modélisation dimensionnelle

Trois modèles permettant la présentation d’un Data warehouse :
— Modèle en étoile (star join) :
Il s’agit de relier une dimension à un fait dans un entrepôt de données. On trouve
une table de fait centrale qui est liée par les tables de dimensions. Les dimensions
ne sont pas liées entre elles.
— Modèle en ocon (snowFlake) :
C’est une manière de relier une dimension à un fait dans un entrepôt de données.
Il peut exister des hiérarchies des dimensions pour diviser les tables de
dimensions lorsqu’elles sont trop volumineuses.
— Modèle en constellation (Multi-star schema) :
Il s‘agit de l’existence de plusieurs modèles en étoile qui sont liés entre eux par
des dimensions communes. Les tables de dimensions communes aux différentes
tables des faits ne font pas l’objet de redondances : c’est l’un des principaux
avantages cette modélisation. Cela permet de réduire l’espace de stockage
nécessaire.

1.5 Le Big Data

Le terme Big Data décrit des ensembles de très gros volumes de données, qui sont
à la fois structurées, semi-structurées ou non structurées. Des données qui peuvent
être traitées et exploitées dans le but d’en tirer des informations intelligibles et
pertinentes.

1.5.1 Définition
Littéralement, ces termes signifient Mégadonnées, grosses données ou encore don-
nées massives. Ces termes désignent un ensemble très volumineux de données qui ne
peut pas être traiter par les outils classiques de gestion de base de données. Des nou-
velles technologies sont apparues pour faire face à ces énormes volumes de données
comme Hadoop, MapReduce ou les bases de données NoSQL.
Les caractéristiques de Big Data sont résumés par :
— Volume : La quantité de données générée est en pleine expansion et suit une loi
quasi exponentielle.
— Vélocité : Ou vitesse, énorme rapidité avec laquelle les données sont générées et
traitées.
— Variété : Des données structurées ou non structurées(Texte, Son, Vidéo ...)
peuvent être gérée.
— Véracité : Fait référence à la fiabilité de la donnée.

1
 CHAPITRE 1. L’INFORMATIQUE

1.5.2 Les bases des données NoSQL

En informatique et en bases de données, NoSQL désigne une famille de systèmes de
gestion de base de données qui s’écarte du paradigme classique des bases
relationnelles. L’explicitation la plus populaire de l’acronyme est Not only SQL.

1.5.2.1 Définition

NoSQL est une approche de la conception des bases et de leur administration

particuliè- rement utile pour de très grands ensembles de données distribuées. NoSQL
englobe une gamme de technologie et d’architecture afin de résoudre les problèmes de
performance en matière d’évolutivité et de Big Data que les bases de données
relationnelles ne sont pas conçues pour affronter.

1.5.2.2 La différence entre SQL et NoSQL

— Stockage de données :
Les base de données SQL sont stockées dans un modèle relationnel des tables
avec des lignes et des colonnes, alors que les données NoSQL sont stockées dans
des documents, graphes, clé-valeur ou colonne.
— Architecture :
Contrairement à SQL, NoSQL utilise une architecture distribuée qui permet l’uti-
lisation d’un grand nombre de serveurs afin d’atténuer les limitations de taille, de
haute disponibilité ou de redondance.
— Les caractéristiques et les performances :
SQL a plus de fonctions intensives que NoSQL et offre plus de souplesse
d’exécu- tion.
NoSQL est un choix plus approprié pour la manipulation de grands volumes
de données.
SQL est un meilleur choix pour les données structurées limités.

1.5.2.3 Schémas de données dans les bases NoSQL

Les solution NoSQL existantes peuvent être divisées en quatre catégories principales :

1
 CHAPITRE 1. L’INFORMATIQUE

FIgUre 1.3 – "types de bases de données NoSQL"

1. Bases de données Clé-Valeur(Key Value ) :

Les valeurs sont enregistrées sous forme de paires de valeurs cryptées. Les
valeurs sont affectées à des clés spécifiques, le jeu de données est ajouté en tant
que clé (Key) et représente une valeur (Value). Le Key génère un index qui
permet la recherche dans la base de données.
2. Bases orientées documents :
Ces bases de données stockent des données semi-structurée : Le contenu est for-
maté JSON ou XML, mais la structure n’est pas contrainte.
3. Bases de données orientées colonne : Les jeux de données sont enregistrées
par des colonnes, cela permet une lecture de données plus rapide et augmente les
performances.
4. Bases de données graphiques : Ce modèle se base sur la théorie des graphes.
Les relations entre les données sont établis par des noeuds et des arrêtes. Les
bases de données graphiques NoSQL présentent une performance qui peut faire
face à un volume de données aux informations fortement interconnectées.

1.6 Conclusion
Dans ce chapitre, nous avons détaillé toutes les notions relatives aux systèmes déci-
sionnels, aux Big Data et aux bases de données NoSQL pour les maîtriser afin de favo-
riser le bon déroulement du projet.

2
 2
CHAPITR

Cadre du projet

2.1 Introduction
Ce deuxième chapitre, présente le cadre général du projet. Tout d’abord, il présente
l’organisme d’accueil qui est le cadre de réalisation du projet. Ensuite, il définit la pro-
blématique, suivie d’une analyse de l’existant et les objectifs de la solution proposée.
Finalement, il précise la méthodologie adopté pour la conduite du projet.

2.2 Présentation de l’organisme d’accuei : BIAT

2.2.1 Présentation générale

Au terme de 44 ans d’existence, la Banque Internationale Arabe de Tunisie (BIAT),
lan- cée en 1976 avec des moyens humains et matériels modestes, est devenue
l’une des plus importantes institutions financières en Afrique du Nord et un acteur de
référence en Tunisie. Avec 1968 collaborateurs en 2019, la BIAT compte plus de 924
mille clients et un réseau de correspondants internationaux de près de 1500 banques.
Elle dispose d’un réseau des plus denses en Tunisie avec 205 agences réparties sur
l’ensemble du pays, d’une représentation à Tripoli –Libye. Elle compte également, une
filiale BIAT France, sous le statut d’agent de paiement avec une agence à Paris.
Banque universelle offrant une gamme complète de service à tout type de clientèle
Particuliers, Tunisiens Résidents à l’Etranger, Professionnels, Petites et Moyennes
Entreprises, Grandes Entre- prises et Institutionnels, la BIAT constitue aujourd’hui un
groupe financier diversifié dans les domaines de l’assurance, de la gestion d’actifs, du
capital- investissement, de l’intermédiation boursière et du Conseil à l’international.
Appuyant son développement sur la proximité et l’engagement sociétal, elle met son
expertise au profit de ses clients, de ses partenaires et de l’économie du pays.

FIgUre 2.1 – "Logo de la BIAT"

2
 CHAPITRE 2. CADRE DU

2.2.2 Organigrammme global

La figure suivante présente l’organigramme de la banque, il s’agit de l’organisation
hié- rarchique de la BIAT.

FIgUre 2.2 – "organigramme de la BIAT"

Le département système d’information est composé de six directions. Notre stage est
effectué au sein de la direction "Digital Factory et Données"

2.2.3 Les missions du département système d’information

Le département système des d’information prend en charges de plusieurs missions dont
notamment :

— Participer à l’élaboration de la stratégie de la banque pour la partie impactant le

système d’information.
— Superviser de l’élaboration du plan informatique et des schémas directeurs des
systèmes d’information et assurer la veille technologique.
— Participer à l’élaboration et la mise à jour du portefeuille des projets informa-
tiques.
— Garantir la qualité, la fiabilité, la confidentialité, la sécurité et l’intégrité des sys-
tèmes d’information.
— Veiller à la cohérence des solutions apportées au niveau du système
d’information en collaboration avec les structures concernées.

2
 CHAPITRE 2. CADRE DU

— Veiller au cadrage des projets, à l’élaboration des cahiers de charges qui en dé-
coulent, au dépouillement des offres des prestataires et des fournisseurs et à l’éla-
boration des contrats d’acquisition ou de maintenance conformément aux pro-
cessus et aux procédures en vigueur.
— Gérer et suivre les relations avec les prestataires externes (matériels, progiciels,
développements spécifiques, intégration de systèmes . . . ) et veiller à la bonne
exé- cution de leurs contrats avec la BIAT.

2.3 Cadre du projet

2.3.1 contexte du projet

Dans le cadre de construire une « vision 360 » sur les activités financières des
clients, et dans le but de distinguer les potentiels clients éligibles pour l’offre digitale,
la BIAT vise à mettre en place une solution décisionnelle qui offre une vision globale
sur les activités des clients et permet de cibler ceux qui peuvent être intéressés par sa
panoplie de service digital. Nous sommes appelés, au sein de la direction « digital
Factory et données » de la BIAT à concevoir et à mettre en place une solution
décisionnelle qui prend en entrée les informations relatives aux clients.

2.3.2 Problématique
En vue de satisfaire leur clientèle, la BIAT propose une application « BIATNET
». Celle-ci permet aux différents clients, de consulter leurs comptes en temps
réel, d’effectuer certaines opérations bancaires à distance sans déplacement aux
agences. Cette application qui subit quotidiennement des milliers de transactions
génère un fichier log qui contient les différentes informations relatives aux
activi- tés financières des clients. Face à ce très grand volume de données, en
croissance exponentielle, la BIAT se trouve en difficulté à analyser et à
construire un sup- port sur lequel se basent les décideurs afin de prendre les
bonnes et meilleures décisions, et afin d’avoir une vue globale sur les
opérations financières.

2.4 Analyse de l’existant

C’est la phase du projet pendant laquelle le Business Analyst va auditer les pro-
cessus et les solutions informatiques existants. C’est une étape qui doit être réa-
liser avant l’initialisation du changement. Elle permet de préparer l’analyse des
besoins de la solution cible et de réaliser l’analyse des écarts. C’est dans cette
section, que nous allons présenter la situation actuelle au sein de la direction «
Digital Factory et données » et ses limites.

2
 CHAPITRE 2. CADRE DU

2.4.1 Description de l’existant

Il est intéressant de signaler que la direction « Digital Factory données » ne
dispose d’aucun système d’aide à la décision de l’application BIATNET. Donc il est
très difficile pour les dirigeants de distinguer les clients qui peuvent être
intéressés par l’offre digitale.

2.4.2 Critique de l’existant

Suite à une étude de l’existant, nous avons constaté certaines insuffisances : Tous
d’abord, lorsque la banque ne dispose pas d’une application décisionnelle qui
per- met d’exploiter les données générées par BIATNET, BIAT perd
l’opportunité de fidéliser ses clients. En effet ces données sont utiles non
seulement pour proposer des offres ciblées, mais aussi pour détecter les fraudes
rapidement en temps réel en identifiant les comportements inhabituels(le
montant et le type d’opération).

2.4.3 Objectifs du projet

Afin de pallier aux limites citées dans la section précédente, nous proposons,
dans le cadre de ce projet, une solution informatique d’aide à la décision pour le
dé- partement Digital Factory et données.
Cette solution aura pour objectif d’implanter plus concrètement les concepts de
l’informatique décisionnelle en concevant et en développant une application BI.
Cette application devra permettre aux décideurs d’avoir une vision claire et com-
plète sur les activités financières pour des fins d’analyse, de suivi et de prise de
décisions.
A traves cette solution décisionnelle, nous tâcherons de satisfaire les exigences
suivantes :
. Réalisation d’un outils dynamique et interactif d’aide à la décision .
. Fournir une résolution et une quantité graphique adéquate.
. Mettre en place d’une solution décisionnelle qui offre une vision globale sur
les activités clients et permettre de distinguer la famille des clients éligibles
à l’offre digitale .
. Fournir des interfaces interactives et compréhensibles manipulées facile-
ment par les décideurs afin d’explorer leurs données.
. Élaboration des rapports d’une façon dynamique et sous différents formats.
. Mettre en disposition du décideurs des tableaux de bord clairs et facilement
analysables.
. Suivre l’évolution des activités des clients.
. Assurer la sécurité et la performance de l’entrepôt.

2
 CHAPITRE 2. CADRE DU

2.4.4 Analyse et spécification des besoins

2.4.4.1 Besoins fonctionnels
Les besoins fonctionnels représentent ce que le système offre comme services,
ou encore l’ensemble des actions que le système fournit pour satisfaire les
besoins de l’utilisateur.
Notre solution décisionnelle doit permettre de :
— Calculer le nombre d’agences par zone, par région. En effet, l’utilisateur a
besoin d’avoir une idée sur les zones et les régions ou le nombre des
agences est important, ce qui traduit une grande masse populaire et par la
suite plus de clients à cibler.
— Calculer le nombre d’opérations réalisées par les client à travers
l’application BIATNET, afin de distinguer les clients qui font confiance au
digital, qui par la suite peuvent être intéressés par l’offre proposée.
— Calculer le nombre d’opérations réalisées par les client à travers les agences.
— Suivre l’évolution du volume des opérations réalisées par client. En effet,
à partir cette évolution l’utilisateur peut comprendre le comportement des
clients.
— Calculer le nombre d’opérations réalisées à travers l’agence de
rattachement du client. Cet indicateur permet aux décideurs de trier les
clients. En effet si cet indicateur est important, cela veut dire que le client
n’est pas intéressé par l’offre digitale.
— Offrir une comparaison entre le nombre des opérations réalisées à travers
l’agence de rattachement et les autres agences de chaque client, pour distin-
guer les clients éligibles pour l’offre digitale.
— Produire des tableaux de bord dynamiques et interactifs permettant d’avoir
une vue globale sur les opérations financières des clients.

2.4.4.2 Besoins non fonctionnels

Pour le bon fonctionnement d’un projet BI, nous avons retenu les besoins
non fonctionnels suivants :
. La fiabilité :
Le système doit être disponible à tout moment pour l’utilisateur.
. La sécurité :
Besoins d’établissement de la connexion : Niveaux d’accès « CRUD levels
» (Create, Read, Update and Delete).
Besoins de mot de passe : Longueur, caractères spéciaux, expiration, poli-
tique de réutilisation.
Déconnexion après temps morts d’inactivité : Durées, actions.
. La performance :
Temps de réponse : le chargement de l’application, ouverture d’écran et des

2
 CHAPITRE 2. CADRE DU

délais de rafraîchissement.
En temps de traitement : Fonctions, calculs, importations/exportations
de données.
L’interrogation de données et Rapports – temps de chargement initial et des
chargements suivantes.
. Ergonomie : Les standards d’ergonomie : La densité d’éléments sur les
écrans, la disposition et le flux, les couleurs, l’Interface Utilisateur, les rac-
courcis clavier.
Internationalisation / besoins de localisation – langages, orthographe,
cla- viers, formats de papier.

2.5 Méthode adoptée pour la conduite du projet

Scrum est la méthodologie la plus utilisée parmi les méthodes Agiles existantes.
Le principe de base : Toute l’équipe avance ensemble et soit toujours prête à
réorienter le projet au fur-et-à-mesure de sa progression.

2.5.1 La méthodologie Scrum

Pour la réalisation de notre projet, nous avons choisi la méthodologie Scrum.
Les objectifs à réaliser sont clairs et précis, ce qui va nous permettre de décomposer le
projet en plusieurs sprints de 2 semaines. Durant chaque itération, une partie du produit
est réalisée et validée avec le client.
Afin d’appliquer au mieux les fondements de la méthodologie Scrum, nous avons eu
recours au gestionnaire de projet nommé « Trello ».
Trello est un outil de gestion de projet en ligne, qui permet d’organiser ses projets
sous forme de tableaux, eux-mêmes composés de listes en colonnes qui répertorient
des tâches sous formes de cartes.

FIgUre 2.3 – "Tableau Trello"

2
 CHAPITRE 2. CADRE DU

2.5.2 Equipe Scrum

FIgUre 2.4 – "Processus Scrum"

L’équipe Scrum est auto-organisée, elle choisit la meilleure façon d’accomplir son tra-
vail et elle possède toutes les compétences nécessaires à l’accomplissement du projet.
La flexibilité, la créativité et la productivité de l’équipe sont ainsi optimisées.

Scrum définit trois roles :

— Product Owner => Chedly Ben Ammar :

Présentation des caractéristiques et des fonctionnalités du produit à
développer et approbation du produit à livrer.
— Scrum Master => Heithem Dridi :
Supervision de l’avancement du projet et des activités de l’équipe.
— Equipe de développement => Jihene sellami :
Conception et implémentation de la solution.

2.5.3 Backlog produit

Il s’agit d’une liste hiérarchisée des exigences initiales du client concernant le produit
à réaliser. Ce document évolue sans cesse durant le projet, en fonction des besoins du
client. Le product owner est responsable du product backlog.

2
 CHAPITRE 2. CADRE DU

ID Tâches User Story Esti

1.1 En tant qu’utilisateur, je souhaite analyser
les agences par zone et par région afin d’avoir
Analyse des agences une idée sur les régions et les zones
par zone, par région et caractérisées par une concentration élevée en
par agence. terme du nombre des agences. 48h
1
1.2 En tant qu’utilisateur, je souhaite avoir un
tableau de bord, et un rapport dynamiques et
interactifs représentant le nombre d’agences
par zone et par région. 03h
2.1 En tant qu’utilisateur, je souhaite effectuer
des analyses sur les opérations réalisées en
ligne à travers l’application Biatnet, afin de
Analyse des opérations distinguer les clients qui font confiance au
réalisées à travers digitale et par la suite peuvent être intéressés
l’application BIATNET. par l’offre proposée. 26h
2
2.2 En tant qu’utilisateur, je souhaite avoir un
tableau de bord, et un rapport dynamiques,
qui présentent les différentes informations
relatives aux opérations en ligne. . 20h
Analyse des opérations 3.1 En tant qu’utilisateur, je souhaite avoir le
réalisées à travers les nombre d’opérations réalisées par un client à
agences. travers son agence de rattachement. 26h
3 3.2 En tant qu’utilisateur, je souhaite avoir le
nombre d’opérations réalisées par un client à
travers les autres agences. 20h
3.3 En tant qu’utilisateur, je souhaite avoir un
tableau de bord dynamique, qui permet de
faire une comparaison entre les opérations
réalisées à travers l’agence de rattachement et
celles réalisées à travers les autres agences. Je
souhaite aussi avoir un rapport résumant la
situation des clients. 05h

TABle 2.1 – Backlog du produit

Sprint 0 : Analyse et conception globale.

— Étude conceptuelle globale.

— Élaboration du backlog de produit.
— Élaboration d’une étude comparative des outils logiciels.
— Modélisation.

2
 CHAPITRE 2. CADRE DU

Sprint 1 : Analyse des agences par zone, par région, et par gouvernorat.
— Élaboration du backlog sprint.
— Analyse et conception.
— Réalisation.
— Test.
Sprint 2 : Analyse des opérations réalisées à travers l’application BIATNET.
— Élaboration du backlog sprint.
— Analyse et conception.
— Réalisation.
— Test.
Sprint 3 : Analyse des opérations réalisées à travers les agences.
— Élaboration du backlog sprint.
— Analyse et conception.
— Réalisation.
— Test.

FIgUre 2.5 – "Planification du projet : Diagramme de Gantt"

2
 CHAPITRE 2. CADRE DU

2.6 Conclusion
Ce chapitre, nous a permis de présenter l’organisme d’accueil et de définir le périmètre
général de projet en spécifiant les besoins qui nous permettra de passer à la
construction du Data Mart. Ainsi, le chapitre présente la méthodologie adopté afin
avoir une vision générale des procédures d’élaboration de rapports et de consolidation
des données.
La modélisation de la solution proposée fera l’objet du chapitre suivant.

3
 3
CHAPITR

Modélisation de la
Solution Proposée

3.1 Introduction
Ce chapitre, présente la structure de la base de données. Puis, il présente la conception
multidimensionnelle de l’entrepôt de données.

3.2 La collecte d’information

Lors de l’élaboration d’un tableau de bord, la collecte des données est une étape
cruciale. Il y a la collecte de données initiale pour faire l’analyse de départ et la collecte
de don- nées récurrente, qui permettra de nourrir le tableau de bord, une fois celui-ci en
place. Cette collecte de données doit être, le plus possible automatisée pour faciliter le
proces- sus.
On présente dans ce qui suit toutes les tables, en précisent pour chacune d’elle ses at-
tributs, leurs types et leurs siginifcations.

3.2.1 Table Affectation

Nom de l’attribut Type Signification

ID_REGION VARCHAR2 Identificateur de région
LIB_REGION VARCHAR2 Libéllé de région
ID_ZONE VARCHAR2 Identificateur de Zone
LIB_ZONE VARCHAR2 Libéllé de Zone
ID_AGENCE VARCHAR2 Identificateur d’Agence
LIB_AGENCE VARCHAR2 Libéllé d’Agence
COMPANY VARCHAR2 Référence de la compagine

TABle 3.1 – Attribut de la table Affectation

3
 CHAPITRE 3. MODÉLISATION DE LA SOLUTION

3.2.2 Table ProtocolTC

Nom de l’attribut Type Signification

ID_ VARCHAR2 Identificateur de client
CUSTOMER_ VARCHAR2 Nom de client
Agence de rattachement
AGENCE_RATTACHEMENT_CLIENT VARCHAR2 pour chaque client
COMPANY_ VARCHAR2 Référence de la compagnie

TABle 3.2 – Attribut de la table ProtocolTC

3.2.3 Table Protocol

Nom de l’attribut Type Signification

ID_USER VARCHAR2 Identificateur de l’utilisateur
NOM_USER VARCHAR2 Nom de l’utilisateur
DATE VARCHAR2 Date de transaction par utilisateur
HEURE VARCHAR2 Heure de transaction par utilisateur
COMPANY_ VARCHAR2 Référence de compagnie
NOM_COMPAGNIE VARCHAR2 Nom de la compagnie
APPLICATION VARCHAR2 Type de transaction
ID VARCHAR2 Identificateur de l’application
IP VARCHAR2 Adresse IP de l’application
ID_PROTOCOL VARCHAR2 Identifiant de protocol

TABle 3.3 – Attribut de la table Protocol

3.2.4 Table Longitude_Latitude

Nom de l’attribut Type Signification

LR_LONGITUDE FLOAT coordonnée géographique
LR_LATITUDE FLOAT coordonnée géographique
COMPANY VARCHAR2 Référence de la compagnie

TABle 3.4 – Attribut de la table Longitude_Latitude

3
 CHAPITRE 3. MODÉLISATION DE LA SOLUTION

3.3 Choix des indicateurs

L’efficacité d’un tableau de bord reste conditionnée à la sélection des indicateurs
appro- priés et pertinents, afin de répondre aux objectifs fixés au début.
Le tableaux ci dessous permet de présenter chaque indicateur ainsi que son mode
de calcul.

Indicateurs Mode de calcul

— Count([clients par agence])
Taux d’accès aux agences par : — Count([client par zone])
-Zone. — Count([client par région])
-Région
— Count([transaction par agence])
Taux de transactions par :
— Count([transaction par zone])
-Agence.
-Zone. — Count([transaction par région)]
-Région. — Count([transaction par date)]
-Date.
Taux des opérations dans les agences de if [(COMPANY()=COMPANY(AGR) ,
rattachement client. KPIAGR=1
Taux des opérations hors des agence de if ! [(COMPANY()=COMPANY(AGR) ,
rattachement client. KPIAGR=0
if [(ID(protocol)startswith(“IU”)],
Taux d’utilisation BiatNet KPIBIATNET=1
if ![(ID(protocol)startswith(“IU”)],
Taux d’opérations hors BiatNet KPIBIATNET=0

TABle 3.5 – Liste des indicateurs et leurs modes de calcul

3.4 Liste des dimensions

Dans cette étape, nous devrons choisir les différentes dimensions ou les axes
d’analyses. Les dimensions qui constituent notre entrepôt de données sont :

1. Dimension Agence Dim_AGENCE

2. Dimension Zone Dim_ZONE
3. Dimension Région Dim_REGION
4. Dimension Date Dim_DATE
5. Dimension Agence Rattachement Dim_AGR

3
 CHAPITRE 3. MODÉLISATION DE LA SOLUTION

6. Dimension Transaction Dim_TRANSACTION

7. Dimension User Dim_USER

Par la suite, on présente l’ensemble de colonnes pour chaque dimensions.

3.4.1 Dimension AGENCE

La dimension Agence décrit les différentes agences de la banque. D’après l’étude des
besoins, il est nécessaire d’avoir le nombre d’agences dans chaque zone et région. Le
tableau suivant présente les attributs de la dimension AGENCE et définit leurs types.

Nom de colonne Type de donnée

ID_AGENCE VARCHAR2
LIB_AGENCE VARCHAR2
ID NUMBER
COMPANY VARCHAR2
ID_ZONE VARCHAR2
LR_LONGITUDE FLOAT
LR_LATITUDE FLOAT

TABle 3.6 – Dimension agence : Dim_AGENCE

3.4.2 Dimension Agence de Ratachement Client

Le tableau suivant présente les attributs de la dimension Agence Rattachement et
définit leurs types. Cette dimension permet d’identifier l’agence de rattachement de
chaque client à travers une jointure avec l’identifiant de l’opération réalisée.

3
 CHAPITRE 3. MODÉLISATION DE LA SOLUTION

Nom de colonne Type de donnée

ID NUMBER
COMPANY_ VARCHAR2
ID_ VARCHAR2
LIB_AGENCE VARCHAR2

TABle 3.7 – Dimension agence de rattachement : Dim_AGENCER

3.4.3 Dimension DATE

Le tableau suivant présente les attributs de la dimension DATE et définit leurs types.

Nom de colonne Type de donnée

DATE DATE
HEURE_ VARCHAR2
ID NUMBER

TABle 3.8 – Dimension date : Dim_DATE

3.4.4 Dimension RÉGION

Le tableau suivant présente les attributs de la dimension REGION et définit leurs types.
Cette dimension permet de présenter les différentes régions ou se trouvent les agences
afin d’analyser le nombre d’agences par région.

Nom de colonne Type de donnée

ID_REGION VARCHAR2
LIB_REGION VARCHAR2
ID NUMBER

TABle 3.9 – Dimension region : Dim_REGION

3
 CHAPITRE 3. MODÉLISATION DE LA SOLUTION

3.4.5 Dimension TRANSACTION

Le tableau suivant présente les attributs de la dimension TRANSACTION et définit
leurs types. Cette dimension permet de modéliser les opérations réalisées à travers les
agences et ceux qui sont effectuées en ligne.

Nom de colonne Type de donnée

APPLICATION VARCHAR2
ID NUMBER

TABle 3.10 – Dimension transaction : Dim_TRANSACTION

3.4.6 Dimension USER

Pour réaliser des analyses relatives aux clients, il faut créer une dimension USER
comme l’indique la figure suivante :

Nom de colonne Type de donnée

ID_USER VARCHAR2
NOM_USER VARCHAR2
ID NUMBER

TABle 3.11 – Dimension user : Dim_USER

3.4.7 Dimension ZONE

La dimension Zone désigne les différentes zones ou les agences se trouvent. Les dé-
cideurs de la direction Digital Factory et données ont besoin d’avoir le nombre des
agences dans chaque zone. La figure suivante décrit les différents attributs de cette di-
mension

Nom de colonne Type de donnée

ID_ZONE VARCHAR2
LIB_ZONE VARCHAR2
ID NUMBER
LIB_REGION VARCHAR2

TABle 3.12 – Dimension zone : Dim_ZONE

3
 CHAPITRE 3. MODÉLISATION DE LA SOLUTION

3.5 Table de Fait

Le tableau suivant présente les attributs de la table de fait FACT_BIATNET, définit
leurs types et leurs significations.

Nom de l’attribut Type Signification

ID_AGENCE NUMBER Clé primaire de la table Agence
ID_ZONE NUMBER Clé primaire de la table Zone
ID_REGION NUMBER Clé primaire de la table Région
ID_DATE NUMBER Clé primaire de la table Date
ID_AGR NUMBER Clé primaire de la table AGR
ID_TRANSACTION NUMBER Clé primaire de la table transaction
ID_USER NUMBER Clé primaire de la table USER
Indicateur clé de performance correspond aux
KPI_BIATNET NUMBER opérations BIATNET
Indicateur clé de performance correspond aux
KPI_NN_BIATNET NUMBER opérations HORS BIATNET
Indicateur clé de performance correspond aux
KPI_AGR NUMBER opérations AGENCE RATTACHEMENT
Indicateur clé de performance correspond aux
KPI_HORS_AGR NUMBER opérations HORS AGENCE RATTACHEMENT

TABle 3.13 – Attribut de la table Fait

3
 CHAPITRE 3. MODÉLISATION DE LA SOLUTION

3.6 Schéma de DataMart

Après avoir définir les dimensions et les mesures, on passe à concevoir notre Datamart.
Nous avons opté pour un schéma en étoile. C’est la structure de données la plus utilisée
et la plus appropriée aux requêtes et aux analyses des utilisateurs de DW.
L’architecture dimensionnelle de notre entrepôt de données est illustré dans la figure
suivante.

FIgUre 3.1 – "Schéma en étoile du Data Mart"

3
 CHAPITRE 3. MODÉLISATION DE LA SOLUTION

3.7 Conclusion
Ce chapitre, a présenté la conception du projet, ainsi que les tables des dimensions et la
table de fait.
Le chapitre suivant, sera une présentation de toutes les étapes de la réalisation de la
solution décisionnelle.

3
 4
CHAPITR

Réalisation

4.1 Introduction
La réalisation est la dernière phase de la mise en place de la solution business intelli-
gence que nous proposons pour la BIAT. Le but de ce chapitre est d’avoir une
application fonctionnelle à travers l’interaction de l’environnement logiciel et matériel
en exposant les différentes étapes depuis la phase ETL jusqu’à la phase reporting.

4.2 Environnement de réalisation

Les outils matériels et logiciels qui ont été nécessaires pour la réalisation du notre
projet sont :

4.2.1 Environnement matériel

Device name : DESKTOP-38MBHB6
Processor : Intel(R) Core(TM) i3-6006U CPU @ 2.00GHz 2.00 GHz
Installed RAM : 4.00 GB (3.30 GB usable)
Sytem type : 64-bit operating system, x64-based processor

4.2.2 Environnement logiciels

Cette partie présente les solutions logicielles amenant à l’élaboration du projet afin
de bien sélectionné l’environnement de travail adéquat. Ce choix est guidé aussi par
l’existant et les exigences de l’entreprise.

4
 CHAPITRE 4.

— Oracle Database

FIgUre 4.1 – "Logo de Oracle Database"

Un système de gestion de base de données produit et commercialisé par Oracle Cor-

poration. Il s’agit d’une base de données couramment utilisée pour exécuter des
charges de travail de base de données OLTP.
— Talend Data Integration

FIgUre 4.2 – "Logo de Talend"

Talend pour la partie ETL, permet d’extraire les données d’une source, de les
modifier et les recharger vers une destination.

— Dbeaver

FIgUre 4.3 – "Logo de DBeaver"

Logiciel qui permet l’administration et le requêtage de base de données. Il utilise un

driver JDBC pour les bases de données relationnelles.

— ELK(Elastic search, Logstash, Kibana)

ELK est une pile logicielle composée d’Elasticsearch, Logstash et Kibana. Ces
trois outils ont chacun un rôle bien précis dans le workflow permettant de
rechercher, d’analyser et de visualiser, en toute fiabilité et sécurité, ainsi qu’en
temps réel, des données issues de n’importe quelle source et sous n’importe quel
format.

4
 CHAPITRE 4.

FIgUre 4.4 – "Logo de Elasticsearch"

1. Elasticsearch : Est une base NoSQL qui est orientée Big Data il peut donc gérer
un très grand volume de données. Elasticsearch permet l’indexation et recherche de
don- nées. Il fournit un moteur de recherche distribué et multi-entité à travers une
interface REST. Elasticsearch est un logicile écrit en Java distribué sous licence
Elastic.

FIgUre 4.5 – "Logo de Kibana"

3. Kibana : Greffon de visualisation de données pour Elasticsearch publié sous la

licence libre Apache version 2. Kibana fournit des fonctions de visualisation sur du
contenu indexé dans une grappe Elasticsearch.

FIgUre 4.6 – "Logo de Logstash"

3. Logstash : Est un outil de collecte, d’analyse et de stockage de logs. Il est généra-

lement associé avec Elasticsearch, moteur de recherche distribué, et Kibana, interface
d’Elasticsearch. Logstash est capable d’intégrer une multitude de sources simultané-
ment.

4.3 Description des processus ETL

L’ETL, est une étape importante dans un projet Data Mart.
Cette étape a pour objectif d’assurer l’acheminement des données des systèmes sources
jusqu’à l’entrepôt de données, en passant par les différentes phases de nettoyage et de
transformations nécessaires.

4
 CHAPITRE 4.

4.3.1 Les outils ETL

Avant de commencer notre travail, nous avons mené une étude sur quelques solutions
open source pour choisir l’outil qui convient à notre besoin. Plusieurs solutions ETL
open source existent sur le marché. Nous avons choisi de faire une comparaison entre
les deux outils les plus utilisés à savoir : Talend Open Studio (TOS) et Pentaho Data
Integration (PDI).

Talend Open Pentaho Data

Studio Integration Explication
TOS a une gamme plus
Fonctionnalité ++ - grande de composants
TOS consomme
Performance - ++ beaucoup de mémoire
Le lancement des jobs
est plus rapide pour
Rapidité ++ - TOS
TOS dispose une
interface plus pratique
Convivialité ++ + et plus agréable
TOS nous offre la
possibilité de créer des
modules et de coder
Architecture ++ - plus de fonctions
TOS qui affiche les
erreurs détaillées pour
l’utilisateur : TOS
utilise des Bug
Qualité ++ - Trackers.
Dans TOS il existe un
référentiel qui permet
Référentiel vers de stocker des
métadonnées ++ - métadonnées

TABle 4.1 – Etude comparative entre TOS et PDI

Échelle de l’évaluation : ++ : L’emporte largement, + :l’emporte, - : dominé

Les deux outils sont fiables, performants et conviviaux mais étant donné que Talend
est une plate-forme de gestion des données plus générale et complète, nous avons opté
de l’utiliser dans la partie intégration.

4
 CHAPITRE 4.

4.3.2 Étapes ETL

Nous présentons les étapes de création des jobs sous Talend qui a comme but de migrer
les données des fichiers.CSV vers une base de données SQL.
Les job Talend comporte les étapes suivantes :
— Création d’une connexion avec la base de données : Il s’agit de choisir le type
de la Base de données et de remplir les différentes informations pour de
connecter à la base.
— Création de schéma de la table cible : Il s’agit de récupérer le schéma de la
table cible.
— Définition du Job : C’est le processus de lecture et de transformation des don-
nées puis leur chargement dans la table cible.

4.3.2.1 Extraction des données

— Notre ETL commence par la connexion à la base SQL "BIAT_BIGITAL" à travers

l’ETL "Talend Data Integration".
Nous avons indiqués les paramètres nécessaires pour la connexion : DB Type,
identifiant, mot de passe, serveur, nom de base de données. L’espace du travail
nommée Job au niveau duquel se déroule tout le travail d’ETL.
La figure suivante présente l’étape de la connexion à la base de données SQL.

FIgUre 4.7 – "Connexion à la base de données SQL"

4
 CHAPITRE 4.

— Une fois la connexion est établie avec succés, nous pouvons parcourir l’ensemble
des fichiers.CSV : "Affectation", "LONG_LATITUDE_AGENCE", "PREProto-
col", "TCPROTOCOL".
La figure suivante montre l’extraction et le chargement des données à partir des
fichiers.

FIgUre 4.8 – "Extraction des données"

4.3.2.2 Transformation des données

La transformation des données a pour but de vérifier les types des données
importées et contrôler l’intégrité de ces données.
Dans cette étape nous avons appelé le composant Tmap, c’est l’un des composant
prin- cipaux utilisé pour mapper les données d’entrée vers les données de sortie
( mapper un schéma à un autre). Il permet aussi d’appliquer des filtres et des jointures.

1. Transformation de la table ProtocolTC :

Dans le JOB du Talend nous avons pris comme input un fichier délimité TC_PROTOCOL.
Un flux de données sera transmis à l‘aide du composant Tmap pour assurer un
stockage des données dans la table cible STG_PROTOCOLTC dans la base de
données BIAT_DIGITAL.
Au niveau du composant Tmap, on a apporté des modifications sur les colonnes
de la table. L’expression ReplaceALL("¨","") nous a permis de les nettoyer.

4
 CHAPITRE 4.

FIgUre 4.9 – "Transformation de la table ProtocolTC"

2. Transformation de la table Affectation :

Dans le JOB du Talend nous avons pris comme input un fichier délimité
Affecta- tion. Un flux de données sera transmis à l‘aide du composant Tmap
pour assurer un stockage des données dans la table cible STG_AFFECTATION
dans la base de données BIAT_DIGITAL.
Au niveau du composant Tmap, on a apporté des modifications l’expression avec
ReplaceALL("¨","") qui nous a permis de nettoyer la colonne ID.

4
 CHAPITRE 4.

FIgUre 4.10 – "Transformation de la table Affectation"

3. Transformation de la table Protocol :

Dans le JOB du Talend nous avons pris comme input un fichier délimité Proto-
col Un flux de données sera transmis à l‘aide du composant Tmap pour assurer
un stockage des données dans la table cible STG_PROTOCOL dans la base de
données BIAT_DIGITAL.
Au niveau du composant tmap, on a pu convertir la date du type String en type
Date tout en modifiant le format à l’aide de l’expression TalendDate.ParseDate.
Et aussi on a apporté des modifications avec l’expression ReplaceALL("¨","")
qui nous a permis de nettoyer les colonnes.

4
 CHAPITRE 4.

FIgUre 4.11 – "Transformation de la table Protocol"

4.3.2.3 Chargement des données

Cette partie consiste à préparer et charger les dimensions(Dim_Agence,

Dim_AgenceR, Dim_User, Dim_Date, Dim_Zone, Dim_Transaction).
1. Chargement dimensions Agence :

Nous avons alimenté la dimension à travers le composant tDBOutput représenté

sous le nom « BIAT_DIGITAL ».
Tmap nous permis d’effectuer les jointures nécessaires pour le référencement
entre les tables de la source et les tables de dimensions.
Le travail est présenté par la figure suivante.

4
 CHAPITRE 4.

FIgUre 4.12 – "Chargement de la dimension AGENCE"

Chargement de la dimension Agence de rattachement :

FIgUre 4.13 – "Chargement de la table dimension AGR"

4
 CHAPITRE 4.

Chargement de la dimension user :

FIgUre 4.14 – "Chargement de la table dimension AGR"

Toutes les dimensions ont été construites de la même manière. Leurs transformations
se différencient soit par élimination de quelques attributs qui ne sont pas utiles ou bien
qui sont redondants, soit par les règlements de certains types d’attributs qu’ils
soient conformes ou pour assurer leur chargement d’une manière correcte.

4.3.2.4 Création et chargement du Data mart

La première étape à réaliser pour mettre en place notre solution Big Data est de créer
le schéma multidimensionnel en étoile avec l’outil Talend.

Aprés l’alimentation des dimensions, nous arrivons à l’alimentation de la table de fait.

5
 CHAPITRE 4.

Les figures suivantes présentent les étapes de l’alimentation du table de fait

FACT_BIATNET tel que output BIAT_DIGITAL.

FIgUre 4.15 – "Création du job de schéma multidimensionnel"

5
 CHAPITRE 4.

Pour effectuer le chargement d‘une table de fait nous avons recours aux dimensions
déjà alimentées(Dim_Agence, Dim_AgenceR, Dim_User, Dim_Date, Dim_Zone,
Dim_Transaction) pour référencer les données à alimenter. Tout cela est assuré par
l‘outil « tmap » qui nous a permis d‘effectuer les jointures nécessaires.

Nous avons combiner les tables de dimensions et la table de fait à travers "main row"
avec le maximum des colonnes.

FIgUre 4.16 – "Main row "

FIgUre 4.17 – "Les jointures"

5
 CHAPITRE 4.

La jointure de DIM_AGENCE avec la colonne ID_AGENCE.

La jointure de DIM_ZONE avec la colonne ID_ZONE.
La jointure de DIM_REGION avec la colonne ID_REGION.
La jointure de DIM_DATE avec la colonne ID_DATE.
La jointure de DIM_TRANSACTION avec la colonne ID_TRANSACTION.
La jointure de DIM_USER avec la colonne ID_USER.
La jointure de DIM_AGR avec la colonne ID_AGR.

Résultat de chargement de la table de fait FACT_BIATNET :

FIgUre 4.18 – "Aperçu de FACT_BIATNET"

5
 CHAPITRE 4.

4.4 Développement de l’application BI

Avant de se lancer tête baissée dans le déploiement d’un serveur NoSQL, une
entreprise devra se poser plusieurs questions. Qu’est-ce qui est recherché en premier?
La vitesse ? La volumétrie? La recherche multicritères? En fonction des réponses, elle
s’orientera vers l’une ou l’autre des grandes familles de base NoSQL.
Elasticsearch est avant tout connu pour son moteur de recherche distribué. Il utilise la
bibliothèque d’indexation open source Lucene tout comme Apache Solr à qui il est
sou- vent comparé. Cet outil permet de stocker et analyser des données, structurées ou
non, comme des textes libres ou des logs systèmes. Projet open source développé en
Java sous licence Apache, Elasticsearch est associé à deux autres produits open source
: le visua-
liseur de données Kibana et l’outil d’extraction, de transformation et de chargement de
[ ]
données (ETL) Logstash. 6

FIgUre 4.19 – "Input du fichier Log"

4.4.1 L’ingestion de données avec "Logstash/Elasticsearch"

Le chargement des données d’une source de base de données oracle vers Elasticsearch
passe par logstash .
Dans les figures suivantes nous présentons un plug-in d’entrée , un filtre et un plug-in
de sortie.

1. Input du fichier Log :

Dans cette partie, nous avons spécifié : User, Password, Connection string, et
JDBC driver path.
— Elasticsearch est une base de données non SQL, elle ne reconnaît pas les join-
tures établies. C’est pourquoi nous ne pouvons pas charger le fait tel quel sans
remplacer les ID des dimensions avec les noms correspondants.
— Pour obtenir les noms correspondants, nous avons effectué une jointure de la
table de fait avec toutes ses dimensions afin d’avoir leurs noms.

5
 CHAPITRE 4.

FIgUre 4.20 – "Input du fichier Log"

2. Filtre du fichier Log :

Elasticsearch ne comprendra pas les coordonnées des agences avant de les trans-
former en type de géopoint.
— Nous avons créé une variable de type de géolocalisation nommée loca- tion.
— Nous avons converti les attributs "lr_latitude" et "lr_longitude" en type float.

FIgUre 4.21 – "Filtre du fichier Log"

3. Output du fichier Log :

— Nous avons spécifié Database host et nous avons nommé la table chargée.
— Nous avons configuré : User et Password.

5
 CHAPITRE 4.

FIgUre 4.22 – "Output du fichier Log"

4. Index_biatnet :
La figure suivante présente le résultat du chargement de la base de données dans
Elasticsearch.

FIgUre 4.23 – "Index_biatnet"

5
 CHAPITRE 4.

4.4.2 Visualisation des données avec kibana

FIgUre 4.24 – "Interface Login kibana"

Grâce à la page DISCOVER de l’interface Kibana nous pouvons explorer les données .
Cette interface se décompose en trois parties :
— Un Toolbar pour les recherches.
— Un histogramme pour voir la distribution des indexe dans le temps.
— Un tableau des documents qui comporte l’ensemble des indexes. Par conséquent,
nous pouvons accéder à chaque indexe qui représente un enregistrement de la
base de donnée et qui est représenté sous forme de document JSON.
Ainsi nous pouvons faire des requêtes de recherche, filtrer les résultats et afficher les
données. Nous avons la possibilité finalement de configurer le champ du temps pour
changer la distribution des documents au fil du temps dans l’histogramme et
paramétrer la durée de rafraîchissement des données pour récupérer les données
rajoutées à Elasticsearch comme le montre la figure suivante.

5
 CHAPITRE 4.

FIgUre 4.25 – "Interface Discover Kibana"

1. Tableau de bord : Agence .

Le tableau de bord Agence a pour but :

— D’avoir une vision sur la distribution des agences par zone et par région.
— D’avoir la répartition des agences.
— De comparer le nombre et la nature d’opérations effectuées dans chaque agence
pour chaque région et pour chaque zone.
— De comparer le nombre et la nature d’opérations effectuées dans chaque agence
pour les quatre régions pendant une année.
— De manipuler le tableau de bord en utilisant des filtres.

Les figures suivantes présentent les visualisations détaillées :

5
 CHAPITRE 4.

FIgUre 4.26 – "Interface de tableau de bord Agence 1.1"

FIgUre 4.27 – "Interface de tableau de bord Agence 1.2"

5
 CHAPITRE 4.

FIgUre 4.28 – "Interface de tableau de bord Agence 1.3"

2. Tableau de bord : BIATNET.

Le tableau de bord BIATNET a pour but :

— De distinguer les clients qui utilisent Biatnet.
— De déterminer nombres de clients qui réalisent des opérations en ligne.
— De comparer le nombre d’opération réaliser à travers Biatnet et hors Biatnet.
— De comparer la nature d’opération réaliser à travers Biatnet et hors Biatnet.
— D’avoir une comparaison entre les quatre régions à propos d’utilisation de Biat-
net.
— D’avoir la répartition des clients éligibles et non éligibles à l’offre digitale
dans toutes les régions et les zones.
— De manipuler le tableau de bord en utilisant des filtres.

Les figures suivantes présentent les visualisations :

FIgUre 4.29 – "Interface tableau de bord BIATNET 1.1 "

6
 CHAPITRE 4.

FIgUre 4.30 – "Interface tableau de bord BIATNET 1.1"

3. Tableau de bord : Agence de rattachement.

Le tableau de bord Agence de rattachement a pour but :

— D’analyser les opérations réalisées par les clients à travers leurs agences de rat-
tachement, et celles réalisées à travers d’autres agences.
— De déterminer le nombre de clients qui réalisent des transactions dans leurs
agences de rattachement.
— De déterminer le nombre de clients qui réalisent des transactions hors leurs
agences de rattachement.
— De déterminer le nombre et la nature d’opérations réalisées dans les agences de
rattachement des clients.
— De déterminer le nombre et la nature d’opérations réalisées hors des agences de
rattachement des clients.
— De comparer entre le nombre et la nature des opérations réalisées dans les
agences de rattachement client, et celles qui sont réalisées hors des agences
de rattache- ments client.
— De manipuler le tableau de bord en utilisant des filtres.
— D’avoir la répartition des clients qui effectuent des opérations dans leurs agences
de rattachement dans les régions et les zones.
— D’avoir la répartition des clients qui effectuent des opérations hors leurs agences
de rattachement dans les régions et les zones.

Les visualisations sont présentées dans les figures suivantes :

6
 CHAPITRE 4.

FIgUre 4.31 – "Interface tableau de bord Agence de rattachement"

FIgUre 4.32 – "Interface tableau de bord Agence de rattachement"

4.5 Conclusion
Dans ce chapitre nous avons présenté l’environnement logiciel et matériel avec lequel
cette solution a été réalisé. Ensuite, les interfaces d’ETL et de reporting de la solution
d’analyse multidimensionnel, puis nous avons présenté les tableaux de bord réalisés.
Le tableaux de bord permettra au décideur d’organiser ses données et en retenant que
l’essentiel. Cette synthèse sera une sorte de bilan de certains point bien précis de l’ac-
tivité.

6
Conclusion
Exploiter les données à disposition de l’entreprise afin de leur donner de la valeur
ajouté, tel est le défi des entreprises modernes.
Dans ce cadre, et afin de palier à des problèmes récurrents dans le processus de prise de
décision, la Banque Internationale Arabe de Tunisie a initié le projet de réalisation d‘un
Data Mart pour permettre la mise en place d‘un système décisionnel fiable et efficace.
Tout au long de notre travail, nous avons essayé de suivre la démarche de conduite
d’un projet BI, allant de l’identification des sources de données jusqu’à la phase de
restitu- tion.
Nous avons opté pour la méthodologie Scrum au cours du développement de notre so-
lution. Nous avons détaillé en premier lieu les besoins des décideurs, les outils et les
méthodes BI. Puis nous nous sommes tournés en second lieu vers la modélisation de
notre Datamart, nous avons suivi les régles de la modélisation dimensionnelle pour
aboutir au schéma en étoile de notre Datamart. Nous avons par conséquent appliqué
un processus d’extraction, de transformation et de stockage pour mettre en place cette
solution. Cette partie ETL a été la partie du projet la plus fastidieuse et consommatrice
en temps. Cette partie nous a permis de concevoir et de réaliser les routines
d’extraction, de transformation et de chargementdes données sous l’outil TOS (Talend
Open Studio For Data Integration).
En dernier lieu, nous avons arrivé à consolider et restituer les données via la suite ELK
(Elasticsearch Logstash Kibana).

Avant de clôturer cette conclusion, nous pourrons dire que ce stage au sein de la
BIAT nous a permis de faire évoluer considérablement nos connaissance dans le
domaine BI et de renforcer ainsi nos compétences sur les outils associés à ce domaine à
savoir base de données, ETL, Tableau de bord, ect. Nous avons également améliorer
nos connais- sances en matière de gestion des projets en générale en BI en particulier.
La solution a été exposé et testée devant les responsables du département d’accueil qui
ont exprimé leur satisfaction.

En guise de perspective, notre solution a l’avantage d’être ouverte et extensible. En

effet, l’application présente plusieurs points d’amélioration qui seront traités prochai-
nement, à savoir développer une application web qui présente une platform, avec la
gestion d’accès des utilisateurs aux différents tableaux de bord et rapports. En effet
chaque utilisateur possède un compte sur lequel, il a accès seulement aux rapports dont
il a besoin, avec la possibilité de téléchargement de ces rapports en plusieurs formats.

6
Bibliographi
[1] : https:
//www.biat.com.tn/la-biat/presentation-generale
[2] : https://www.biat.com.tn/sites/default/files/
2020-09/BIAT-RA2019-vfr.pdf
[3] : https://www.journaldunet.com/solutions/dsi/
1194284-base-nosql-laquelle-choisir-pour-quels-besoins/
[4] : https://www.lemagit.fr/definition/
NoSQL-base-de-donnees-Not-Only-SQL
[5] : https://community.talend.com/
[6] : https://www.elastic.co/fr/what-is/elk-stack
[7] : https://www.elastic.co/
[8] : https://www.next-decision.fr/
[9] : https://www.overleaf.com/
[10] : https://openclassrooms.com/

Thèse

Ines BEN KRAIEM, Modélisation et intégration de données de capteurs/compteurs du

SGE, Juillet 2017
Abdallah BENSLIMANE- Abdel Hafid BOUKLIHACENE, Développement d’une
solution Business Intelligence pour la scolarité de l’Université deTlemcen, 2016-
2017 Sawssen Riahi, Conception, développement et mise en place d’une solution
Décisionnelle pour l’activité monétique, 2013-2014

Ouvrage
framabook5_latex_v1_art-libre, 2e semestre 2008
support de formation Formation Talend Open Studio for Data Integration, : 19/06/2017
elasticsearch-fr.pdf
Introduction aux technologies et applications Big Data, 2018

6
 Bibliographie

Résumé

Le présent projet s’inscrit dans le cadre d’un projet de fin d’étude en

vue de l’obtention d’un Mastère Professionnel en Ingénierie des Systèmes
d’information et des connaissances.
Ce projet vise à concevoir et à appliquer une approche méthodologique
afin de construire un prototype d’entrepôt de données et ainsi faciliter
la prise de décision par l’élaboration de tableaux de bord présentés à
l’intention des responsables. Il s’agit d’avoir une "vision 360" sur les
ac- tivités financières des clients et distinguer ceux qui sont éligibles
pour l’offre digitale. La solution proposée offre 3 modules qui sont
l’analyse des agences, l’analyse des opérations réalisées à travers
l’application Bi- atnet et l’analyse des opérations réalisées à travers les
agences.

Abstract

This project is part of an end-of-study project in order to get a

Professio- nal Masters in Information Systems and Knowledge
Engineering.
This project aims to design and apply a methodological approach in
order to build a data warehouse prototype and to facilitate decision-
making by developing dashboards presented for managers. It is about
having a "360 vision" on the financial activities of clients and
distinguishing those who are eligible for the digital offer. The proposed
solution offers 3 modules which are the analysis of agencies, the
analysis of transactions through Biatnet application and the analysis of
transactions through the agencies.