BaccoucheHellaMise en Place Dun Entrepot de Données Pour Le Processus Doctroit Des Credits de Gestion Copie 1

REPUBLIQUE TUNISIENNE
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

ET DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITE TUNIS EL MANAR
FACULTE DES SCIENCES ECONOMIQUES

ET DE GESTION DE TUNIS
MEMOIR DE FIN D’ETUDES
Pour l'obtention de diplôme de Master professionnel en Ingénierie

des systèmes d'information de l'entreprise
Thème
Mise en place d'un entrepôt de données pour le

processus d'octroi de crédit de gestion
Réalisé au sein de la BNA
Réalisé par : Baccouche Hella Encadrants : FSEGT Mme Kboubi Fariha

BNA Mme. Manaa Marwa
Année Universitaire 2017/2018

Remerciements
A la clôture de ce travail et avant d’entamer la rédaction de ce
rapport, je tiens à exprimer dans un premier temps, mes
remerciements les plus sincères à Mme. Marwa Menaa pour la
proposition de ce sujet, sa disponibilité, son soutien et sa
précieuse aide lors de l’élaboration du projet.
Je remercie aussi l’ensemble du personnel du service BNA qui a
été accueillant, chaleureux et compréhensif.
J’adresse mes vifs remerciements à mon encadrante, Mme
ferihane Kboubi, enseignante à la faculté de la science
économique et de gestion de Tunis, pour son entière disponibilité,
son aide inestimable et ses conseils, sans lesquels ce travail
n’aurait pu aboutir.
Je remercie très sincèrement, les membres du jury d’avoir bien
voulu accepter de faire la commission d’examinateurs.
Finalement j'adresse mes plus sincères remerciements à tous mes
proches et amis qui m'ont toujours soutenu et encouragés au
cours de la réalisation de ce projet ainsi qu’à nos prof qui ont
contribué à la réussite de cette formidable année universitaire.
J'adresse aussi mes sincères remerciements à tous ceux qui ont
participé de près ou de loin à la réalisation de ce projet, aux
personnes qui, malgré que leurs noms ne figurent pas dans ce
document, étaient toujours prêtes à aider et à contribuer dans le
bon déroulement de ce travail.
Dédicaces
A:
Mes parents, pour leur soutient indéniable et leur aide

précieuse
« Pourrais-je jamais vous dire tous mon amour»,
Mon frère Aymen et mes sœurs Imen et Hayfa pour leurs

encouragements et leur amour,
Tous les membres de la famille, pour l’intérêt qu’ils m’ont

montré,
Mes amis, pour tous ce qu’on a partagés ensemble,
Toutes les personnes proches que je n’ai pas citées
Je dédie ce travail.
HELLA
Table des matières
Introduction générale......................................................................................................1
Chapitre 1 : Contexte du projet.....................................................................................4
Introduction...............................................................................................................5
1. Organisme d’accueil..........................................................................................5
1.1 Histoire de la BNA......................................................................................5
1.2 Présentation de la banque « BNA ».............................................................6
1.3 Produit et services........................................................................................7
2. Description du cadre de travail..........................................................................8
3. Présentation du projet........................................................................................9
3.1 Problématique............................................................................................10
3.2 Objectifs....................................................................................................10
4. Méthodologie de travail...................................................................................11
4.1 Comparaison des methodologies de travail...............................................11
4.2 Choix de la méthodologie de travail..........................................................12
5. Planification du projet.....................................................................................15
Conclusion...............................................................................................................16
Chapitre 2 : Etat de l'art...............................................................................................17
Introduction.............................................................................................................18
1. La business intelligence au service de l’entreprise..........................................18
1.1. Modélisation.............................................................................................20
1.1.1 Les entrepôts de données au service de la BI.....................................20
1.1.2 Architecture du SID............................................................................21
1.1.3. L'ETL (extract transform load)..........................................................22
1.1.4 Datawarehouse (Entrepôt de données)...............................................23
1.1.5 Magasins de données (Datamarts)......................................................25
1.1.6 Modélisation multidimensionnelle.....................................................26
1.2 Analyse......................................................................................................28
1.2.1 OLAP (On-Line-Analytical-Processing)............................................28
1.3Visualisation...............................................................................................31
1.3.1 Le reporting........................................................................................31
1.3.2 Tableau de bord (Dashboard).............................................................31
1.3.3 Fouille de données (Datamining).......................................................32
Coclusion.................................................................................................................33
Chapitre 3 : Etude de l'existant et spécification de besoin..........................................34
Introduction.............................................................................................................35
1. Etude de l’existant...........................................................................................35
1.1 Description du système d'information de la BNA.....................................35
1.2 Critique de l’existant.................................................................................37
1.3 Solution proposée......................................................................................38
2. Spécification des besoins.................................................................................38
2.1 Identification des acteurs...........................................................................38
2.2. Branche fonctionnelle...............................................................................38
2.2.1 Les besoins fonctionnels.....................................................................38
2.2.2 Les besoins non fonctionnels..............................................................40
2.3 Branche technique.....................................................................................41
2.3.1Etude comparative des ETLs...............................................................41
2.3.2 Etude comparative des outils de restitution........................................42
2.3.3 Bilan des études comparatives............................................................43
Conclusion...............................................................................................................44
Chapitre 4 : Conception...............................................................................................45
Introduction.............................................................................................................46
1. Conception de l’entrepôt des données.............................................................46
1.1 Présentation de l’activité « l'octroi de crédit »..........................................46
1. 2 Choix des dimensions...............................................................................47
1.2.1 Dim_Crédit.........................................................................................48
1.2.2 Dim_garanties.....................................................................................49
1.2.3 Dim_date............................................................................................50
1.2.4 Dim_agence........................................................................................50
1.2.5 Dim_direction_decision.....................................................................51
1. 3 Choix des mesures....................................................................................51
1.4 Table de faits.............................................................................................52
1.5 Structure du Data warehouse.....................................................................53
2. Conception ETL..............................................................................................54
2.1 Etude des données sources........................................................................54
2.1.1 Bases de données sources...................................................................54
2.2 Extraction des données..............................................................................60
2.3 Transformation des données......................................................................61
2.4 Chargement des données :.........................................................................63
3. Conception du tableau de bord........................................................................64
Conclusion...............................................................................................................65
Introduction.............................................................................................................67
Chapitre 5 : Réalisation...............................................................................................66
1. Environnement matériel et logiciel.................................................................67
1.1 Environnement matériel............................................................................67
1.2 Environnement logiciel.............................................................................67
1.2.1 Oracle SQL Développer 12c..............................................................67
1.2.3 ETL : Talend Open Studio v 7.0.1....................................................68
1.2.4 Outil décisionnel QlikView...............................................................68
1.2.5 EarthViewMaps..................................................................................69
2. Architecture globale de l'application...............................................................70
3. Réalisation de la phase ETL............................................................................70
3.1 Composants Talend utilisés.......................................................................71
3.2 Préparation de l’environnement de l’ETL.................................................72
3.3 Alimentation de l’entrepôt.........................................................................73
3.3.1 Transformation des données...............................................................73
3.3.2 Alimentation des dimensions.............................................................78
3.3.3 Alimentation de la table de faits « Fait »............................................83
3.4 Processus ETL global : job « DataMart_Crédit ».....................................84
3.5 Mise à jour des données de l’entrepôt.......................................................85
4. Réalisation du tableau de bord........................................................................86
4.1. Connexion à l’entrepôt de données :........................................................87
4.2 Chargement des données dans QlikView..................................................88
4.3 Interfaces homme-machine.......................................................................89
4.3.1 Ecran d’accueil...................................................................................89
4.3.2 Ecran de la situation globale...............................................................90
4.3.3 Ecran de la feuille « crédit »...............................................................91
4.3.4 Ecran de la feuille « Les garantie »....................................................92
4.3.5 Ecran de la feuille « Temps ».............................................................93
Conclusion...............................................................................................................94
Conclusion générale................................................................................................95
Bibliographie...................................................................................................................97
TABLE DES FIGURES
Figure 1: Historique de la BNA.........................................................................................6
Figure 2: Organigramme de la BNA................................................................................7
Figure 3: Méthodologie 2TUP [2]...................................................................................14
Figure 4: Diagramme de Gantt........................................................................................15
Figure 5 : Le système de l'informatique décisionnel au service de l'entreprise [2].........19
Figure 6 : Ensemble des composants intervenant dans un système décisionnel [2]........21
Figure 7: Schéma de fonctionnement d’un ETL. [2]......................................................23
Figure 8 : Opérateurs Slicing [2].....................................................................................29
Figure 9: Opérateur Rotate [2]........................................................................................30
Figure 10 : Opérateurs Roll-Up et Drill-Down [2]..........................................................30
Figure 11: Interface de l'application métier SMILE........................................................36
Figure 12: Interface SAEB..............................................................................................36
Figure 13: système en scilos : montre l'hétérogénéité des données................................37
Figure 14: Processus d'octroi des crédits.........................................................................47
Figure 15: Modèle en étoile du datawarehouse...............................................................54
Figure 16: La table « crédit »..........................................................................................55
Figure 17: Structure de la table « Crédit »......................................................................56
Figure 18: Structure de la table « garantie »....................................................................57
Figure 19: Structure de la table « produits »...................................................................58
Figure 20: Structure de la table agence...........................................................................59
Figure 21: Structure de la table direction décision..........................................................60
Figure 22: Données non cible dans la table « Garantie».................................................61
Figure 23 : Données redondante dans la table « Garantie».............................................61
Figure 24: Données ambigu dans la table « Garantie»....................................................62
Figure 25 : valeur manquante dans table garantie...........................................................62
Figure 26: Diagramme d’activité du processus d’alimentation.......................................63
Figure 27 : Oracle 12c.....................................................................................................68
Figure 28 : Talend Open Studio......................................................................................68
Figure 29 : QlikView.......................................................................................................69
Figure 30 : Interface Earth View Maps...........................................................................69
Figure 31: Architecture globale de notre application......................................................70
Figure 32: Création projet...............................................................................................72
Figure 33: Paramétrage de la connexion de la base de données source..........................72
Figure 34: La connexion à la base de production créée..................................................73
Figure 35 : Transformation et alimentation de dim_garantie..........................................74
Figure 36: Mapping de la table garantie.....................................................................75
Figure 37: Division de la colonne nat_gar......................................................................76
Figure 38 : Suppressions des données redondantes.........................................................77
Figure 39 : Mapping de table produit..............................................................................77
Figure 40 : Capture d'écran avec tUniqurow...................................................................78
Figure 41 : Transformation et alimentation de dim_gar..................................................79
Figure 42 : job Structure..................................................................................................79
Figure 43 : job Dim_crédit..............................................................................................80
Figure 44 : Mapping de dim_crédit.............................................................................80
Figure 45 : Constructeur d'expression.............................................................................81
Figure 46 : job Dim_credit..............................................................................................82
Figure 47: Le Mapping du job «dim_date »....................................................................82
Figure 48 : job Fait........................................................................................................83
Figure 49: Le Mapping du job FAIT...............................................................................84
Figure 50: Fait_credit......................................................................................................85
Figure 51 : Ordonnanceur des tâches Talend [20]...........................................................86
Figure 52: Interface d’accueil de « QlikView »..............................................................87
Figure 53: Configuration de la source de données « DWH-connection ».......................87
Figure 54: Etablissement de la connexion entre QlikView et l’entrepôt des données....88
Figure 55: Script pour le chargement des données dans QlikView.................................88
Figure 56: Visionneur de tables.......................................................................................89
Figure 57: Interface d’accueil..........................................................................................89
Figure 58: Ecran de la feuille « Situation globale »........................................................90
Figure 59: Ecran de la feuille « Crédit ».........................................................................91
Figure 60: Ecran de la feuille « Garantie »......................................................................92
Figure 61: Ecran de la feuille « Temps »........................................................................93
TABLE DES TABLEAUX
Tableau 1: Tableau comparatif des différentes méthodologies de Travail......................12
Tableau 2: Tableau comparatif entre les tables de faits et les tables de dimensions.......28
Tableau 3: Comparaison basée sur le critère des fonctionnalités....................................42
Tableau 4: Tableau comparatif des outils de restitution..................................................43
Tableau 5: Description de la dimension dim_crédit........................................................49
Tableau 6: Description de la dimension dim_garantie....................................................49
Tableau 7: Description de la dimension «dim_date ».....................................................50
Tableau 8: Description de la dimension «dim_agence ».................................................51
Tableau 9: Description de la dimension «dim_diection_decision».................................51
Tableau 10: Récapitulatif des indicateurs........................................................................52
Tableau 11: La table de faits...........................................................................................53
Tableau 12: La table « garantie».....................................................................................56
Tableau 13: Table «produit»...........................................................................................57
Tableau 14: La table « agence »......................................................................................58
Tableau 15: La table « Direction décision »....................................................................59
Introduction Générale
Introdu ction générale
La mondialisation des échanges, la globalisation des marchés et l’innovation

technologique constituent des facteurs de multiplication des risques qui rendent le
management des entreprises de plus en plus difficile à une échelle économique
mondiale. C’est ce contexte qui a engendré un accroissement de plus en plus important
du volume d’information. Ainsi, l’entreprise doit extraire des connaissances à valeur
ajoutée afin d’agir à temps à certaines situations ou même pour prendre des décisions
stratégiques. Ces informations doivent être extraites, transformés et chargés dans un
entrepôt de données unique et mises à la disposition des décideurs des entreprises.
Dès les années 60, les données informatisées dans les organisations ont pris une
importance qui n’a cessé de croître. Les systèmes informatiques gérant ces données sont
utilisés essentiellement pour faciliter l’activité quotidienne des organisations. La
démocratisation de la micro-informatique dans les années 80 a permis un important
développement de ces systèmes augmentant considérablement les valeurs des données
informatisées disponibles.
Face aux évolutions nombreuses et rapides qui s’imposent aux organisations, la

prise de décision est devenue dès les années 90 une activité primordiale nécessitant la
mise en place des systèmes dédiés et efficaces. A partir de ces années, les éditeurs de
logiciels ont proposé des outils facilitant l’analyse des données pour soutenir les prises
de décision. Les tableurs sont probablement les premiers outils qui ont été utilisés pour
analyser les données à des fins décisionnelles. Le développement des systèmes dédiés à
la prise de décision a vu naître des outils Extract-Transform-Load (E.T.L.) destinés à
faciliter l’extraction et la transformation des données bruts à savoir non interprétées,
hétérogènes et redondantes.
Dans le cadre de notre stage au sein de la BNA, le système d'information se

compose d'un noyau gérant l'aspect comptable et le référentiel et de plusieurs
applications métiers structurés en silos à savoir système agence, système de gestion des
crédits, système de gestion des garanties, etc. Cette organisation engendre l'absence
d'une vision globale sur les objectifs de la banque et que chaque système offre une
1
visibilité sur son métier. De ce fait, la direction générale rencontre alors une difficulté
pour avoir une vision consolidée des indicateurs de performance de la banque et dispose
de l'information par service. Parmi des indicateurs, nous traitons le cœur de métier de la
banque qui est "le crédit". Le système d'information de la BNA ne permet pas d'avoir
une analyse approfondie des différents états de traitement du processus d'octroi et de
gestion des dossiers de crédit et des garanties y afférentes. Ces insuffisances sont dues à
l’hétérogénéité des données dans les différents systèmes de gestion.
C’est dans ce cadre que s’insère notre projet intitulé «Mise en place d'une
application BI d'analyse des dossiers de crédit » et qui consiste à modéliser un entrepôt
de données d’octroi de crédit de gestion et d’analyser le processus d'octroi de crédit
dans ses différents phases.
Ainsi la réalisation de ce projet nous amène à suivre le plan de travail en quatre

chapitres organisés comme suit :
 Chapitre 1 : « Contexte du projet »

Le premier chapitre est dédié à la présentation du projet et de son contexte général
d’une part. D’autre part, il inclut la problématique et les solutions proposées. Vers la fin
de ce chapitre, nous présentons la méthodologie de travail à suivre.
 Chapitre 2 : « Etat de l'art »

Ce chapitre présente une vue générale de l’état de l’art de la littérature de l'informatique
décisionnelle dans l'entreprise dès la modélisation, l'analyse jusqu'à la visualisation des
données.
 Chapitre 3 : «Etude de l’existant et spécification des besoins»

Ce chapitre présente une description du système d'information de la BNA, qui permet
de déterminer les critiques de l'existant, ainsi que les solutions proposés.
 Chapitre 4 : « Conception»
Ce chapitre est consacré à la conception générale et détaillée de l’application à mettre en
place. Il présente la conception de l'entrepôt des données, la conception de l'ETL et la
conception du tableau de bord.
 Chapitre 5 : « Réalisation »
Ce dernier chapitre décrit l'architecture technique (l’environnement matériel et logiciel
du développement), les outils de conception et de développement, ainsi que la
2
représentation de quelques interfaces de notre application sous formes des captures

écrans commentés qui montrent la phase de réalisation du processus ETL et représente
la phase de reporting et la visualisation des données.
Conclusion Générale
Nous concluons avec la présentation des principaux résultats attenus et les perspectives
d’amélioration, de la présente application.
3
Chapitre 1 : Contexte du projet
Chapitre 1 :
Contexte
du projet
Introduction
4
Ce chapitre est consacré à la présentation de l’organisme d’accueil. Ensuite, nous

présentons le contexte de travail et nous abordons la problématique et les objectifs.
A la fin de ce chapitre nous justifions la méthodologie de conception adoptée et

nous décrivons le plan de travail à suivre tout au long du projet.
1. Organisme d’accueil
1.1 Histoire de la BNA
À l'époque de sa création, l'agriculture tunisienne est financée par l'ancien système

de crédit agricole constitué par la Caisse mutuelle de crédit agricole, la Caisse foncière.
La banque national agricole BNA est fondée le 1er juin 1959. C'est le président Habib
Bourguiba qui lance véritablement ses activités le 10 octobre 1959.
Après dix ans de croissance de son activité et son importante participation dans le
développement économique du pays, au travers de l'ouverture de ses financements aux
différents secteurs de l'économie, comme, l'immobilier, l'agroalimentaire et les sociétés
de services, Cette croissance étonnante a provoqué le changement de sa dénomination
en Banque Nationale de Tunisie (BNT).
La restructuration le 24 juin 1989 de la BNT et sa fusion avec la Banque Nationale de

Développement Agricole BNDA, redonnent à la banque sa dénomination initiale BNA
et unifient à nouveau les structures d'octroi du crédit agricole.
Cette fusion constitue le début du processus de restructuration du système bancaire

tunisien. [1]
HISTORIQUE :
 1959, LA CRÉATION DE LA BANQUE NATIONALE AGRICOLE
 1969, LA CONVERSION EN BANQUE UNIVERSELLE
 1989, FUSION PAR ABSORPTION DE LA BNDA
5
Historique de la BNA
Figure 1: Historique de la BNA
1.2 Présentation de la banque « BNA »
La Banque nationale agricole (‫( )البنك الوطني الفالحي‬BNA) a le statut de Société

Anonyme, au capital de cent soixante millions de dinars.
Son réseau s'étale sur 177 agences et 17 directions régionales couvrant tout le territoire
et réparties en cinq catégories selon l'importance de leur activité.
La BNA met également à la disposition de sa clientèle des box de change dans les
principaux ports et aéroports du pays.
La BNA est la première banque tunisienne spécialisée dans le financement agricole.

Aujourd’hui, la BNA est à la tête d’un groupe composé de 18 sociétés intervenant dans
plusieurs secteurs d’activité (Financier, Immobilier, Agricole et Sociétés de Service).
6
Une nouvelle organisation orientée client qui vise la refonte des processus clés de la
banque et la mise en place de nouveaux dispositifs de gestion de la relation client a été
mise en Aout 2017. Cette nouvelle structure est composée principalement par une
direction générale et 6 pôles (Figure 1) qui sont : [11]
 -pôle commerciale
 -Pôle opération et service client
 -Pôle risque
 -Pôle finance comptable et pilotage de la performance
 -Pôle ressource et support
 -Pôle organisation et système d'information
Figure 2: Organigramme de la BNA
1.3 Produit et services
La BNA offre des produits et des services diversifiés à ces clients [1]
 Des services à l'international
 le paiement international
7
 garanties international
 opération de change
 allocation des voyage d'affaire AVA
 Crédit et financement
 financement des entreprises
 financement des professionnels
 financement agricole
 Epargne et placement
 produit épargne
 produit placement
 Banque au quotidien
 compte en dinar
 compte en devise et en dinar convertible
 banque a distance
 carte bancaire
 affiliation PFE
 bancassurances
 money Gram
2. Description du cadre de travail
Notre travail est assimilé au sein du pôle d'organisation et système d'information,

dans la direction maîtrise d'ouvrage D. MOA sous la Direction Centrale Projet de
Transformation Systèmes d'Informations dans laquelle les missions suivantes sont
gérées : [12]
 Veiller à l'amélioration de la gouvernance IT de la banque.

 Mettre en place la stratégie de la transformation IT de la banque.
 Assurer l'évolution et la maintenance du système d'information de la banque tout
en veillant à la mise à jour du portefeuille des projets informatiques en prenant
en charge tous les besoins métiers émanant des différentes structures de la
banque.
 Définir et veiller à la mise en œuvre des règles de gouvernance des projets.
 Coordonner, diriger et piloter tous les projets informatique métiers, en tenant
compte de tous les aspects fonctionnels et technique, et de mise en place des
systèmes informatiques intégrés évolutifs en parfaite corrélation avec les
systèmes de gestion, d'organisation et des procédures de la banque.
8
 Veiller à l'élaboration des cahiers des charges qui en découlent, à l'analyse des
offres des prestataires et des fournisseurs et à la participation à l'élaboration de
contrats d'acquisition ou de maintenance conformément aux procédures en
vigueur.
 Veiller à la bonne exécution des travaux de migration et la fiabilisation des
données.
 Suivre l'avancement et la mise en place des travaux de développement ou
d'acquisition de solutions et rectifier les trajectoires le cas échéant (cout, délais).
 Veiller à la bonne coordination entre les différentes structures de la banque et la
direction MOA de manière à répondre parfaitement et fidèlement aux besoins
des utilisateurs
 Veiller à ce que les projets de développement ou d'acquisition de solutions
soient mis en production dans le respect des règles de cohérence informatique,
des délais impartis et des budgets alloués
 Veiller à l'alignement des moyens mis en œuvre par rapport au besoin de la
banque.
 Suivre les relations avec les prestataires externes (progiciels, développement
spécifiques, intégration de systèmes...)
3. Présentation du projet
La BNA propose de mettre en place un tableau de bord centralisé qui permet de

donner une vision globale concernant l’activité d’octroi de crédit de gestion de tous les
agences ce qui permet aux décideurs de prendre des décisions stratégiques et tactiques.
Pour ce faire, nous avons analysé les dossiers des crédits pour les années
2016_2017, les données collectées couvrent le processus d'octroi de crédit dés la
demande du client déposée à l'agence jusqu'à la réalisation du crédit. Au sein de la BNA
on distingue quatre types de crédits : [13]
 Crédits professionnels,
 Crédits pour les particuliers,
 Crédits agricoles,
 Crédit pour les entreprises.
9
Les crédits pour les entreprises (crédit de gestion) concernent :
 Crédit à l'exportation,
 Ligne de change,
 Escompte commerciale,
 Crédits saisonniers,
 Crédit de financement,
 Autre crédit d'exploitation courante.
Le traitement des dossiers des crédits passe par six phases qui sont :
 La gestion de la demande,
 La décision,
 La mise en place,
 Le déblocage,
 Le recouvrement,
 Le transfert à contentieux.
3.1 Problématique
Chaque jour, une centaine de demandes de dossiers de crédits et des dossiers des
garanties sont déposées dans les agences de la BNA et transmis aux chargés des dossiers
de crédits dans les différents centres de décisions pour traitement.
Ce processus émet beaucoup de temps dans la transmission des dossiers entre les
différents intervenants et engendre des délais de traitement très longs et une réponse
tardive vis-à-vis de la clientèle.
Le facteur temps est un facteur très important dans le secteur bancaire, le but est
donc d'analyser les données émanant des traitements des dossiers de crédits de gestion
et d’identifier les tâches dans lesquelles on remarque des retards afin d’améliorer les
délais, agir à temps, identifier les insuffisances au niveau du système d'information de la
banque, aider à prendre des décisions stratégiques.
3.2 Objectifs
La BNA propose de mettre en place une application BI qui permet de donner une
vision détaillée concernant les dossiers de crédits et les dossiers de garanties dans ses
différents phases de traitement afin de contrôler les périodes de traitement nécessaire
10
pour chaque phase ce qui permet aux décideurs de prendre des décisions stratégiques et
tactiques.
Le travail consiste à réaliser une application BI qui facilite les tâches d’analyse et
de pilotage aux décideurs.
L’application décrite ci-dessus doit répondre aux objectifs suivants :
 Modéliser un entrepôt de données pour les données de gestion des dossiers de

crédits
 Assurer une analyse détaillée des données.
 Avoir une vue globale sur toutes les données et possibilité de générer des
rapports automatiques selon le besoin de l’utilisateur.
 Assurer la mise à jour annuelle et planifiée de l’entrepôt de données avec lequel
le tableau de bord va communiquer.
4. Méthodologie de travail
4.1 Comparaison des methodologies de travail
Méthodologie Description Points forts Points faibles
Cascade  Les phases se  Distingue  Non itératif

déroulent d’une clairement les  Pas de modèles
manière phases du projet pour les
séquentielle documents.
RUP (Rational  Le RUP est à la fois  Itératif  Vision non

Unified une méthodologie et  évidente ni
Propose des
un outil prêt à immédiate
Process) modèles de
l’emploi ; documents, et des  Très axé processus
 Cible des projets de canevas pour des  Coût de
plus de 10 projets types. personnalisation
personnes.  une évolution souvent élevé
n’impacte qu’une  Assez flou dans sa
itération et non mise en œuvre
forcément tout le
logiciel.
Scrum  Se base sur des  Entièrement  Peu, voire pas, de
11
itérations dites développé et testé documentation

spirales de pour de courtes écrite.
développement itérations.  Violation de
 Simplicité des responsabilité.
processus
 L'équipe ne se prête
 Règles définies pas au SCRUM
clairement
 Augmentation de
productivité
 Organisation
personnelle
 Chaque équipe a
son lot de
responsabilité
 Amélioration de la
communication
2TUP (Two  Propose un cycle de  Itératif  Ne propose pas des

Truck Unified développement en documents types.
 Définit les profils
Y
Process) des intervenants, les  Plutôt superficiel
 Cible des projets de plannings, les sur les phases
toutes tailles. prototypes. situées en amont et
en aval du
 S’articule autour de  Consacre une large
développement.
l’architecture. place à la
technologie et à la
gestion des risques.
Tableau 1: Tableau comparatif des différentes méthodologies de Travail
4.2 Choix de la méthodologie de travail
Suite à l’étude et à la comparaison des principaux processus de développement

et afin de contrôler les risques et de mener à bon terme notre projet vu sa complexité,
nous avons opté pour le processus 2TUP qui signifie « 2 Track Unified Process ».
Notre projet est basé sur un processus de développement bien défini qui va de la
détermination des besoins fonctionnels attendus du système jusqu’à la conception et le
codage final. Ce processus se base lui-même sur le Processus Unifié (Unified Process)
qui est devenu un standard général réunissant les meilleures pratiques de
12
développement. Cette méthode ne se base aucunement sur un processus linéaire mais

bien, sur un développement itératif et incrémental.
Le Processus Unifié (PU ou UP en anglais pourUnified Process) est une méthode

de développement logiciel construite sur UML ; elle est itérative et incrémentale,
centrée sur l’architecture, conduite par les cas d’utilisation et pilotée par les risques.
Itérative et incrémentale : la méthode est itérative dans le sens où elle propose

de faire des itérations lors de ses différentes phases, ceci garantit que le modèle
construit à chaque phase ou étape soit affiné et amélioré. Chaque itération peut servir
aussi à ajouter de nouveaux incréments.
Conduite par les cas d’utilisation : elle est orientée utilisateur pour répondre aux
besoins de celui-ci.
Centrée sur l’architecture : les modèles définit tout au long du processus de

développement vont contribuer à établir une architecture cohérente et solide.
Pilotée par les risques : en définissant des priorités pour chaque fonctionnalité,
on peut minimiser les risques d’échec du projet
2TUP c’est un processus qui répond aux caractéristiques du Processus Unifié. Il

apporte une réponse aux contraintes de changement continuel imposées aux systèmes
d’information de l’entreprise. En ce sens, il renforce le contrôle sur les capacités
d’évolution et de correction de tels systèmes. «2 Track» signifient littéralement que le
processus suit deux branches. Il s’agit des « branche fonctionnels » et « branches
technique », qui correspondent aux deux axes de changement imposés au système
d’information, Comme la montre la figure suivante.
13
Figure 3: Méthodologie 2TUP [2]

La branche gauche (branche fonctionnelle) : capitalise la connaissance du
métier de l’entreprise. Elle constitue généralement un investissement pour le moyen et
le long terme.
Les fonctions du système d’information sont en effet indépendantes des technologies

utilisées. Cette branche comporte les étapes suivantes :
 La capture et l'analyse des besoins fonctionnels, qui produit un modèle des

besoins focalisé sur le métier des utilisateurs.
 La capture des besoins non fonctionnels.
La branche droite (branche technique) : capitalise un savoir-faire technique.

Elle constitue un investissement pour le court et moyen terme. Les techniques
développées pour le système peuvent l’être en effet indépendamment des fonctions à
réaliser.
Cette branche comporte les étapes suivantes :
 La capture des besoins techniques.

 La conception générique.
14
La branche du milieu (branche réalisation) : à l’issue des évolutions du modèle

fonctionnel et de l’architecture technique, la réalisation du système consiste à fusionner
les résultats des 2 branches. Cette fusion conduit à l’obtention d’un processus en forme
de Y.
 Cette branche comporte les étapes suivantes :

 La conception préliminaire.
 La conception détaillée.
 Le codage.
 L’intégration
5. Planification du projet
L’initiation de tout projet nécessite une phase de planification. Celle-ci permet de

définir les tâches à réaliser, maîtriser les risques et rendre compte de l’état
d’avancement du projet.
« Planifier optimise ainsi les chances de réussite d'un projet en améliorant la

productivité grâce à une meilleure maîtrise de la qualité.» [Soler, 2001]
Pour garantir le bon déroulement du projet, tout en respectant les délais, nous
avons élaboré une planification globale de conduite du projet. Le diagramme de Gantt
suivant décrit cette planification ainsi que l’ordonnancement prévu des phases du projet
de mise en place d’une application BI d'analyses des dossiers de crédits.
Figure 4: Diagramme de Gantt
15
Conclusion
Dans ce présent chapitre, nous avons présenté l’organisme d'accueil, le contexte
général du projet et la problématique liée. De même, nous avons présenté la
méthodologie de travail ainsi la panification du projet. A la suite de ce chapitre, qui
contient une présentation du cadre de travail on passe à donner une description globale
du système d'information de la BNA et les solutions proposées.
16
Chapitre 2 : Etat de l'art
Chapitre 2 :
Etat de l'art
17
Introduction
Ce chapitre présente une vue générale de l'état de l’art de la littérature de
l'informatique décisionnelle dans l'entreprise dès la modélisation, l'analyse et la
visualisation des données. L'objet de ce chapitre est de définir les concepts
fondamentaux relatifs aux systèmes décisionnels.
1. La business intelligence au service de l’entreprise
Il est convenu de fixer la naissance du business intelligence à 1958. Et d’en

accorder la paternité à Hans Peter Luhn, un analyste d’IBM. Il définit la BI comme « la
capacité à appréhender les interrelations entre les faits pour les présenter de façon à
orienter l'action vers un but désiré » [Luhn, 1958].
L’informatique décisionnelle, business intelligence BI ou décision support

system (DSS) est l'informatique à l'usage des décideurs et des dirigeants d'entreprises.
Elle désigne les moyens, les outils et les méthodes qui transforment la donnée en
connaissance et qui permettent de collecter, consolider, modéliser et restituer
les données, d'une entreprise (comme le montre la figure 6). Les systèmes BI sont utilisé
en vue d'offrir une aide à la décision et de permettre à un décideur d’avoir une vue
d’ensemble de l’activité traitée de l'entreprise leurs permettant de définir et soutenir
leurs stratégies d’affaires :
 D'acquérir un avantage concurrentiel

 D’améliorer la performance de l'entreprise
 De répondre plus rapidement aux changements
 D’augmenter la rentabilité
 D’une façon générale la création de valeur ajoutée de l’entreprise.
18
Figure 5 : Le système de l'informatique décisionnel au service de l'entreprise [2]
Ce type d’application repose sur une architecture commune dont les bases
théoriques viennent principalement de R. Kimball, B. Inmon et D. Linstedt.
Les données opérationnelles sont extraites périodiquement de sources

hétérogènes: fichiers plats, fichiers Excel, base de données (DB2, Oracle, SQL Server,
etc.), service web, données massives et stockées dans un entrepôt de données.
Dans le monde de l’entreprise actuel, les données sont :
 Quantifiées en Giga et Téra chaque jour

 De formats hétérogènes
 Hébergées dans plusieurs bases opérationnelles différentes.
De manière assez intuitive, les enjeux du processus décisionnels se sont donc articulés
autour de :
 La qualité de l’information et de la connaissance extraite de cette information.

 La fiabilité de cette connaissance.
 La quantité toujours grandissante de l’information à traiter.
 Le délai d’interprétation de l’information et le délai de la prise de décision.
Dans le passé, les solutions de BI pour les banques prenaient des années à
planifier et à déployer, et elles ne s'adaptaient pas facilement à l'évolution des réalités et
des technologies. De plus, du fait de la complexité de ces outils, le personnel
informatique devait effectuer des analyses sophistiquées pour les clients.
19
L'objet de ce chapitre est de définir les concepts fondamentaux relatifs aux systèmes
décisionnels au service de l'entreprise
1.1. Modélisation
Les outils BI d'aujourd'hui sont beaucoup plus adaptables, avec du matériel, des
logiciels, des appareils et des services qui recueillent des données structurées et non
structurées à partir de sources de données hétérogènes dans divers formats. Les outils
sont suffisamment simples pour que les employés de l'entreprise puissent les utiliser,
quel que soit leur niveau de compétence informatique. Ils traitent beaucoup plus de
données en temps réel, et ils sont disponibles dans des formats conviviaux sur différents
d'outils. Les outils BI modernes sont capables de traiter plusieurs types d’analyse :
 L'analyse de contenu : appliquent la BI au contenu non structuré, y compris la

vidéo, les commentaires sur les médias sociaux et les courriels, de sorte qu'il
peut être utilisé avec des données structurées pour glaner ( Recueillir) des idées
pour les banques.
 L'analyse d'entreprise examine les modèles d'affaires passés, présents et futurs
afin de déterminer ce qui fonctionne et ce qui peut être modifié pour améliorer
l'efficacité et la rentabilité. [Gartner survey 2014].
1.1.1 Les entrepôts de données au service de la BI

Dans toute entreprise ou organisation, la fonction la plus importante de
l'administrateur réside dans la prise de décision. Pour ce faire, il doit choisir,
consciemment, entre plusieurs solutions afin d’atteindre un objectif. Le processus
décisionnel se décompose en 5 étapes :
1- Définir le problème à résoudre / objectif à atteindre

2- Rassembler les faits et données
3- Evaluer et interpréter
4- Etablir plusieurs solutions
5- Choisir une solution / décider
L'étape 2 se suit par la construction d'un entrepôt de données supportant OLAP (Online
Analytical Processing) qui permet aux utilisateurs chevronnées (bien expérimentée)
20
d’analyser les opérations via des accès aux données stockées. Cela permet aux
responsables métier d’améliorer les stratégies d’entreprise ainsi que les prises de
décision en interrogeant l’entrepôt de données pour examiner les processus métier, les
performances et les tendances.
Voici une liste de tâches pouvant être effectuées par un entrepôt de données : [4]
 Suivre, gérer et améliorer les performances de l’entreprise ;

 Modifier une campagne marketing ;
 Optimiser la logistique et les opérations ;
 Améliorer l’efficacité en matière de gestion de produits et de développement ;
 Interroger, agréger et accéder à des informations disparates et multi-sources ;
 Améliorer la relation clients ;
 Prévoir les opportunités de croissance ;
 Nettoyer et améliorer la qualité des données de l’entreprise
1.1.2 Architecture du SID
Figure 6 : Ensemble des composants intervenant dans un système décisionnel [2]

Nous trouvons le processus ETL entre les sources de données et l’entrepôt. Ce
processus est responsable de l’identification des données dans les diverses sources
internes et externes, de l’extraction de l’information qui nous intéresse et de la
21
préparation et de la transformation (nettoyage, filtrage...) des données. A l’intérieur de

l’entrepôt, nous trouvons le processus de stockage, il est responsable de structurer les
données par rapport à leur niveau de granularité (agrégats). Finalement, le quatrième
processus correspond à la restitution qui se place entre l’entrepôt et les différents outils
pour arriver à l’analyse des données, pour les différents utilisateurs de l’entreprise.
Cette fonction de restitution est assurée par des outils décisionnels variés comme des
outils de Reporting, des outils de tableau de bord, ou des outils de fouille de données.
1.1.3. L'ETL (extract transform load)

Assure la connexion du système à une ou plusieurs sources de données,
l'extraction, la transformation et le chargement dans l'entrepôt. Il s'agit d'un outil
fondamental de l'entrepôt de données, base du système d'information d'une solution BI .
Les sources de données a extraire sont hétérogènes tant sur le plan technique que
logique. Les données sont stockées dans des systèmes et sous des formats variés. Par
ailleurs la plupart des données a collecter doivent être vérifiées afin d'assurer la fiabilité
des informations recueillies.
Les principales fonctionnalités d'un ETL :
Extract (Extraire) : Assurer la connexion a la majorité des systèmes de

stockage de données afin de pouvoir identifier, sélectionner et récupérer les
données. Il doit aussi pouvoir assurer un mécanisme de synchronisation pour la
réactualisation.
Transform (Transformer) : Les données a récupérer ne sont pas forcément

dans l'état dans lequel elles seront stockées. Elles doivent être vérifiées,
reformatées, nettoyées afin d'éliminer les valeurs incohérentes ainsi que les
doublons. Il s'agit donc des opérations permettant de consolider et d'assurer la
validité des données.
Load (Charger) : Stocker les données dans le data warehouse afin qu'elles
puissent être utilisable par les autres outils du système BI.
22
Figure 7: Schéma de fonctionnement d’un ETL. [2]
1.1.4 Datawarehouse (Entrepôt de données)
a) Présentation d'un datawarehouse

Un datawarehouse est une base de données regroupant l'ensemble des données
fonctionnelles d'une entreprise. Ces données sont :
Orientées sujet : Les données dans l’entrepôt sont réparties par sujet et non par
application.
Historiée : La prise en compte de l’évolution des données est essentielle pour la
prise de décision.
Non volatiles : Le rafraîchissement de l’entrepôt consiste uniquement à rajouter

de nouvelles données sans perdre ou modifier celles qui existent déjà.
Intégrées : Les données du DWH sont cohérentes.
On distingue généralement quatre types d’entrepôt de données :
Les traditionnels systèmes de gestion de bases de données (SGBD) : La plupart

sont relationnels, mais pas tous. IBM, Microsoft, Oracle et SAP forment le gros des
fournisseurs de technologies.
Les SGDB analytiques spécialisés : Les entrepôts de données de cette catégorie

ne sont pas des SGDB traditionnels. Ils ont été « augmentés » pour supporter les
23
workloads spécifiques de l’entrepôt de donnés. On retrouve par exemple les bases en

colonne, comme celles de HP et de SAP.
Les Appliance : Elles sont conçues pour fournir des services d’entrepôt de
données prêts à l’emploi. Le serveur est livré avec une quantité de mémoire et une
capacité de stockage adaptées. Teradata, IBM et Oracle en proposent à leur catalogue.
Les entrepôts de données dans le Cloud : Le SGBD n’est pas installé sur site
mais est accessible via Internet. Une offre Cloud fournit donc un entrepôt de données
as-a-service, sans avoir de SGBD ni de hardware sur le site du client. Microsoft,
Amazon et IBM sont parmi les spécialistes de ce domaine.
b) Structure des données d’un Datawarehouse
Les données rassemblées dans un Entrepôt de données sont issues des applications
transactionnelles (systèmes opérationnels) pour la plupart et de bases des données
externes, après avoir extraites par des outils spécialisés (ETL). Trois catégories
principales présentes dans un entrepôt sont à distinguer : les données détaillées, les
données agrégées et les métas données
Données détaillées : Ce sont l’ensemble des données quotidiennes et plus

couramment utilisées. Elles représentent le « socle » de l’entrepôt de données. Ces
données sont issues directement des systèmes transactionnels de l’entreprise et elles
sont généralement stockées sur le disque pour avoir un accès rapide. Il est à noter que
malgré les grandes capacités de stockage, toutes les données de l’entreprise n’ont pas à
être stockées dans l’entrepôt. Seules les données susceptibles d’avoir un sens pour le
processus d’aide à la décision doivent être incorporées. Ce choix des données à
conserver implique l’anticipation des usages décisionnels dès la conception de
l’entrepôt de données.
Exemple des données détaillées : le détail des ventes de l’année en cours, dans les
différents magasins.
Données agrégées ou résumées : Ce sont « le cœur de l’entrepôt de données ».

Elles sont moins détaillées et elles permettent de réduire le volume des données à
stocker. Le type de données, en fonction de leur niveau de détail, permet de les classifier
comme des données légèrement ou fortement résumées.
24
Exemple, les ventes mensuelles par magasin des dix dernières années sont des données
faiblement résumées.
Données fortement agrégées : Ce sont des données agrégées à partir des données
détaillées, mais à un niveau d’agrégation plus élevé que les données agrégées.
Exemple, les ventes semestrielles, par région, des dix dernières années sont fortement
agrégées.
Les métadonnées « Données sur les données » : Ce sont des données

essentielles pour parvenir à une exploitation efficace du contenu d’un entrepôt. Elles
représentent des informations nécessaires à l’accès et l’exploitation des données dans
l’entrepôt comme :
 Le modèle de données.
 La structure des données telle qu’elle est vue par les développeurs.
 La structure des données, telle qu’elle est vue par les utilisateurs.
 Les sources des données.
 Les transformations nécessaires.
 Suivi des alimentations.
1.1.5 Magasins de données (Datamarts)

Les Data Warehouses étant, en général, très volumineux et très complexes à
concevoir. On peut les diviser par fonction (pour les ventes, pour les commandes, pour
les ressources humaines) ou par sous-ensemble organisationnel (par succursale).
Le datamart est un ensemble de données ciblées, organisées, regroupées et

agrégées pour répondre à un besoin spécifique à un métier ou un domaine donné.
De façon plus technique, le DataMart peut être considéré de deux manières différentes,
attribuées aux deux principaux théoriciens de l’informatique décisionnelle, Bill
Inmon et Ralph Kimball :
 Définition d'Inmon : Le DataMart est issu d’un flux de données provenant

du DataWarehouse. Contrairement à ce dernier qui présente le détail des
25
données pour toute l’entreprise, il a vocation à présenter la donnée de manière

spécialisée, agrégée et regroupée fonctionnellement.
 Définition de Kimball : Le DataMart est un sous-ensemble du DataWarehouse,
constitué de tables au niveau détail et à des niveaux plus agrégés, permettant de
restituer tout le spectre d’une activité métier. L’ensemble des DataMarts de
l’entreprise constitue le DataWarehouse.
1.1.6 Modélisation multidimensionnelle

La modélisation dimensionnelle structure les données d'une façon très différente
de la structure en 3FN (3ème forme normale) fréquemment utilisée par les
modélisateurs des systèmes OLTP. La modélisation dimensionnelle produit ce qu'on
appelle le Modèle dimensionnel. [23]
a) Modèle en étoile
Ce modèle est initié par Ralph Kimball, est représenté par une table de faits
centrale autour de laquelle gravitent les dimensions permettant d’analyser les faits qui y
sont contenus. Chaque dimension est décrite par une seule table dont les attributs
peuvent représenter toutes les granularités possibles.
b) Modèle en flocon de neige
Ce modèle est initié par Inmon, la table de faits est également au cœur du modèle.
Là encore, les dimensions gravitent autour de la table centrale mais la différence réside
dans une plus grande hiérarchisation de ces dimensions.
Les flocons et les étoiles peuvent être vus comme une manière de diviser les entrepôts
de données et les magasins de données. On peut les voir comme l'atome de
l'informatique décisionnelle : le plus petit élément avec lequel on peut faire des analyses
et avec lequel on peut faire des magasins de données qui, mis ensemble, forment un
entrepôt de données.
c) Modèle en constellation
Ce modèle est un ensemble de schémas qui fusionne plusieurs modèles en étoiles ou en

flocon qui utilisent des dimensions communes.
26
Un modèle en constellation comprend plusieurs tables de faits et des tables de

dimensions communes ou non à cette table de faits.
d) La table fait
La table de fait contient l’ensemble des mesures correspondant aux informations de

l’activité à analyser. Mais rappelons que certaines tables de faits peuvent contenir aucun
attribut et représentent que des liaisons entre tables dimensionnelles.
Le fait modélise le sujet de l'analyse. Un fait est formé de mesures correspondant

aux informations de l'activité analysée. La table comporte des clés étrangères, qui ne
sont autres que les clés primaires des tables de dimension.
e) La table dimension
Une dimension donne le contexte de fait, elle se compose de paramètres

correspondant aux informations faisant varier les mesures du fait. Les dimensions
servent à enregistrer les valeurs pour lesquelles sont analysées les mesures de l'activité.
Une dimension est généralement formée de paramètres (ou attributs) textuels et discrets.
Les paramètres textuels sont utilisés pour restreindre la portée des requêtes afin de
limiter la taille des réponses.
Table de fait Table de dimension
Structure Peu de colonnes beaucoup de Peu de lignes beaucoup de

lignes colonnes
Données Mesurable, généralement Descriptives généralement

numérique textuelles
Référentiel Plusieurs clés étrangères Une clé primaire
Valeur Prend de nombreuses valeurs Plus ou moins constantes
Manipulatio Participe à des calculs Participe à des contraintes

n
27
Signification Valeurs de mesure Descriptive
Rôle Assure les relations entre les Assure l’interface homme / entrepôt
dimensions
de données
Tableau 2: Tableau comparatif entre les tables de faits et les tables de dimensions
f) Les mesures
Les mesures d'un fait sont numériques et généralement valorisées de manière

continue et structuré par des dimensions.
Les mesures sont numériques pour permettre de résumer un grand nombre

d'enregistrements en quelques enregistrements. Elles sont valorisées de façon continue,
car il est important de ne pas valoriser le fait avec des valeurs nulles. [24]
g) Les attributs
Dans le cadre de la modélisation dimensionnelle, un attribut est un champ qui

permet de décrire une table de dimension. Plus généralement, tous les éléments d'une
table de dimension sont des attributs à l'exception de la clé primaire.
1.2 Analyse
1.2.1 OLAP (On-Line-Analytical-Processing)

L'acronyme OLAP désigne un mécanisme qui permet d'analyser des données
selon différents niveaux de détails (année, trimestre, mois, pays, région, département...)
et dimensions (le temps, le client, le produit, la localisation géographique...).
R. Kimball définit le concept « OLAP » comme « Activité globale de requêtage

et de présentation de données textuelles et numériques contenues dans l’entrepôt de
données ; Style d’interrogation spécifiquement dimensionnel » [Kimball, 2005].
Lors du processus OLAP, les données sont généralement analysées en partant d'un
faible niveau de détail vers des données plus détaillées
OLAP se décline en quatre architectures qui permettent de s'adapter à différentes

problématiques de performance et de stockage de données :
28
a) Architecture des serveurs OLAP
 {M-OLAP : Multidimensional OLAP

 {R-OLAP : Relational OLAP
 {H-OLAP: Hybrid OLAP (mix entre MOLAP et ROLAP)
 {S-OLAP: Spatial OLA or DOLAP (Dynamic OLAP)
b) La navigation dans les données

 Tailler (slicing) : autorise l'extraction d'une tranche, d'un bloc
d'informations. Il s'agit d'une sélection classique
 Le Dicing peut être vu comme étant une extraction d’un sous cube.
Figure 8 : Opérateurs Slicing [2]
 Pivoter (rotate ou swap) : Rotation des axes du cube. Permet d'interchanger

deux dimensions pour fournir une vue alternative des données.
29
Figure 9: Opérateur Rotate [2]
 Remonter (roll-up) : synthétise les informations en fonction d'une

dimension. Par exemple, sur la dimension géographique, il s'agirait de passer
du niveau département au niveau région.
 Forer (drill-down) : il s'agit de l'inverse du (drill-up), on « zoome » sur une
des dimensions (de la région au département).
Figure 10 : Opérateurs Roll-Up et Drill-Down [2]
 Drill-in/Merge : réduire le cube d’une ou plusieurs dimensions.
 Drill-out/Split : ajouter une ou plusieurs dimensions.
30
c) Langage de requête
MDX (MultiDimensional eXpressions) est un langage de requête utilisé pour

manipuler les données d'une base OLAP. MDX est similaire au langage SQL pour les
bases de données relationnelles.
Le langage des expressions multidimensionnelles possède une syntaxe appropriée

à l'interrogation et manipulation des données multidimensionnelles mémorisées dans
un cube OLAP
1.3Visualisation
1.3.1 Le reporting
Le reporting est probablement l'application la plus utilisée de l’informatique

décisionnelle, cela permet aux gestionnaires :
 De sélectionner des données relatives à telle période, telle production, tel

secteur de clientèle, etc.
 De trier, regrouper ou répartir ces données selon les critères de leur choix
 De réaliser divers calculs (totaux, moyennes, écarts, comparatif d'une
période à l'autre…)
 De présenter les résultats d’une manière synthétique ou détaillée, le plus
souvent graphique selon leurs besoins ou les attentes des dirigeants de
l’entreprise
Le reporting, quant à lui, est un ensemble d'indicateurs de résultat, construit a

posteriori, de façon périodique, afin d'informer la hiérarchie des performances de l'unité.
1.3.2 Tableau de bord (Dashboard)

Le tableau de bord est un outil qui permettant de quantifier l'activité de
l'entreprise, d'un service, d'une personne. A partir de données provenant d'une ou
plusieurs sources. Le tableau de bord fournit une vision synthétique du passé, du présent
et par conséquent du futur de l'entreprise, d'un service, d'une personne. Ces outils
s’adressent aux cadres dirigeants, Directeur général, Directeur financier, Directeur RH,
Directeur commercial, mais aussi à tous les managers de toute entreprise, tous secteurs
31
confondus, car ces outils s’adaptent à toutes les activités. Cet outil contribue à réduire
l'incertitude et facilite la prise de risque inhérente à toutes décisions.
Le reporting est complété par le tableau de bord, qui lui est un outil
d’évaluation de l’organisation d'une entreprise ou d’une institution constituée de
plusieurs indicateurs de sa performance à des moments donnés ou sur des périodes
données. Il permet de répondre aux objectifs de management suivants :
 Evaluer la performance
 Réaliser un diagnostic de la situation
 Communiquer et informer
En bref, Le tableau de bord est un outil de pilotage, le reporting est un outil de

contrôle. Les deux fonctionnent ensemble et se complètent.
1.3.3 Fouille de données (Datamining)

Le Datamining ou fouille de données est un ensemble de méthodes qui consistent
à extraire un savoir ou une connaissance, à partir d'une base de données. Contrairement
aux méthodes classiques, le Datamining est plus adapté à des données à grand volume et
les informations récoltées doivent aider à prendre des décisions. Le datamining permet
alors d’exploiter ces données au profit de l'activité de l'entreprise et il permet aussi
d’augmenter le retour sur investissement des systèmes d’information.
Le Datamining est une suite ordonnée d'opérations qui permettent d'aboutir par la
suite à un résultat. Pour cela il faut :
 Comprendre le métier : définir clairement les objectifs du projet et les

contraintes que l’on peut rencontrer.
 Comprendre les données : recueillir, évaluer et sélectionner les données.
 Préparation des données : préparer à partir des données brutes celles qui
seront utilisés.
 Modélisation : sélectionner et paramétrer les techniques de modélisation à
utiliser.
 Études des résultats : évaluer la qualité et la pertinence des résultats, en
fonction de l'objectif défini.
32
 Prise de décision
Coclusion
Le concept « Data Warehouse » est apparu comme une réponse à des besoins
grandissants dans le domaine décisionnel pour toute entreprise soucieuse du suivi de ces
performances.
Nous avons consacré ce chapitre à définir les notions et les concepts de base du système
décisionnel.
Au cours des chapitres suivants, nous allons utiliser les concepts présentés dans l’état de
l’art, et cela afin de mettre en œuvre notre système.
33
Chapitre
3 : Etude
de
l'existant
et
spécificati
on des
besoins
34
Chapitre 3 : Etude de l'existant et spécification des besoins
Introduction
Dans ce chapitre nous présentons une description du système

d'information de la BNA qui permet de déterminer les critiques de
l'existant. Ensuite nous focalisons sur une analyse de la branche
fonctionnelle, ou nous allons définir les besoins fonctionnels et non
fonctionnels et la deuxième branche de la méthodologie à savoir la
branche technique, d’où seront présentés les outils décisionnels que nous
allons utiliser.
1. Etude de l’existant
A fin de bien comprendre le besoin de notre projet, on a besoin

d’une étude détaillée et approfondie de l’existant.
1.1 Description du système d'information de la BNA
Le système d'information de la BNA actuel se compose d'un noyau comptable

Carthago Compta et de plusieurs applications métiers tels que SMILE, SAEB, SAGA,
E-BANK, SAFEWATCH, CED, STARFIND,etc.
 (SMILE) : Système Multifonction Intelligible, Léger et Evolutif
Le projet SMILE s’inscrit dans le cadre de dotation de la BNA d’un nouveau système
agence, intégrant la totalité des activités exercées et permettant une meilleure
qualité de service au client, à travers une solution garantissant l’unicité de
l’information quel que soit le canal de distribution (WEB, GAB, guichets, etc.).
SMILE offre une vision globale permettant une meilleure prise de décision et améliore
la qualité de service vis à vis du client en éliminant les lourdeurs dans les
traitements.
35
Figure 11: Interface de l'application métier SMILE

 (SAEB) : Système Automatisé des Engagements Bancaires
SMILE est une application métier qui assure la gestion de tous les types de prêts.
Le système englobe différents modules :
 Crédits bruts pour net,

 Engagement par signature,
 Crédits d’investissement,
 Crédits de gestion : CME, Escompte, facilité de caisse et dépassement
passagers.
Figure 12: Interface SAEB
36
 (SAGA) est une application métier qui centralise la gestion de toutes les
garanties reçues en couverture d’engagements donnés par la banque.
A l’heure actuelle la manipulation des informations dans le système

est complexe et gourmande en termes de temps.
1.2 Critique de l’existant
Nous avons remarqué l’utilisation d’une panoplie d’outils

informatiques tels que SMILE, SAEB, SAGA, etc. de technologies
différentes tels que web et forms gérant des bases de données différentes.
Le nombre important de ces outils augmente les scilos (Figure8) entre les
différents services. En effet la base des données du système d'information
est large et hétérogène. Cette organisation engendre l'absence d'une
vision globale sur les objectifs de la banque et que chaque système offre
une visibilité sur son métier.
Dans cet organisme les outils sont multiples mais le système

d'information actuel manque un outil d'analyse du processus d'octroi des
crédits
Afin de résoudre cette problématique, nous avons proposé cette solution.
Figure 13: système en scilos : montre l'hétérogénéité des données
37
1.3 Solution proposée
Notre solution consiste à développer une application BI qui :
 Modéliser un entrepôt des données qui stocke les données importées à

partir de différentes sources après l’application des transformations
nécessaires.
 Analyse les dossiers de crédits et les dossiers de garanties y afférentes
dans ses différentes étapes de traitement,
 Génère des rapports sous forme de tableau de bord software.
2. Spécification des besoins
La spécification des besoins décrit sans ambigüité l’application à

développer. Cette phase consiste à décrire les fonctionnalités requises au
système pour un utilisateur et à préciser les risques les plus critiques : à
savoir les acteurs et leurs rôles, l'étude de la branche fonctionnelle et
technique.
2.1 Identification des acteurs
Notre application réagit avec l'acteur suivant :
 Utilisateur (Décideur) : le décideur est la personne physique ou morale qui est

appelée à prendre une décision concernant le financement d’un projet ou
l’autorisation de procéder à sa réalisation. Le décideur dans un projet BI est la
personne qui est chargée de lire, évaluer et estimer le tableau de bord afin de
prendre les bonnes décisions.
2.2. Branche fonctionnelle
Cette branche est consacrée à l’étude des besoins fonctionnels et

non fonctionnels de notre application
2.2.1 Les besoins fonctionnels

La solution s’agit de mettre en place une application BI qui permet
d'analyser le processus d'octroi des crédits : Cette application basée sur
38
un entrepôt de données qui stocke de manière cohérente les données

relatives aux dossiers de crédits et les dossiers de garanties.
Par la suite, un tableau de bord se connecte à l’entrepôt de données

et génère d’une façon automatique et selon différents axes des analyses,
des rapports qui résument l’état des dossiers.
Cette solution permet aux décideurs d’avoir une vue globale sur le
déroulement du processus d'octroi de crédits via une interface unique
pour pouvoir finalement gagner en productivité en facilitant l’accès aux
informations.
Nous avons détecté les axes d’analyse suivants : (Les crédits, les garanties, les agences,
les directions régionales, le temps.)
Ci-dessous nous illustrons les besoins fonctionnels de notre application :
 Déterminer le pourcentage des crédits octroyés par :
 Période (jour, mois, année, semestre, trimestre)
 Instruction (agence, direction de décision)
 Espace et par période,
 Produit et par période.
 Déterminer le nombre des crédits couvert par garanties par :
 Espace (agence, direction de décision)
 Période (mois, année)
 Produit
 Par agence et par période
 Nature garantie
 Rang
 Par nature pour chaque garantie par rang
39
 Les durées moyenne de traitement des dossiers des crédits par
 Espace (agence, direction de décision)
 Produit
 Par nature garantie
 Le montant total des crédits couvert par garantie octroyés par
 Instruction (agence, direction de décision, zone géographique),
 Période (mois, années),
 Produit
 Déterminer la période optimale de traitement d'une demande
 Déterminer les natures des garanties les plus utilisés
 Déterminer l'agence la plus active
 Capture des Top Cinq agences.
 Déterminer la zone géographique la plus chargée
 Déterminer l'agence qui fait le plus grand nombre des retards en 2016 & 2017
2.2.2 Les besoins non fonctionnels

Outre que les besoins fonctionnels cités précédemment, pour bien
répondre aux exigences des utilisateurs, le système devra pouvoir assurer
les besoins non fonctionnels suivants :
 Capacité : La quantité totale des données recueillies au sein des bases de

données sélectionnées représente un volume très important. De plus le traitement
de celles-ci augmentera quelque peu ce volume initial. De ce fait, la capacité du
serveur doit être suffisante afin de pouvoir recueillir l'ensemble de ces données,
permettre l'exécution du programme et la sauvegarde des mises à jour au fil du
temps.
 Intégrité : À tous les niveaux de la mise en place de l'entrepôt de données,

différentes erreurs devront être traitées notamment celles-ci :
40
 Le traitement des mauvaises données lors de l'import de données à partir

des différentes bases.
 L'intégrité référentielle dans les tables de base de données.
 Qualité :
 Facilitation de l’accès aux données et de la diffusion de

l’information.
 Fiabilité et traçabilité des données.
 Interaction homme machine la plus intuitive possible.
 Performance : l'application doit réagir correctement face aux gros volumes de

données.
 Ergonomie et convivialité : La facilité d’apprentissage et d’utilisation de

l'application doit être suffisante pour les utilisateurs
 Exploitabilité : les ressources nécessaires à la bonne exploitation du système

doivent être à la mesure des capacités de l’entreprise.
 Sécurité : Le système doit être sécurisé : Besoins d’établissement des

connexions et d’établissement des connexions au bases des données.
 Fiabilité : Il faut garantir la qualité du contenu et la pertinence des informations.
 L’extensibilité : Le système doit permettre l’intégration de nouvelles

fonctionnalités.
Après avoir identifié les rôles des acteurs aussi bien que les besoins
du système. Nous pouvons passer à présent à la branche technique qui va
se charger de présenter les besoins techniques indispensables au
développement de notre projet.
2.3 Branche technique
Les besoins fonctionnels ayant été définis, nous passons maintenant

à savoir quels outils nous allons utiliser pour mettre en œuvre notre
application.
41
Nous devons faire des études comparatives pour choisir les outils les plus appropriés
pour développer notre application, la problématique de choix concernera : Les outils
ETL pour l’extraction, la transformation et chargement de l’entrepôt de données et les
outils de restitution des données.
2.3.1Etude comparative des ETLs

Il ya plusieurs outils ETL open source Donc, il nous a fallu
rechercher sur Internet les différents ETLs open sources disponibles.
Cette phase de recherche sur des sites internet (forums, sites officiels,
blogs, etc.) nous a permis de connaitre plus ces outils et ses
fonctionnalités, Donc nous allons comparer ces ETLs selon leurs
fonctionnalités.
Point fort Point faible
 Possède environ 180  Pas de planification de

composants. traitements intégrée.
PentahoDat  Référentiel disponible,  Interface pas toujours très
a possibilité de le gérer via claire.
Integration n’importe quel SGBD.

 Pas de gestion des contextes
 Interface ergonomique
 Installation très simple  Des fonctionnalités payantes.
 Très complet (environ 250  TOS est un grand
Talend composants java) et peu consommateur de mémoire.
Open moins en Perl.
Studio  Interface ergonomique.
 Le composant tMap très

puissant permet de faire
facilement de nombreux
42
traitements.
Tableau 3: Comparaison basée sur le critère des fonctionnalités
2.3.2 Etude comparative des outils de restitution

Les outils de restitution sont multiples Donc, il nous a fallu
rechercher sur Internet les différents outils de restitution Open Source
disponibles. Cette phase de recherche sur des sites internet (forums, sites
officiels, blogs, etc.) a permis de répertorier les outils de restitution
suivants : QlikView, Qliksens, Tableau [25] [26]
Avant de nous pencher sur le logiciel le mieux adapté pour notre

solution, nous examinons de plus près ce que chacun à offrir
Points forts Point faible
 Installation très simple  Difficile à apprendre et à

utiliser en tant que débiteur.
 Visualisation des données
 L’extrémité arrière n'est pas
 Collaboration sécurisée et en
aussi conviviale et intuitive que
temps réel
la partie frontale et nécessite
 Modèles des rapports parfois une assistance
avancés informatique pour la gestion des
 Interagir avec des données et la cartographie.
QlikView
applications dynamiques, des
tableaux de bord et des
analyses
 Connecteurs par défaut et
personnalisés
 Le calcul à la volée lors de
sélection
 Finesse graphique et
simplicité d'utilisation
 L’analyse guidée et la  Une connexion à QlikSense

modification par ajouts ou Enterprise ou à un compte Qlik
43
QlikSens modifications de graphique est obligatoire pour utiliser

QlikSens desktop
 Traiter des données à
l'échelle à des milliards de
lignes de données
 Liste des connecteurs de  Processus ETL obligatoire pour

données natifs extraire des données hors
système.
Tableau  Tableaux de bord mobiles
 Intégration des données
 Notifications de données
possible, mais avec une liste des
 Commentaires sur le tableau sources moins courte que celle
de bord de QlikView
Tableau 4: Tableau comparatif des outils de restitution
2.3.3 Bilan des études comparatives

Compte tenu des résultats de comparaison des 2 outils ETLs Open
Source : Talend Open Studio et Pentaho Data Integration et en prenant en
considération les fonctionnalités des deux outils, on conclut que : TOS
est le plus puissant parmi les ETLs Open source et le plus adapté au
contexte de notre projet.
Suite à la brève étude établie ci-dessus sur les point forts et faibles
de chacun des outils de restitution QlikView, QlikSens et Tableau. On
conclut que QlikView est l’outil de restitution le plus convenable pour
l’élaboration de notre tableau de bord.
Dans cette perspective nous avons choisi pour notre solution BI les
deux outils : Talend Open Studio pour le processus ETL et QlikView
pour la création, du tableau de bord.
Conclusion
Le concept « Data Warehouse » est apparu comme une réponse à

des besoins grandissants dans le domaine décisionnel...
44
Nous avons consacré ce chapitre à définir les notions et les

concepts de base du système décisionnel.
Au cours des chapitres suivants, nous allons utiliser les concepts

présentés précédemment, et cela afin de mettre en œuvre notre système.
45
Chapitre 4 :
Conception
46
Chapitre 4 : Conception
Introduction
Dans ce présent chapitre et afin de parvenir à bien identifier les différentes
conceptions que nous avons réalisé pour effectuer notre projet, nous présenterons une
première section qui met l’accent sur la conception de l'entrepôt des données, une
deuxième section qui présente la conception ETL et une troisième section pour la
conception du tableau de bord.
1. Conception de l’entrepôt des données
La modélisation constitue la phase la plus déterminante et fondamental dans le

déroulement du projet. La conception d’un modèle dimensionnel passe par quatre étapes
essentielles :
 Définition de l’activité à analyser

 Choix des dimensions
 Choix des mesures ou des indicateurs.
 Choix du modèle dimensionnel
1.1 Présentation de l’activité « l'octroi de crédit »
L'octroi de crédit demeure comme l'activité principale d'une banque.
Selon les normes (ISO 9000 :2005), un processus est un ensemble d'activité
corrélées qui transforme des éléments d'entrée en éléments de sorti. Pour une banque,
c'est un ensemble d'activités effectuées par le banquier, en vue de traiter une demande
de financement. [8]
Ce processus commence par la réception de la demande de crédit dans une

agence, si le dossier de la demande du client est valide alors le chef d'agence transmet le
dossier à la direction régionale pour l'analyser. Par la suite une décision est donner :
"décision validée" si le dossier est complet, ou "décision en instance" si le dossier doit
être envoyer à la direction centrale pour le ré analyser. Puis si la décision est validée
alors il y aura la mise en place de crédit et en fin le déblocage.
D'où on remarque que le processus dont on s'intéresse doit avoir quatre dates
importantes :
 1-date de demande de crédit
47
 2-date de validation au niveau de la direction régionale
 3-date de validation au niveau de la direction centrale
 4-date de mise en place
Les dates liées à ce processus se présentent comme des indicateurs d’une grande
signification par rapport à la performance de l'opération d'octroi de crédit. Ainsi, la
disponibilité de ces informations s’avère indispensable pour les décideurs de la banque.
La figure suivante montre le processus d'octroi de crédit au sein de la BNA d'une

manière simple.
Figure 14: Processus d'octroi des crédits
1. 2 Choix des dimensions
« Une table de dimension établi l'interface homme / entrepôt, elle comporte une
clé primaire » [Kimball, 2002].
48
1.2.1 Dim_Crédit
Un crédit est une mise à disposition d'argent sous forme de prêt, consentie par un
créancier à un débiteur.
Octroyer un crédit est une « Opération qui consiste pour un établissement de crédit à
mettre des fonds à la disposition d'un de ses clients (crédit par décaissement) ou à
s'engager à payer en cas de défaillance de celui-ci (crédit par signature) » [6]
La banque offre une vingtaine types de crédits pour ces clients telles que :
 Crédits de Campagne,
 Avance sur Marchandises,
 Préfinancement Exportation en Dinars,
 Avance sur Factures,
 Crédit de Financement de Stocks en dinars,
 Démarrage huiles.
Cette dimension décrit les caractéristiques d’un crédit qui sont illustrées dans le tableau
suivant :
Désignation Détails
ID_CREDIT La clé primaire
NUM_DEC Numéro décision
DAT_DEM Date de demande
COD_STRC Code agence
LIB_STRC Libellé de l'agence
DAT_VALDR Date de validation dans la direction

régionale
DAT_VALCCI Date de validation dans la direction

centrale
COD_STRC_DEC Code de structure de décision (DR ou
49
DC)
LIB_STRC_DEC Libellé de structure de décision (DR ou

DC)
DAT_MEP Date de mise en place
MNT_PRO Montant du crédit
COD_PRO Code du crédit
LIB_PRO Libellé du crédit
Tableau 5: Description de la dimension dim_crédit
1.2.2 Dim_garanties
Une garantie est un engagement envers un tiers qui vient garantir la bonne fin
d'une opération en cas de défaillance du payeur. [7]
La banque offre une trentaine types de garanties pour ces clients telles que :
 Domiciliation de marche privée,
 Nantissement de récoltes,
 Hypothèque maritime,
 Assurance véhicule,
 Assurance incendie.
Les caractéristiques d’une garantie sont illustrées dans le tableau suivant :
ID_GAR La clé primaire
G_NUM_DEC Numéro décision
RANG Rang d'une garantie
NUM_GAR Numéro de garantie
50
COD_GAR Code de garantie
LIB_GAR Libellé de garantie
Tableau 6: Description de la dimension dim_garantie
1.2.3 Dim_date
La dimension date est « la seule dimension qui figure systématiquement dans tout
entrepôt de données, car en pratique tout entrepôt de données est une série temporelle.
Le temps est le plus souvent la première dimension dans le classement sous-jacent de la
base de données ». [Kimball, 2011]
Le niveau de détail le plus bas de cette dimension est la journée (le mois). En
effet, l’un des objectifs de ce travail est de suivre l'activité au jour le jour (chaque mois).
Dans cette dimension, la clé primaire est une clé artificielle qui a la fourme de
(jjmmaaaa). Cette clé sert à faciliter la manipulation de la dimension.
Le tableau suivant donne plus de détails sur cette dimension
Date_id Clé primaire. La date pendant laquelle la

l'activité s’est passée
Année L’année pendant laquelle la l'activité s’est

passée
Mois Le mois pendant lequel la l'activité s’est

passée
Jour Le jour pendant lequel la l'activité s’est

passée
Tableau 7: Description de la dimension «dim_date »
1.2.4 Dim_agence
La BNA a 177 agences couvrant tout le territoire de la Tunisie. Chaque agence est
identifiée par une clé unique, un libellé, position de latitude et position de longitude.
51
La latitude est une expression de la position d'un point sur Terre au nord ou au sud de
l'équateur et la longitude est une expression du positionnement est-ouest d'un point sur
Terre.
ID_AGENCE La clé primaire
LIB_AGENCE Libellé de l'agence
LATITUDE Latitude de l'agence
LONGITUDE Longitude de l'agence
Tableau 8: Description de la dimension « dim_agence »
1.2.5 Dim_direction_decision
ID_DIRECTION_REGIONALE La clé primaire
LIB_DD Libellé de la structure de décision
LATITUDE Latitude de la structure de décision
LONGITUDE Longitude de la structure de décision
Tableau 9: Description de la dimension « dim_diection_decision»
1. 3 Choix des mesures

Un indicateur clé de performance « Key performance indicator » est une information ou un
ensemble d'informations permettant et facilitant l'appréciation, par un décideur, d'une
situation donnée. C'est une mesure d'un aspect critique de la performance globale du projet.
[5]
Les mesures doivent être :
52
 Clairs et en lien direct avec l’action à entreprendre,

 Les moins nombreux possibles,
 Non manipulables (doit être lu de la même façon),
 Prédictifs (doivent prévoir l’avenir),
 Évolutifs (doivent pouvoir évoluer dans le même temps que la stratégie).
Les mesures textuelles peuvent exister mais sont rares, ils sont généralement des valeurs
numériques, additives
Indicateurs Description Formule de calcul
MONTANT Le montant total des crédits Sum (Mnt_prod)

octroyé
NBR_CRE Le nombre des crédits octroyés Count (distinct

(num_dec))
NBR_CRE_GAR le nombre des crédits octroyés Count(distinct(G_nu

couvert par des garanties m_dec))
DUREE_ETUDE Période de traitement de la

Dat_valdr -
demande dat_dem
DUREE_DR-DC Période de transmission du

Dat_valcci-
dossier de la direction régionale dat_valdr
à la direction centrale
DUREE_REALISA Période de réalisation de la

Dat_mep -
TION demande dat_valcci
Date_mep -
DUREE_TOTALE Période total de traitement de
date_dem
dossier de crédit
Tableau 10: Récapitulatif des indicateurs
1.4 Table de faits
Une table de faits est la table centrale d'un modèle dimensionnel, où les mesures de
performances sont stockées, et elle comporte aussi des clés étrangères qui sont des clés
53
primaires des tables de dimensions. La table de fait dans notre cas se présente comme
suit
INDICATEUR TYPE
ID_FAIT Number <<FR>>
ID_CREDIT Number <<FR>>
ID_GAR Number <<FR>>
ID_D_DEM Number <<FR>>
ID_D_VALDR Number <<FR>>

Clés
étrangères ID_D_CCI Number <<FR>>
vers les tables
ID_D_MEP Number <<FR>>
ID_AGENCE Number <<FR>>
ID_DIRECTION DECISION Number <<FR>>
DUREE_ETUDE Number
DUREE_DR-DC Number
DUREE_REALISATION Number
Mesures
MONTANT Number
NBR_CRE Number
NBR_CRE_GAR Number
Tableau 11: La table de faits
54
1.5 Structure du Data warehouse
Nous avons choisi le modèle en étoile pour la réalisation du Data Warehouse. Il est
constitué d’une table de faits et cinq tables de dimensions. La table de faits est
constituée d’une clé primaire et des clés étrangères qui sont les clés primaires des tables
de dimension, plus les indicateurs qui nous servirons après lors de la création du tableau
de bord.
Figure 15: Modèle en étoile du datawarehouse
2. Conception ETL
Une fois le Data Warehouse conçu, il faut l'alimenter en données. Cette alimentation se
déroule en 4 phases qui sont :
 Etude des données source

 Extraction des données primaires (issue de la base de données source).
 Transformation des données.
 Le chargement des données traitées dans l'entrepôt de données.
Ces quatre étapes décrivent une mécanique cyclique qui a pour but de garantir
l'alimentation du Data Warahouse en données homogènes, propres et fiables
55
2.1 Etude des données sources
Cette première étape porte sur l'étude des données sources qui serviront par la
suite à l’alimentation du Data Warehouse. En effet, avant d’effectuer l’extraction des
données, il est important de bien connaître leurs contenues.
2.1.1 Bases de données sources

A cause des raisons de sécurité et de protection de données imposé par la BNA et
la non accessibilité à tous les données concernant les crédit et les garanties nous avons
obtenu donc quelque colonnes de deux tables sur deux fichiers Excel avec des données
qui contiennent des informations concernant les crédits et les garanties datés de l’année
2016 et 2017.
Nous avons obtenu aussi deux autres fichiers Excel qui contiennent les codes et
libellées de 178 agences et 16 directions régionales.
C’est pour cela nous avons créé une base de données sur SQL développer
nommée Source puis nous avons pris en charge ces données-là dans la base. Cette base
va être notre base source nommé "source" qui va alimenter la base du Data Warehouse
"output".
a) Description détaillée des tables sources

 Table crédit
C’est la table qui contient des détails sur un dossier de crédit.
Groupe thématique Informations
Informations crédits Id_crédit, numéro_décision,
Informations des structures Code_structure, libellé_structure,

code_structure_décision, libellé_structure_décision
Dates de crédits Date_demande, date_validation_direction_régionale

dat_validation_direction_centrale,
date_mise_en_place.
Figure 16: La table « crédit »

Ci-dessous la structure de la table
56
Figure 17: Structure de la table « Crédit »

Cette table contient les indicateurs que nous allons utiliser pour effectuer nos
calculs telles que le numéro_decision « num_dec », les quatre attributs dates
« dat_dem », « dat_valdr », « dat_valcci » et « dat_mep ».
 Table garantie
C’est la table qui contient des détails sur les garanties liées aux crédits.
Informations garantie Id_garantie,numéro_décision,

nature_garantie , numéro_garantie, rang
Informations crédit Montant_produit, code_produit.
Tableau 12: La table « garantie »

Après une étude exhaustive des données de cette table. Nous avons extrait
seulement les données dont nous avons besoin. Ci-dessous la totalité des champs
composant la table garantie.
57
Figure 18: Structure de la table « garantie »

Cette table contient les indicateurs que nous allons utiliser pour effectuer nos
calculs telles que le montant de crédit « mnt_pro » et le numéro_decision « num_dec ».
 Table produit
Comme nous avons mentionné auparavant la BNA met à la disposition de ces

clients une variété riche de types de crédit qui sont 455 en total. Cette table contient des
informations à propos les crédits.
Informations produit Code_produit, libellé_produit
Tableau 13: Table « produit »

Après l'étude des données de cette table. Nous avons extrait seulement les
colonnes dont nous avons besoin. Ci-dessous la totalité des champs composant la table
produit
58
Figure 19: Structure de la table « produits »

 Table agence
C’est la table qui contient des détails sur les agences.
Informations agence Code_agence, libelle_agence, latitude,

longitude, cod_dr
Tableau 14: La table « agence »

Puis nous avons enrichi cette table à l’aide de l'outil EarthViewMaps par l'ajout de
deux colonnes « latitude » et « longitude » qui sont les cordonnées de chaque agence sur
la carte de la terre.
Ensuite nous avons ajouté la colonne « cod_dr » qui indique le code de direction
régionale associé à chaque agence. Ci-dessous la totalité des champs composant la table
agence.
59
Figure 20: Structure de la table agence

 Table direction décision
C’est la table qui contient des détails sur les directions décision de la BNA qui sont 16
directions régionale, et une direction centrale.
Informations direction_decision Code_direction_décision,

libellé_direction_décision, latitude,
longitude
Tableau 15: La table « Direction décision »
Puis nous avons enrichi cette table à l’aide de l'outil EarthViewMaps par l'ajout de
deux colonnes « latitude » et « longitude» qui sont les cordonnées de chaque direction
décision sur la carte de la terre. Ci-dessous la totalité des champs composant la table
direction_decision.
60
Figure 21: Structure de la table direction décision
2.2 Extraction des données
« L'extraction est la première étape du processus d'apport de données à l'entrepôt de

donnée. Extraire, cela veut dire lire et interpréter les données sources et les copier dans
la zone de préparation en vue de manipulations ultérieures. » [Kimball, 2005].
Elle consiste en :
 Cibler les données,

 Appliquer les filtres nécessaires,
 Définir la fréquence de chargement.
Comme le montre la figure en dessous la table garantie contient 34 231 lignes de

données non cible. Ces garanties sont affectées à d’autres types de crédits.
Exemple : numéro de décision commencent par I, D, A dans la colonne num_dec
concernent les crédits d'investissement, les crédits à long terme, etc.
61
Figure 22: Données non cible dans la table « Garantie »
Comme la montre la figure en dessus la table produit contient des données non cible.
2.3 Transformation des données
La transformation est la seconde phase du processus. Cette étape assure en réalité

plusieurs tâches qui garantissent la fiabilité des données et leurs qualités. Ces tâches
sont :
 Consolidation des données,

 Elimination des données redondantes,
 Compléter et renseigner les valeurs manquantes,
 Correction des données et élimination de toute ambigüité.
Figure 23 : Données redondante dans la table « Garantie »
62
Comme la montre la figure en dessus la table garantie contient des lignes redondantes.
Ce qui nécessite l'élimination de la redondance par la suppression de ces valeurs
inappropriées afin de garantir le chargement des données fiables et pertinentes dans
l’entrepôt des données.
Exemple : la ligne 36 se répète 22 fois. En total on a 28 230 lignes en double.
Figure 24: Données ambigu dans la table « Garantie »

Comme la montre la figure en dessus la colonne nat_gar dans la table garantie contient
des données ambiguës que nous devons les corriger pour bien les exploiter par la suite.
Nous devons diviser cette colonne en 2 la première doit contenir la valeur numérique et
la deuxième les chaines de caractères.
Figure 25 : valeur manquante dans table garantie
63
La figure en dessus montre l'existence de 324 valeurs nulles dans la colonne num_dec
dans la table garantie
2.4 Chargement des données :
C'est la dernière phase de l'alimentation d'un entrepôt de données, le chargement

est une étape indispensable. Elle reste toutefois très délicate et exiges une certaine
connaissance des structures du système de gestion de la base de données afin
d'optimiser le plus le processus.
Le diagramme d’activités suivant décrit le processus général de l’alimentation de

l’entrepôt de données dès sa mise en service :
Figure 26: Diagramme d’activité du processus d’alimentation
64
3. Conception du tableau de bord
1. Table des agrégations
 Pourcentage des crédits octroyés par agence,
 Nombre des crédits octroyés par direction régional,
 Nombre des crédits octroyés par période,
 Nombre des crédits octroyés par agence et par période,
 Pourcentage des crédits octroyés couvert par garantie par agence,
 Nombre des crédits octroyés couvert par garantie par direction régional,
 Nombre des crédits octroyés couvert par garantie par période,
 Nombre des crédits octroyés couvert par garantie par agence et période,
 Nombre des crédits octroyés couvert par garantie par agence et produit,
 Montant total des crédits octroyés par période,
 Montant total des crédits octroyés par agence,
 Montant total des crédits octroyés par direction décision,
 Montant total des crédits octroyés par produit,
 La moyenne des durées d'étude des dossiers des crédits,
 La moyenne des durées de réalisation des dossiers des crédits,
 La moyenne des durées de transmission des dossiers des crédits de la

direction régionale a la direction centrale,
 La moyenne des durées totale de traitement des dossiers des crédits.
La liste des agrégations des rapports d’analyse des dossiers des crédits sites en
dessus donne les différentes statistiques que l’on peut calculer pour pouvoir juger le
processus d'octroi des crédits dans toutes les agences de la BNA. Ce qui va nous
permettre par la suite, et grâce aux tableaux de bord qui seront créés de découvrir les
agences les plus actives les agence qui émit le plus de temps pour le traitement des
dossiers de crédits ainsi que les pourcentages des crédits octroyés couvert par garantie.
65
Conclusion
Nous avons consacré ce chapitre à la conception de la zone d’entreposage, qui
constitue la zone exploitable par les utilisateurs. La conception de cette zone se fait
grâce à la modélisation dimensionnelle. Cette manière de représenter les données offre
aux utilisateurs des modèles intuitifs et compréhensibles permettant de naviguer et de
manipuler les données sans difficulté afin de satisfaire leurs besoins en analyse.
A présent, nous sommes capables d'entamer la partie réalisation.
66
Chapitre 5 :
Réalisation
67
Chapitre 5 : Réalisation
Introduction
Après avoir élaboré la conception de notre application, nous abordons dans ce chapitre
la dernière branche de la méthodologie suivie, qui a pour objectif d'exposer la phase de
réalisation.
La phase de réalisation est considérée comme étant la concrétisation finale de toute la

méthode de conception. Nous menons tout d’abord notre choix de l’environnement de
travail ensuite, nous présenterons la mise en place pratique de notre travail Enfin,
nous clôturons ce chapitre par la présentation des quelques interfaces homme-
machine du tableau de bord créé.
1. Environnement matériel et logiciel
Pour la réalisation de cette solution, nous avons eu recours à plusieurs moyens

matériels et logiciels :
1.1 Environnement matériel
L’environnement matériel sur lequel nous avons travaillé est constitué d'un ordinateurs
caractérisés par :
L’ordinateur :
 Marque : Dell attitude

 Système d’exploitation : Microsoft Windows 7 édition.
 Processeur : Intel(R) Core(TM) i5-4210M CPU @2.60 GHz
 RAM : 6,00 Go
 Disque dur : 500
1.2 Environnement logiciel
Après avoir présenté les moyens matériels. Nous abordons dans cette partie
l’environnement logiciel.
1.2.1 Oracle SQL Développer 12c

Nous avons utilisé ORACLE 12c comme SGBD pour le stockage des nos bases de
données sources ainsi que, l’entrepôt de données vu qu’il est un système de gestion des
bases de données utilisé par la BNA, de plus ce SGBD présente une richesse
68
fonctionnelle importante et connu par sa performance par rapport a sa capacité

importante de stockage de données.
Figure 27 : Oracle 12c
1.2.3 ETL: Talend Open Studio v 7.0.1
Talend Open Studio est un ETL (Extract Transform Load) Open Source, développé
par la société Talend. Cet outil intervient essentiellement dans la chaîne décisionnelle,
lors du processus d’intégration des données. Il permet de répondre à toutes les
problématiques liées au traitement des données dans la chaîne décisionnelle. [3]
Figure 28 : Talend Open Studio

Talend Open Studio est un ETL de type « générateur de code », c’est-à-dire qu’il permet
de créer graphiquement des processus de manipulation et de transformation de données
puis de générer l’exécutable correspondant sous forme de programme Java ou Perl.
1.2.4 Outil décisionnel QlikView
« QlikView est une plateforme de Business Discovery qui permet de récupérer et

d'assimiler des données provenant de différentes sources. Une fois les données chargées
dans le document QlikView, elles sont présentées de façon compréhensible et
utilisable. »[9]
69
Figure 29 : QlikView
QlikView gère les informations de la même manière que le cerveau humain. Ce logiciel
est totalement différent des logiciels traditionnels de Business Intelligence. Il est simple
d’utilisation et met l’utilisateur final en situation de contrôle total de ses analyses.
1.2.5 EarthViewMaps
Earth View Maps est un service de cartographie en ligne qui permet, à partir de l'échelle
d'un pays, de zoomer jusqu'à l'échelle d'une rue. Des prises de vue fixes montrant les
détails de certaines rues.
Nous avons utilisé Earth View Maps pour compléter nos bases de données sources.
Pour donner une richesse à nos données, nous avons ajouté à nos deux tables source
agence et direction régionale deux colonnes : latitude et longitude, qui sont rempli par
cet outil qui permet de trouver des coordonnées d'un point sur la carte de la terre.
Figure 30 : Interface Earth View Maps
70
2. Architecture globale de l'application
Deux phases sont fondamentales pour réaliser une application BI

fiable : la première est la phase d’extraction, de transformation et de
chargement réaliser par l'ETL TOS (Talend Open Studio) et la deuxième
est la phase de restitution effectué par l'outil QlikView.
Le schéma démonstratif suivant montre mieux la mise en place de notre application BI

dans ces différentes étapes
Figure 31: Architecture globale de notre application
3. Réalisation de la phase ETL
Dans cet axe, nous allons décrire les étapes de mise en œuvre du système décisionnel,
pour cela nous allons d’abord présenter les composants utilisés dans Talend Studio puis
nous élaborons les étapes suivies pour l’implémentation ETL.
71
3.1 Composants Talend utilisés
 tMap : L’élément tMap permet d’effectuer différentes jointures entre les

divers composants des sources de données et même des transformations sur des
flux. Il permet de choisir les données à extraire en se connectant à la base de
données de production, les transformer, les rendre homogènes et les charger
dans les tables de destination.
 tDBInput : Le composant tDBInput lit une base de données et en extrait

des champs à l'aide de requêtes. Il exécute une requête en base de données selon
un ordre strict qui doit correspondre à celui défini dans le schéma. La liste des
champs récupérée est ensuite transmise au composant suivant via une connexion
de flux.
 tDBOutput : Le composant tDBOutput écrit, met à jour, modifie ou

supprime les données d'une base de données. Ce composant exécute l'action définie
sur les données d'une table, en fonction du flux entrant provenant du composant
précédent.
 tFilterRow : Le composant tFilterRow filtre des lignes d'entrée en

définissant une ou plusieurs condition(s) sur les colonnes sélectionnées.
Ce composant aide à paramétrer les filtres sur les données source.
 tExtractRegexFields : Le composant tExtractRegexFields génère

plusieurs colonnes à partir d'une colonne donnée en utilisant la correspondance
regex. Ce composant permet d'utiliser des expressions régulières pour extraire
des données d'une chaîne.
 tUniqRow : Le composant tUniqRow compare les entrées et supprime

les doublons du flux d'entrée. Ce composant assure une qualité de données des
flux d'entrée et de sortie du Job.
72
3.2 Préparation de l’environnement de l’ETL
A l’aide du logiciel Talend, nous faisons l’extraction et le transfert des données de la

base de production vers l’entrepôt de données. Nous commençons notre travail par la
création d’un nouveau projet nommé « projet » :
Figure 32: Création projet

Puis, nous établissons une connexion à la base de données source de type oracle. Dans
ce stade, nous remplissons les différents champs pour assurer la bonne connexion :
Figure 33: Paramétrage de la connexion de la base de données source
73
Figure 34: La connexion à la base de production créée
La figure en dessus montre la création de la base de données de production et la

récupération des schémas des cinq tables sources.
3.3 Alimentation de l’entrepôt
Cette phase consiste à créer des jobs, sous l’ETL Talend, qui
comprend des composants d’extraction, de transformation et de
chargement. À l’aide de ces composants nous allons extraire les données
de leurs sources, faire les conversions des données nécessaires, et faire
des jointures entre les tables lorsque cela est nécessaire. Cette phase est la
plus critique de l’ETL.
74
3.3.1 Transformation des données
Avant de commencer le processus d’alimentation de l’entrepôt des

données, toutes les données inappropriées doivent être supprimées.
A. Transformation de la table garantie
D’après l’étude des données sources élaborée dans le chapitre conception, nous avons
signalé des données non cible, redondante et ambigu dans la table « garantie ».
Pour cette raison, nous avons commencé le processus ETL par un job qui permet à la fois
le nettoyage de la table garantie puis l'alimentation de la dimension dim_garantie.
Ce job est illustré dans la figure qui suit.
Figure 35 : Transformation et alimentation de dim_garantie

a) La figure suivante montre l'extraction des données cibles à partir de la table
source garantie à l'aide de composant tMap .
Avec ce composant nous avons choisi les données à extraire en se connectant à la base
de données source, les filtrer (ne pas extraire des valeurs nul), les rendre homogènes
(extraire que les num_décision commençant par G) puis les charger dans les tables de
destination.
Remarque : G fait référence au crédit de Gestion
75
Figure 36: Mapping de la table garantie
b) La figure suivante montre l'élimination des données ambiguës existantes dans la

table garantie. Nous avons remarqué que la colonne nature_garantie nat_gar est
former par une partie numérique qui désigne le code de garantie et une partie de
chaine de caractères qui désigne le libellé de garantie séparer par un point-
virgule";" .
Donc nous avons divisé la colonne garantie en 2 colonnes à l'aide du composant

tExtractRegexFields en utilisant les expressions régulières suivante pour extraire les
données d'une chaîne. ([0-9] *) ;(([a-zA-Z_0-9 ]*[é]*[è]*[ê]*[à]*[î]*[ç]*[']*)*) [21]
 cod_gar comportant les valeurs numériques de 0 à 9.

 lib_gar comportant les chaines de caractères qui est composé par des lettres des
espaces et des lettres avec accents.
76
Figure 37: Division de la colonne nat_gar

c) La figure suivante montre l'élimination des données redondante existante dans la
table garantie. A l'aide du composant tUniqRow nous avons supprimé les
doublons du flux de données en comparant toutes les colonnes sauf la clé
primaire.
77
Figure 38 : Suppressions des données redondantes
B. Transformations de la table Produit
D’après l’étude des données sources, des données non cible sont signalés dans la table
« produit ». Donc un deuxième job ''produit'' doit extraire que les données que
nous avons besoin dans notre étude. Cette opération se réalise avec le composant
tmap comme le montre la figure suivante.
Figure 39 : Mapping de table produit
78
C. Transformations de la table crédit
D’après l’étude des données sources, des données redondantes sont signalés dans la
table « crédit » pour éliminer ces redondances nous avons créé un job qui permet
à la fois le nettoyage de la tabla crédit puis l'alimentation de dimension
dim_credit.
La figure suivante montre l'opération de nettoyage qui se réalise avec le composant

tUniqRow qui élimine les doublons du flux de données en comparant toutes les
colonnes sauf la clé primaire.
Figure 40 : Capture d'écran avec tUniqurow
3.3.2 Alimentation des dimensions
Nous avons cinq tables de dimensions à charger depuis les tables

sources étudiées dans le chapitre précédent.
Ces tables sont : Dim_garantie,, dim_agence, dim_direction_decision, dim_crédit,

dim_date,.
 Dim_garantie : Cette table est alimentée par les données extraites de la table
source garantie qui sont transformées et nettoyer par tMap, tExtractRegexFields
et tUniqRow.
79
Figure 41 : Transformation et alimentation de dim_gar

 Dim_agence et Dim_direction_decision
Ces tables sont alimentées par les données contenues dans la base de données
"source" stocké sous oracle. Le composant tMap fait l'extraction de tous les
champs de la table source agence et la table source direction_désicion, et assure
le remplissage de la dim_agence, et la dim_direction_décision ligne par ligne.
Figure 42 : job Structure

 Dim_crédit : Cette table est alimentée par les données contenues dans la base de
données "source" à travers les deux tables crédit, garantie, et par les données
contenues dans la base de données "output" à trouver les deux tables produit et
dim_direction_decision.
Ce job nommé Dim_crédit figuré dans le schéma suivant, permet l’alimentation du

DataMart « Dim_crédit » :
80
Figure 43 : job Dim_crédit

Aprés l'élimination des lignes redondantes dans la table crédit par le composant
tUniqRow, les quatres tables sont liées entre eux par des clés étrangères num_dec,
cod_strc_dec et cod_pro en utilisant le composant tmap, qui assure comme expliqué
précédemment la jointure entre les tables et l’alimentation du table de sortie dim_crédit
ligne par ligne, comme il est figuré dans le schéma suivant.
Figure 44 : Mapping de dim_crédit
81
Le champ lib_strc_dec dans la table dim_crédit doit être rempli par

des données identifié par une expression, cette dernière est déterminée à
l'aide du constructeur d'expression comme le montre la figure suivante.
Figure 45 : Constructeur d'expression

Signifiquation de l'expression utilisé : Si lib_strc_dec de la table
crédit est « dir.régionale" alors dim_crédit prend la valeur de lib_dd de la
table produit, si non elle prend lib_strc_dec de la table crédit.
 Dim_date
Ce job nommé date figuré dans le schéma suivant, permet l’alimentation du DataMart
« Dim_date »
82
Figure 46 : job Dim_credit

Nous avons alimenté la dimension date à partir de la table
« dim_crédit ». Nous avons récupéré les valeurs des quatre attributs et les
fusionner en un seul flux à l’aide de composant tUnite. Puis nous avons
enlevé les doublons par tUniqRow. Ensuite nous avons triés les dates
dans un sens croissant à l'aide de composant tSortRow.
Par la suite avec le composant tMap nous avons :
 Décomposé les valeurs de dates selon les granularités dont nous avons
besoin : année, mois, jours en utilisant les fonctions TalendDate,
prédéfinies dans les expressions tMap
 Généré les valeurs des clés primaires avec la forme suivante :

ddmmyyyy.
Ci-dessous une figure démonstrative du mapping utilisé.
83
Figure 47: Le Mapping du job «dim_date »

3.3.3 Alimentation de la table de faits « Fait »
L’étape d’alimentation de la table de faits est la dernière étape du
processus ETL.
La table de faits « FAIT » est alimentée via toutes les tables dimension, en faisant la
lecture de la table dim_date quatre fois dans le but de faire la jointure chaque fois avec
un attribut date dans la table dim_crédit.
Le chargement et les jointures se réalisent avec le composant tMap, comme le montre le

job figuré dans le schéma ci-dessous.
Figure 48 : job Fait
Ci-dessous une figure démonstrative du mapping utilisé
84
Figure 49: Le Mapping du job FAIT
3.4 Processus ETL global : job « DataMart_Crédit »
Ce job nommé « DataMart_Crédit » récapitule le processus ETL de

notre solution.
En effet, des sous jobs se lancent successivement tous liés par un OnComponenetOk .
D'abord le sous job nommé « produit » se lance :
Il se connecte à la table produit dans la base de données source, il extrait les deux
champs nécessaires par le composant tMap.
Par la suite, un deuxième sous job se lance « structure » :

 Il se connecte aux deux tables agence et direction_décision dans la base de
données production,
 Il alimente les deux tables dans la base de données decisionnelles dim_agence et
dim_structure_decision par des simples liaisons avec le composant tMap.
Ensuite un troisième sous job se lance « dim_garantie » :
 Il se connecte à la table garantie de la base de données "souce",

 Il effectue des opérations d'extraction des colonnes nécessaire, et de filtrage du
numéro de décision (de crédit de gestion) et la suppression des valeurs nuls
grâce au composant tMap,
85
 Il divise la colonne nature_garantie en deux colonnes code_garantie et

libellé_garantie grâce au composant tExtractRegexFields,
 Il supprime les lignes redondantes par le composant tUniqRow.
Puis, un quatrième sous job se lance « dim_crédit » durant cette étape :

 Il se connecte aux deux tables dans la base de données de production crédit et
garantie et deux tables dans la base de données décisionnelle Produit et
dim_direction_decision.
 Il élimine les lignes redondantes dans la table crédit par le composant tUniqRow.
 Il fait la jointure entre les quatre tables par des clés étrangères en utilisant le
composant tmap, puis il charge la table de sortie dim_crédit ligne par ligne.
Maintenant puisque toutes les tables dimension sont chargées, alors à l'aide de
composant tDBCconnection il se connecter à la base des données "output" pour
alimenter la table fait_credit .
En fin un cinquième sous job se lance « Fait_credit » :
 Il se connecte au cinq tables dimension dans la base de données décisionnelle,
 Il extrait la clé primaire de chaque table et le transmet dans la table fait_credit,
 Il calcule les mesures par des expressions de calcule intégrés dans talend.
Nous illustrons dans la figure suivante notre Job mère nommée « Fait_credit »
Figure 50: Fait_credit
3.5 Mise à jour des données de l’entrepôt
Le rafraîchissement périodique des données du DataMart est une

phase fondamentale. Il est possible de choisir l’action à appliquer sur les
86
données entrantes aux tables de destination parmi « update or insert » si

les mises-à-jours sont jugées plus volumineuses que les insertions et «
insert or update » en situation inverse.
Talend Open Studio contient un programmeur de tâches « scheduler » qui permet de

configurer le script d’exécution des jobs. Il n’est pas possible d’utiliser ce « scheduler »
qu’à avec la version Entreprise du TOS. Ci-dessous une figure illustrant l’ordonnanceur
Talend.
Figure 51 : Ordonnanceur des tâches Talend [20]

Si nous disposons de la version Entreprise du logiciel Talend, nous
pouvons ordonnancer une mise à jour des données chaque minuit par
exemple à travers le scheduler illustré ci-dessus.
4. Réalisation du tableau de bord
Notre Data warehouse est créé et alimenté avec toutes les tables
nécessaires à l’élaboration des analyses, et notre choix de l’outil de
restitution est déjà fait. Donc il nous reste que d’entamer le travail
requis : la création du tableau de bord de processus d'octroi de crédit de
gestion.
87
4.1. Connexion à l’entrepôt de données :
Avant d’entamer nos analyses, il faut se connecter à la source de

données, et ceci via un utilitaire très intuitif qu’on démarre depuis
l’accueil de QlikView en cliquant sur l’icône « Edit script » qu’affiche la
capture ci-dessous.
Figure 52: Interface d’accueil de « QlikView »

La connexion entre le data warehouse et l’outil de visualisation
QlikView s’effectue via un driver ODBC propriétaire :
« OracleODBCDriver » qui permet l’accès aux tables de l’entrepôt de
données.
D’abord on commence par installer ce pilote sur l’ordinateur.
Ensuite, on doit configurer une source de données sous Windows par le biais du pilote
« OracleODBCDrive» .Cette source de données est désormais utilisable pour se
connecter à l’entrepôt de données.
88
Figure 53: Configuration de la source de données « DWH-connection »

QlikView est prêt maintenant à se connecter directement à notre data warehouse via la
source de données "output" configurée précédemment.
Figure 54: Etablissement de la connexion entre QlikView et l’entrepôt des données
4.2 Chargement des données dans QlikView
Une fois la connexion établie, nous procédons au chargement des données dans
QlikView. Cette étape se réalise grâce au script qui suit :
89
Figure 55: Script pour le chargement des données dans QlikView

Une fois implémenté dans l’outil décisionnel, il faut alimenter notre modèle de données.
Figure 56: Visionneur de tables

Cette interface permet de visionner les tables de notre Data Mart « Fait_Credit »
4.3 Interfaces homme-machine
Un tableau de bord n’est pas seulement une collection des

indicateurs bien choisis. En fait, Un bon tableau de bord doit être bien
structuré, organisé et désigné pour réussir dans son rôle d’aide à la
décision. Pour cette raison, nous avons divisé nos axes en 4 catégories :
Situation globale, crédits, garantie, temps.
4.3.1 Ecran d’accueil

A l’ouverture de l’application, l’utilisateur reçoit une interface
d’accueil qui contient le logo de la BNA, ainsi que le nom de
l’application « Tableau de bord pour le processus d'octroi des crédits de
gestion »
90
Figure 57: Interface d’accueil

4.3.2 Ecran de la situation globale
Figure 58: Ecran de la feuille « Situation globale »
En cliquant sur l’onglet situation globale, une interface décrivant la

situation globale des crédits de gestion s’affiche.
Comme la montre l’interface, l’utilisateur peut choisir ses axes

d’analyse grâce aux options qui se présentent au côté gauche de l’écran,
en haut, l’axe du temps se divise en 4 axes, présente chacun un indicateur
91
de dates (dat_dem, dat_valdr, dat_valcci, dat_mep) hiérarchisé sur

plusieurs niveaux : Année, mois, jour.
L’utilisateur peut sélectionner un ou plusieurs axes, les sélections

en cours s’affichent dans la zone « sélection en cours ». Si aucune
sélection n’est faite les résultats qui s’affichent sont relatifs à la situation
globales d'octoir des crédits qui s'affichent dans deux tableaux. Ces
tableaux contiennent des informations relatives aux crédits dans toutes
les agences et direction régionale analyser par totale d'engagement, par
produit, par garantie, par rang des garanties et par quelque durée de
traitement des dossiers des crédits
4.3.3 Ecran de la feuille « crédit »
Figure 59: Ecran de la feuille « Crédit »
En cliquant sur l’onglet crédit, une interface décrivant les crédits

s’affiche. Cette feuille se concentre sur les analyses dont l’axe principal
est la dimension « Dim_crédit ».
92
Comme nous remarquons sur cet écran, une variété des objets est mise à la disposition
du décideur.
L’histogramme situé en haut et à gauche de l’écran donne le

nombre des crédits octroyés par direction régionale ainsi le secteur juste à
son côté à droite donne le pourcentage des crédits octroyés par agence.
Par exemple les 3 agences les plus actives sont (Sfax, Tunis B, Sfax
Poudriere).
La courbe intitulé « Nombre des crédits octroyés par période » renseigne sur l'évolution
du nombre des crédits octroyés par année et par mois. Par exemple 3624 est le plus
grand nombre d'octroi des crédits qui est à 2017 pendant le mois juin.
L’histogramme situé juste à côté, présente le nombre des crédits octroyé par produit.
4.3.4 Ecran de la feuille « Les garantie »
Figure 60: Ecran de la feuille « Garantie »
93
Ayant la même structure que l’interface des crédits, cette feuille se

concentre sur les analyses dont l’axe principal est la dimension
« Dim_garantie ».
Comme nous remarquons sur cet écran, Cette feuille se focalise sur les crédits couverts
par garanties.
Nous avons utilisé une boucle pour afficher dans le même histogramme qui se situe en
haut et à gauche de l’écran le nombre des crédits octroyés couvert par garantie par
direction régionale et le totale d'engagement par direction régionale.
Ainsi le secteur juste à son côté à droite donne le pourcentage des crédits octroyés
couvert par des garanties par agence et aussi avec un simple clic un changement rapide
s'effectue pour afficher le totale d'engagement par agence.
Aussi nous avons analysé le total d'engagent par année et le nombre des crédits octroyés
par années et les résultats sont affiché dans la courbe en bas de l'écran.
Les deux histogrammes en bas à droite de l'écran donnent les nombres des crédits
couverts par garanties octroyés par nature et par rang. On remarque que les garantie 201
et 501 et les garanties ayant le rang numéro un sont les plus utiliser.
4.3.5 Ecran de la feuille « Temps »
94
Figure 61: Ecran de la feuille « Temps »

Ayant la même structure que les interfaces précédentes
Nous avons consacré cette dernière feuille pour faire le suivi du processus d'octroi des
crédits par période en se basant sur la dimension "dim_date"
Dans cette feuille, nous visualisons les durées calculées dans la table fait par direction
décision, par agence, par types des crédits et par garantie en utilisant des histogrammes.
C’est facilement remarquable à partir du premier graphe à gauche que la direction

centrale ayant le code 780 est la direction qui émet la plus grande durée pour le
traitement des dossiers des crédits.
L'histogramme juste a son côté affiche que les trois agence (succursale de tunis, Beja,
Amdoun) ayant les codes structures 120, 11, 125 émettent plus de 15 jours pour le
traitement des dossiers des crédits donc ces 3 agence ont les plus grandes durées de
traitement des données.
Conclusion
Au cours de ce chapitre, nous avons présenté en détails la projection de la conception du
plan théorique sur le plan pratique. En effet, nous avons décrit les plates-formes
matérielles et logicielles sur et avec lesquelles nous avons construit notre application.
Nous avons par la suite élaboré les étapes du processus ETL. Finalement, nous avons
illustré l’utilisation de l’application en ce qui concerne la situation du processus d'octroi
des crédits de gestion par des interfaces graphiques de l’application.
95
96
Conclusion générale
Exploiter les données à disposition de l’entreprise afin de leur

donner de la valeur ajoutée, est le défi des entreprises modernes.
Dans ce cadre, la BNA a initié le projet de réalisation d’une

application BI fiable et efficace dont l’objectif est le suivi de processus
d'octroi des crédits de gestion grâce à un système décisionnel. Ce dernier
ne se conçoit pas sans l’intermédiaire d’un entrepôt de données qui
regroupe l'opération d'octroi des crédits effectuées dans les différentes
agences ainsi que les informations qui leurs sont relatives, c’est pour
cette raison que nous avons recouru aux bases de données décisionnelles.
Afin de réussir notre projet nous avons élaboré la stratégie qui

consiste les étapes suivantes :
D’abord, nous avons réalisé une étude complète pour comprendre

le métier de l’entreprise et leur environnement de travail.
Puis, nous avons élaboré une étude exhaustive de nos sources des
données. Il nous a fallu un grand temps pour achever cette étape à cause
des difficultés rencontrées.
L’une de ces difficultés, qui était la plus ardue, concerne la compréhension de la

structure des sources des données. En effet, nous avons dû surmonter cette structure
complexe composée de plusieurs tables, chacune parvient d'un système différent.
Ensuite, nous nous sommes tournés à la modélisation de l’entrepôt de données. Cette

phase est faite grâce aux principes de la modélisation dimensionnelle. Cette
modélisation offre une vision claire et une compréhension intuitive des modèles
proposés. Nous avons de ce fait proposé de modèle en étoile pour notre activité
recensée.
Par la suite, nous avons réalisé l’alimentation du Data warehouse.

Cette phase a été sans doute la partie du projet la plus fastidieuse et
consommatrice en temps. Plus que 50% du temps a été consacré à la
réalisation du Data warehouse. Cette étape nous a permis de concevoir et
97
de réaliser, grâce à des outils open source, les routines d’extraction,

transformation et chargement des données.
Une fois les données sont chargées dans l’entrepôt de données,

nous avons procédé à l’étape finale du processus BI, qui est la restitution
des données. C’est durant cette phase que nous avons mis en place un
tableau de bord qui contient les indicateurs de suivi du processus d'octroi
des crédits et qui contribue à minimiser les efforts fournis par les
décideurs dans le processus de prise de décision.
En fait, ce projet nous a été d'une grande utilité en termes de

savoir-faire et d'un grand intérêt en apport de connaissances utiles. C’est
ainsi que nous avons pu mettre en pratique les différentes connaissances
techniques, et pu nous projeter dans le monde réel des entreprises et dans
le milieu professionnel avec tout ce qu’il implique en termes de
discipline, de responsabilité et de travail en équipe.
Comme un projet Data Warehouse n’est jamais complètement terminé, nous pouvons
citer les perspectives et les développements suivants :
 Utilisation des méthodes et algorithmes de Data Mining pour une meilleure

exploitation des données.
 L'analyse des données de notre Data warehouse selon différents niveaux de

détails par le concept OLAP
98
Bibliographie
Bibliographie
Sites Internet :
 www.bna.com.tn [1] [Consulté en 03/2018]
 https://business-intelligence.developpez.com/tutoriels/etl-open source/?
page=Introduction [2] [Consulté en 03/2018]
 help.talend.com : Guide de prise en main de Talend Open Studio for Data
Integration [3] [Consulté en 04/2018]
 www.lemagit.fr conseil/Deployer-un-entrepot-de-donnees-quels-avantages [4]
[Consulté en 03/2018]
 bricks.univ-lille1.fr/M26/cours/co/chap3_01.html [5] [Consulté en 03/2018]
 www.banque-info.com/lexique-bancaire [6] [Consulté en 06/2018]
 www.lexique-financier.actufinance.fr/dictionnaire-banque [7] [Consulté en

06/2018]
 www.iso.org/fr Organisation internationale de normalisation [8] [Consulté en

06/2018]
 www.supinfo.com/articles/single/1914-qlikview [9] [Consulté en 07/2018]
 www.cnam-idf.fr/informatique-decisionnelle-nfe115[10] [Consulté en 05/2018]
 https://graphorama.net/Caracteres-speciaux-codes-ASCII-et-HTML-Alt-
codes.html [21] [Consulté en 06/2018]
 www.talendforge.org/ [20] [Consulté en 07/2018]
 https://sql.sh/cours [22] [Consulté en 05/2018]
 https://grim.developpez.com/cours/businessintelligence/concepts/conception-
datawarehouse [23] [Consulté en 05/2018]
 https://www.compta-facile.com/choisir-indicateurs-tableau-de-bord [24]
 http://www.easyneo.fr/qlikview.html [25] [Consulté en 05/2018]
 https://www.next-decision.fr/wiki/qlik-sense-vs-qlikview [26] [Consulté en
05/2018]
 https://community.qlik.com/groups/qlikview-brasil/blog/2015/07/19/ [27]
99
Bibliographie
Ouvrage :
 [Kimball , 2002]: R. Kimball et M. Ross ; « Entrepôts de Données : Guide
Pratique de Modélisation Dimensionnelle 2ème édition » ;
 [Kimball , 2005] Guide de conduite de projet , 1ère Edition ;Paris,
France ;Eyrolles ;Mars 2005.
 [Kimball , 2011] The Microsoft Data Warehouse Toolkit ;Second Edition;
2011
 [Soler, 2001] : Y.Soler; PLANIFICATION ET SUIVI D'UN PROJET; 2001
 [Luhn, 1958] : , « A Business Intelligence System ».
 [Gartner survey 2014 ] : « BETTER DATA THROUGH BI» . Today’s BI
Tools
 [Luhn, 1958] : www.asist.org, Association for Information Science and
Technology
Fichiers divers :
 Circulaire BNA N°2017/76 Relative au nouveau organigramme de la Banque
[11]
 Circulaire BNA N°2017/116 relative la présentation des missions et attributions
du pôle organisation et Système d'Information [12]
 Circulaire BNA N°2016/12 Relative a la procédure d'octroi et de traitement d'un
crédit de gestion [13]
 Présentation BNA 2017 : Processus d’octroi et de mise en place des crédits [14]
 Présentation BNA 2017 : Gestion des CME dans le cadre du Nouveau Système
d’engagements S.A.E.B
 Cahier de Charge SAEB Escompte
 (CIRCULAIRE AUX BANQUES N°87-47, 1987) [15]
100
Bibliographie
101

BaccoucheHellaMise en Place Dun Entrepot de Données Pour Le Processus Doctroit Des Credits de Gestion Copie 1

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

BaccoucheHellaMise en Place Dun Entrepot de Données Pour Le Processus Doctroit Des Credits de Gestion Copie 1

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE TUNISIENNE

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

FACULTE DES SCIENCES ECONOMIQUES

MEMOIR DE FIN D’ETUDES

Pour l'obtention de diplôme de Master professionnel en Ingénierie

Mise en place d'un entrepôt de données pour le

Réalisé au sein de la BNA

Réalisé par : Baccouche Hella Encadrants : FSEGT Mme Kboubi Fariha

Année Universitaire 2017/2018

Mes parents, pour leur soutient indéniable et leur aide

« Pourrais-je jamais vous dire tous mon amour»,

Mon frère Aymen et mes sœurs Imen et Hayfa pour leurs

Tous les membres de la famille, pour l’intérêt qu’ils m’ont

Mes amis, pour tous ce qu’on a partagés ensemble,

Toutes les personnes proches que je n’ai pas citées

Introdu ction générale

La mondialisation des échanges, la globalisation des marchés et l’innovation

Face aux évolutions nombreuses et rapides qui s’imposent aux organisations, la

Dans le cadre de notre stage au sein de la BNA, le système d'information se

Ainsi la réalisation de ce projet nous amène à suivre le plan de travail en quatre

 Chapitre 1 : « Contexte du projet »

 Chapitre 2 : « Etat de l'art »

 Chapitre 3 : «Etude de l’existant et spécification des besoins»

représentation de quelques interfaces de notre application sous formes des captures

Ce chapitre est consacré à la présentation de l’organisme d’accueil. Ensuite, nous

A la fin de ce chapitre nous justifions la méthodologie de conception adoptée et

1.1 Histoire de la BNA

À l'époque de sa création, l'agriculture tunisienne est financée par l'ancien système

La restructuration le 24 juin 1989 de la BNT et sa fusion avec la Banque Nationale de

Cette fusion constitue le début du processus de restructuration du système bancaire

Figure 1: Historique de la BNA

1.2 Présentation de la banque « BNA »

La Banque nationale agricole (‫( )البنك الوطني الفالحي‬BNA) a le statut de Société

La BNA est la première banque tunisienne spécialisée dans le financement agricole.

Figure 2: Organigramme de la BNA

1.3 Produit et services

2. Description du cadre de travail

Notre travail est assimilé au sein du pôle d'organisation et système d'information,

 Veiller à l'amélioration de la gouvernance IT de la banque.

La BNA propose de mettre en place un tableau de bord centralisé qui permet de

Les crédits pour les entreprises (crédit de gestion) concernent :

L’application décrite ci-dessus doit répondre aux objectifs suivants :

 Modéliser un entrepôt de données pour les données de gestion des dossiers de

4.1 Comparaison des methodologies de travail

Méthodologie Description Points forts Points faibles

Cascade  Les phases se  Distingue  Non itératif

RUP (Rational  Le RUP est à la fois  Itératif  Vision non

Scrum  Se base sur des  Entièrement  Peu, voire pas, de

itérations dites développé et testé documentation

2TUP (Two  Propose un cycle de  Itératif  Ne propose pas des

Tableau 1: Tableau comparatif des différentes méthodologies de Travail

4.2 Choix de la méthodologie de travail

Suite à l’étude et à la comparaison des principaux processus de développement

développement. Cette méthode ne se base aucunement sur un processus linéaire mais

Le Processus Unifié (PU ou UP en anglais pourUnified Process) est une méthode

Itérative et incrémentale : la méthode est itérative dans le sens où elle propose

Centrée sur l’architecture : les modèles définit tout au long du processus de

2TUP c’est un processus qui répond aux caractéristiques du Processus Unifié. Il

Figure 3: Méthodologie 2TUP [2]

Les fonctions du système d’information sont en effet indépendantes des technologies

 La capture et l'analyse des besoins fonctionnels, qui produit un modèle des

La branche droite (branche technique) : capitalise un savoir-faire technique.

Cette branche comporte les étapes suivantes :